Vi har set på flere aspekter ved normalisering af en database tabel. For det første diskuterede vi de grundlæggende principper for database normalisering. Sidste gang undersøgte vi de grundlæggende krav, der var fastsat ved den første normale formular (1NF). Lad os nu fortsætte vores rejse og dække principperne for den anden normale form (2NF).
De generelle krav til 2NF
- Fjern delmængder af data, der gælder for flere rækker af en tabel, og placer dem i separate tabeller.
- Opret forhold mellem disse nye tabeller og deres forgængere ved brug af fremmede nøgler.
Disse regler kan opsummeres i en simpel sætning: 2NF forsøger at reducere mængden af overflødige data i en tabel ved at udvinde den, placere den i nye tabeller og skabe relationer mellem disse tabeller.
Lad os se på et eksempel. Forestil dig en online butik, der opretholder kundeoplysninger i en database. De kan have et enkelt bord kaldet kunder med følgende elementer:
- CustNum
- Fornavn
- Efternavn
- Adresse
- by
- Stat
- ZIP
Et kort kig på denne tabel afslører en lille mængde overflødige data. Vi lagrer "Sea Cliff, NY 11579" og "Miami, FL 33157" poster to gange hver. Nu kan det ikke virke som for meget tilføjet opbevaring i vores enkle eksempel, men forestil dig det spildte rum, hvis vi havde tusindvis af rækker i vores bord. Hvis postnummeret til Sea Cliff skulle ændres, måtte vi også ændre på mange steder i hele databasen.
I en 2NF-kompatibel databasestruktur er denne overflødige information uddraget og opbevaret i et separat bord. Vores nye bord (lad os kalde det ZIPs) kan have følgende felter:
- ZIP
- by
- Stat
Hvis vi ønsker at være supereffektive, kan vi endda udfylde denne tabel på forhånd - postkontoret indeholder en liste over alle gyldige postnumre og deres by / statlige relationer. Du har sikkert set en situation, hvor denne type database blev brugt. En person, der tager en ordre, kan have bedt dig om din postnummer først og derefter kendte byen og oplyse, hvor du ringer fra. Denne type arrangement reducerer operatørfejl og øger effektiviteten.
Nu hvor vi har fjernet de duplikative data fra tabellen Kunder, har vi opfyldt den første regel for anden normal formular. Vi skal stadig bruge en fremmed nøgle til at knytte de to tabeller sammen. Vi bruger postnummeret (den primære nøgle fra ZIP-tabellen) for at oprette dette forhold. Her er vores nye kunder bord:
- CustNum
- Fornavn
- Efternavn
- Adresse
- ZIP
Vi har nu minimeret mængden af overflødige oplysninger, der er gemt i databasen, og vores struktur er i anden normal form.
