Første Normal Form (1NF) fastsætter de grundlæggende regler for en organiseret database:
- Eliminer duplikative kolonner fra samme tabel.
- Opret separate tabeller for hver gruppe relaterede data og identificer hver række med en unik kolonne (primærnøglen).
Hvad betyder disse regler, når man overvejer det praktiske design af en database? Det er faktisk ret simpelt.
Eliminere duplikering
Den første regel dikterer, at vi ikke må duplikere data inden for samme række i en tabel. Inden for databasens samfund betegnes dette koncept som et bords atomitet. Tabeller, der overholder denne regel, siges at være atomiske. Lad os undersøge dette princip med et klassisk eksempel: Et bord i en human resource database, der lagrer det underordnede manager-underordnede forhold. Med henblik på vores eksempel pålægger vi forretningsreglen, at hver leder kan have en eller flere underordnede, mens hver underordnede kun har én administrator.
Intuitivt, når vi opretter en liste eller et regneark for at spore disse oplysninger, kan vi oprette en tabel med følgende felter:
- Manager
- Subordinate1
- Subordinate2
- Subordinate3
- Subordinate4
Husk dog den første regel pålagt af 1NF: Eliminer duplikative kolonner fra samme tabel. Det er klart, at kolonnen Underordnede1-Underordnede4 er duplikative. Tag et øjeblik og overvej de problemer, der opstår i dette scenario. Hvis en leder kun har en underordnet, slettes underordnede2-underordnede4 kolonner simpelthen oplagringsplads (en værdifuld databasevare). Desuden kan du forestille dig, hvor en leder allerede har 4 underordnede - hvad sker der, hvis hun påtager sig en anden medarbejder? Hele bordstrukturen ville kræve ændring.
På dette tidspunkt opstår der en ny lyst idé, som regel begynder med databasen begyndere: Vi ønsker ikke at have mere end en kolonne, og vi ønsker at tillade en fleksibel mængde datalagring. Lad os prøve noget som dette:
- Manager
- Underordnede
Og feltet Underordnede vil indeholde flere poster i formularen "Mary, Bill, Joe."
Denne løsning er tættere, men den falder heller ikke under mærket. Underordnede kolonne er stadig duplikativ og ikke-atomisk. Hvad sker der, når vi skal tilføje eller fjerne en underordnet? Vi skal læse og skrive hele indholdet af tabellen. Det er ikke en stor ting i denne situation, men hvad hvis en leder havde et hundrede medarbejdere? Det komplicerer også processen med at vælge data fra databasen i fremtidige forespørgsler.
Her er et bord, der opfylder den første regel af 1NF:
- Manager
- underordnet
I dette tilfælde har hver underordnet en enkelt post, men ledere kan have flere poster.
Identificer den primære nøgle
Hvad med den anden regel: Identificer hver række med en unik kolonne eller et sæt kolonner (primærnøglen). Du kan tage et kig på tabellen ovenfor og foreslå brugen af den underordnede kolonne som en primærnøgle. Faktisk er den underordnede kolonne en god kandidat til en primærnøgle på grund af, at vores forretningsregler specificerede, at hver underordnede kun har en leder. Men de data, som vi har valgt at gemme i vores bord, gør dette til en mindre end ideel løsning. Hvad sker der, hvis vi ansætter en anden medarbejder ved navn Jim? Hvordan gemmer vi hans manager-underordnede forhold i databasen?
Det er bedst at bruge en helt unik identifikator (som et medarbejder-id) som en primær nøgle. Vores finalebord ville se sådan ud:
- Manager ID
- Underordnet ID
Nu er vores bord i første normale form! Udover dette er der muligheder for at sætte din database i Second Normal Form samt Tredje Normal Form, hvis du er begejstret for endnu mere organisation.
