O dependență funcțională completă este o stare de normalizare a bazei de date care echivalează cu standardul de normalizare a Formei II Normale (2NF). Pe scurt, aceasta înseamnă că îndeplinește cerințele Formei Normale (1NF) și toate atributele non-cheie sunt complet funcționale dependente de cheia primară.
Acest lucru nu este la fel de complicat cum ar putea suna. Să ne uităm la acest lucru în detaliu.
Rezumatul primei forme normale
Înainte ca o bază de date să poată fi pe deplin funcțională dependentă, trebuie să se conformeze mai întâi Formei Normale.
Toate acestea înseamnă că fiecare atribut trebuie să dețină o singură valoare atomică.
De exemplu, se face următorul tabel nu se conformează cu 1NF, deoarece angajatul Tina este legat de două locații, ambele într-o singură celulă:
| Angajat | Locație |
|---|---|
| Ioan | Los Angeles |
| Tina | Los Angeles, Chicago |
Permiterea acestui design ar putea avea un impact negativ asupra actualizărilor sau intrărilor de date. Pentru a asigura conformitatea cu 1NF, rearanjați tabelul astfel încât toate atributele (sau celulele din coloane) să dețină o singură valoare:
Prima conformare normală a formularului
Dar 1NF nu este încă suficient pentru a evita problemele cu datele.
Cum funcționează 2NF pentru a asigura o dependență deplină
Pentru a fi complet dependent, toate atributele de cheie non-candidate trebuie să depindă de cheia primară. (Rețineți că un atribut cheie candidat este orice cheie (de exemplu, o cheie primară sau străină) folosită pentru a identifica în mod unic o înregistrare de bază de date.
Designerii de baze de date folosesc o notație pentru a descrie relațiile dependente dintre atribute:
Dacă atributul A determină valoarea lui B, scriem acest lucruA -> B- ceea ce înseamnă că B este funcțional dependent de A. În această relație, A determină valoarea lui B, în timp ce B depinde de A.
De exemplu, în cele ce urmează Departamentele angajaților tabel, EmployeeID și DeptID sunt ambele chei candidate: EmployeeID este cheia primară a tabelului, în timp ce DeptID este o cheie străină.
Orice alt atribut - în acest caz, EmployeeName și DeptName - trebuie să depindă de cheia primară pentru a obține valoarea sa.
| Card de identitate al angajatului | Numele angajatului | DeptID | DeptName |
|---|---|---|---|
| Emp1 | Ioan | Dept001 | Finanţa |
| Emp2 | Tina | Dept003 | Vânzări |
| Emp3 | Carlos | Dept001 | Finanţa |
În acest caz, tabela nu este pe deplin dependentă, deoarece, în timp ce EmployeeName depinde de cheia primară EmployeeID, DeptName depinde în schimb de DeptID. Aceasta se numește dependența parțială .
Pentru a face ca acest tabel să fie conform cu 2NF, trebuie să separăm datele în două tabele:
| Card de identitate al angajatului | Numele angajatului | DeptID |
|---|---|---|
| Emp1 | Ioan | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Eliminăm atributul DeptName din Angajați tabel și creați o tabelă nouă departamente :
| DeptID | DeptName |
|---|---|
| Dept001 | Finanţa |
| Dept002 | Resurse umane |
| Dept003 | Vânzări |
Acum relațiile dintre mese sunt complet dependente, sau în 2NF.
De ce este importantă dependența deplină
Deplina dependență între atributele bazei de date ajută la asigurarea integrității datelor și evitarea anomaliilor de date.
De exemplu, luați în considerare tabelul din secțiunea de mai sus, care aderă doar la 1NF. Aici este, din nou:
| Angajat | Locație |
|---|---|
| Ioan | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina are două înregistrări. Dacă ne actualizăm una fără a realiza că există două, rezultatul ar fi date incoerente.
Sau, dacă vrem să adăugăm un angajat la această masă, dar nu știm încă locația? S-ar putea să nu fi permis să adăugăm chiar un angajat nou dacă atributul Locație nu permite valori NULL.
Dependența deplină nu este întreaga imagine, totuși, când vine vorba de normalizare. Trebuie să vă asigurați că baza dvs. de date se află în Forma a treia normală (3NF).
