logo

Boyce-Codd normale vorm (BCNF)

Voorwaarde: Eerste normaalvorm , Tweede normaalvorm , Derde normaalvorm

Toepassing van de algemene definities van 2NF en 3NF kan extra redundantie identificeren die wordt veroorzaakt door afhankelijkheden die een of meer kandidaatsleutels schenden. Ondanks deze extra beperkingen kunnen er echter nog steeds afhankelijkheden bestaan ​​die ervoor zorgen dat er redundantie aanwezig is in 3NF-relaties. Deze zwakte in 3NF resulteerde in de presentatie van een sterkere normale vorm, genaamd de Boyce-Codd normale vorm (Codd, 1974) .



Hoewel 3NF een adequate normale vorm is voor relationele databases, verwijdert deze (3NF) normale vorm mogelijk niet 100% redundantie vanwege X->Y functionele afhankelijkheid als X geen kandidaatsleutel is van de gegeven relatie. Dit kan worden opgelost door Boyce-Codd Normal Form (BCNF).

Boyce-Codd normale vorm (BCNF)

Boyce-Codd Normal Form (BCNF) is gebaseerd op functionele afhankelijkheden die rekening houden met alle kandidaatsleutels in een relatie; BCNF heeft echter ook aanvullende beperkingen vergeleken met de algemene definitie van 3NF.

Regels voor BCNF

Regel 1: De tabel moet de derde normaalvorm hebben.



Regel 2: X zou een supersleutel moeten zijn voor elke functionele afhankelijkheid (FD) X−>Y in een gegeven relatie.

Opmerking: Om te testen of een relatie in BCNF ligt, identificeren we alle determinanten en zorgen we ervoor dat het kandidaat-sleutels zijn.

BCNF in DBMS



Je kwam een ​​soortgelijke hiërarchie tegen die bekend staat als de Chomsky-normale vorm in de rekentheorie. Bestudeer nu zorgvuldig de bovenstaande hiërarchie. Dat kan worden afgeleid elke relatie in BCNF is ook in 3NF . Anders gezegd: een relatie in 3NF hoeft niet in BCNF te zijn. Denk een tijdje na over deze uitspraak.

Om de hoogste normaalvorm van een gegeven relatie R met functionele afhankelijkheden te bepalen, is de eerste stap het controleren of de BCNF-voorwaarde geldt. Als blijkt dat R in BCNF ligt, kan veilig worden afgeleid dat de relatie ook in zit 3NF , 2NF, En 1NF zoals de hiërarchie laat zien. De 1NF heeft de minst beperkende beperking: er is alleen een relatie R nodig om atomaire waarden in elk tupel te hebben. De 2NF heeft een iets restrictievere beperking.

De 3NF heeft een restrictievere beperking dan de eerste twee normale vormen, maar is minder restrictief dan de BCNF. Op deze manier neemt de beperking toe naarmate we verder in de hiërarchie komen.

Voorbeelden

Hier gaan we enkele basisvoorbeelden bespreken waarmee u de eigenschappen van BCNF kunt begrijpen. We zullen hier meerdere voorbeelden bespreken.

voorbeeld 1

Laten we eens kijken naar de studentendatabase, waarin gegevens van de student worden vermeld.

Deze_ID Deze_tak Stu_Cursus Filiaalnummer Stu_Cursus_nr
101 Computerwetenschappen en techniek DBMS B_001 201
101 Computerwetenschappen en techniek Computer netwerken B_001 202
102 Elektronica en communicatietechniek VLSI-technologie B_003 401
102 Elektronica en communicatietechniek Mobiele communicatie B_003 402

De functionele afhankelijkheid van het bovenstaande is zoals vermeld:

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

Kandidaatsleutels van de bovenstaande tabel zijn: {Deze_ID, deze_cursus}

Waarom staat deze tabel niet in BCNF?

De bovenstaande tabel is niet in BCNF, omdat zoals we kunnen zien noch Stu_ID noch Stu_Course een Super Key is. Zoals de hierboven genoemde regels duidelijk aangeven dat een tabel, wil deze in BCNF staan, de eigenschap moet volgen dat voor functionele afhankelijkheid X−>Y, X in Super Key moet staan ​​en hier faalt deze eigenschap. Daarom is deze tabel niet in BCNF .

Hoe voldoet u aan BCNF?

Om aan deze tabel in BCNF te voldoen, moeten we deze in verdere tabellen opsplitsen. Hier is de volledige procedure waarmee we deze tabel omzetten in BCNF. Laten we deze hoofdtabel eerst in twee tabellen verdelen Deze_tak En Stu_Cursus Tafel.

Stu_Branch-tabel

Deze_ID Deze_tak
101 Computerwetenschappen en techniek
102 Elektronica en communicatietechniek

Kandidaatsleutel voor deze tabel: Deze_ID .

kat timpf gewicht

Stu_Cursustabel

Stu_Cursus Filiaalnummer Stu_Cursus_nr
DBMS B_001 201
Computer netwerken B_001 202
VLSI-technologie B_003 401
Mobiele communicatie B_003 402

Kandidaatsleutel voor deze tabel: Stu_Cursus .

Stu_ID naar Stu_Course_No tabel

Deze_ID Stu_Cursus_nr
101 201
101 202
102 401
102 402

Kandidaatsleutel voor deze tabel: {Stu_ID, Stu_Cursusnr.}.

Na te zijn ontbonden in verdere tabellen, is het nu in BCNF, omdat het de voorwaarde van Super Key doorgeeft, dat X in functionele afhankelijkheid X−>Y een Supersleutel.

Voorbeeld 2

Vind de hoogste normaalvorm van een relatie R(A, B, C, D, E) met FD ingesteld als:

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

Uitleg:

  • Stap 1: Zoals we kunnen zien, kan (AC)+ ={A, C, B, E, D} maar geen van de subsets ervan alle attributen van de relatie bepalen. AC zal dus de kandidaatsleutel zijn. A of C kan niet worden afgeleid van enig ander attribuut van de relatie, dus er zal slechts 1 kandidaatsleutel {AC} zijn.
  • Stap 2: Prime-attributen zijn die attributen die in dit voorbeeld deel uitmaken van kandidaatsleutel {A, C} en andere zullen in dit voorbeeld niet-prime {B, D, E} zijn.
  • Stap 3: De relatie R heeft de eerste normale vorm, aangezien een relationeel DBMS geen meerwaardige of samengestelde attributen toestaat.

De relatie heeft de 2e normaalvorm omdat BC->D de 2e normaalvorm heeft (BC is geen juiste subset van kandidaatsleutel AC) en AC->BE is de 2e normaalvorm (AC is kandidaatsleutel) en B->E bevindt zich in de 2e normaalvorm (B is geen juiste subset van kandidaatsleutel AC).

De relatie is niet in de 3e normaalvorm omdat in BC->D (noch BC is een supersleutel, noch D een hoofdkenmerk) en in B->E (noch B is een supersleutel, noch E een hoofdkenmerk) maar om te voldoen aan de 3e normaal voor , moet de LHS van een FD supersleutel zijn, of moet RHS een hoofdattribuut zijn. De hoogste normale relatievorm zal dus de 2e Normaalvorm zijn.

Opmerking: Een hoofdattribuut kan niet transitief afhankelijk zijn van een sleutel in de BCNF-relatie.

Beschouw deze functionele afhankelijkheden van een relatie R

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

Stel dat het bekend is dat de enige kandidaatsleutel van R AB is. Een zorgvuldige observatie is nodig om te concluderen dat de bovenstaande afhankelijkheid een transitieve afhankelijkheid is, aangezien het hoofdkenmerk B transitief afhankelijk is van de sleutel AB tot en met C. Nu bevinden de eerste en de derde FD zich in BCNF omdat ze beide de kandidaatsleutel bevatten (of eenvoudigweg SLEUTEL) aan hun linkerkant. De tweede afhankelijkheid bevindt zich echter niet in BCNF, maar zeker in 3NF vanwege de aanwezigheid van het primaire attribuut aan de rechterkant. De hoogste normale vorm van R is dus 3NF, aangezien alle drie de FD's voldoen aan de noodzakelijke voorwaarden om in 3NF te zijn.

Voorbeeld 3

Beschouw bijvoorbeeld de relatie R(A, B, C)

A ->BC, B -> A>

A en B zijn beide supersleutels, dus de bovenstaande relatie is in BCNF.

Opmerking: BCNF-ontleding is mogelijk altijd niet mogelijk met de voorwaarde voor verliesloze join. Bijvoorbeeld relatie R (V, W, X, Y, Z), met functionele afhankelijkheden:

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

Het zou niet voldoen aan de afhankelijkheid als de BCNF-ontbinding behouden blijft.

Opmerking: In een BCNF-relatie zijn soms nog redundanties aanwezig, omdat het niet altijd mogelijk is deze volledig te elimineren.

Er zijn ook enkele normaalvormen van hogere orde, zoals de 4e normaalvorm en de 5e normaalvorm.

Raadpleeg voor meer informatie de 4e en 5e normaalvorm.