Redigerer Boyce–Codd normalform (avsnitt)

== Oppnåbarhet av BCNF ==
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.<ref name="Beeri">Beeri, Catriel and Bernstein, Philip A. "Computational problems related to the design of normal form relational schemas". ''ACM Transactions on Database Systems'' 4(1), March 1979, p. 50.</ref>

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

{| class="wikitable"
|+Nærmeste butikker
! Person
! Butikktype
! Nærmeste butikk
|-
| Davidsen
| Optiker
| Ørneøye
|-
| Davidsen
| Frisør
| Snippets
|-
| Wold
| Bokhandel
| Merlin bøker
|-
| Fredriksen
| Bakeri
| Deigen
|-
| Fredriksen
| Frisør
| Frisyr
|-
| Fredriksen
| Optiker
| Ørneøye
|}

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:

{| style="border-spacing:2em 0; margin-left:-2em"
| style="vertical-align:top" |
{| class="wikitable"
|+ Butikk nær person
! Person
! Butikk
|-
| Davidsen
| Ørneøye
|-
| Davidsen
| Snippets
|-
| Wold
| Merlin bøker
|-
| Fredriksen
| Deigen
|-
| Fredriksen
| Frisyr
|-
| Fredriksen
| Ørneøye
|}
| style="vertical-align:top" |
{| class="wikitable"
|+ Butikk
! Butikk
! Butikktype
|-
| Ørneøye
| Optiker
|-
| Snippets
| Frisør
|-
| Merlin bøker
| Bokhandel
|-
| Deigen
| Bakeri
|-
| Frisyr
| Frisø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).<ref name="Zaniolo">Zaniolo, Carlo. "A New Normal Form for the Design of Relational Database Schemata". ''ACM Transactions on Database Systems'' 7(3), September 1982, p. 493.</ref> Dette designet består av den originale "Nærmeste butikker"-tabellen supplert med "Butikk"-tabellen beskrevet ovenfor. Tabellstrukturen generert av Bernsteins skjemagenereringsalgoritme<ref name="Bernstein">Bernstein, P. A. "Synthesizing Third Normal Form relations from functional dependencies". ''ACM Transactions on Database Systems'' 1(4), December 1976 pp. 277–298.</ref> er faktisk EKNF, selv om den forbedringen av 3NF ikke hadde blitt gjenkjent på det tidspunktet algoritmen ble designet:

{| style="border-spacing:2em 0; margin-left:-2em"
| style="vertical-align:top" |
{| class="wikitable"
|+ Nærmeste butikker
! Person
! Butikktype
! Nærmeste butikk
|-
| Davidsen
| Optiker
| Ørneøye
|-
| Davidsen
| Frisør
| Snippets
|-
| Wold
| Bokhandel
| Merlin bøker
|-
| Fredriksen
| Bakeri
| Deigen
|-
| Fredriksen
| Frisør
| Frisyr
|-
| Fredriksen
| Optiker
| Ørneøye
|}
| style="vertical-align:top" |
{| class="wikitable" style="float:left;"
|+ Butikk
! Butikk
! Butikktype
|-
| Ørneøye
| Optiker
|-
| Snippets
| Frisør
|-
| Merlin bøker
| Bokhandel
|-
| Deigen
| Bakeri
|-
| Frisyr
| Frisør
|}
|}
Hvis en [[Referanseintegritet|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.