4NF (czwarta postać normalna) została wprowadzona przez Ronalda Fagina w 1977 roku jako naturalne rozszerzenie BCNF. O ile BCNF eliminuje wszystkie anomalie związane z zależnościami funkcyjnymi (FD), o tyle nie radzi sobie z szerszą klasą zależności – zależnościami wielowartościowymi (MVD). Typowym przykładem jest sytuacja, w której jeden czytelnik biblioteczny ma wiele numerów telefonów i wiele adresów e-mail. Są to dwie niezależne listy: liczba telefonów nie ma związku z liczbą emaili.

W BCNF taka tabela byłaby formalnie poprawna, ponieważ nie ma w niej nielegalnych FD, ale w praktyce generuje ogromną redundancję – produkt kartezjański między listami. Dla czytelnika z 3 telefonami i 4 emailami otrzymujemy 12 wierszy zamiast 7. 4NF rozwiązuje ten problem, wymagając aby każda MVD wynikała z klucza głównego. Jeśli tak nie jest – dzielimy tabelę na osobne tabele dla każdej niezależnej listy.

W bibliotece oznacza to, że dane kontaktowe czytelnika powinny być przechowywane w trzech tabelach: Czytelnicy (dane stałe), Telefony i Emaile. Każda z tych tabel przechowuje jeden niezależny fakt, co eliminuje produkt kartezjański i wynikające z niego anomalie.

Prezentacja została podzielona na sześć logicznych części, które prowadzą słuchacza od przypomnienia wcześniejszych postaci normalnych przez wprowadzenie nowego typu zależności (MVD), aż po praktyczną implementację w MariaDB. Taka struktura pozwala stopniowo budować zrozumienie: najpierw utrwalamy wiedzę o BCNF i jej ograniczeniach, potem poznajemy narzędzie (MVD), które opisuje te ograniczenia, a następnie uczymy się, jak 4NF je eliminuje.

Najważniejsza w tej agendzie jest część I (definicja MVD) i część II (definicja 4NF), ponieważ stanowią one teoretyczny fundament. Część III pokazuje praktyczne zastosowanie na przykładzie systemu bibliotecznego, a część IV demonstruje, jak przełożyć teorię na kod SQL. Dwie ostatnie części (V i VI) podsumowują cykl i przygotowują grunt pod 5NF.

Studenci powinni zwrócić szczególną uwagę na różnicę między FD a MVD – to klucz do zrozumienia, dlaczego BCNF nie wystarcza i dlaczego potrzebujemy 4NF. Bez tego rozróżnienia dalsze slajdy będą trudne do przyswojenia.

BCNF (Boyce-Codd Normal Form) jest często uznawana za ostateczną wersję 3NF. Gwarantuje, że każda zależność funkcyjna (FD) w tabeli ma swój wyznacznik będący nadkluczem. W praktyce oznacza to, że nie ma w tabeli "ukrytych" zależności, które mogłyby prowadzić do anomalii przy aktualizacji danych. Biblioteczna baza po BCNF składa się z 6 tabel, które przechowują informacje o czytelnikach, książkach, miastach, wypożyczeniach, opiekunach i przypisaniach.

Jednak BCNF bada tylko zależności funkcyjne, czyli takie, gdzie jedna wartość jednoznacznie wyznacza drugą (np. ID_Czytelnika → Nazwisko). Nie bada ona sytuacji, w której jedna wartość wyznacza cały zbiór niezależnych wartości, czyli zależności wielowartościowych (MVD). Dlatego tabela w BCNF może wciąż zawierać problematyczne dane, o ile problem nie leży w FD, ale w MVD.

To tak, jakbyśmy sprawdzili, czy wszystkie drzwi w domu są zamknięte (BCNF), ale zapomnieli sprawdzić, czy okna też są zamknięte (MVD). Gość może wejść przez okno, nawet jeśli drzwi są zamknięte. 4NF "zamyka okna", czyli eliminuje problemy związane z MVD.

Zależność funkcyjna (FD) to podstawowe pojęcie w teorii normalizacji. Mówimy, że X → Y (X funkcyjnie wyznacza Y), jeśli każda wartość X jest związana z dokładnie jedną wartością Y. W przykładzie bibliotecznym: ID_Czytelnika → Nazwisko oznacza, że każdy czytelnik ma dokładnie jedno nazwisko przypisane do swojego identyfikatora. Nie ma możliwości, aby ten sam ID_Czytelnika wskazywał na dwa różne nazwiska.

FD jest fundamentalna, ponieważ pozwala wykrywać redundancję: jeśli w tabeli wielokrotnie powtarza się ta sama para (ID_Czytelnika, Nazwisko), oznacza to, że dane są zduplikowane i mogą prowadzić do anomalii. Gdybyśmy zmienili nazwisko w jednym wierszu, a zapomnieli w innym, dane stałyby się niespójne. Normalizacja (2NF, 3NF, BCNF) eliminuje te problemy, rozdzielając dane na osobne tabele.

W kontekście 4NF FD jest punktem wyjścia, ale nie wystarcza. BCNF zapewnia, że wszystkie FD są "legalne", ale nie gwarantuje, że nie ma innych typów zależności (MVD). To jak sprawdzenie, że każde dziecko ma dokładnie jednego rodzica (FD), ale nie sprawdzenie, że rodzic może mieć wiele dzieci (MVD).

Po przejściu przez 1NF, 2NF, 3NF i BCNF nasza baza biblioteczna ma 6 tabel: Czytelnicy, Miasta, Ksiazki, Wypozyczenia, Opiekunowie i Przypisania_BCNF. Każda z tych tabel spełnia rygorystyczne wymagania BCNF, co oznacza, że żadna zależność funkcyjna nie powoduje już anomalii. Klucze główne są prawidłowo zdefiniowane, a dane są przechowywane bez zbędnej redundancji wynikającej z FD.

W tabeli Czytelnicy mamy dane osobowe czytelników, Miasta stanowią słownik miast z kodami pocztowymi, Ksiazki zawierają informacje o książkach, a Wypozyczenia łączą czytelników z książkami. Opiekunowie realizują relację wiele-do-wielu między czytelnikami a bibliotekarzami, a Przypisania_BCNF przechowują dodatkowe informacje o przypisaniach. Każda z tych tabel ma prostą strukturę z jasno określonymi zależnościami.

Mimo to, jak za chwilę zobaczymy, istnieją jeszcze problemy, których BCNF nie wychwytuje. Dotyczą one sytuacji, w których w jednej tabeli przechowujemy dwie niezależne listy wartości dla tego samego obiektu. W naszej bibliotece przykładem są dane kontaktowe: czytelnik może mieć wiele telefonów i wiele emaili, a te listy są od siebie niezależne.

BCNF eliminuje wszystkie problemy wynikające z zależności funkcyjnych (FD). Jeśli w tabeli istnieje FD X → Y, to w BCNF X musi być nadkluczem. To gwarantuje, że żadna wartość nie jest niepotrzebnie powielana z powodu zależności funkcyjnych. Jednak istnieją dwa inne typy zależności, którymi BCNF się nie zajmuje: zależności wielowartościowe (MVD) i zależności złączeniowe (JD).

MVD różni się od FD fundamentalnie: podczas gdy FD mówi "znasz X, znasz dokładnie jeden Y", MVD mówi "znasz X, znasz zbiór możliwych Y". Na przykład ID_Czytelnika →→ Telefon oznacza, że czytelnik może mieć wiele telefonów, ale nie ma FD, która by wyznaczała konkretny telefon. To "wiele" jest kluczowe – FD daje pewność, MVD daje zbiór możliwości.

4NF eliminuje MVD, a 5NF eliminuje JD. W tej prezentacji skupiamy się na MVD i 4NF. Warto zapamiętać hierarchię: FD ⊂ MVD ⊂ JD, czyli każda FD jest szczególnym przypadkiem MVD (gdy zbiór ma jeden element), a każda MVD jest szczególnym przypadkiem JD (dla dwóch zbiorów). Kolejne postaci normalne eliminują coraz ogólniejsze typy zależności.

Zależność wielowartościowa (MVD) oznaczana jest symbolem A →→ B i czytana jako "A wielowyznacza B". Oznacza to, że dla danej wartości A istnieje zbiór wartości B, które mogą być z nią powiązane. W przeciwieństwie do FD, gdzie dla danego A mamy dokładnie jedną wartość B, w MVD dla danego A możemy mieć wiele wartości B, a wszystkie są równie poprawne.

Przykład z biblioteki: ID_Czytelnika →→ Telefon. Dla czytelnika o ID=1 możemy mieć telefony '123-456-789', '987-654-321' i '555-111-222'. Każdy z tych telefonów jest poprawny dla tego czytelnika i nie ma między nimi hierarchii. Gdybyśmy mieli FD ID_Czytelnika → Telefon, to czytelnik mógłby mieć tylko jeden telefon – to oczywiście nieprawda w rzeczywistości.

Najważniejsza własność MVD: atrybuty po prawej stronie (B) są niezależne od pozostałych atrybutów w tabeli (C = R – A – B). Oznacza to, że wartości B i C dla danego A mogą wystąpić w dowolnej kombinacji. To właśnie ta niezależność prowadzi do produktu kartezjańskiego, który jest głównym problemem eliminowanym przez 4NF.

Po co nam 4NF, skoro mamy już BCNF? Odpowiedź jest prosta: BCNF nie eliminuje wszystkich anomalii. Rozważmy tabelę DaneKontaktowe (ID_Czytelnika, Telefon, Email). W BCNF ta tabela jest formalnie poprawna: jedyną FD jest (ID_Czytelnika, Telefon, Email) → (ID_Czytelnika, Telefon, Email), a to jest trywialne. Nie ma żadnych "nielegalnych" FD.

Jednak w praktyce tabela zachowuje się problematycznie. Jeśli czytelnik ma 3 telefony i 4 emaile, w tabeli pojawi się 12 wierszy (3 × 4). To produkt kartezjański między listą telefonów a listą emaili. Każdy telefon jest sparowany z każdym emailem, co jest sztuczne – w rzeczywistości telefony i emaile są niezależne, a nie połączone w pary.

Anomalie są oczywiste: dodanie nowego telefonu wymaga 4 INSERT-ów (dla każdego emaila), zmiana emaila wymaga 3 UPDATE-ów (dla każdego telefonu), a usunięcie telefonu wymaga wielu DELETE-ów. 4NF rozwiązuje ten problem poprzez rozdzielenie niezależnych list na osobne tabele, eliminując produkt kartezjański u źródła.

Formalna definicja MVD brzmi następująco: w relacji R zachodzi A →→ B, jeśli dla każdych dwóch krotek t1 i t2 takich, że t1.A = t2.A, istnieją krotki t3 i t4 spełniające: t3.A = t4.A = t1.A, t3.B = t1.B, t3.C = t2.C oraz t4.B = t2.B, t4.C = t1.C, gdzie C = R – A – B. Mówiąc prościej: wartości B i C są wymienne dla danej wartości A.

W praktyce definicja ta oznacza, że jeśli mamy dwa wiersze z tą samą wartością A, ale różnymi wartościami B i C, to możemy "wymieszać" wartości B i C między tymi wierszami i nadal otrzymać poprawne wiersze w relacji. To jest właśnie niezależność: B i C nie są ze sobą powiązane, można je dowolnie łączyć.

Na przykładzie bibliotecznym: jeśli mamy wiersze (ID=1, Tel='123', Email='jan@example.com') i (ID=1, Tel='987', Email='jan@work.com'), to MVD ID →→ Tel | Email oznacza, że poprawne są również kombinacje (ID=1, Tel='123', Email='jan@work.com') i (ID=1, Tel='987', Email='jan@example.com'). Jeśli te kombinacje nie są poprawne w rzeczywistości, to MVD nie zachodzi.

Intuicyjnie MVD można rozumieć jako "listę zakupów" dla danego obiektu. FD to jak przepis kulinarny: znasz danie (X), znasz dokładnie składnik (Y). MVD to jak lista zakupów: znasz osobę (X), znasz listę rzeczy do kupienia (Y), ale nie wiesz, którą kupi najpierw.

Różnica między FD a MVD jest fundamentalna dla projektowania baz danych. FD to relacja funkcyjna: ID_Czytelnika → Miasto oznacza, że czytelnik mieszka w dokładnie jednym mieście. MVD to relacja wielowartościowa: ID_Czytelnika →→ Telefon oznacza, że czytelnik może mieć wiele telefonów, ale nie ma FD, która by wyznaczała konkretny.

W systemie bibliotecznym MVD pojawiają się wszędzie tam, gdzie jeden obiekt (czytelnik, książka) ma wiele wartości tego samego typu, które są od siebie niezależne. Dlatego właśnie 4NF jest tak ważna: pozwala odróżnić sytuacje, w których "wiele" jest naturalne i niezależne, od tych, w których "wiele" wynika z innej zależności.

Porównanie FD i MVD najlepiej zilustrować na konkretnych przykładach z życia bibliotecznego. FD: ID_Czytelnika → Nazwisko (jeden czytelnik = jedno nazwisko, nie ma wyjątków). MVD: ID_Czytelnika →→ Telefon (jeden czytelnik = wiele telefonów, wszystkie poprawne). FD daje pewność jednoznaczności, MVD dopuszcza zbiór.

Kluczowa różnica leży w liczbie wartości Y dla danego X. Dla FD jest to dokładnie 1 – wartość jest zdeterminowana. Dla MVD jest to wiele – wartości są niezależne i żadna nie jest "bardziej poprawna" od innej. To ma ogromne konsekwencje dla struktury tabeli: FD może wymagać osobnej tabeli (jeśli nie wynika z klucza), MVD zawsze wymaga osobnej tabeli (chyba że jest trywialna).

Warto też pamiętać, że FD jest szczególnym przypadkiem MVD: jeśli A → B (FD), to również A →→ B (MVD), gdzie zbiór wartości B ma dokładnie jeden element. Dlatego BCNF jest szczególnym przypadkiem 4NF: jeśli tabela jest w 4NF, to automatycznie jest w BCNF, ale nie odwrotnie.

MVD powstaje, gdy jeden obiekt (encji) ma dwa lub więcej atrybutów, które mogą przyjmować wiele wartości, a te wartości są od siebie niezależne. Typowe przykłady to: osoba z wieloma telefonami i emailami, książka z wieloma autorami i kategoriami, student z wieloma przedmiotami i hobby. We wszystkich tych przypadkach mamy jeden obiekt i dwie (lub więcej) niezależne listy.

Warunkiem koniecznym do powstania MVD jest niezależność list. Jeśli atrybuty są zależne, to nie ma MVD. Na przykład: jeśli książka ma wielu autorów, ale każdy autor jest przypisany do konkretnego rozdziału (a rozdziały są różne), to nie ma MVD między autorem a rozdziałem – są one zależne, bo konkretny autor napisał konkretny rozdział.

W bibliotece typowym przypadkiem MVD są dane kontaktowe czytelników. Każdy czytelnik może mieć wiele telefonów (komórkowy, stacjonarny, służbowy) i wiele emaili (prywatny, służbowy). Liczba telefonów nie ma związku z liczbą emaili – czytelnik może mieć 3 telefony i 2 emaile, 1 telefon i 5 emaili, etc. To właśnie niezależność list generuje MVD.

Problem dwóch niezależnych faktów w jednej tabeli polega na tym, że przechowujemy w jednym miejscu informacje, które nie są ze sobą bezpośrednio powiązane. Tabela DaneKontaktowe (ID_Czytelnika, Telefon, Email) przechowuje dwa rodzaje faktów: "czytelnik ma numer telefonu" i "czytelnik ma adres email". Te dwa fakty są niezależne, ale tabela wymusza sztuczne połączenie między nimi.

Produkt kartezjański powstaje, gdy dla czytelnika z 2 telefonami i 3 emailami musimy utworzyć 6 wierszy, bo każdy telefon musi być sparowany z każdym emailem. To nie jest rzeczywista zależność między danymi – to artefakt struktury tabeli. W rzeczywistości czytelnik ma po prostu 2 telefony i 3 emaile, a nie 6 "par telefon-email".

Problem narasta wykładniczo z liczbą wartości. Dla czytelnika z 10 telefonami i 20 emailami, w BCNF otrzymamy 200 wierszy. Po normalizacji do 4NF: 10 + 20 = 30 wierszy. Różnica 170 wierszy to nie tylko większe zużycie pamięci, ale przede wszystkim źródło potencjalnych anomalii przy każdej operacji INSERT, UPDATE i DELETE.

Wizualizacja produktu kartezjańskiego na przykładzie Jana Kowalskiego pokazuje skalę problemu. Jan ma 2 telefony ('123-456-789' i '987-654-321') oraz 3 emaile ('jan@example.com', 'jan.kowalski@work.com', 'j.k@proton.com'). W tabeli naruszającej 4NF pojawia się 6 wierszy, w których każdy telefon jest powtórzony 3 razy (raz dla każdego emaila), a każdy email 2 razy (raz dla każdego telefonu).

Ta redundancja jest nie tylko marnotrawstwem miejsca, ale przede wszystkim źródłem ryzyka. Jeśli Jan zmieni jeden ze swoich emaili, trzeba zaktualizować 2 wiersze (dla każdego telefonu). Jeśli programista zapomni zaktualizować jeden z nich, dane staną się niespójne – część wierszy będzie miała stary email, a część nowy.

Dodatkowo, taka struktura sugeruje, że istnieje związek między konkretnym telefonem a konkretnym emailem (np. '123-456-789' jest "sparowany" z 'jan@example.com'), podczas gdy w rzeczywistości żaden taki związek nie istnieje. To wprowadza w błąd każdego, kto analizuje dane, i może prowadzić do błędnych wniosków biznesowych.

Anomalie w tabeli z MVD to dokładnie te same typy problemów, które znamy z wcześniejszych postaci normalnych: nadmiarowość przy INSERT-ach, ryzyko niespójności przy UPDATE-ach i utrata informacji przy DELETE-ach. Różnica polega na źródle problemu: podczas gdy w 2NF/3NF anomalie wynikały z nieprawidłowych FD, tutaj wynikają z MVD.

INSERT: dodanie nowego telefonu dla czytelnika wymaga wstawienia nowego wiersza dla KAŻDEGO istniejącego emaila. Jeśli czytelnik ma 20 emaili, jeden nowy telefon generuje 20 INSERT-ów. Co gorsza, jeśli chcemy dodać telefon, ale nie znamy jeszcze emaili czytelnika, nie możemy tego zrobić – musielibyśmy wstawić wiersze z NULL-ami lub wymyślonymi wartościami.

DELETE i UPDATE działają symetrycznie: usunięcie emaila wymaga usunięcia wiersza dla każdego telefonu, a zmiana numeru telefonu wymaga aktualizacji wiersza dla każdego emaila. Wszystkie te anomalie znikają po zastosowaniu 4NF, ponieważ każda niezależna lista trafia do osobnej tabeli, gdzie operacje DDL są proste i bezpieczne.

Anomalia INSERT w tabeli naruszającej 4NF jest szczególnie uciążliwa, bo wymaga dodania wielu wierszy dla jednej logicznej operacji. W przykładzie z biblioteką, dodanie nowego telefonu '555-123-456' dla Jana Kowalskiego wymaga trzech INSERT-ów – po jednym dla każdego z jego emaili.

Problem staje się jeszcze bardziej widoczny, gdy czytelnik ma wiele emaili. Jeśli Anna Nowak ma 50 emaili, dodanie dla niej jednego nowego telefonu wymaga 50 INSERT-ów. To nie tylko problem wydajnościowy, ale przede wszystkim ryzyko błędu: jeśli zabraknie jednego INSERT-a, dane będą niespójne.

Co więcej, jeśli chcemy dodać telefon dla nowego czytelnika, który nie ma jeszcze żadnego emaila, nie możemy tego zrobić w tej strukturze. Klucz główny wymaga, aby każdy wiersz miał zarówno telefon, jak i email. Musielibyśmy najpierw dodać "sztuczny" email (np. NULL lub pusty string), co narusza integralność danych. To klasyczny przykład, jak zła struktura tabeli wymusza złe praktyki.

Anomalia DELETE w tabeli z MVD jest równie poważna. Usunięcie jednego emaila dla czytelnika wymaga usunięcia wszystkich wierszy, w których ten email występuje – czyli po jednym dla każdego telefonu czytelnika. W przykładzie, usunięcie emaila 'jan.kowalski@work.com' dla Jana Kowalskiego wymaga dwóch DELETE-ów (dla telefonu '123-456-789' i '987-654-321').

Jeszcze gorsza sytuacja ma miejsce, gdy chcemy usunąć wszystkie emaile czytelnika (np. czytelnik zrezygnował z korespondencji emailowej). Wtedy tracimy również informację o jego telefonach, bo całe wiersze są usuwane. To nieodwracalna utrata danych – telefonów nie da się odzyskać, bo były przechowywane w tych samych wierszach co emaile.

W 4NF każda lista jest przechowywana osobno, więc usunięcie emaila dotyczy tylko tabeli Emaile – telefony pozostają nienaruszone. To fundamentalna różnica: 4NF izoluje niezależne fakty, chroniąc je przed skutkami operacji na innych, niezależnych faktach.

Anomalia UPDATE w tabeli z MVD jest być może najgroźniejsza, bo prowadzi do niespójności danych, która może pozostać niezauważona. Zmiana numeru telefonu dla czytelnika wymaga aktualizacji wszystkich wierszy, w których ten numer występuje – czyli po jednym dla każdego emaila. W przykładzie, zmiana numeru z '123-456-789' na '111-222-333' wymaga trzech UPDATE-ów.

Jeśli z jakiegoś powodu tylko dwa z trzech UPDATE-ów się wykonają (np. błąd sieci, przerwanie transakcji), w bazie pozostaną wiersze z oboma numerami: część wierszy będzie miała nowy numer, a część stary. Baza danych będzie zawierać sprzeczne informacje – który numer jest prawdziwy? System nie ma jak tego stwierdzić.

W 4NF zmiana numeru telefonu to jeden UPDATE w tabeli Telefony. Prosty, atomowy, bezpieczny. Nie ma ryzyka pominięcia któregoś wiersza, bo każdy fakt (telefon) występuje dokładnie raz w bazie. To jedna z największych zalet normalizacji: każdy fakt jest przechowywany w jednym miejscu, więc jego aktualizacja jest zawsze prosta i bezpieczna.

Definicja 4NF jest zaskakująco prosta: relacja jest w 4NF, jeśli jest w BCNF i każda nietrywialna zależność wielowartościowa (MVD) w tej relacji wynika z klucza głównego (tzn. lewa strona MVD jest nadkluczem). Innymi słowy: 4NF = BCNF + warunek na MVD. To pokazuje, że 4NF jest naturalnym rozszerzeniem BCNF na nowy typ zależności.

Warunek "A jest nadkluczem" oznacza, że jeśli mamy MVD A →→ B, to A musi jednoznacznie identyfikować każdy wiersz w tabeli. W naszym przykładzie, w tabeli DaneKontaktowe mamy MVD ID_Czytelnika →→ Telefon. ID_Czytelnika nie jest nadkluczem (kluczem jest (ID_Czytelnika, Telefon, Email)), więc tabela narusza 4NF.

Gdy rozdzielimy dane na Telefony i Emaile, w tabeli Telefony MVD ID_Czytelnika →→ Telefon staje się trywialna, bo ID_Czytelnika ∪ Telefon = wszystkie atrybuty tabeli. MVD trywialna nie narusza 4NF. Podobnie w tabeli Emaile. Zatem po dekompozycji obie tabele są w 4NF.

Warunki 4NF można rozbić na dwa szczegółowe wymagania. Po pierwsze, tabela musi być w BCNF – to znaczy, że nie ma nielegalnych zależności funkcyjnych. To jest warunek wstępny, który zakładamy przed rozważaniem 4NF. Po drugie, dla każdej nietrywialnej MVD A →→ B, A musi być nadkluczem. To jest warunek właściwy dla 4NF.

Kluczowe jest rozróżnienie między MVD "naturalną" (wynikającą z klucza) a "problemową" (nie wynikającą z klucza). Jeśli A jest nadkluczem, to MVD A →→ B jest naturalną konsekwencją struktury klucza – nie ma w niej niczego podejrzanego. Jeśli A nie jest nadkluczem, to MVD wskazuje na istnienie niezależnych list w tabeli, które należy rozdzielić.

W przykładzie DaneKontaktowe, ID_Czytelnika →→ Telefon jest problemowe, bo ID_Czytelnika to nie nadklucz. Natomiast po dekompozycji, w tabeli Telefony, MVD ID_Czytelnika →→ Telefon jest naturalne (choć trywialne), bo ID_Czytelnika w połączeniu z Telefonem tworzy klucz.

Porównanie BCNF i 4NF można ująć w prosty schemat: BCNF dotyczy FD (zależności funkcyjnych), 4NF dotyczy MVD (zależności wielowartościowych). BCNF wymaga, aby każdy wyznacznik FD był nadkluczem. 4NF dodaje wymaganie, aby każdy wyznacznik MVD był nadkluczem. To analogiczne podejście do dwóch różnych typów zależności.

W kontekście historycznym: BCNF powstała w 1974 roku jako odpowiedź na ograniczenia 3NF (problem nakładających się kluczy). 4NF pojawiła się trzy lata później (Fagin, 1977) jako odpowiedź na odkrycie MVD. To pokazuje, że teoria normalizacji rozwijała się stopniowo, w miarę odkrywania coraz subtelniejszych typów zależności między danymi.

W praktyce oznacza to, że jeśli tabela jest w BCNF, to nie znaczy automatycznie, że jest w 4NF. Ale jeśli tabela jest w 4NF, to automatycznie jest w BCNF. 4NF jest bardziej restrykcyjna, bo nakłada dodatkowy warunek na MVD. To tak, jakby BCNF była egzaminem z FD, a 4NF egzaminem z FD + MVD.

Nie każda MVD stanowi problem dla 4NF. MVD trywialne to takie, które są zawsze prawdziwe niezależnie od danych. Są dwa przypadki: gdy B ⊆ A (lewa strona zawiera prawą, np. (ID, Telefon) →→ ID) lub gdy A ∪ B = R (wszystkie atrybuty tabeli). MVD trywialne nie wpływają na 4NF, ponieważ nie wskazują na istnienie niezależnych list.

MVD nietrywialne to takie, które nie są trywialne – czyli B nie jest podzbiorem A i A ∪ B ≠ R. To właśnie te MVD są problematyczne w kontekście 4NF. W tabeli DaneKontaktowe, ID_Czytelnika →→ Telefon jest nietrywialne, bo Telefon nie jest podzbiorem {ID_Czytelnika}, a ID_Czytelnika ∪ Telefon nie zawiera Emaila.

Po dekompozycji do 4NF, tabela Telefony ma atrybuty (ID_Czytelnika, Telefon). MVD ID_Czytelnika →→ Telefon jest tutaj trywialna, bo ID_Czytelnika ∪ Telefon = wszystkie atrybuty. To samo dotyczy tabeli Emaile. Dlatego po dekompozycji obie tabele spełniają 4NF.

Algorytm dekompozycji do 4NF jest prosty i powtarzalny: dla każdej nietrywialnej MVD A →→ B, gdzie A nie jest nadkluczem, dzielimy tabelę na dwie: (A, B) i (A, C), gdzie C = R – A – B (pozostałe atrybuty). Następnie powtarzamy proces dla każdej z nowych tabel, aż wszystkie MVD będą trywialne lub wynikać z kluczy.

W przykładzie bibliotecznym, tabela DaneKontaktowe ma dwie MVD: ID_Czyt →→ Telefon i ID_Czyt →→ Email. Stosując algorytm: dla MVD ID_Czyt →→ Telefon tworzymy (ID_Czyt, Telefon, TypTel) i (ID_Czyt, Email). Dla MVD ID_Czyt →→ Email tworzymy (ID_Czyt, Email, TypEmail). Rezultat: trzy tabele (Czytelnicy, Telefony, Emaile), każda w 4NF.

Ważna uwaga: algorytm gwarantuje dekompozycję bezstratną, co oznacza, że złączenie nowych tabel da dokładnie oryginalne dane. Nie tracimy żadnych informacji, a zyskujemy czystą strukturę pozbawioną redundancji i anomalii.

Weryfikacja 4NF po dekompozycji polega na sprawdzeniu, czy w nowych tabelach nie ma nietrywialnych MVD, które nie wynikają z kluczy. W tabeli Telefony (ID_Czytelnika, Telefon) sprawdzamy: czy istnieje MVD ID_Czytelnika →→ Telefon? Tak, ale jest trywialna, bo ID_Czytelnika ∪ Telefon = wszystkie atrybuty. Zatem 4NF spełniona.

Analogicznie dla tabeli Emaile (ID_Czytelnika, Email): MVD ID_Czytelnika →→ Email jest trywialna z tego samego powodu. Oryginalna tabela Czytelnicy (ID_Czytelnika, Imie, Nazwisko, ID_Miasta) nie ma żadnych MVD – nie ma atrybutów wielokrotnych. Zatem wszystkie trzy tabele są w 4NF.

Weryfikacja jest ważnym krokiem, bo pozwala upewnić się, że dekompozycja nie wprowadziła nowych problemów. W praktyce, jeśli stosujemy algorytm dekompozycji poprawnie, nowe tabele zawsze są w 4NF. Niemniej warto sprawdzić, czy nie pominięto którejś MVD, zwłaszcza gdy tabela miała wiele atrybutów i złożone zależności.

4NF jest rzadziej potrzebna niż BCNF, ponieważ MVD występują rzadziej niż FD. Szacuje się, że około 90% baz danych zatrzymuje się na 3NF, 9% na BCNF, a tylko 1% dociera do 4NF. To nie znaczy, że 4NF jest nieistotna – znaczy, że w większości przypadków struktura danych jest na tyle prosta, że MVD nie występują.

Typowe sytuacje, w których MVD się pojawiają, to dane kontaktowe (wiele telefonów, emaili), systemy tagowania (wiele tagów dla obiektu), role użytkowników (wiele ról), kategorie produktów (wiele kategorii). Wszędzie tam, gdzie jeden obiekt ma dwie lub więcej niezależnych list wartości, 4NF może być potrzebna.

W wielu komercyjnych systemach 4NF jest pomijana, a programiści akceptują produkt kartezjański jako "cenę za prostotę". Dla małych danych (np. średnio 2 telefony i 2 emaile na czytelnika) różnica jest niewielka. Jednak dla systemów z dużymi wolumenami danych (np. system CRM z milionami klientów) 4NF może przynieść znaczące oszczędności miejsca i poprawić wydajność.

Ćwiczenie 1 polega na identyfikacji MVD w tabeli AutorzyKsiazki (ISBN, Autor, Kategoria, Jezyk). Każda książka może mieć wielu autorów, wiele kategorii i być w wielu językach. Są to trzy niezależne listy: autorzy nie zależą od kategorii, kategorie nie zależą od języka, itd. Zatem mamy trzy MVD: ISBN →→ Autor, ISBN →→ Kategoria, ISBN →→ Jezyk.

ISBN nie jest nadkluczem – kluczem jest (ISBN, Autor, Kategoria, Jezyk). Zatem tabela nie jest w 4NF. Rozwiązanie: dekompozycja na trzy tabele: Autorzy (ISBN, Autor), Kategorie (ISBN, Kategoria), Jezyki (ISBN, Jezyk). Każda z tych tabel przechowuje jedną niezależną listę i jest w 4NF.

To ćwiczenie pokazuje, że liczba MVD w tabeli może być większa niż dwie. W tabeli z czterema atrybutami i trzema niezależnymi listami mamy trzy MVD. Każda z nich wymaga osobnej tabeli. W efekcie z jednej tabeli otrzymujemy trzy, co eliminuje produkt kartezjański między wszystkimi trzema listami.

Ćwiczenie 2 polega na zaprojektowaniu dekompozycji tabeli AutorzyKsiazki (ISBN, Autor, Kategoria, Jezyk) do 4NF. Mamy trzy MVD: ISBN →→ Autor, ISBN →→ Kategoria, ISBN →→ Jezyk. Stosując algorytm dekompozycji, tworzymy trzy tabele: Autorzy (ISBN, Autor), Kategorie (ISBN, Kategoria), Jezyki (ISBN, Jezyk).

Każda z nowych tabel ma prosty klucz złożony z dwóch atrybutów. W tabeli Autorzy kluczem jest (ISBN, Autor). MVD ISBN →→ Autor jest teraz trywialna, bo ISBN ∪ Autor = wszystkie atrybuty tabeli. Podobnie dla pozostałych tabel. Wszystkie trzy są zatem w 4NF.

Warto zwrócić uwagę na to, że w oryginalnej tabeli produkt kartezjański występuje między trzema listami naraz. Dla książki z 2 autorami, 3 kategoriami i 2 językami, w 4NF mamy 2 + 3 + 2 = 7 wierszy. Przed 4NF: 2 × 3 × 2 = 12 wierszy. Różnica będzie rosnąć wykładniczo z liczbą wartości na każdej liście.

Ćwiczenie 3 analizuje tabelę Czytelnicy z BD_3NF: (ID_Czyt, Imie, Nazwisko, ID_Miasta, Telefon, Email). Kluczowe pytanie: czy przechowywanie Telefonu i Emaila w tej samej tabeli narusza 4NF? Odpowiedź: tak, jeśli czytelnik może mieć wiele telefonów i wiele emaili.

W tabeli Czytelnicy z BD_3NF zakładaliśmy, że każdy czytelnik ma jeden telefon i jeden email. W takim przypadku nie ma MVD – nie ma niezależnych list, bo każda lista ma dokładnie jeden element. Tabela jest w BCNF i jednocześnie w 4NF. Problem pojawia się dopiero, gdy dopuścimy wiele telefonów i wiele emaili.

To ćwiczenie uczy ważnej lekcji: 4NF nie jest potrzebna automatycznie. Jest potrzebna tylko wtedy, gdy faktycznie występują niezależne listy wartości. Jeśli w systemie biznesowym każdy czytelnik ma dokładnie jeden telefon i jeden email, to 4NF jest spełniona automatycznie. Normalizacja nie powinna być "sztuką dla sztuki" – powinna odpowiadać rzeczywistym potrzebom.

Scenariusz systemu kontaktów w bibliotece jest praktycznym przykładem, który pokazuje, jak 4NF znajduje zastosowanie w rzeczywistym systemie. Biblioteka gromadzi dane kontaktowe czytelników: każdy czytelnik może podać wiele numerów telefonów (komórkowy, stacjonarny, służbowy) i wiele adresów email (prywatny, służbowy). Telefony i emaile są od siebie niezależne.

Dodatkowo, każdy telefon ma swój typ (komórkowy, stacjonarny), a każdy email ma swój typ (prywatny, służbowy). To są atrybuty zależne od konkretnego telefonu lub emaila – nie są niezależne. Typ telefonu jest zależny od telefonu, więc nie tworzy osobnej MVD. Podobnie typ emaila jest zależny od emaila.

W projekcie musimy zdecydować, czy przechowywać wszystkie dane w jednej tabeli (wygodnie, ale 4NF naruszona), czy rozdzielić na trzy tabele (bardziej złożone zapytania, ale czysta struktura). To klasyczny kompromis między prostotą a czystością danych, który projektant bazy musi rozważyć.

Pierwsza próba projektowa – jedna tabela DaneKontaktowe (ID_Czytelnika, Telefon, Email) – jest wygodna, ale narusza 4NF. Schemat jest prosty, zapytania są łatwe do napisania, a aplikacja może korzystać z jednej tabeli zamiast trzech. Jednak ta wygoda ma swoją cenę: produkt kartezjański i wynikające z niego anomalie.

Z punktu widzenia BCNF tabela jest poprawna: jedyną FD jest (ID_Czytelnika, Telefon, Email) → (ID_Czytelnika, Telefon, Email), która jest trywialna. Nie ma żadnych "nielegalnych" FD. BCNF nie zgłasza zastrzeżeń. Ale 4NF już tak: MVD ID_Czytelnika →→ Telefon i ID_Czytelnika →→ Email nie wynikają z klucza.

To ważna lekcja: BCNF można porównać do kontroli biletów, która sprawdza, czy każdy pasażer ma bilet. Jeśli wszyscy mają bilety, kontrola mówi "OK". Ale kontrola nie sprawdza, czy pasażerowie nie siedzą na cudzych miejscach (produkt kartezjański). 4NF to dodatkowa kontrola, która sprawdza właśnie to.

Przykładowi czytelnicy – Jan Kowalski i Anna Nowak – pokazują skalę problemu z 4NF. Jan ma 2 telefony i 3 emaile, co w tabeli naruszającej 4NF daje 6 wierszy. Anna ma 1 telefon i 2 emaile, co daje 2 wiersze. Łącznie: 8 wierszy dla dwojga czytelników. Po normalizacji do 4NF: Jan: 2 + 3 = 5 wierszy, Anna: 1 + 2 = 3 wiersze. Łącznie: 8 wierszy.

W tym przypadku różnica nie jest duża (8 wierszy w obu przypadkach), ale to dlatego, że dane są małe. W rzeczywistym systemie z tysiącami czytelników, każdy średnio z 3 telefonami i 4 emailami, różnica jest znacząca: przed 4NF: 1000 × 3 × 4 = 12 000 wierszy, po 4NF: 1000 × (3 + 4) = 7 000 wierszy.

Co więcej, różnica rośnie proporcjonalnie do iloczynu liczby telefonów i emaili. Dla czytelnika z 10 telefonami i 20 emailami: przed 4NF = 200 wierszy, po 4NF = 30 wierszy. Przy 50 telefonach i 100 emailach: 5000 vs 150 wierszy. To pokazuje, że 4NF jest tym bardziej opłacalna, im więcej wartości wielokrotnych ma obiekt.

Wizualizacja danych Jana Kowalskiego w tabeli naruszającej 4NF pokazuje produkt kartezjański w akcji. Telefon '123-456-789' pojawia się 3 razy (dla każdego emaila), a email 'jan@example.com' pojawia się 2 razy (dla każdego telefonu). W tabeli jest 6 wierszy, każdy z pełną informacją o typie telefonu i typie emaila.

Redundancja jest widoczna gołym okiem: dane o typie telefonu są powtórzone 3 razy (dla '123-456-789') i 3 razy (dla '987-654-321'). To łącznie 6 powtórzeń informacji, która w 4NF wystąpiłaby tylko 2 razy (raz na telefon). Dla 10 telefonów i 20 emaili, typ telefonu byłby powtórzony 20 razy dla każdego telefonu – czysta strata miejsca.

Produkt kartezjański jest szczególnie niebezpieczny, gdy w grę wchodzą dane wrażliwe (np. numery telefonów, adresy email). W przypadku wycieku danych, każdy wiersz zawiera kompletny zestaw danych kontaktowych, a nie tylko jeden fakt. 4NF ogranicza ryzyko, bo każda tabela przechowuje tylko jeden rodzaj danych.

Anomalia w praktyce – zmiana emaila Jana z 'jan@example.com' na 'jan.nowy@example.com' – ilustruje ryzyko niespójności. W tabeli naruszającej 4NF trzeba zaktualizować 2 wiersze (dla każdego telefonu). Jeśli jedna z aktualizacji się nie powiedzie, w bazie pozostanie jeden wiersz ze starym emailem i jeden z nowym.

Konsekwencje: biblioteka wysyła powiadomienia na oba adresy – stary (nieaktywny) i nowy. Albo, co gorsza, system wyświetla oba emaile w profilu czytelnika, dezorientując zarówno personel, jak i samego czytelnika. W 4NF zmiana emaila to jeden UPDATE w tabeli Emaile – atomowy, bezpieczny, niezawodny.

Ten przykład pokazuje, że normalizacja to nie tylko teoria, ale praktyczne narzędzie do zapewnienia integralności danych. W środowisku produkcyjnym, gdzie tysiące transakcji są wykonywane równolegle przez wielu użytkowników, ryzyko pominięcia jednej z wielu aktualizacji jest realne. 4NF eliminuje to ryzyko u źródła.

Rozwiązanie 4NF: dekompozycja na trzy tabele – Czytelnicy, Telefony, Emaile. Każda tabela przechowuje jeden rodzaj faktów. Czytelnicy: dane osobowe (stałe, jeden wiersz na czytelnika). Telefony: numery telefonów (wiele wierszy na czytelnika). Emaile: adresy email (wiele wierszy na czytelnika). Żadna tabela nie miesza dwóch niezależnych list.

Po dekompozycji, dodanie nowego telefonu to jeden INSERT w tabeli Telefony. Zmiana emaila to jeden UPDATE w tabeli Emaile. Usunięcie telefonu to jeden DELETE w tabeli Telefony. Każda operacja jest atomowa i dotyczy dokładnie jednego faktu. Nie ma ryzyka pominięcia którejś z wielu operacji, nie ma produktu kartezjańskiego.

Kosztem tej czystości jest konieczność używania JOIN-ów do odczytu wszystkich danych kontaktowych czytelnika. SELECT z JOIN-em trzech tabel (Czytelnicy LEFT JOIN Telefony LEFT JOIN Emaile) daje produkt kartezjański w wyniku – ale to tylko tymczasowy wynik zapytania, a nie struktura danych. To fundamentalna różnica.

Porównanie przed i po 4NF pokazuje, że korzyści rosną wraz z ilością danych. Dla Jana (2 telefony, 3 emaile): przed 4NF = 6 wierszy, po 4NF = 5 wierszy (2 + 3). Dla Anny (1 telefon, 2 emaile): przed 4NF = 2 wiersze, po 4NF = 3 wiersze (1 + 2). W przypadku Anny liczba wierszy nawet wzrosła – to dlatego, że dane są małe, a struktura została "rozdzielona".

Dla całej biblioteki z 10 000 czytelników, każdy średnio z 3 telefonami i 4 emailami: przed 4NF: 10 000 × 3 × 4 = 120 000 wierszy. Po 4NF: 10 000 × (3 + 4) = 70 000 wierszy. Oszczędność 50 000 wierszy to nie tylko miejsce na dysku, ale przede wszystkim szybsze indeksowanie, mniejsze zapotrzebowanie na pamięć podręczną i sprawniejsze zapytania.

Co więcej, w 4NF każda tabela ma prostszy indeks (dwie kolumny zamiast pięciu), co przyspiesza operacje wyszukiwania. A brak anomalii oznacza, że programiści mogą pisać prostszy kod aplikacji bez ryzyka niespójności danych. To oszczędność czasu i pieniędzy w dłuższej perspektywie.

Przykład tagów i kategorii książek pokazuje, że 4NF znajduje zastosowanie w wielu kontekstach, nie tylko w danych kontaktowych. Tabela KsiazkiTagiKategorie (ISBN, Tag, Kategoria) przechowuje dwa niezależne fakty: "książka ma tag" i "książka należy do kategorii". Tagi i kategorie są niezależne, więc mamy MVD ISBN →→ Tag i ISBN →→ Kategoria.

Rozwiązanie 4NF: Tagi (ISBN, Tag) i Kategorie (ISBN, Kategoria). Każda tabela przechowuje jedną listę. Produkt kartezjański między tagami a kategoriami znika. Dla książki z 5 tagami i 3 kategoriami: przed 4NF = 15 wierszy, po 4NF = 8 wierszy.

To samo dotyczy wielu innych domen: systemów e-commerce (produkt z wieloma kolorami i rozmiarami), systemów rezerwacji (hotel z wieloma pokojami i udogodnieniami), platform społecznościowych (użytkownik z wieloma grupami i zainteresowaniami). Wszędzie tam, gdzie jeden obiekt ma wiele niezależnych list wartości, 4NF jest odpowiedzią.

Ostateczny schemat biblioteki po dodaniu 4NF składa się z 8 tabel: 6 dotychczasowych (Czytelnicy, Miasta, Ksiazki, Wypozyczenia, Opiekunowie, Przypisania_BCNF) plus 2 nowe (Telefony, Emaile). Każda z tych tabel jest w 4NF, co oznacza, że żadna nie zawiera nietrywialnych MVD niewynikających z kluczy.

W porównaniu do schematu z BCNF, dodaliśmy dwie tabele, ale zyskaliśmy czystość danych i brak anomalii. Czytelnicy nie przechowują już telefonów ani emaili – te informacje są w osobnych tabelach, połączonych kluczami obcymi. Każdy fakt jest przechowywany dokładnie raz, w odpowiedniej tabeli.

To dobry moment, aby podkreślić, że normalizacja to proces iteracyjny. Nie trzeba od razu projektować bazy w 4NF – można zacząć od 3NF, potem sprawdzić BCNF, a na końcu 4NF. Każdy krok dodaje czystości, ale też złożoności. Decyzja o tym, jak daleko iść, zależy od konkretnych wymagań systemu.

Ćwiczenie z tabelą StudenciZainteresowania (ID_Studenta, Przedmiot, Hobby, JezykObcy) to samodzielne zadanie do przećwiczenia. Mamy trzy niezależne listy dla każdego studenta: przedmioty, hobby i języki obce. Trzy MVD: ID_Studenta →→ Przedmiot, ID_Studenta →→ Hobby, ID_Studenta →→ JezykObcy.

Rozwiązanie: dekompozycja na trzy tabele: Przedmioty (ID_Studenta, Przedmiot), Hobby (ID_Studenta, Hobby), JezykiObce (ID_Studenta, JezykObcy). Każda tabela w 4NF. Dla studenta z 4 przedmiotami, 3 hobby i 2 językami: przed 4NF = 24 wiersze, po 4NF = 9 wierszy.

Zachęcamy do samodzielnego przeanalizowania innych przykładów: lekarz z wieloma specjalizacjami i gabinetami, klient z wieloma adresami i numerami telefonów, produkt z wieloma wariantami i kolorami. Im więcej przykładów przerobisz, tym łatwiej będzie Ci rozpoznawać MVD w rzeczywistych systemach.

Ćwiczenie z bazą noclegów: tabela HoteleWyposazenie (ID_Hotelu, NazwaHotelu, Pokoj, Udogodnienie) zawiera dane o hotelach. Każdy hotel ma nazwę, listę pokoi i listę udogodnień. Pokój i udogodnienie są niezależne – liczba pokoi nie ma związku z liczbą udogodnień. Mamy MVD: ID_Hotelu →→ Pokoj i ID_Hotelu →→ Udogodnienie.

Rozwiązanie: dekompozycja na trzy tabele: Hotele (ID_Hotelu, NazwaHotelu), Pokoje (ID_Hotelu, Pokoj), Udogodnienia (ID_Hotelu, Udogodnienie). Każda tabela w 4NF. Dla hotelu z 10 pokojami i 5 udogodnieniami: przed 4NF = 50 wierszy, po 4NF = 15 wierszy.

To ćwiczenie pokazuje, że 4NF jest uniwersalna – nie zależy od domeny, tylko od struktury zależności. W każdym systemie, gdzie jeden obiekt ma dwie lub więcej niezależnych list wartości, 4NF jest potrzebna. Umiejętność rozpoznawania MVD w różnych kontekstach to kluczowa kompetencja projektanta baz danych.

Podsumowując: 4NF stosujemy, gdy w tabeli występują niezależne listy wartości dla tego samego obiektu. Objawy ostrzegawcze to produkt kartezjański w danych (gwałtowny wzrost liczby wierszy), konieczność wykonywania wielu INSERT-ów/UPDATE-ów/DELETE-ów dla jednej logicznej operacji oraz widoczna redundancja (te same wartości powtarzane wielokrotnie).

Nie stosujemy 4NF, gdy listy są zależne (np. telefon i typ telefonu – typ zależy od telefonu) lub gdy koszt JOIN-ów przewyższa korzyści z eliminacji redundancji. Dla małych danych (np. średnio 1-2 wartości na listę) 4NF może być przesadą, choć czystość struktury jest zawsze wartością samą w sobie.

Pamiętaj: normalizacja to narzędzie, nie cel. Celem jest integralność i spójność danych. Jeśli 4NF pomaga ten cel osiągnąć – stosuj ją. Jeśli przeszkadza (np. dramatycznie spowalnia zapytania) – rozważ kompromis. Dobry projektant baz danych wie, kiedy normy są pomocne, a kiedy stanowią przeszkodę.

Implementacja w MariaDB rozpoczyna się od utworzenia tabeli naruszającej 4NF – DaneKontaktowe (ID_Czytelnika, Telefon, Email). Kod CREATE TABLE jest prosty, a klucz główny jest złożony ze wszystkich trzech kolumn. Z punktu widzenia składni SQL wszystko jest poprawne – MariaDB nie ostrzeże nas przed MVD, bo system zarządzania bazą danych nie analizuje zależności wielowartościowych.

To ważny punkt: normalizacja jest zadaniem projektanta, nie systemu bazodanowego. MariaDB (ani żaden inny popularny RDBMS) nie sprawdzi automatycznie, czy tabela jest w 4NF. To odpowiedzialność projektanta, aby przeanalizować zależności i zaprojektować tabelę zgodnie z regułami normalizacji.

W kodzie SQL widać, że tabela jest w BCNF – nie ma FD poza kluczem. Komentarz ostrzega przed MVD, które naruszają 4NF. W praktyce warto dodawać takie komentarze w kodzie DDL, aby dokumentować, dlaczego tabela ma taką, a nie inną strukturę i jakie zależności zostały wzięte pod uwagę.

Wstawienie danych do tabeli naruszającej 4NF pokazuje skalę redundancji w praktyce. Dla Jana Kowalskiego (2 telefony, 3 emaile) musimy wykonać 6 INSERT-ów, każdy z pełnym zestawem danych. Kod jest długi, podatny na błędy (łatwo pominąć jedną kombinację) i nieczytelny – 6 wierszy dla danych, które logicznie są tylko 2 + 3 = 5 faktami.

W kodzie SQL widać wyraźnie powtarzające się wartości: telefon '123-456-789' z typem 'Komórkowy' pojawia się 3 razy, email 'jan@example.com' z typem 'Prywatny' pojawia się 2 razy. To marnotrawstwo przestrzeni dyskowej i pasma sieciowego przy przesyłaniu danych.

Dla porównania, po dekompozycji do 4NF ten sam zestaw danych wymaga 2 INSERT-ów do tabeli Telefony i 3 INSERT-ów do tabeli Emaile. Łącznie 5 INSERT-ów, każdy prosty i czytelny. Różnica w objętości kodu SQL jest oczywista – 6 złożonych wierszy vs 5 prostych wierszy.

Rozdzielenie na dwie tabele – Telefony i Emaile – to sedno implementacji 4NF. Każda tabela ma klucz główny złożony z ID_Czytelnika i odpowiednio Telefon lub Email. Klucz obcy do tabeli Czytelnicy zapewnia integralność referencyjną: nie można dodać telefonu dla nieistniejącego czytelnika.

Warto zwrócić uwagę na atrybuty TypTelefonu i TypEmaila. Są one funkcyjnie zależne od odpowiednio telefonu i emaila – nie tworzą MVD. TypTelefonu zależy od konkretnego numeru telefonu, a nie od czytelnika. Dlatego są one przechowywane w tej samej tabeli co telefon/email, a nie w osobnej tabeli.

Po tej dekompozycji, każda tabela przechowuje jeden niezależny fakt. Telefony: "czytelnik ma numer telefonu o określonym typie". Emaile: "czytelnik ma adres email o określonym typie". Żadna tabela nie miesza dwóch niezależnych faktów, więc 4NF jest spełniona.

Wstawianie danych po 4NF pokazuje zalety nowej struktury. Dwa INSERT-y do tabeli Telefony (dla dwóch numerów) i trzy INSERT-y do tabeli Emaile (dla trzech adresów). Łącznie 5 wierszy zamiast 6. Każdy wiersz jest prosty, zawiera tylko istotne dane, bez redundantnych powtórzeń.

Przy większych danych różnica jest jeszcze bardziej widoczna. Dla czytelnika z 10 telefonami i 20 emailami: przed 4NF = 200 INSERT-ów, po 4NF = 30 INSERT-ów. To 170 INSERT-ów mniej – oszczędność czasu przy wstawianiu danych i mniejsze obciążenie dziennika transakcyjnego bazy danych.

Dodatkowo, po 4NF możemy dodać telefon bez emaila (lub email bez telefonu) – nie jesteśmy zmuszeni do tworzenia sztucznych kombinacji. Nowy czytelnik może mieć tylko numer telefonu, a emaile dodać później. To naturalne i zgodne z rzeczywistością biznesową.

Test anomalii INSERT po 4NF: dodanie nowego telefonu '555-123-456' dla czytelnika to jeden INSERT w tabeli Telefony. Jeden wiersz, jedna operacja, zero ryzyka. Nie trzeba tworzyć kombinacji z emailami, nie trzeba sprawdzać, ile emaili ma czytelnik. Po prostu: INSERT INTO Telefony VALUES (1, '555-123-456', 'Komórkowy').

Przed 4NF ten sam telefon wymagałby INSERT-ów dla każdego emaila czytelnika. Jan ma 3 emaile → 3 INSERT-y. Gdyby Jan miał 50 emaili → 50 INSERT-ów. Liczba INSERT-ów zależy od liczby emaili, które są niezależne od telefonu – to absurdalna zależność, którą 4NF eliminuje.

Co więcej, po 4NF możemy dodać telefon dla czytelnika, który nie ma jeszcze żadnego emaila. W starej strukturze było to niemożliwe, bo klucz główny wymagał zarówno telefonu, jak i emaila. 4NF daje nam elastyczność, której BCNF nie zapewnia.

Test anomalii UPDATE po 4NF: zmiana numeru telefonu to jeden UPDATE w tabeli Telefony. UPDATE Telefony SET Telefon = '111-222-333' WHERE ID_Czytelnika = 1 AND Telefon = '123-456-789'. Jedna operacja, atomowa, bezpieczna. Niezależnie od tego, ile emaili ma czytelnik.

Przed 4NF ten sam UPDATE wymagał modyfikacji wielu wierszy – po jednym dla każdego emaila. Ryzyko niespójności było realne: jeśli baza danych ulegnie awarii podczas aktualizacji, część wierszy będzie miała stary numer, a część nowy. W 4NF takie ryzyko nie istnieje.

Dodatkowo, po 4NF UPDATE jest szybszy, bo dotyczy tylko jednego wiersza. Nie wymaga skanowania całej tabeli w poszukiwaniu wszystkich wierszy z danym numerem telefonu. Indeks na kolumnie Telefon szybko znajdzie odpowiedni wiersz, a aktualizacja jest błyskawiczna.

Test anomalii DELETE po 4NF: usunięcie emaila to jeden DELETE w tabeli Emaile. DELETE FROM Emaile WHERE ID_Czytelnika = 1 AND Email = 'jan.kowalski@work.com'. Jedna operacja, jeden wiersz. Telefony czytelnika pozostają nienaruszone – usunięcie emaila nie wpływa na informacje o telefonach.

Przed 4NF usunięcie emaila wymagało usunięcia wszystkich wierszy z tym emailem – po jednym dla każdego telefonu. Dwa DELETE-y dla czytelnika z 2 telefonami, 50 DELETE-ów dla czytelnika z 50 telefonami. Ryzyko pominięcia któregoś DELETE-a i pozostawienia niespójnych danych.

Co ważne, po 4NF możemy bezpiecznie usunąć wszystkie emaile czytelnika (np. czytelnik zrezygnował z korespondencji), nie tracąc informacji o jego telefonach. W starej strukturze usunięcie ostatniego emaila skutkowałoby usunięciem wszystkich wierszy, a wraz z nimi – informacji o telefonach. To nieodwracalna utrata danych.

Zapytania po 4NF wymagają JOIN-ów, ale to nie jest wada – to naturalna konsekwencja rozdzielenia niezależnych faktów. SELECT z LEFT JOIN trzech tabel (Czytelnicy, Telefony, Emaile) daje produkt kartezjański w wyniku, ale to tylko tymczasowa struktura – nie ma redundancji w danych źródłowych.

Warto podkreślić różnicę między produktem kartezjańskim w strukturze danych (złym) a produktem kartezjańskim w wyniku zapytania (neutralnym). W pierwszym przypadku dane są przechowywane redundantnie i podatne na anomalie. W drugim przypadku produkt kartezjański powstaje na żądanie, tylko na czas trwania zapytania, i nie wpływa na integralność danych.

MariaDB optymalizuje JOIN-y bardzo efektywnie, zwłaszcza gdy kolumny JOIN-u są indeksowane. W praktyce, dla dobrze zaprojektowanej bazy, zapytania z JOIN-ami są szybkie i wydajne. Koszt JOIN-ów jest zazwyczaj akceptowalny w porównaniu do korzyści z eliminacji redundancji i anomalii.

Funkcja GROUP_CONCAT w MariaDB jest niezwykle przydatna po normalizacji do 4NF. Pozwala na przekształcenie wielu wierszy w jedną listę wartości, co daje czytelny wynik zapytania bez produktu kartezjańskiego. Dla czytelnika z 2 telefonami i 3 emailami, GROUP_CONCAT zwróci jeden wiersz z listą telefonów i listą emaili.

Zapytanie z GROUP_CONCAT i DISTINCT gwarantuje, że w liście nie ma duplikatów. W przykładzie, GROUP_CONCAT(DISTINCT t.Telefon) zwróci '123-456-789,987-654-321' – jeden wiersz z dwoma numerami. Podobnie dla emaili. Wynik jest czytelny i zwięzły.

Warto pamiętać, że GROUP_CONCAT ma ograniczenie długości (domyślnie 1024 znaki, można zwiększyć do 8192). Dla bardzo długich list może być konieczne użycie innych technik (np. aplikacja kliencka scala wyniki). Mimo to, w większości przypadków GROUP_CONCAT jest idealnym narzędziem do prezentacji danych po normalizacji.

Weryfikacja 4NF w SQL polega na sprawdzeniu, czy w tabeli występują nietrywialne MVD. W MariaDB nie ma bezpośredniego polecenia do wykrywania MVD, ale można to zrobić analizując strukturę tabeli i zależności między atrybutami. W praktyce, jeśli tabela ma tylko jeden klucz kandydujący i wszystkie atrybuty są od niego zależne, to 4NF jest spełniona.

Dla tabeli Telefony: atrybuty to ID_Czytelnika, Telefon, TypTelefonu. Klucz: (ID_Czytelnika, Telefon). MVD ID_Czytelnika →→ Telefon? Tak, ale jest trywialna, bo ID_Czyt ∪ Telefon = R. Podobnie dla Emaile. Zatem obie tabele są w 4NF.

W komentarzach SQL warto udokumentować, dlaczego dana tabela jest w 4NF. To pomaga innym programistom zrozumieć strukturę i uniknąć przypadkowego naruszenia normalizacji przy późniejszych modyfikacjach schematu.

Porównanie wydajności przed i po 4NF: dla scenariusza z 10 czytelnikami, każdy średnio z 3 telefonami i 4 emailami, przed 4NF mamy 10 × 3 × 4 = 120 wierszy. Po 4NF: 10 × 3 + 10 × 4 = 70 wierszy. Oszczędność 50 wierszy (42% mniej). Przy skali 10 000 czytelników: 120 000 vs 70 000 wierszy – oszczędność 50 000 wierszy.

Oszczędność miejsca to nie tylko mniej danych na dysku. To również mniejsze indeksy (szybsze wyszukiwanie), mniejsze zapotrzebowanie na pamięć podręczną (więcej danych mieści się w RAM), szybsze operacje INSERT/UPDATE/DELETE (mniej wierszy do modyfikacji) i szybsze backup'y.

Warto jednak pamiętać, że zapytania SELECT z JOIN-ami mogą być wolniejsze niż SELECT z jednej tabeli. To kompromis: szybkie zapisy (INSERT/UPDATE/DELETE) kosztem wolniejszych odczytów (SELECT z JOIN). Dla systemów z częstymi zapisami i rzadkimi odczytami 4NF jest korzystna. Dla systemów z częstymi odczytami może być mniej opłacalna.

Typowe błędy przy implementacji 4NF: (1) Brak klucza obcego – Telefony.ID_Czytelnika musi być FK do Czytelnicy.ID_Czytelnika. Bez tego można dodać telefon dla nieistniejącego czytelnika, co narusza integralność. (2) Przesadna normalizacja – dzielenie tabeli, która nie ma MVD, tylko dlatego, że "tak wypada". Normalizacja ma sens tylko gdy jest uzasadniona.

(3) Mylenie FD z MVD – to najczęstszy błąd. FD: ID_Czyt → Nazwisko (jedno nazwisko). MVD: ID_Czyt →→ Telefon (wiele telefonów). FD może wymagać osobnej tabeli (jeśli nie wynika z klucza), ale z innych powodów niż MVD. Mylenie ich prowadzi do błędnej dekompozycji.

(4) Zakładanie MVD tam, gdzie ich nie ma. Nie każda tabela z wieloma wartościami ma MVD. Jeśli wartości są zależne (np. telefon i typ telefonu), to nie ma MVD – jest zwykła tabela z atrybutami. MVD wymaga niezależności list. Bez niezależności nie ma problemu i nie trzeba normalizować.

Porównanie postaci normalnych od 1NF do 4NF pokazuje ewolucję teorii normalizacji. Każda postać normalna rozwiązuje konkretny problem: 1NF – atomowość, 2NF – zależności częściowe, 3NF – zależności przechodnie, BCNF – nakładające się klucze FD, 4NF – zależności wielowartościowe. Każda kolejna postać jest bardziej restrykcyjna od poprzedniej.

Warto zapamiętać, że normalizacja to hierarchia: każda tabela w 4NF jest automatycznie w BCNF, 3NF, 2NF i 1NF. Ale tabela w 3NF nie musi być w BCNF, a tabela w BCNF nie musi być w 4NF. Im wyższa postać normalna, tym więcej warunków musi spełniać tabela.

Rok 1977 (4NF, Fagin) to 7 lat po pierwszej publikacji Codda o modelu relacyjnym. To pokazuje, że teoria normalizacji rozwijała się stopniowo, w miarę odkrywania coraz subtelniejszych zależności. Dziś normalizacja jest uznaną i dojrzałą dziedziną, ale wciąż wymaga od projektanta dogłębnego zrozumienia zależności w danych.

Podsumowanie 4NF w 5 punktach: (1) 4NF eliminuje MVD, czyli sytuacje, gdy jeden obiekt ma wiele niezależnych list wartości. (2) MVD różni się od FD – FD daje jedną wartość, MVD daje zbiór wartości. (3) Objawem naruszenia 4NF jest produkt kartezjański w danych i konieczność wykonywania wielu operacji DML dla jednej logicznej zmiany.

(4) Rozwiązaniem jest podział tabeli na osobne tabele dla każdej niezależnej listy. W przykładzie bibliotecznym: Telefony i Emaile osobno. (5) Warunkiem koniecznym jest, aby tabela była w BCNF. 4NF = BCNF + warunek na MVD. Bez BCNF nie ma 4NF.

Te 5 punktów warto zapamiętać jako checklistę przed podjęciem decyzji o normalizacji do 4NF. Jeśli wszystkie punkty są spełnione, 4NF jest prawdopodobnie potrzebna. Jeśli któryś nie jest spełniony, 4NF nie jest wymagana.

Kiedy stosować 4NF? Gdy masz niezależne listy wartości dla tego samego obiektu i widzisz produkt kartezjański w danych. Kiedy nie stosować? Gdy listy są zależne (np. telefon i typ telefonu) lub gdy koszt JOIN-ów przewyższa korzyści z eliminacji redundancji. Decyzja o normalizacji to zawsze kompromis.

W praktyce, dla systemów z małą liczbą wartości wielokrotnych (np. średnio 1-2 telefony, 1-2 emaile), 4NF może być przesadą. Dla systemów z dużą liczbą wartości (np. system CRM z wieloma kanałami komunikacji) 4NF jest koniecznością. Kluczem jest zrozumienie skali danych i wymagań biznesowych.

Pamiętaj: 4NF to narzędzie, a nie dogma. Jeśli Twoja baza danych działa dobrze w 3NF lub BCNF, nie musisz normalizować do 4NF. Normalizacja ma służyć integralności danych, a nie być celem samym w sobie. Dobry projektant wie, kiedy zakończyć normalizację.

Koszt 4NF to przede wszystkim więcej tabel i więcej JOIN-ów w zapytaniach. Zamiast jednej tabeli DaneKontaktowe mamy trzy: Czytelnicy, Telefony, Emaile. Każde zapytanie pobierające pełne dane kontaktowe wymaga LEFT JOIN dwóch dodatkowych tabel. To zwiększa złożoność zapytań i może wpływać na wydajność.

Jednak korzyści są znaczące: brak redundancji, brak anomalii, czysta struktura, oszczędność miejsca, prostsze operacje DML. Dla systemów z częstymi zapisami (INSERT/UPDATE/DELETE) korzyści przewyższają koszty. Dla systemów z częstymi odczytami (SELECT) koszty mogą przewyższać korzyści.

Rozwiązaniem kompromisowym jest użycie widoków (CREATE VIEW), które opakowują JOIN-y i prezentują dane w formie przypominającej jedną tabelę. Aplikacja korzysta z widoku jak z tabeli, a pod spodem dane są przechowywane w 4NF. To łączy zalety normalizacji z wygodą programistyczną.

Mapa normalizacji od 1NF do 5NF pokazuje, że 4NF jest przedostatnim krokiem. Za nami: 1NF (atomowość, 1970), 2NF (częściowe zależności, 1971), 3NF (przechodnie zależności, 1971), BCNF (nakładające się klucze, 1974). Przed nami: 5NF (złączeniowe zależności, 1979).

Każdy krok normalizacji eliminuje konkretny typ problemu. 4NF eliminuje problemy związane z MVD, czyli niezależnymi listami wartości. To ważny krok, bo MVD są częstsze niż się wydaje – występują wszędzie tam, gdzie jeden obiekt ma wiele wartości tego samego typu.

Po 4NF pozostaje jeszcze jeden krok – 5NF, która eliminuje zależności złączeniowe (JD). JD są jednak bardzo rzadkie w praktyce – większość baz danych nigdy ich nie napotyka. Dlatego 4NF jest często uznawana za praktyczne maksimum normalizacji dla większości systemów.

Przygotowanie do 5NF: po 4NF wciąż mogą istnieć zależności złączeniowe (JD), które nie są wykrywane przez 4NF. JD to uogólnienie MVD na więcej niż dwa zbiory atrybutów. Podczas gdy MVD dotyczy dwóch niezależnych list, JD dotyczy trzech lub więcej. 5NF eliminuje JD, rozkładając tabelę na tabele binarne.

W naszym przykładzie bibliotecznym, potencjalna JD może wystąpić w relacji trójskładnikowej (np. ISBN, Autor, Bibliotekarz). Jeśli wszystkie pary tych atrybutów są niezależne, to JD może być spełniona, a tabela nie jest w 5NF. Wtedy trzeba rozłożyć na trzy tabele binarne.

Na szczęście JD są bardzo rzadkie w praktyce. Większość systemów zatrzymuje się na 3NF lub BCNF, a 4NF jest stosowana wybiórczo. 5NF to głównie wiedza akademicka – warto ją znać, ale rzadko stosować. Niemniej, pełne zrozumienie normalizacji wymaga znajomości wszystkich postaci normalnych.

FAQ: Czy 4NF wymaga BCNF? Tak, 4NF = BCNF + warunek na MVD. Bez BCNF nie ma 4NF. Czy każda tabela w BCNF jest w 4NF? Nie – tabela może być w BCNF, ale naruszać 4NF (jak nasza tabela DaneKontaktowe). BCNF to warunek konieczny, ale nie wystarczający dla 4NF.

Jak często występują naruszenia 4NF? Rzadko – szacuje się, że około 1% baz danych wymaga 4NF. Większość systemów nie ma niezależnych list wartości, więc 4NF jest spełniona automatycznie. Czy 4NF jest ważniejsza od 3NF? Nie – każda postać normalna jest ważna w swoim kontekście. 3NF jest fundamentalna, 4NF jest uzupełnieniem.

Czy mogę pominąć 4NF? Tak, możesz. Wiele systemów produkcyjnych działa w 3NF lub BCNF i nigdy nie napotyka problemów związanych z MVD. Decyzja o normalizacji do 4NF zależy od konkretnych danych i wymagań biznesowych. Jeśli nie masz MVD – nie potrzebujesz 4NF.

Gratulacje! Poznałeś czwartą postać normalną. Kluczowa myśl: każda postać normalna eliminuje konkretny typ problemu. 1NF eliminuje nieatomowe wartości, 2NF – zależności częściowe, 3NF – przechodnie, BCNF – nakładające się klucze FD, 4NF – zależności wielowartościowe. Przed nami 5NF – zależności złączeniowe.

W trakcie tej prezentacji przeszliśmy od teorii (definicja MVD) przez przykłady (system biblioteczny) do praktyki (implementacja w MariaDB). Mamy nadzieję, że to kompleksowe podejście pomogło Ci zrozumieć nie tylko co to jest 4NF, ale przede wszystkim kiedy i jak ją stosować.

Normalizacja to potężne narzędzie w rękach projektanta baz danych. Pozwala tworzyć struktury danych, które są czyste, wydajne i odporne na anomalie. 4NF to kolejny krok w tej podróży – od atomowości (1NF) po niezależność list (4NF). Powodzenia w dalszej nauce!