Pełna zależność funkcjonalna to stan normalizacji baz danych, który odpowiada standardowi normalizacji Drugiej Normalnej Formy (2NF). W skrócie oznacza to, że spełnia on wymagania Pierwszej Normalnej Formy (1NF), a wszystkie nie-kluczowe atrybuty są w pełni funkcjonalnie zależne od klucza podstawowego.
To nie jest tak skomplikowane, jak mogłoby się wydawać. Przyjrzyjmy się temu bardziej szczegółowo.
Podsumowanie pierwszej formy normalnej
Zanim baza danych będzie w pełni funkcjonalnie zależna, musi najpierw zachować zgodność z Pierwszą Normalną Formą.
Wszystko to oznacza, że każdy atrybut musi zawierać pojedynczą, atomową wartość.
Na przykład: poniższa tabela nie stosować się do 1NF, ponieważ pracownik Tina jest połączony z dwiema lokalizacjami, obie w jednej komórce:
| Pracownik | Lokalizacja |
|---|---|
| Jan | Los Angeles |
| Tina | Los Angeles, Chicago |
Dopuszczenie tego projektu może negatywnie wpłynąć na aktualizacje danych lub wpisy. Aby zapewnić zgodność z 1NF, zmień kolejność tabel tak, aby wszystkie atrybuty (lub komórki kolumn) zawierały jedną wartość:
Pierwsza zgodność z normalną formą
Ale 1NF nadal nie wystarcza, aby uniknąć problemów z danymi.
Jak działa 2NF, aby zapewnić pełną zależność
Aby być w pełni zależnymi, wszystkie niezatwierdzone atrybuty klucza muszą zależeć od klucza podstawowego. (Pamiętaj, że kluczem kandydującym jest dowolny klucz (na przykład klucz podstawowy lub klucz obcy) używany do jednoznacznego identyfikowania rekordu bazy danych.
Projektanci baz danych używają notacji, aby opisać zależności zależne między atrybutami:
Jeśli atrybut A określa wartość B, to to piszemyA -> B- co oznacza, że B jest funkcjonalnie zależne od A. W tej zależności A określa wartość B, podczas gdy B zależy od A.
Na przykład poniżej Działy pracownicze tabela, EmployeeID i DeptID są obydwoma kluczami kandydującymi: EmployeeID jest kluczem podstawowym tabeli, a DeptID jest kluczem obcym.
Każdy inny atrybut - w tym przypadku EmployeeName i DeptName - musi zależeć od klucza podstawowego, aby uzyskać jego wartość.
| Numer identyfikacyjny pracownika | Imię i nazwisko pracownika | DeptID | DeptName |
|---|---|---|---|
| Emp1 | Jan | Dept001 | Finanse |
| Emp2 | Tina | Dept003 | Obroty |
| Emp3 | Carlos | Dept001 | Finanse |
W tym przypadku tabela nie jest w pełni zależna, ponieważ podczas gdy nazwa pracownika jest zależna od klucza podstawowego EmployeeID, DeptName zależy od DeptID. To się nazywa zależność częściowa .
Aby ta tabela była zgodna z 2NF, musimy oddzielić dane na dwie tabele:
| Numer identyfikacyjny pracownika | Imię i nazwisko pracownika | DeptID |
|---|---|---|
| Emp1 | Jan | Dept001 |
| Emp2 | Tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Usuwamy atrybut DeptName z pliku Pracowników tabela i utwórz nową tabelę Departamenty :
| DeptID | DeptName |
|---|---|
| Dept001 | Finanse |
| Dept002 | Zasoby ludzkie |
| Dept003 | Obroty |
Teraz relacje między tabelami są w pełni zależne lub w 2NF.
Dlaczego pełna zależność jest ważna
Pełna zależność między atrybutami bazy danych pomaga zapewnić integralność danych i uniknąć anomalii danych.
Weźmy na przykład tabelę w powyższej sekcji, która przylega tylko do 1NF. Oto znowu:
| Pracownik | Lokalizacja |
|---|---|
| Jan | Los Angeles |
| Tina | Los Angeles |
| Tina | Chicago |
Tina ma dwie płyty. Jeśli zaktualizujemy jeden, nie zdając sobie sprawy, że są dwa, wynik będzie niespójny danych.
A co, jeśli chcemy dodać pracownika do tej tabeli, ale nie znamy jeszcze lokalizacji? Możemy nie być uprawnieni do dodania nowego pracownika, jeśli atrybut Location nie zezwala na wartości NULL.
Pełna zależność nie jest jednak całością, jeśli chodzi o normalizację. Musisz upewnić się, że twoja baza danych jest w trzeciej normalnej formie (3NF).
