Opis podstaw normalizacji bazy danych

  • Artykuł
  • Dotyczy:
    Access 2021, Access 2019, Access 2016, Access 2013

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 ona tworzenie tabel i ustanawianie relacji między tymi tabelami zgodnie z regułami zaprojektowanymi zarówno w celu ochrony danych, jak i zwiększenia elastyczności bazy danych poprzez wyeliminowanie nadmiarowości i niespójnej 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 łatwiejsza do zaimplementowania, jeśli te dane są przechowywane tylko w tabeli Customers i nigdzie indziej w bazie danych.

Co to jest „niespójna zależność”? Chociaż intuicyjne jest, aby użytkownik poszukał w tabeli Customers adresu określonego klienta, może nie mieć sensu szukać tam wynagrodzenia pracownika, który wywołuje 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.

Podobnie jak w przypadku wielu formalnych reguł i specyfikacji, rzeczywiste scenariusze nie zawsze pozwalają na 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 używaj 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? Dodawanie pola nie jest odpowiedzią; Wymaga on modyfikacji programu i tabeli i nie uwzględnia w sposób płynny dynamicznej liczby 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 (klucz złożony, jeśli to konieczne). 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

  • Eliminuj pola, które nie zależą od klucza.

Wartości w rekordzie, które nie są częścią klucza tego rekordu, nie należą do 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: Przestrzeganie trzeciej normalnej formy, choć teoretycznie pożądanej, 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. Teoretycznie warto dążyć do normalizacji. 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 normalna forma, nazywana również Boyce-Codd formą normalną (BCNF), i piąta normalna forma istnieją, ale rzadko są brane pod uwagę w praktycznym projekcie. Pominięcie tych reguł może spowodować mniej niż doskonały projekt bazy danych, ale nie powinno mieć wpływu na funkcjonalność.

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.

    Arkusze kalkulacyjne często używają trzeciego wymiaru, ale tabele nie powinny. Innym sposobem przyjrzenia się temu problemowi jest relacja jeden do wielu, nie umieszczaj jednej strony i wielu stron w tej samej tabeli. Zamiast tego utwórz inną tabelę w pierwszej normalnej formie, eliminując powtarzaną grupę (Class#), jak pokazano w poniższym przykładzie:

    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

    Zwróć uwagę na wiele wartości Class# dla każdej wartości Student# w powyższej tabeli. Klasa# nie jest funkcjonalnie zależna od studenta# (klucz podstawowy), więc ta relacja nie jest w drugiej normalnej formie.

    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