temat: Normalizacja baz danych

Normalizacja baz danych
Definicja 11
Normalizacja to proces organizowania danych w bazie danych. Obejmuje to tworzenie tabel
i ustanawianie relacji między tymi tabelami zgodnie z regułami zaprojektowanymi w celu zarówno
ochrony danych, jak i zapewnienia większej elastyczności bazy danych przez wyeliminowanie
nadmiarowości i niespójnych zależności.
Definicja 2
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.
Nadmiarowe dane zajmują dodatkowe miejsce na dysku i przyczyniają się do problemów
z konserwacją. Gdy trzeba zmienić dane istniejące w więcej niż jednym miejscu, dane we wszystkich
tych lokalizacjach należy zmienić w dokładnie taki sam sposób. Zmiana adresu klienta jest znacznie
łatwiejsza, gdy te dane są przechowywane tylko w tabeli Klienci i nigdzie indziej w bazie danych.
Co to jest „niespójna zależność”? Użytkownik intuicyjnie zagląda do tabeli Klienci, aby sprawdzić
adres określonego klienta, ale nie zajrzy tam, aby sprawdzić wynagrodzenie pracownika dzwoniącego
do tego klienta. Wynagrodzenie pracownika jest powiązane z pracownikiem (zależne od niego), więc
powinno zostać przeniesione do tabeli Pracownicy. Niespójne zależności utrudniają dostęp do danych,
ponieważ może brakować ścieżki do odnalezienia danych.
Istnieje kilka reguł normalizacji bazy danych. Każda reguła jest nazywana „postacią normalną”. Jeśli
pierwsza reguła jest przestrzegana, o bazie danych mówi się, że jest w pierwszej postaci normalnej.
Jeśli pierwsze trzy reguły są przestrzegane, o bazie danych mówi się, że jest w trzeciej postaci
normalnej. Chociaż są możliwe inne poziomy normalizacji, trzecia postać normalna jest uważana za
najwyższy poziom niezbędny dla większości aplikacji.
Tak jak w przypadku wielu formalnych reguł i specyfikacji, rzeczywiste scenariusze nie zawsze
umożliwiają doskonałą zgodność. Normalizacja wymaga zwykle dodatkowych tabel i niektórzy
klienci mogą uważać to za niewygodne. W razie decyzji o naruszeniu jednej z trzech pierwszych reguł
normalizacji należy upewnić się, że aplikacja przewiduje wszelkie ewentualne problemy, na przykład
nadmiarowe dane i niespójne zależności.
Cel normalizacji:
1. Uniknięcie redundancji (tj. powtarzania się pól z identycznymi wartościami w różnych
tabelach).
2. Wyeliminowanie niewygodnych relacji wieloznacznych.
3. Uniknięcie anomalii przy aktualizacji: modyfikacji, wstawianiu i usuwaniu.
4. Unikniecie niespójności.
1
http://support.microsoft.com/kb/283878/pl
1
Koszt:
Mnożenie liczby tabel – wydłużenie czasu dostępu do danych.
Postacie Normalne
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.
Pierwsza postać normalna 1NF
•
•
•
Wyeliminuj powtarzające się grupy w poszczególnych tabelach.
Utwórz osobną tabelę dla każdego zestawu powiązanych danych.
Zidentyfikuj każdy zestaw powiązanych danych za pomocą klucza podstawowego.
Nie należy używać wielu pól w jednej tabeli do przechowywania podobnych danych. Na przykład aby
można było śledzić pozycję magazynową mogącą pochodzić z dwóch źródeł, rekord magazynu może
zawierać pola na kod pierwszego dostawcy i na kod drugiego dostawcy.
Co się stanie po dodaniu trzeciego dostawcy? Dodanie pola nie jest rozwiązaniem. Wymagałoby
zmodyfikowania programu i tabeli, a ponadto nie jest sprawną metodą dodawania kolejnych
dostawców. Zamiast tego najlepiej jest umieścić wszystkie informacje o dostawcach w osobnej tabeli
o nazwie Dostawcy, a następnie połączyć magazyn z dostawcami za pomocą klucza numeru pozycji
albo połączyć dostawców z magazynem za pomocą klucza kodu dostawcy.
Druga postać normalna 2NF
•
•
Utwórz osobne tabele dla zestawów wartości dotyczących wielu rekordów.
Powiąż te tabele za pomocą klucza obcego.
Rekordy nie powinny zależeć od niczego innego niż klucz podstawowy tabeli (jeśli jest to niezbędne,
klucza złożonego). Rozważmy na przykład adres klienta w systemie księgowym. Adres jest potrzebny
w tabeli Klienci, ale także w tabelach Zamówienia, Wysyłka, Faktury, Rozrachunki z odbiorcami i
Pobory należności. Zamiast przechowywać adres klienta w osobnym wpisie w każdej z tych tabel,
należy przechowywać go w jednym miejscu, w tabeli Klienci lub w osobnej tabeli Adresy.
Trzecia postać normalna 3NF
•
Wyeliminuj pola, które nie zależą od klucza.
Wartości w rekordzie, które nie stanowią części klucza rekordu, nie powinny znajdować się w danej
tabeli. Ogólnie w każdym przypadku, w którym zawartość grupy pól może dotyczyć więcej niż
jednego rekordu w tabeli, należy rozważyć umieszczenie tych pól w osobnej tabeli.
Na przykład w tabeli Rekrutacja pracowników można uwzględnić nazwę i adres uniwersytetu
kandydata. Ale do wysyłek grupowych potrzebna jest pełna lista uniwersytetów. Jeśli informacje o
uniwersytetach są przechowywane w tabeli Kandydaci, nie można utworzyć listy uniwersytetów bez
bieżących kandydatów. Należy utworzyć osobną tabelę Uniwersytety i połączyć ją z tabelą Kandydaci
za pomocą klucza kodu uniwersytetu.
WYJĄTEK: stosowanie się do trzeciej postaci normalnej, chociaż teoretycznie pożądane, nie zawsze
jest praktyczne. Jeśli jest używana tabela Klienci i trzeba wyeliminować wszelkie możliwe zależności
między polami, należy utworzyć osobne tabele dla miast, kodów pocztowych, przedstawicieli
2
handlowych, klas klientów oraz wszelkich innych czynników, które mogą zostać zduplikowane w
wielu rekordach. W teorii warto stosować normalizację. Jednak stosowanie wielu małych tabel może
pogorszyć wydajność lub spowodować przekroczenie dozwolonej liczby otwartych plików lub
pojemności pamięci.
Niekiedy lepszym rozwiązaniem jest stosowanie trzeciej postaci normalnej tylko do danych często
zmienianych. Jeśli pozostają jakieś pola zależne, projekt aplikacji powinien wymagać od użytkownika
zweryfikowania wszystkich powiązanych pól po zmianie jednego z nich.
Inne postacie normalizacji
Czwarta postać normalna, nazywana też postacią BCNF (Boyce Codd Normal Form), i piąta postać
normalna istnieją, ale rzadko są brane pod uwagę w rzeczywistych projektach. Zignorowanie tych
reguł może skutkować projektem niedoskonałym, ale nie powinno wpływać na działanie.
2
Normalizowanie przykładowej tabeli
W ramach tych czynności przedstawiono proces normalizowania fikcyjnej tabeli studentów.
Tabela nieznormalizowana:
Nr studenta Opiekun Pokój opiekuna Zajęcia 1 Zajęcia 2 Zajęcia 3
1022
Czarnecki 412
101-07 143-01 159-02
4123
Borkowski 216
201-01 211-02 214-01
1. Pierwsza postać normalna: brak powtarzających się grup
2
http://www.zie.pg.gda.pl/md/bazy_danych/przyklady_normalizacja.pdf
3
Tabele powinny mieć tylko dwa wymiary. Ponieważ jeden student może mieć kilka rodzajów
zajęć, zajęcia powinny być wymienione w osobnej tabeli. Pola Zajęcia 1, Zajęcia 2 i Zajęcia 3
w powyższych rekordach sygnalizują problemy z projektem.
W arkuszach kalkulacyjnych często jest używany trzeci wymiar, ale w tabelach nie powinno to
mieć miejsca. Inną metodą przestawienia tego problemu jest relacja jeden-do-wielu: nie należy
umieszczać strony „jeden” i strony „wielu” tej relacji w tej samej tabeli. Zamiast tego należy
utworzyć inną tabelę w pierwszej postaci normalnej przez wyeliminowanie powtarzającej się
grupy (Zajęcia nr), tak jak to pokazano poniżej:
Nr studenta Opiekun Pokój opiekuna Nr zajęć
1022
Czarnecki 412
101-07
1022
Czarnecki 412
143-01
1022
Czarnecki 412
159-02
4123
Borkowski 216
201-01
4123
Borkowski 216
211-02
4123
Borkowski 216
214-01
2. Druga postać normalna: wyeliminowanie danych nadmiarowych
W powyższej tabeli dla każdej wartości Nr studenta występuje wiele wartości Nr zajęć.
Wartości Nr zajęć nie są funkcjonalnie zależne od klucza podstawowego Nr studenta, więc ta
relacja nie jest w drugiej formie normalnej.
W poniższych dwóch tabelach pokazano drugą formę normalną:
Studenci:
Nr
studenta
Rejestracja:
Opiekun
Pokój
opiekuna
1022
Czarnecki 412
4123
Borkowski 216
Nr studenta Nr zajęć
1022
101-07
1022
143-01
1022
159-02
4123
201-01
4123
211-02
4123
214-01
3. Trzecia postać normalna: wyeliminowanie danych, które nie zależą od klucza
W ostatniej tabeli wartości Pokój opiekuna są funkcjonalnie zależne od atrybutu Opiekun.
4
Rozwiązaniem jest przeniesienie tego atrybutu z tabeli Studenci do tabeli Wykładowcy, jak
pokazano poniżej:
Studenci:
Nr studenta Opiekun
1022
Czarnecki
4123
Borkowski
Wykładowcy:
Nazwisko Pokój Wydział
Czarnecki 412 42
Borkowski 216 42
Przykłady zastosowań normalizacji:
Poniższe przykłady pochodzą z materiałów ze strony http://www.neurosoft.edu.pl/jbartman/BDW3.pdf
5
6
7