1. czym jest trzecia postać normalna (3NF)?
Osiągnięcie Drugiej Postaci Normalnej (2NF) wyeliminowało zależności częściowe, ale nie rozwiązało wszystkich problemów z redundancją. Trzecia Postać Normalna (3NF) idzie o krok dalej, koncentrując się na usunięciu zależności przechodnich.
Definicja 3NF: Relacja jest w Trzeciej Postaci Normalnej (3NF) wtedy i tylko wtedy, gdy:
- Jest w Drugiej Postaci Normalnej (2NF).
- Każdy atrybut niekluczowy nie jest przechodnio zależny od klucza głównego. Oznacza to, że żaden atrybut niekluczowy nie może zależeć od innego atrybutu niekluczowego.
Mówiąc prościej: „Każdy atrybut niekluczowy musi dostarczać informacji o kluczu, całym kluczu i tylko o kluczu”.
2. identyfikacja zależności przechodnich – studium przypadku
Rozważmy tabelę Zamowione_Produkty, która jest już w 2NF (klucz główny jest prosty).
| ID_Zamowienia | ID_Produktu | Nazwa_Produktu | ID_Kategorii | Nazwa_Kategorii | Ilosc |
|---|---|---|---|---|---|
| Z01 | P1 | Laptop | K1 | Elektronika | 1 |
| Z02 | P2 | Mysz | K1 | Elektronika | 2 |
| Z03 | P3 | Książka | K2 | Książki | 5 |
Krok 1: Analiza zależności. Kluczem głównym jest ID_Zamowienia. Atrybuty niekluczowe to pozostałe kolumny.
ID_Zamowienia → ID_Produktu, Ilosc(OK, zależą bezpośrednio od klucza).ID_Produktu → Nazwa_Produktu, ID_Kategorii(OK, to są atrybuty produktu).ID_Kategorii → Nazwa_Kategorii(Problem!).
Znaleźliśmy zależność przechodnią:
ID_Zamowienia → ID_Produktu → ID_Kategorii → Nazwa_Kategorii
Atrybut niekluczowy Nazwa_Kategorii zależy od innego atrybutu niekluczowego ID_Kategorii, a nie bezpośrednio od klucza głównego ID_Zamowienia. To powoduje redundancję – nazwa „Elektronika” jest powtórzona.
3. proces dekompozycji do 3NF
Aby osiągnąć 3NF, musimy wyeliminować zależność przechodnią poprzez dekompozycję. Atrybuty powodujące problem są przenoszone do nowej tabeli.
- Tworzymy nową tabelę dla atrybutu, który jest determinantem w zależności przechodniej (w naszym przypadku
ID_Kategorii). Staje się on kluczem głównym nowej tabeli. - Przenosimy do nowej tabeli wszystkie atrybuty, które od niego zależą (
Nazwa_Kategorii). - Z oryginalnej tabeli usuwamy przeniesione atrybuty, ale pozostawiamy atrybut, który będzie kluczem obcym.
W naszym przypadku, dekompozycja tabeli Zamowione_Produkty prowadzi do powstania trzech tabel, które w pełni opisują nasz system bez redundancji.
Wynik dekompozycji:
| ID_Zamowienia | ID_Produktu_FK | Ilosc |
|---|---|---|
| Z01 | P1 | 1 |
| Z02 | P2 | 2 |
| Z03 | P3 | 5 |
| ID_Produktu | Nazwa_Produktu | ID_Kategorii_FK |
|---|---|---|
| P1 | Laptop | K1 |
| P2 | Mysz | K1 |
| P3 | Książka | K2 |
| ID_Kategorii | Nazwa_Kategorii |
|---|---|
| K1 | Elektronika |
| K2 | Książki |
Po dekompozycji każda tabela jest w 3NF. Informacje o kategoriach są przechowywane tylko raz. Anomalie zostały wyeliminowane.
4. krok dalej: postać normalna boyce’a-codda (BCNF)
Postać Normalna Boyce’a-Codda (BCNF) jest silniejszą, bardziej rygorystyczną wersją 3NF. Większość tabel w 3NF jest automatycznie w BCNF. Problem pojawia się w rzadkich przypadkach, gdy tabela ma wiele kluczy kandydujących, które są złożone i częściowo się pokrywają.
Definicja BCNF: Relacja jest w BCNF wtedy i tylko wtedy, gdy dla każdej nietrywialnej zależności funkcyjnej X → Y, X jest superkluczem.
Mówiąc prościej, w BCNF jedynymi determinantami mogą być klucze kandydujące. Oznacza to, że żaden atrybut (nawet będący częścią klucza kandydującego) nie może być zdeterminowany przez atrybut niebędący kluczem.
Przykład naruszenia BCNF (ale nie 3NF)
Rozważmy tabelę zapisów studentów na kursy prowadzone przez profesorów, gdzie każdy profesor prowadzi tylko jeden kurs.
| ID_Studenta | ID_Profesora | Kurs |
|---|
Klucze kandydujące: {ID_Studenta, ID_Profesora} oraz {ID_Studenta, Kurs}.
Zależności: ID_Profesora → Kurs.
Ta tabela jest w 3NF (ponieważ Kurs nie jest atrybutem niekluczowym), ale narusza BCNF, ponieważ determinant ID_Profesora nie jest superkluczem. Aby osiągnąć BCNF, musielibyśmy dokonać dekompozycji na dwie tabele: {ID_Profesora, Kurs} i {ID_Studenta, ID_Profesora}.
5. podsumowanie i znaczenie 3NF
Osiągnięcie Trzeciej Postaci Normalnej jest złotym standardem w projektowaniu relacyjnych baz danych dla systemów transakcyjnych (OLTP). Zapewnia ona, że dane są logicznie pogrupowane, redundancja jest zminimalizowana, a anomalie wyeliminowane.
- 1NF: Eliminuje grupy powtarzalne (atomowość wartości).
- 2NF: Eliminuje zależności częściowe (każdy atrybut zależy od całego klucza).
- 3NF: Eliminuje zależności przechodnie (atrybuty niekluczowe zależą tylko od klucza).
Chociaż istnieją wyższe postaci normalne (BCNF, 4NF, 5NF), w większości praktycznych zastosowań osiągnięcie 3NF jest wystarczające i zapewnia doskonałą równowagę między integralnością danych a wydajnością zapytań.
