1. dlaczego 3NF/BCNF to nie koniec? problem zależności wielowartościowych
Osiągnięcie Trzeciej Postaci Normalnej (3NF) lub jej rygorystyczniejszej wersji, BCNF, eliminuje anomalie wynikające z zależności funkcyjnych. Jednak istnieje jeszcze jeden, bardziej subtelny rodzaj zależności, który może prowadzić do redundancji: zależność wielowartościowa (ang. Multivalued Dependency, MVD).
Definicja Zależności Wielowartościowej (MVD): W relacji R, mówimy, że zachodzi MVD X →→ Y (X wielowartościowo determinuje Y), jeśli dla danej wartości X istnieje dobrze zdefiniowany zbiór wartości Y, a ten zbiór jest niezależny od pozostałych atrybutów w relacji.
Problem pojawia się, gdy w jednej tabeli próbujemy opisać dwa lub więcej niezależnych faktów wielowartościowych o tej samej encji. Aby zachować spójność, baza danych jest zmuszona do tworzenia wszystkich możliwych kombinacji tych faktów, co prowadzi do eksplozji liczby wierszy i poważnej redundancji.
Definicja 4NF: Relacja jest w Czwartej Postaci Normalnej (4NF) wtedy i tylko wtedy, gdy jest w BCNF i nie zawiera żadnych nietrywialnych zależności wielowartościowych.
2. identyfikacja zależności wielowartościowych – studium przypadku
Wyobraźmy sobie bazę danych dla pizzerii. Chcemy przechowywać informacje o tym, jakie rodzaje pizzy oferuje dana pizzeria, oraz na jakie dzielnice realizuje dostawy.
| Nazwa_Pizzerii | Rodzaj_Pizzy | Dzielnica_Dostawy |
|---|---|---|
| Pizza Hut | Margherita | Śródmieście |
| Pizza Hut | Margherita | Mokotów |
| Pizza Hut | Pepperoni | Śródmieście |
| Pizza Hut | Pepperoni | Mokotów |
| Dominos | Hawajska | Wola |
Analiza:
- Kluczem głównym jest {Nazwa_Pizzerii, Rodzaj_Pizzy, Dzielnica_Dostawy}. Tabela jest w BCNF, ponieważ nie ma żadnych zależności funkcyjnych (wszystkie atrybuty są częścią klucza).
- Jednakże, rodzaj pizzy oferowany przez pizzerię jest faktem niezależnym od dzielnicy dostawy.
- Mamy tu dwie zależności wielowartościowe:
Nazwa_Pizzerii →→ Rodzaj_PizzyNazwa_Pizzerii →→ Dzielnica_Dostawy
Aby zapisać fakt, że „Pizza Hut” oferuje Margheritę i Pepperoni oraz dostarcza na Śródmieście i Mokotów, musimy stworzyć 2 * 2 = 4 wiersze. To jest źródło problemu.
Anomalie w tabeli naruszającej 4NF:
- Anomalia wstawiania: Jeśli „Pizza Hut” zacznie oferować nową pizzę „Capricciosa”, musimy dodać dwa nowe wiersze: jeden dla Śródmieścia i jeden dla Mokotowa.
- Anomalia usuwania: Jeśli „Pizza Hut” przestanie dostarczać na Mokotów, musimy usunąć dwa wiersze. Jeśli przez pomyłkę usuniemy tylko wiersz (Pizza Hut, Margherita, Mokotów), nasza baza danych będzie w niespójnym stanie.
- Anomalia modyfikacji: Modyfikacje są również problematyczne i wymagają aktualizacji wielu rekordów.
3. proces dekompozycji do 4NF
Rozwiązaniem jest dekompozycja tabeli na mniejsze, tak aby każda z nich przechowywała tylko jeden, niezależny fakt wielowartościowy.
- Tworzymy nową tabelę dla każdej zależności wielowartościowej.
- Każda nowa tabela zawiera determinant (w naszym przypadku
Nazwa_Pizzerii) oraz jeden z atrybutów wielowartościowych.
Wynik dekompozycji:
| Nazwa_Pizzerii_FK | Rodzaj_Pizzy |
|---|---|
| Pizza Hut | Margherita |
| Pizza Hut | Pepperoni |
| Dominos | Hawajska |
| Nazwa_Pizzerii_FK | Dzielnica_Dostawy |
|---|---|
| Pizza Hut | Śródmieście |
| Pizza Hut | Mokotów |
| Dominos | Wola |
Po dekompozycji, aby dodać nową pizzę do oferty „Pizza Hut”, wystarczy dodać jeden wiersz do tabeli Oferta_Pizzy. Redundancja i anomalie zostały wyeliminowane.
4. podsumowanie i znaczenie 4NF
Czwarta Postać Normalna (4NF) jest ważnym narzędziem do projektowania baz danych, które muszą przechowywać złożone, wieloaspektowe informacje o encjach. Chociaż przypadki naruszenia 4NF są rzadsze niż naruszenia 3NF, ich identyfikacja i rozwiązanie są kluczowe dla uniknięcia problemów z integralnością danych.
Kluczowa zasada: Nie przechowuj w jednej tabeli dwóch lub więcej niezależnych, wielowartościowych faktów o tej samej encji. Zamiast tego, utwórz osobną tabelę dla każdego takiego faktu.
Normalizacja do 4NF zapewnia, że struktura bazy danych jest semantycznie czysta, a każda tabela reprezentuje jeden, spójny koncept, co ułatwia zarządzanie danymi i zapobiega błędom w przyszłości.
