Normalizacja Bazy Danych
Opis normalizacji
Normalizacja to proces organizacji danych w bazie danych. Polega on na tworzeniu tabel i ustanawianiu pomiędzy nimi powiązań według reguł obowiązujących zarówno przy ochronie danych, jak i uelastycznianiu bazy danych przez eliminowanie powtarzających się i niespójnych zależności.
Powtarzające się dane niepotrzebnie zajmują miejsce na dysku i są przyczyną powstawania problemów z obsługą. Jeśli konieczna jest zmiana danych istniejących w więcej niż jednej lokalizacji, musi być ona przeprowadzona we wszystkich lokalizacjach w ten sam sposób. Implementacja zmiany adresu klienta jest o wiele łatwiejsza, jeśli dane są przechowywane tylko w tabeli Klienci i w żadnym innym miejscu bazy danych.
Co to jest „niespójna zależność”? O ile przeglądanie tabeli Klienci w poszukiwaniu adresu konkretnego klienta można nazwać zachowaniem intuicyjnym, to poszukiwanie w tej tabeli pensji pracownika obsługującego tego klienta nie ma żadnego sensu. Pensja pracownika jest związana z pracownikiem lub zależy od pracownika i dlatego powinna być przeniesiona do tabeli Pracownicy. Niespójne zależności mogą utrudniać dostęp do danych, ponieważ ścieżka ich odnajdywania może zostać utracona lub uszkodzona.
Istnieje kilka reguł normalizacji baz danych. Każda reguła nosi nazwę „postać normalna”. Jeśli przestrzegana jest pierwsza reguła, o postaci bazy danych mówi się, że jest „pierwszą postacią normalną”. Jeśli przestrzegane są pierwsze trzy reguły, postać bazy danych przyjmuje się za „trzecią postać normalną”. Chociaż możliwe są inne poziomy normalizacji, trzecia postać normalna uważana jest za najwyższy poziom wymagany przez większość aplikacji.
Jak to bywa z wieloma formalnymi regułami i specyfikacjami, rzeczywistość nie zawsze pozwala na ich dokładne odwzorowanie. Ogólnie rzecz biorąc, normalizacja wymaga dodatkowych tabel i dla niektórych osób jest to uciążliwe. Przed podjęciem decyzji o złamaniu jednej z pierwszych trzech reguł normalizacji należy upewnić się, że projekt aplikacji przewiduje występowanie problemów, takich jak powtarzające się dane lub niespójne zależności.
Pierwsza postać normalna
W poszczególnych tabelach wyeliminuj powtarzające się grupy.
Dla każdego zestawu danych pokrewnych utwórz oddzielną tabelę.
Dla każdego zestawu danych pokrewnych określ klucz podstawowy.
Do przechowywania podobnych danych w jednej tabeli nie należy używać wielu pól. Na przykład rekord służący do śledzenia pozycji magazynowej, która może pochodzić z dwóch różnych źródeł, może zawierać pola Kod sprzedawcy 1 oraz Kod sprzedawcy 2.
Co się zdarzy po dodaniu trzeciego sprzedawcy? Dodanie pola nie jest rozwiązaniem. Wymaga to modyfikacji programu i tabel oraz nie umożliwia obsługi zmieniającej się dynamicznie liczby sprzedawców. Zamiast tego należy umieścić wszystkie informacje o sprzedawcach w oddzielnej tabeli o nazwie Sprzedawcy, a następnie połączyć magazyn ze sprzedawcami za pomocą klucza z numerem pozycji, albo sprzedawców z magazynem za pomocą klucza z kodem sprzedawcy.
Druga postać normalna
Utwórz oddzielne tabele dla zestawów wartości, odnoszących się do wielu rekordów.
Ustal powiązania tabel za pomocą klucza obcego.
Rekordy nie powinny zależeć od niczego innego tylko od klucza podstawowego tabeli (w razie potrzeby może to być klucz złożony). Rozważmy na przykład adres klienta w systemie księgowym. Obecność adresu konieczna jest w tabeli Klienci, ale również w tabelach Zamówienia, Wysyłka, Faktury, Należności i Inkaso. Zamiast przechowywać adres w postaci wpisu w każdej tabeli, przechowuje się go w jednym miejscu: albo w tabeli Klienci, albo w oddzielnej tabeli Adresy.
Trzecia postać normalna
Wyeliminuj pola, które nie zależą od klucza.
Wartości rekordu, które nie są częścią jego klucza, nie należą do tabeli. Zazwyczaj, jeśli zawartość grupy pól odnosi się do więcej niż jednego rekordu tabeli, należy rozważyć umieszczenie tych pól w oddzielnej tabeli.
Na przykład w tabeli Rekrutacja pracowników może znajdować się nazwa i adres uczelni, którą ukończył kandydat. Do korespondencji seryjnej potrzebna jest jednak kompletna lista uczelni. Jeśli informacje o uczelniach przechowywane są w tabeli Kandydaci, nie ma możliwości wyświetlenia listy uczelni bez aktualnych kandydatów. Utwórz oddzielną tabelę Uczelnie i połącz ją z tabelą Kandydaci za pomocą klucza z kodem uczelni.
WYJĄTEK: Stosowanie reguł trzeciej postaci normalnej, chociaż teoretycznie wskazane, nie zawsze jest praktyczne. Chcąc wyeliminować wszystkie możliwe wewnętrzne zależności pomiędzy polami tabeli Klienci, należałoby utworzyć oddzielne tabele dla miast, kodów pocztowych, przedstawicieli handlowych, klas klienta i innych czynników, które mogą być zduplikowane w wielu rekordach. Normalizacja oznacza teoretycznie poprawę wydajności. Jednak wiele mniejszych tabel może spowodować spadek wydajności lub brak możliwości otwarcia pliku i przekroczenie pojemności pamięci.
Bardziej realne może okazać się zastosowanie trzeciej postaci normalnej tylko do często zmienianych danych. Pozostawiając niektóre pola zależne, zmień projekt aplikacji tak, aby po zmianie dowolnego pola wymagała od użytkownika sprawdzenia wszystkich pól pokrewnych.
Inne postacie normalizacji
Istnieje czwarta postać normalna, zwana również postacią normalną Boyce'a-Codda (BCNF) oraz piąta postać normalna, ale są one rzadko wykorzystywane w praktyce. Zlekceważenie tych reguł może skutkować mniej doskonałym projektem bazy danych, ale nie powinno ono wpływać na funkcjonalność.
Normalizowanie tabeli przykładowej
W poniższych krokach przedstawiono proces normalizacji fikcyjnej tabeli studentów.
Tabela nieznormalizowana:
NrStudenta |
Doradca |
Pok-Dor |
Klasa1 |
Klasa2 |
Klasa3 |
1022 |
Nowak |
412 |
101-07 |
143-01 |
159-02 |
4123 |
Kowalski |
216 |
201-01 |
211-02 |
214-01 |
Pierwsza postać normalna: brak powtarzających się grup
Tabele powinny mieć tylko dwa wymiary. Ponieważ jeden student ma kilka klas, klasy powinny znajdować się w oddzielnej tabeli. Występowanie pól Klasa1, Klasa2 i Klasa3 w powyższych rekordach jest oznaką problemów podczas projektowania.
Arkusze kalkulacyjne często wykorzystują trzeci wymiar, ale tabele nie powinny. Innym podejściem do problemu jest relacja jeden-do-wielu, w której nie należy strony jeden i strony wielu umieszczać w tej samej tabeli. Zamiast tego, należy utworzyć inną tabelę w pierwszej postaci normalnej, eliminując powtarzające się grupy (NrKlasy), tak jak to przedstawiono poniżej:
NrStudenta |
Doradca |
Pok-Dor |
NrKlasy |
1022 |
Nowak |
412 |
101-07 |
1022 |
Nowak |
412 |
143-01 |
1022 |
Nowak |
412 |
159-02 |
4123 |
Kowalski |
216 |
201-01 |
4123 |
Kowalski |
216 |
211-02 |
4123 |
Kowalski |
216 |
214-01 |
Druga postać normalna: eliminowanie powtarzających się danych
W powyższej tabeli dla każdego pola NrStudenta istnieje wiele wartości w polach NrKlasy. Pole NrKlasy nie jest czynnościowo zależne od pola NrStudenta (klucz podstawowy), dlatego ta relacja nie znajduje się w drugiej postaci normalnej.
Drugą postać normalną przedstawiono na podstawie następujących dwóch tabel:
Studenci:
NrStudenta |
Doradca |
Pok-Dor |
1022 |
Nowak |
412 |
4123 |
Kowalski |
216 |
Rejestracja:
NrStudenta |
NrKlasy |
1022 |
101-07 |
1022 |
143-01 |
1022 |
159-02 |
4123 |
201-01 |
4123 |
211-02 |
4123 |
214-01 |
Trzecia postać normalna: eliminowanie danych, które nie zależą od klucza
W ostatnim przykładzie pole Pok-Dor (numer pokoju doradcy) jest czynnościowo zależne od atrybutu Doradca. Rozwiązaniem jest przeniesienie tego atrybutu z tabeli Studenci do tabeli Wydział, tak jak to przedstawiono poniżej:
Studenci
NrStudenta |
Doradca |
1022 |
Nowak |
4123 |
Kowalski |
Wydział:
Nazwa |
Pokój |
Wydział |
Nowak |
412 |
42 |
Kowalski |
216 |
42 |
Patrycja Łukaszek
Kl. IIa1
1