Boyce–Codd normalform

I 1970 ga Edgar Frank Codd ut den velkjente artikkelen A Relational Model of Data for Large Shared Databanks. Dette var første gang ideen om en relasjonsdatabase ble publisert. Alt arbeid etter dette, inkludert Boyce–Codd normalformen, er basert på denne relasjonsmodellen.

Boyce–Codd normalformen ble først beskrevet i 1971 av Ian Heath, og formen har derfor også blitt kalt Heath normalform av Chris Date.^[2][1]

BCNF ble utviklet i 1974 av Raymond Francis Boyce og Edgar Frank Codd for å håndtere visse typer anomalier som ikke håndteres av tredje normalform.^[3]

Hvis et relasjonsskjema er i BCNF er all redundans basert på funksjonell avhengighet fjernet,^[4] selv om det fortsatt kan eksistere andre typer redundans. Et relasjonsskjema R er på Boyce-Codd normalform hvis og bare hvis minst én av følgende betingelser gjelder for hver av dens avhengigheter X → Y:^[5]

• X → Y er en triviell funksjonell avhengighet (Y ⊆ X),
• X er en supernøkkel for skjema R.^[5]

Merk at hvis et relasjonsskjema tilfredstiller BCNF så tilfredstiller det også 3NF.

Bare i sjeldne tilfeller oppfyller ikke 3NF-tabeller kravene til BCNF. En 3NF-tabell som ikke har flere overlappende kandidatnøkler er garantert på BCNF.^[6] Avhengig av hva dens funksjonelle avhengigheter er kan en 3NF-tabell med to eller flere overlappende kandidatnøkler være på BCNF eller ikke.

Et eksempel på en 3NF-tabell som ikke oppfyller BCNF er:

• Hver rad i tabellen representerer en bestilling på en tennisbane. Denne tennisklubben har én hardbane (bane 1) og én gressbane (bane 2).
• En bestilling er definert av banenummer og perioden den er reservert for.
• I tillegg er hver bestilling tilknyttet en prisklasse. Det er fire forskjellige prisklasser:
  • STANDARD, for bane 1-bestillinger gjort av ikke-medlemmer
  • SPARE, for bane 1-bestillinger gjort av medlemmer
  • PREMIUM-B, for bane 2-bestillinger gjort av ikke-medlemmer
  • PREMIUM-A, for bane 2-bestillinger gjort av medlemmer

Tabellens supernøkler er:

• S₁ = {Bane, starttid}
• S₂ = {Bane, sluttid}
• S₃ = {Prisklasse, starttid}
• S₄ = {Prisklasse, sluttid}
• S₅ = {Bane, starttid, sluttid}
• S₆ = {Prisklasse, starttid, sluttid}
• S₇ = {Bane, prisklasse, starttid}
• S₈ = {Bane, prisklasse, sluttid}
• S_T = {Bane, prisklasse, starttid, sluttid}, den trivielle supernøkkelen

Merk at selv om attributtene for starttid og sluttid i tabellen ovenfor ikke har noen dupliserte verdier for hver av dem, må vi likevel innrømme at det på noen dager kan være to forskjellige bookinger på bane 1 og bane 2 som starter samtidig eller slutter samtidig. Dette er grunnen til at {Starttid} og {Sluttid} ikke kan betraktes som tabellens supernøkler.

Imidlertid er bare S₁, S₂, S₃ og S₄ kandidatnøkler (det vil si minimale supernøkler for relasjonen) fordi f.eks. S₁ ⊂ S₅, så S₅ kan ikke være en kandidatnøkkel.

Ettersom at 2NF forbyr partielle funksjonelle avhengigheter av ikke-primære attributter (altså et attributt som ikke forekommer i noen kandidatnøkkel) og at 3NF forbyr transitive funksjonelle avhengigheter av ikke-primære attributter på kandidatnøkler.

I tabellen Dagens tennisbane-bestillinger er det ingen ikke-primære attributter, det vil si at alle attributter tilhører en eller annen kandidatnøkkel. Derfor overholder tabellen både 2NF og 3NF.

Tabellen overholder imidlertid ikke BCNF på grunn av avhengigheten Prisklasse → Banenummer hvor det bestemmende attributtet Prisklasse – som Banenummer avhenger av – (1) verken er en kandidatnøkkel eller en overmengde av en kandidatnøkkel og (2) Banenummer er ingen delmengde av Prisklasse.

Avhengigheten Prisklasse → Banenummer respekteres her, siden en prisklasse kun skal gjelde for en enkelt bane.

Designet kan endres slik at det oppfyller BCNF:

Kandidatnøklene for tabellen Prisklasse er {Prisklasse} og {Banenummer, Medlemsflagg}. Kandidatnøklene for tabellen Dagens bestillinger er {Banenummer, starttid} og {Banenummer, sluttid}. Begge tabellene er på BCNF. Når {Prisklasse} er en nøkkel i satstypetabellen, er det umulig å ha én satstype assosiert med to forskjellige banenummer, så ved å bruke {Prisklasse} som en nøkkel i prisklasse-tabellen har anomalien som påvirket den opprinnelige tabellen blitt eliminert.

I noen tilfeller er det umulig å dekomponere en ikke-BCNF-tabell til tabeller som tilfredsstiller BCNF og samtidig bevarer avhengighetene som holdt i den opprinnelige tabellen. Beeri og Bernstein viste i 1979 for eksempel at en mengde med funksjonelle avhengigheter {AB → C, C → B} ikke kan representeres av et BCNF-skjema.^[7]

Anta følgende ikke-BCNF-tabell hvis funksjonelle avhengigheter følger {AB → C, C → B}-mønsteret:

For hver kombinasjon av person/butikktype gir tabellen hvilken butikk av denne typen som er geografisk nærmest personens hjem. Vi antar for enkelhets skyld at en enkelt butikk ikke kan være av mer enn én type.

Tabellens kandidatnøkler er:

• {Person, butikktype},
• {Person, nærmeste butikk}.

Fordi alle tre attributtene er primære attributter (det vil si tilhører kandidatnøkler) er tabellen på 3NF. Tabellen er imidlertid ikke på BCNF siden butikktype-attributten er funksjonelt avhengig av ikke-supernøkkelen nærmeste butikk.

Brudd på BCNF betyr at tabellen er gjenstand for uregelmessigheter. For eksempel kan Ørneøye få butikktypen endret til "optometrist" på Fredriksen-raden, mens butikktypen "optiker" beholdes på Davidsen-raden. Dette ville innebære motstridende svar på spørsmålet: "Hva er Ørneøye sin butikktype?" Å holde hver butikks butikktype bare én gang virker å foretrekke, da dette vil forhindre at slike uregelmessigheter oppstår:

I dette reviderte designet har tabellen "Butikk nær person" kandidatnøkkelen {Person, butikk}, og "Butikk"-tabellen har kandidatnøkkelen {Butikk}. Selv om dette designet tilfredsstiller BCNF er denne løsningen dessverre uakseptabel av andre årsaker: Den lar oss registrere flere butikker av samme type mot samme person. Med andre ord garanterer ikke kandidatnøklene at funksjonsavhengigheten {Person, butikktype} → {Butikk} vil bli respektert.

Et design som eliminerer alle disse anomaliene (men ikke samsvarer med BCNF) er mulig. Dette designet introduserer en ny normalform kjent som elementærnøkkel normalform (EKNF).^[8] Dette designet består av den originale "Nærmeste butikker"-tabellen supplert med "Butikk"-tabellen beskrevet ovenfor. Tabellstrukturen generert av Bernsteins skjemagenereringsalgoritme^[9] er faktisk EKNF, selv om den forbedringen av 3NF ikke hadde blitt gjenkjent på det tidspunktet algoritmen ble designet:

Hvis en referanseintegritets-begrensning er definert slik at {Butikktype, nærmeste butikk} fra den første tabellen må referere til en {Butikktype, Butikk} fra den andre tabellen så forhindres dataavvikene beskrevet tidligere.

Gitt et databaseskjema på tredje normalform er det NP-komplett å avgjøre om det bryter med Boyce–Codd normalform.^[10]

Hvis en relasjon R ikke er i BCNF på grunn av en funksjonell avhengighet X→Y så kan man dekompone R til BCNF ved å erstatte relasjonen med to underrelasjoner:

1. En med attributtene X⁺,
2. og en annen med attributtene R-X⁺+X. Merk at R representerer alle attributtene i den opprinnelige relasjonen.

Detetter må det sjekkes om begge underrelasjonene er i BCNF, og prosessen gjentas rekursivt med enhver underrelasjon som ikke er i BCNF.^[11]