Normalizacja baz danych Definicja 1 1 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 Opiekun 1022 Czarnecki 412 4123 Borkowski 216 Pokój opiekuna Rejestracja: 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/bd- W3.pdf 5
6
7