Aceasta este partea a treia a seriei, Cinci forme normale. Titlurile primelor două părți (tutoriale) sunt First Normal Form, urmate de Second Normal Form. În această parte a seriei, este explicată a treia formă normală.
Explicația urmează povestea: un tată a murit și a lăsat niște bani fiului său. Fiul a decis să investească banii într-un magazin de proximitate. Un magazin de proximitate, cunoscut și ca un magazin de proximitate, este o mică afacere de vânzare cu amănuntul care primește articole de zi cu zi de la furnizori și le vinde clienților individuali din cartier.
În acest moment, magazinul este deja stocat, iar unele vânzări au fost deja făcute. Fiul, care este proprietarul afacerii, are niște angajați, care sunt numiți funcționari în acest tutorial. Proprietarul și orice angajat pot primi provizii și pot face vânzări după înregistrarea produselor.
Cu toate acestea, înainte de începerea magazinului, nici proprietarul, nici angajații nu știau nimic despre formularele normale. Deci, ei înregistrau totul ca tranzacții într-un singur tabel și un caiet de exerciții. Nu aveau computer.
Tu, cititorul, ai finalizat cele cinci părți ale acestei serii de tutoriale; acum sunteți dezvoltator de baze de date. Proprietarul magazinului este prietenul tău. Ați vizitat magazinul în urmă cu două zile și ați instruit proprietarul și funcționarii să producă o masă în prima sa formă normală. De asemenea, ați vizitat magazinul ieri și i-ați instruit despre cum să creeze un tabel în a doua formă normală din prima formă normală.
Astăzi, tocmai ați ajuns la magazin pentru o vizită pentru a-i instrui despre cum să producă o masă în a treia formă normală din a doua formă normală. Toate tabelele pe care le au în prezent sunt în a doua formă normală. Tabelele (după nume și titlurile coloanelor) sunt:
Produse (ID produs, ID categorie, produs)
Categorii (ID categorie, categorie)
Vânzări (ID vânzări, client, angajat, dată)
Detalii vânzare (saleID, productID, numberSold, selling Price)
Comenzi (ID comandă, furnizor, angajat, dată)
Detalii comandă (ID comandă, ID produs, număr cumpărat, preț preț)
Tastele simple sau compuse sunt subliniate.
După ce a rezumat ceea ce a fost predat în ultimele două zile și înainte de a putea face ceva, proprietarul întreabă:
„Dar numerele de telefon, adresele etc., pentru clienți și angajați?
Dar cantitatea din stoc, nivelul de recomandă etc., pentru produse?
Au nevoie de propriile lor mese separate sau ar trebui să fie montate în mesele actuale?”
Tu, dezvoltatorul bazei de date, răspunzi:
„Felicitări, proprietar! Ați introdus indirect problema a treia formă normală.”
Tu continui.
Alte coloane necesare
Alte coloane necesare sunt adăugate mai întâi la tabelele anterioare, care sunt în 1NF și 2NF. Unele dintre numele coloanelor anterioare sunt modificate.
Tabelul Categorii trebuie să aibă cel puțin următoarele coloane:
Categorii (ID categorie, Nume categorie, descriere)
Descrierea este un scurt paragraf care descrie categoria. Acest tabel de categorii este deja în 1NF, 2NF și 3NF. 3NF este explicat mai jos:
Tabelul Produse ar trebui să aibă cel puțin următoarele coloane:
Produse (ID produs, ID categorie, ID furnizor, ProductName, UnitPrice, quantityInStock, reorderLevel)
Pe măsură ce fiecare produs este vândut, se va atinge un nivel scăzut (număr) de produse atunci când produsul trebuie să fie recomandat, astfel încât clienții nu ar trebui să vină la magazin și să nu aibă produsul. O astfel de absență nu este bună pentru afaceri. cantitateInStoc este numărul unui anumit produs în stoc. Aceasta include ceea ce este în magazin și ce este pe raft.
categoryID și providerID sunt chei străine. De aceea au subliniat liniuță în loc de subliniere unică. Cheia străină este explicată mai jos. În partea anterioară a seriei (a doua formă normală), categoryID făcea parte din cheia primară cu o singură subliniere datorită modului în care s-a ajuns. Cu toate acestea, din explicația de mai jos, ar fi clar că categoryID ar trebui să fie o cheie străină (cu o liniuță subliniată).
Acest tabel de produse este deja în 1NF, 2NF și 3NF. Vedeți de ce este în 3NF mai jos:
Cel puțin, tabelul SaleDetails ar trebui să aibă următoarele coloane:
Detalii vânzare (saleID, productID, unitSellingPrice, cantitate, discount)
Valoarea reducerii este de așteptat să fie zero de cele mai multe ori. Reducerea este reducerea pe care magazinul o oferă unui client.
Cel puțin, tabelul OrderDetails ar trebui să aibă următoarele coloane:
Detalii comandă (ID comandă, ID produs, preț unitar, cantitate, reducere)
Valoarea reducerii este de așteptat să fie zero de cele mai multe ori. Reducerea aici este reducerea pe care furnizorul o oferă magazinului.
După cum se vede mai jos, tabelul Produse poate fi luat în considerare în 2NF sau 3NF. Tabelele de vânzări și comenzi au problema 3NF. Doar Tabelul de vânzări va fi folosit pentru a explica problema și soluția. Tabelul 3NF pentru Comenzi și Tabelul Produselor urmează un raționament similar și ar fi doar citat.
În timp ce adăugați coloane, tabelul Vânzări ar fi:
Vânzări (saleID, dateSold clientNume, telefon, adresă, oraș, regiune, cod poștal, țara, angajat)
Șapte coloane au înlocuit coloana client din tabelul original. Deoarece clienții sunt oameni din cartier, celulele pentru coloanele oraș, regiune (stat), cod poștal și țară pot fi lăsate goale, deși nu sunt lăsate goale în acest articol.
Acest tabel de vânzări este încă în 2NF, deoarece atât regulile 1NF, cât și 2NF nu au fost încălcate. Cu toate acestea, trebuie realizat că într-un rând de tabel de vânzări, clientul (numele) a fost înlocuit cu șapte celule de rând de client.
Notă: o celulă de adresă are numărul casei, numele străzii sau al drumului și numele orașului, toate separate prin virgule. Un oraș poate fi considerat alcătuit din mai multe orașe. Deși virgulele separă aceste componente specifice șirului, ele formează o valoare de celulă și nu trei valori de celule.
Coloana angajat trebuie, de asemenea, să fie înlocuită cu șapte astfel de coloane. Cu toate acestea, acest lucru nu se face în acest tutorial pentru a economisi timp și spațiu de predare. Deci, un tabel de vânzări cu date poate fi:
Tabel de vânzări – 2NF – Fără ID client
Coloana de tip de date SaleID este un număr întreg sau, mai bine, incrementare automată. Tipul de date al coloanei dateSold este o dată și nu un număr, deoarece are caracterul „/”, care nu este o cifră. Tipul de date pentru restul coloanelor, inclusiv coloana telefon, este șir (sau text). Valoarea telefonului are caracterul „-”, care nu este o cifră.
Rețineți că pentru fiecare rând, client (nume), așa cum a fost în partea anterioară a seriei, a fost înlocuit cu șapte celule, dintre care una este încă numele clientului. Aceasta înseamnă că datele clienților sunt o entitate. În prezent, numele-client identifică celelalte șase date la rând. Dacă acest tabel este programat, va fi convenabil să identificați entitatea client din fiecare rând cu un număr întreg (nu auto-incrementare). În acest caz, o coloană customerID ar trebui să precedă customerName. Tabelul anterior devine:
Tabel de vânzări – 2NF – Cu ID client
Există trei ID-uri de client: 1, 2 și 3, 1 aparând de cinci ori pentru John Smith, 2 aparând de două ori pentru James Taylor și 3 aparând o dată pentru Susan Wright.
Rețineți că unele ID-uri de client și dependenții acestora se repetă.
Reguli pentru a treia formă normală
Un tabel este în a treia formă normală dacă respectă următoarele reguli:
- Ar trebui să fie deja în a doua formă normală.
- Și nu ar trebui să aibă dependență tranzitivă.
Apoi unul dintre funcționari (angajați) întreabă: „Ce este o dependență tranzitivă?”. Și tu, dezvoltatorul bazei de date, răspundeți: „Aceasta este o întrebare bună!”
Dependența tranzitivă
Este adevărat că într-un rând, SaleID identifică toate valorile din rând; cu toate acestea, customerID identifică cele șapte valori ale sale de date, dar nu identifică restul valorilor identificate de SaleID în acel rând. Cu alte cuvinte, SaleID depinde de zece valori de celule din fiecare rând. Cu toate acestea, customerID depinde de șapte valori de celule din același rând, dar customerID nu depinde de SaleID și de celelalte valori de care depinde SaleID.
O astfel de dependență pentru ID-ul clientului este dependență tranzitivă. Iar customerID se numește cheie străină și este subliniat liniuță în această serie de tutoriale, Cele cinci forme normale.
Să presupunem că un atribut non-prim (valoarea celulei non-primare) depinde de alte atribute non-prime, iar atributul non-prim în cauză (de exemplu, customerID și dependenții acestuia) nu depinde de cheia primară și de restul celulei valorile din rând. Atunci aceasta este dependența tranzitivă.
Tabelul de vânzări anterior cu cheia externă și dependenții acesteia ar cauza probleme de contabilitate (anomalii).
Tabel de vânzări De la 2NF la 3NF
Pentru a rezolva problema pusă de cheia externă și dependențele acesteia, eliminați cheia externă și dependențele sale, pentru a forma un nou tabel fără repetări. Cu toate acestea, chiar dacă cheia străină nu depinde de cheia primară, cheia primară depinde de cheia străină. Deci, o copie a cheii externe trebuie să rămână în tabelul părinte. Noul tabel de vânzări, în acest moment, este compatibil cu 1NF, 2NF și 3NF; este o masă părinte. Noul tabel copil din tabelul de vânzări anterior este, de asemenea, compatibil cu 1NF, 2NF și 3NF. Numele tabelului copil cu cheie străină și dependenții acesteia este Clienți. Dacă nu poate fi găsit un nume potrivit, atunci ceva nu a mers prost cu analiza. Noul tabel de vânzări din 3NF este:
Tabelul final de vânzări în 3NF
Acest tabel din 3NF are același număr de rânduri ca și cel din 2NF, dar cu mai puține coloane.
Notația de tabel pentru acest tabel final de vânzări în 3NF este:
Vânzări (saleID, dateSold, customerID, employeeID)
SaleID este cheia primară cu o singură subliniere. customerID este o cheie străină, cu o liniuță subliniată. employeeID este, de asemenea, o cheie străină cu o liniuță subliniată. Rețineți că situația angajaților din tabelul de vânzări din 2NF este aceeași cu situația clientului. ID-ul angajatului și propriile sale dependențe trebuie să fie extrase pentru a forma un alt tabel; rămâne o copie a ID-ului angajatului.
Notă: salesID, customerID și employeeID nu formează o cheie compusă. SaleID depinde de customerID și employeeID.
Relația dintre salesID și customerID este multi-la-unu.
Tabelul clienților din 3NF
Acest tabel are trei rânduri în loc de 9 rânduri în tabelul 2NF Sales. În acest tabel, customerID este o cheie primară. Este la fel ca cheia externă din tabelul Vânzări, dar fără repetări. Cheia externă din tabelul Vânzări și cheia primară din tabelul Client leagă ambele tabele.
Rândurile repetate din tabelul Client au fost eliminate pentru a nu încălca 1NF.
După cum poate vedea cititorul, punerea unui tabel în 3NF ar rezolva și problema rândurilor repetate (redundanță).
Notația de tabel pentru Tabelul clienți este:
Clienți (ID client, nume client, telefon, adresă, oraș, regiune, cod poștal, țară)
Tabelul cu produse revizuit
Tabelul produselor prezentat mai sus sub formă de notație este:
Produse (ID produs, ID categorie, ID furnizor, ProductName, UnitPrice, quantityInStock, reorderLevel)
Cheia primară aici este productID. categoryID și providerID sunt chei străine. Similar cu tabelul Client, există un tabel Categorii, unde categoryID este cheia primară și există un tabel Supplier, unde furnizorID este cheia primară.
Dacă valorile pentru celulele pentru unitPrice, quantityInStock și reorderLevel vor rămâne fixe, atunci tabelul Produse, așa cum este, este cu adevărat în 3NF. Dacă aceste valori se vor schimba, atunci tabelul Produse, așa cum este, este în 2NF. În această parte a seriei de tutoriale, se presupune că acele valori rămân fixe în timp.
Toate Tabelele
Toate mesele sunt acum în 3NF. Ele sunt prezentate ca:
Angajații (ID angajat, nume, telefon, adresă, oraș, regiune, cod poștal, țară, data nașterii, data angajării, data lansării)
Furnizori (ID furnizor, nume, telefon, adresă, oraș, regiune, cod poștal, țară)
Produse (ID produs, ID categorie, ID furnizor, ProductName, UnitPrice, quantityInStock, reorderLevel)
Categorii (ID categorie, Nume categorie, descriere)
Vânzări (saleID, dateSold, customerID, employeeID)
Detalii vânzare (saleID, productID, numberSold, selling Price)
Clienți (ID client, nume client, telefon, adresă, oraș, regiune, cod poștal, țară)
Comenzi (ID comandă, data Vândut, ID furnizor, ID angajat)
Detalii comandă (ID comandă, ID produs, număr cumpărat, preț preț)
Până la nouă tabele profesionale au fost produse dintr-un singur tabel produs de începători pentru a preveni redundanța și problemele contabile (anomalii de la inserare, ștergere și actualizare). Doar masa începătorilor ar duce la pierderi financiare.
Testarea personalului
În acest moment, toți angajații, inclusiv proprietarul, ar fi trebuit să înțeleagă 1NF, 2NF și 3NF. Cu toate acestea, ele trebuie testate. Toți, inclusiv proprietarul, vor sta în locuri diferite și vor completa testul. Testul constând dintr-o întrebare, va dura o oră și este după cum urmează:
Întrebare: Folosind regulile pentru 1NF, 2NF și 3NF, dovediți că toate cele nouă tabele de mai sus sunt deja în prima formă normală, a doua formă normală și a treia formă normală. Clienții și furnizorii nu trebuie să fie entități reale. Datele pentru tabele ar trebui să facă copii de rezervă pentru notațiile din tabel.
În timp ce ei termină testul, tu, în calitate de dezvoltator de baze de date, ieși să bei o gustare și o bere, pentru a te întoarce după o oră.
Viitorul apropiat și îndepărtat
În timp ce tu, dezvoltatorul bazei de date, ești afară, te gândești și la ce sfaturi să le oferi dacă toți trec testul.
De asemenea, în timp ce îi antrenați, iar acum că fac testul, clienții au venit și au plecat fără să fie serviți. Acest lucru nu este bun pentru afaceri, iar tu, dezvoltatorul bazei de date, știi asta. Unii clienți pot merge la magazinele concurenței și nu se mai întorc niciodată.
Tu, dezvoltatorul bazei de date, ai 30 de ani. Proprietarul, în calitate de prieten al tău, are și el 30 de ani. Funcționarii (angajații) au vârste cuprinse între 18 și 24 de ani. Toate calitățile de care aveau nevoie pentru a lucra pentru proprietar erau: să fie sănătoși, să știe să citească și să scrie, să poată aduna, scădea, înmulți și împărți. , și pentru a putea folosi computerul și Internetul.
Când un tabel este în 3NF, majoritatea vulnerabilităților au fost eliminate din baza de date. Multe baze de date comerciale nu depășesc 3NF, iar firmele sau companiile sunt confortabile.
Deci, dacă toți trec testul, veți cere funcționarilor să meargă și să continue lucrul. De asemenea, îi veți sfătui să economisească părți din salarii, astfel încât să-și poată deține magazinele de proximitate. Veți continua mâine să instruiți numai proprietarul în 4NF și 5NF. Cu cunoștințele despre 4NF și 5NF, toate vulnerabilitățile cunoscute sunt eliminate.
Evaluare
După o oră, tu, dezvoltatorul bazei de date, revii. Le marcați scenariile. O veste excelentă! Toți, inclusiv proprietarul, au 100% fiecare. Ura! Asta este excelent!
Așadar, vă felicit tuturor: profesorului și elevilor.
Nu mai este nimic de făcut în acest tutorial decât să închei.
Concluzie
Un tabel este în prima formă normală, dacă nu încalcă niciuna dintre următoarele reguli:
- Toate coloanele dintr-un tabel ar trebui să aibă nume de antet unice.
- Fiecare celulă trebuie să aibă o singură valoare.
- Valorile stocate într-o coloană trebuie să fie de același tip.
- Rândurile ar trebui să fie distincte.
- Ordinea coloanelor sau a rândurilor nu contează.
Un tabel este în a doua formă normală, dacă nu încalcă niciuna dintre următoarele reguli:
- Tabelul trebuie să fie deja în prima formă normală.
- Nu trebuie să existe dependență parțială.
Un tabel este în a treia formă normală, dacă nu încalcă niciuna dintre următoarele reguli:
- Trebuie să fie deja în a doua formă normală.
- Și nu trebuie să aibă dependență tranzitivă.
Dumneavoastră, dezvoltatorul bazei de date, spuneți funcționarilor că au învățat suficient. Le oferiți sfaturi și le cereți să se întoarcă la serviciu și să rămână la stațiile lor în mod implicit.
Stabiliți o întâlnire doar cu proprietarul, care urmează să aibă loc mâine în biroul lui pentru antrenament pe 4NF și 5NF.
