Opis podstaw normalizacji bazy danych

Oryginalny numer KB: 283878

W tym artykule wyjaśniono terminologię dotyczącą normalizacji bazy danych dla początkujących. Podczas omawiania projektu relacyjnej bazy danych przydaje się podstawowa znajomość tej terminologii.

Opis normalizacji

Normalizacja to proces organizowania danych w bazie danych. Obejmuje to tworzenie tabel i ustanawianie relacji między tymi tabelami zgodnie z regułami opracowanymi 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.

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 lub może być ona uszkodzona.

Istnieje kilka reguł normalizacji bazy danych. Każda reguła jest nazywana "formularzem normalnym". Jeśli zostanie zaobserwowana pierwsza reguła, mówi się, że baza danych ma "pierwszą normalną formę". Jeśli zostaną zaobserwowane pierwsze trzy reguły, baza danych jest uważana za "trzecią normalną formę". Chociaż możliwe są inne poziomy normalizacji, trzecia normalna forma 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.

Do poniższych opisów dołączono przykłady.

Pierwsza postać normalna

  • 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

  • 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

  • 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 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.

Normalizowanie przykładowej tabeli

W ramach tych czynności zaprezentowano proces normalizowania fikcyjnej tabeli studentów.

  1. 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 101-07 143-01 179-04
  2. Pierwsza normalna forma: brak powtarzających się grup

    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 101-07
    4123 Borkowski 216 143-01
    4123 Borkowski 216 179-04
  3. Druga normalna forma: wyeliminowanie nadmiarowych danych

    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 Pokój opiekuna
    1022 Czarnecki 412
    4123 Borkowski 216

    Rejestracja:

    Nr studenta Nr zajęć
    1022 101-07
    1022 143-01
    1022 159-02
    4123 101-07
    4123 143-01
    4123 179-04
  4. Trzecia normalna forma: wyeliminowanie danych zależnych od klucza

    W ostatniej tabeli wartości Pokój opiekuna są funkcjonalnie zależne od atrybutu Opiekun. 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:

    Name (Nazwa) Pokój Wydzia³
    Czarnecki 412 42
    Borkowski 216 42