Piąta postać normalna, znana również jako PJ/NF (Project-Join Normal Form), została wprowadzona przez Ronalda Fagina w 1979 roku jako naturalne uogólnienie czwartej postaci normalnej. Stanowi ona teoretyczne domknięcie procesu normalizacji relacyjnych baz danych, eliminując ostatnią klasę anomalii związanych z zależnościami złączeniowymi. W przeciwieństwie do wcześniejszych postaci normalnych, 5NF nie koncentruje się na zależnościach funkcyjnych ani wielowartościowych, lecz bada bardziej subtelne powiązania między atrybutami.

Podstawowym pojęciem leżącym u podstaw piątej postaci normalnej jest zależność złączeniowa, oznaczana symbolem gwiazdki i zbioru podzbiorów atrybutów. JD stwierdza, że relację można bezstratnie rozłożyć na szereg projekcji, które po złączeniu dają dokładnie oryginalną relację bez dodawania fałszywych wierszy. Jest to zatem bezpośrednie uogólnienie koncepcji zależności wielowartościowej, która operuje wyłącznie na dwóch podzbiorach atrybutów.

W praktyce inżynierii oprogramowania piąta postać normalna rzadko znajduje bezpośrednie zastosowanie, co wynika z faktu, że relacje spełniające warunki JD bez jednoczesnego wynika z kluczy kandydujących są niezwykle rzadkie. Mimo to znajomość 5NF stanowi istotny element wykształcenia każdego projektanta baz danych, pozwalając na pełne zrozumienie teoretycznych podstaw modelu relacyjnego i jego ograniczeń.

Niniejsza prezentacja została podzielona na pięć zasadniczych części, prowadzących słuchacza od podstaw teoretycznych przez konkretne przykłady aż po implementację w systemie MariaDB. Rozpoczniemy od przypomnienia kluczowych koncepcji czwartej postaci normalnej oraz zależności wielowartościowych, które stanowią niezbędny fundament do zrozumienia bardziej zaawansowanego materiału. Następnie przejdziemy do szczegółowego omówienia zależności złączeniowych, które są centralnym pojęciem piątej postaci normalnej.

Druga część prezentacji skupi się na formalnej definicji 5NF oraz na analizie warunków, jakie musi spełniać relacja, aby znajdować się w tej postaci normalnej. Szczególną uwagę poświęcimy relacji między JD a kluczami kandydującymi, która decyduje o tym, czy dana tabela wymaga dalszej dekompozycji. W części trzeciej przedstawimy praktyczny przykład systemu rekomendacji bibliotecznych obrazujący działanie mechanizmu JD w konkretnym kontekście biznesowym.

Część czwarta zawierać będzie szczegółową demonstrację implementacji w MariaDB krok po kroku, od tworzenia tabel, przez testowanie JD, aż po weryfikację poprawności dekompozycji. Ostatnia część stanowi podsumowanie całego cyklu normalizacji od 1NF do 5NF, zestawiając ze sobą wszystkie postaci normalne i omawiając ich praktyczne zastosowania w rzeczywistych systemach bazodanowych.

Po przejściu przez kolejne etapy normalizacji od 1NF do 4NF nasz schemat bazy danych biblioteki osiągnął już wysoki poziom czystości strukturalnej. Pierwsza postać normalna zapewniła atomowość wartości i eliminację powtarzających się grup, druga usunęła częściowe zależności funkcyjne, trzecia wyeliminowała zależności przechodnie, a BCNF uporał się z problemem nakładających się kluczy kandydujących. Czwarta postać normalna wniosła kluczową poprawkę dotyczącą niezależnych list atrybutów, rozdzielając zależności wielowartościowe na osobne tabele.

Obecny schemat składa się z ośmiu tabel, z których każda przechowuje informacje dotyczące jednej konkretnej encji lub związku między encjami. Mimo że struktura ta wydaje się kompletna i pozbawiona oczywistych wad, teoria normalizacji wskazuje na istnienie jeszcze jednego rodzaju zależności, który może powodować ukryte problemy. Zależności te dotyczą sytuacji, w których trzy lub więcej zbiorów atrybutów pozostają ze sobą w specyficznej relacji wykraczającej poza prostą parę niezależnych list.

Właśnie ten brakujący element analizy stanowi przedmiot zainteresowania piątej postaci normalnej. Zrozumienie, dlaczego 4NF nie jest ostatnim krokiem normalizacji, wymaga spojrzenia na problem z szerszej perspektywy uwzględniającej nie tylko pary zbiorów atrybutów, ale także bardziej złożone struktury wieloskładnikowe. To właśnie ta perspektywa prowadzi do odkrycia zależności złączeniowych i definicji 5NF.

Zależność wielowartościowa, oznaczana symbolem A →→ B, stanowi rozszerzenie koncepcji zależności funkcyjnej na przypadki, w których danej wartości atrybutu A odpowiada zbiór wartości atrybutu B. W przeciwieństwie do zależności funkcyjnej, która mówi o dokładnie jednej wartości wyznaczanej przez poprzednik, MVD dopuszcza istnienie wielu niezależnych wartości dla tego samego wyznacznika. Typowym przykładem jest sytuacja, w której jeden czytelnik posiada wiele numerów telefonów lub adresów e-mail, a każda z tych list jest od siebie niezależna.

Kluczowa własność zależności wielowartościowej polega na tym, że generuje ona swoisty produkt kartezjański pomiędzy niezależnymi zbiorami wartości. Jeśli czytelnik ma trzy telefony i dwa adresy e-mail, to w tabeli zgodnej wyłącznie z BCNF pojawi się sześć wierszy, co stanowi źródło nadmiarowości. Rozwiązaniem oferowanym przez czwartą postać normalną jest wydzielenie każdej niezależnej listy do osobnej tabeli, co eliminuje niepożądany efekt mnożenia wierszy.

Zależność wielowartościowa jest szczególnym przypadkiem zależności złączeniowej dla sytuacji, w której występują dokładnie dwa podzbiory atrybutów. Formalnie rzecz biorąc, MVD A →→ B | C jest równoważna JD *{A ∪ B, A ∪ C}, co w praktyce oznacza, że każdą tabelę z MVD można bezstratnie rozłożyć na dwie projekcje. To ścisłe powiązanie między MVD a JD stanowi klucz do zrozumienia, dlaczego 5NF jest naturalnym uogólnieniem 4NF.

Po pełnym procesie normalizacji do czwartej postaci normalnej schemat bazy bibliotecznej składa się z ośmiu wyspecjalizowanych tabel spełniających rygorystyczne kryteria integralności danych. Tabela Czytelnicy przechowuje dane osobowe czytelników z kluczem głównym ID_Czytelnika, natomiast tabela Miasta stanowi słownik zawierający przypisanie kodów pocztowych do miejscowości. Książki są reprezentowane przez tabelę z atrybutami ISBN, Tytul i RokWydania, która pełni rolę centralnego katalogu zbiorów bibliotecznych.

Tabela Wypozyczenia łączy ze sobą czytelników i książki, przechowując informacje czasowe dotyczące każdego zdarzenia wypożyczenia, natomiast tabela Opiekunowie realizuje relację wiele-do-wielu między czytelnikami a bibliotekarzami. Przypisania_BCNF zawiera dodatkowe atrybuty związane z przypisaniem książek do czytelników, które wymagały osobnej tabeli ze względu na specyfikę zależności funkcyjnych. Tabele Telefony i Emaile przechowują dane kontaktowe czytelników, rozdzielone zgodnie z wymaganiami 4NF.

Wszystkie osiem tabel znajduje się w czwartej postaci normalnej, co oznacza, że żadna z nich nie zawiera zależności wielowartościowych niewynikających z kluczy kandydujących. Mimo tego zaawansowanego poziomu normalizacji, wciąż istnieje teoretyczna możliwość wystąpienia zależności złączeniowych, które nie są wykrywane przez mechanizmy 4NF. To właśnie te ukryte zależności, dotyczące trzech lub więcej zbiorów atrybutów, stanowią przedmiot analizy w piątej postaci normalnej.

Czwarta postać normalna skutecznie eliminuje problemy związane z niezależnymi listami atrybutów, jednak jej zakres ogranicza się wyłącznie do przypadków binarnych, czyli sytuacji z dokładnie dwoma zbiorami wartości. Mechanizm zależności wielowartościowych nie jest w stanie opisać bardziej złożonych związków między trzema lub większą liczbą niezależnych wymiarów danych. Wyobraźmy sobie tabelę zawierającą informacje o książkach, autorach i bibliotekarzach, gdzie każda para tych encji może występować w dowolnej kombinacji, ale niekoniecznie wszystkie trójki są dozwolone.

W takiej sytuacji 4NF nie sygnalizuje żadnego problemu, ponieważ pomiędzy żadną parą atrybutów nie występuje niezależność wielowartościowa w klasycznym rozumieniu. Każdy atrybut z osobna może być powiązany z pozostałymi w sposób, który nie generuje redundantnych produktów kartezjańskich. Jednak z punktu widzenia teorii normalizacji taka tabela może wciąż zawierać ukrytą zależność złączeniową, która umożliwia bezstratny podział na trzy mniejsze relacje.

Różnica między 4NF a 5NF sprowadza się więc do liczby analizowanych podzbiorów atrybutów: 4NF bada pary, podczas gdy 5NF rozważa dowolną liczbę zbiorów. To uogólnienie sprawia, że piąta postać normalna stanowi najbardziej restrykcyjne kryterium normalizacji w modelu relacyjnym. W praktyce oznacza to, że tabela może spełniać wszystkie warunki 4NF, a jednocześnie nie znajdować się w 5NF, jeśli istnieje w niej JD niewynikająca z kluczy kandydujących.

Zależność złączeniowa to stwierdzenie, że relację R można bezstratnie podzielić na co najmniej dwie projekcje, których naturalne złączenie daje w wyniku dokładnie tę samą relację R. Formalnie zapisuje się ją jako *{X₁, X₂, ..., Xₙ}, gdzie każde Xᵢ stanowi podzbiór atrybutów relacji R, a suma wszystkich Xᵢ pokrywa wszystkie atrybuty R. Jeśli dana JD jest spełniona przez relację, oznacza to, że w każdej dopuszczalnej instancji tej relacji zachodzi równość między relacją a złączeniem jej projekcji.

Intuicyjnie rzecz ujmując, JD orzeka, że informacja zawarta w relacji R jest w pewnym sensie złożona z niezależnych fragmentów, które mogą być przechowywane osobno bez utraty danych. Własność ta ma fundamentalne znaczenie dla projektowania baz danych, ponieważ wskazuje na możliwość dekompozycji tabel bez ryzyka utraty informacji. Jeśli JD nie jest spełniona, próba rozkładu i ponownego złączenia projekcji wygeneruje dodatkowe, fałszywe wiersze, które nie występowały w oryginalnej relacji.

Zależność złączeniowa stanowi bezpośrednie uogólnienie zależności wielowartościowej: podczas gdy MVD dotyczy dwóch podzbiorów atrybutów, JD może obejmować dowolną liczbę podzbiorów. W szczególności każda MVD A →→ B | C jest równoważna JD *{A ∪ B, A ∪ C}, co pokazuje, że teoria normalizacji rozwija się od przypadków szczególnych ku coraz bardziej ogólnym sformułowaniom. To właśnie ta hierarchiczna struktura zależności stanowi podstawę do definiowania kolejnych postaci normalnych.

Po przejściu przez wszystkie wcześniejsze etapy normalizacji, w tym wymagającą czwartą postać normalną, projektant bazy danych może odnieść wrażenie, że schemat jest już całkowicie optymalny. Jednak teoria normalizacji dowodzi, że istnieje jeszcze jedna klasa problemów związanych z zależnościami złączeniowymi, które nie są wykrywane przez żadną z wcześniejszych postaci normalnych. Problem pojawia się wtedy, gdy relacja zawiera trzy lub więcej atrybutów, a reguły biznesowe dopuszczają dowolne kombinacje między poszczególnymi parami tych atrybutów.

Rozważmy tabelę zawierającą trzy kolumny: ISBN książki, nazwisko autora oraz identyfikator bibliotekarza. W tej tabeli każdy bibliotekarz może polecać dowolną książkę, każdy bibliotekarz może polecać dowolnego autora, a każda książka ma swoich autorów. Mimo że wszystkie te stwierdzenia są prawdziwe, nie oznacza to automatycznie, że każdy bibliotekarz poleca każdego autora w każdej książce – ta ostatnia kombinacja może być niedozwolona przez reguły biznesowe.

Pytanie, na które odpowiada 5NF, brzmi: czy z faktu, że istnieją pewne pary (ISBN, autor), (ISBN, bibliotekarz) i (autor, bibliotekarz), wynika konieczność istnienia całej trójki (ISBN, autor, bibliotekarz)? Jeśli odpowiedź brzmi tak, to JD jest spełniona i tabelę należy podzielić na trzy mniejsze. Jeśli nie, tabela pozostaje w 5NF, ponieważ JD nie wynika z danych ani z kluczy kandydujących, a zatem dekompozycja nie jest wymagana.

Niech R będzie relacją o zbiorze atrybutów U, a A₁, A₂, ..., Aₙ będą podzbiorami U takimi, że suma wszystkich Aᵢ równa się U. Mówimy, że w relacji R zachodzi zależność złączeniowa *{A₁, A₂, ..., Aₙ}, jeśli dla każdej dopuszczalnej instancji relacji R zachodzi równość R = π_{A₁}(R) ⋈ π_{A₂}(R) ⋈ ... ⋈ π_{Aₙ}(R). Innymi słowy, relacja R jest dokładnie równa naturalnemu złączeniu swoich projekcji na podzbiory A₁, A₂, ..., Aₙ, co oznacza, że rozkład na te projekcje jest bezstratny.

Symbol gwiazdki poprzedzający listę podzbiorów atrybutów jest standardowym oznaczeniem przyjętym w literaturze bazodanowej dla zależności złączeniowych. Każdy podzbiór Aᵢ może zawierać jeden lub więcej atrybutów, a liczba podzbiorów n jest zawsze większa lub równa dwa. W przypadku n równego dwa zależność złączeniowa redukuje się do zależności wielowartościowej, co potwierdza, że MVD jest szczególnym przypadkiem JD.

Weryfikacja, czy dana JD jest spełniona przez konkretną instancję relacji, polega na wykonaniu operacji złączenia projekcji i porównaniu wyniku z oryginalną relacją. Jeśli wynik złączenia zawiera więcej wierszy niż oryginał, oznacza to, że JD nie jest spełniona. Jeśli natomiast liczba wierszy jest identyczna, JD zachodzi i relację można bezpiecznie zdekomponować. Ta własność stanowi podstawę praktycznego testowania JD w systemach zarządzania bazami danych.

Aby zrozumieć istotę zależności złączeniowej w sposób intuicyjny, warto posłużyć się prostym przykładem z trzema zbiorami danych. Wyobraźmy sobie trzy listy: listę par (ISBN, autor) oznaczającą, które książki napisali którzy autorzy, listę par (ISBN, bibliotekarz) określającą, które książki polecają poszczególni bibliotekarze, oraz listę par (autor, bibliotekarz) informującą, których autorów polecają bibliotekarze. Każda z tych list stanowi projekcję pewnej nadrzędnej relacji trójskładnikowej na konkretną parę atrybutów.

Zależność złączeniowa bada, czy z istnienia wszystkich trzech list par wynika automatycznie istnienie wszystkich możliwych kombinacji trójek. Inaczej mówiąc, jeśli wiemy, że książka o danym ISBN ma określonego autora, że ten sam ISBN jest polecany przez pewnego bibliotekarza oraz że ten sam autor jest polecany przez tego samego bibliotekarza, to czy musimy wnioskować, że ów bibliotekarz poleca właśnie tę książkę tego autora? Jeśli odpowiedź jest twierdząca, oznacza to, że między atrybutami zachodzi zależność złączeniowa.

W praktyce odpowiedź na to pytanie zależy wyłącznie od reguł biznesowych obowiązujących w modelowanej rzeczywistości. Jeśli system dopuszcza wszystkie kombinacje, JD jest spełniona i relację można rozłożyć. Jeśli natomiast istnieją konkretne ograniczenia biznesowe wykluczające niektóre kombinacje, JD nie zachodzi, a relacja pozostaje nierozłożona. To właśnie te reguły biznesowe, a nie struktura matematyczna, decydują ostatecznie o tym, czy 5NF wymaga dalszej dekompozycji.

Zależności wielowartościowe i zależności złączeniowe stanowią dwie strony tej samej monety, różniące się przede wszystkim liczbą analizowanych podzbiorów atrybutów. MVD, oznaczana jako A →→ B, opisuje sytuację, w której zbiór atrybutów A determinuje zbiór wartości atrybutów B niezależnie od pozostałych atrybutów C = R - A - B. JD natomiast, zapisywana jako *{A₁, A₂, ..., Aₙ}, uogólnia to pojęcie na dowolną liczbę podzbiorów, nie ograniczając się do przypadku trzech komplementarnych zbiorów.

Z punktu widzenia hierarchii normalizacji, 4NF eliminuje wszystkie MVD niewynikające z kluczy kandydujących, podczas gdy 5NF rozszerza to wymaganie na wszystkie JD. Oznacza to, że każda relacja w 5NF jest automatycznie w 4NF, ale relacja w 4NF może nie znajdować się w 5NF, jeśli istnieje w niej JD, która nie jest MVD. Ta hierarchiczna zależność między postaciami normalnymi odzwierciedla rosnący poziom restrykcyjności wymagań nakładanych na strukturę danych.

W praktyce różnica między MVD a JD ma istotne znaczenie dla zrozumienia, jakiego rodzaju anomalie mogą pozostać nierozwiązane po osiągnięciu 4NF. O ile MVD prowadzi do redundantnych produktów kartezjańskich między dwiema niezależnymi listami, o tyle JD może powodować bardziej subtelne problemy związane z wymuszoną obecnością lub brakiem określonych kombinacji atrybutów. Rozpoznanie, z którym typem zależności mamy do czynienia, wymaga dogłębnej analizy reguł biznesowych i struktury kluczy kandydujących.

Zależności złączeniowe powstają w specyficznych okolicznościach, które w praktyce występują niezwykle rzadko, ale są dobrze zdefiniowane teoretycznie. Podstawowym warunkiem koniecznym jest obecność relacji trójskładnikowej lub wyższego rzędu, czyli takiej, w której występują co najmniej trzy atrybuty lub grupy atrybutów powiązane ze sobą w sposób niezależny. Nie wystarczy jednak sama obecność trzech atrybutów – konieczne jest, aby każda para tych atrybutów mogła występować niezależnie od wartości trzeciego atrybutu.

Klasycznym przykładem prowadzącym do JD jest relacja między książką, autorem i bibliotekarzem, gdzie każdy bibliotekarz może polecać dowolną książkę niezależnie od autora, a także polecać dowolnego autora niezależnie od konkretnej książki. W takiej sytuacji każda para encji tworzy własną, niezależną relację binarną, a wszystkie trzy relacje binarne istnieją równolegle. Problem pojawia się, gdy reguły biznesowe nie wymuszają żadnych dodatkowych ograniczeń na kombinacje trójek poza tymi, które wynikają z par.

Aby JD zaistniała w praktyce, muszą być spełnione trzy warunki: relacja musi zawierać co najmniej trzy atrybuty, każda para atrybutów musi być od siebie niezależna w tym sensie, że wartości w jednej parze nie determinują wartości w trzecim atrybucie, oraz wszystkie kombinacje par muszą być dozwolone przez reguły biznesowe. Spełnienie tych trzech warunków jednocześnie jest w realnych systemach na tyle rzadkie, że wielu programistów nigdy nie spotyka JD w swojej karierze zawodowej.

W przykładowej bazie bibliotecznej wprowadzamy nową funkcjonalność systemu rekomendacji, która pozwala bibliotekarzom polecać czytelnikom konkretne książki określonych autorów. Do przechowywania tych informacji tworzymy tabelę Rekomendacje o schemacie zawierającym trzy kolumny: ISBN identyfikujący książkę, Autor określający twórcę dzieła oraz ID_Bibliotekarza wskazującego na pracownika biblioteki. Klucz główny tej tabeli jest złożony ze wszystkich trzech kolumn, co oznacza, że każda kombinacja (ISBN, autor, bibliotekarz) może wystąpić co najwyżej raz.

Reguły biznesowe w tym systemie są następujące: każdy bibliotekarz może polecać dowolną książkę bez względu na to, kto jest jej autorem, oraz może polecać dowolnego autora bez względu na to, które książki tego autora znajdują się w zbiorach. Oznacza to, że relacje binarne między parami encji są w pełni niezależne: relacja między ISBN a autorem wynika z faktu autorstwa, relacja między ISBN a bibliotekarzem odzwierciedla polecenie książki, a relacja między autorem a bibliotekarzem reprezentuje polecenie twórcy. Te trzy niezależne wymiary stanowią idealne podłoże do wystąpienia zależności złączeniowej.

W analizie tej struktury kluczowe pytanie brzmi: czy z faktu, że dany bibliotekarz poleca konkretną książkę oraz że poleca również konkretnego autora, i że ta książka została napisana przez tego autora, wynika automatycznie, że bibliotekarz poleca tę książkę tego autora? Jeśli reguły biznesowe nie nakładają dodatkowych ograniczeń, odpowiedź brzmi twierdząco i JD jest spełniona. W przeciwnym razie, gdy pewne kombinacje są wykluczone przez politykę biblioteki, JD nie zachodzi i tabela pozostaje w 5NF.

Rozpatrzmy konkretny przykład danych w tabeli Rekomendacje, który ilustruje sytuację, gdy zależność złączeniowa nie jest spełniona. Załóżmy, że mamy trzy wiersze: bibliotekarz o identyfikatorze 1 poleca książkę o numerze ISBN1 autorstwa Żeromskiego, bibliotekarz 2 poleca tę samą książkę ISBN1 autorstwa Prusa, a bibliotekarz 2 poleca również inną książkę ISBN2 autorstwa Żeromskiego. W tej sytuacji wszystkie trzy możliwe pary atrybutów są reprezentowane para ISBN1 i Żeromski występuje w pierwszym wierszu, para ISBN1 i bibliotekarz 2 występuje w drugim wierszu, a para Żeromski i bibliotekarz 2 występuje w trzecim wierszu.

Gdyby zależność złączeniowa *{ISBN, Autor}, {ISBN, ID_Bibliotekarza}, {Autor, ID_Bibliotekarza} była spełniona, to w tabeli musiałby istnieć wiersz (ISBN1, Żeromski, bibliotekarz 2), ponieważ wszystkie trzy składające się na niego pary są obecne. Analiza danych pokazuje jednak, że taki wiersz nie istnieje, co oznacza, że JD nie jest spełniona. Konsekwencją tego faktu jest to, że próba rozłożenia tabeli na trzy projekcje binarne i ponownego ich złączenia wygeneruje dodatkowy, nieistniejący w oryginalnych danych wiersz.

Z praktycznego punktu widzenia brak spełnienia JD oznacza, że w systemie obowiązuje konkretna reguła biznesowa: bibliotekarz 2 nie poleca Żeromskiego w książce ISBN1, mimo że poleca samego Żeromskiego oraz poleca książkę ISBN1 w innym kontekście. Taka reguła może wynikać z subiektywnych preferencji bibliotekarza, który ceni twórczość Żeromskiego, ale nie uważa książki ISBN1 za godną polecenia. W tym przypadku tabeli nie należy rozkładać, ponieważ JD nie jest spełniona, a zatem 5NF jest zachowana.

Zależność złączeniowa jest spełniona wtedy i tylko wtedy, gdy dla każdej kombinacji par atrybutów występujących w odpowiednich projekcjach istnieje odpowiadający jej wiersz w relacji wyjściowej. Innymi słowy, jeśli w projekcji na podzbiór A znajduje się para (a₁, b₁), w projekcji na podzbiór B znajduje się para (a₁, c₁), a w projekcji na podzbiór C znajduje się para (b₁, c₁), to w relacji R musi istnieć wiersz (a₁, b₁, c₁). Spełnienie tego warunku dla wszystkich możliwych kombinacji jest konieczne i wystarczające do tego, aby JD zachodziła.

W kontekście naszego przykładu bibliotecznego, JD byłaby spełniona, gdybyśmy dodali do tabeli Rekomendacje czwarty wiersz (ISBN1, Żeromski, bibliotekarz 2). Wówczas wszystkie kombinacje par wynikające z trzech projekcji byłyby reprezentowane w pełnej relacji trójskładnikowej. Złączenie projekcji binarnych na (ISBN, Autor), (ISBN, ID_Bibliotekarza) i (Autor, ID_Bibliotekarza) dałoby w wyniku dokładnie cztery wiersze identyczne z oryginalną tabelą, co potwierdza bezstratność dekompozycji.

W praktyce spełnienie JD oznacza, że reguły biznesowe nie nakładają żadnych ograniczeń na kombinacje atrybutów poza tymi, które wynikają z samych par. Jeśli bibliotekarz może polecać dowolną książkę, dowolnego autora, a każda książka ma swoich autorów, to automatycznie każda kombinacja tych trzech elementów jest dozwolona. W takiej sytuacji przechowywanie wszystkich kombinacji w jednej tabeli jest nieefektywne i lepiej rozłożyć ją na trzy mniejsze, co właśnie nakazuje 5NF.

Operacja złączenia projekcji stanowi podstawowe narzędzie weryfikacji zależności złączeniowych i może być łatwo zwizualizowana na konkretnym przykładzie. Załóżmy, że nasza relacja Rekomendacje zawiera cztery wiersze spełniające JD i chcemy sprawdzić, czy rozkład na trzy tabele binarne jest rzeczywiście bezstratny. W tym celu wykonujemy trzy projekcje: pierwsza zawiera pary (ISBN, Autor), druga zawiera pary (ISBN, ID_Bibliotekarza), a trzecia zawiera pary (Autor, ID_Bibliotekarza). Każda z tych projekcji jest mniejsza od oryginalnej relacji, ponieważ zawiera wyłącznie dwie kolumny.

Następnym krokiem jest wykonanie naturalnego złączenia tych trzech projekcji, które odbywa się w dwóch etapach. Najpierw łączymy pierwszą i drugą projekcję po wspólnym atrybucie ISBN, otrzymując tymczasową relację zawierającą trzy kolumny: ISBN, Autor i ID_Bibliotekarza. Następnie łączymy tę tymczasową relację z trzecią projekcją po wspólnych atrybutach Autor i ID_Bibliotekarza. Wynik końcowy powinien zawierać dokładnie te same wiersze, co oryginalna relacja, jeśli JD jest spełniona.

Gdyby zależność złączeniowa nie była spełniona, złączenie projekcji wygenerowałoby dodatkowe wiersze nieobecne w oryginalnej relacji. Dzieje się tak dlatego, że operacja złączenia naturalnego tworzy wszystkie kombinacje pasujących par, nawet jeśli odpowiadająca im trójka nie istnieje w rzeczywistości. Wizualizacja tego mechanizmu pomaga zrozumieć, dlaczego test złączenia jest tak skutecznym narzędziem do wykrywania JD: jeśli wynik złączenia pokrywa się z oryginałem, dekompozycja jest bezpieczna, w przeciwnym razie prowadzi do utraty integralności danych.

Zależności złączeniowe należą do najrzadziej występujących zjawisk w praktyce projektowania i eksploatacji systemów bazodanowych. Większość profesjonalnych programistów i administratorów baz danych pracuje przez całą swoją karierę, nie napotykając ani razu na sytuację, w której JD wymagałaby ingerencji w strukturę tabel. Szacuje się, że w standardowych systemach informatycznych, takich jak systemy ERP, CRM czy platformy e-commerce, odsetek tabel, które mogłyby potencjalnie naruszać 5NF, wynosi poniżej 0,01% wszystkich relacji.

Taka rzadkość wynika z faktu, że JD wymaga jednoczesnego spełnienia kilku restrykcyjnych warunków, które rzadko występują razem w rzeczywistych aplikacjach. Po pierwsze, tabela musi modelować relację trójskładnikową lub wyższego rzędu, co samo w sobie nie jest częste w dobrze zaprojektowanych schematach. Po drugie, każda para atrybutów musi być od siebie w pełni niezależna, co w praktyce oznacza brak jakichkolwiek ograniczeń biznesowych nakładanych na konkretne kombinacje wartości. Po trzecie, wszystkie możliwe kombinacje par muszą być dozwolone przez reguły biznesowe.

W rezultacie większość relacji trójskładnikowych w rzeczywistych systemach zawiera dodatkowe atrybuty opisujące konkretne powiązanie między encjami, takie jak data, ilość, cena czy ocena, które uniemożliwiają spełnienie JD. Na przykład w tabeli zawierającej informacje o lekarzach, pacjentach i lekach z atrybutem Dawka, wartość dawki zależy od całej trójki, co wyklucza możliwość dowolnych kombinacji. Dlatego też 5NF pozostaje głównie w sferze rozważań akademickich, choć jej znajomość jest istotna dla pełnego zrozumienia teorii normalizacji.

Praktyczna wartość piątej postaci normalnej jest przedmiotem dyskusji w środowisku inżynierów baz danych, ponieważ jej zastosowanie wiąże się z korzyściami teoretycznymi, ale także z konkretnymi kosztami implementacyjnymi. Z jednej strony 5NF zapewnia najwyższy możliwy poziom czystości strukturalnej, eliminując wszystkie znane typy anomalii związanych z dekompozycją relacji. Z drugiej strony osiągnięcie 5NF wymaga wprowadzenia dodatkowych tabel, co zwiększa złożoność zapytań i może negatywnie wpływać na wydajność operacji odczytu.

W praktyce inżynierskiej przyjmuje się, że zatrzymanie się na trzeciej postaci normalnej lub BCNF jest w zupełności wystarczające dla zdecydowanej większości systemów produkcyjnych. Czwarta postać normalna jest stosowana w sytuacjach, gdy występują niezależne listy atrybutów, takich jak numery telefonów czy adresy e-mail, ale i to nie jest regułą. Piąta postać normalna znajduje zastosowanie niemal wyłącznie w systemach o bardzo restrykcyjnych wymaganiach integralności danych lub w specyficznych domenach, gdzie modelowanie wielowymiarowe jest szczególnie istotne.

Należy pamiętać, że większość tabel w rzeczywistych systemach jest automatycznie w 5NF, ponieważ zawiera prosty klucz główny składający się z jednej kolumny. W takich przypadkach wszystkie JD wynikają w sposób naturalny z kluczy kandydujących, a zatem analiza 5NF nie wnosi żadnych nowych informacji. Decyzja o stosowaniu 5NF powinna być zatem podejmowana świadomie, z uwzględnieniem konkretnych wymagań projektowych i analizy kosztów i korzyści, a nie jako automatyczny krok w procesie normalizacji.

Relacja R znajduje się w piątej postaci normalnej, zwanej również Project-Join Normal Form, wtedy i tylko wtedy, gdy spełnia dwa warunki. Po pierwsze, relacja R musi być w czwartej postaci normalnej, co oznacza, że nie zawiera żadnych zależności wielowartościowych niewynikających z kluczy kandydujących. Po drugie, każda zależność złączeniowa *{A₁, A₂, ..., Aₙ} zachodząca w relacji R musi wynikać z kluczy kandydujących tej relacji, co w praktyce oznacza, że każdy podzbiór Aᵢ musi być nadkluczem relacji R.

Innymi słowy, 5NF wymaga, aby każdy możliwy bezstratny rozkład relacji na projekcje był uzasadniony strukturą kluczy kandydujących, a nie przypadkowymi zależnościami między danymi. Jeśli istnieje JD, która nie wynika z kluczy kandydujących, oznacza to, że tabelę można podzielić na mniejsze części w sposób, który nie jest oczywisty z punktu widzenia integralności referencyjnej. W takiej sytuacji 5NF nakazuje dokonanie dekompozycji w celu wyeliminowania ukrytej zależności.

Nazwa Project-Join Normal Form pochodzi od sposobu, w jaki definiuje się tę postać normalną poprzez badanie związku między operacjami projekcji i złączenia. W odróżnieniu od wcześniejszych postaci normalnych, które koncentrowały się na zależnościach funkcyjnych i wielowartościowych, 5NF bada ogólną własność dekompozycyjności relacji. To sprawia, że 5NF jest najbardziej fundamentalną postacią normalną w modelu relacyjnym, ponieważ dotyka samej istoty tego, co oznacza bezstratny podział informacji.

Warunek pierwszy piątej postaci normalnej wymaga, aby relacja znajdowała się w 4NF, co jest konieczne, ale nie wystarczające do osiągnięcia 5NF. Czwarta postać normalna gwarantuje, że wszystkie zależności wielowartościowe wynikają z kluczy kandydujących, co eliminuje problem niezależnych list atrybutów. Jednak 4NF nie bada bardziej złożonych zależności między trzema lub większą liczbą zbiorów atrybutów, które mogą prowadzić do ukrytych anomalii niewidocznych na poziomie par atrybutów.

Warunek drugi stanowi sedno definicji 5NF: każda zależność złączeniowa w relacji musi wynikać z kluczy kandydujących. Oznacza to, że jeśli istnieje JD *{A₁, A₂, ..., Aₙ}, to dla każdego podzbioru Aᵢ zachodzi jedna z dwóch możliwości: albo Aᵢ zawiera klucz kandydujący relacji R, albo JD jest logiczną konsekwencją innych JD, które już wynikają z kluczy. W praktyce najczęściej oznacza to, że każdy podzbiór Aᵢ musi być nadkluczem, czyli minimalnym identyfikatorem wiersza.

Weryfikacja warunku drugiego w praktyce sprowadza się do sprawdzenia, czy istnieje jakakolwiek JD, której żaden z podzbiorów nie zawiera klucza kandydującego. Jeśli taka JD istnieje i jest spełniona przez dane, relacja nie znajduje się w 5NF i wymaga dekompozycji. Jeśli natomiast wszystkie JD w relacji wynikają z kluczy, 5NF jest spełniona i dalsza normalizacja nie jest potrzebna. W przypadku relacji z pojedynczym kluczem kandydującym warunek ten jest prawie zawsze spełniony automatycznie.

Związek między zależnościami złączeniowymi a kluczami kandydującymi ma fundamentalne znaczenie dla zrozumienia piątej postaci normalnej. Klucz kandydujący to minimalny zbiór atrybutów, który jednoznacznie identyfikuje każdy wiersz w relacji, a w 5NF wymagamy, aby każda JD była w pewnym sensie pochodną tych kluczy. Konkretnie, JD *{A₁, A₂, ..., Aₙ} wynika z kluczy kandydujących wtedy, gdy każdy podzbiór Aᵢ zawiera co najmniej jeden klucz kandydujący relacji R.

Rozważmy naszą przykładową tabelę Rekomendacje z kluczem kandydującym (ISBN, Autor, ID_Bibliotekarza). JD, którą analizujemy, to *{ISBN, Autor}, {ISBN, ID_Bibliotekarza}, {Autor, ID_Bibliotekarza}. Żaden z podzbiorów tej JD nie zawiera pełnego klucza kandydującego, ponieważ każdy z nich składa się z dwóch atrybutów, podczas gdy klucz ma ich trzy. Oznacza to, że ta JD nie wynika z kluczy kandydujących, a zatem jeśli jest spełniona przez dane, relacja nie znajduje się w 5NF.

W praktyce oznacza to, że im więcej kluczy kandydujących ma relacja, tym większa szansa, że JD będą z nich wynikać. Relacje z jednym prostym kluczem głównym są niemal zawsze w 5NF, ponieważ każda JD, która nie zawiera tego klucza, nie może być spełniona w sposób nierozkładalny. Z kolei relacje z wieloma złożonymi kluczami kandydującymi wymagają dokładniejszej analizy, ponieważ mogą zawierać JD, które nie wynikają wprost z żadnego z istniejących kluczy.

Szczegółowe porównanie zależności wielowartościowych i złączeniowych ujawnia hierarchiczną strukturę teorii normalizacji, w której każda kolejna postać normalna rozszerza zakres analizowanych zależności. MVD dotyczy ściśle dwóch zbiorów atrybutów, które uzupełniają się do pełnego zbioru atrybutów relacji, co zapisujemy jako A →→ B | C, gdzie C = R - A - B. Z kolei JD może obejmować dowolną liczbę podzbiorów, których suma pokrywa wszystkie atrybuty, ale nie muszą one być parami rozłączne ani komplementarne.

Różnica w liczbie analizowanych podzbiorów przekłada się bezpośrednio na zakres stosowalności 4NF i 5NF. Czwarta postać normalna bada wyłącznie przypadki binarne, co oznacza, że wykrywa problemy związane z dwiema niezależnymi listami atrybutów. Jeśli jednak mamy trzy lub więcej niezależnych wymiarów danych, 4NF pozostaje ślepa na istniejącą zależność, ponieważ nie istnieje MVD, która by ją opisywała. W takiej sytuacji konieczne jest zastosowanie bardziej ogólnego narzędzia, jakim jest JD.

Warto zauważyć, że każda MVD jest szczególnym przypadkiem JD, ale nie każda JD jest MVD. Konkretnie, MVD A →→ B | C jest równoważna JD *{A ∪ B, A ∪ C}. Oznacza to, że 4NF jest szczególnym przypadkiem 5NF dla relacji, w których wszystkie JD są dwuelementowe. W tym sensie 5NF stanowi naturalne uogólnienie 4NF, a przejście od 4NF do 5NF polega na rozszerzeniu analizy z przypadków dwuelementowych na przypadki wieloelementowe.

Tabela nie znajduje się w piątej postaci normalnej wtedy i tylko wtedy, gdy istnieje w niej zależność złączeniowa, która nie wynika z kluczy kandydujących, a jednocześnie jest spełniona przez bieżący stan danych. Innymi słowy, muszą być spełnione trzy warunki jednocześnie: musi istnieć JD o odpowiedniej strukturze, JD musi wynikać z reguł biznesowych lub danych, oraz JD nie może być konsekwencją istniejących kluczy kandydujących. Dopiero spełnienie wszystkich trzech warunków oznacza naruszenie 5NF i konieczność dekompozycji.

W praktyce naruszenie 5NF jest sytuacją wyjątkowo rzadką, ponieważ wymaga specyficznej konfiguracji struktury tabeli i reguł biznesowych. Tabela musi mieć co najmniej trzy atrybuty, ponieważ JD dla dwóch atrybutów jest zawsze trywialna. Ponadto wszystkie pary atrybutów muszą być od siebie niezależne, co oznacza, że nie istnieją żadne zależności funkcyjne ani wielowartościowe, które ograniczałyby kombinacje. Wreszcie, dane muszą potwierdzać, że wszystkie możliwe kombinacje par faktycznie występują w relacji.

W przypadku naszej tabeli Rekomendacje, naruszenie 5NF wystąpiłoby dopiero wtedy, gdyby reguły biznesowe zezwalały na dowolne kombinacje wszystkich trzech atrybutów, a dane odzwierciedlałyby tę swobodę. Jeśli natomiast istnieje choćby jedna reguła ograniczająca kombinacje, JD nie jest spełniona, a tabela automatycznie znajduje się w 5NF. To wyjaśnia, dlaczego w praktyce tak trudno znaleźć tabelę naruszającą 5NF: większość systemów ma bogate reguły biznesowe, które naturalnie ograniczają dozwolone kombinacje.

Dekompozycja relacji do piątej postaci normalnej przebiega według prostej i powtarzalnej procedury opartej na zbiorach atrybutów występujących w zależności złączeniowej. Dla każdego podzbioru Aᵢ występującego w JD *{A₁, A₂, ..., Aₙ} tworzymy osobną tabelę zawierającą wyłącznie atrybuty należące do tego podzbioru. Każda nowa tabela otrzymuje klucz główny złożony z atrybutów wchodzących w skład danego podzbioru, co zapewnia jednoznaczną identyfikację wierszy w ramach tej projekcji.

W naszym przykładzie JD *{ISBN, Autor}, {ISBN, ID_Bibliotekarza}, {Autor, ID_Bibliotekarza} prowadzi do utworzenia trzech tabel binarnych. Pierwsza tabela o nazwie KsiazkiAutorzy zawiera kolumny ISBN i Autor z kluczem złożonym z obu atrybutów. Druga tabela KsiazkiBibliotekarze przechowuje pary ISBN i ID_Bibliotekarza, również z kluczem złożonym. Trzecia tabela AutorzyBibliotekarze zawiera atrybuty Autor i ID_Bibliotekarza, a jej kluczem jest para tych dwóch kolumn.

Po dokonaniu dekompozycji każda z nowych tabel automatycznie znajduje się w 5NF, ponieważ ma prostą strukturę z jednym kluczem kandydującym i żadnymi złożonymi zależnościami między atrybutami. Wszystkie JD w tych tabelach są trywialne i wynikają wprost z kluczy głównych. Należy pamiętać, że dekompozycję wykonujemy wyłącznie wtedy, gdy JD jest faktycznie spełniona przez dane w przeciwnym razie prowadzi ona do utraty integralności danych i generowania fałszywych wierszy przy złączeniu.

Po dokonaniu dekompozycji relacji na mniejsze tabele zgodnie z zasadami 5NF, konieczne jest przeprowadzenie weryfikacji, czy każda z nowych tabel rzeczywiście spełnia wymagania piątej postaci normalnej. W przypadku tabel binarnych, takich jak KsiazkiAutorzy z kluczem (ISBN, Autor), weryfikacja jest stosunkowo prosta, ponieważ każda tabela ma tylko jeden klucz kandydujący złożony z obu atrybutów. Wszystkie potencjalne JD w takiej tabeli są trywialne, ponieważ każdy podzbiór atrybutów zawiera niepusty fragment klucza.

Kluczowym aspektem weryfikacji jest upewnienie się, że podczas dekompozycji nie utraciliśmy żadnych informacji ani nie wprowadziliśmy fałszywych danych. Test bezstratności złączenia polega na wykonaniu naturalnego złączenia wszystkich trzech tabel binarnych i porównaniu wyniku z oryginalną relacją. Jeśli liczba wierszy w wyniku złączenia jest identyczna z liczbą wierszy w oryginalnej tabeli, dekompozycja jest bezstratna i poprawna. Jeśli natomiast wynik złączenia zawiera więcej wierszy, oznacza to, że JD nie była spełniona, a dekompozycja została wykonana błędnie.

Dodatkowym elementem weryfikacji jest sprawdzenie integralności referencyjnej między nowymi tabelami a pozostałymi tabelami w schemacie bazy danych. Każda nowa tabela powinna mieć zdefiniowane klucze obce łączące ją z odpowiednimi tabelami nadrzędnymi, na przykład kolumna ISBN w tabeli KsiazkiAutorzy powinna być kluczem obcym prowadzącym do tabeli Ksiazki. Zapewnienie tych powiązań gwarantuje, że dane w zdekomponowanych tabelach pozostają spójne z resztą systemu.

W pierwszym ćwiczeniu praktycznym analizujemy tabelę DostawyProduktyDostawcy zawierającą atrybuty ID_Dostawy, ID_Produktu, ID_Dostawcy, Data oraz Cena. Klucz główny tej tabeli stanowi para atrybutów (ID_Dostawy, ID_Produktu), która jednoznacznie identyfikuje każdy wiersz. Potencjalna zależność złączeniowa, którą należy zbadać, to *{ID_Dostawy, ID_Produktu}, {ID_Dostawy, ID_Dostawcy, Data}, {ID_Produktu, ID_Dostawcy}. Celem ćwiczenia jest ustalenie, czy ta JD wynika z kluczy kandydujących, a jeśli nie, czy jest spełniona przez dane.

Analiza rozpoczyna się od sprawdzenia, czy którykolwiek z podzbiorów JD zawiera klucz kandydujący. Podzbiór pierwszy {ID_Dostawy, ID_Produktu} jest dokładnie równy kluczowi głównemu, co oznacza, że ten element JD wynika z kluczy. Jednak pozostałe dwa podzbiory, {ID_Dostawy, ID_Dostawcy, Data} oraz {ID_Produktu, ID_Dostawcy}, nie zawierają pełnego klucza kandydującego, ponieważ żaden z nich nie obejmuje jednocześnie ID_Dostawy i ID_Produktu. Zatem JD jako całość nie wynika bezpośrednio z kluczy kandydujących.

W drugim kroku należy sprawdzić, czy JD jest spełniona przez konkretne dane w tabeli. Wymaga to wykonania testu złączenia projekcji i porównania liczby wierszy. Jeśli wszystkie możliwe kombinacje par z trzech projekcji istnieją w oryginalnej tabeli, JD jest spełniona i tabela nie znajduje się w 5NF. W przeciwnym razie, gdy pewne kombinacje są wykluczone przez reguły biznesowe, JD nie zachodzi, a tabela pozostaje w 5NF. Wynik ćwiczenia zależy zatem od konkretnych danych biznesowych.

Drugie ćwiczenie wymaga zaprojektowania dekompozycji tabeli DostawyProduktyDostawcy do piątej postaci normalnej, zakładając że zależność złączeniowa jest spełniona. Na podstawie analizy JD *{ID_Dostawy, ID_Produktu}, {ID_Dostawy, ID_Dostawcy, Data}, {ID_Produktu, ID_Dostawcy} należy utworzyć trzy osobne tabele, z których każda będzie przechowywała jeden aspekt relacji między encjami. Pierwsza tabela DostawaProdukt zawierać będzie pary (ID_Dostawy, ID_Produktu) wraz z atrybutem Cena, który jest funkcyjnie zależny od tej właśnie pary.

Druga tabela DostawaDostawca przechowuje informację o tym, który dostawca realizuje daną dostawę, wraz z datą dostawy. Jej klucz główny stanowi para (ID_Dostawy, ID_Dostawcy), a atrybut Data jest od niej w pełni zależny funkcyjnie. Trzecia tabela ProduktDostawca zawiera dane o tym, który produkt może być dostarczany przez którego dostawcę, z kluczem złożonym (ID_Produktu, ID_Dostawcy). Każda z tych tabel ma prostą strukturę dwuatrybutowego klucza głównego i co najwyżej jeden dodatkowy atrybut.

Po zakończeniu dekompozycji każda z trzech nowych tabel automatycznie znajduje się w 5NF, ponieważ ma tylko jeden klucz kandydujący i żadnych złożonych zależności między atrybutami. Wszystkie potencjalne JD w tych tabelach są trywialne i wynikają bezpośrednio z kluczy. Należy również pamiętać o dodaniu kluczy obcych łączących nowe tabele z istniejącymi tabelami słownikowymi, takimi jak Produkty i Dostawcy, co zapewni integralność referencyjną całego schematu.

Trzecie ćwiczenie analizuje tabelę StudenciWykladowcyPrzedmioty o atrybutach ID_Studenta, ID_Wykladowcy, ID_Przedmiotu oraz Ocena. Klucz główny tej tabeli jest złożony ze wszystkich trzech atrybutów identyfikacyjnych, ponieważ ocena jest przypisana do konkretnej kombinacji studenta, wykładowcy i przedmiotu. Potencjalna JD *{ID_Studenta, ID_Przedmiotu}, {ID_Studenta, ID_Wykladowcy}, {ID_Wykladowcy, ID_Przedmiotu} istnieje w teorii, ale jej spełnienie zależy od konkretnych reguł biznesowych obowiązujących w systemie.

Kluczowym czynnikiem decydującym o spełnieniu JD jest obecność atrybutu Ocena, który zależy od całej trójki encji. W praktyce oznacza to, że nie wszystkie kombinacje studenta, wykładowcy i przedmiotu są możliwe, ponieważ ocena musi być wystawiona przez konkretnego wykładowcę za konkretny przedmiot dla konkretnego studenta. Nawet jeśli w projekcjach binarnych istnieją wszystkie pary, trójka (student, wykładowca, przedmiot) może nie istnieć w oryginalnej tabeli, jeśli ocena nie została jeszcze wystawiona lub taka kombinacja nie jest dozwolona przez regulamin studiów.

Wniosek z tego ćwiczenia jest następujący: mimo że JD istnieje w teorii, w praktyce nie jest spełniona ze względu na atrybut Ocena, który blokuje możliwość dowolnych kombinacji. Tabela pozostaje zatem w 5NF, ponieważ pomimo istnienia JD, nie jest ona spełniona przez dane, a zatem dekompozycja nie jest wymagana. To ćwiczenie doskonale ilustruje, jak ważne jest odróżnienie teoretycznej możliwości wystąpienia JD od jej faktycznego spełnienia w konkretnym systemie.

W naszej przykładowej bibliotece wprowadzamy nowy system rekomendacji, który ma umożliwić bibliotekarzom polecanie czytelnikom konkretnych książek i autorów. System ten wymaga przechowywania informacji o tym, który bibliotekarz poleca którą książkę którego autora, co prowadzi do utworzenia tabeli Rekomendacje o trzech atrybutach: ISBN, Autor oraz ID_Bibliotekarza. Każdy wiersz w tej tabeli interpretujemy jako stwierdzenie, że dany bibliotekarz poleca konkretną książkę napisaną przez konkretnego autora.

Reguły biznesowe w tym systemie są celowo zaprojektowane tak, aby dopuszczać wysoki stopień swobody: każdy bibliotekarz może polecać dowolną książkę bez względu na jej autora, a także może polecać dowolnego autora bez względu na konkretną książkę. Oznacza to, że relacje binarne między parami atrybutów są w pełni niezależne, co stwarza idealne warunki do wystąpienia zależności złączeniowej. Jeśli reguły te są w pełni przestrzegane, każda kombinacja ISBN, autora i bibliotekarza powinna być dozwolona, o ile tylko istnieją odpowiednie związki między parami.

Scenariusz ten został celnie dobrany do zilustrowania mechanizmu JD, ponieważ pokazuje, jak pozornie nieszkodliwy system rekomendacji może ukrywać zależność złączeniową. W praktyce rzadko zdarza się, aby reguły biznesowe pozwalały na taką dowolność, ale właśnie dlatego ten przykład jest tak pouczający. Pokazuje on, że nawet w prostych strukturach trójskładnikowych mogą istnieć złożone zależności wymagające analizy w kontekście 5NF, a ich wykrycie wymaga starannego zbadania reguł biznesowych i danych.

Analiza zależności w tabeli Rekomendacje rozpoczyna się od identyfikacji wszystkich możliwych par atrybutów i określenia, czy między nimi zachodzą jakiekolwiek ograniczenia. Mamy trzy atrybuty: ISBN, Autor oraz ID_Bibliotekarza, które tworzą trzy pary: (ISBN, Autor), (ISBN, ID_Bibliotekarza) oraz (Autor, ID_Bibliotekarza). Każda z tych par reprezentuje inną relację binarną: para (ISBN, Autor) oznacza, że dana książka ma określonego autora, para (ISBN, ID_Bibliotekarza) oznacza polecenie książki przez bibliotekarza, a para (Autor, ID_Bibliotekarza) oznacza polecenie autora przez bibliotekarza.

Z punktu widzenia teorii normalizacji, kluczowe pytanie dotyczy niezależności tych trzech par. Jeśli każda para może występować niezależnie od pozostałych, to znaczy, że wartości w jednej parze nie determinują wartości w trzecim atrybucie, wówczas mamy do czynienia z potencjalną JD. W szczególności, jeśli dla danego ISBN istnieje autor A i bibliotekarz B, a dla tego samego autora A istnieje związek z bibliotekarzem B, to czy musi istnieć wiersz łączący wszystkie trzy wartości w jednym rekordzie?

Odpowiedź na to pytanie zależy wyłącznie od reguł biznesowych systemu. Jeśli system biblioteczny działa według zasady, że bibliotekarz polecający książkę i autora automatycznie poleca tę książkę tego autora, to JD jest spełniona. Jeśli jednak bibliotekarz może selektywnie polecać książki niezależnie od autorów, mimo że poleca zarówno daną książkę, jak i danego autora, to JD nie zachodzi. Ta subtelna różnica w regułach biznesowych decyduje o tym, czy tabela wymaga dekompozycji do 5NF.

Przykładowe dane w tabeli Rekomendacje zostały dobrane tak, aby zilustrować sytuację, w której JD nie jest spełniona, mimo że wszystkie pary atrybutów są obecne w odpowiednich projekcjach. Tabela zawiera trzy wiersze: pierwszy łączy ISBN1 z autorem Żeromskim i bibliotekarzem 1, drugi łączy ISBN1 z autorem Prusem i bibliotekarzem 2, a trzeci łączy ISBN2 z autorem Żeromskim i bibliotekarzem 2. W tych trzech wierszach każda z trzech możliwych par atrybutów występuje co najmniej raz, ale brakuje jednej konkretnej trójki.

Konkretnie, para (ISBN1, Żeromski) istnieje w wierszu pierwszym, para (ISBN1, bibliotekarz 2) istnieje w wierszu drugim, a para (Żeromski, bibliotekarz 2) istnieje w wierszu trzecim. Gdyby JD *{ISBN, Autor}, {ISBN, ID_Bibliotekarza}, {Autor, ID_Bibliotekarza} była spełniona, w tabeli musiałby istnieć wiersz (ISBN1, Żeromski, bibliotekarz 2), ponieważ wszystkie trzy składające się na niego pary są obecne w projekcjach. Taki wiersz jednak nie istnieje, co stanowi dowód na to, że JD nie jest spełniona.

Brak tego wiersza ma konkretne uzasadnienie biznesowe: bibliotekarz 2 nie poleca książki ISBN1 w kontekście autora Żeromskiego, mimo że poleca samego Żeromskiego w książce ISBN2 oraz poleca książkę ISBN1 w kontekście autora Prusa. Ta selektywność poleceń jest w pełni uzasadniona z punktu widzenia reguł biznesowych i pokazuje, że nie wszystkie kombinacje trójek muszą być dozwolone. W rezultacie tabela pozostaje w 5NF, ponieważ JD nie jest spełniona, a dekompozycja nie jest wymagana.

Brak spełnienia zależności złączeniowej w praktyce oznacza, że w systemie obowiązują konkretne reguły biznesowe ograniczające dozwolone kombinacje wartości atrybutów. W przypadku tabeli Rekomendacje, brak wiersza (ISBN1, Żeromski, bibliotekarz 2) wskazuje na to, że bibliotekarz 2 nie poleca Żeromskiego w tej konkretnej książce. Decyzja ta może wynikać z subiektywnej oceny bibliotekarza, który uważa, że twórczość Żeromskiego jest wartościowa, ale konkretna książka ISBN1 nie zasługuje na polecenie w zestawieniu z tym autorem.

Z punktu widzenia integralności danych, brak JD jest zjawiskiem pożądanym, ponieważ odzwierciedla rzeczywiste reguły biznesowe i zapobiega powstawaniu fałszywych skojarzeń między encjami. Gdybyśmy mechanicznie rozłożyli tabelę na trzy projekcje binarne, a następnie je złączyli, otrzymalibyśmy dodatkowy wiersz (ISBN1, Żeromski, bibliotekarz 2), który nie występuje w rzeczywistych danych. Taki fałszywy wiersz stanowiłby naruszenie integralności systemu, sugerując polecenie, które w rzeczywistości nie miało miejsca.

Wniosek praktyczny jest następujący: dekompozycję do 5NF należy wykonywać wyłącznie wtedy, gdy JD jest faktycznie spełniona przez dane i reguły biznesowe. Jeśli JD nie jest spełniona, oznacza to, że system wymaga przechowywania wszystkich trzech atrybutów razem w jednej tabeli, ponieważ tylko w ten sposób można odzwierciedlić istniejące ograniczenia. Próba dekompozycji w takiej sytuacji prowadzi do utraty informacji o rzeczywistych ograniczeniach biznesowych i generowania nieprawdziwych danych.

Zależność złączeniowa jest spełniona, gdy reguły biznesowe dopuszczają wszystkie możliwe kombinacje wartości atrybutów wynikające z istniejących par. W kontekście bibliotecznym oznacza to, że jeśli bibliotekarz poleca daną książkę i poleca danego autora, to automatycznie poleca tę książkę tego autora. Taka sytuacja ma miejsce, gdy system rekomendacji działa według zasady pełnej kompozycyjności: każda kombinacja encji, która jest dozwolona na poziomie par, jest również dozwolona na poziomie trójek.

W praktyce spełnienie JD oznacza, że dane w tabeli muszą zawierać wszystkie kombinacje wynikające z projekcji binarnych. Jeśli w projekcji (ISBN, Autor) mamy parę (ISBN1, Żeromski), w projekcji (ISBN, ID_Bibliotekarza) mamy parę (ISBN1, bibliotekarz 2), a w projekcji (Autor, ID_Bibliotekarza) mamy parę (Żeromski, bibliotekarz 2), to w pełnej tabeli musi istnieć wiersz (ISBN1, Żeromski, bibliotekarz 2). Brak tego wiersza oznacza niespełnienie JD.

Aby JD była spełniona, muszą być zatem spełnione dwa warunki: po pierwsze, reguły biznesowe nie mogą nakładać żadnych ograniczeń na kombinacje trójek poza tymi, które wynikają z par, a po drugie, dane muszą faktycznie zawierać wszystkie wymagane kombinacje. Spełnienie tych warunków jest w praktyce bardzo rzadkie, ponieważ większość systemów ma bogate reguły biznesowe, które naturalnie ograniczają dozwolone kombinacje nawet na poziomie trójek.

Porównanie dwóch scenariuszy, w których JD jest spełniona i nie jest spełniona, pozwala na lepsze zrozumienie praktycznych implikacji piątej postaci normalnej. W scenariuszu, gdzie JD nie jest spełniona, w tabeli brakuje pewnych kombinacji trójek, mimo że wszystkie pary istnieją w odpowiednich projekcjach. Taka sytuacja odzwierciedla istnienie konkretnych reguł biznesowych, które ograniczają dozwolone kombinacje, a tabela pozostaje w 5NF bez konieczności dekompozycji.

W scenariuszu, gdzie JD jest spełniona, wszystkie kombinacje trójek wynikające z par są obecne w tabeli, co oznacza, że reguły biznesowe dopuszczają pełną dowolność kombinacji. W tym przypadku tabela nie znajduje się w 5NF i wymaga dekompozycji na trzy mniejsze tabele binarne. Liczba wierszy w oryginalnej tabeli jest wtedy dokładnie równa liczbie wierszy powstałej ze złączenia trzech projekcji, co potwierdza bezstratność dekompozycji.

Z praktycznego punktu widzenia, różnica między tymi dwoma scenariuszami ma kluczowe znaczenie dla integralności danych. Jeśli JD nie jest spełniona, dekompozycja prowadzi do utraty informacji o rzeczywistych ograniczeniach biznesowych i generowania fałszywych wierszy. Jeśli JD jest spełniona, dekompozycja jest bezpieczna i prowadzi do czystszej struktury danych. Dlatego tak ważne jest wykonanie testu JD przed podjęciem decyzji o dekompozycji, ponieważ błędna ocena może prowadzić do poważnych problemów z integralnością.

Wizualizacja rozkładu tabeli z JD spełnioną na trzy tabele binarne pomaga zrozumieć, jak działa mechanizm dekompozycji w praktyce. Załóżmy, że tabela Rekomendacje zawiera cztery wiersze spełniające JD, a więc każda kombinacja par znajduje odzwierciedlenie w pełnej trójce. Projekcja na atrybuty (ISBN, Autor) daje trzy pary: (ISBN1, Żeromski), (ISBN1, Prus) i (ISBN2, Żeromski). Projekcja na (ISBN, ID_Bibliotekarza) również daje trzy pary: (ISBN1, bibliotekarz 1), (ISBN1, bibliotekarz 2) i (ISBN2, bibliotekarz 2).

Projekcja na (Autor, ID_Bibliotekarza) także zawiera trzy pary: (Żeromski, bibliotekarz 1), (Prus, bibliotekarz 2) i (Żeromski, bibliotekarz 2). Łącznie trzy projekcje zawierają dziewięć wierszy, podczas gdy oryginalna tabela miała tylko cztery wiersze. Złączenie tych trzech projekcji daje w wyniku dokładnie cztery wiersze, które są identyczne z wierszami oryginalnej tabeli. To potwierdza, że dekompozycja jest bezstratna i że JD jest rzeczywiście spełniona.

Wizualizacja ta pokazuje również, dlaczego dekompozycja do 5NF prowadzi do zwiększenia liczby przechowywanych wierszy z czterech do dziewięciu, ale jednocześnie eliminuje ukryte zależności między atrybutami. Każdy fakt jest teraz przechowywany w jednym miejscu: informacja o autorstwie książki znajduje się w tabeli KsiazkiAutorzy, informacja o poleceniu książki przez bibliotekarza w tabeli KsiazkiBibliotekarze, a informacja o poleceniu autora przez bibliotekarza w tabeli AutorzyBibliotekarze. Taka struktura jest bardziej elastyczna i odporna na anomalie.

Po dodaniu 5NF do naszego schematu bibliotecznego, liczba tabel może wzrosnąć z ośmiu do dziesięciu, w zależności od tego, czy niektóre z projekcji binarnych już istnieją w schemacie. Na przykład tabela KsiazkiAutorzy może już istnieć, jeśli wcześniej znormalizowaliśmy dane o autorstwie książek zgodnie z wymaganiami 3NF lub BCNF. W takim przypadku 5NF nie dodaje nowej tabeli, a jedynie wykorzystuje już istniejącą strukturę do przechowywania odpowiednich danych.

W kontekście całego schematu, 5NF często odkrywa brakujące tabele, które powinny były znaleźć się w bazie danych już na etapie projektowania konceptualnego. Jeśli podczas modelowania związku między książkami, autorami i bibliotekarzami pominięto fakt, że każda para tych encji tworzy osobną relację, to 5NF wymusi dodanie odpowiednich tabel. W tym sensie 5NF pełni funkcję weryfikatora poprawności modelu związków encji, ujawniając ukryte powiązania.

Warto zauważyć, że 5NF nie dodaje tabel arbitralnie, ale jedynie wtedy, gdy istnieje ku temu uzasadnienie w postaci spełnionej JD. Jeśli reguły biznesowe nie dopuszczają wszystkich kombinacji, 5NF jest automatycznie spełniona i nie wymaga modyfikacji schematu. Dlatego też proces normalizacji do 5NF jest selektywny i dotyczy wyłącznie tych relacji, w których faktycznie występują zależności złączeniowe niewynikające z kluczy kandydujących.

Piąta postać normalna nie jest zawsze potrzebna, a w praktyce większość systemów bazodanowych działa poprawnie i efektywnie bez jej stosowania. Decyzja o zastosowaniu 5NF powinna być podejmowana na podstawie analizy konkretnych wymagań projektowych, a nie jako automatyczny krok w procesie normalizacji. Większość tabel w rzeczywistych systemach ma prostą strukturę z jednym kluczem głównym i kilkoma atrybutami, co sprawia, że 5NF jest spełniona automatycznie bez konieczności jakichkolwiek działań.

Warunkiem koniecznym do rozważenia 5NF jest obecność relacji trójskładnikowej lub wyższego rzędu, w której wszystkie pary atrybutów są od siebie niezależne. Jeśli taka relacja występuje w systemie, należy zbadać, czy JD jest spełniona przez reguły biznesowe i dane. Jeśli tak, wówczas 5NF wymaga dekompozycji w celu wyeliminowania ukrytej zależności. Jeśli nie, tabela pozostaje w 5NF i nie wymaga modyfikacji.

W praktyce inżynierskiej przyjmuje się, że zatrzymanie na trzeciej postaci normalnej jest optymalnym rozwiązaniem dla większości systemów produkcyjnych. BCNF i 4NF są stosowane w specyficznych sytuacjach, a 5NF pozostaje głównie w sferze akademickiej. Mimo to znajomość 5NF jest ważna, ponieważ pozwala projektantowi na pełne zrozumienie teoretycznych podstaw normalizacji i świadome podejmowanie decyzji o tym, kiedy proces normalizacji można zakończyć.

W tym ćwiczeniu analizujemy tabelę FakturyPozycjeDostawy o atrybutach ID_Faktury, ID_Pozycji, ID_Dostawy oraz Kwota. Klucz główny tabeli stanowi para (ID_Faktury, ID_Pozycji), która jednoznacznie identyfikuje każdą pozycję na fakturze. Potencjalna JD, którą należy zbadać, to *{ID_Faktury, ID_Pozycji}, {ID_Faktury, ID_Dostawy}, {ID_Pozycji, ID_Dostawy}. Celem ćwiczenia jest ustalenie, czy ta JD wynika z kluczy kandydujących i czy jest spełniona przez dane.

Pierwszy podzbiór JD, {ID_Faktury, ID_Pozycji}, jest dokładnie równy kluczowi głównemu, co oznacza, że ta część JD wynika z kluczy kandydujących. Jednak pozostałe dwa podzbiory nie zawierają klucza, a zatem cała JD nie wynika automatycznie z kluczy. W drugim kroku należy sprawdzić, czy JD jest spełniona przez reguły biznesowe: jeśli każda faktura może być związana z wieloma dostawami, a każda pozycja może pochodzić z różnych dostaw, to wszystkie kombinacje par są dozwolone i JD jest spełniona.

W praktyce spełnienie JD w tej tabeli zależy od tego, czy system dopuszcza sytuację, w której ta sama pozycja na fakturze może pochodzić z różnych dostaw w zależności od konkretnej faktury. Jeśli tak, to dla każdej pary faktura-pozycja, faktura-dostawa i pozycja-dostawa musi istnieć odpowiadająca im trójka w oryginalnej tabeli. W przeciwnym razie JD nie jest spełniona i tabela pozostaje w 5NF. To ćwiczenie pokazuje, jak ważne jest zrozumienie reguł biznesowych przed podjęciem decyzji o dekompozycji.

W tym ćwiczeniu projektujemy system recept, w którym lekarze przepisują leki pacjentom w określonych dawkach. Tabela Recepty zawiera atrybuty ID_Lekarza, ID_Pacjenta, ID_Leku, Dawka oraz Data, a klucz główny jest złożony ze wszystkich atrybutów identyfikacyjnych, ponieważ dawka leku zależy od konkretnej kombinacji lekarza, pacjenta i leku. Potencjalna JD, którą należy rozważyć, to *{ID_Lekarza, ID_Pacjenta}, {ID_Lekarza, ID_Leku}, {ID_Pacjenta, ID_Leku}.

Kluczowym czynnikiem decydującym o tym, czy JD jest spełniona, jest atrybut Dawka, który zależy od całej trójki encji. W praktyce oznacza to, że nie wszystkie kombinacje lekarza, pacjenta i leku są dozwolone, ponieważ dawka musi być przepisana przez konkretnego lekarza dla konkretnego pacjenta i konkretnego leku. Nawet jeśli w projekcjach binarnych istnieją wszystkie pary, trójka może nie istnieć w oryginalnej tabeli, jeśli taka kombinacja nie została zrealizowana w postaci recepty.

Wniosek z tego ćwiczenia jest analogiczny do poprzednich: mimo że JD istnieje w teorii, nie jest spełniona w praktyce ze względu na atrybut Dawka, który blokuje możliwość dowolnych kombinacji. Tabela pozostaje zatem w 5NF, ponieważ pomimo istnienia JD, nie jest ona spełniona przez dane. To ćwiczenie dodatkowo podkreśla, że obecność dodatkowego atrybutu opisującego związek między encjami często uniemożliwia spełnienie JD i czyni 5NF automatycznie zachowaną.

Podsumowując dyskusję o praktycznym zastosowaniu piątej postaci normalnej, można sformułować trzy konkretne warunki, które muszą być spełnione jednocześnie, aby dekompozycja do 5NF była uzasadniona. Po pierwsze, tabela musi modelować relację trójskładnikową lub wyższego rzędu, co oznacza, że zawiera co najmniej trzy atrybuty powiązane ze sobą w sposób niezależny. Po drugie, wszystkie pary atrybutów muszą być od siebie niezależne, co oznacza, że wartości w jednej parze nie determinują wartości w trzecim atrybucie.

Po trzecie, zależność złączeniowa musi być faktycznie spełniona przez dane i reguły biznesowe, co można zweryfikować za pomocą testu złączenia projekcji. Jeśli wszystkie trzy warunki są spełnione, 5NF wymaga dekompozycji na osobne tabele binarne. Jeśli którykolwiek z warunków nie jest spełniony, tabela znajduje się w 5NF i nie wymaga modyfikacji. W praktyce wszystkie trzy warunki są spełnione jednocześnie niezwykle rzadko, co wyjaśnia, dlaczego 5NF jest tak rzadko stosowana.

Ostateczna rekomendacja dla projektantów baz danych jest następująca: projektuj schemat w 3NF jako punkt wyjścia, a następnie rozważaj wyższe postaci normalne tylko wtedy, gdy analiza reguł biznesowych wskazuje na konkretne problemy. 5NF powinna być stosowana wyłącznie wtedy, gdy istnieją ku temu wyraźne przesłanki w postaci zidentyfikowanej i spełnionej JD. W przeciwnym razie czas poświęcony na analizę 5NF jest lepiej spożytkowany na inne aspekty projektowania systemu.

Implementację piątej postaci normalnej w systemie MariaDB rozpoczynamy od utworzenia tabeli Rekomendacje, która ma potencjał naruszania 5NF, jeśli zależność złączeniowa okaże się spełniona. Tabela ta zawiera trzy kolumny: ISBN typu VARCHAR o długości 20 znaków, Autor typu VARCHAR o długości 100 znaków oraz ID_Bibliotekarza typu INTEGER. Klucz główny jest złożony ze wszystkich trzech kolumn, co zapewnia, że każda kombinacja ISBN, autora i bibliotekarza może wystąpić w tabeli tylko raz.

Struktura tej tabeli jest zgodna z czwartą postacią normalną, ponieważ nie zawiera żadnych zależności wielowartościowych niewynikających z kluczy. Między atrybutami nie występują dwie niezależne listy, które wymagałyby rozdzielenia na osobne tabele. Jednak z punktu widzenia 5NF, tabela ta wymaga dalszej analizy, ponieważ istnieje w niej potencjalna JD *{ISBN, Autor}, {ISBN, ID_Bibliotekarza}, {Autor, ID_Bibliotekarza}, która może być spełniona w zależności od reguł biznesowych i danych.

W kodzie SQL tworzymy tabelę za pomocą polecenia CREATE TABLE, definiując wszystkie trzy kolumny jako NOT NULL ze względu na ich udział w kluczu głównym. Klauzula PRIMARY KEY zapewnia integralność wewnątrz tabeli, gwarantując, że nie pojawią się duplikaty pełnych trójek. W dalszych krokach wstawimy dane testowe i sprawdzimy, czy JD jest spełniona, co zdecyduje o konieczności dekompozycji do 5NF.

W drugim kroku implementacji wstawiamy do tabeli Rekomendacje trzy wiersze danych testowych, które mają na celu sprawdzenie, czy zależność złączeniowa jest spełniona. Pierwszy wiersz łączy książkę o numerze ISBN1 z autorem Żeromskim i bibliotekarzem 1, drugi wiersz łączy tę samą książkę ISBN1 z autorem Prusem i bibliotekarzem 2, a trzeci wiersz łączy książkę ISBN2 z autorem Żeromskim i bibliotekarzem 2. Po wstawieniu tych trzech wierszy analizujemy, jakie pary atrybutów występują w projekcjach tabeli.

W projekcji na atrybuty ISBN i Autor znajdujemy trzy pary: (ISBN1, Żeromski), (ISBN1, Prus) i (ISBN2, Żeromski). W projekcji na ISBN i ID_Bibliotekarza znajdujemy pary: (ISBN1, bibliotekarz 1), (ISBN1, bibliotekarz 2) i (ISBN2, bibliotekarz 2). W projekcji na Autor i ID_Bibliotekarza znajdujemy pary: (Żeromski, bibliotekarz 1), (Prus, bibliotekarz 2) i (Żeromski, bibliotekarz 2). Wszystkie dziewięć par jest obecnych w odpowiednich projekcjach, co oznacza, że każda para atrybutów występuje w tabeli w jakimś kontekście.

Mimo że wszystkie pary istnieją, w tabeli brakuje wiersza (ISBN1, Żeromski, bibliotekarz 2), który łączyłby wszystkie trzy pary w jedną trójkę. Oznacza to, że JD nie jest spełniona, ponieważ złączenie trzech projekcji wygeneruje dodatkowy wiersz nieobecny w oryginalnej tabeli. Wniosek z tego testu jest jednoznaczny: tabela znajduje się w 5NF i nie wymaga dekompozycji, ponieważ JD nie wynika z danych i reguł biznesowych.

W trzecim kroku modyfikujemy zestaw danych, dodając czwarty wiersz do tabeli Rekomendacje, który czyni zależność złączeniową spełnioną. Nowy wiersz zawiera książkę ISBN1, autora Żeromskiego oraz bibliotekarza 2, czyli dokładnie tę kombinację, której brakowało w poprzednim zestawie danych. Po dodaniu tego wiersza tabela zawiera cztery rekordy, a każda możliwa kombinacja par atrybutów znajduje odzwierciedlenie w odpowiadającej jej trójce.

Weryfikacja spełnienia JD polega na wykonaniu złączenia trzech projekcji i porównaniu wyniku z oryginalną tabelą. W tym przypadku projekcja na (ISBN, Autor) zawiera trzy pary, projekcja na (ISBN, ID_Bibliotekarza) zawiera trzy pary, a projekcja na (Autor, ID_Bibliotekarza) również zawiera trzy pary. Złączenie tych trzech projekcji daje w wyniku cztery wiersze, które są dokładnie takie same, jak wiersze w oryginalnej tabeli Rekomendacje. Oznacza to, że JD jest spełniona, a dekompozycja jest możliwa i bezpieczna.

W tej sytuacji tabela Rekomendacje nie znajduje się w 5NF, ponieważ JD *{ISBN, Autor}, {ISBN, ID_Bibliotekarza}, {Autor, ID_Bibliotekarza} jest spełniona i nie wynika z kluczy kandydujących. Konieczne jest zatem przeprowadzenie dekompozycji na trzy tabele binarne, z których każda będzie przechowywała jedną parę atrybutów. W kolejnych krokach zaimplementujemy tę dekompozycję i zweryfikujemy jej poprawność za pomocą testów SQL.

W czwartym kroku implementacji dokonujemy dekompozycji tabeli Rekomendacje na trzy tabele binarne, zgodnie z wymaganiami piątej postaci normalnej. Pierwsza tabela KsiazkiAutorzy zawiera kolumny ISBN i Autor z kluczem złożonym z obu atrybutów, przechowując informację o tym, którzy autorzy napisali które książki. Druga tabela KsiazkiBibliotekarze zawiera kolumny ISBN i ID_Bibliotekarza z kluczem złożonym, rejestrując, którzy bibliotekarze polecają które książki.

Trzecia tabela AutorzyBibliotekarze zawiera kolumny Autor i ID_Bibliotekarza z kluczem złożonym, przechowując informację o tym, których autorów polecają poszczególni bibliotekarze. Każda z tych tabel ma prostą strukturę z jednym kluczem kandydującym złożonym z dwóch atrybutów, co automatycznie zapewnia zgodność z 5NF. Wszystkie potencjalne JD w tych tabelach są trywialne i wynikają bezpośrednio z kluczy, ponieważ każda tabela ma tylko dwie kolumny.

W kodzie SQL definiujemy każdą tabelę za pomocą polecenia CREATE TABLE z odpowiednimi typami danych i kluczami głównymi. Należy również dodać klauzule FOREIGN KEY łączące kolumnę ISBN z tabelą Ksiazki oraz kolumnę ID_Bibliotekarza z tabelą Bibliotekarze, co zapewni integralność referencyjną w całym schemacie. Po utworzeniu tabel możemy wstawić do nich dane odpowiadające projekcjom oryginalnej tabeli Rekomendacje.

Po utworzeniu trzech tabel binarnych w ramach dekompozycji do 5NF, przystępujemy do wstawienia danych, które odpowiadają projekcjom oryginalnej tabeli Rekomendacje. Do tabeli KsiazkiAutorzy wstawiamy trzy wiersze: książka ISBN1 z autorem Żeromskim, książka ISBN1 z autorem Prusem oraz książka ISBN2 z autorem Żeromskim. Do tabeli KsiazkiBibliotekarze wstawiamy również trzy wiersze: książka ISBN1 polecana przez bibliotekarza 1, książka ISBN1 polecana przez bibliotekarza 2 oraz książka ISBN2 polecana przez bibliotekarza 2.

Do tabeli AutorzyBibliotekarze wstawiamy trzy wiersze: autor Żeromski polecany przez bibliotekarza 1, autor Prus polecany przez bibliotekarza 2 oraz autor Żeromski polecany przez bibliotekarza 2. Łącznie w trzech tabelach mamy dziewięć wierszy, podczas gdy oryginalna tabela Rekomendacje zawierała cztery wiersze. Większa liczba wierszy po dekompozycji jest zjawiskiem normalnym i wynika z faktu, że każdy elementarny fakt jest teraz przechowywany w osobnej tabeli bez redundancji.

Warto zauważyć, że mimo większej łącznej liczby wierszy, każda z tabel binarnych jest prostsza i bardziej wyspecjalizowana niż oryginalna tabela trójskładnikowa. Ponadto, każdy fakt jest przechowywany dokładnie raz, co eliminuje potencjalne anomalie związane z aktualizacją danych. Na przykład informacja o tym, że bibliotekarz 2 poleca autora Żeromskiego, jest przechowywana w jednym wierszu tabeli AutorzyBibliotekarze, a nie w wielu wierszach jak w oryginalnej strukturze.

Szósty krok implementacji polega na weryfikacji poprawności dekompozycji za pomocą testu złączenia bezstratnego. Wykonujemy zapytanie SQL, które łączy wszystkie trzy tabele binarne naturalnie za pomocą odpowiednich kluczy i porównuje wynik z oryginalną tabelą Rekomendacje. Zapytanie łączy tabelę KsiazkiAutorzy z tabelą KsiazkiBibliotekarze po atrybucie ISBN, a następnie łączy wynik z tabelą AutorzyBibliotekarze po atrybutach Autor i ID_Bibliotekarza.

Jeśli dekompozycja jest poprawna, wynik złączenia powinien zawierać dokładnie cztery wiersze, czyli tyle samo, ile zawierała oryginalna tabela Rekomendacje przed dekompozycją. W naszym przypadku, ponieważ JD była spełniona przed dekompozycją, wynik złączenia daje dokładnie cztery wiersze odpowiadające wszystkim kombinacjom trójek. Oznacza to, że dekompozycja jest bezstratna i żadne informacje nie zostały utracone podczas podziału na trzy tabele binarne.

Dla dodatkowej weryfikacji możemy również porównać liczbę wierszy za pomocą funkcji COUNT. Jeśli COUNT z złączenia trzech tabel jest równy COUNT z oryginalnej tabeli, dekompozycja jest w pełni poprawna. Jeśli natomiast COUNT z złączenia jest większy, oznacza to, że JD nie była spełniona i dekompozycja została wykonana błędnie. Ten prosty test ilościowy jest skutecznym narzędziem do automatycznej weryfikacji poprawności dekompozycji w codziennej praktyce administracji bazami danych.

W siódmym kroku analizujemy sytuację, w której JD nie jest spełniona, aby zrozumieć, jakie skutki dla integralności danych miałaby próba dekompozycji w takich warunkach. Gdybyśmy rozłożyli tabelę Rekomendacje zawierającą tylko trzy wiersze na trzy tabele binarne, a następnie złączyli je z powrotem, otrzymalibyśmy cztery wiersze zamiast trzech. Dodatkowy, czwarty wiersz (ISBN1, Żeromski, bibliotekarz 2) powstałby w wyniku złączenia par atrybutów, które istnieją w projekcjach, ale nie występują w oryginalnych danych.

Ten dodatkowy wiersz stanowi fałszywą informację, która sugeruje, że bibliotekarz 2 poleca Żeromskiego w książce ISBN1, podczas gdy w rzeczywistości taka rekomendacja nie istnieje. Wprowadzenie takiego fałszywego wiersza do systemu mogłoby mieć poważne konsekwencje biznesowe, ponieważ czytelnicy otrzymywaliby rekomendacje, które nie zostały faktycznie wystawione przez bibliotekarzy. To pokazuje, jak ważne jest upewnienie się, że JD jest spełniona przed przystąpieniem do dekompozycji.

W praktyce sytuacja, w której złączenie projekcji daje więcej wierszy niż oryginał, jest jednoznacznym sygnałem, że JD nie jest spełniona, a dekompozycja jest niedozwolona. W takim przypadku tabela pozostaje w 5NF i nie wymaga modyfikacji. Należy pamiętać, że 5NF nie wymaga dekompozycji wszystkich tabel, a jedynie tych, w których JD jest faktycznie spełniona. Większość tabel w rzeczywistych systemach pozostaje w 5NF bez konieczności jakichkolwiek zmian strukturalnych.

W ósmym kroku porównujemy dwa scenariusze JD spełnionej i niespełnionej za pomocą konkretnych zapytań SQL, które można wykonać w systemie MariaDB. Dla scenariusza, w którym JD nie jest spełniona, uruchamiamy zapytanie zliczające wiersze w oryginalnej tabeli Rekomendacje, a następnie zapytanie zliczające wiersze powstałe ze złączenia trzech projekcji binarnych. Jeśli wyniki COUNT są różne, oznacza to, że JD nie jest spełniona i dekompozycja jest niedozwolona.

Dla scenariusza, w którym JD jest spełniona, oba zapytania COUNT powinny zwrócić tę samą liczbę, co potwierdza możliwość bezpiecznej dekompozycji. W naszym przykładzie, gdy tabela zawiera cztery wiersze spełniające JD, złączenie projekcji również daje cztery wiersze, a oba zapytania zwracają wartość 4. Różnica w wynikach COUNT jest zatem prostym i skutecznym testem na spełnienie JD.

Porównanie to można również rozszerzyć o wizualną inspekcję wyników złączenia, co pozwala na identyfikację konkretnych fałszywych wierszy w przypadku niespełnionej JD. W praktyce zaleca się wykonywanie obu testów ilościowego COUNT oraz wizualnego SELECT przed podjęciem decyzji o dekompozycji. W systemach produkcyjnych warto również zautomatyzować ten proces poprzez utworzenie procedury składowanej, która wykonuje test JD i zwraca informację o możliwości dekompozycji.

Po dekompozycji do 5NF niektóre zapytania stają się prostsze i bardziej intuicyjne, ponieważ każda tabela przechowuje jeden rodzaj faktów. Na przykład zapytanie o listę bibliotekarzy polecających konkretnego autora, takie jak Stefan Żeromski, wymaga w nowej strukturze wyłącznie odczytu z tabeli AutorzyBibliotekarze bez konieczności stosowania operatora DISTINCT czy złączeń. W oryginalnej strukturze to samo zapytanie wymagałoby odczytu z tabeli Rekomendacje i eliminacji duplikatów.

Zapytanie o książki polecane przez konkretnego bibliotekarza również staje się prostsze, ponieważ wystarczy odczytać odpowiednie wiersze z tabeli KsiazkiBibliotekarze. W oryginalnej strukturze to samo zapytanie wymagałoby odczytu z tabeli Rekomendacje i filtrowania po identyfikatorze bibliotekarza, ale wynik zawierałby również informacje o autorach, które w danym momencie mogą nie być potrzebne. Dekompozycja pozwala zatem na bardziej precyzyjne pobieranie danych.

Należy jednak pamiętać, że niektóre zapytania, które w oryginalnej strukturze były prostymi odczytami z jednej tabeli, po dekompozycji wymagają złączeń. Na przykład zapytanie o pełną informację o rekomendacji łączącej książkę, autora i bibliotekarza wymaga złączenia wszystkich trzech tabel binarnych. Jest to typowy kompromis między czystością struktury danych a wydajnością zapytań, który projektant bazy danych musi uwzględnić przy podejmowaniu decyzji o normalizacji do 5NF.

W dziesiątym kroku analizujemy bardziej złożone zapytania, które wymagają złączeń między tabelami po dekompozycji do 5NF. Przykładem może być zapytanie o listę bibliotekarzy polecających konkretną książkę wraz z nazwiskami autorów tej książki. W nowej strukturze takie zapytanie wymaga złączenia tabeli KsiazkiBibliotekarze z tabelą KsiazkiAutorzy po wspólnym atrybucie ISBN, ponieważ informacja o poleceniu książki i informacja o autorstwie znajdują się w różnych tabelach.

W oryginalnej strukturze to samo zapytanie byłoby prostym SELECT-em z filtrowaniem po ISBN, ale wynik zawierałby wszystkie kombinacje autorów i bibliotekarzy dla danej książki. Po dekompozycji każda kombinacja autora i bibliotekarza dla danej książki musi być jawnie złączona, co może być bardziej kosztowne obliczeniowo, ale jednocześnie bardziej przejrzyste i łatwiejsze do optymalizacji przez system zarządzania bazą danych. Dodatkowo, wynik złączenia jest wolny od fałszywych kombinacji.

W praktyce warto rozważyć utworzenie widoków SQL, które opakowują złączenia trzech tabel binarnych i prezentują dane w formie przypominającej oryginalną strukturę. Widoki takie mogą być użyteczne dla aplikacji, które wymagają dostępu do pełnych informacji o rekomendacjach, podczas gdy bezpośrednie zapytania do tabel binarnych są zarezerwowane dla precyzyjnych odczytów. Takie podejście łączy zalety normalizacji z wygodą programistyczną.

W jedenastym kroku omawiamy najczęstsze błędy popełniane podczas implementacji piątej postaci normalnej, które mogą prowadzić do poważnych problemów z integralnością danych. Pierwszym i najpoważniejszym błędem jest zakładanie istnienia JD tam, gdzie w rzeczywistości nie jest ona spełniona. Programiści często mylnie zakładają, że każda relacja trójskładnikowa automatycznie zawiera JD, podczas gdy w praktyce większość takich relacji ma konkretne ograniczenia biznesowe, które uniemożliwiają spełnienie JD.

Drugim częstym błędem jest dekompozycja tabeli bez uprzedniego testu JD za pomocą złączenia projekcji. Jeśli JD nie jest spełniona, dekompozycja prowadzi do utraty informacji o rzeczywistych ograniczeniach biznesowych i generowania fałszywych wierszy podczas złączenia. Trzecim błędem jest nieprawidłowe zdefiniowanie kluczy głównych w tabelach binarnych, co może prowadzić do powstawania duplikatów i naruszenia integralności danych w nowych tabelach.

Czwartym błędem jest pominięcie kluczy obcych łączących nowe tabele binarne z istniejącymi tabelami słownikowymi. Brak kluczy obcych może prowadzić do pojawienia się danych sierot, czyli wierszy odnoszących się do nieistniejących encji w innych tabelach. Aby uniknąć tych błędów, zaleca się zawsze wykonywać test COUNT przed dekompozycją, starannie definiować klucze główne i obce oraz dokumentować reguły biznesowe uzasadniające dekompozycję.

Podsumowując proces implementacji piątej postaci normalnej w systemie MariaDB, można wyróżnić pięć kluczowych kroków, które należy wykonać sekwencyjnie. Krok pierwszy polega na sprawdzeniu, czy tabela znajduje się w czwartej postaci normalnej, co jest warunkiem koniecznym do analizy 5NF. Krok drugi to identyfikacja potencjalnych zależności złączeniowych poprzez analizę podzbiorów atrybutów i sprawdzenie, czy każdy z nich jest nadkluczem.

Krok trzeci jest najważniejszy i polega na wykonaniu testu COUNT w celu sprawdzenia, czy JD jest faktycznie spełniona przez dane. Jeśli wyniki COUNT dla oryginalnej tabeli i złączenia projekcji są identyczne, JD jest spełniona. Krok czwarty to właściwa dekompozycja, czyli utworzenie osobnych tabel dla każdego podzbioru JD i przeniesienie odpowiednich danych. Krok piąty to weryfikacja poprawności dekompozycji poprzez ponowny test złączenia bezstratnego.

W praktyce krok trzeci prawie zawsze daje wynik negatywny, co oznacza, że JD nie jest spełniona i proces normalizacji kończy się bez modyfikacji schematu. Należy pamiętać, że 5NF to ostatnia postać normalna w modelu relacyjnym po jej osiągnięciu dalsza normalizacja nie jest możliwa ani potrzebna. Jeśli tabela znajduje się w 5NF, oznacza to, że jest w pełni znormalizowana zgodnie ze wszystkimi znanymi kryteriami teorii relacyjnych baz danych.

Przegląd całego procesu normalizacji od pierwszej do piątej postaci normalnej ukazuje systematyczny rozwój teorii relacyjnych baz danych na przestrzeni dziewięciu lat. Pierwsza postać normalna, zdefiniowana przez Edgara Codda w 1970 roku, wprowadziła fundamentalne zasady atomowości wartości i eliminacji powtarzających się grup. Druga i trzecia postać normalna, również autorstwa Codda z 1971 roku, rozwinęły teorię zależności funkcyjnych, eliminując odpowiednio częściowe i przechodnie zależności między atrybutami.

BCNF, zaproponowana przez Boyce i Codda w 1974 roku, zaostrzyła wymagania trzeciej postaci normalnej, wymagając aby każdy wyznacznik zależności funkcyjnej był nadkluczem. Czwarta postać normalna, wprowadzona przez Ronalda Fagina w 1977 roku, rozszerzyła teorię na zależności wielowartościowe. Wreszcie piąta postać normalna, również autorstwa Fagina z 1979 roku, domknęła teorię normalizacji poprzez wprowadzenie zależności złączeniowych, które są najogólniejszym typem zależności w modelu relacyjnym.

Każda kolejna postać normalna jest bardziej restrykcyjna od poprzedniej, co oznacza, że relacja w 5NF jest automatycznie w 4NF, BCNF, 3NF, 2NF i 1NF. Ta hierarchiczna struktura postaci normalnych stanowi fundament teoretyczny projektowania relacyjnych baz danych i jest nauczana na wszystkich kierunkach informatycznych. Mimo że w praktyce rzadko stosuje się postaci wyższe niż 3NF, znajomość całej hierarchii jest niezbędna do pełnego zrozumienia możliwości i ograniczeń modelu relacyjnego.

Śledząc ewolucję schematu bibliotecznego przez kolejne etapy normalizacji, możemy zaobserwować systematyczny wzrost liczby tabel przy jednoczesnym zmniejszeniu redundancji i eliminacji anomalii. Punktem wyjścia była jedna wielka tabela Wypozyczenia zawierająca siedemnaście kolumn, która łączyła dane czytelników, książek i wypożyczeń w jednej strukturze. Po pierwszej postaci normalnej tabela zachowała swoją strukturę, ale wszystkie wartości stały się atomowe, a klucz główny został zdefiniowany.

Druga postać normalna przyniosła radykalną zmianę: z jednej tabeli powstały trzy, rozdzielające dane czytelników, książek i wypożyczeń do osobnych struktur. Trzecia postać normalna dodała tabelę Miasta dla kodów pocztowych, a BCNF wprowadził tabele Opiekunowie i Przypisania_BCNF dla specyficznych zależności funkcyjnych. Czwarta postać normalna rozdzieliła dane kontaktowe czytelników na tabele Telefony i Emaile, zwiększając liczbę tabel do ośmiu.

Piąta postać normalna potencjalnie dodaje dwie lub trzy nowe tabele związane z systemem rekomendacji, w zależności od tego, czy JD jest spełniona i czy niektóre projekcje nie są już zaimplementowane w istniejącym schemacie. Ostatecznie, po pełnej normalizacji, schemat biblioteki może zawierać od dziesięciu do jedenastu wyspecjalizowanych tabel, z których każda przechowuje jeden rodzaj faktów i jest w pełni znormalizowana zgodnie ze wszystkimi wymaganiami teorii relacyjnych baz danych.

W praktyce inżynierii oprogramowania rzadko stosuje się wszystkie postaci normalne w każdym projekcie, a wybór poziomu normalizacji zależy od konkretnych wymagań systemu. Trzecia postać normalna jest uznawana za standardowy poziom normalizacji dla większości systemów produkcyjnych, ponieważ zapewnia dobry balans między integralnością danych a wydajnością zapytań. BCNF jest stosowana w systemach o podwyższonych wymaganiach integralności, takich jak systemy bankowe czy medyczne, gdzie nawet subtelne anomalie mogą mieć poważne konsekwencje.

Czwarta postać normalna znajduje zastosowanie w systemach, które przechowują wiele niezależnych atrybutów dla jednej encji, takich jak numery telefonów, adresy e-mail czy tagi. W takich przypadkach 4NF eliminuje problem produktu kartezjańskiego między niezależnymi listami atrybutów. Piąta postać normalna, jak już wielokrotnie podkreślano, jest stosowana niezwykle rzadko i tylko w specyficznych sytuacjach, gdzie występują zależności złączeniowe.

Denormalizacja, czyli celowe odstąpienie od zasad normalizacji na rzecz wydajności, jest powszechnie stosowana w systemach raportowych i hurtowniach danych. W takich systemach dopuszczalne jest przechowywanie zduplikowanych danych lub preagregowanych wartości w celu przyspieszenia zapytań analitycznych. Kluczową zasadą jest jednak to, że denormalizacja powinna być świadomym wyborem opartym na pomiarach wydajności, a nie domyślnym podejściem do projektowania.

Decyzja o denormalizacji powinna być podejmowana świadomie na podstawie analizy wymagań wydajnościowych i charakterystyki operacji wykonywanych na bazie danych. Denormalizacja jest zalecana przede wszystkim w systemach, w których przeważają operacje odczytu nad operacjami zapisu, a wydajność zapytań jest krytyczna z punktu widzenia użytkownika. Typowymi przykładami są systemy raportowe, hurtownie danych i aplikacje analityczne, gdzie czas odpowiedzi na zapytanie jest ważniejszy niż optymalne wykorzystanie przestrzeni dyskowej.

Denormalizacja może polegać na dodaniu zduplikowanych kolumn do tabel w celu uniknięcia kosztownych złączeń, na przykład przechowywanie nazwy miasta bezpośrednio w tabeli Czytelnicy zamiast odwoływania się do tabeli Miasta za pomocą klucza obcego. Inną formą denormalizacji jest dodanie preagregowanych wartości, takich jak liczba wypożyczeń dla każdej książki, które są aktualizowane przy każdej operacji zapisu, ale znacznie przyspieszają zapytania agregujące. W obu przypadkach należy być świadomym ryzyka niespójności danych.

Denormalizacji nie zaleca się w systemach, w których dane często się zmieniają, ponieważ utrzymanie spójności zduplikowanych danych wymaga dodatkowej logiki biznesowej i zwiększa ryzyko błędów. W systemach transakcyjnych o wysokich wymaganiach integralności, takich jak systemy bankowe, medyczne czy rezerwacyjne, denormalizacja powinna być stosowana z dużą ostrożnością lub w ogóle unikana. W każdym przypadku decyzja o denormalizacji powinna być poprzedzona dokładnymi pomiarami wydajności i analizą kosztów utrzymania spójności danych.

Porównanie wydajności systemów znormalizowanych i zdenormalizowanych ujawnia fundamentalny kompromis między szybkością zapisu a szybkością odczytu danych. Systemy w pełni znormalizowane, zwłaszcza do 3NF i wyższych postaci, optymalizują operacje zapisu poprzez minimalizację redundancji i zapewnienie integralności danych. Każdy fakt jest przechowywany dokładnie w jednym miejscu, co oznacza, że operacje INSERT, UPDATE i DELETE są szybkie i bezpieczne, ale zapytania odczytu wymagają kosztownych złączeń między wieloma tabelami.

Systemy zdenormalizowane z kolei optymalizują operacje odczytu kosztem wolniejszych zapisów i większego zużycia przestrzeni dyskowej. Przechowywanie zduplikowanych danych eliminuje potrzebę złączeń, ale każda aktualizacja musi być propagowana do wszystkich kopii danych. W praktyce oznacza to, że wybór między normalizacją a denormalizacją zależy od charakterystyki systemu: systemy OLTP o dużej liczbie transakcji korzystają z normalizacji, podczas gdy systemy OLAP i hurtownie danych częściej stosują denormalizację.

Optymalnym podejściem jest często zastosowanie strategii hybrydowej, w której dane są przechowywane w postaci znormalizowanej dla operacji transakcyjnych, a dla celów raportowych i analitycznych tworzone są zdenormalizowane widoki lub osobne struktury danych. Takie podejście, znane jako architektura lambda lub architektura kappa, pozwala na czerpanie korzyści z obu światów przy jednoczesnym minimalizowaniu wad każdego z rozwiązań.

Cały cykl prezentacji o normalizacji relacyjnych baz danych składał się z siedmiu części, prowadzących słuchacza od historii rozwoju baz danych przez wszystkie postaci normalne aż do 5NF. Prezentacja o historii baz danych wprowadziła kontekst i motywację do powstania modelu relacyjnego. Kolejne prezentacje szczegółowo omawiały każdą postać normalną, od 1NF zapewniającej atomowość, przez 2NF eliminującą częściowe zależności, 3NF usuwającą zależności przechodnie, BCNF zaostrzającą wymagania 3NF, 4NF rozwiązującą problem MVD, aż po 5NF domykającą teorię zależnościami złączeniowymi.

Każda prezentacja była oparta na tym samym przykładzie bibliotecznym, co pozwoliło na ciągłość narracji i pokazanie, jak ewoluuje schemat bazy danych w miarę stosowania kolejnych postaci normalnych. Punktem wyjścia była jedna wielka tabela z siedemnastoma kolumnami i licznymi anomaliami, a punktem docelowym zestaw dziesięciu wyspecjalizowanych tabel, z których każda jest w pełni znormalizowana i przechowuje jeden rodzaj faktów. Ta ewolucja ilustruje siłę i elegancję teorii normalizacji.

Mimo że w praktyce rzadko stosuje się wszystkie postaci normalne, znajomość całej hierarchii jest niezbędna do świadomego projektowania baz danych. Projektant, który rozumie teorię normalizacji, potrafi ocenić, kiedy proces normalizacji można zakończyć na 3NF, a kiedy konieczne jest zastosowanie wyższych postaci normalnych. Prezentacje te stanowią zatem kompendium wiedzy niezbędnej każdemu inżynierowi baz danych, niezależnie od stopnia zaawansowania projektowanych systemów.

Ostateczna rada dla studentów kończących cykl nauki o normalizacji brzmi: traktuj normalizację jako narzędzie, a nie dogmat. Znajomość reguł normalizacji jest niezbędna, ale równie ważna jest umiejętność świadomego odstąpienia od tych reguł, gdy wymaga tego specyfika projektowanego systemu. W praktyce inżynierskiej najważniejsza jest umiejętność znalezienia złotego środka między czystością teoretyczną a wydajnością praktyczną, co wymaga doświadczenia i głębokiego zrozumienia kompromisów.

Zalecany poziom normalizacji dla większości systemów produkcyjnych to 3NF jako minimum, BCNF dla systemów o podwyższonych wymaganiach integralności, 4NF w przypadku niezależnych list atrybutów oraz 5NF tylko wtedy, gdy analiza reguł biznesowych wskazuje na istnienie zależności złączeniowych. Pamiętaj, że denormalizacja powinna być zawsze świadomym wyborem, a nie wynikiem ignorancji lub lenistwa projektowego. Projektuj od razu z myślą o normalizacji, ponieważ przebudowa istniejącego schematu jest zawsze bardziej kosztowna niż zaprojektowanie go poprawnie od początku.

Kończąc, zachęcam do dalszego zgłębiania tematyki baz danych poza standardowym kursem normalizacji. Warto zapoznać się z takimi zagadnieniami jak modelowanie wymiarowe w hurtowniach danych, bazy NoSQL i ich modele danych, a także nowoczesne techniki optymalizacji zapytań w systemach relacyjnych. Teoria normalizacji stanowi solidny fundament, ale prawdziwa biegłość w projektowaniu baz danych wymaga ciągłego uczenia się i praktyki w różnorodnych projektach.

Gratulujemy dotarcia do końca cyklu prezentacji o normalizacji relacyjnych baz danych. Od pierwszej publikacji Edgara Codda w 1970 roku, przez prace Ronalda Fagina w latach siedemdziesiątych, aż do współczesnych implementacji w systemach takich jak MariaDB, teoria normalizacji stanowi niezmienny fundament projektowania baz danych. Mimo upływu lat podstawowe zasady normalizacji pozostają aktualne i są nauczane na wszystkich kierunkach informatycznych na całym świecie.

Mamy nadzieję, że zdobyta wiedza pozwoli Państwu projektować czyste, wydajne i łatwe w utrzymaniu systemy bazodanowe. Pamiętajcie, że normalizacja to nie tylko zbiór reguł, ale przede wszystkim sposób myślenia o danych i ich wzajemnych powiązaniach. Umiejętność identyfikacji zależności między atrybutami, przewidywania potencjalnych anomalii i projektowania struktur minimalizujących redundancję jest nieoceniona w codziennej pracy inżyniera baz danych.

Życzymy powodzenia w dalszej nauce i rozwijaniu umiejętności w zakresie projektowania i administracji baz danych. Teoria normalizacji to dopiero początek drogi w świecie relacyjnych baz danych, ale stanowi niezbędny fundament dla bardziej zaawansowanych zagadnień, takich jak optymalizacja zapytań, modelowanie danych czy projektowanie systemów rozproszonych. Powodzenia na egzaminach i w przyszłej karierze zawodowej.