Normalizarea ar trebui să facă parte din procesul de proiectare a bazei de date. Cu toate acestea, este dificil să separați procesul de normalizare de procesul de modelare ER, astfel încât cele două tehnici ar trebui utilizate simultan.
Utilizați o diagramă a relației entității (ERD) pentru a furniza imaginea de ansamblu sau vizualizarea macro a cerințelor și operațiunilor de date ale unei organizații. Aceasta este creată printr-un proces iterativ care implică identificarea entităților relevante, a atributelor și a relațiilor lor.
Procedura de normalizare se concentrează pe caracteristicile entităților specifice și reprezintă viziunea micro a entităților din cadrul ERD.
Ce este normalizarea?
Normalizarea este ramura teoriei relaționale care oferă informații despre proiectare. Este procesul de determinare a câtă redundanță există într-un tabel. Obiectivele normalizării sunt:
- Să fie capabilă să caracterizeze nivelul de redundanță într-o schemă relațională
- Să furnizeze mecanisme pentru transformarea schemelor pentru a elimina redundanța
Teoria normalizării se bazează puternic pe teoria dependențelor funcționale. Teoria normalizării definește șase forme normale (normal forms, NF). Fiecare formă normală implică un set de proprietăți de dependență pe care o schemă trebuie să le îndeplinească și fiecare formă normală oferă garanții cu privire la prezența și / sau absența anomaliilor de actualizare. Aceasta înseamnă că formele normale mai ridicate au o redundanță mai redusă și, ca urmare, mai puține probleme de actualizare.
Forme normale
Toate tabelele din orice bază de date pot fi într-una din formele normale pe care le vom discuta în continuare. În mod ideal, dorim doar redundanță minimă pentru PK la FK. Orice altceva ar trebui derivat din alte tabele. Există șase forme normale, dar ne vom uita doar la primele patru, care sunt:
- Prima formă normală (1NF)
- A doua formă normală (2NF)
- A treia formă normală (3NF)
- Forma normală Boyce-Codd (BCNF)
BCNF este rar folosită.
Prima formă normală (1NF)
În prima formă normală, numai valorile unice sunt permise la intersecția fiecărui rând și coloană; prin urmare, nu există grupuri care se repetă.
Pentru a normaliza o relație care conține un grup care se repetă, eliminați grupul care se repetă și formați două relații noi.
PK-ul noii relații este o combinație a PK-ului relației originale plus un atribut din relația nou creată pentru identificare unică.
Proces pentru 1NF
Vom folosi tabelul Student_Grade_Report de mai jos, dintr-o bază de date a școlii, ca exemplu pentru a explica procesul pentru 1NF.
Student_Grade_Report (StudentNo, StudentName, Major, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade)
- În tabelul Student Grade Report, grupul care se repetă este informația despre curs. Un student poate urma multe cursuri.
- Scoateți grupul care se repetă. În acest caz, sunt informațiile despre curs pentru fiecare student.
- Identificați PK pentru noul dvs. tabel.
- PK trebuie să identifice în mod unic valoarea atributului (StudentNo și CourseNo).
- După eliminarea tuturor atributelor legate de curs și student, rămâneți cu tabelul cursului studentului (StudentCourse).
- Tabelul student (Student) este acum în prima formă normală, cu grupul care repetă eliminat.
- Cele două noi tabele sunt prezentate mai jos.
Student (StudentNo, StudentName, Major)
StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade)
Cum se actualizează anomaliile 1NF
StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade)
- Pentru a adăuga un curs nou, avem nevoie de un student.
- Când informațiile despre curs trebuie actualizate, este posibil să avem incoerențe.
- Pentru a șterge un student, am putea șterge și informații critice despre un curs.
A doua formă normală (2NF)
Pentru a doua formă normală, relația trebuie să fie mai întâi în 1NF. Relația este automat în 2NF dacă și numai dacă PK cuprinde un singur atribut.
Dacă relația are un PK compozit, atunci fiecare atribut non-cheie trebuie să fie pe deplin dependent de întregul PK și nu de un subset al PK (adică nu trebuie să existe dependență parțială sau augmentare).
Proces pentru 2NF
Pentru a trece la 2NF, un tabel trebuie să fie mai întâi în 1NF.
- Tabelul Student este deja în 2NF deoarece are un PK cu o singură coloană.
- Când examinăm tabelul Student Course, vedem că nu toate atributele sunt pe deplin dependente de PK; în mod specific, toate informațiile despre curs. Singurul atribut care este pe deplin dependent este gradul.
- Identificați noul tabel care conține informațiile despre curs.
- Identificați PK pentru noul tabel.
- Cele trei noi tabele sunt prezentate mai jos.
Student (StudentNo, StudentName, Major)
CourseGrade (StudentNo, CourseNo, Grade)
CourseInstructor (CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation)
- Când adăugăm un nou instructor, avem nevoie de un curs.
- Actualizarea informațiilor despre curs poate duce la neconcordanțe pentru informațiile instructorului.
- Ștergerea unui curs poate șterge și informațiile instructorului.
A treia formă normală (3NF)
Pentru a fi în a treia formă normală, relația trebuie să fie în a doua formă normală. De asemenea, toate dependențele tranzitive trebuie eliminate; un atribut non-cheie poate să nu depindă funcțional de un alt atribut non-cheie.
Proces pentru 3NF
- Eliminați toate atributele dependente din relațiile tranzitive din fiecare tabel care are o relație tranzitivă.
- Creați tabele noi cu dependență eliminată.
- Verificați tabelele noi, precum și tabelele modificate pentru a vă asigura că fiecare tabel are un factor determinant și că niciun tabel nu conține dependențe inadecvate.
- Consultați cele patru tabele noi de mai jos.
Student (StudentNo, StudentName, Major)
CourseGrade (StudentNo, CourseNo, Grade)
Course (CourseNo, CourseName, InstructorNo)
Instructor (InstructorNo, InstructorName, InstructorLocation)
În acest stadiu, nu ar trebui să existe anomalii în a treia formă normală. Să vedem diagrama dependenței (Figura 12.1) pentru acest exemplu. Primul pas este eliminarea grupurilor care se repetă, după cum s-a discutat mai sus.
Student (StudentNo, StudentName, Major)
StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation, Grade)
Figura 12.1 Diagrama dependenței, de A. Watt.
Abrevierile utilizate în Figura 12.1 sunt după cum urmează:
- PD: dependență parțială (partial dependency)
- TD: dependență tranzitivă (transitive dependency)
- FD: dependență completă (full dependency) (Notă: FD reprezintă de obicei dependența funcțională. Folosirea FD ca abreviere pentru dependență completă este utilizată numai în Figura 12.1.)
Forma normală Boyce-Codd (BCNF)
Când un tabel are mai multe chei candidate, pot apărea anomalii chiar dacă relația este în 3NF. Forma normală Boyce-Codd este un caz special al 3NF. O relație este în BCNF dacă și numai dacă, fiecare determinant este o cheie candidată.
BCNF Exemplul 1
Luați în considerare următorul tabel (St_Maj_Adv).
Student_id | Major | Advisor |
111 | Physics | Smith |
111 | Music | Chan |
320 | Math | Dobbs |
671 | Physics | White |
803 | Physics | Smith |
Regulile semantice (reguli comerciale aplicate bazei de date) pentru acest tabel sunt:
- Fiecare student poate studia mai multe discipline.
- Pentru fiecare materie principală, un anumit student are un singur consilier.
- Fiecare materie principală are mai mulți consilieri.
- Fiecare consilier recomandă o singură materie principală.
- Fiecare consilier îi sfătuiește pe mai mulți studenți într-o materie principală.
Dependențele funcționale pentru acest tabel sunt enumerate mai jos. Prima este o cheie candidat; a doua nu este.
- Student_id, Major -> Advisor
- Consilier -> Major
Anomaliile pentru acest tabel includ:
- Ștergere – studentul șterge informațiile consilierului
- Inserare – un consilier nou are nevoie de un student
- Actualizare – neconcordanțe
Notă: Niciun atribut unic nu este o cheie candidat.
PK poate fi Student id, Major, sau Student id, Advisor.
Pentru a reduce relația St_Maj_Adv la BCNF, creați două tabele noi:
- St_Adv (Student id, Advisor)
- Adv_Maj (Advisor, Major)
Tabelul St_Adv
Student_id | Advisor |
111 | Smith |
111 | Chan |
320 | Dobbs |
671 | White |
803 | Smith |
Tabelul Adv_Maj
Advisor | Major |
Smith | Physics |
Chan | Music |
Dobbs | Math |
White | Physics |
BCNF Exemplul 2
Luați în considerare următorul tabel (Client_Interview).
ClientNo | InterviewDate | InterviewTime | StaffNo | RoomNo |
CR76 | 13-May-02 | 10.30 | SG5 | G101 |
CR56 | 13-May-02 | 12.00 | SG5 | G101 |
CR74 | 13-May-02 | 12.00 | SG37 | G102 |
CR56 | 1-July-02 | 10.30 | SG5 | G102 |
FD1 – ClientNo, InterviewDate –> InterviewTime, StaffNo, RoomNo (PK)
FD2 – staffNo, interviewDate, interviewTime –> clientNO (candidate key: CK)
FD3 – roomNo, interviewDate, interviewTime –> staffNo, clientNo (CK)
FD4 – staffNo, interviewDate –> roomNo
O relație este în BCNF dacă și numai dacă, fiecare determinant este o cheie candidat. Trebuie să creăm un tabel care încorporează primele trei FD-uri (tabelul Client_Interview2) și un alt tabel (tabelul StaffRoom) pentru al patrulea FD.
Tabelul Client_Interview2
ClientNo | InterviewDate | InterViewTime | StaffNo |
CR76 | 13-May-02 | 10.30 | SG5 |
CR56 | 13-May-02 | 12.00 | SG5 |
CR74 | 13-May-02 | 12.00 | SG37 |
CR56 | 1-July-02 | 10.30 | SG5 |
Tabelul StaffRoom
StaffNo | InterviewDate | RoomNo |
SG5 | 13-May-02 | G101 |
SG37 | 13-May-02 | G102 |
SG5 | 1-July-02 | G102 |
Normalizare și proiectare baze de date
În timpul procesului de normalizare a proiectării bazei de date, asigurați-vă că entitățile propuse îndeplinesc forma normală necesară înainte de crearea structurilor de tabel. Multe baze de date din lumea reală au fost proiectate necorespunzător sau împovărate cu anomalii dacă au fost modificate necorespunzător în decursul timpului. Vi se poate cere să reproiectați și să modificați bazele de date existente. Aceasta poate fi o întreprindere importantă dacă tabelele nu sunt normalizate corespunzător.
Termeni cheie și abrevieri
- a doua formă normală (2NF): relația trebuie să fie în 1NF și PK cuprinde un singur atribut
- a treia formă normală (3NF): relația trebuie să fie în 2NF și toate dependențele tranzitive trebuie eliminate; un atribut non-cheie poate să nu depindă funcțional de un alt atribut non-cheie.
- forma normală Boyce-Codd (BCNF): un caz special pentru al 3-lea NF
- normalizare: procesul de determinare a câtă redundanță există într-un tabel
- prima formă normală (1NF): numai valorile unice sunt permise la intersecția fiecărui rând și coloană, deci nu există grupuri repetate
- reguli semantice: reguli de afaceri aplicate bazei de date
Sursa: Adrienne Watt, Database Design – 2nd Edition. Descărcare gratuită de la B.C. Open Textbook Collection. © 2014 Adrienne Watt and Nelson Eng. Licența (inclusiv imagini) CC BY 4.0. Traducere Nicolae Sfetcu
© 2021 MultiMedia Publishing, Baze de date, Volumul 1
Lasă un răspuns