Normalizacja bazy danych
1
Normalizacja bazy danych
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
Edgar Frank Codd (twórca normalizacji) początkowo wymyślił 3 postacie formalne: 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
Pierwsza postać normalna. Jej jedynym warunkiem jest aby każda składowa w każdej krotce była atomowa (nie
dawała podzielić się na mniejsze wartości). Atomowość danych jest ściśle powiązana z ich typem (nazwanym i
skończonym zbiorem 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 atomowym 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 atomowe. Jeśli jednak dopuszczamy możliwość, że będziemy potrzebowali tylko samej miejscowości, to
wtedy pole adres nie jest już atomowe i nie spełnia 1NF. Należy więc rozbić pole adres, np. na pola: ulica,
miejscowość, kod pocztowy (czyli na pola atomowe).
Normalizacja bazy danych
2
2NF
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.
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.
CREATE TABLE produkt(id_produkt,
wymiar,
nazwa_producenta,
PRIMARY KEY(id_produkt));
w powyższym przykładzie, pole nazwa_producenta nie jest zależne funkcyjnie od pola id_produkt, gdyż w tym
przykładzie, może wystąpić wielu producentów jednego produktu. Taką tabele należy rozbić na dwie tabele.
CREATE TABLE produkt(id_produkt,
wymiar
PRIMARY KEY(id_produkt));
oraz
CREATE TABLE producent(id_producent,
nazwa_producenta,
PRIMARY KEY(id_producent));
3NF
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
Normalizacja bazy danych
3
CREATE TABLE producent(id_producent,
nazwa_producent,
adres,
PRIMARY KEY(id_producent));
y
ródła i autorzy artykułu
4
y
ródła i autorzy artykułu
Normalizacja bazy danych y
ródło: http://pl.wikipedia.org/w/index.php?oldid=21201894 Autorzy: Derbeth, Fisher1st, Gdarin, Herr Kriss, Kamiseq, Lesiu79, Majkiw, Michalgarbowski,
Misza13, Prezes84, Rynraf, Turkusowy smok, 18 anonimowych edycji
Licencja
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/