Database normalisering: Anden Normalform
Anden normalform forkortes, på samme måde som den første, bare med et 2-tal i stedet for. Nemlig 2. NF.
Definition: En relation R er på anden normalform, hvis den er på første normalform, og hvis enhver ikke-nøgle-attribut er fuldt funktionelt afhængig af enhver kandidatnøgle i R.
– Første normalform SKAL være opfyldt.
– Ingen attributter der ikke selv tilhører nøglen, må afhænge af en del af nøglen (Det opstår tit hvis man har en primær nøgle som er sammensat af to eller flere felter).
Hvis vi ser på tabellen UDLAAN nedenfor, kan vi se flere ting som ikke stemmer overens med anden normalform. Der er også ting som bare direkte er upraktiske.
UDLAAN:
laanerId | bogId | Forfatter | Titel | Forlag | dato |
101 | 1 | Klaus R | Heste | Dyreforlag | 1/1 – 08 |
101 | 2 | Bente F | Grise | Dyreforlag | 1/1 – 08 |
101 | 4 | Jørgen P | Både | Skibsforlag | 1/1 – 08 |
201 | 3 | Bente F | Får | Dyreforlag | 2/1 – 08 |
– Primær nøglen består af en sammensætning af ’laanerId’ og ’bogId’
– Oplysninger om en bog afhænger kun af ’bogId’ og derved kun en del af nøglen. Dette kaldes også for funktionel afhængighed.
– Data om bogen blandes sammen med data om udlånet.
– En låner kan låne samme bog flere gange på én dag.
Derfor gør vi som ved første normalform, og deler relationen (læs. tabellen) op i to:
UDLAAN:
udlaansId | laanerId | bogId | dato |
1 | 101 | 1 | 1/1 – 08 |
2 | 101 | 2 | 1/1 – 08 |
3 | 101 | 4 | 1/1 – 08 |
4 | 201 | 3 | 2/1 – 08 |
BOGTABEL:
bogId | Forfatter | Titel | Forlag |
1 | Klaus R | Heste | Dyreforlag |
2 | Bente F | Grise | Dyreforlag |
3 | Bente F | Får | Dyreforlag |
4 | Jørgen P | Både | Skibsforlag |
Nu har vi fået to nye og forbedrede tabeller.
For det første har vi adskilt data om bøgerne og data om udlånet.
Dernæst har vi også fået delt primærnøglen op, så vi ikke længere har en sammensat nøgle.
Det kan ses i BOGTABEL, hvor de forskellige oplysninger om en given bog, nu består af hele nøglen (bogId).
Læg også mærke til at jeg har lavet en ny primær nøgle i UDLAAN i stedet for ‘laanerId’. Jeg har oprettet ‘udlaansId’, så hvert udlån får sit eget id. Jeg har dog stadig beholdt ‘laanerId’ i UDLAAN, da vi skal kunne identificere hvilken låner der er registreret til et givent udlån.
Så vidt at jeg har forstået, så er det vigtigt
BlueBoden | 17. oktober 2008 | 03:53Så vidt at jeg har forstået, så er det vigtigt at have et unikt id som vi kan bruge i vores select statements, hvis bruger-id er et unikt nummer ville dette være en oplagt mulighed.
Men i andre tilfælde har man ikke noget konkredt at gå efter, derfor ville det ofte være bedst at lave en id nøgle/kolonne, med et primært index og muligvis auto-increment.
Det er også vigtigt vi har indexer på de nøgler vi bruger mest i vores selects. Eks i tilfældet med et biblotek ville det være en god ide at have et index på de mest relevante kolonner, “BogID” skulle helst være unikt, det samme med “lånerId” hvilket også helst skulle være unikt til den enkelte bruger, og begge bør have et primært index.
Andre kolonner som. Eks “postnummer” ville jeg give et unikt index. Men det afhænger mere af den ønskede funktionalitet.
Der er iøvrigt en anden fordel, som måske er vigtigere for større tabeller. Idet du opdeler en tabel, vil du også nedsætte antallet af concurrent-request på den enkelte tabel, det betyder at inserts, updates og andet kan blive udført hurtigere.
Velkommen BlueBoden :) Det er nemlig en rigtig god ide at
Kim Andersen | 17. oktober 2008 | 11:48Velkommen BlueBoden 🙂
Det er nemlig en rigtig god ide at have en eller anden form for id til hver kolonne efter min mening, så man nemt kan få fat i hver enkelt række.
Er også enig i dine andre betragtninger, tak for din kommentar 😀
[...] Læs om 2. normalform her. [...]
Normalisering af en database: Første Normalform | 4. januar 2010 | 21:59[…] Læs om 2. normalform her. […]