Formy normalne bazy danych

3.1 Normalizacja bazy danych

Postać normalna to właściwość relacji w relacyjnym modelu danych, która charakteryzuje ją pod względem redundancji, potencjalnie prowadząc do logicznie błędnych wyników próbkowania lub zmiany danych. Postać normalna jest zdefiniowana jako zestaw wymagań, które musi spełniać relacja (tabele w bazie danych).

Proces przekształcania relacji w bazie danych do postaci zgodnej z normalnymi formami nazywany jest normalizacją. Normalizacja ma na celu doprowadzenie struktury bazy danych do postaci zapewniającej minimalną redundancję logiczną i nie ma na celu zmniejszenia lub zwiększenia wydajności ani zmniejszenia lub zwiększenia fizycznej objętości bazy danych .

Ostatecznym celem normalizacji jest zmniejszenie potencjalnej niespójności informacji przechowywanych w bazie danych. Ogólny cel procesu normalizacji jest następujący:

• wykluczenie niektórych rodzajów zwolnień;
• naprawić niektóre anomalie aktualizacji;
• opracowanie projektu bazy danych, która jest wystarczająco „wysokiej jakości” reprezentacją świata rzeczywistego, jest intuicyjna i może służyć jako dobra podstawa do późniejszej rozbudowy;
• uproszczenie procedury stosowania niezbędnych ograniczeń integralności.

Nadmiarowość jest zwykle eliminowana przez dekompozycję relacji w taki sposób, że w każdej relacji przechowywane są tylko fakty podstawowe (to znaczy fakty, które nie pochodzą z innych przechowywanych faktów).

Chociaż koncepcje normalizacji są bardzo przydatne w projektowaniu baz danych, w żadnym wypadku nie są one uniwersalnymi ani wyczerpującymi sposobami poprawy jakości projektu bazy danych. Wynika to z faktu, że istnieje zbyt duża różnorodność możliwych błędów i niedociągnięć w strukturze bazy danych, których nie można wyeliminować poprzez normalizację.

Mimo tych rozważań teoria normalizacji jest bardzo cennym osiągnięciem teorii i praktyki relacyjnej, ponieważ dostarcza naukowo rygorystycznych i solidnych kryteriów jakości projektu bazy danych oraz formalnych metod poprawy tej jakości. To sprawia, że ​​teoria normalizacji wyróżnia się spośród czysto empirycznych podejść do projektowania, które są oferowane w innych modelach danych. Ponadto można argumentować, że w całej dziedzinie informatyki praktycznie nie ma metod oceny i doskonalenia rozwiązań projektowych, które byłyby porównywalne z teorią normalizacji relacyjnych baz danych pod względem poziomu rygoru formalnego.

Normalizacja jest czasami krytykowana na podstawie tego, że „to po prostu zdrowy rozsądek”, a każdy kompetentny profesjonalista „naturalnie” zaprojektuje w pełni znormalizowaną bazę danych bez konieczności stosowania teorii zależności.

Jednak, jak zauważył profesor Christopher Date, normalizacja to właśnie zasady zdrowego rozsądku, którymi kieruje się w umyśle dojrzałego projektanta, to znaczy zasady normalizacji są sformalizowanymi zdrowym rozsądkiem . Tymczasem zidentyfikowanie i sformalizowanie zasad zdrowego rozsądku jest zadaniem bardzo trudnym, a sukces w jego rozwiązaniu jest znaczącym osiągnięciem.

3.2 Pierwsza postać normalna

Pierwsza postać normalna (1NF) jest podstawową postacią normalną relacji w relacyjnym modelu danych.

Zmienna relacji jest w pierwszej postaci normalnej wtedy i tylko wtedy, gdy w dowolnej prawidłowej wartości tej zmiennej każda krotka relacji zawiera dokładnie jedną wartość dla każdego z atrybutów.

W modelu relacyjnym relacja jest zawsze w pierwszej postaci normalnej, zgodnie z definicją pojęcia relacji.

Jeśli chodzi o różne tabele, mogą one nie być poprawnymi reprezentacjami relacji, a zatem mogą nie znajdować się w 1NF. Zgodnie z definicją Christophera Date'a dla takiego przypadku, tabela jest znormalizowana (równoważnie, jest w pierwszej postaci normalnej) wtedy i tylko wtedy, gdy jest bezpośrednią i prawdziwą reprezentacją jakiejś relacji. Mówiąc dokładniej, dana tabela musi spełniać pięć następujących warunków:

• Nie ma kolejności rzędów od góry do dołu (innymi słowy, kolejność rzędów nie przekazuje żadnych informacji).
• Nie ma kolejności kolumn od lewej do prawej (innymi słowy, kolejność kolumn nie zawiera żadnych informacji).
• Brak zduplikowanych linii.
• Każde przecięcie wiersza i kolumny zawiera dokładnie jedną wartość z odpowiedniej dziedziny (i nic więcej).
• Wszystkie kolumny są „zwykłe”.

„Regularność” wszystkich kolumn tabeli oznacza, że ​​w tabeli nie ma żadnych „ukrytych” elementów, do których można uzyskać dostęp tylko przez wywołanie jakiegoś specjalnego operatora zamiast odwoływania się do zwykłych nazw kolumn, lub które prowadzą do skutków ubocznych dla wierszy lub tabele podczas wywoływania operatorów standardowych.

Oryginalna nieznormalizowana (to znaczy niepoprawna reprezentacja jakiejś relacji):

Tabela zredukowana do 1NF, która jest poprawną reprezentacją pewnej relacji:

3.3 Druga postać normalna

Zmienna relacji jest w drugiej postaci normalnej wtedy i tylko wtedy, gdy jest w pierwszej postaci normalnej i każdy atrybut niebędący kluczem jest nieredukowalnie zależny od (każdego) swojego klucza kandydującego .

Nieredukowalność oznacza, że ​​potencjalny klucz nie zawiera mniejszego podzbioru atrybutów, z których można również wyprowadzić tę zależność funkcjonalną. W przypadku nieredukowalnej zależności funkcjonalnej często stosuje się równoważną koncepcję „pełnej zależności funkcjonalnej”.

Jeśli klucz kandydujący jest prosty, to znaczy składa się z pojedynczego atrybutu, to wszelka zależność funkcjonalna od niego jest nieredukowalna (kompletna). Jeśli klucz kandydujący jest kluczem złożonym, to zgodnie z definicją drugiej postaci normalnej w relacji nie może być żadnych atrybutów niebędących kluczami, które zależą od części złożonego klucza kandydującego.

Przykład konwersji relacji do drugiej postaci normalnej

Niech para atrybutów {branża firmy, stanowisko} tworzy klucz podstawowy w następującej relacji:

Powiedzmy, że wynagrodzenie zależy od branży i stanowiska, a dostępność komputera zależy tylko od stanowiska.

Istnieje zależność funkcjonalna Pozycja -> Posiadanie komputera, w której lewa strona (wyznacznik) jest tylko częścią klucza podstawowego, co narusza warunek drugiej postaci normalnej.

Aby zredukować do 2NF, pierwotną relację należy rozłożyć na dwie relacje:

3.4 Trzecia postać normalna (3NF)

Zmienna relacji R jest w 3NF wtedy i tylko wtedy, gdy spełnione są następujące warunki:

• Rjest w drugiej postaci normalnej.
• brak atrybutu niebędącego kluczemRnie jest w przechodniej zależności funkcjonalnej od klucza kandydującegoR.

Wyjaśnienia do definicji:

Niekluczowy atrybut relacji R to atrybut, który nie należy do żadnego z kandydujących kluczy R.

Funkcjonalna zależność zbioru atrybutów Z od zbioru atrybutów X (pisane X → Z, wymawiane „x determinuje z”) jest przechodnia, jeśli istnieje taki zbiór atrybutów Y, że X → Y i Y → Z. W tym przypadku żaden ze zbiorów X, Y i Z nie jest podzbiorem drugiego, tj. zależności funkcjonalne X → Z, X → Y i Y → Z nie są trywialne, nie ma też zależności funkcjonalnej Y → X.

Definicja 3NF, równoważna definicji Codda, ale inaczej sformułowana, została podana przez Carlo Zaniolo w 1982 roku. Zgodnie z nim zmienna relacji jest w 3NF wtedy i tylko wtedy, gdy każda z jej zależności funkcjonalnych X → A spełnia co najmniej jeden z następujących warunków:

• X zawiera A (to znaczy X → A jest trywialną zależnością funkcjonalną)
• X - superklucz
• A jest atrybutem klucza (to znaczy A jest częścią klucza kandydującego).

Definicja Zaniolo jasno określa różnicę między 3NF a bardziej rygorystyczną postacią normalną Boyce'a-Codda (BCNF): BCNF wyklucza trzeci warunek („A jest atrybutem kluczowym”).

Pamiętne i tradycyjnie opisowe podsumowanie definicji 3NF Codda zostało podane przez Billa Kenta: każdy atrybut niebędący kluczem „powinien dostarczać informacji o kluczu, pełnym kluczu i tylko o kluczu ” .

Warunek zależności od „pełnego klucza” atrybutów niekluczowych zapewnia, że ​​relacja jest w drugiej postaci normalnej; a warunkiem polegania na „niczym poza kluczem” jest to, że są w trzeciej postaci normalnej.

Chris Date mówi o podsumowaniu Kenta jako o „intuicyjnie atrakcyjnej cesze” 3NF i zauważa, że ​​z niewielką modyfikacją może ono również służyć jako definicja bardziej rygorystycznej postaci normalnej Boyce’a-Codda: „każdy atrybut musi dostarczać informacji o kluczowym , pełny klucz i nic poza kluczem.

Wersja definicji 3NF Kenta jest mniej ścisła niż wersja sformułowania Data w postaci normalnej Boyce'a-Codda, ponieważ ta pierwsza stwierdza tylko, że atrybuty niebędące kluczami zależą od kluczy.

Atrybuty podstawowe (które są kluczami lub ich częściami) wcale nie muszą być funkcjonalnie zależne; każdy z nich przekazuje informacje o kluczu, podając sam klucz lub jego część. Należy tutaj zauważyć, że ta reguła obowiązuje tylko dla atrybutów niebędących kluczami, ponieważ zastosowanie jej do wszystkich atrybutów całkowicie wyłączy wszystkie złożone klucze alternatywne, ponieważ każdy element takiego klucza naruszy warunek „pełnego klucza”.

Rozważmy zmienną relacyjną R1 jako przykład:

Każdy pracownik należy wyłącznie do jednego działu; każdy wydział ma jeden telefon. Atrybut Pracownik jest kluczem podstawowym. Pracownicy nie mają telefonów osobistych, a numer telefonu pracownika zależy wyłącznie od działu.

W przykładzie istnieją następujące zależności funkcjonalne: Pracownik → Dział, Dział → Telefon, Pracownik → Telefon.

Zmienna relacyjna R1 jest w drugiej postaci normalnej, ponieważ każdy atrybut ma nieredukowalną zależność funkcyjną od potencjalnego kluczowego Pracownika.

Relacja Pracownik → Telefon jest przechodnia, więc relacja nie jest w trzeciej postaci normalnej.

Podział R1 skutkuje dwiema zmiennymi relacyjnymi, które znajdują się w 3NF:

Relację początkową R1 w razie potrzeby można łatwo otrzymać w wyniku operacji łączenia relacji R2 i R3.