First Normal Form (1NF) heeft twee basisregels voor een genormaliseerde en georganiseerde database. De eerste is om dubbele kolommen uit dezelfde tabel te verwijderen. De tweede is om afzonderlijke tabellen te maken voor elke groep gerelateerde gegevens en elke rij te identificeren met een unieke kolom (de primaire sleutel). Wat betekenen deze regels bij het nadenken over de praktische opzet van een database?
Duplicatie elimineren
De eerste regel schrijft voor dat we geen gegevens binnen dezelfde rij van een tabel mogen dupliceren. Binnen de databasegemeenschap wordt dit concept de atomiciteit van een tabel genoemd. Tabellen die aan deze regel voldoen, worden atomair genoemd. Laten we dit principe onderzoeken aan de hand van een klassiek voorbeeld: een tabel in een HR-database waarin de relatie tussen manager en ondergeschikte is opgeslagen. Voor de doeleinden van ons voorbeeld zullen we de bedrijfsregel opleggen dat elke manager een of meer ondergeschikten mag hebben, terwijl elke ondergeschikte slechts één manager mag hebben. Bij het maken van een lijst of spreadsheet om deze informatie bij te houden, kunnen we intuïtief een tabel maken met de volgende velden:
- Manager
- ondergeschikte1
- ondergeschikte2
- ondergeschikte3
- ondergeschikte4
Onthoud echter de eerste regel die is opgelegd door 1NF: verwijder dubbele kolommen uit dezelfde tabel. Het is duidelijk dat de kolommen Ondergeschikt1 tot en met Ondergeschikt4 duplicatief zijn. Neem even de tijd en denk na over de problemen die dit scenario met zich meebrengt. Als een manager slechts één ondergeschikte heeft, zijn de kolommen Ondergeschikt2 tot en met Ondergeschikt4 verspilde opslagruimte (een kostbaar databaseproduct). Stel je bovendien het geval voor waarin een manager vier ondergeschikten heeft. Wat gebeurt er als ze een andere werknemer aannemen? De tabelstructuur zou moeten worden aangepast. Op dit punt komt er meestal een tweede helder idee bij database-beginners op: we willen niet meer dan één kolom hebben en we willen een flexibele hoeveelheid gegevensopslag mogelijk maken; laten we iets als dit proberen:
- Manager
- ondergeschikten
En het veld Ondergeschikten zou meerdere vermeldingen bevatten in de vorm van ‘Mary, Bill, Joe’. Deze oplossing is dichterbij, maar schiet ook tekort. De kolom ondergeschikten is nog steeds duplicatief en niet-atomair. Wat gebeurt er als we een ondergeschikte moeten toevoegen of verwijderen? We moeten de volledige inhoud van de tabel lezen en schrijven. Dat is in deze situatie niet erg, maar wat als één manager honderd medewerkers had? Het bemoeilijkt ook het proces van het selecteren van gegevens uit de database bij toekomstige zoekopdrachten. Hier is een tabel die voldoet aan de eerste regel van 1NF:
- Manager
- Ondergeschikt
In dit geval heeft elke ondergeschikte één vermelding, maar managers kunnen meerdere vermeldingen hebben.
Identificeer de primaire sleutel
Hoe zit het nu 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 Ondergeschikte kolom als primaire sleutel voorstellen. In feite is de kolom Ondergeschikte een goede kandidaat voor een primaire sleutel vanwege het feit dat in onze bedrijfsregels is gespecificeerd dat elke ondergeschikte slechts één manager mag hebben. 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, genaamd Jim? Hoe slaan we zijn manager-ondergeschikte relatie op in de database? Het is het beste om een unieke identificatie te gebruiken, zoals een such Werknemer-ID als primaire sleutel. Onze finaletafel ziet er als volgt uit:
- Manager-ID
- Ondergeschikte ID
Nu is onze tabel in de eerste normale vorm. Verder zijn er opties om uw database in de tweede normale vorm te plaatsen, evenals in de derde normale vorm als u enthousiast bent over meer organisatie.
