Spis treści
Postaci normalne w relacyjnych bazach danych
Normalizacja baz danych polega na takim sformalizowaniu zapisu danych w tabeli, aby spełniły one założenia teoretyczne postaci normalnych. Opierać się będziemy na najczęściej spotykanych i stosowanych postaciach normalne czyli:
- Pierwsza postać normalna (1NF)
- Druga postać normalna (2NF)
- Trzecia postać normalna (3NF)
W literaturze można również trafić na postaci normalne takie jak:
- Postać normalna Boyce’a Codda
- Czwarta postać normalna (4NF)
- Piąta postać normalna (5NF)
Pierwsza postać normalna
Rozważmy przykład tabeli zawierającej pozycje w menu pizzerii:
Pierwsza postać normalna mówi o tym, że każda wartość w bazie danych powinna być atomowa (czyli niepodzielna). Przedstawiony przykład nie spełnia tej zasady. Przede wszystkim w każdej z pozycji widnieje lista składników. Co więcej, część składników powtarza się w kilku pozycjach. W przypadku chęci modyfikacji składnika, na przykład zastąpienia pozycji ser pozycją ser mozarella, konieczne będzie zmodyfikowanie wszystkich pozycji w tabeli. Przeszukiwanie tabeli o takiej strukturze pod kątem wykorzystanych składników również pozostawia wiele do życzenia.
W przedstawionym przypadku rozwiązaniem jest zastosowanie relacji wiele-do-wielu i podział przedstawionej tabeli na tabelę z pozycjami, tabelę ze składnikami oraz tabelę pośredniczącą zawierającą informację o tym, jakie składniki zawiera dana pozycja. Dzięki temu, składnik staje się osobną encją w bazie danych, posiada klucz podstawowy przez co jest identyfikowalny i unikatowy. Przedstawiona tabela sprowadzona do pierwszej postaci normalnej wygląda następująco:
Innymi przykładami, często występującymi w bazach danych, gdzie warto zastosować pierwszą postać normalną jest rozdzielenie pola z imieniem i nazwiskiem na dwa osobne czy wspomniany już podział adresu na ulicę i miasto.
Druga postać normalna
Pierwszy warunek niezbędny do spełnienia założeń drugiej postaci normalnej, to spełnienie pierwszej postaci normalnej. Drugi warunek konieczny mówi o tym, że wszystkie kolumny w tabeli muszą zależeć od klucza głównego. Przedstawiam przykład tabeli nie spełniającej drugiej postaci normalnej:
Przedstawiona tabela zawiera dane dotyczące zamówień w sklepie internetowym. Pierwsza postać normalna jest spełniona, ponieważ każda kolumna jest atomowa. Niemniej jednak przedstawiona tabela zawiera zdecydowanie zbyt dużo niepowiązanych ze sobą danych. Przede wszystkim, dane klienta tj. imię, nazwisko, adres i miasto należy wydzielić do osobnej tabeli. Dla uproszczenia załóżmy, że w jednym zamówieniu może znajdować się tylko jedne produkt. W takim wypadku, zamiast nazwy produktu i jego ceny, w tabeli powinien znaleźć się klucz obcy wskazujący na rekord w tabeli z produktami. Tabela z zamówieniami po normalizacji wygląda następująco:
Wszystkie dane niepowiązane z zamówieniami zostały przeniesione do innych tabel, zaś w zamówieniu przechowywane są jedynie klucze obce.
Trzecia postać normalna
Pierwszym warunkiem koniecznym do spełnienia trzeciej postaci normalnej jest, aby normalizowana tabela spełniała drugą postać normalną. Drugi warunek konieczny do spełnienia mówi o tym, że niekluczowa kolumna nie może zależeć od innej niekluczowej kolumny. Innymi słowy, żadna z kolumn nie będąca kluczem podstawowym nie może zależeć od innej kolumny niebędącej kluczem podstawowym. Poniżej przykład tabeli, która będzie poddana normalizacji:
Powyższa tabela zawiera listę kontrahentów, w której można znaleźć takie wartości jak nazwa firmy, adres, miasto, telefon i numer kierunkowy. Problemem w przedstawionej tabeli jest kolumna z numerem kierunkowym. Numer kierunkowy w żaden sposób nie zależy od klucza podstawowego, a od miasta, które nie jest kluczem podstawowym. W tej sytuacji należałoby wydzielić pola city oraz dial_code do osobnej tabeli, a w omawianej tabeli dodać klucz obcy wskazujący na tabelę zawierającą pasujące miasto oraz numer kierunkowy.