Andre normale form de fem normale formene

Denne opplæringen forklarer den andre normale skjemaet, relatert til relasjonsdatabase. Det er den andre delen av serien: de fem normale formene. Forklaringen på disse fem normale formene følger en historielinje, som starter som følger: En far døde og etterlot litt penger for sønnen. Sønnen bestemte seg for å bruke pengene til å åpne en nærbutikk. Sønnen ansatte noen få arbeidere (funksjonærer). Alt i butikken er allerede lager, og personalet begynte å selge til noen kunder. I starten av butikken til butikken, som ikke er lenge siden, visste sønnen, som er innehaver og hans arbeidere, ingenting om de normale formene.

Du er allerede en venn av sønnen, innehaveren. Du har endelig fullført denne opplæringsserien på normale skjemaer, du vet alt om normale former, og du har blitt en databaseutvikler. Du besøkte vennens butikk i går, og du la merke til at de bare hadde et transaksjonstabell, som ikke overholdt den første normale skjemaet. Du lærte da både innehaver og hans funksjonærer om hvordan du produserer transaksjonstabellen i første normale form. De forsto og bordet de nå har i den første normale formen er:

Dette er transaksjonstabellen. Det er en kolonne for den primære nøkkelen, som er transid (auto-increment).

Siden enhver første normal form kan ha sårbarheter, besøkte du dem (butikken) i dag for å trene dem på den andre normale form for å redusere sårbarhetene.

Før du begynner å gjøre noe, spurte innehaveren:

“Er ikke dette nåværende transaksjonstabellen for stor?

Jeg har hørt at selskapene som ikke bruker datamaskiner registrerer dataene sine i forskjellige hovedbøker.

Jeg tror denne transaksjonstabellen faktisk består av to mindre transaksjonstabeller, som kan ha nye navn på salgstabell og ordre tabell.”

Du svarer mens du smiler:

“Ja, den nåværende transaksjonstabellen er for stor.”

Du fortsatte med å gratulere ham for å være positivt nysgjerrig, spesielt angående virksomheten hans. Du er enig i tankene hans. Du fortsetter for å si at det faktisk er tre hovedbord der: salgstabellen, ordrebordet og produkttabellen. Når salgs- og ordredabellene blir identifisert, vil de erstatte transaksjonstabellen. Salgstabellen og ordrebordet er mindre transaksjoner (halverte) tabeller i seg selv. Produkttabellen er helt klart en enhet. Det må skaffes fra forrige store transaksjonstabell.

Imidlertid vil disse tre tabellene hentet fra det forrige store bordet fortsatt være i første normale form. Den andre normale formen adresserer repetisjonsproblemet (redundans), og det er ikke det som skal skje her.

Merk: Den andre normale formen kan ikke ta opp alle repetisjon (redundans) problemer.

Du, databaseutvikleren og en venn til innehaveren, fortsetter å produsere de tre tabellene med deres deltakelse som følger:

Hovedenhetene

De viktigste enhetene er de tre hovedtabellene som er nevnt tidligere. I forrige kolonne, med overskriften, har handlingen enten salg eller bestilling. Salg betyr at produktet i den raden ble solgt til en kunde. Bestilling betyr at produktet i den raden ble bestilt fra en leverandør. En nærbutikk må bestille produkter før du selger dem.

Kolonnene som tilsvarer de tre tabellene er som følger:

Salg (SaleID, produkt, kunde, ansatt, SellingPrice)

Bestilling (OrderID, produkt, leverandør, ansatt, kostnadsprise)

Produkter (produktid, produkt, kategori)

Hver tabellnotasjon har en understreket primærnøkkel. Hver av disse tabellene er fremdeles i første normale form. Og så er hvert nøkkelnummer relatert direkte til radverdiene.

I salgstabellen er Saleids ikke kopier av transidene. I bestillingsbordet er ordrenene heller ikke kopier av transidene. Hver av SaleID- og OrderId-kolonnen er auto-increment, fra 1. Transaksjonstabellen og dens rad -ID -er er ikke lenger viktig siden all informasjonen i transaksjonstabellen nå er i disse tre tabellene. Sale- og OrderID -kolonnene erstatter transaksjonstabellen, men ikke ved å kopiere. Salgstabellen har ikke leverandørkolonnen, og ordrebordet har ikke kundekolonnen, som var sammen i transaksjonstabellen. Ingen av tabellene har også handlingskolonnen siden salg og bestilling nå er atskilt, og de to salgsverdiene og ordren er ikke lenger nødvendig.

Kategori -kolonnen, som var i transaksjonskolonnen, er verken i salgstabellen eller i ordrebordet. Det er i produkttabellen. Dette er fordi kategoriverdien i hver rad bare er relatert til produktverdien og ikke til den andre cellen i raden. Kategorikolonnen må gå ut av transaksjonstabellen sammen med produktkolonnen for å skaffe produkttabellen. Denne begrunnelsen har noe å gjøre med transitiv avhengighet i produksjonen av den tredje normale formen som vil bli diskutert i neste opplæring.

Produkttabellen hentet fra forrige transaksjonstabell er:

Produktbord

Merk at denne tabellen ikke har noen repetisjon av produktnavnet (nedover) som kan ha vært i transaksjonstabellen. Dessuten er hver produktverdi til stede, og hver kategoriverdi er også til stede.

Denne tabellen er fremdeles i 1NF. Avhengigheten for verdiene til en rad er bare relatert til den primære nøkkelen, så langt. Verdiene i kategorikolonnen gjentas når kolonnen er avstammet. Konfekt gjentar to ganger. “Brus” gjentar seg fire ganger. "Meieriprodukt" gjentar seg tre ganger. Gjentakelse er overflødig og forårsaker regnskapsproblemer. Å sette et bord i 2NF betyr å fjerne mange repetisjoner. Denne fjerningen av repetisjoner gjøres ikke vilkårlig.

Salgstabellen hentet fra forrige transaksjonstabell er:

Salgstabell

Fire nye rader er lagt til, og det har vært en viss endring for å gjøre forklaringen bedre. En datakolonne introduseres av samme grunn. Nå er det 15 rader i denne salgstabellen i stedet for 11 for transaksjonstabellen.

Forretningsregler

Hva er et salg? Hvis den samme ansatte selger til en bestemt kunde på samme dato minst ett produkt, er det ett salg. Selv på samme dag (dato), hvis en kunde kommer to ganger og blir betjent av to forskjellige ansatte, er det to salg. Hvis en kunde kommer to ganger på samme dag og blir servert av samme ansatt, selv om de to settene med produkter er forskjellige, danner begge kommens ett salg. I ett salg kan en kunde kjøpe ett eller flere produkter. Med andre ord, i ett salg, må trioen (kunde, ansatt og dato) være den samme. Når en av disse trioverdiene endres, er det et annet salg. Ulike salg identifiseres av forskjellige SaleID -er i forrige tabell. Og så gjentar Saleids. Ulike kolonneverdier gjentas i kolonnene sine.

I det første salget som har to rader og samme Saleid, kjøpte John Smith, en kunde, en søtsaker og en sprite fra Jacob Jones på samme dato.

Om morgenen 09/06/22 kom James Taylor, en kunde, og kjøpte to yoghurt og en Coca-Cola. Det er ett salg. Det tar tre rader i bordet med samme SaleID.

Samme dag, men på ettermiddagen, kom den samme James Taylor og kjøpte Pepsi, men fra en annen ansatt som er Peter Lewis. Trioen har nå en endring med en annen ansatt. Og så, dette er et annet salg forårsaket av en endring i en av trioen. Siden dette er et annet salg, har det en annen rad i tabellen med et annet SaleID.

Den 09/08/22 kom Susan Wright, en kunde, og kjøpte to ost og en melk fra Mary Baker. Det er ett salg fordi trioen forblir det samme (i de tre radene). Imidlertid tar det tre rader i tabellen. Siden trioen forblir den samme, forblir Saleid også den samme.

Resten av radene nedover i tabellen har ikke samme SaleId -repetisjon. Denne tabellen er fremdeles i 1NF. Avhengigheten så langt for verdiene på en rad er fremdeles bare relatert til den primære nøkkelen til den raden. Hver kolonne har gjentatte verdier. Gjentakelsen i en kolonne må ikke nødvendigvis være i påfølgende celler som kommer ned.

Se når du skal vurdere prisen eller SellingPrice -kolonnen i opplæringsdelen av håndtering av repetisjoner. Å sette et bord i 2NF løser problemet med vanlige sett repetisjoner (redundans) på tvers av rader.

Bestillingsbordet hentet fra forrige transaksjonstabell er:

Bestill bord

Denne tabellen er fremdeles i den første normale formen. Det er mulighet for enhver verdi i en hvilken som helst kolonne å gjenta under kolonnen. Disse repetisjonene er adressert i denne opplæringen for å ha den andre normale formen på tabellen.

På dette tidspunktet var du, databaseutvikleren, enig i forslag fra personalet om å sette transaksjonstabellen i mindre tabeller. Og du legger transaksjonstabellen i mindre tabeller (enheter) på en praktisk måte. Personalet, inkludert deres innehaver, mener nå at de også har potensial til å forstå de normale formene helt og er villige til å lære mer fordi forslaget deres har materialisert seg.

Imidlertid insisterer du, databaseutvikleren til dem at den opprinnelige transaksjonstabellen ikke lenger eksisterer og er erstattet av de tre mindre tabellene. Salget og ordrebordet erstatter i hovedsak transaksjonstabellen. Transid (transaksjons -ID) er ikke lenger relevant. Det erstattes av SaleID og OrderID i to forskjellige tabeller.

De viktigste enhetene som nå er mindre tabeller over den opprinnelige transaksjonstabellen er: Produkttabellen, salgstabellen og ordrebordet. Du, databaseutvikleren, fortsetter å forklare og insisterer på at disse nye, men mindre tabellene fremdeles er i første normale form. Å erstatte en tabell med hovedtabell. Du, databaseutvikleren, fortsetter å sette de tre tabellene i den andre normale formen som følger:

Håndtering av repetisjoner

Produktbordet

I produkttabellen gjentar verdiene til kategorikolonnen. Alle navnene (verdiene) på kategorikolonnen må fjernes fra produkttabellen inn i en kategoritabell der det ikke ville være noen eller begrensede repetisjoner. Kategoriene -tabellen blir:

Kategorier tabell

Kategoriene -tabellen har ikke lenger noe element som "brus" som gjentar. Denne tabellen er kortere vertikalt enn plasseringen i forrige produkttabell.

Enhver tabell trenger en primærnøkkel. Så langt består kategoriene tabellen av en kolonne der alle verdiene er unike og det ikke er noen tom celle- eller nullverdi. Denne kolonnen kan være den primære nøkkelkolonnen for kategoritabellen. Imidlertid kan det være bedre å ha en primærnøkkel for auto-increment. Følgende modifiserte kategorier tabell viser dette:

Kategorier Tabell - 2NF

Dette er den endelige kategorien tabellen. Det er nå i 1NF og 2NF. Hva med det originale produkttabellen? Det må opprettes et nytt produktbord. I den nye tabellen vil ethvert kategorinavn i den originale tabellen bli erstattet av den tilsvarende IDen i kategoritabellen. Så produkttabellen blir:

Produkter Tabell - 2NF

Kategori -kolonnen erstattes av kategorien CategoryID. Informasjonen for kategoriverdiene er fremdeles der i produkttabellen som kategorier. Kategorikolonnen er plassert like etter ProductID -kolonnen i stedet for etter produktkolonnen for bedre presentasjon. Denne tabellen er ikke kortere enn det originale produkttabellen, men den har fortsatt en fordel.

“Hva er den primære nøkkelen til produkttabellen?”Spurt av en av funksjonærene. Merk at i hver rad er ProductID og CategoryID begge avhengig av verdien av produktnavnet (verdi). Hvis enten ProductID eller CategoryId endres for en hvilken som helst rad, vil den nye kombinasjonen av ProductID og CategoryId peke på et annet produktnavn (verdi). Med andre ord, et produktnavn (verdi) på rad er relatert til både ProductID og CategoryID for den raden. På grunn av denne avhengigheten (funksjonell avhengighet) av ProductID og CategoryId -kombinasjonen på et bestemt produktnavn (verdi), danner både ProductID og CategoryId den primære nøkkelen.

Når en nøkkel er en kombinasjon av mer enn en kolonne, kalles nøkkelen en sammensatt nøkkel. Tabellnotasjonen for dette nye produkttabellen er:

Produkter (ProductID, CategoryID, Produkt)

Forholdet mellom ProductID og CategoryID er mange-til-en.

Hvert kolonnenavn for den primære tasten (sammensatt nøkkel denne gangen) er understreket. CategoryID -verdiene i produktene og kategorienId -verdiene i kategoriene tabellen gir de nøyaktige korrespondansene mellom de to tabellene.

Tabellnotasjonen for kategoritabellen er:

Kategorier (kategoriid, kategori)

De nye tabellene som erstattet den originale produkttabellen er: kategorier tabell og produkttabell (samme navn). Disse tabellene er nå i den første normale formen og den andre normale formen. Se de faktiske reglene for det andre normale skjemaet i følgende diskusjon.

Salgstabellen

Radeksjonene der SaleId gjentar seg, men kolonnecelleverdiene gjentar seg ikke, må fjernes fra salgstabellen og plasseres i en ny tabell. I den nye tabellen vil de identiske raden (kolonnene) der celleverdiene gjentas sammen med SaleID i salgstabellen ikke være inkludert. Det vil si hvilken som helst celleverdi eller radseksjon som trioen (kunde, ansatt og dato) som må gjenta med samme SaleID i salgstabellen, vil ikke bli inkludert i den nye tabellen selv om repetisjonen bare er en gang. Verdiene til produktkolonnen som kan endres med samme SaleID i salgstabellen, må være i den nye tabellen. En ny kolonne blir introdusert som har antall av de samme produktene som selges for et bestemt SaleID. Som opprettholder den nye tabellen i 1NF, og tar det til 2NF. Den nye tabellen kalles Saledetails -tabellen. Hvis utvikleren ikke kan finne et nytt passende navn for den nye tabellen, har noe gått galt med analysen hans. Saledetails -bordet blir:

Saledetails - 2nf

Saledetails -bordet, fjernet fra salgstabellen, er nå i den andre normale formen så vel som fortsatt i første normale form. Sale -ID fra den opprinnelige salgstabellen må inkluderes i Saledetails -tabellen for å opprettholde forholdet mellom det opprinnelige salgstabellen og det nye Saledetails -tabellen. Nå er det 13 rader i Saledetails -bordet i stedet for 15 fra det opprinnelige salgstabellen.

I den opprinnelige salgstabellen ble en hvilken som helst kolonne hvis verdi ikke endret seg, mens SaleId ikke endret seg, forble i det opprinnelige salgstabellen og ikke ble fjernet. Dette er egentlig trioen (kunde, ansatt og dato) i denne situasjonen. Produktkolonneverdiene endret mens SaleID ikke endret seg, så det må fjernes. Hvis prisen for pris eller salg av price endres mens SaleId ikke endrer seg, må den også fjernes.

Ville alle komme til en butikk og bare kjøpe bare ett tinn melk? Nei. For enhver kunde som kjøper, si 4 bokser melk, ville nummer 4 bare passe godt i Numbersold -kolonnen i den bevilgede raden.

“Og hva er den primære nøkkelen til det nye Saledetails -tabellen?”Spurt av innehaveren. Dette er svaret ditt som databaseutvikler:

Legg merke til at i hver rad er SaleID og produktet begge avhengig av Numbersold og SellingPrice (verdier). Hvis enten SalesID eller produktnavnet endres for en hvilken. Med andre ord, en Numbersold og SellingPrice Row er relatert til både SaleID og produktverdiene til den raden. På grunn av denne avhengigheten (funksjonell avhengighet) av SalesID og produktkombinasjonen på en bestemt rad, danner både SalesID og produkt den primære nøkkelen. Produktet skal også understrekes.

Når en nøkkel er en kombinasjon av mer enn en kolonne, kalles nøkkelen en sammensatt nøkkel. Tabellnotasjonen for dette nye Saledetails -tabellen er:

Saledetails (SaleID, produkt, Numbersold, SellingPrice)

Forholdet mellom SalesID og produktet er mange-til-mange.

“Jeg har tenkt å datere databasen. Siden en produkttabell allerede eksisterer med ProductID, ville det ikke være bedre å erstatte produktet som en del av nøkkelen med ProductID? Da vil datamaskinen bruke ProductID fra Saledetails-tabellen og se etter produktnavnet fra produkttabellen, ”kommenterer innehaveren.

Du, databaseutvikleren og treneren, smiler mens du nikker på hodet. Og dette er svaret ditt:

“Innehaver, du har det bra. Du forstår raskere enn jeg forventet. Når en database bare vil være i treningsbøker (hovedbøker), hvor det er mulig, vil den ha tekstnavn i stedet for nummererte IDS. Når en database vil være i en datamaskin, der det er mulig, vil den ha nummererte ID -er i stedet for tekstnavn. Datamaskinen kobler sammen nummererte ID -er og tekstnavn i tabellene sine og skriver ut tekstnavnene når en spørring er utstedt.

La meg ha æren av å gjøre datastyringen; Men for datastyringen vil du betale meg.”Og så, tabellnotasjonen for Saledetails -tabellen blir:

Saledetails (SaleID, ProductID, Numbersold, SellingPrice)

“Det som gjenstår av salgstabellen?”Spurt av en av funksjonærene. Kolonnene hvis verdier ikke endret seg mens SaleID ikke endret seg i salgstabellen. SaleID gjenstår også fordi det "styrer" hver rad i salgstabellen. Det nye salgstabellen blir:

Salgsbord - mellomliggende

Produktet og SellingPrice -kolonnene der det var endring i verdi mens SaleID ikke endret ble fjernet. Nå er det helt klart noen dupliserte komplette rader. Slike duplikater er allerede talt og registrert i Saledetails -tabellen i Numbersold -kolonnen. I selve tabellen Saledetails er tellingen enten 2 eller 1. Så duplikatene trenger ikke å tas i betraktning i det nye salgstabellen. Hvis duplikatene er tillatt, vil en av reglene for den første normale form bli krenket. Det nye salgstabellen blir:

Salgstabell - 2NF

Dette nye og siste salgstabellen er i 2NF så vel som fortsatt i 1NF. Ingen SaleID forekommer mer enn en gang i denne tabellen. Det er 10 rader her, og ikke 15, sammenlignet med det opprinnelige salgstabellen. Dette nye salgsbordet er kortere enn den originale en av fem rader.

Denne endelige salgstabellen har bare en primær nøkkelkolonne som er SaleID. Det er understreket. Sale -ID -verdiene i salgstabellen og SaleD -verdiene i Saledetails -tabellen gjør de nøyaktige korrespondansene mellom de to tabellene.

Tabellnotasjonen for salgstabellen er:

Salg (SaleID, kunde, ansatt, dato)

Og tabellnotasjonen for Saledetails -tabellen er:

Saledetails (SaleID, ProductID, Numbersold, SellingPrice)

De nye tabellene som erstattet den opprinnelige salgstabellen er: Saledetails -tabell og salgstabell (samme navn). Disse tabellene er nå i den første normale formen og den andre normale formen. Se de faktiske reglene for den andre normale skjemaet i følgende diskusjon:

Bestillingsbordet

Analysen som ligner på salgstabellen kan gjøres for at ordrebordet skal ha de nye erstatningstabellene:

Bestilling (OrderId, leverandør, ansatt, dato)

og

OrderDetails (OrderId, ProductID, Numberkjøp, CostPrice)

På dette tidspunktet er du, databaseutvikleren, nettopp ferdig med å illustrere de ansatte inkludert innehaveren om hvordan 2NF er produsert fra 1NF.

Innehaveren spør nå: "Er det slik vi skal danne 2NF -tabellen (e) fra 1NF -tabellen?”Du, databaseutvikleren, svarer som følger:

"Vel ja. Uansett hvordan du bruker for å danne en 2NF fra 1NF, må du overholde reglene for 2NF.”Du fortsetter deretter med å forklare 2NF -reglene.

Regler for den andre normale skjemaet

For at en tabell skal være i den andre normale form, må den respektere følgende to regler:

1) Tabellen må allerede være i første normalform.

2) Det må ikke være noen delvis avhengighet.

Den funksjonelle avhengigheten eller bare avhengighet blir forklart i forrige del av serien, den første normale formen. Forklaringen blir kort gjentatt her, og da vil den delvise avhengigheten bli forklart.

Funksjonell avhengighet

I en hvilken som helst tabell i den første normale formen, når en primærnøkkel er kjent, kan resten av verdiene i raden til den primære nøkkelen hentes. For eksempel, i den aller første tabellen i forrige eksempel, er verdiene for det primære nøkkelen nummer 10: tannkrem, toalettsaker, oppryddingsselskap, Peter Lewis, ordre og 4. Så nøkkel nummer 10 avhenger av disse verdiene. En primær nøkkel identifiserer unikt alle dens verdier.

Delvis avhengighet

Delvis avhengighet er en situasjon med sammensatt nøkkel der en ikke-primær nøkkelverdi på rad bare kan ha en del av den sammensatte nøkkelen, e.g. en av cellene avhengig av den. I de forrige tabellene med sammensatte tasker har hver ikke-primær nøkkelverdi på rad begge celler i den primære nøkkelen avhengig av den. Den andre regelen for 2NF sier at det ikke må være noen delvis avhengighet. Og det er ingen delvis avhengighet i noen av de tidligere tabellene.

Begge cellene i den sammensatte tasten avhenger av hver verdi i raden for alle ovennevnte tabeller med komposittnøkler. Hvis det var delvis avhengighet, vil den ene cellen i den sammensatte nøkkelen avhenge av noen verdier i raden, og den andre cellen til den sammensatte nøkkelen vil avhenge av de andre verdiene i samme rad.

Produksjon av 2NF fra produkttabellen og salgstabellen sammenlignet

Produkttabellen har en lengde (går nedover) grensen. Salgstabellen har ikke en lengdegrense fordi det er en transaksjonstabell. Imidlertid er denne forskjellen ikke det som nødvendigvis gir begge tabellene sine forskjellige måter å skaffe 2NF -tabellene.

I det gitte 1NF -produkttabellen gjentas kategoriene nedover. Kategori -kolonnen fjernes for å danne en ny tabell med begrenset lengde og den sammensatte nøkkelen går til overordnet tabell, produktene tabellen.

I det gitte 1NF -salgstabellen gjentar SaleID og tilsvarende sett med andre celler i samme rad nedover. De ganske ikke-gjentatte kolonnene ble fjernet for å danne en ny tabell, og den sammensatte tasten går til barnebordet, Saledetails-tabellen. Både salget og Saledetails -bordene er av ubegrensede lengder.

På dette tidspunktet ber du, databaseutvikleren som trener personalet inkludert innehaveren deres, alle om å bekrefte om alle de nye tabellene virkelig er i første og andre normale skjemaer. De burde gjøre det med hell og svare ja.

Og så konkluderer du.

Konklusjon

En tabell er i den andre normale form hvis den overholder følgende regler:

1) Tabellen må allerede være i første normalform.

2) Det må ikke være noen delvis avhengighet.

For alle tabellene med sammensatte primærnøkler, bestemmer alle ikke-primære nøkkelverdiene på rad hver av den primære nøkkelverdien til den raden.

Å ta et bord fra 1NF til 2NF vil innebære å håndtere en større gjentatt gruppe (sett med celler).

Selv om noen sårbarheter er eliminert, har en tabell i 2NF fortsatt andre sårbarheter. Flere av disse sårbarhetene vil bli behandlet i neste opplæring (artikkel) på tredje normale form.

Fra spørsmålene som de ansatte stiller og tilbakemeldingene fra dem, viser det at de har forstått alt de har blitt lært så langt. Du må gratulere dem før du drar og er tilbake igjen for å diskutere om den tredje normale formen.