Normalizarea este o tehnică de proiectare a bazei de date, care este utilizată pentru a proiecta un tabel de baze de date relaționale până la o formă normală superioară. Procesul este progresiv, iar un nivel mai ridicat de normalizare a bazei de date nu poate fi atins decât dacă nivelurile anterioare au fost îndeplinite.
Asta înseamnă că, având date în formă neormalizată (cea mai puțin normalizată) și cu scopul de a atinge cel mai înalt nivel nivel de normalizare, primul pas ar fi să se asigure conformitatea cu prima formă normală, al doilea pas ar fi să se asigure că a doua formă normală este îndeplinită și așa mai departe în ordinea menționată mai sus, până când datele sunt conforme cu a șasea formă normală.
Cu toate acestea, este demn de remarcat faptul că formele normale dincolo de 4NF sunt în principal de interes academic, deoarece problemele pe care le există pentru a le rezolva apar rar în practică.
Vă rugăm să rețineți că datele din exemplul următor au fost concepute intenționat pentru a contrazice majoritatea formelor normale. În viața reală, este foarte posibil să poți sări peste unele dintre etapele de normalizare, deoarece tabelul nu conține nimic care să contrazică forma normală dată. De asemenea, se întâmplă în mod obișnuit că remedierea unei încălcări a unei forme normale remediază și o încălcare a unei forme normale superioare în proces. De asemenea, a fost ales un tabel pentru normalizare la fiecare pas, ceea ce înseamnă că la sfârșitul acestui exemplu de proces, ar putea exista încă unele tabele care nu satisfac cea mai înaltă formă normală.
Initial dataEdit
Lăsați un tabel de baze de date cu următoarea structură:
| Title | Author | Nationality Author | Format | Preț | Subiect | Pagini | Grosime | Editor | Țara editorului | Tip de publicație | ID gen | Nume gen |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Începând proiectarea și optimizarea bazei de date MySQL | Chad Russell | American | Hardcover | 49.99 | MySQL,
Baza de date, Design |
520 | Thick | Apress | SUA | E-book | 1 | Tutorial |
Presupunem în acest exemplu că fiecare carte are un singur autor.
1NFEdit satisfăcător
Pentru a satisface 1NF, valorile din fiecare coloană a unui tabel trebuie să fie atomice. În tabelul inițial, Subiectul conține un set de valori ale subiectului, ceea ce înseamnă că nu respectă.
O modalitate de a obține 1NF ar fi separarea duplicităților în mai multe coloane utilizând grupuri repetate Subiect:
| Titlu | Format | Autor | Naționalitatea autorului | Preț | Subiect 1 | Subiect 2 | Subiect 3 | Pagini | Grosime | Editor | Țara editorului | ID gen | Nume gen |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Începând proiectarea și optimizarea bazei de date MySQL | Hardcover | Chad Russell | American | 49.99 | MySQL | Baza de date | Design | 520 | Gros | Apress | SUA | 1 | Tutorial |
Deși acum tabelul respectă în mod formal 1NF (este atomic), problema cu această soluție este evidentă – dacă o carte are mai mult de trei subiecte, nu poate fi adăugată la baza de date fără a-i modifica structura.
Pentru a rezolva problema într-un mod mai elegant, este necesar să identificați entitățile reprezentate în tabel și să le separați în propriile tabele respective. În acest caz, ar rezulta tabele Cartea, subiectul și editorul:
| Titlu | Format | Autor | Naționalitate autor | Preț | Pagini | Grosime | ID gen | Nume gen | ID editor |
|---|---|---|---|---|---|---|---|---|---|
| Începutul MySQL Proiectare și optimizare baze de date | Hardcover | Chad Russell | American | 49.99 | 520 | Gros | 1 | Tutorial | 1 |
|
|
Simpla separare a datelor inițiale în mai multe tabele ar întrerupe conexiunea dintre date. Asta înseamnă că trebuie stabilite relațiile dintre tabelele nou introduse. Observați că coloana ID editor din tabelul cărții este o cheie străină care realizează relații multiple între o carte și un editor.
O carte se potrivește multor subiecte, precum și un subiect corespund multor cărți. Asta înseamnă, de asemenea, că trebuie definită o relație de la mulți la mulți, realizată prin crearea unui tabel de legături:
|
În loc de un tabel în formă neormalizată, există acum 4 tabele conforme cu 1NF.
2NFEdit satisfăcător
Tabelul Book are o cheie candidată (care este deci cheia principală), cheia compusă {Title, Format}. Luați în considerare următorul fragment de tabel:
| Titlu | Format | Autor | Naționalitatea autorului | Preț | Pagini | Grosime | ID gen | Nume gen | ID editor |
|---|---|---|---|---|---|---|---|---|---|
| Începând proiectarea și optimizarea bazei de date MySQL | Hardcover | Chad Russell | American | 49.99 | 520 | Gros | 1 | Tutorial | 1 |
| Începând proiectarea și optimizarea bazei de date MySQL | E-book | Chad Russell | American | 22.34 | 520 | Gros | 1 | Tutorial | 1 |
| Modelul relațional pentru gestionarea bazelor de date: versiunea 2 | E-book | EFCodd | Britanic | 13.88 | 538 | Gros | 2 | Științe populare | 2 |
| Modelul relațional pentru baza de date Ma nagement: Versiunea 2 | Volum broșat | EFCodd | Britanic | 39.99 | 538 | Gros | 2 | Știință populară | 2 |
Toate atributele care nu fac parte din cheia candidat depind de Titlu, dar numai Prețul depinde și de Format. Pentru a se conforma 2NF și a elimina duplicitățile, fiecare atribut care nu este candidat trebuie să depindă de întreaga cheie candidată, nu doar de o parte din ea.
Pentru a normaliza acest tabel, faceți din {Title} o cheie candidată (simplă) (cheia primară), astfel încât fiecare atribut non-cheie candidat să depindă de întreaga cheie candidat și eliminați prețul într-un tabel separat, astfel încât să se poată păstra dependența sa de format:
|
|
Acum, tabelul Book este conform cu 2NF.
3NFEdit satisfăcător
Tabelul Book are încă o dependență funcțională tranzitivă ({Author Nationality} este dependentă de {Author}, care este dependentă de {Title }). Există o încălcare similară pentru gen ({Genre Name} depinde de {Genre ID}, care depinde de {Title}). Prin urmare, tabelul Carte nu este în 3NF. Pentru a face acest lucru în 3NF, să folosim următoarea structură a tabelului, eliminând astfel dependențele funcționale tranzitive plasând {Author Nationality} și {Genre Name} în propriile tabele respective:
| Titlu | Autor | Pagini | Grosime | ID gen | ID editor |
|---|---|---|---|---|---|
| Începând proiectarea bazei de date MySQL și Optimizare | Chad Russell | 520 | Gros | 1 | 1 |
| Modelul relațional pentru gestionarea bazei de date: versiunea 2 | EFCodd | 538 | Gros | 2 | 2 |
|
| Author | Author Nationality |
|---|---|
| Chad Russell | American |
| EFCodd | Britanic |
| Gen re ID | Nume gen |
|---|---|
| 1 | Tutorial |
| 2 | Știință populară |
EKNFEdit satisfăcător
Forma normală cheie elementară (EKNF) se încadrează strict între 3NF și BCNF și nu este mult discutat în literatură. Se intenționează „să surprindă calitățile evidente atât ale 3NF, cât și ale BCNF” evitând în același timp problemele ambelor (și anume, faptul că 3NF este „prea iertător” și BCNF este „predispus la complexitatea calculațională”). nu este inclus în acest exemplu.
4NFEdit satisfăcător
Să presupunem că baza de date este deținută de o franciză de retailer de cărți care are mai mulți francizați care dețin magazine în locații diferite.Prin urmare, retailerul a decis să adauge un tabel care conține date despre disponibilitatea cărților în diferite locații:
| ID francizat | Titlu | Locație |
|---|---|---|
| 1 | Începând proiectarea și optimizarea bazei de date MySQL | California |
| 1 | Începând proiectarea și optimizarea bazei de date MySQL | Florida |
| 1 | Începând proiectarea și optimizarea bazei de date MySQL | Texas |
| 1 | Modelul relațional pentru gestionarea bazelor de date: versiunea 2 | California |
| 1 | Modelul relațional pentru gestionarea bazelor de date: versiunea 2 | Florida |
| 1 | Modelul relațional pentru gestionarea bazelor de date: versiunea 2 | Texas |
| 2 | Începând proiectarea și optimizarea bazei de date MySQL | California |
| 2 | Începând proiectarea și optimizarea bazei de date MySQL | Florida |
| 2 | Începutul proiectării și optimizării bazei de date MySQL | Texas |
| 2 | Modelul relațional pentru gestionarea bazei de date: versiunea 2 | California |
| 2 | Modelul relațional pentru gestionarea bazelor de date: versiunea 2 | Florida |
| 2 | Modelul relațional pentru gestionarea bazei de date: versiunea 2 | Texas |
| 3 | Începând proiectarea și optimizarea bazei de date MySQL | Texas |
Deoarece această structură a tabelului constă dintr-o cheie primară compusă, nu conține atribute care nu sunt cheie și este deja în BCNF (și, prin urmare, satisface și toate formele normale anterioare). Cu toate acestea, dacă presupunem că toate cărțile disponibile sunt oferite în fiecare zonă, am putea observa că titlul nu este legat fără echivoc de o anumită locație și, prin urmare, tabelul nu satisface 4NF.
Asta înseamnă că, pentru a satisface a patra formă normală, acest tabel trebuie descompus și:
|
|
||||||||||||
| ID francizat | Locație | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | California | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | California | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Acum, fiecare înregistrare este identificată fără ambiguități printr-o supercheie, de aceea 4NF este satisfăcut.
ETNFEdit satisfăcător
Să presupunem că francizații pot comanda și cărți de la diferiți furnizori. Relația să fie, de asemenea, supusă următoarei constrângeri:
- Dacă un anumit furnizor furnizează un anumit titlu
- și titlul este furnizat francizatului
- iar francizatul este furnizat de furnizor,
- apoi furnizorul furnizează titlul francizatului.
| ID furnizor | Titlu | ID francizat |
|---|---|---|
| 1 | Începând proiectarea și optimizarea bazei de date MySQL | 1 |
| 2 | Modelul relațional pentru gestionarea bazei de date: versiunea 2 | 2 |
| 3 | Learning SQL | 3 |
Acest tabel este în 4NF, dar codul furnizorului este egal cu îmbinarea proiecțiilor sale: {{ID furnizor, carte}, {carte, ID francizat}, {ID francizat, furnizor ID}}.Nicio componentă a dependenței de asociere nu este o supercheie (singura supercheie fiind întreaga antet), deci tabelul nu satisface ETNF și poate fi descompus în continuare:
|
|
|
Descompunerea produce conformitatea ETNF.
5NFEdit satisfăcător
Pentru a localiza un tabel care nu satisface 5NF, acesta este de obicei necesar pentru a examina detaliat datele. Să presupunem că tabelul din exemplul 4NF cu o mică modificare a datelor și să examinăm dacă îndeplinește 5NF:
| ID francizat | Titlu | Locație |
|---|---|---|
| 1 | Începând proiectarea și optimizarea bazei de date MySQL | California |
| 1 | Învățarea SQL | California |
| 1 | Modelul relațional pentru gestionarea bazelor de date: versiunea 2 | Texas |
| 2 | Modelul relațional pentru gestionarea bazei de date: versiunea 2 | California |
Dacă descompunem acest tabel, reducem redundanțele și obținem următoarele două tabele:
|
|
Ce se întâmplă dacă încercăm să ne alăturăm acestor tabele? Interogarea va returna următoarele date:
| ID francizat | Titlu | Locație |
|---|---|---|
| 1 | Începând proiectarea bazei de date MySQL și Optimizare | California |
| 1 | Învățare SQL | California |
| 1 | Modelul relațional pentru gestionarea bazelor de date: versiunea 2 | California |
| 1 | Modelul relațional pentru gestionarea bazelor de date: versiunea 2 | Texas |
| 1 | SQL de învățare | Texas |
| 1 | Începând proiectarea și optimizarea bazei de date MySQL | Texas |
| 2 | Modelul relațional pentru gestionarea bazei de date: versiunea 2 | California |
Aparent, JOIN returnează încă trei rânduri decât ar trebui – să încercăm să adăugăm un an tabelul pentru a clarifica relația.Încheiem cu trei tabele separate:
|
|
|
Ce va returna JOIN acum? De fapt, nu este posibil să vă alăturați acestor trei tabele. Asta înseamnă că nu a fost posibil să se descompună francizatul – Locația cărții fără pierderi de date, prin urmare tabelul satisface deja 5NF.
CJ Date a susținut că doar o bază de date din 5NF este cu adevărat „normalizată”.
DKNFEdit satisfăcător
Să vedem tabelul Book din exemplele anterioare și să vedem dacă îndeplinește forma normală a cheii de domeniu:
| Titlu | Pagini | Grosime | ID gen | ID editor | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Începând proiectarea și optimizarea bazei de date MySQL | 520 | Gros | 1 | 1 | ||||||||||||||||||||||||||
| Modelul relațional pentru gestionarea bazei de date: versiunea 2 | 538 | Thick | 2 | 2 | ||||||||||||||||||||||||||
| Learning SQL | 338 | Slim | 1 | 3 | ||||||||||||||||||||||||||
| SQL Cookbook | 636 | Gros | 1 | 3 |
|
|
În acest fel, încălcarea integrității domeniului a fost eliminată, iar tabelul este în DKNF.
Satisfăcător 6NFEdit
O definiție simplă și intuitivă a celei de-a șasea forme normale este aceea că „un tabel este în 6NF când rândul conține cheia primară și cel mult un alt atribut”.
Asta înseamnă, de exemplu, tabelul Publisher conceput în timpul creării 1NF
| Publisher_ID | Nume | Țară |
|---|---|---|
| 1 | Apress | SUA |
trebuie să fie mai departe descompus în două tabele:
|
|
Dezavantajul evident al 6NF este proliferarea tabelelor necesare pentru a reprezenta informațiile despre o singură entitate. Dacă un tabel din 5NF are o coloană cheie principală și N atribute, reprezentând aceleași informații în 6NF va necesita N tabele; actualizările pe mai multe câmpuri pentru o singură înregistrare conceptuală vor necesita actualizări pentru mai multe tabele; iar inserțiile și ștergerile vor necesita în mod similar operații pe mai multe tabele. Din acest motiv, în bazele de date destinate să răspundă nevoilor de procesare a tranzacțiilor online, 6NF nu ar trebui să fie utilizat.
Cu toate acestea, în depozitele de date, care nu permit actualizări interactive și care sunt specializate pentru interogări rapide pe volume mari de date , anumite SGBD utilizează o reprezentare internă 6NF – cunoscută sub numele de depozit de date coloane. În situațiile în care numărul valorilor unice ale unei coloane este cu mult mai mic decât numărul de rânduri din tabel, stocarea orientată pe coloane permite economii semnificative de spațiu prin comprimarea datelor. Stocarea pe coloane permite, de asemenea, executarea rapidă a interogărilor de gamă (de exemplu, afișează toate înregistrările în care o anumită coloană este între X și Y sau mai puțin decât X.)
În toate aceste cazuri, totuși, proiectantul bazei de date nu trebuie să efectueze manual normalizarea 6NF prin crearea de tabele separate. Unele SGBD specializate pentru depozitare, cum ar fi Sybase IQ, utilizează în mod implicit stocarea pe coloane, dar proiectantul vede în continuare doar un singur tabel cu mai multe coloane. Alte SGBD, cum ar fi Microsoft SQL Server 2012 și versiunile ulterioare, vă permit să specificați un „index de depozit de coloane” pentru un anumit tabel.
