Den tredje Normalform

Den Tredje Normalform



Dette er del tre af serien, Five Normal Forms. Titlerne på de to første dele (tutorials) er First Normal Form, efterfulgt af Second Normal Form. I denne del af serien forklares Tredje Normalform.

Forklaringen følger historien: En far er død og har efterladt nogle penge til sin søn. Sønnen besluttede at investere pengene i en dagligvarebutik. En dagligvarebutik, også kendt som en dagligvarebutik, er en lille detailhandel, der modtager hverdagsting fra leverandører og sælger dem til individuelle kunder i nabolaget.







På dette tidspunkt er butikken allerede på lager, og der er allerede gennemført nogle salg. Sønnen, som er indehaver af virksomheden, har nogle ansatte, som kaldes ekspedienter i denne vejledning. Indehaveren og enhver medarbejder kan modtage forsyninger og foretage salg efter registrering af produkterne.



Inden butikken startede, vidste hverken indehaveren eller de ansatte noget om normale former. Så de registrerede alt som transaktioner i en tabel og en øvelsesbog. De havde ikke en computer.



Du, læseren, har gennemført de fem dele af denne vejledningsserie; du er nu databaseudvikler. Indehaveren af ​​dagligvarebutikken er din ven. Du besøgte butikken for to dage siden og trænede indehaveren og ekspedienterne i at fremstille et bord i dets første normale form. Du besøgte også butikken i går og trænede dem i, hvordan man laver en tabel i den anden normalform fra den første normalform.





I dag er du netop ankommet til butikken på besøg for at træne dem i, hvordan man fremstiller et bord i den tredje normalform fra den anden normalform. Alle de tabeller, de har i øjeblikket, er i den anden normale form. Tabellerne (efter navn og kolonneoverskrifter) er:

Produkter (produkt-id, kategori-id, produkt)
Kategorier (kategori-id, kategori)



Salg (salgs-id, kunde, medarbejder, dato)
Udsalgsdetaljer(udsalgs-id, produkt-id, antal solgt, salgspris)

Ordrer (ordre-id, leverandør, medarbejder, dato)
Ordredetaljer(ordre-id, produkt-id, antal købt, kostpris)

De enkelte eller sammensatte tangenter er understreget.

Efter at have opsummeret, hvad der blev undervist i de foregående to dage, og før du kunne gøre noget, spørger indehaveren:

”Hvad med telefonnumre, adresser osv. til kunder og medarbejdere?

Hvad med mængde på lager, genbestillingsniveau osv. for produkter?
Har de brug for deres egne separate borde, eller skal de monteres i de nuværende borde?”

Du, databaseudvikleren, svarer:

'Tillykke, indehaver! Du har indirekte introduceret spørgsmålet om den tredje normalform.'

Du fortsætter.

Andre nødvendige kolonner

Andre nødvendige kolonner tilføjes først til de foregående tabeller, som er i 1NF og 2NF. Nogle af de tidligere kolonnenavne er ændret.

Tabellen Kategorier skal som minimum have følgende kolonner:

Kategorier (kategori-id, kategorinavn, beskrivelse)

Beskrivelsen er et kort afsnit, der beskriver kategorien. Denne kategoritabel er allerede i 1NF, 2NF og 3NF. 3NF er forklaret nedenfor:

Produkttabellen skal som minimum have følgende kolonner:

Produkter (produkt-id, kategori-id, leverandør-id, produktnavn, enhedspris, antal på lager, genbestillingsniveau)

Da hvert produkt sælges, vil et lavt niveau (antal) af produkterne blive nået, når produktet skal genbestilles, så kunder bør ikke komme i butikken og ikke have produktet. Et sådant fravær er ikke godt for erhvervslivet. quantityInStock er antallet af et bestemt produkt på lager. Dette inkluderer, hvad der er i butikken, og hvad der er på hylden.

kategori-ID og leverandør-id er fremmednøgler. Derfor har de streg understregning i stedet for enkelt understregning. Fremmednøgle er forklaret nedenfor. I den forrige del af serien (Second Normal Form) var kategori-ID en del af den primære nøgle med en enkelt understregning på grund af, hvordan man nåede frem til det. Men ud fra forklaringen nedenfor vil det være klart, at kategori-ID'et skal være en fremmednøgle (med en streg understregning).

Denne produkttabel er allerede i 1NF, 2NF og 3NF. Se hvorfor det er i 3NF nedenfor:

Som minimum skal SaleDetails-tabellen have følgende kolonner:

Salgsdetaljer(udsalgs-id, produkt-id, enhedssalgspris, antal, rabat)

Diskonteringsværdien forventes at være nul det meste af tiden. En rabat er den rabat, butikken giver en kunde.

Som minimum skal OrderDetails-tabellen have følgende kolonner:

Ordredetaljer (ordre-id, produkt-id, enhedsomkostningspris, antal, rabat)

Diskonteringsværdien forventes at være nul det meste af tiden. Rabatten her er den rabat leverandøren giver butikken.

Som det ses nedenfor, kan produkttabellen overvejes i 2NF eller 3NF. Salgs- og ordretabellerne har udgaven af ​​3NF. Kun salgstabellen vil blive brugt til at forklare problemet og løsningen. 3NF for ordretabellen og produkttabellen følger lignende ræsonnementer og vil blot blive citeret.

Mens du tilføjer kolonner, vil salgstabellen være:

Salg (salgs-id, datoSolgt kundenavn, telefon, adresse, by, region, postnummer, land, medarbejder)

Syv kolonner har erstattet kundekolonnen i den oprindelige tabel. Da kunderne er personer i nabolaget, kan cellerne for kolonnerne by, region(stat), postnummer og land stå tomme, selvom de ikke efterlades tomme i denne artikel.

Denne salgstabel er stadig i 2NF, da både 1NF og 2NF reglerne ikke er blevet overtrådt. Det skal dog gøres klart, at i en salgstabelrække er kunden (navn) blevet erstattet af syv kunderækkeceller.

Bemærk: En adressecelle har husnummeret, navnet på gaden eller vejen og byens navn, alle adskilt af kommaer. En by kan betragtes som bestået af flere byer. Selvom kommaer adskiller disse særlige strengkomponenter, danner de én celleværdi og ikke tre celleværdier.

Medarbejderkolonnen skal også erstattes af syv sådanne kolonner. Det er dog ikke gjort i denne tutorial for at spare undervisningstid og plads. Så en salgstabel med data kan være:

Salgstabel – 2NF – Uden kunde-ID

Datatypen SaleID-kolonnen er et heltal eller, bedre, automatisk stigning. Datatypen for dateSold-kolonnen er en dato og ikke et tal, fordi den har tegnet '/', som ikke er et ciffer. Datatypen for resten af ​​kolonnerne, inklusive telefonkolonnen, er streng (eller tekst). Telefonværdien har tegnet '-', som ikke er et ciffer.

Bemærk, at for hver række er kunde (navn), som det var i den forrige del af serien, blevet erstattet af syv celler, hvoraf den ene stadig er kundenavn. Det betyder, at kundedata er en enhed. I øjeblikket identificerer kundenavnet sine øvrige seks data i træk. Hvis denne tabel er programmeret, vil det være praktisk at identificere kundeenheden i hver række med et heltal (ikke automatisk stigning). I så fald skal en kundeID-kolonne stå foran kundenavnet. Den foregående tabel bliver:

Salgstabel – 2NF – Med kunde-ID

Der er tre kunde-id'er: 1, 2 og 3, hvor 1 forekommer fem gange for John Smith, 2 forekommer to gange for James Taylor, og 3 forekommer én gang for Susan Wright.

Bemærk, at nogle kunde-id'er og deres afhængige gentages.

Regler for tredje normalform

En tabel er i tredje normalform, hvis den overholder følgende regler:

  1. Det burde allerede være i den anden normale form.
  2. Og det bør ikke have transitiv afhængighed.

Så spørger en af ​​ekspedienterne (medarbejderne): 'Hvad er en transitiv afhængighed?'. Og du, databaseudvikleren, svarer: 'Det er et godt spørgsmål!'

Transitiv afhængighed

Det er rigtigt, at SaleID i en række identificerer alle værdierne i rækken; dog identificerer kunde-ID sine syv dataværdier, men identificerer ikke resten af ​​værdierne identificeret af SaleID i den pågældende række. Sagt på en anden måde afhænger SaleID'et af ti celleværdier i hver række. Kunde-id'et afhænger dog af syv celleværdier i samme række, men kunde-id'et afhænger ikke af SaleID'et og de andre værdier, som SaleID afhænger af.

En sådan afhængighed for kunde-ID'et er transitiv afhængighed. Og kunde-ID kaldes en fremmednøgle og er streg understreget i denne vejledningsserie, De fem normale former.

Antag, at en ikke-primær attribut (ikke-primær celleværdi) afhænger af andre ikke-primære attributter, og at den pågældende ikke-primære attribut (f.eks. kunde-ID og dets afhængige) ikke afhænger af primærnøglen og resten af ​​cellen værdier i rækken. Så er det transitiv afhængighed.

Den tidligere salgstabel med fremmednøglen og dens afhængige ville forårsage regnskabsmæssige problemer (anomalier).

Salgstabel Fra 2NF til 3NF

For at løse problemet med den fremmede nøgle og dens afhængige skal du fjerne den fremmede nøgle og dens afhængige for at danne en ny tabel uden gentagelser. Men selvom den fremmede nøgle ikke afhænger af den primære nøgle, afhænger den primære nøgle af den fremmede nøgle. Så en kopi af den fremmede nøgle skal forblive i den overordnede tabel. Den nye salgstabel er på dette tidspunkt 1NF, 2NF og 3NF kompatibel; det er et forældrebord. Den nye underordnede tabel fra den tidligere salgstabel er også 1NF-, 2NF- og 3NF-kompatibel. Navnet på den underordnede tabel med fremmednøgle og dens afhængige er Kunder. Hvis et passende navn ikke kan findes, så er der gået noget galt med analysen. Den nye salgstabel i 3NF er:

Endelig salgstabel i 3NF

Denne tabel i 3NF har det samme antal rækker som den i 2NF, men med færre kolonner.

Tabelnotationen for denne endelige salgstabel i 3NF er:

Salg(udsalgs-id, solgt dato, kunde-id, medarbejder-id)

SaleID'et er den primære nøgle med en enkelt understregning. customerID er en fremmednøgle med en streg understregning. medarbejderID er også en fremmednøgle med en streg understregning. Bemærk at medarbejdersituationen i Salgstabellen i 2NF er den samme som kundesituationen. Medarbejder-ID'et og dets egne afhængige skal trækkes ud for at danne en anden tabel; en kopi af medarbejder-ID forbliver.

Bemærk: salgs-id, kunde-id og medarbejder-id udgør ikke en sammensat nøgle. saleID er afhængig af kunde-id og medarbejder-ID.

Forholdet mellem salgs-id og kunde-id er mange-til-en.

Kundebordet i 3NF

Denne tabel har tre rækker i stedet for 9 rækker i 2NF Sales-tabellen. I denne tabel er kunde-ID en primær nøgle. Det er det samme som fremmednøglen i salgstabellen, men uden gentagelser. Fremmednøglen i salgstabellen og primærnøglen i kundetabellen forbinder begge tabeller.

De gentagne rækker i kundetabellen er blevet fjernet for ikke at overtræde 1NF.

Som læseren kan se, ville en tabel i 3NF også løse problemet med gentagne rækker (redundans).

Tabelnotationen for kundetabellen er:

Kunder (kunde-id, kundenavn, telefon, adresse, by, region, postnummer, land)

Produkttabellen gensynet

Produkttabellen givet ovenfor i notationsform er:

Produkter (produkt-id, kategori-id, leverandør-id, produktnavn, enhedspris, antal på lager, genbestillingsniveau)

Den primære nøgle her er productID. kategori-ID og leverandør-id er fremmednøgler. I lighed med kundetabellen er der en kategori-tabel, hvor kategori-ID er den primære nøgle, og der er en leverandørtabel, hvor leverandør-ID er den primære nøgle.

Hvis værdierne for cellerne for unitPrice, quantityInStock og reorderLevel forbliver faste, så er produkttabellen, som den er, virkelig i 3NF. Hvis disse værdier vil ændre sig, er produkttabellen, som den er, i 2NF. I denne del af selvstudieserien antages det, at disse værdier forbliver faste over tid.

Alle borde

Alle tabeller er nu i 3NF. De er vist som:

Medarbejdere (medarbejder-id, navn, telefon, adresse, by, region, postnummer, land, fødselsdato, ansættelsesdato, udgivelsesdato)

Leverandører (leverandør-ID, navn, telefon, adresse, by, region, postnummer, land)

Produkter (produkt-id, kategori-id, leverandør-id, produktnavn, enhedspris, antal på lager, genbestillingsniveau)
Kategorier (kategori-id, kategorinavn, beskrivelse)

Salg(udsalgs-id, solgt dato, kunde-id, medarbejder-id)
Udsalgsdetaljer(udsalgs-id, produkt-id, antal solgt, salgspris)
Kunder (kunde-id, kundenavn, telefon, adresse, by, region, postnummer, land)

Ordrer (ordre-id, solgt dato, leverandør-id, medarbejder-id)
Ordredetaljer(ordre-id, produkt-id, antal købt, kostpris)

Op til ni professionelle tabeller er blevet produceret ud fra kun én tabel produceret af nybegyndere for at forhindre redundans og regnskabsproblemer (uregelmæssigheder fra indsættelse, sletning og opdatering). Begynderbordet alene ville føre til økonomiske tab.

Test af personalet

På dette tidspunkt burde alle ansatte, inklusive indehaveren, have forstået 1NF, 2NF og 3NF. De skal dog testes. Alle, inklusive indehaveren, vil sidde forskellige steder og gennemføre testen. Testen, der består af et spørgsmål, vil tage en time, og den er som følger:

Spørgsmål: Brug regler for 1NF, 2NF og 3NF til at bevise, at alle ovenstående ni tabeller allerede er i første normalform, anden normalform og tredje normalform. Kunderne og leverandørerne behøver ikke at være reelle enheder. Data for tabeller skal sikkerhedskopiere tabelnotationerne.

Mens de gennemfører testen, går du som databaseudvikler ud for at få en snack og en øl, for at vende tilbage efter en time.

Den nære og fjerne fremtid

Mens du, databaseudvikleren, er ude, overvejer du også, hvilke råd du skal give dem, hvis de alle består testen.

Mens du trænede dem, og nu hvor de tager testen, har kunderne også kommet og gået uden at blive betjent. Det er ikke godt for erhvervslivet, og du, databaseudvikleren, ved det. Nogle kunder går måske til konkurrenternes butikker og kommer aldrig tilbage.

Du, databaseudvikleren, er 30 år gammel. Ejeren er som din ven også 30 år. Ekspedienterne (medarbejderne) er mellem 18 og 24 år. Alle de egenskaber, de behøvede for at arbejde for indehaveren var: at være sunde, at kunne læse og skrive, at kunne addere, trække fra, gange og dividere , og for at kunne bruge computeren og internettet.

Når en tabel er i 3NF, er de fleste sårbarheder blevet fjernet fra databasen. Mange kommercielle databaser går ikke ud over 3NF, og virksomhederne eller virksomhederne er komfortable.

Så hvis alle består testen, vil du bede ekspedienterne om at gå og fortsætte med at arbejde. Du vil også råde dem til at spare dele af deres løn, så de kan eje deres dagligvarebutikker. Du fortsætter i morgen med kun at træne indehaveren i 4NF og 5NF. Med kendskab til 4NF og 5NF fjernes alle kendte sårbarheder.

Evaluering

Efter en time kommer du, databaseudvikleren, tilbage. Du markerer deres scripts. En god nyhed! De har alle, inklusive indehaveren, 100% hver. Hurra! Det er fremragende!

Så tillykke til jer alle: læreren og eleverne.

Der er ikke andet at gøre i denne tutorial end at afslutte.

Konklusion

En tabel er i First Normal Form, hvis den ikke overtræder nogen af ​​følgende regler:

  1. Alle kolonnerne i en tabel skal have unikke overskriftsnavne.
  2. Hver celle må kun have en enkelt værdi.
  3. Værdier gemt i en kolonne skal være af samme type.
  4. Rækkerne skal være adskilte.
  5. Rækkefølgen af ​​kolonnerne eller rækkerne er ligegyldig.

En tabel er i anden normal form, hvis den ikke overtræder nogen af ​​følgende regler:

  1. Tabellen skal allerede være i First Normal Form.
  2. Der må ikke være nogen delvis afhængighed.

En tabel er i tredje normalform, hvis den ikke overtræder nogen af ​​følgende regler:

  1. Det skal allerede være i den anden normalform.
  2. Og den må ikke have transitiv afhængighed.

Du, databaseudvikleren, fortæller ekspedienterne, at de har lært nok. Du giver råd og beder dem om at vende tilbage på arbejde og blive på deres stationer som standard.

Du aftaler kun en aftale med indehaveren, som skal finde sted på hans kontor i morgen til træning i 4NF og 5NF.