Normalizare în SQL: 1NF, 2NF, 3NF și BCNF

Normalizarea este un proces sistematic de a se asigura că un model de bază de date relațională este eficient, potrivit pentru interogări cu scop general și lipsit de caracteristici nedorite, cum ar fi anomalii de inserare, actualizare și ștergere, ceea ce duce la pierderea integrității datelor. Acest proces de normalizare ajută, de asemenea, la eliminarea redundanței datelor și reduce șansele de inconsecvență după orice operațiuni de inserare, actualizare sau ștergere.

Pentru o mai bună înțelegere, luați în considerare următoarea schemă: Student (Nume, Adresă, Subiect, Clasă)

Există câteva probleme sau ineficiențe în această schemă.

1) Redundanță : Adresa studentului se repetă pentru fiecare materie la care este înscris.

2) Actualizarea anomaliei : Este posibil să fi actualizat adresa într-un tuplu (rând) în timp ce l-am lăsat neschimbat în celelalte rânduri. Astfel, nu am avea o adresă unică în mod constant pentru fiecare student.

3) Anomalie de inserare : Nu vom înregistra adresa unui student fără să ne înregistrăm pentru cel puțin un subiect. În mod similar, atunci când un student dorește să se înscrie la un subiect nou, este posibil ca o altă adresă să fie inserată.

4) Anomalie de ștergere : Dacă un student decide să întrerupă toate disciplinele înscrise, atunci și adresa studentului se va pierde în procesul de ștergere.

Astfel, este important să se reprezinte datele utilizatorului prin relații care nu creează anomalii în urma operațiunilor de adăugare, ștergere sau actualizare a tuplelor. Acest lucru poate fi realizat doar printr-o analiză atentă a constrângerilor de integritate, în special a dependențelor de date ale bazei de date.

Relațiile ar trebui concepute astfel încât să fie grupate numai acele atribute care există în mod natural împreună. Acest lucru poate fi realizat în mare parte printr-o înțelegere de bază a semnificației tuturor atributelor datelor. Cu toate acestea, avem încă nevoie de o măsură formală pentru a ne asigura obiectivul de proiectare.

Normalizarea este acea măsură formală. Răspunde la întrebarea de ce o anumită grupare de atribute va fi mai bună decât oricare alta.

În prezent există șapte forme normale:

• Prima formă normală (1NF)
• A doua formă normală (2NF)
• A treia formă normală (3NF)
• Forma normală Boyce-Codd (BCNF)
• A patra formă normală (4NF)
• A cincea formă normală (5NF)
• Forma normală a șasea sau cheie de domeniu (6NF)

Citiți: Tipuri de vizualizări în SQL

Prima formă normală (1NF sau formă minimă)

• Nu există o ordonare de sus în jos pentru rânduri și de la stânga la dreapta pentru coloane.
• Nu există rânduri duplicat.
• Fiecare intersecție de rând și coloană conține exact o valoare din domeniul aplicabil sau valoarea nulă. Această condiție indică faptul că toate valorile coloanei ar trebui să fie atomice, scalare sau să dețină o singură valoare. Aici nu este permisă repetarea informațiilor sau a valorilor în mai multe coloane.
• Toate coloanele sunt regulate (adică rândurile nu au componente ascunse, cum ar fi ID-uri de rând, ID-uri de obiect sau marcaje temporale ascunse).

Să luăm un exemplu de schemă care nu este normalizată. Să presupunem că un designer dorește să înregistreze numele și numerele de telefon ale clienților. Ei definesc un tabel de clienți după cum se arată:

Aici, nu este în 1 NF. Coloana Numere de telefon nu este atomică sau nu are o valoare scalară, adică a avut mai mult de o valoare, ceea ce nu poate fi permis în 1 NF.

Pentru a face 1 NF

• Mai întâi vom sparge (descompune) masa noastră unică în două.
• Fiecare tabel ar trebui să aibă informații despre o singură entitate.

Grupuri repetate de numere de telefon nu apar în acest design. În schimb, fiecare link de la client la numărul de telefon apare în propria înregistrare.

Checkout: Cele mai frecvente întrebări și răspunsuri la interviu SQL

A doua formă normală

Fiecare formă normală are mai multe criterii constrângeri decât predecesorul său. Deci, orice tabel care este în a doua formă normală (2NF) sau mai mare este, prin definiție, și în 1NF. Pe de altă parte, un tabel care este în 1NF poate fi sau nu în 2NF; dacă este în 2NF, poate fi sau nu în 3NF și așa mai departe.

Se spune că un tabel 1NF este în 2NF dacă și numai dacă niciunul dintre atributele sale neprime nu este dependent funcțional de o parte (subset propriu) a unei chei candidate. (Un atribut nonprim nu aparține niciunei chei candidate.)

Rețineți că atunci când un tabel 1NF nu are chei candidate compuse (chei candidate constând din mai mult de un atribut), tabelul este automat în 2NF.

Verificați dacă o relație R (A, B, C, D, E) cu FD Setată ca { BC ? D, AC? BE, B? E } este în 2NF?

• După cum putem vedea, închiderea AC este (AC)+ = {A, C, B, E, D} prin aplicarea algoritmului de apartenență. Dar niciuna dintre submulțimile sale nu poate determina toate atributele relației de la sine, deci AC este cheia candidată pentru această relație. Mai mult, nici A, nici C nu pot fi derivate din orice alt atribut al relației, deci va exista doar o cheie candidată care este {AC}.
• Aici {A, C} sunt atributele prime și {B, D, E} sunt atributele neprime.
• Relația R este deja în prima formă normală, deoarece un SGBD relațional în 1NF nu permite atribute multi-valorice sau compuse.

BC? D este în a doua formă normală deoarece BC nu este un subset adecvat al cheii candidate AC,

AC? BE este în a doua formă normală, deoarece AC însuși este cheia candidată și

B? E este în a doua formă normală B nu este un subset adecvat al cheii candidate AC.

Astfel, relația dată R este în a 2-a formă normală.

A treia formă normală

Se spune că un tabel este în 3NF dacă și numai dacă pentru fiecare dintre dependențele sale funcționale.

X → A , cel puțin una dintre următoarele condiții este îndeplinită:

• X conține A (adică X → A este o dependență funcțională trivială) sau
• X este o super-cheie sau
• A este un atribut principal (adică, A este prezent într-o cheie candidată)

O altă definiție a 3NF afirmă că fiecare atribut non-cheie al lui R este dependent netranzitiv (adică dependent direct) de cheia primară a lui R. Aceasta înseamnă că niciun atribut non-prim (nu face parte din cheia candidată) nu este dependent funcțional de alte atribute non-prime. Dacă există două dependențe astfel încât A ? B și BC, apoi din aceste FD-uri, putem deriva A ? C. Această dependenţă AC este tranzitivă.

Exemplu de 3NF:

Luați în considerare următoarea relație Comandă (Număr comandă, Piesă, Furnizor, Preț unitar, Cantitate comandată) cu setul dat de FD:

Ordin# ? Piesa, Furnizor, Cantitate comandata si Furnizor, Piesa ? Preț unitar)

Aici comanda # este cheia relației.

Folosind axiomele lui Amstrong, obținem

Ordin# ? Parte, comanda? Furnizor și comandă? CantitateComandată.

Ordin# ? Parte, Furnizor și Furnizor, Parte? Preț unitar, ambele dau # de comandă? Preț unitar.

Astfel, vedem că toate atributele nonprime depind de cheie (Order#). Cu toate acestea, există o dependență tranzitivă între Order# și UnitPrice. Deci această relație nu este în 3NF. Cum o facem în 3NF?

Nu putem stoca prețul unitar al oricărei piese furnizate de orice furnizor decât dacă cineva plasează o comandă pentru acea parte. Deci, va trebui să descompunem tabelul pentru a-l face să urmeze 3NF după cum urmează.

Comanda (Nr. comandă, Piesă, Furnizor, Cantitate comandată) și Preț Master (Piesă, Furnizor, UnitPrice).

Acum nu există dependențe tranzitive prezente. Relația este în 3NF.

Citiți și: SQL pentru știința datelor

Învață cursuri de software online de la cele mai bune universități din lume. Câștigă programe Executive PG, programe avansate de certificat sau programe de master pentru a-ți accelera cariera.

Concluzie

Există mai mult la normalizare, cum ar fi BCNF, 4NF, 5NF și 6NF. Pe scurt, BCNF nu este altceva decât o extensie a 3NF, deoarece ultima regulă a 3NF nu se aplică aici. Toate dependențele funcționale trebuie să aibă atributele cheie în stânga și niciunul în partea dreaptă. (BCNF se mai numește și 3.5NF). Cu toate acestea, formele normale de la 4NF și nu numai sunt implementate cu greu în practica obișnuită.

Dacă sunteți interesat să aflați mai multe despre dezvoltarea full-stack, consultați programul Executive PG de la upGrad și IIIT-B în dezvoltarea software full-stack, care este conceput pentru profesioniști care lucrează și oferă peste 500 de ore de formare riguroasă, peste 9 proiecte, și misiuni, statutul de absolvenți IIIT-B, proiecte practice practice și asistență la locul de muncă cu firme de top.