Dette er del tre av serien, Five Normal Forms. Titlene på de to første delene (veiledninger) er First Normal Form, etterfulgt av Second Normal Form. I denne delen av serien forklares Third Normal Form.
Forklaringen følger historien: En far er død og har lagt igjen noen 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 detaljhandel som mottar dagligvarer fra leverandører og selger dem til enkeltkunder i nabolaget.
På dette tidspunktet er butikken allerede på lager, og noen salg er allerede gjort. Sønnen, som er innehaver av virksomheten, har noen ansatte, som kalles funksjonærer i denne opplæringen. Innehaveren og enhver ansatt kan motta forsyninger og foreta salg etter registrering av produktene.
Men før butikken startet, visste verken innehaver eller de ansatte noe om vanlige former. Så de registrerte alt som transaksjoner i en tabell og en oppgavebok. De hadde ikke datamaskin.
Du, leseren, har fullført de fem delene av denne opplæringsserien; du er nå en databaseutvikler. Eieren av nærbutikken er din venn. Du besøkte butikken for to dager siden og trente innehaveren og funksjonærene i å produsere et bord i sin første normale form. Du besøkte også butikken i går og lærte dem hvordan du lager en tabell i den andre normalformen fra den første normalformen.
I dag har du nettopp ankommet butikken på besøk for å lære dem hvordan de produserer et bord i den tredje normalformen fra den andre normalformen. Alle tabellene de har for øyeblikket er i den andre normalformen. Tabellene (etter navn og kolonneoverskrifter) er:
Produkter (produkt-ID, kategori-ID, produkt)
Kategorier (kategori-ID, kategori)
Salg (salgs-ID, kunde, ansatt, dato)
Salgsdetaljer(salgs-ID, produkt-ID, antall solgt, salgspris)
Bestillinger (ordreID, leverandør, ansatt, dato)
Ordredetaljer(ordre-ID, produkt-ID, antall kjøpt, kostpris)
De enkle eller sammensatte tangentene er understreket.
Etter å ha oppsummert hva som ble undervist i de to foregående dagene og før du kunne gjøre noe, spør innehaveren:
«Hva med telefonnumre, adresser osv. til kunder og ansatte?
Hva med antall på lager, etterbestillingsnivå osv. for produkter?
Trenger de sine egne separate bord, eller bør de monteres i de nåværende bordene?»
Du, databaseutvikleren, svarer:
«Gratulerer, innehaver! Du har indirekte introdusert problemet med tredje normalform.»
Du fortsetter.
Andre nødvendige kolonner
Andre nødvendige kolonner legges først til de foregående tabellene, som er i 1NF og 2NF. Noen av de tidligere kolonnenavnene er endret.
Som et minimum bør kategorier-tabellen ha følgende kolonner:
Kategorier (kategori-ID, kategorinavn, beskrivelse)
Beskrivelsen er et kort avsnitt som beskriver kategorien. Denne kategoritabellen er allerede i 1NF, 2NF og 3NF. 3NF er forklart nedenfor:
Som et minimum bør produkttabellen ha følgende kolonner:
Produkter (produkt-ID, kategori-ID, leverandør-ID, produktnavn, enhetspris, kvantitet på lager, ombestillingsnivå)
Ettersom hvert produkt selges, vil et lavt nivå (antall) av produktene nås når produktet må bestilles på nytt, så kunder bør ikke komme til butikken og ikke ha produktet. Slikt fravær er ikke bra for virksomheten. quantityInStock er nummeret på et bestemt produkt på lager. Dette inkluderer hva som er i butikken og hva som er i hylla.
kategoriID og leverandørID er fremmednøkler. Det er derfor de har strek understreking i stedet for enkel understreking. Fremmednøkkel er forklart nedenfor. I den forrige delen av serien (Second Normal Form) var kategoriID en del av primærnøkkelen med en enkelt understreking på grunn av hvordan man kom frem til den. Men fra forklaringen nedenfor vil det være klart at kategori-IDen skal være en fremmednøkkel (med en strek understreking).
Denne produkttabellen er allerede i 1NF, 2NF og 3NF. Se hvorfor det er i 3NF nedenfor:
Som et minimum bør SaleDetails-tabellen ha følgende kolonner:
Salgsdetaljer(salgs-ID, produkt-ID, enhetssalgspris, antall, rabatt)
Rabattverdien forventes å være null mesteparten av tiden. En rabatt er rabatten butikken gir en kunde.
Som et minimum bør OrderDetails-tabellen ha følgende kolonner:
Bestillingsdetaljer(ordre-ID, produkt-ID, enhetskostnadspris, antall, rabatt)
Rabattverdien forventes å være null mesteparten av tiden. Rabatten her er rabatten leverandøren gir butikken.
Som vist nedenfor, kan produkttabellen vurderes i 2NF eller 3NF. Salg- og ordretabellene har utgaven av 3NF. Kun salgstabellen vil bli brukt til å forklare problemet og løsningen. 3NF for bestillingstabell og produkttabell følger lignende resonnement og vil bare bli sitert.
Når du legger til kolonner, vil salgstabellen være:
Salg (salgs-ID, datosolgt kundenavn, telefon, adresse, by, region, postnummer, land, ansatt)
Sju kolonner har erstattet kundekolonnen i den opprinnelige tabellen. Siden kundene er folk i nabolaget, kan cellene for kolonnene by, region(stat), postnummer og land stå tomme, selv om de ikke står tomme i denne artikkelen.
Denne salgstabellen er fortsatt i 2NF da både 1NF- og 2NF-reglene ikke har blitt brutt. Du bør imidlertid være klar over at i en salgstabellrad har kunden (navnet) blitt erstattet med syv kunderadceller.
Merk: en adressecelle har husnummeret, navnet på gaten eller veien og navnet på byen, alt atskilt med komma. En by kan betraktes som består av flere byer. Selv om kommaer skiller disse spesielle strengkomponentene, danner de én celleverdi og ikke tre celleverdier.
Ansattkolonnen må også erstattes med syv slike kolonner. Dette gjøres imidlertid ikke i denne opplæringen for å spare tid og plass til undervisningen. Så en salgstabell med data kan være:
Salgstabell – 2NF – Uten kunde-ID
Datatypen SaleID-kolonnen er et heltall eller, bedre, automatisk økning. Datatypen til dateSold-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 var i forrige del av serien, erstattet med syv celler, hvorav én fortsatt er kundenavn. Dette betyr at kundedata er en enhet. For øyeblikket identifiserer kundenavnet de andre seks dataene på rad. Hvis denne tabellen er programmert, vil det være praktisk å identifisere kundeenheten i hver rad med et heltall (ikke automatisk inkrement). I så fall bør en kundeID-kolonne komme foran kundenavnet. Den forrige tabellen blir:
Salgstabell – 2NF – Med kunde-ID
Det er tre kunde-IDer: 1, 2 og 3, hvor 1 forekommer fem ganger for John Smith, 2 forekommer to ganger for James Taylor, og 3 forekommer én gang for Susan Wright.
Vær oppmerksom på at enkelte kunde-IDer og deres avhengige gjentas.
Regler for tredje normalform
En tabell er i tredje normalform hvis den overholder følgende regler:
- Den skal allerede være i den andre normalformen.
- Og den skal ikke ha transitiv avhengighet.
Så spør en av funksjonærene (ansatte) 'Hva er en transitiv avhengighet?'. Og du, databaseutvikleren, svarer: 'Det er et godt spørsmål!'
Transitiv avhengighet
Det er sant at på rad identifiserer SaleID alle verdiene i raden; kunde-ID identifiserer imidlertid de syv dataverdiene, men identifiserer ikke resten av verdiene identifisert av SaleID i den raden. Sagt på en annen måte, SaleID avhenger av ti celleverdier i hver rad. Kunde-ID avhenger imidlertid av syv celleverdier i samme rad, men kunde-ID avhenger ikke av SaleID og de andre verdiene som SaleID er avhengig av.
Slik avhengighet for kunde-ID er transitiv avhengighet. Og kunde-ID kalles en fremmednøkkel og er strek understreket i denne opplæringsserien, The Five Normal Forms.
Anta at et ikke-primærattributt (ikke-primærcelleverdi) avhenger av andre ikke-primærattributter, og det aktuelle ikke-primærattributtet (f.eks. kunde-ID og dens avhengige) ikke er avhengig av primærnøkkelen og resten av cellen verdier i raden. Da er det transitiv avhengighet.
Den forrige salgstabellen med fremmednøkkelen og dens avhengige ville forårsake regnskapsproblemer (avvik).
Salgstabell Fra 2NF til 3NF
For å løse problemet med fremmednøkkelen og dens avhengige, fjern fremmednøkkelen og dens avhengige, for å danne en ny tabell uten repetisjoner. Men selv om fremmednøkkelen ikke er avhengig av primærnøkkelen, er primærnøkkelen avhengig av fremmednøkkelen. Så en kopi av fremmednøkkelen må forbli i den overordnede tabellen. Den nye salgstabellen er på dette tidspunkt 1NF, 2NF og 3NF-kompatibel; det er et foreldrebord. Den nye underordnede tabellen fra den forrige salgstabellen er også 1NF-, 2NF- og 3NF-kompatibel. Navnet på den underordnede tabellen med fremmednøkkel og dens avhengige er Kunder. Hvis det ikke finnes et passende navn, har noe gått galt med analysen. Den nye salgstabellen 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 siste salgstabellen i 3NF er:
Salg (salgs-ID, solgt dato, kunde-ID, ansatt-ID)
SaleID-en er primærnøkkelen med en enkel understreking. kunde-ID er en fremmednøkkel, med en strek understreking. ansattID er også en fremmednøkkel med en strek understreking. Merk at ansattsituasjonen i Salgstabellen i 2NF er den samme som kundesituasjonen. Medarbeider-IDen og dens egne avhengige må trekkes av for å danne en annen tabell; en kopi av ansatt-ID gjenstår.
Merk: salgs-ID, kunde-ID og ansatt-ID utgjør ikke en sammensatt nøkkel. saleID er avhengig av kunde-ID og ansatt-ID.
Forholdet mellom salgs-ID og kunde-ID er mange-til-en.
Kundebordet i 3NF
Denne tabellen har tre rader i stedet for 9 rader i 2NF Sales-tabellen. I denne tabellen er kunde-ID en primærnøkkel. Den er den samme som fremmednøkkelen i Sales-tabellen, men uten repetisjoner. Fremmednøkkelen i salgstabellen og primærnøkkelen i kundetabellen kobler sammen begge tabellene.
De gjentatte radene i kundetabellen er fjernet for ikke å bryte 1NF.
Som leseren kan se, vil å sette en tabell i 3NF også løse problemet med gjentatte rader (redundans).
Tabellnotasjonen for kundetabellen er:
Kunder (kunde-ID, kundenavn, telefon, adresse, by, region, postnummer, land)
Produkttabellen ble besøkt på nytt
Produkttabellen gitt ovenfor i notasjonsform er:
Produkter (produkt-ID, kategori-ID, leverandør-ID, produktnavn, enhetspris, kvantitet på lager, ombestillingsnivå)
Den primære nøkkelen her er produkt-ID. kategoriID og leverandørID er fremmednøkler. I likhet med kundetabellen er det en kategoritabell, der kategori-ID er primærnøkkelen, og det er en leverandørtabell, der leverandør-ID er primærnøkkel.
Hvis verdiene for cellene for unitPrice, quantityInStock og reorderLevel forblir faste, er Produkttabellen, som den er, virkelig i 3NF. Hvis disse verdiene vil endres, er produkttabellen, som den er, i 2NF. I denne delen av opplæringsserien antas det at disse verdiene forblir faste over tid.
Alle tabellene
Alle tabellene er nå i 3NF. De vises som:
Ansatte (ansatt-ID, navn, telefon, adresse, by, region, postnummer, land, fødselsdato, ansettelsesdato, utgivelsesdato)
Leverandører (leverandør-ID, navn, telefon, adresse, by, region, postnummer, land)
Produkter (produkt-ID, kategori-ID, leverandør-ID, produktnavn, enhetspris, kvantitet på lager, ombestillingsnivå)
Kategorier (kategori-ID, kategorinavn, beskrivelse)
Salg (salgs-ID, solgt dato, kunde-ID, ansatt-ID)
Salgsdetaljer(salgs-ID, produkt-ID, antall solgt, salgspris)
Kunder (kunde-ID, kundenavn, telefon, adresse, by, region, postnummer, land)
Bestillinger (ordre-ID, solgt dato, leverandør-ID, ansatt-ID)
Ordredetaljer(ordre-ID, produkt-ID, antall kjøpt, kostpris)
Opptil ni profesjonelle tabeller har blitt produsert fra bare én tabell produsert av nybegynnere for å forhindre redundans og regnskapsproblemer (avvik fra innsetting, sletting og oppdatering). Nybegynnerbordet alene ville føre til økonomiske tap.
Tester personalet
På dette tidspunktet burde alle ansatte, inkludert innehaveren, ha forstått 1NF, 2NF og 3NF. Imidlertid må de testes. Alle, 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 den er som følger:
Spørsmål: Ved å bruke regler for 1NF, 2NF og 3NF, bevis at alle de ni tabellene ovenfor allerede er i første normalform, andre normalform og tredje normalform. Kundene og leverandørene trenger ikke å være reelle enheter. Data for tabeller bør sikkerhetskopiere tabellnotasjonene.
Mens de gjennomfører testen, går du som databaseutvikler ut for å ta en matbit og en øl, for å komme tilbake etter en time.
Den nære og fjerne fremtiden
Mens du, databaseutvikleren, er ute, vurderer du også hvilke råd du skal gi dem hvis de alle består testen.
Mens du trente dem, og nå som de tar testen, har kunder også kommet og gått 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. Ekspeditørene (ansatte) er mellom 18 og 24 år. Alle egenskapene de trengte for å jobbe for innehaveren var: å være frisk, å kunne lese og skrive, å kunne addere, subtrahere, multiplisere og dividere , og for å kunne bruke datamaskinen og Internett.
Når en tabell er i 3NF, er de fleste sårbarhetene fjernet fra databasen. Mange kommersielle databaser går ikke lenger enn 3NF, og firmaene eller selskapene er komfortable.
Så hvis alle består testen, vil du be funksjonærene om å gå og fortsette å jobbe. Du vil også råde dem til å spare deler av lønnen, slik at de kan eie nærbutikkene sine. Du fortsetter i morgen for å kun trene 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 merker skriptene deres. En god nyhet! De alle, inkludert innehaveren, har 100 % hver. Hurra! Det er utmerket!
Så gratulerer til dere alle: læreren og elevene.
Det er ingenting annet å gjøre i denne opplæringen enn å konkludere.
Konklusjon
En tabell er i First Normal Form, hvis den ikke bryter med noen av følgende regler:
- Alle kolonnene i en tabell skal ha unike overskriftsnavn.
- Hver celle må bare ha en enkelt verdi.
- Verdier lagret i en kolonne skal være av samme type.
- Radene skal være distinkte.
- Rekkefølgen på kolonnene eller radene spiller ingen rolle.
En tabell er i Second Normal Form, hvis den ikke bryter med noen av følgende regler:
- Tabellen må allerede være i First Normal Form.
- Det må ikke være noen delvis avhengighet.
En tabell er i tredje normalform, hvis den ikke bryter med noen av følgende regler:
- Den må allerede være i den andre normalformen.
- Og den 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 på jobb og bli på stasjonene sine som standard.
Du avtaler kun med innehaveren, som skal finne sted på kontoret hans i morgen for opplæring på 4NF og 5NF.
