Normalizarea bazelor de date

• Scopul normalizării este de a identifica schemele de relații care să modeleze cât mai corect realitatea funcțională.
• Proiectarea incorectă a schemelor de relație poate duce la apariția anomaliilor care complică dezvoltarea sau exploatarea aplicațiilor software.
• Verificarea dependențelor funcționale atașate schemei este o metodă de testare a corectitudinii acesteia.

Reguli importane

• Datele redundante sunt aceleași date stocate de mai multe ori într-o relație sau în relații diferite, și ar trebui evitate.
• Datele care se pot deduce prin prelucrare din alte date nu ar trebui stocate în baza de date.

Definitii

• Normalizarea este un proces de descompunere a unei relații în mai multe, cu scopul de a elimina anomaliile de proiectare și exploatare a bazei de date.
• Formele normale impun regulile de descompunere în timpul normalizării.
• O schemă de relație obținută în urma normalizării, care îndeplinește un set de standarde și cerințe specifice, este într-o formă normală.
• Edgar F. Codd a definit formalismul primelor forme normale în 1970: FN1, FN2 și FN3.
• Forma Normală Boyce-Codd (FNBC) a fost definită în 1974 de Edgar F. Codd și Raymond F. Boyce.
• Formele normale FN4, FN5 și FN6 au avut aplicabilitate redusă în proiectarea bazelor de date.

Forma Normală 1 (FN1)

• O relație R este în FN1 dacă toate atributele sale au doar valori atomice (fără atribute cu valori multiple) și nu există atribute sau grupuri de atribute care se repetă.
• Semnificația termenului "atomic" este similară cu cea din modelul entitate-asociere: valoarea este întotdeauna folosită ca un întreg.
• În FN1, domeniul fiecărui atribut este construit din valori indivizibile, adică toate atributele trebuie să conțină o singură informație.

Forma Normală 2 (FN2)

• O dependență funcțională Y → A este o dependență parțială dacă Y este strict inclusă într-o cheie a relației R.
• O dependență funcțională Y → A este o dependență tranzitivă dacă Y nu este inclusă în nicio cheie a relației R.
• Relația R este în FN2 dacă respectă cerințele FN1 și nu conține dependențe parțiale (dar poate conține dependențe tranzitive).
• O relație este în FN2 dacă este în FN1 și orice atribut care nu face parte dintr-o cheie este identificat de întreaga cheie, nu doar de unele atribute care fac parte din cheie.
• Dacă o entitate este în FN1 și cheia sa este formată dintr-un singur atribut, atunci este automat și în FN2.

Forma Normală 2 (FN2) Exemple

• Relația PRODUSE este în FN2 deoarece cheia are un singur atribut, nu are dependențe parțiale, iar ultimele două dependențe sunt tranzitive deoarece Cod_furniz nu aparține cheii unice Cod_prod.
• Relația NOTE nu este în FN2 deoarece există dependențe parțiale (Nr_matricol → Nume_stud și Cod_discip → Den_discip).

Forma Normală 3 (FN3)

• Un atribut A ∈ R este atribut prim dacă aparține unei chei a lui R.
• Relația R este în FN3 dacă oricare ar fi o dependență netrivială X → A din F, atunci X este supercheie pentru R sau A este atribut prim.
• Se aplică regula de descompunere pentru a obține dependențe cu un singur atribut în partea dreaptă.
• Într-o relație FN3, niciun atribut care nu este parte a unei chei nu depinde de un alt atribut care nu face parte din cheie.
• Într-o relație FN3, nu se acceptă dependențe tranzitive.

Forma Normală 3 (FN3) Exemple

• Relația R=NLAP nu respectă FN3 deoarece are dependență parțială N→L.
• Relația R=OSC are toate atributele prime și este în FN3.
• Relația R=MADS nu este în FN3 deoarece MD nu este supercheie.
• Relația MAD este în FN2 deoarece nu există dependențe parțiale.

Necesitatea FN3

• Prin FN3 se evită problemele legate de redundanță și anomaliile de actualizare.
• Dependențele funcționale X→Y reprezintă o restricție de integritate asupra relațiilor, ci reprezintă, o legătură pe care baza de date "are intenția să o memoreze".
• Dacă avem o dependență tranzitivă X→Y→A, nu putem asocia o valoare Y cu o valoare X, dacă nu există o valoare A asociată cu valoarea Y.
• Dependența N→L este o dependență parțială, iar localitatea furnizorului trebuie să fie repetată pentru fiecare articol livrat de furnizor.
• FN3 elimină redundanța.

Forma Normală Boyce-Codd (FNBC)

• Într-o relație FNBC, fiecare dependență din F are o supercheie în partea stângă.
• Condiția de FNBC este inclusă în definiția FN3.
• Orice relație care este în FNBC este implicit și în FN3.
• Reciproca nu este adevărată.
• Dacă o schemă de relație nu este în FN3, nu poate fi nici în FNBC.

Forma Normală Boyce-Codd (FNBC) Exemple

• Relația R = ABCDE nu este în FNBC deoarece are cheile AD și BD, dar nicio dependență nu are o supercheie în partea stângă.
• Relația R = ABCD nu este în FNBC deoarece atributele A, B, C si D au cheia AB dar nu toate dependentee au in partea stanga o supercheie.

Anomalii în baza de date

• Două tipuri de anomalii pot apărea: de proiectare (redundante, tipuri greșite de atribute, constrângeri incorecte) și de funcționare (apar la operații DML).

Redundanța

• Redundanța este apariția datelor stocate de mai multe ori în baza de date (în aceeași relație sau în relații diferite).
• Atributul Den_spec în relația NOTE este redundant.
• Efectele negative ale existenței redundantelor: alocare suplimentară de spațiu fizic, inconsistența datelor, creșterea costurilor de acces, prelucrări eronate și creșterea probabilității erorii umane la actualizări.

Alte tipuri de anomalii

• Tipurile atributelor pot genera anomalii, de exemplu, un format greșit al datei.
• Constrângerile incorecte apar la definirea relațiilor și au efect în timpul funcționării.
• Inserarea poate genera anomalii (neconcordanța codurilor de specializare cu denumirile).
• Modificarea datelor poate duce la inconsistența datelor (schimbarea specializării unui student).
• Ștergerea poate produce anomalii (pierderea numărului matricol și specializarea unui student odată cu ștergerea tuturor înregistrărilor aferente).
• Anomaliile pot fi evitate prin crearea relației STUDENTI(Matricol, Nume, Cod_spec).
• Proiectarea atentă a bazei de date minimizează redundanța datelor și spațiul fizic alocat.

Independența datelor

• O bază de date poate fi accesată de mai multe aplicații concurent.
• Modificările majore de structură la nivel inferior implică modificări la nivel superior (aplicație).
• Independența datelor se referă la modul în care modificările structurii bazei de date afectează aplicațiile.
• Independența datelor are două aspecte: logică și fizică.
• Independența logică se referă la imunitatea schemelor externe față de modificările din schema conceptuală (adăugarea de entități/atribute, modificarea structurii entităților, adăugarea/modificarea/ștergerea obiectelor, activarea/dezactivarea constrângerilor).
• Independența logică permite modificări în structura bazei de date fără a rescrie codul programului.
• Independența fizică se referă la imunitatea schemei conceptuale față de modificările din schema internă (reorganizarea fișierelor, introducerea de noi dispozitive, exportul bazei de date, modificări în configurarea rețelei, replicarea datelor, utilizarea serverelor redundante).

Alte detalii despre independenta datelor

• Independența datelor este o problemă complexă chiar și în sistemele de ultimă generație.
• Independența datelor trebuie studiată și îmbunătățită continuu, indiferent de complexitatea limbajelor relationale sau a aplicatiilor.
• Instrumentele moderne de proiectare software oferă modificări în cascadă ale obiectelor relaționate.
• Instrumentele CASE oferă recompilarea sau generarea aplicației pentru a prelua modificările structurii bazei de date.
• Intervențiile manuale ale dezvoltatorilor sunt necesare.
• Este posibil ca o aplicație să nu fie afectată de modificarea bazei de date (adăugarea de entități/atribute noi).
• Modificarea bazei de date solicită modificări în aplicație și în acest caz trebuie intervenit și la nivel extern.
• Cererile de interogare nu trebuie rescrise dacă se adaugă entități noi sau se modifică relațiile fără a afecta datele existente.
• Editarea vedederilor (view) create pe una sau mai multe entități nu trebuie recreată, dar şi aici implictiile trebuie studiate cu atentie.