Forutsetning: Første normalform , Andre normalform , Tredje normalform
Anvendelse av de generelle definisjonene av 2NF og 3NF kan identifisere ytterligere redundans forårsaket av avhengigheter som bryter med en eller flere kandidatnøkler. Til tross for disse ekstra begrensningene, kan det fortsatt eksistere avhengigheter som vil føre til at redundans er tilstede i 3NF-relasjoner. Denne svakheten i 3NF resulterte i presentasjonen av en sterkere normal form kalt de Boyce-Codd normal form (Codd, 1974) .
Selv om 3NF er en tilstrekkelig normalform for relasjonsdatabaser, kan det hende at denne (3NF) normalformen ikke fjerner 100 % redundans på grunn av X−>Y funksjonell avhengighet hvis X ikke er en kandidatnøkkel for den gitte relasjonen. Dette kan løses med Boyce-Codd Normal Form (BCNF).
Boyce-Codd normal form (BCNF)
Boyce–Codd Normal Form (BCNF) er basert på funksjonelle avhengigheter som tar hensyn til alle kandidatnøkler i en relasjon; BCNF har imidlertid også ytterligere begrensninger sammenlignet med den generelle definisjonen av 3NF.
Regler for BCNF
Regel 1: Tabellen skal være i 3. Normalform.
Regel 2: X skal være en supernøkkel for hver funksjonell avhengighet (FD) X−>Y i en gitt relasjon.
Merk: For å teste om en relasjon er i BCNF, identifiserer vi alle determinantene og sørger for at de er kandidatnøkler.
BCNF i DBMS
Du kom over et lignende hierarki kjent som Chomsky normal form i teorien om beregning. Studer nå hierarkiet ovenfor nøye. Det kan utledes at hver relasjon i BCNF er også i 3NF . For å si det på en annen måte, en relasjon i 3NF trenger ikke være i BCNF. Tenk over denne uttalelsen en stund.
For å bestemme den høyeste normalformen av en gitt relasjon R med funksjonelle avhengigheter, er det første trinnet å sjekke om BCNF-betingelsen holder. Hvis R er funnet å være i BCNF, kan det trygt utledes at relasjonen også er i 3NF , 2NF, og 1NF som hierarkiet viser. 1NF har den minst restriktive begrensningen - den krever bare en relasjon R for å ha atomverdier i hver tuppel. 2NF har en litt mer restriktiv begrensning.
3NF har en mer restriktiv begrensning enn de to første normale formene, men er mindre restriktiv enn BCNF. På denne måten øker begrensningen når vi går nedover hierarkiet.
Eksempler
Her skal vi diskutere noen grunnleggende eksempler som lar deg forstå egenskapene til BCNF. Vi vil diskutere flere eksempler her.
Eksempel 1
La oss vurdere studentdatabasen, der data om studenten er nevnt.
This_ID | Denne_grenen | Stu_Course | Avdelingsnummer | Stu_Course_No |
---|---|---|---|---|
101 | Informatikk og ingeniørfag | DBMS | B_001 | 201 |
101 | Informatikk og ingeniørfag | Datanettverk | B_001 | 202 |
102 | Elektronikk og kommunikasjonsteknikk | VLSI-teknologi | B_003 | 401 |
102 | Elektronikk og kommunikasjonsteknikk | Mobil kommunikasjon | B_003 | 402 |
Funksjonell avhengighet av ovenstående er som nevnt:
Stu_ID −>Stu_Branch Stu_Course −> {Branch_Number, Stu_Course_No}>
Kandidatnøkler i tabellen ovenfor er: {This_ID, This_Course}
Hvorfor er ikke denne tabellen i BCNF?
Tabellen ovenfor er ikke i BCNF, fordi som vi kan se at verken Stu_ID eller Stu_Course er en supernøkkel. Ettersom reglene nevnt ovenfor tydelig forteller at for at en tabell skal være i BCNF, må den følge egenskapen at for funksjonell avhengighet X−>Y, må X være i Super Key og her feiler denne egenskapen, det er derfor denne tabellen ikke er i BCNF .
Hvordan tilfredsstille BCNF?
For å tilfredsstille denne tabellen i BCNF, må vi dekomponere den i ytterligere tabeller. Her er hele prosedyren som vi forvandler denne tabellen til BCNF. La oss først dele denne hovedtabellen i to tabeller Denne_grenen og Stu_Course Bord.
Stu_Branch Table
This_ID | Denne_grenen |
---|---|
101 | Informatikk og ingeniørfag |
102 | Elektronikk og kommunikasjonsteknikk |
Kandidatnøkkel for denne tabellen: This_ID .
typescript datotype
Stu_Course Tabell
Stu_Course | Avdelingsnummer | Stu_Course_No |
---|---|---|
DBMS | B_001 | 201 |
Datanettverk | B_001 | 202 |
VLSI-teknologi | B_003 | 401 |
Mobil kommunikasjon | B_003 | 402 |
Kandidatnøkkel for denne tabellen: Stu_Course .
Stu_ID til Stu_Course_No Table
This_ID | Stu_Course_No |
---|---|
101 | 201 |
101 | 202 |
102 | 401 |
102 | 402 |
Kandidatnøkkel for denne tabellen: {Stu_ID, Stu_Course_No}.
Etter å ha dekomponert i ytterligere tabeller, er det nå i BCNF, ettersom det passerer betingelsen til Super Key, at i funksjonell avhengighet X−>Y, er X en Supernøkkel.
Eksempel 2
Finn den høyeste normalformen av en relasjon R(A, B, C, D, E) med FD satt som:
{ BC->D, AC->BE, B->E }>
Forklaring:
- Trinn 1: Som vi kan se, (AC)+ ={A, C, B, E, D}, men ingen av undergruppene kan bestemme alle attributtene til relasjonen, så AC vil være kandidatnøkkelen. A eller C kan ikke utledes fra noen andre attributter i relasjonen, så det vil bare være 1 kandidatnøkkel {AC}.
- Steg 2: Primære attributter er de attributtene som er en del av kandidatnøkkelen {A, C} i dette eksemplet, og andre vil være ikke-prime {B, D, E} i dette eksemplet.
- Trinn-3: Relasjonen R er i 1. normal form ettersom et relasjonelt DBMS ikke tillater flerverdier eller sammensatte attributter.
Relasjonen er i 2. normalform fordi BC->D er i 2. normalform (BC er ikke en riktig delmengde av kandidatnøkkel AC) og AC->BE er i 2. normalform (AC er kandidatnøkkel) og B->E er i 2. normalform (B er ikke en riktig delmengde av kandidatnøkkel AC).
Forholdet er ikke i 3. normalform fordi i BC->D (verken BC er en supernøkkel eller D er et primattributt) og i B->E (verken B er en supernøkkel eller E er en primattributt), men for å tilfredsstille 3. normal for , enten LHS til en FD skal være supernøkkel eller RHS skal være et hovedattributt. Så den høyeste normalformen for relasjon vil være den andre normalformen.
Merk: Et hovedattributt kan ikke være transitivt avhengig av en nøkkel i BCNF-relasjonen.
Vurder disse funksjonelle avhengighetene til en eller annen relasjon R
AB ->C C ->B AB ->B>
Anta at det er kjent at den eneste kandidatnøkkelen til R er AB. En nøye observasjon er nødvendig for å konkludere med at den ovennevnte avhengigheten er en transitiv avhengighet ettersom hovedattributtet B transitivt avhenger av nøkkelen AB til C. Nå er den første og den tredje FD i BCNF da de begge inneholder kandidatnøkkelen (eller ganske enkelt KEY) på venstre side. Den andre avhengigheten er imidlertid ikke i BCNF, men er definitivt i 3NF på grunn av tilstedeværelsen av hovedattributtet på høyre side. Så den høyeste normale formen for R er 3NF ettersom alle tre FDene tilfredsstiller de nødvendige betingelsene for å være i 3NF.
Eksempel 3
Tenk for eksempel på relasjon R(A, B, C)
A ->BC, B -> A>
A og B er begge supernøkler, så relasjonen ovenfor er i BCNF.
Merk: BCNF-dekomponering kan alltid ikke være mulig med tapsfri sammenføyningstilstand. For eksempel, relasjon R (V, W, X, Y, Z), med funksjonelle avhengigheter:
V, W ->X Y, Z -> X W -> Y>
Det ville ikke tilfredsstille avhengighet ved å bevare BCNF-nedbrytning.
Merk: Redundanser er noen ganger fortsatt til stede i et BCNF-forhold, da det ikke alltid er mulig å eliminere dem fullstendig.
Det er også noen høyere ordens normalformer, som den fjerde normalformen og den femte normalformen.
For mer, se 4. og 5. normalskjema.