Boyce-Codd, fjerde og femte normale former

“Dette er del fire av serien, de fem normale formene. Boyce-Codd normal form er forkortet BCNF. Det er også kjent som 3.5nf. 3.5 er 3½. Det kommer etter den tredje normale formen. Den fjerde normale formen er forkortet 4NF og kommer etter Boyce-Codds normal form. Den femte normale formen er forkortet 5NF og kommer etter den fjerde normale formen.

Denne opplæringen (artikkel) er den fjerde delen av veiledningsserien, de fem normale formene. Denne opplæringen forklarer BCNF, 4NF og 5NF.

Denne opplæringen følger en historie som følger: en far har dødd. Han har lagt igjen litt penger til sønnen. Sønnen hans har bestemt seg for å bruke pengene til å åpne (starte) en nærbutikk. Comvenience Shop er allerede lager og har drevet i noen tid. Sønnen har noen ansatte, kalt Clerks, i denne opplæringsserien. Sønnen er innehaver. Før butikken gikk i drift, visste ikke både innehaver og funksjonærer de normale formene.

Du, leseren, har fullført denne fem normale formopplæringsserien og er også en databaseutvikler. Sønnen til den avdøde faren er din venn. Du har besøkt butikken hans de siste tre dagene. Den første dagen besøkte du dem; Du trente innehaveren og hans ansatte om hvordan du legger en databasetabell i 1NF. Den andre dagen trente du dem på hvordan du flytter et bord fra 1NF til 2NF. På den tredje dagen trente du dem på hvordan du flytter et bord fra 2NF til 3NF.

I dag, den fjerde dagen, besøkte du butikken for å trene bare innehaveren på BCNF, 4NF og 5NF på kontoret hans.”

Boyce-Codd normal form

BCNF-problemstilling oppstår når det er en sammensatt primærnøkkel og en ikke-primær nøkkelattributt (kolonne), og den ikke-primære nøkkelen avhenger funksjonelt av delen (e.g., en) av de primære nøkkelattributtene, mens tabellen allerede er i tredje normalform.

Dette innebærer at den ikke-prime (ikke-primære nøkkelen) kolonnen og prime-kolonnen er avhengig av form av en enhet og må fjernes som en egen tabell, der ikke-prime-kolonnen vil være den primære nøkkelen. Den andre delen av den sammensatte primære tasten vil danne en ny tabell med spalten som ikke er prime, og spalten som ikke er prime vil ikke nødvendigvis være en del av den primære nøkkelen. Den andre delen av den sammensatte primære nøkkelen er fortsatt en primærnøkkel. De relaterte mulige avhengige fra foreldrebordet følger med de to barnebordene på riktig måte.

Separasjonen av tabeller for Boyce-Codd normal form er egentlig ikke den samme som separasjonen av tabeller i 2NF og 3NF.

En tabell er i Boyce-Codd normal form hvis følgende regler blir overholdt:

1. Bordet skal allerede være i tredje normalform.
2. Ingen non-prime-attributt (kolonne) skal avhenge av den delen av den sammensatte primære nøkkelen.

Dette andre poenget, som sitert, er forenklet.

Eksempel

I forrige del av denne serien ble Saledetails -tabellen (med en viss modifisering) gitt som følger:

Saledetails (SaleID, produkt, Numbersold, UnitsellingPrice, rabatt)

En tilsvarende tabell med data er:

Enheten som selger pris er av type, float eller tall. Den primære nøkkelen i denne tabellen er en sammensatt nøkkel som består av SaleID og produkt.

Denne tabellen er i 3NF. Antall solgte produkter kan anses å avhenge av produktet og ikke av SaleID. Med andre ord, en ikke-prime-nøkkel kan bare avhenge av den delen av den sammensatte primære nøkkelen. Dette skal ikke skje; Og så fra disse tre kolonnene, kan følgende to tabeller føre til:

Mengde (tallold, produkt)

og

Saledetails (SaleID, Numbersold)

For tabellen, mengde, er den primære nøkkelen tallold. For det nye Saledetails -tabellen er den primære nøkkelen fremdeles SaleID.

Fra overordnet Saledetails -bordet er den eneste avhengige for Numbersold produktet. Fra foreldrene Saledetails -bordet er de avhengige for SaleId Numbersold, UnitsellingPrice, rabatt og uten produkt. Og så bør bordene faktisk være:

Mengde (tallold, produkt)

og

Saledetails (SaleID, Numbersold, Numbersold, UnitsellingPrice, Rabatt)

På dette tidspunktet kommer innehaveren følgende kommentar:

”Jeg tror ikke jeg noen gang vil ønske å vite mengden av et bestemt produkt som selges uten å ville vite SaleId, som avhenger av trioen (kjøper kunde, selger ansatt og datoen for transaksjonen).”Du, databaseutvikleren, svarer som følger:

“La oss i så fall tillate tabellen Saledetails og OrderDetails på 3NF. Tross alt går mange kommersielle databaser der ute ikke utover 3NF, og virksomhetene er komfortable. Imidlertid, når du vil vite at for et lignende bord, kan du bryte foreldrebordet i BCNF -tabeller.”

Fjerde normal form

1NF, 2NF, 3NF og BCNF er avhengige av funksjonell avhengighet. 4NF er avhengig av en spesiell type funksjonell avhengighet, som er ganske "urovekkende", spesielt om ikke godt forstått. Denne ganske urovekkende avhengigheten kalles multivalued avhengighet.

Funksjonell avhengighet kalles ganske enkelt avhengighet. Imidlertid kalles ikke flervurdert avhengighet ikke bare avhengighet, da det vil føre til forvirring. Det kalles multivalued avhengighet.

Du, databaseutvikleren forteller innehaveren følgende, “Det skal interessere deg for at for en tabell skal være i 1NF, må hver celle ha en enkelt verdi. Et noe lignende problem oppstår her, men med en tabell som allerede er i BCNF etter 3NF. Multivalued avhengighet er med den sammensatte primære nøkkelen, og hver celle i hele tabellen har allerede en enkelt verdi. I 1NF -utgaven trenger ikke flere verdier i en celle å bekymre seg for en nøkkel. Med 4NF -utgaven er det minst tre kolonner. Hvis det bare er tre kolonner, danner de tre kolonnene den primære komposittnøkkelen. I dette tilfellet kan den første kolonnen med celler bestemme den andre kolonnen med celler, men den andre kolonnen er uavhengig av den tredje kolonnen. 4NF tillater ikke dette.”

Med andre ord, problemet kan være at den andre kolonnen avhenger av den første kolonnen, og den tredje kolonnen avhenger fortsatt av den første kolonnen og har ingenting å gjøre når det gjelder avhengighet av den andre kolonnen. 4NF tillater ikke dette.

Før du fortsetter med forklaringen av multivalued avhengighet, bør hvordan spørsmålet om den fjerde normale formen kan oppstå først.

Hvordan utstedelse av 4NF kan oppstå med Convenience Shop

Se for deg at du etter en gang har hatt rivaler (andre nærbutikker) i nabolaget ditt, og du selger ikke så mye som du solgte før. Dette kunne ikke forutses da du startet nærbutikken.

Det forekommer deg at hvis du kan redusere prisene dine, ikke under kostprisen, selvfølgelig, for kundene dine som kjøper mest, så vil de kjøpe mer, og salget og fortjenesten din vil øke fra det nedlagte nivået. Dette betyr at du må vite hvor slike kunder forlater og adressene deres (gater), slik at du til og med kan levere produkter til husene deres. Igjen, dette problemet var ikke forutsett i begynnelsen.

Og så kommer du med følgende tabell, som du vil jobbe gjennom, opp til BCNF, før utstedelsen av 4NF kan vise seg selv:

Leveranse

For deg, innehaveren, er interessen din kategori av produktet, selve produktet som skal leveres, og adressen til å levere til. Ser vi på hele tabellen, bestemmer resten av radseksjonene fra CustomName til høyre ende de tre første kolonnene. Med andre ord, de tre første kolonnene danner den primære nøkkelen for resten av kolonnene. Det vil si at de tre første kolonnene avhenger av resten av kolonnene med rader. Og så må de tre første kolonneoverskriftene understrekes med enkeltlinjer. Med det er denne tabellen nå i sin første normale form. Hver kombinasjon av horisontale celler i de tre første kolonnene er unik.

Denne tabellen er også i den andre normale formen fordi hver kombinasjon av horisontale celler i de tre første kolonnene er unik, og det er ingen delvis avhengighet (med gjentatte grupper). Imidlertid er det ikke i den tredje normale formen fordi radseksjonene (deler) som begynner fra CustomName til høyre ende, bestemme CustomerId (CustomerId avhenger av dem). Så alt som må fjernes, og etterlater deg en kopi av CustomerID. CustomerID er nå både en fremmed nøkkel og en del av den primære nøkkelen. Bordet er nå i 3NF.

Før du, databaseutvikleren og treneren, kan fortsette, sier innehaveren: "I stedet for å jobbe med kategorikolonnen, produktkolonnen og adresse -kolonnen, vil jeg jobbe med kategorikolonnen, produktkolonnen og CustomerID -kolonnen, siden en gang CustomerId er Kjent, adressen kan være kjent, og det ville være mer praktisk, spesielt for datamaskinen.”

Svaret ditt, "Det er bra, innehaver. Du er på sporet. Det er det som vil bli gjort.”

Husk at kundebordet allerede eksisterer. Dette ble produsert i forrige del av denne opplæringsserien. Så det eneste bordet å produsere nå er et bord som bare har de tre primære nøklene.

Permutasjoner av kategori levering, etter produkt

Dessverre er ikke kolonnene i denne sammensatte primære nøkkelen i 2NF seg imellom. Det er repetisjoner av celleverdier som går nedover, med delvis avhengighet innen komposittnøkkelen. Disse repetisjonene er ikke så konstruktive som de ser ut til.

Legg merke til at konfekt er tilknyttet kunde 1, og det er også tilknyttet kunde 2. Brus er assosiert med kunde 1, og den er også assosiert med kunde 2.

Hvis kunden 1 har bedt om søtsaker i dag, vil han be om sjokolade i morgen (ikke vist i bordet). Konfekt er assosiert med kunde 1 gjennom søtsaker på bordet, men det kan også knyttes til kunde 1 gjennom sjokolade i leveranser i morgen. Hvis kunden 1 har bedt om Sprite i dag, vil han be om Coca-Cola i morgen. Brus er assosiert med kunde 1 til og med sprite, i tabellen, men det kan også være assosiert med kunde 1 til Coca-Cola. Det samme leveringsproblemet oppstår med kunden 2. Denne typen repetisjon kalles multivalued avhengighet.

Legg merke til at i tabellen ovenfor har ikke produktkolonnen repetisjon (i det minste foreløpig).

For å løse dette problemet er det best å først legge disse repetisjonene av kolonneverdiene, til den primære nøkkelen, i den første normale formen for å resultere i følgende:

Komplett kategori levering permutasjoner etter produkt

Permutasjon betyr å endre rekkefølgen på en ordning. I denne situasjonen betyr det å gi alle de forskjellige mulige bestillinger av produkter i produktkolonnen. Nå er det flere repetisjoner (mer redundans) i denne tabellen enn i ovennevnte. Den gode nyheten er at disse tre kolonnene nå er i orden, i første normal form. 2NF og 3NF må sees for disse tre kolonnene.

Husk at levering ikke var forutsett helt i begynnelsen da butikken startet (gikk i drift). Hvis det hadde vært forutsett, ville den aller første transaksjonstabellen i den første delen av denne opplæringsserien vært slik:

Legg merke til at multi-verdiene i hver celle i denne produktkolonnen har flere faktorer tatt i betraktning enn det som skjedde i den aller første transaksjonstabellen i den første delen av serien. Å bringe denne tabellen inn i første normale form ville resultere i den forrige tabellen, som er skrevet ut her, for enkel referanse til leseren, med noen modifikasjoner i produktkolonnen:

De to først-normale formene er de samme fordi permutasjonen i produktkolonnen er relativt til CustomerID-kolonnen. Ikke glem at hver CustomerID her identifiserer en rad i kundetabellen.

Definisjonen av multivalued avhengighet betyr at hvis det er tre kolonner, henholdsvis x, y og z, og for en bestemt rad med verdier x, y og z, betyr en multivalure avhengighet x ->> y, at hvis vi velger noen x faktisk forekommer i tabellen (ring dette valget x_c), og kompilere en liste over alle x_cYZ -kombinasjoner som kan oppstå i tabellen, som gjort ovenfor, vil vi finne at x_c er assosiert med de samme y -oppføringene, uavhengig av z. Så i hovedsak gir tilstedeværelsen av Z ingen nyttig informasjon for å begrense de mulige verdiene til y.

I tabellen ovenfor, x_c, For eksempel er konfekt, og en tilsvarende y -verdi er søtsaker. Kombinasjonen av konfekt og søtsaker har ingenting å gjøre med CustomerID -kolonnen, der verdien kanskje 1 eller 2 i radene. Hvis x tas som brus, vil en tilsvarende y -verdi være sprite. Kombinasjonen av brus og sprite har ingenting å gjøre med CustomerID -kolonnene, der verdien kanskje 1 eller 2 i radene.

Sett fra en annen normal form og funksjonell avhengighetspunkter, er kategorikolonnen avhengig av produktkolonnen og avhenger også av CustomerID -kolonnen, men avhenger ikke av begge kolonnene når de kombineres. Verdiene i produktkolonnen gjentar, og bestemmer verdiene i kategorikolonnen; og verdiene i CustomerID -kolonnen gjentar, og bestemme verdiene i kategorikolonnen; Men begge disse kolonnene sammen bestemmer ikke verdiene i kategorikolonnen.

Så tabellen må deles i to, med kategorien og produktkolonnene som går en vei og kategorien og CustomerID -kolonnene som går den andre veien, som følger:

Kategori- produkttabell

Kategori - Kundebord

Disse to barnebordene er nå i 1NF, 2NF, 3NF, BCNF og viktigst av alt, 4NF. Tabellen for kategori-produkt har sammensatte primærnøkler. Kategorikustomertabellen har også sammensatte primærnøkler. Hver av kolonnetastene er enten allerede en primærnøkkel i en annen tabell i databasen, eller det er en fremmed nøkkel i en annen tabell i samme database.

Disse to tabellene som erstatter overordnede tabellen, er ikke de eneste tabellene i hele databasen. De er faktisk relatert til andre tabeller i databasen. Så det er fremdeles noe husholdningsarbeid i databasedesignprosjektet som skal gjøres angående hele databasen og disse to nye tabellene.

Husk at det allerede er en produkttabell i 4NF og en kategoritabell i 4NF i databasen, med henvisning til kategoriprodukttabellen, og husk at det allerede er en produkttabell i 4NF og en kategoritabell i 4NF. For at en tabell skal være i normal form, bør det ikke bryte noen av de normale formens regler. Produktene eller produkttabellen har ProductID som sin primære nøkkel og kategori eller kategori som en utenlandsk nøkkel.

Så kategori-produkttabellen produsert her, i 4NF, bør forlates siden de følgende to tabellene, som er i 4NF, har all informasjon (og mer):

Kategorier (kategorier, kategorienavn, beskrivelse)
Produkter (ProductID, CategoryID, leverandørid, produktnavn, UnitPrice, QuantityInstock, ReorderLevel)

På den annen side kan ikke kategori-kunde-tabellen i 4NF forlates, ettersom det kommer med noen nye forhold ved levering. Faktisk bør tabellen kalles bedre, kategori levering. Å kalle det produktutlevering vil være misvisende for databaseprogrammerere, men ville ikke være villedende for kundene, som er analfabeter i databasen. Så kall det kategori levering. I tabellnotasjonsskjema er det:

Kategori levering (kategori, CustomerId)

Husk at hver CustomerId refererer til en rad i kundens tabell. Den sammensatte primære nøkkelen er: kategori, CustomerID. Siden det allerede er en kategorier -tabell med kategorier, bør denne tabellen faktisk være:

Kategori levering (kategoriid, customerid, kategori)

Hvor kategorier er avhengig av kategori (navn) og omvendt.

Så spørsmålet om levering bringer inn et ekstra bord i 4NF. Resten av tabellene i databasen er allerede i 4NF, da de ikke bryter 4NF -reglene som er angitt nedenfor.

Leveringsproblemet ble ikke forutsett før normalisering i de forskjellige klassene startet, i begynnelsen. Hvis det hadde blitt forutsett som indikert ovenfor, ville kategorien levering kommet; ved eller før den tredje normale formstadiet uten noen omtale av 4NF.

Fjerde normal formregler

En tabell er i 4NF hvis den ikke bryter følgende regler:

1. Det er allerede i Boyce-Codd normal form.
2. Tabellen har ingen multi-verdsatt avhengighet.

Dette betyr at et bord kan utformes første gang, og at det allerede er i 4NF.

Femte normal form

5NF -situasjoner oppstår sjelden, men når de oppstår, må den femte normale form tas i betraktning for å unngå noe kjent regnskapsproblem. Den femte normale formen er også kjent som projeksjonen med normal form. Med den femte normale formen er det minst tre kolonner. Hvis det bare er tre kolonner av interesse, er det en sammensatt primærnøkkel, som består av de tre kolonnene.

Se for deg at du, innehaveren, har hatt opptil to nærbutikker i samme by og blir levert av det samme settet med leverandører. Ring disse butikkene, Shop1 og Shop2. Leverandørene ser disse to forskjellige butikkene som to forskjellige kunder. Så her har kunden en annen betydning. Det betyr å handle og ikke personen. Betydningen av produktet forblir det samme.

Så det er et bord med primærnøklene: leverandør, produkt og kunde. Det er:

Tabell (leverandør, produkt, kunde)

5NF -utgaven dukker opp når en gitt leverandør kan levere et gitt produkt til mer enn en kunde (de to butikkene). En gitt kunde kan også motta et gitt produkt fra mer enn en leverandør. Og en gitt kunde kan motta fra forskjellige leverandører forskjellige produkter. Det vil si at en av de tre partnerne kan gjøre de samme tingene med de to andre partnerne.

Det vil si at en leverandør kan tilsvare mer enn en kunde. Én kunde kan samsvare med mer enn ett produkt. Og ett produkt kan tilsvare mer enn en leverandør. Dette betyr at de følgende tre binærebordene kan resultere:

Leverandør-kundebord
Kundeproduktbord
Produkt-leverandørbord

Hvis en overordnet bord kan deles opp i tre mindre tabeller uten tap eller tillegg av informasjon, og hvis tabellene er sammenføyd tilbake, er det fremdeles ikke noe tap eller tillegg av informasjon, så skal overordnede tabellen brytes ned. De mindre bordene er i 5NF. I så fall er sammenføyning av avhengighet eliminert. Tap av informasjon betyr å miste radforhold, og tillegg av informasjon betyr å legge til nye radforhold.

Hvis dette brytes sammen og å sette sammen igjen vil føre til tap eller tillegg av informasjon, bør ikke tabellen brytes ned. I så fall er foreldrebordet allerede i den femte normale form.

På dette tidspunktet sier du, databaseutvikleren og treneren, “Innehaver, jeg legger igjen data som legger ut data (foreldrebord og tre små tabeller) som en øvelse for deg. Jeg vil sjekke det i morgen.”

Femte normale skjemaregler

En tabell er i 5NF hvis den ikke bryter følgende regler:

1. Det er allerede i fjerde normale form.
2. Tabellen har ikke sammenføyningsavhengighet.

Dette betyr at et bord kan utformes første gang, og at det allerede er i 5NF.

Konklusjon

En tabell er i Boyce-Codd normal form hvis følgende regler blir overholdt:

1. Bordet skal allerede være i tredje normalform.
2. Ingen non-prime-attributt (kolonne) skal avhenge av den delen av den sammensatte primære nøkkelen.

En tabell er i 4NF hvis den ikke bryter følgende regler:

1. Det er allerede i Boyce-Codd normal form.
2. Tabellen har ingen multi-verdsatt avhengighet.

En tabell er i 5NF hvis den ikke bryter følgende regler:

1. Det er allerede i fjerde normale form.
2. Tabellen har ikke sammenføyningsavhengighet.

Innehaveren sier nå: “Dette krever en stor feiring for oss begge.”

Du, databaseutvikleren, svarer: "Hvorfor venter vi ikke til i morgen når jeg skal sette sammen alle tabellene og forbedre produktene?”

Innehaveren reagerer ved å smile, “Hva ville jeg gjort uten deg?”

Du, databaseutvikleren, legger til, smiler: “Vi sees i morgen da, på kontoret ditt.”Og la være.