Predpogoj: Prva normalna oblika , Druga normalna oblika , Tretja normalna oblika

Uporaba splošnih definicij 2NF in 3NF lahko identificira dodatno redundanco, ki jo povzročajo odvisnosti, ki kršijo enega ali več kandidatnih ključev. Kljub tem dodatnim omejitvam pa lahko še vedno obstajajo odvisnosti, ki bodo povzročile odvečnost v odnosih 3NF. Ta slabost v 3NF je povzročila predstavitev močnejše normalne oblike, imenovane the Boyce-Codd normalna oblika (Codd, 1974) .

Čeprav je 3NF ustrezna normalna oblika za relacijske baze podatkov, vseeno ta (3NF) normalna oblika morda ne bo odstranila 100-odstotne redundance zaradi funkcionalne odvisnosti X−>Y, če X ni kandidatni ključ dane relacije. To je mogoče rešiti z Boyce-Coddovo normalno obliko (BCNF).

Boyce-Codd normalna oblika (BCNF)

Boyce–Codd normalna oblika (BCNF) temelji na funkcionalnih odvisnostih, ki upoštevajo vse kandidatne ključe v relaciji; vendar ima BCNF tudi dodatne omejitve v primerjavi s splošno definicijo 3NF.

Pravila za BCNF

1. pravilo: Tabela mora biti v 3. normalni obliki.

2. pravilo: X bi moral biti nadključ za vsako funkcionalno odvisnost (FD) X−>Y v dani relaciji.

Opomba: Za preizkus, ali je relacija v BCNF, identificiramo vse determinante in se prepričamo, da so kandidatni ključi.

BCNF v DBMS

Naleteli ste na podobno hierarhijo, znano kot Normalna oblika Chomskega v teoriji računanja. Zdaj natančno preučite zgornjo hierarhijo. Lahko se sklepa, da vsaka relacija v BCNF je tudi v 3NF . Povedano drugače, ni nujno, da je relacija v 3NF v BCNF. Nekaj ​​časa premislite o tej izjavi.

Za določitev najvišje normalne oblike dane relacije R s funkcionalnimi odvisnostmi je prvi korak preveriti, ali pogoj BCNF drži. Če se ugotovi, da je R v BCNF, je mogoče varno sklepati, da je razmerje tudi v 3NF , 2NF, in 1NF kot kaže hierarhija. 1NF ima najmanj omejevalno omejitev – zahteva le, da ima relacija R atomske vrednosti v vsaki torki. 2NF ima nekoliko bolj restriktivno omejitev.

3NF ima bolj restriktivno omejitev kot prvi dve normalni obliki, vendar je manj restriktivna kot BCNF. Na ta način se omejitev povečuje, ko gremo po hierarhiji navzdol.

Primeri

Tukaj bomo obravnavali nekaj osnovnih primerov, ki vam bodo pomagali razumeti lastnosti BCNF. Tukaj bomo razpravljali o več primerih.

Primer 1

Oglejmo si podatkovno bazo študentov, v kateri so navedeni podatki o študentu.

Funkcionalna odvisnost zgoraj navedenega je, kot je navedeno:

Stu_ID −>Stu_Branch Stu_Course −> {Branch_Number, Stu_Course_No}>

Ključi kandidatov zgornje tabele so: {This_ID, This_Course}

Zakaj te tabele ni v BCNF?

Zgornja tabela ni v BCNF, ker kot lahko vidimo, niti Stu_ID niti Stu_Course nista Super Key. Ker zgoraj omenjena pravila jasno povedo, da je tabela v BCNF, mora slediti lastnosti, da mora biti za funkcionalno odvisnost X−>Y, X v Super Key in tukaj ta lastnost ne uspe, zato ta tabela ni v BCNF .

Kako zadovoljiti BCNF?

Da bi zadovoljili to tabelo v BCNF, jo moramo razstaviti na nadaljnje tabele. Tukaj je celoten postopek, s katerim to tabelo pretvorimo v BCNF. Najprej razdelimo to glavno tabelo na dve tabeli Ta veja in Stu_Course Tabela.

Stu_Branch Tabela

Ključ kandidata za to tabelo: Ta_ID .

java veljavni identifikatorji

Stu_Course Table

Ključ kandidata za to tabelo: Stu_Course .

Stu_ID do Stu_Course_No Table

Ključ kandidata za to tabelo: {Stu_ID, Stu_Course_No}.

Po razgradnji v nadaljnje tabele je zdaj v BCNF, saj posreduje pogoj super ključa, da je v funkcionalni odvisnosti X−>Y X Super ključ.

Primer 2

Poiščite najvišjo normalno obliko relacije R(A, B, C, D, E) s FD, nastavljenim kot:

{ BC->D, AC->BE, B->E }>

Pojasnilo:

• Korak 1: Kot lahko vidimo, je (AC)+ = {A, C, B, E, D}, vendar nobena od njegovih podmnožic ne more določiti vseh atributov relacije, zato bo AC kandidatni ključ. A ali C ni mogoče izpeljati iz nobenega drugega atributa relacije, zato bo na voljo samo 1 kandidatni ključ {AC}.
• 2. korak: Praatributi so tisti atributi, ki so del kandidatnega ključa {A, C} v tem primeru, drugi pa bodo v tem primeru neprimarni {B, D, E}.
• 3. korak: Relacija R je v 1. normalni obliki, saj relacijski DBMS ne dovoljuje večvrednostnih ali sestavljenih atributov.

Relacija je v 2. normalni obliki, ker je BC->D v 2. normalni obliki (BC ni ustrezna podmnožica kandidatnega ključa AC) in je AC->BE v 2. normalni obliki (AC je kandidatni ključ) in B->E je v 2. normalni obliki (B ni pravilna podmnožica kandidatnega ključa AC).

Razmerje je ne v 3. normalni obliki, ker v BC->D (niti BC ni superključ niti D ni primarni atribut) in v B->E (niti B ni super ključ niti E ni primarni atribut), ampak za izpolnitev 3. normale za , naj bo LHS FD super ključ ali RHS glavni atribut. Torej bo najvišja normalna oblika relacije 2. normalna oblika.

Opomba: Primarni atribut ne more biti tranzitivno odvisen od ključa v relaciji BCNF.

Razmislite o teh funkcionalnih odvisnostih neke relacije R

AB ->C C ->B AB ->B>

Recimo, da je znano, da je edini kandidat za ključ R AB. Natančno opazovanje je potrebno za zaključek, da je zgornja odvisnost prehodna odvisnost, saj je glavni atribut B prehodno odvisen od ključa AB do C. Zdaj sta prvi in ​​tretji FD v BCNF, saj oba vsebujeta kandidatni ključ (ali preprosto KEY) na njihovi levi strani. Druga odvisnost pa ni v BCNF, ampak je vsekakor v 3NF zaradi prisotnosti glavnega atributa na desni strani. Torej je najvišja normalna oblika R 3NF, saj vse tri FD izpolnjujejo potrebne pogoje, da so v 3NF.

Primer 3

Na primer upoštevajte razmerje R(A, B, C)

A ->BC, B -> A>>

A in B sta super ključa, zato je zgornja relacija v BCNF.

Opomba: Razgradnja BCNF morda vedno ni mogoča s pogojem združevanja brez izgub. Na primer relacija R (V, W, X, Y, Z), s funkcionalnimi odvisnostmi:

V, W ->X Y, Z -> X W -> Y>>

Ne bi zadovoljil razgradnje BCNF, ki ohranja odvisnost.

Opomba: Redundance so včasih še vedno prisotne v razmerju BCNF, saj jih ni vedno mogoče popolnoma odpraviti.

Obstaja tudi nekaj normalnih oblik višjega reda, kot sta 4. normalna oblika in 5. normalna oblika.

Za več glejte 4. in 5. normalno obliko.