Trzecia postać normalna (3NF): definicja i zasady normalizacji baz danych
Trzecia postać normalna (3NF) — definicja i zasady normalizacji baz danych. Dowiedz się, jak eliminować redundancję i poprawić integralność danych.
Trzecia postać normalna (3NF) to własność modelu relacyjnego, a konkretnie tabel, która jest kryterium normalizacji bazy danych. Celem 3NF jest eliminacja zbędnych zależności między kolumnami, zwłaszcza zależności przechodnich, które powodują redundancję danych i utrudniają ich aktualizację.
Definicja
Tabela jest w trzeciej postaci normalnej (3NF) wtedy, gdy spełnione są następujące warunki:
- jest w drugiej postaci normalnej (2NF) (czyli wszystkie atrybuty niebędące częścią klucza są w pełni zależne od klucza podstawowego), oraz
- nie występują zależności przechodnie między atrybutami niebędącymi częścią klucza — innymi słowy żaden atrybut niekluczowy nie zależy od innego atrybutu niekluczowego.
Formalna, alternatywna definicja: dla każdej niebanalnej zależności funkcyjnej X → A w relacji zachodzi przynajmniej jedna z dwóch sytuacji:
- X jest superkluczem relacji (czyli z X można jednoznacznie wyznaczyć wszystkie atrybuty), lub
- A jest atrybutem pierwszorzędnym (prime attribute), czyli należy do pewnego klucza kandydującego.
Wyjaśnienie pojęć
- Klucz podstawowy (primary key) — wybrany klucz kandydujący, identyfikujący wiersz tabeli.
- Klucz kandydujący — minimalny zestaw atrybutów jednoznacznie identyfikujących wiersz.
- Atrybut pierwszy (prime) — atrybut będący częścią jakiegokolwiek klucza kandydującego.
- Zależność przechodnia — sytuacja, gdy A → B i B → C powoduje, że A → C (gdzie B jest atrybutem niekluczowym); to właśnie takie zależności usuwa 3NF.
Przykład praktyczny
Mamy tabelę Zamówienia(OrderID, CustomerID, CustomerName, CustomerAddress, OrderDate), gdzie OrderID jest kluczem podstawowym. Jeśli CustomerName i CustomerAddress zależą od CustomerID (CustomerID → CustomerName, CustomerID → CustomerAddress), to występuje zależność przechodnia:
- OrderID → CustomerID (poprzez relację zamówienia do klienta)
- CustomerID → CustomerAddress (informacja o kliencie)
- w efekcie OrderID → CustomerAddress — to jest zależność przechodnia, powodująca powielanie danych adresowych przy wielu zamówieniach tego samego klienta.
Aby osiągnąć 3NF, należy rozdzielić tabelę na dwie: Zamówienia(OrderID, CustomerID, OrderDate) oraz Klienci(CustomerID, CustomerName, CustomerAddress). Decompozycja taka eliminuje redundancję i ułatwia utrzymanie spójności.
Jak sprawdzić i przekształcić tabelę do 3NF — krok po kroku
- Zidentyfikuj wszystkie atrybuty i zależności funkcyjne (FD) w tabeli.
- Wyznacz wszystkie klucze kandydujące i klucz podstawowy.
- Sprawdź, czy tabela jest w 2NF (brak częściowych zależności od części klucza złożonego).
- Znajdź zależności przechodnie (A → B i B → C, gdzie B jest niekluczowy) i wyodrębnij je, tworząc osobne relacje dla atrybutów zależnych od B.
- Upewnij się, że dekompozycja jest bezstratna (lossless join) i — jeśli to możliwe — że zachowuje zależności (dependency preservation).
Korzyści i ograniczenia
- Zalety: mniejsza redundancja, prostsze aktualizacje, mniejsze ryzyko anomalii wstawiania/aktualizacji/usuwania, czytelniejsza struktura danych.
- Wady: większa liczba tabel i konieczność łączeń (JOIN) w zapytaniach — może to wpływać na wydajność. W praktyce czasem stosuje się denormalizację tam, gdzie wydajność odczytów jest krytyczna.
- Uwaga: 3NF nie jest najściślejszą formą normalizacji — istnieje silniejsza postać BCNF, która eliminuje jeszcze więcej anomalii, ale czasami kosztem zachowania wszystkich zależności funkcyjnych.
Podsumowanie
Trzecia postać normalna to praktyczne i często wystarczające kryterium normalizacji relacyjnej: wymaga, by tabela była w 2NF oraz pozbawiona zależności przechodnich. Stosowanie 3NF pomaga utrzymać spójność i zredukować powtarzanie danych, choć w projektach realnych warto rozważyć także kwestie wydajności i ewentualną denormalizację.
Przeszukaj encyklopedię