Normalizacja bazy danych

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacja, szukaj

Normalizacja bazy danych jest to proces mający na celu eliminację powtarzających się danych w relacyjnej bazie danych. Główna idea polega na trzymaniu danych w jednym miejscu, a w razie potrzeby linkowania do danych. Taki sposób tworzenia bazy danych zwiększa bezpieczeństwo danych i zmniejsza ryzyko powstania niespójności (w szczególności problemów anomalii).

Istnieją sposoby ustalenia czy dany schemat bazy danych jest „znormalizowany”, a jeżeli jest to jak bardzo. Jednym ze sposobów jest przyrównanie danej bazy do schematów zwanych postaciami normalnymi (ang. normal forms lub NF). Normalizacja bazy danych do konkretnej postaci może wymagać rozbicia dużych tabel na mniejsze i przy każdym wykonywaniu zapytania do bazy danych ponownego ich łączenia. Zmniejsza to wydajność, więc w niektórych przypadkach świadoma denormalizacja (stan bez normalizacji) jest lepsza – zwłaszcza w systemach niekorzystających z modelu relacyjnego (np. OLAP).

Normalizacja nie usuwa danych, tylko zmienia schemat bazy danych. Normalizacja przeprowadza bazę danych z jednego stanu spójnego (przed normalizacją) w inny stan spójny (po normalizacji). Jedyna różnica polega na innym układzie danych i relacji pomiędzy nimi, ale bez utraty danych (ewentualnie dodawane są nowe klucze główne).

Postacie Normalne[edytuj | edytuj kod]

Edgar Frank Codd (twórca normalizacji) początkowo wymyślił 3 postacie normalne: 1NF, 2NF i 3NF. Obecnie istnieją jeszcze inne postacie, ale 3NF jest powszechnie uznawana za wystarczającą do większości projektów. Większość tabel spełniając postać 3NF, spełnia także BCNF (ang. Boyce-Codd normal form). 4NF i 5NF są następnymi rozszerzeniami, a 6NF jest używana do baz uwzględniających w modelu relacyjnym wymiar czasowy.

Normalizacja według postaci powyżej 3NF może być skomplikowana ze względu na SQL, lecz brak normalizacji (lub niepełna normalizacja) naraża bazę danych na problemy uszkodzenia danych (anomalie). Pełne znormalizowanie, nawet gdy nie jest wspierane przez technologię, jest warte rozważenia, gdyż pomaga wykryć wszystkie potencjalne braki spójności.

1NF[edytuj | edytuj kod]

Pierwsza postać normalna. Jej jedynym warunkiem jest aby każda składowa w każdej komórce była elementarna (nie dawała podzielić się na mniejsze wartości). Ważną cechą relacji utworzonych zgodnie z modelem relacyjnym jest to, że zawsze są znormalizowane – spełniają 1NF.

Przykład:

Czy pole adres jest polem elementarnym czy nie?

Jeśli wiemy, że w czasie operowania na bazie zawsze będziemy potrzebowali całego adresu, to pole adres możemy uznać za elementarne. Jeśli jednak dopuszczamy możliwość, że będziemy potrzebowali tylko samej miejscowości, to wtedy pole adres nie jest już elementarne i nie spełnia 1NF. Należy więc rozbić pole adres, np. na pola: ulica, miejscowość, kod pocztowy (czyli na pola elementarne).

2NF[edytuj | edytuj kod]

Przed przystąpieniem do zapoznania się z poszczególnymi postaciami normalnymi należy zapoznać się z kilkoma definicjami.

Potrzebne definicje:

  1. Atrybut funkcyjnie zależny od innego atrybutu.
  2. Atrybut w pełni funkcyjnie zależny od innego atrybutu.
  3. Atrybut relacji podstawowy.
  4. Atrybut relacji wtórny.

Relacja jest w drugiej postaci normalnej tylko wtedy, gdy jest w pierwszej postaci normalnej. Ponadto druga postać normalna zabrania, aby dla zdefiniowanego klucza istniał podzbiór atrybutów podstawowych, który identyfikuje atrybuty wtórne. Innymi słowy – aby każdy atrybut wtórny tej relacji był w pełni funkcyjnie zależny od wszystkich kluczy tej relacji.

3NF[edytuj | edytuj kod]

Relacja jest w trzeciej postaci normalnej tylko wtedy, gdy jest w drugiej postaci normalnej i każdy atrybut wtórny jest tylko bezpośrednio zależny od klucza głównego. Innymi słowy wymaga usunięcia wszelkich pól niezwiązanych z kluczem głównym.

 CREATE TABLE producentprodukt(id_produkt, nazwa_producent,
  cena,
  adres,
 PRIMARY KEY(id_produkt, nazwa_producent));

Pole adres zależy jedynie od producenta, ponieważ trudno sobie wyobrazić sytuacje, w której adres producenta zmieniałby się w zależności od zmian produktu. Natomiast pole cena zależy funkcyjnie od wybranego producenta i produktu, w przypadku gdy wielu producentów oferuje ten sam produkt, po różnych cenach. Powyżej przedstawiona tabela powinna być zdekomponowana na dwie tabele wprowadzając klucz obcy do pierwszej tabeli.

 CREATE TABLE producentprodukt(id_produkt, id_producent,
  cena,
 PRIMARY KEY(id_produkt, id_producent));

oraz

 CREATE TABLE producent(id_producent,
  nazwa_producent,
  adres,
 PRIMARY KEY(id_producent));