First Normal Form (1NF) stelt de basisregels in voor een georganiseerde database:
- Elimineer duplicatieve kolommen uit dezelfde tabel.
- Maak afzonderlijke tabellen voor elke groep verwante gegevens en identificeer elke rij met een unieke kolom (de primaire sleutel).
Wat betekenen deze regels als je nadenkt over het praktische ontwerp van een database? Het is eigenlijk vrij simpel.
Duplicatie elimineren
De eerste regel dicteert dat we geen gegevens moeten dupliceren binnen dezelfde rij van een tabel. Binnen de databasecommunity wordt dit concept de atomiciteit van een tabel genoemd. Tabellen die aan deze regel voldoen, zouden atoom zijn. Laten we dit principe onderzoeken met een klassiek voorbeeld: een tabel in een personeelsdatabase waarin de relatie manager-ondergeschikte wordt opgeslagen. Voor het doel van ons voorbeeld leggen we de bedrijfsregel op dat elke manager een of meer ondergeschikten kan hebben, terwijl elke ondergeschikte mogelijk slechts één manager heeft.
Intuïtief kunnen we bij het maken van een lijst of spreadsheet om deze informatie bij te houden, een tabel maken met de volgende velden:
- Manager
- Subordinate1
- Subordinate2
- Subordinate3
- Subordinate4
Roep echter de eerste regel op die is opgelegd door 1NF: verwijder duplicatieve kolommen uit dezelfde tabel. Het is duidelijk dat de Subordinate1-Subordinate4 kolommen duplicatief zijn. Neem een moment en denk na over de problemen die dit scenario met zich meebrengt. Als een manager slechts één ondergeschikte heeft, zijn de Subordinate2-Subordinate4-kolommen gewoon verspilde opslagruimte (een kostbare database-grondstof). Stel je bovendien het geval voor waarin een manager al 4 ondergeschikten heeft - wat gebeurt er als ze een andere werknemer opneemt? De hele tabelstructuur zou moeten worden aangepast.
Op dit moment gebeurt er meestal een tweede helder idee bij database-beginners: we willen niet meer dan één kolom hebben en we willen een flexibele hoeveelheid gegevensopslag mogelijk maken. Laten we zoiets proberen als dit:
- Manager
- ondergeschikten
En het veld Ondergeschikten zou meerdere vermeldingen bevatten in de vorm "Mary, Bill, Joe."
Deze oplossing is dichterbij, maar schiet ook tekort. De kolom met ondergeschikten is nog steeds duplicatief en niet-atomisch. Wat gebeurt er wanneer we een ondergeschikte moeten toevoegen of verwijderen? We moeten de volledige inhoud van de tabel lezen en schrijven. Dat is geen probleem in deze situatie, maar wat als één manager honderd werknemers had? Bovendien bemoeilijkt dit het proces voor het selecteren van gegevens uit de database in toekomstige zoekopdrachten.
Hier is een tabel die voldoet aan de eerste regel van 1NF:
- Manager
- Ondergeschikt
In dit geval heeft elke ondergeschikte een enkele invoer, maar managers kunnen meerdere vermeldingen hebben.
Identificeer de primaire sleutel
Nu, hoe zit het met de tweede regel: identificeer elke rij met een unieke kolom of reeks kolommen (de primaire sleutel). U kunt de bovenstaande tabel bekijken en het gebruik van de onderliggende kolom als primaire sleutel voorstellen. In feite is de onderliggende kolom een goede kandidaat voor een primaire sleutel vanwege het feit dat onze bedrijfsregels hebben gespecificeerd dat elke ondergeschikte mogelijk slechts één manager heeft. De gegevens die we in onze tabel hebben opgeslagen, maken dit echter een minder dan ideale oplossing. Wat gebeurt er als we een andere werknemer aannemen die Jim heet? Hoe slaan we zijn manager-ondergeschikte relatie op in de database?
Het is het beste om een echt unieke ID (zoals een medewerker-ID) als primaire sleutel te gebruiken. Onze finaletafel zou er als volgt uitzien:
- Manager-ID
- Ondergeschikte ID
Nu is onze tafel in de eerste normale vorm! Verder zijn er opties om uw database in Second Normal Form en Third Normal Form te plaatsen als u enthousiast bent over nog meer organisatie.
