CARE ESTE A TREIA FORMĂ NORMALĂ? (BAZE DE DATE) - TEHNOLOGIE - 2025

A treia formă normală (baze de date) este o tehnică relațională de proiectare a bazelor de date, în care diferitele tabele care o compun nu numai că respectă a doua formă normală, dar toate atributele sau câmpurile sale depind direct de cheia primară.

Când proiectați o bază de date, obiectivul principal este crearea unei reprezentări precise a datelor, a relațiilor dintre acestea și a restricțiilor asupra datelor relevante.

Sursa: pixabay.com

Pentru a atinge acest obiectiv, pot fi utilizate câteva tehnici de proiectare a bazelor de date, dintre care este normalizarea.

Acesta este un proces de organizare a datelor într-o bază de date pentru a evita redundanțele și posibile anomalii în inserarea, actualizarea sau eliminarea datelor, generând astfel un design simplu și stabil al modelului conceptual.

Începe prin examinarea relației funcționale sau a dependenței dintre atribute. Acestea descriu unele proprietăți ale datelor sau relația dintre ele.

Forme normale

Normalizarea folosește o serie de teste, numite forme normale, pentru a ajuta la identificarea grupării optime a acestor atribute și, în final, a stabili setul adecvat de relații care susțin cerințele de date ale companiei.

Adică, tehnica de normalizare este construită în jurul conceptului de formă normală, care definește un sistem de constrângeri. Dacă o relație îndeplinește constrângerile unei anumite forme normale, se spune că relația este într-o formă normală.

Prima formă normală (1FN)

Se spune că un tabel este în 1FN dacă toate atributele sau câmpurile din el conțin doar valori unice. Adică, fiecare valoare pentru fiecare atribut trebuie să fie indivizibilă.

Prin definiție, o bază de date relațională va fi întotdeauna normalizată la prima formă normală, deoarece valorile atributului sunt întotdeauna atomice. Toate relațiile dintr-o bază de date sunt în 1FN.

Totuși, pur și simplu părăsirea bazei de date stimulează o serie de probleme, cum ar fi redundanța și posibile eșecuri la upgrade. Au fost dezvoltate forme normale superioare pentru corectarea acestor probleme.

A doua formă normală (2FN)

Se ocupă cu eliminarea dependențelor circulare dintr-un tabel. Se spune că o relație este în 2FN dacă este în 1FN și, în plus, fiecare câmp sau atribut non-cheie depinde în totalitate de cheia primară sau, mai precis, se asigură că tabelul are un singur scop.

Un atribut non-cheie este orice atribut care nu face parte din cheia primară pentru o relație.

A treia formă normală (3FN)

Se ocupă cu eliminarea dependențelor tranzitorii dintr-un tabel. Adică eliminați atributele non-cheie care nu depind de cheia primară, ci de un alt atribut.

O dependență tranzitorie este un tip de dependență funcțională în care valoarea unui câmp sau atribut non-cheie este determinată de valoarea unui alt câmp care, de asemenea, nu este cheie.

Ar trebui să căutați repetarea valorilor în atributele non-cheie pentru a vă asigura că aceste atribute non-cheie nu depind de nimic altceva decât de la cheia primară.

Se spune că atributele sunt reciproc independente dacă niciunul dintre ele nu depinde funcțional de o combinație de altele. Această independență reciprocă asigură faptul că atributele pot fi actualizate individual, fără pericolul de a afecta un alt atribut.

Prin urmare, pentru ca o relație dintr-o bază de date să fie într-o a treia formă normală, aceasta trebuie să respecte:

- Toate cerințele 2FN.

- Dacă există atribute care nu au legătură cu cheia primară, acestea trebuie eliminate și plasate într-o tabelă separată, corelând ambele tabele cu ajutorul unei chei străine. Adică, nu ar trebui să existe dependențe tranzitorii.

Exemple de a treia formă normală

Exemplul 1

Să fie tabelul STUDENT, a cărui cheie principală este identificarea studentului (STUDENT_ID) și este alcătuită din următoarele atribute: STUDENT_NAME, STREET, CITY și POST_CODE, îndeplinind condițiile pentru a fi 2FN.

În acest caz, STREET și CITY nu au o relație directă cu cheia principală STUDENT_ID, deoarece acestea nu sunt direct legate de student, ci depind în totalitate de codul poștal.

Deoarece studentul este localizat de site-ul determinat de CODE_POSTAL, STREET și CITY sunt înrudite este cu acest atribut. Datorită acestui al doilea grad de dependență, nu este necesar să stocați aceste atribute în tabelul STUDENT.

Creați un nou tabel

Să presupunem că există mai mulți studenți aflați în același cod poștal, tabelul STUDENT având o cantitate imensă de înregistrări și este necesar să schimbați numele străzii sau orașului, atunci această stradă sau oraș trebuie găsită și actualizată în întregul tabel STUDENT.

De exemplu, dacă trebuie să schimbați strada „El Limón” în „El Limón II”, va trebui să căutați „El Limón” în întregul tabel al STUDENTULUI și apoi să-l actualizați la „El Limón II”.

Căutarea într-un tabel imens și actualizarea înregistrărilor unice sau multiple vor dura mult timp și, prin urmare, vor afecta performanța bazei de date.

În schimb, aceste detalii pot fi păstrate într-un tabel separat (POSTCARD) care este legat de tabelul STUDENT folosind atributul POST_CODE.

Tabelul POST va avea relativ puține înregistrări, iar acest tabel POST va trebui actualizat doar o singură dată. Aceasta se va reflecta automat în tabelul STUDENT, simplificând baza de date și interogări. Deci, tabelele vor fi în 3FN:

Exemplul 2

Să se folosească următorul tabel cu câmpul Project_Num ca cheie primară și cu valori repetate în atribute care nu sunt chei.

Valoarea telefonului se repetă de fiecare dată când se repetă numele managerului. Acest lucru se datorează faptului că numărul de telefon are doar o dependență de gradul doi de numărul proiectului. În primul rând, depinde de manager și acest lucru depinde de numărul proiectului, ceea ce face o dependență tranzitorie.

Atributul Project_Manager nu poate fi o cheie posibilă în tabelul Proiecte, deoarece același manager gestionează mai mult de un proiect. Soluția pentru aceasta este să eliminați atributul cu datele repetate (Telefon), creând un tabel separat.

Atributele corespunzătoare trebuie grupate, creând o nouă tabelă pentru a le salva. Datele sunt introduse și se verifică că valorile repetate nu fac parte din cheia primară. Cheia primară este setată pentru fiecare tabel și, dacă este necesar, se adaugă chei străine.

Pentru a respecta a treia formă normală, este creat un nou tabel (Managers) pentru a rezolva problema. Ambele tabele sunt legate prin câmpul Project_Manager:

Referințe

1. Teradata (2019). Prima, a doua și a treia formă normală. Luate de la: docs.teradata.com.
2. Cupa Tutorial (2019). A treia formă normală (3NF). Luat de la: tutorialcup.com.
3. Database Dev (2015). Al treilea formular normal (3NF) - Normalizarea bazei de date. Preluat de la: databasedev.co.uk.
4. Relational DB Design (2019). Introducere în forma a treia normală. Luat de la: relaationaldbdesign.com.
5. Manechine (2019). SQL Prima, a doua și a treia formă normală. Luat de la: dummies.com.