Normalizacja baz danych – czym jest postać normalna?

Normalizacja baz danych jest procesem, który polega na strukturyzacji bazodanowej, a dotyczy zwykle relacyjnych baz danych. Ma związek z wykorzystaniem tak zwanych postaci normalnych, których celem jest zmniejszenie nadmiarowości danych oraz wsparcie ich integralności. Poniższy artykuł przybliża najważniejsze problemy, jakie rozwiązać może poprawnie przeprowadzona normalizacja.

Na czym polega normalizacja baz danych?

Termin normalizacji baz danych wprowadził Edgar F. Codd w ramach swojego modelu relacyjnego, który przedstawił w A Relational Model of Data for Large Shared Data Banks. Proces ten pozwala projektować, jak również organizować każdą kolumnę (atrybuty) oraz tabelę (relacje) konkretnej bazy. Celem rozbudowanych działań normalizacyjnych jest także zapewnienie poprawnego wymuszania zależności pomiędzy nimi bez zbędnej redundancji. 

Istnieje szereg reguł formalnych, których właściwa implementacja pozwala rozbić poszczególne rekordy celem sprawniejszego działania systemu. Zasady te dotyczyć mogą syntezy (budowy nowego projektu bazodanowego), albo też dekompozycji (ulepszenia istniejącego projektu). Pierwsze reguły opracowane zostały już w 1970 roku przez wspomnianego wcześniej twórcę relacyjnych baz danych.

Po co stosować normalizację relacyjnych baz danych?

Okazuje się, że gromadzenie nadmiarowych danych przyczynia się do marnowania przestrzeni dyskowej oraz kłopotów z wydajnością. Jeżeli zmieniamy dane w jednym miejscu, muszą one zostać zmienione w ten sam sposób w innych lokalizacjach. O wiele łatwiej zmienić konkretną informację (np. adres klienta), jeśli przechowuje się ją wyłącznie w jednej konkretnej tabeli (np. klienci).

O ile przechowywanie adresów w sekcji poświęconej klientom ma sens, o tyle nie powinny się tam już znaleźć informacje na temat wynagrodzeń pracowników. Gdy dane nie są spójne, dochodzić może do skomplikowanych problemów w kontekście odnalezienia interesujących nas informacji. Tego typu niespójności zależności należy unikać i właśnie temu służą procesy normalizacyjne. W modelach relacyjnych chodzi przecież o łatwe łączenie i odnajdywanie danych według właściwie określonego klucza.

Jeszcze raz powołać się musimy na Codda, który w ramach określania procesu normalizacji zaproponował kluczowe pojęcie. Chodzi o postaci normalne (zwane też formami normalnymi), które określają reguły, wedle jakich należy przestrzegać normalizacji. To dzięki nim uda się uniknąć wszelkich anomalii wynikających z nadmiarowego lub błędnego zarządzania danymi.

Pierwsza postać normalna 1NF

Wśród najważniejszych czynników określających zasadę działania tej reguły, należy wymienić:

• Usunięcie powtarzających się grup w ramach pojedynczych tabel.
• Tworzenie oddzielnej tabeli dla pojedynczego zestawu danych relacyjnych.
• Określenie każdego z zestawów dzięki kluczowi podstawowemu.

Reguła ta dotyczy atomowości danych, a więc sytuacji, gdy tabela (encja) przechowuje dane atomowo. Każda komórka to konkretna informacja, co zapewnia najbardziej efektywną pracę z zapytaniami. Dzięki tej podstawowej formie pojawia się też klucz główny. To on odpowiedzialny jest za identyfikację każdego wiersza. Nie występują tutaj kolekcje, a struktura bazodanowa opiera się na pojedynczych informacjach w pojedynczych wierszach.

Druga postać normalna 2NF

Wprowadzenie drugiej formy normalnej ma na celu przede wszystkim:

• Budowę osobnych tabel dla zestawów wartości powiązanych z wieloma zapisami.
• Ustalenie relacji pomiędzy tabelami przy użyciu klucza obcego.

Zgodnie z teorią tej reguły, poszczególne zapisy powinny być zależne wyłącznie od klucza głównego konkretnej tabeli. Przykładowo, warto pochylić się nad poruszonym wcześniej adresem klienta. Informacji tej potrzebować mogą tabele z danymi klientów, ale także dotyczące zamówień, dostaw, fakturowania, należności czy kolekcji. Nie musisz przetrzymywać adresu klienta w każdej tabeli z osobna, jeśli znormalizujesz dane do jednej tabeli z adresami.

Trzecia postać normalna 3NF

Głównym celem implementacji tej formy w swojej relacyjnej bazie danych jest:

• Usunięcie pół, które nie zależą od klucza.

Jeżeli wartości zapisu nie stanowią części klucza rekordu, wówczas nie powinny się tam znajdować. Ogólnie rzecz biorąc, zawsze, gdy zawartość grup lub pól dotyczy więcej niż jednego rekordu w tabeli, warto przenieść je do osobnej encji.

Przykładowo, możesz potrzebować nazwy i adresu uniwersytetu osoby ubiegającej się o pracę w tabeli przeznaczonej kandydatom. Z drugiej strony, lista wszystkich uczelni wyższych może być potrzebna również w innych celach. Jeżeli informacje o uniwersytetach znajdują się w tabeli Kandydaci, wówczas nie da się wyświetlić szkół bez wyświetlania kandydatów. W takim przypadku przydatne jest stworzenie osobnej tabeli Uniwersytety oraz połączenie jej z Kandydatami za pomocą klucza kodu uczelni.

Warto dodać, że zastosowanie się do reguły 3NF może okazać się przydatne wyłącznie w sytuacji częstej zmiany danych. Jeżeli w bazie pozostaną pola zależne, należy tak zaprojektować aplikację, by zmuszała użytkownika do weryfikacji wszystkich powiązanych pól w razie wprowadzenia jakichkolwiek modyfikacji.

Jeżeli szukasz praktycznego kursu z PostgreSQL, sprawdź Kurs Praktyczna Administracja PostgreSQL. Mocno praktyczne podejście, gotowe skrypty SQL i wiele więcej. Ponad 640 zadowolonych studentów.

Normalizacja baz – do czego się przydaje?

Relacyjny model danych powstał z myślą o ułatwieniu organizacji, przechowywania i wyciągania informacji z bazy. Wykonując projekt bazy należy się zastanowić, po co tworzyć te wszystkie tabele i ustawiać pomiędzy nimi relacje. Praktyczna strona budowy schematu bazy danych ma sporo korzyści, które ułatwiają administratorom (DBA) i użytkownikom poprawne poruszanie się po informacjach.

Wiesz już, czym jest normalizacja i jak działają jej trzy najbardziej podstawowe formy. Każda reguła wpływa pozytywnie na codzienną pracę z danymi, więc warto stosować je w swoim SQL. Pierwsze trzy reguły (spośród jedenastu obecnie opracowanych) przydają się między innymi do walki z następującymi problemami:

• Jedna i ta sama informacja pojawia się w wielu wierszach jednocześnie. Zjawisko to wpływa negatywnie na przestrzeń dyskową oraz tworzy nieporządek w ramach bazy. To z kolei przekłada się na większą liczbę operacji odczytu i zapisu. Cierpi na tym również pamięć RAM serwera.
• Kłopotliwa aktualizacja informacji. Jeżeli ta sama informacja funkcjonuje w kilku wierszach, aktualizacja wymaga zmiany w każdym wierszu z osobna. Zapominając o jednym wpisie można doprowadzić do wielu błędów i nieprawidłowości.
• Kolumny zawierają niepotrzebne kolekcje wartości. Gdy dochodzi do takiej sytuacji, nie da się przeprowadzić podstawowych operacji w obrębie danych. Nieefektywność pracy z takimi zapisami skutkuje brakiem pełnej integralności i kontroli nad danymi.
• Przypadkowa utrata danych. Częstym problemem, z którym musi sobie poradzić normalizacja, jest usuwanie rekordów, które powoduje przypadkową utratę danych. Na przykład usuwając pozycję zamówienia traci się adres klienta.

Warto wspomnieć też o tym, że istnieje kilka reguł, które mogą przydać się przy rozważaniach teoretycznych. Mowa chociażby o postaci normalnej Boyce’a-Codda (BCNF lub 3.5NF), czwartej postaci normalnej 4NF, a także piątej postaci normalnej 5NF. Jest to jednak temat na osobny artykuł.