Detta är del tre av serien, Fem normala former. Titlarna på de två första delarna (handledningar) är Första Normalform, följt av Andra Normalform. I den här delen av serien förklaras Third Normal Form.
Förklaringen följer historien: En pappa har dött och har lämnat lite pengar till sin son. Sonen bestämde sig för att investera pengarna i en närbutik. En närbutik, även känd som en närbutik, är en liten detaljhandel som tar emot vardagsartiklar från leverantörer och säljer dem till enskilda kunder i grannskapet.
Vid det här laget är butiken redan fylld, och vissa försäljningar har redan gjorts. Sonen, som är företagets ägare, har några anställda, som kallas kontorister i den här handledningen. Innehavaren och alla anställda kan ta emot förnödenheter och göra försäljning efter att ha registrerat produkterna.
Innan butiken startade visste dock varken innehavaren eller de anställda något om normala former. Så de registrerade allt som transaktioner i en tabell och en övningsbok. De hade ingen dator.
Du, läsaren, har slutfört de fem delarna av denna handledningsserie; du är nu en databasutvecklare. Innehavaren av närbutiken är din vän. Du besökte butiken för två dagar sedan och utbildade innehavaren och kontoristerna i att ta fram ett bord i dess första normala form. Du besökte även butiken igår och utbildade dem i hur man skapar en tabell i den andra normalformen från den första normalformen.
Idag har du precis kommit till butiken för ett besök för att utbilda dem i hur man tar fram ett bord i den tredje normalformen från den andra normalformen. Alla tabeller de har för närvarande är i den andra normala formen. Tabellerna (efter namn och kolumnrubriker) är:
Produkter (produkt-ID, kategori-ID, produkt)
Kategorier (kategori-ID, kategori)
Försäljning (försäljnings-ID, kund, anställd, datum)
Försäljningsdetaljer(försäljnings-ID, produkt-ID, nummerSålt, försäljningspris)
Beställningar (order-ID, leverantör, anställd, datum)
Orderdetaljer(order-ID, produkt-ID, antal köpt, kostnadspris)
De enkla eller sammansatta tangenterna är understrukna.
Efter att ha sammanfattat vad som lärdes ut under de två föregående dagarna och innan du kunde göra något, frågar innehavaren:
”Vad sägs om telefonnummer, adresser etc. till kunder och anställda?
Vad sägs om kvantitet i lager, beställningsnivå etc. för produkter?
Behöver de sina egna separata bord, eller ska de passas in i de nuvarande borden?”
Du, databasutvecklaren, svarar:
'Grattis, innehavaren! Du har indirekt introducerat frågan om tredje normalformen.”
Du fortsätter.
Andra nödvändiga kolumner
Andra nödvändiga kolumner läggs först till i de föregående tabellerna, som finns i 1NF och 2NF. Några av de tidigare kolumnnamnen har ändrats.
Som ett minimum bör kategoritabellen ha följande kolumner:
Kategorier (kategori-ID, kategorinamn, beskrivning)
Beskrivningen är ett kort stycke som beskriver kategorin. Denna kategoritabell finns redan i 1NF, 2NF och 3NF. 3NF förklaras nedan:
Som ett minimum bör produkttabellen ha följande kolumner:
Produkter (produkt-ID, kategori-ID, leverantörs-ID, produktnamn, enhetspris, kvantitet i lager, återbeställningsnivå)
Eftersom varje produkt säljs kommer en låg nivå (antal) av produkterna att nås när produkten måste beställas om, så kunder ska inte komma till butiken och inte ha produkten. Sådan frånvaro är inte bra för verksamheten. quantityInStock är numret på en viss produkt i lager. Detta inkluderar vad som finns i butiken och vad som finns i hyllan.
kategori-ID och leverantörs-ID är främmande nycklar. Det är därför de har streck understrykningar istället för enkel understrykning. Främmande nyckel förklaras nedan. I den föregående delen av serien (Second Normal Form) var kategori-ID en del av primärnyckeln med en enda understrykning på grund av hur man kom fram till den. Men från förklaringen nedan skulle det vara tydligt att kategori-ID:t bör vara en främmande nyckel (med ett streck understruket).
Denna produkttabell finns redan i 1NF, 2NF och 3NF. Se varför det finns i 3NF nedan:
Som ett minimum bör SaleDetails-tabellen ha följande kolumner:
Försäljningsdetaljer(försäljnings-ID, produkt-ID, enhetsförsäljningspris, kvantitet, rabatt)
Diskonteringsvärdet förväntas vara noll för det mesta. En rabatt är den rabatt butiken ger en kund.
Som ett minimum bör OrderDetails-tabellen ha följande kolumner:
Orderdetaljer(order-ID, produkt-ID, enhetskostnadspris, kvantitet, rabatt)
Diskonteringsvärdet förväntas vara noll för det mesta. Rabatten här är rabatten leverantören ger butiken.
Som framgår nedan kan produkttabellen övervägas i 2NF eller 3NF. Försäljnings- och ordertabellerna har frågan om 3NF. Endast försäljningstabellen kommer att användas för att förklara problemet och lösningen. 3NF för ordertabell och produkttabell följer liknande resonemang och skulle bara citeras.
När du lägger till kolumner blir tabellen Försäljning:
Försäljning (försäljnings-ID, datum såld kundnamn, telefon, adress, stad, region, postnummer, land, anställd)
Sju kolumner har ersatt kundkolumnen i den ursprungliga tabellen. Eftersom kunderna är människor i grannskapet kan cellerna för kolumnerna stad, region(stat), postnummer och land lämnas tomma, även om de inte lämnas tomma i den här artikeln.
Denna försäljningstabell finns fortfarande i 2NF eftersom både 1NF- och 2NF-reglerna inte har brutits. Det bör dock inses att i en försäljningstabellrad har kunden (namn) ersatts av sju kundradceller.
Obs: en adresscell har husnummer, namn på gata eller väg och namn på staden, alla avgränsade med kommatecken. En stad kan anses bestå av flera städer. Även om kommatecken separerar dessa specifika strängkomponenter, bildar de ett cellvärde och inte tre cellvärden.
Medarbetarkolumnen måste också ersättas med sju sådana kolumner. Det görs dock inte i den här handledningen för att spara tid och utrymme för undervisningen. Så en försäljningstabell med data kan vara:
Försäljningstabell – 2NF – Utan kund-ID
Datatypen SaleID-kolumnen är ett heltal eller, bättre, automatisk ökning. Datatypen för dateSold-kolumnen är ett datum och inte ett nummer eftersom det har tecknet '/', vilket inte är en siffra. Datatypen för resten av kolumnerna, inklusive telefonkolumnen, är sträng (eller text). Telefonvärdet har tecknet '-', vilket inte är en siffra.
Observera att för varje rad har kund (namn), som var i föregående del av serien, ersatts av sju celler, varav en fortfarande är kundnamn. Det betyder att kunddata är en enhet. För närvarande identifierar kundnamnet sina andra sex data i rad. Om denna tabell är programmerad är det bekvämt att identifiera kundentiteten i varje rad med ett heltal (inte automatisk ökning). I så fall bör en kundID-kolumn föregå kundnamnet. Den föregående tabellen blir:
Försäljningstabell – 2NF – Med kund-ID
Det finns tre kund-ID: 1, 2 och 3, där 1 förekommer fem gånger för John Smith, 2 inträffar två gånger för James Taylor och 3 inträffar en gång för Susan Wright.
Observera att vissa kund-ID och deras beroende upprepas.
Regler för tredje normalformen
En tabell är i tredje normalform om den följer följande regler:
- Det borde redan vara i den andra normala formen.
- Och det borde inte ha transitivt beroende.
Sedan frågar en av tjänstemännen (anställda) 'Vad är ett transitivt beroende?'. Och du, databasutvecklaren, svarar: 'Det är en bra fråga!'
Transitivt beroende
Det är sant att i en rad identifierar SaleID alla värden i raden; kund-ID identifierar dock dess sju datavärden men identifierar inte resten av värdena som identifieras av SaleID på den raden. Med andra ord beror SaleID på tio cellvärden i varje rad. Kund-ID beror dock på sju cellvärden i samma rad, men kund-ID beror inte på SaleID och de andra värden som SaleID beror på.
Sådant beroende för kund-ID är transitivt beroende. Och kund-ID kallas en främmande nyckel och är streck understruket i denna handledningsserie, De fem normala formerna.
Antag att ett icke-primärt attribut (icke-primärt cellvärde) beror på andra icke-primära attribut, och att det icke-primära attributet i fråga (t.ex. kund-ID och dess beroende) inte beror på primärnyckeln och resten av cellen värden i raden. Då är det transitivt beroende.
Den tidigare försäljningstabellen med den främmande nyckeln och dess beroende skulle orsaka redovisningsproblem (avvikelser).
Försäljningstabell Från 2NF till 3NF
För att lösa problemet med den främmande nyckeln och dess dependees, ta bort den främmande nyckeln och dess dependees, för att bilda en ny tabell utan upprepningar. Men även om den främmande nyckeln inte är beroende av den primära nyckeln, beror den primära nyckeln på den främmande nyckeln. Så en kopia av den främmande nyckeln måste finnas kvar i den överordnade tabellen. Den nya försäljningstabellen är vid denna tidpunkt 1NF, 2NF och 3NF-kompatibel; det är ett föräldrabord. Den nya underordnade tabellen från den tidigare försäljningstabellen är också 1NF-, 2NF- och 3NF-kompatibel. Namnet på den underordnade tabellen med främmande nyckel och dess beroende är kunder. Om ett passande namn inte kan hittas, så har något gått fel med analysen. Den nya försäljningstabellen i 3NF är:
Slutlig försäljningstabell i 3NF
Den här tabellen i 3NF har samma antal rader som den i 2NF men med färre kolumner.
Tabellnotationen för denna sista försäljningstabell i 3NF är:
Försäljning(försäljnings-ID, datumSåld, kund-ID, anställd-ID)
SaleID är den primära nyckeln med en enda understrykning. customerID är en främmande nyckel, med ett streck understruket. anställd-ID är också en främmande nyckel med ett streck understruket. Observera att personalsituationen i tabellen Försäljning i 2NF är densamma som kundsituationen. Medarbetar-ID och dess egna anhöriga måste dras av för att bilda en annan tabell; en kopia av anställds-ID finns kvar.
Obs: försäljnings-ID, kund-ID och anställd-ID utgör inte en sammansatt nyckel. saleID är beroende av kund-ID och anställd-ID.
Relationen mellan försäljnings-ID och kund-ID är många-till-en.
Kundbordet i 3NF
Den här tabellen har tre rader istället för 9 rader i tabellen 2NF Sales. I den här tabellen är kund-ID en primärnyckel. Det är samma som den främmande nyckeln i försäljningstabellen, men utan upprepningar. Den främmande nyckeln i tabellen Försäljning och primärnyckeln i tabellen Kund länkar båda tabellerna.
De upprepade raderna i kundtabellen har tagits bort för att inte bryta mot 1NF.
Som läsaren kan se skulle en tabell i 3NF också lösa problemet med upprepade rader (redundans).
Tabellnotationen för Kundtabellen är:
Kunder (kund-ID, kundnamn, telefon, adress, stad, region, postnummer, land)
Produkttabellen återbesökt
Produkttabellen ovan i notationsform är:
Produkter (produkt-ID, kategori-ID, leverantörs-ID, produktnamn, enhetspris, kvantitet i lager, återbeställningsnivå)
Den primära nyckeln här är productID. kategori-ID och leverantörs-ID är främmande nycklar. I likhet med Customer-tabellen finns det en kategoritabell, där kategori-ID är primärnyckeln, och det finns en leverantörstabell, där leverantörs-ID är primärnyckel.
Om värdena för cellerna för unitPrice, quantityInStock och reorderLevel kommer att förbli fixerade, så är tabellen Products, som den är, verkligen i 3NF. Om dessa värden kommer att ändras, är tabellen Produkt, som den är, i 2NF. I den här delen av handledningsserien antas det att dessa värden förblir fixerade över tiden.
Alla tabeller
Alla tabeller är nu i 3NF. De visas som:
Anställda (anställd-ID, namn, telefon, adress, stad, region, postnummer, land, födelsedatum, anställningsdatum, releasedatum)
Leverantörer (leverantörs-ID, namn, telefon, adress, stad, region, postnummer, land)
Produkter (produkt-ID, kategori-ID, leverantörs-ID, produktnamn, enhetspris, kvantitet i lager, återbeställningsnivå)
Kategorier (kategori-ID, kategorinamn, beskrivning)
Försäljning(försäljnings-ID, datumSåld, kund-ID, anställd-ID)
Försäljningsdetaljer(försäljnings-ID, produkt-ID, nummerSålt, försäljningspris)
Kunder (kund-ID, kundnamn, telefon, adress, stad, region, postnummer, land)
Beställningar (order-ID, datumSålt, leverantörs-ID, anställd-ID)
Orderdetaljer(order-ID, produkt-ID, antal köpt, kostnadspris)
Upp till nio professionella tabeller har producerats från bara en tabell producerad av nybörjare för att förhindra redundans och redovisningsproblem (avvikelser från infogning, radering och uppdatering). Bara nybörjarbordet skulle leda till ekonomiska förluster.
Testar personalen
Vid denna tidpunkt borde alla anställda, inklusive innehavaren, ha förstått 1NF, 2NF och 3NF. De måste dock testas. Alla, inklusive innehavaren, kommer att sitta på olika platser och genomföra testet. Testet som består av en fråga kommer att ta en timme och det är som följer:
Fråga: Genom att använda regler för 1NF, 2NF och 3NF, bevisa att alla ovanstående nio tabeller redan finns i första normalform, andra normalform och tredje normalform. Kunderna och leverantörerna behöver inte vara verkliga enheter. Data för tabeller bör säkerhetskopiera tabellnotationerna.
Medan de genomför testet går du som databasutvecklare ut för att ta ett mellanmål och en öl, för att komma tillbaka efter en timme.
Den nära och avlägsna framtiden
Medan du, databasutvecklaren, är ute, funderar du också på vilka råd du ska ge dem om de alla klarar testet.
Dessutom, medan du tränade dem och nu när de gör testet, har kunderna kommit och gått utan att bli betjänade. Det är inte bra för affärerna, och det vet du som databasutvecklare. Vissa kunder kan gå till konkurrerande butiker och aldrig komma tillbaka.
Du, databasutvecklaren, är 30 år gammal. Innehavaren, som din vän, är också 30 år gammal. Tjänstemännen (anställda) är mellan 18 och 24 år. Alla egenskaper de behövde för att arbeta för innehavaren var: att vara frisk, att kunna läsa och skriva, att kunna addera, subtrahera, multiplicera och dividera , och för att kunna använda datorn och Internet.
När en tabell är i 3NF har de flesta sårbarheter tagits bort från databasen. Många kommersiella databaser går inte längre än 3NF, och företagen eller företagen är bekväma.
Så om alla klarar provet kommer du att be tjänstemännen att gå och fortsätta arbeta. Du kommer också att råda dem att spara delar av sina löner så att de kan äga sina närbutiker. Du kommer att fortsätta i morgon för att endast utbilda innehavaren i 4NF och 5NF. Med kunskap om 4NF och 5NF tas alla kända sårbarheter bort.
Utvärdering
Efter en timme kommer du, databasutvecklaren, tillbaka. Du markerar deras manus. En fantastisk nyhet! De alla, inklusive ägaren, har 100% vardera. hurra! Det är utmärkt!
Så grattis till er alla: läraren och eleverna.
Det finns inget annat att göra i denna handledning än att avsluta.
Slutsats
En tabell är i First Normal Form, om den inte bryter mot någon av följande regler:
- Alla kolumner i en tabell ska ha unika rubriknamn.
- Varje cell måste bara ha ett enda värde.
- Värden som lagras i en kolumn bör vara av samma typ.
- Raderna ska vara distinkta.
- Ordningen på kolumnerna eller raderna spelar ingen roll.
En tabell är i Second Normal Form, om den inte bryter mot någon av följande regler:
- Tabellen måste redan vara i First Normal Form.
- Det får inte finnas något partiellt beroende.
En tabell är i tredje normalform, om den inte bryter mot någon av följande regler:
- Det måste redan vara i den andra normala formen.
- Och det får inte ha transitivt beroende.
Du, databasutvecklaren, berätta för tjänstemännen att de har lärt sig tillräckligt. Du ger råd och ber dem att återgå till jobbet och stanna på sina stationer som standard.
Du bestämmer endast ett möte med innehavaren, som ska äga rum på hans kontor i morgon för utbildning i 4NF och 5NF.
