Den tredje normale formen

Dette er del tre av serien, fem normale former. Titlene på de to første delene (tutorials) er første normal form, etterfulgt av andre normale form. I denne delen av serien blir tredje normal form forklart.

Forklaringen følger historielinjen: en far har dødd og har lagt igjen penger til sønnen. Sønnen bestemte seg for å investere pengene i en nærbutikk. En nærbutikk, også kjent som en nærbutikk, er en liten detaljhandelsvirksomhet som mottar hverdagsartikler fra leverandører og selger dem til enkeltkunder i nabolaget.

På dette tidspunktet er butikken allerede lager, og det er allerede gjort noe salg. Sønnen, som er innehaver av virksomheten, har noen ansatte, som kalles funksjonærer i denne opplæringen. Innehaver og enhver ansatt kan motta forsyninger og selge etter å ha registrert produktene.

Imidlertid, før butikken startet, visste verken innehaver eller de ansatte noe om normale former. Så de registrerte alt som transaksjoner i en tabell og en treningsbok. De hadde ikke en datamaskin.

Du, leseren, har fullført de fem delene av denne opplæringsserien; Du er nå en databaseutvikler. Innehaveren av bekvemmelighetsbutikken er din venn. Du besøkte butikken for to dager siden og trente innehaveren og funksjonærene på å produsere et bord i sin første normale form. Du besøkte også butikken i går og trente dem på hvordan du oppretter et bord i den andre normale formen fra den første normale formen.

I dag har du nettopp kommet til butikken for et besøk for å trene dem på hvordan du produserer et bord i tredje normalform fra den andre normale form. Alle tabellene de har for tiden er i den andre normale form. Tabellene (etter navn og kolonneoverskrifter) er:

Produkter (ProductID, CategoryID, Produkt)
Kategorier (kategoriid, kategori)

Salg (SaleID, kunde, ansatt, dato)
Saledetails (SaleID, ProductID, Numbersold, SellingPrice)

Bestillinger (OrderID, leverandør, ansatt, dato)
OrderDetails (OrderId, ProductID, Numberkjøp, CostPrice)

Enkelt- eller komposittnøklene er understreket.

Etter å ha oppsummert hva som ble undervist i løpet av de to foregående dagene, og før du kunne gjøre noe, spør innehaveren:

“Hva med telefonnumre, adresser osv., For kunder og ansatte?

Hva med mengde på lager, ombestillingsnivå osv., for produkter?
Trenger de sine egne separate bord, eller hvis de skal monteres i de nåværende tabellene?”

Du, databaseutvikleren, svarer:

“Gratulerer, innehaver! Du har indirekte introdusert spørsmålet om tredje normal form.”

Du fortsetter.

Andre nødvendige kolonner

Andre nødvendige kolonner blir først lagt til de forrige tabellene, som er i 1NF og 2NF. Noen av de forrige kolonnenavnene er endret.

Som et minimum skal kategoritabellen ha følgende kolonner:

Kategorier (kategorier, kategorienavn, beskrivelse)

Beskrivelsen er et kort avsnitt som beskriver kategorien. Denne kategorien tabellen er allerede i 1NF, 2NF og 3NF. 3NF er forklart nedenfor:

Som et minimum skal produkttabellen ha følgende kolonner:

Produkter (ProductID, CategoryID, leverandørid, produktnavn, UnitPrice, QuantityInstock, ReorderLevel)

Når hvert produkt selges, vil et lavt nivå (antall) av produktene nås når produktet må ombestilles, så kundene skal ikke komme til butikken og ikke ha produktet. Slikt fravær er ikke bra for virksomheten. QuantityInstock er antallet av et bestemt produkt på lager. Dette inkluderer hva som er i butikken og hva som er på hyllen.

CategoryId og leverandøren er utenlandske nøkler. Det er grunnen til at de har dash understreket i stedet for en enkelt understrek. Utenlandsk nøkkel er forklart nedenfor. I forrige del av serien (andre normal form) var kategorier en del av den primære nøkkelen med en enkelt understrek på grunn av hvordan den ble kommet til. Fra forklaringen nedenfor vil det imidlertid være tydelig at kategorien skal være en fremmed nøkkel (med en strek understrek).

Dette produkttabellen er allerede i 1NF, 2NF og 3NF. Se hvorfor det er i 3NF nedenfor:

Som et minimum skal Saledetails -tabellen ha følgende kolonner:

Saledetails (SaleID, ProductID, UnitsellingPrice, mengde, rabatt)

Rabattverdien forventes å være null mesteparten av tiden. En rabatt er rabatten butikken gir en kunde.

Som et minimum skal OrderDetails -tabellen ha følgende kolonner:

OrderDetails (OrderId, ProductID, UnitCostPrice, mengde, rabatt)

Rabattverdien forventes å være null mesteparten av tiden. Rabatten her er rabatten som leverandøren gir butikken.

Som vist nedenfor kan produktene tabellen vurderes i 2NF eller 3NF. Salgs- og ordrebordene har utstedelse av 3NF. Bare salgstabellen vil bli brukt til å forklare problemet og løsningen. 3NF for bestillingsbord og produkttabell Følg lignende resonnement og vil nettopp bli sitert.

Mens du legger til kolonner, vil salgstabellen være:

Salg (SaleID, Datesold CustomName, Telefon, adresse, by, region, postalkode, land, ansatt)

Syv kolonner har erstattet kundekolonnen i den opprinnelige tabellen. Siden kundene er mennesker i nabolaget, kan cellene for byen, regionen (staten), postalkode og landskolonner, bli tomme, selv om de ikke blir tomme i denne artikkelen.

Denne salgstabellen er fremdeles i 2NF, da både 1NF- og 2NF -reglene ikke er blitt krenket. Imidlertid må det realiseres at i en salgstabellrekke har kunden (navnet) blitt erstattet av syv kundens radceller.

Merk: En adressecelle har husnummer, navn på gaten eller veien og navnet på byen, alle atskilt med komma. En by kan betraktes som bestående av flere byer. Selv om kommaer skiller disse strengkomponentene, danner de en celleverdi og ikke tre celleverdier.

Ansattes kolonne må også erstattes av syv slike kolonner. Det gjøres imidlertid ikke i denne opplæringen for å spare undervisningstid og rom. Så en salgstabell med data kan være:

Salgstabell - 2NF - Uten CustomerId

Datatypen SaleID-kolonnen er et heltall eller, bedre, auto-increment. Datatypen til dato -kolonnen er en dato og ikke et tall fordi den har tegnet “/”, som ikke er et siffer. Datatypen for resten av kolonnene, inkludert telefonkolonnen, er streng (eller tekst). Telefonverdien har tegnet “-”, som ikke er et siffer.

Merk at for hver rad er kunde (navn), som i forrige del av serien, blitt erstattet av syv celler, hvorav den ene fremdeles er kundenavn. Dette betyr at kundedata er en enhet. Foreløpig identifiserer kundenavnet sine seks andre data på rad. Hvis denne tabellen er programmert, vil det være praktisk å identifisere kundeenheten i hver rad med et heltall (ikke auto-increment). I så fall bør en CustomerID -kolonne gå foran tilpassetnavnet. Den forrige tabellen blir:

Salgstabell - 2NF - med CustomerID

Det er tre CustomerIds: 1, 2 og 3, med 1 som forekommer fem ganger for John Smith, 2 som forekommer to ganger for James Taylor, og 3 som oppstår en gang for Susan Wright.

Merk at noen CustomerIds og deres avhengige gjentar.

Regler for tredje normal form

En tabell er i tredje normal form hvis den overholder følgende regler:

1. Det skal allerede være i den andre normale form.
2. Og det skal ikke ha transitiv avhengighet.

Da spør en av funksjonærene (ansatte): “Hva er en transitiv avhengighet?”. Og du, databaseutvikleren, svar: “Det er et godt spørsmål!”

Transitiv avhengighet

Det er sant at på rad identifiserer Saleid alle verdiene i raden; Imidlertid identifiserer CustomerID sine syv dataverdier, men identifiserer ikke resten av verdiene som er identifisert av SaleID i den raden. Sagt på en annen måte, SaleID avhenger av ti celleverdier i hver rad. Imidlertid avhenger CustomerID av syv celleverdier i samme rad, men CustomerID er ikke avhengig av SaleID og de andre verdiene som SaleID avhenger av.

Slik avhengighet for depumerid er transitiv avhengighet. Og CustomerID kalles en utenlandsk nøkkel og er dash understreket i denne opplæringsserien, de fem normale formene.

Anta at et ikke-prime-attributt (ikke-primær celleverdi) avhenger av andre ikke-prime-attributter, og det ikke-prime attributtet (e.g., CustomerId og dens avhengige) avhenger ikke av den primære nøkkelen og resten av celleverdiene i raden. Da er det transitiv avhengighet.

Den forrige salgstabellen med den utenlandske nøkkelen og dens avhengige, ville forårsake regnskapsproblemer (avvik).

Salgstabell fra 2NF til 3NF

For å løse problemet med den utenlandske nøkkelen og dens avhengige, fjerne den utenlandske nøkkelen og dens avhengige, for å danne et nytt tabell uten repetisjoner. Selv om den utenlandske nøkkelen ikke er avhengig av den primære nøkkelen, avhenger imidlertid den primære nøkkelen av den utenlandske nøkkelen. Så en kopi av den utenlandske nøkkelen må forbli i overordnede tabellen. Det nye salgstabellen er på dette tidspunktet 1NF, 2NF og 3NF -kompatibel; Det er et foreldrebord. Det nye barnebordet fra forrige salgstabell er også 1NF, 2NF og 3NF -kompatibel. Navnet på barnebordet med utenlandsk nøkkel og dets avhengige er kunder. Hvis et passende navn ikke kan bli funnet, har noe gått galt med analysen. Det nye salgsbordet i 3NF er:

Endelig salgstabell i 3NF

Denne tabellen i 3NF har samme antall rader som den i 2NF, men med færre kolonner.

Tabellnotasjonen for denne endelige salgstabellen i 3NF er:

Salg (SaleID, Datesold, CustomerId, EmployeeId)

SaleID er den primære nøkkelen med en enkelt understrek. CustomerId er en fremmed nøkkel, med en strek understrek. EmployeeId er også en utenlandsk nøkkel med en strek understrek. Merk at ansattes situasjon i salgstabellen i 2NF er den samme som kundesituasjonen. EmployeeId og dens egne avhengige må trekkes av for å danne et annet bord; En kopi av ansattes gjenstår.

Merk: SaleID, CustomerID og EmployeeD danner ikke en sammensatt nøkkel. SaleId er avhengig av CustomerID og EmployeeId.

Forholdet mellom SaleID og CustomerID er mange til en.

Kundebordet i 3NF

Denne tabellen har tre rader i stedet for 9 rader i 2NF -salgstabellen. I denne tabellen er CustomerID en primær nøkkel. Det er det samme som den utenlandske nøkkelen i salgstabellen, men uten repetisjoner. Den utenlandske nøkkelen i salgstabellen og den primære nøkkelen i kundetabellen lenker begge tabellene.

De gjentatte radene i kundebordet er fjernet for ikke å krenke 1NF.

Som leseren kan se, ville det å sette et bord i 3NF også løse problemet med gjentatte rader (redundans).

Tabellnotasjonen for kundetabellen er:

Kunder (CustomerId, CustomerName, Phone, Address, City, Region, postnummer, land)

Produktbordet er revidert

Produkttabellen gitt ovenfor i notasjonsskjema er:

Produkter (ProductID, CategoryID, leverandørid, produktnavn, UnitPrice, QuantityInstock, ReorderLevel)

Den primære nøkkelen her er ProductID. CategoryId og leverandøren er utenlandske nøkler. I likhet med kundetabellen er det en kategoritabell, der CategoryID er den primære nøkkelen, og det er et leverandørbord, der leverandøren er den primære nøkkelen.

Hvis verdiene for cellene for UnitPrice, QuantityInstock og ReorderLevel vil forbli fast, er produktene som det er virkelig i 3NF. Hvis disse verdiene endrer seg, er produktene, som det er, i 2NF. I denne delen av opplæringsserien antas det at disse verdiene forblir faste over tid.

Alle bordene

Alle bordene er nå i 3NF. De vises som:

Ansatte (Ansattesid, navn, telefon, adresse, by, region, postnummer, land, fødselsdato, leidet, daterelease)

Leverandører (leverandørid, navn, telefon, adresse, by, region, postnummer, land)

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

Salg (SaleID, Datesold, CustomerId, EmployeeId)
Saledetails (SaleID, ProductID, Numbersold, SellingPrice)
Kunder (CustomerId, CustomerName, Phone, Address, City, Region, postnummer, land)

Bestillinger (OrderId, Datesold, LevererID, EmployeeId)
OrderDetails (OrderId, ProductID, Numberkjøp, CostPrice)

Opptil ni profesjonelle tabeller er produsert fra bare ett bord produsert av nybegynnere for å forhindre redundans og regnskapsproblemer (avvik fra innsatsen, sletting og oppdatering). Nybegynnerbordet alene ville føre til økonomiske tap.

Testing av personalet

På dette tidspunktet skal alle de ansatte, inkludert innehaveren, ha forstått 1NF, 2NF og 3NF. De må imidlertid testes. Alle av dem, inkludert innehaveren, vil sitte på forskjellige steder og fullføre testen. Testen som består av ett spørsmål, vil ta en time, og det er som følger:

SPØRSMÅ. Kundene og leverandørene trenger ikke å være virkelige enheter. Data for tabeller skal sikkerhetskopiere tabellnotasjonene.

Mens de fullfører testen, går du som databaseutvikler ut for å ta en matbit og en øl, for å komme tilbake etter en time.

Nær og fjern fremtid

Mens du, databaseutvikleren, er ute, vurderer du også hvilke råd å gi dem hvis de alle består testen.

Mens du trente dem, og nå som de tar testen, har kundene kommet og forlater uten å bli servert. Det er ikke bra for virksomheten, og du, databaseutvikleren, vet det. Noen kunder kan gå til konkurrentbutikkene og aldri komme tilbake.

Du, databaseutvikleren, er 30 år gammel. Innehaveren, som din venn, er også 30 år gammel. Kontorene (ansatte) er mellom 18 og 24 år. Alle egenskapene de trengte for å jobbe for innehaveren var: å være sunne, å kunne lese og skrive, for å kunne legge til, trekke, multiplisere og dele og kunne bruke datamaskinen og internett.

Når en tabell er i 3NF, er de fleste sårbarheter blitt fjernet fra databasen. Mange kommersielle databaser går ikke utover 3NF, og firmaene eller selskapene er komfortable.

Så hvis alle består av testen, vil du be funksjonærene gå og fortsette å jobbe. Du vil også råde dem til å lagre deler av lønnen deres slik at de kan eie nærbutikker. Du fortsetter i morgen for å trene bare innehaveren i 4NF og 5NF. Med kunnskap om 4NF og 5NF fjernes alle kjente sårbarheter.

Evaluering

Etter en time kommer du, databaseutvikleren, tilbake. Du markerer skriptene deres. Et stykke utmerkede nyheter! De alle, inkludert innehaveren, har 100% hver. Hurra! Det er utmerket!

Så gratulerer til dere alle: læreren og elevene.

Det er ingenting igjen å gjøre i denne opplæringen annet enn å konkludere.

Konklusjon

En tabell er i første normal form, hvis den ikke bryter noen av følgende regler:

1. Alle kolonnene i en tabell skal ha unike toppnavn.
2. Hver celle må bare ha en enkelt verdi.
3. Verdier som er lagret i en kolonne, skal være av samme type.
4. Radene skal være forskjellige.
5. Rekkefølgen på kolonnene eller radene spiller ingen rolle.

En tabell er i andre normal form, hvis den ikke bryter noen av følgende regler:

1. Bordet må allerede være i første normal form.
2. Det må ikke være noen delvis avhengighet.

En tabell er i tredje normal form, hvis den ikke bryter noen av følgende regler:

1. Det må allerede være i den andre normale form.
2. Og det må ikke ha transitiv avhengighet.

Du, databaseutvikleren, forteller funksjonærene at de har lært nok. Du gir råd og ber dem om å gå tilbake til jobb og bo på stasjonene deres som standard.

Du setter bare en avtale med innehaveren, for å finne sted på kontoret hans i morgen for trening på 4NF og 5NF.