10 Yderligere normalisering: 1NF, 2NF, 3NF, BCNF
Se også den ekstra udleverede note om normalisering, som dækker 1. til 3. NF.
10.1 Introduktion
Relationer i en relationel database er altid normaliserede, eftersom de udelukkende indeholder skalare værdier. Selv om en relation er normaliseret kan den sagtens indeholde visse uønskede egenskaber. Principperne om yderligere normalisering tillader os at genkende sådanne situationer, og viser hvordan man kan reducere de pågældende relationer til en mere acceptabel form. [289]
Normalformer
En relation siges at være på en bestemt normalform, hvis den opfylder visse foreskrevne betingelser. F.eks. siger man at relationen er på første normalform (1NF) hvis den udelukkende indeholder skalare værdier. [289]
Den såkaldte normaliseringsprocedure er den proces, hvorigennem man konverterer en relation fra en given normalform (f.eks. 2NF) til en mere acceptabel form (f.eks. 3NF). Man kan karakterisere denne procedure som den successive reduktion af en given samling relationer til en mere ønskværdig form. Proceduren er reversibel, hvilket vil sige, at det altid er muligt at genskabe den oprindelige form. Denne egenskab er vigtig, fordi den betyder, at ingen informationer går tabt i processen. [290]
10.2 Dekomposition uden tab af informationer og funktionel afhængighed
Reversibilitet betyder, at den originale relation er lig med en join af den projektioner. [293]
Mere om funktionel afhængighed
Funktionelle afhængigheder, som ikke kan reduceres på venstre side, og afhængigheder, der ikke kan reduceres vil vise sig at blive vigtige i forbindelse med definitionen af anden og tredie normalform. [294]
I et diagram, der viser funktionelle afhængigheder, vil der pr. definition altid udgå pile fra enhver kandidatnøgle, fordi for en given værdi af kandidatnøglen vil der altid være en værdi for alt andet. Problemerne opstår, hvis der er andre pile end dem, der udgår fra kandidatnøglerne. [295]
Funktionelle afhængigheder må betegnes som en semantisk notation. At finde de funktionelle afhængigheder er en del af den proces, der fører til en forståelse af, hvad dataene betyder. [295]
10.3 Første, anden og tredie normalform
Tredie normalform (meget uformel definition): En relation er i 3NF hvis alle de attributter, der ikke indgår i nøgler er indbyrdes uafhængige og afhængige af primærnøglen, som ikke kan reduceres yderligere. [296]
Første normalform: En relation er i 1NF hvis alle underliggende domæner udelukkende indeholder skalare værdier. [296]
Redundans i en relation medfører en række uregelmæssigheder i forbindelse med opdateringsoperationerne INSERT, DELETE og UPDATE. [Eksempler på side 298]
Anden normalform: En relation er i 2NF hvis den er i 1NF og alle attributter, der ikke indgår i primærnøglen er afhængige af denne primærnøgle, som ikke kan reduceres yderligere. [300]
Når de funktionelle afhængigheder A -> B og B -> C begge gælder, er det en logisk konsekvens, at den transitive (indirekte) afhængighed A - > C også gælder. Transitiv afhængighed fører til problemer i forbindelse med opdateringsoperationerne. [Eksempler på side 301]
Tredie normalform: En relation er i 3NF hvis den er i 2NF, og alle attributter, der ikke indgår i primærnøglen, ikke er transitivt afhængige af primærnøglen. At der ikke er transitiv afhængighed udelukker gensidig afhængighed. [302]
En given relations normaliseringsniveau er et spørgsmål om semantik, og ikke blot et spørgsmål om de dataværdier, som tilfældigvis optræder i relationen på et givet tidspunkt. [303]
10.5 Boyce/Codd normalform
Codd\'s oprindelige definition af 3NF kunne ikke håndtere alle generelle tilfælde på en tilfreddstillende måde. Der opstår problemer, når en relation
har to eller flere kandidatnøgler,
når de to kandidatnøgler er sammensatte og
når de overlapper hinanden (har mindst én fælles attribut). [306]
Boyce/Codd normalform: En relation er i BCNF hvis enhver ikke-triviel funktionel afhængighed har en kandidatnøgle som sin determinant.
Boyce/Codd normalform (mere uformelt): En relation er i BCNF hvis alle determinanter er kandidatnøgler. [306]
Det første eksempel (S {S#, SNAME, STATUS, CITY}) viser en relation med to ikke-overlappende kandidatnøgler (og falder altså uden for ovenstående afgrænsning). Relationen er i BCNF, fordi den funktionelle afhængighed viser, at alle determinanter er kandidatnøgler. [307]
Det andet eksempel (SSP {S#, SNAME, P#, QTY}) viser en relation med to sammensatte og overlappende kandidatnøgler. Relationen er ikke i BCNF, fordi der udover de to sammensatte overlappende kandidatnøgler er to andre determinanter i relationen, idet de to attributter S# og SNAME determinerer hinanden. Relationen indeholder redundans, som giver tilsvarende opdateringsproblemer, som man oplever med relationer i 1NF og 2NF. Løsningen består i at dele relationen i to, hvilket kan gøres på to forskellige lige rigtige måder. [308]
Tredie eksempel (Student subJect Teacher) beskriver også en situation med to sammensatte og overlappende kandidatnøgler. Der gælder desuden følgende betingelser: For hvert emne bliver hver elev undervist af samme lærer, hver lærer underviser kun i et emne og et emne kan have flere lærere. Der er to kandidatnøgler: {S, J} og {S, T}. Herudover er T determinant for J. Relationen er i 3NF; men ikke i BCNF. Følgen bliver opdateringsproblemer. Problemet løses ved at opsplitte den oprindelige relation i to BCNF projektioner: ST(S, T) og TJ(T, J). Desværre opstår der herved et problem, som skyldes den funktionelle afhængighed T -> J. Denne FD er kun indeholdt i tabellen TJ, og følgen er, at de to tabeller ikke kan opdateres uafhængigt af hinanden. [309 - 311]
Fjerde eksempel (EXAM {S, J, P}) beskriver igen en situation med to sammensatte og overlappende kandidatnøgler. Der gælder i øvrigt følgende betingelse: Der er ikke to studerende, som kan opnå samme resultat. Kandidatnøglerne er {S, J} og {J, P}. Relationen er i BCNF, fordi der ikke er andre determinanter end kandidatnøglerne. [311]
taget fra :
http://www.uv.tietgen.dk/edb/laerer/bjla/date1000.htm
Ny bruger
Nybegynder
Opret
Preview
