Vi har tittat på flera aspekter av att normalisera en databas tabell. Först diskuterade vi de grundläggande principerna för databas normalisering. Förra gången undersökte vi de grundläggande kraven som fastställdes av den första normala formen (1NF). Låt oss fortsätta vår resa och täcka principerna för den andra normala formen (2NF).
De allmänna kraven för 2NF
- Ta bort delmängder av data som gäller för flera rader av ett bord och placera dem i separata tabeller.
- Skapa relationer mellan dessa nya tabeller och deras föregångare genom att använda främmande nycklar.
Dessa regler kan sammanfattas i ett enkelt uttalande: 2NF försöker minska antalet överflödiga data i en tabell genom att extrahera den, placera den i nya tabeller och skapa relationer mellan dessa tabeller.
Låt oss titta på ett exempel. Tänk dig en nätbutik som behåller kundinformation i en databas. De kan ha ett enda bord som heter kunder med följande element:
- CustNum
- Förnamn
- Efternamn
- Adress
- Stad
- stat
- blixtlås
En kort titt på denna tabell visar en liten mängd överflödiga data. Vi lagrar "Sea Cliff, NY 11579" och "Miami, FL 33157" poster två gånger vardera. Nu verkar det inte som för mycket lagring i vårt enkla exempel, men föreställ dig bortkastat utrymme om vi hade tusentals rader i vårt bord. Dessutom, om postkoden för Sea Cliff skulle ändras, skulle vi behöva göra den förändringen på många ställen i hela databasen.
I en 2NF-kompatibel databasstruktur extraheras och redigeras denna redundanta information i ett separat bord. Vårt nya bord (låt oss kalla det ZIPs) kan ha följande fält:
- blixtlås
- Stad
- stat
Om vi vill vara supereffektiva kan vi till och med fylla i tabellen i förväg - postkontoret ger en katalog över alla giltiga postnummer och deras stad / statliga relationer. Visst har du stött på en situation där denna typ av databas utnyttjades. Någon som tar order kan ha frågat dig för din postnummer först och visste sedan staden och staten du ringer från. Denna typ av arrangemang minskar operatörsfel och ökar effektiviteten.
Nu när vi har tagit bort duplikatdata från tabellen Kunder har vi uppfyllt den första regeln i andra normala formuläret. Vi behöver fortfarande använda en främmande nyckel för att knyta de två borden tillsammans. Vi använder ZIP-koden (den primära nyckeln från ZIP-tabellen) för att skapa det förhållandet. Här är vårt nya kunderbord:
- CustNum
- Förnamn
- Efternamn
- Adress
- blixtlås
Vi har nu minimerat antalet redundanta uppgifter som lagras i databasen och vår struktur är i andra normala form.
