Opis podstawowych czynności normalizowania bazy danych

Uwaga

Nazwa usługi Office 365 ProPlus została zmieniona na Aplikacje usługi Microsoft 365 dla przedsiębiorstw. Aby uzyskać więcej informacji na temat tej zmiany, przeczytaj ten wpis w blogu.

Oryginalny numer KB:   283878

W tym artykule wyjaśniono terminologia dotycząca normalizacyjnych baz danych dla początkujących. Podstawowa znajomość tej terminologii jest przydatna podczas dyskusji nad projektem relacyjnej bazy danych.

Opis normalizacyjny

Normalizowanie to proces porządkowania danych w bazie danych. Obejmuje to tworzenie tabel i ustanawianie relacji między tymi tabelami zgodnie z regułami zaprojektowanymi zarówno w celu ochrony danych, jak i w celu zapewnienia większej elastyczności bazy danych przez wyeliminowanie nadmiarowości i niespójnej zależności.

Nadmiarowe marnotrawstwo danych i tworzenie problemów z konserwacją. Jeśli dane istnieją w więcej niż jednym miejscu, należy je zmienić w dokładnie ten sam sposób we wszystkich lokalizacjach. Wprowadzenie zmiany adresu klienta jest znacznie łatwiejsze, jeśli te dane są przechowywane tylko w tabeli Klienci i nigdzie indziej w bazie danych.

Co to jest "niespójna współzależność"? Chociaż użytkownik ma intuicyjną edytę wyszukiwania w tabeli Klienci pod adresem określonego klienta, to poszukanie tam zarobków pracownika, który dzwoni do tego klienta, może nie mieć sensu. Zarobki pracowników są związane z pracownikiem lub od niego zależne, dlatego należy je przenieść do tabeli Pracownicy. Niespójne zależności mogą utrudniać dostęp do danych, ponieważ ścieżka znalezienia danych może być chybiona lub może być uszkodzona.

Istnieje kilka reguł normalizacyjnych baz danych. Każda reguła jest nazywana "formularzem normalnym". Jeśli pierwsza reguła jest obserwowana, oznacza to, że baza danych ma "pierwszą normalną formę". Jeśli obserwowane są pierwsze trzy reguły, baza danych jest uznawana za "trzecią postać normalną". Choć możliwe są inne poziomy normalizacji, trzeci normalny formularz jest uznawany 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 idealne zachowanie zgodności z przepisami. Na ogół normalizowanie wymaga dodatkowych tabel, a niektórym klientom jest to uciążliwe. Jeśli zdecydujesz się na naruszenie jednej z trzech pierwszych reguł normalizacyjnych, upewnij się, że aplikacja przewiduje wszelkie mogące wystąpić problemy, takie jak nadmiar danych i niespójne zależności.

Poniższe opisy zawierają przykłady.

Pierwsza normalna forma

  • Eliminowanie powtarzających się grup 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. Aby na przykład śledzić element zapasów, który może pochodzić z dwóch możliwych źródeł, rekord zapasów może zawierać pola Kod dostawcy 1 i Kod dostawcy 2.

Co się dzieje, gdy dodasz trzeciego dostawcę? Dodanie pola nie jest odpowiedzią. wymaga modyfikacji programów i tabel oraz nie obsługuje dynamicznej liczby dostawców. Zamiast tego umieść wszystkie informacje o dostawcach w osobnej tabeli o nazwie Dostawcy, a następnie połącz spis z dostawcami z kluczem numeru elementu lub z dostawcami z kluczem kodu dostawcy.

Druga normalna forma

  • Utwórz osobne tabele dla zestawów wartości, które dotyczą wielu rekordów.
  • Tabele te należy powiązać za pomocą klucza obcego.

Rekordy nie powinny być zależne od niczego innego niż klucz podstawowy tabeli (klucz złożony, jeśli jest to konieczne). Rozważ na przykład adres klienta w systemie księgowym. Adres jest potrzebny w tabeli Klienci, ale również w tabelach Zamówienia, Wysyłka, Faktury, Należności i Kolekcje. Zamiast przechowywać adres klienta jako osobny wpis w każdej z tych tabel, przechowuj go w jednym miejscu, w tabeli Klienci lub w osobnej tabeli Adresy.

Trzecia normalna forma

  • Usunięcie pól, które nie są zależne od klucza.

Wartości w rekordzie, które nie są częścią klucza tego rekordu, nie należą do tabeli. Na ogół zawsze, gdy zawartość grupy pól może dotyczyć więcej niż jednego rekordu w tabeli, warto rozważyć umieszczenie tych pól w osobnej tabeli.

Na przykład w tabeli Pochyła pracowników może zostać uwzględniona nazwa i adres uczelni kandydata. Potrzebna jest jednak pełna lista uniwersytetów dla korespondencji grupowej. Jeśli informacje o uczelniach są przechowywane w tabeli Kandydaty, nie można wyświetlić uniwersytetów, w których nie ma aktualnych kandydatów. Utwórz osobną tabelę Uniwersytety i połącz ją z tabelą Kandydatów z kluczem kodu uniwersytetu.

WYJĄTEK: zastosowanie się do trzeciej normalnej formy, mimo że była ona najlepiej praktyczna, nie zawsze jest praktyczna. Jeśli masz tabelę Klienci i chcesz wyeliminować wszystkie możliwe zależności międzypolowe, musisz utworzyć osobne tabele dla miast, kodów pocztowych, przedstawicieli sprzedaży, klas klientów i wszelkich innych czynników, które mogą być zduplikowane w wielu rekordach. Teoretycznie normalizacja jest warta zasypania. Jednak wiele małych tabel może zmniejszyć wydajność lub przekroczyć ilość otwartego pliku i pamięci.

Bardziej możliwe jest stosowanie trzeciego formularza normalnego tylko do danych, które często się zmienia. Jeśli niektóre pola zależne pozostaną, zaprojektuj aplikację, aby wymagała od użytkownika weryfikowania wszystkich pól pokrewnych po zmianie pola.

Inne formularze normalizowania

Czwarta normalna forma, nazywana także Boyce Codd Normal Form (BCNF), i piąta forma normalna, istnieją jednak rzadko pod uwagę w praktyce. Zignorowanie tych reguł może spowodować mniej niż idealne projektowanie bazy danych, ale nie powinno mieć wpływu na funkcjonalność.

Normalizowanie tabeli przykładowej

Te kroki pokazują proces normalizowania fikcyjnej tabeli uczniów.

  1. Tabela nieznormalizowana:

    Uczeń # Doradca Adv-Room Klasa1 Klasa2 Klasa3
    1022 Kowalski 412 101-07 143-01 159-02
    4123 Kowalski 216 101-07 143-01 179-04
  2. Pierwsza normalna forma: Brak powtarzających się grup

    Tabele powinny mieć tylko dwa wymiary. Ponieważ jeden uczeń ma kilka zajęć, te zajęcia powinny być wymienione w osobnej tabeli. Pola Klasy1, Klasa2 i Klasa3 w powyższych rekordach są oznaczeniami problemów z projektem.

    Arkusze kalkulacyjne często używają trzeciego wymiaru, ale tabele nie powinny. Innym sposobem rozwiązania tego problemu jest relacja jeden-do-wielu, nie umieszczaj strony "jeden" i "wielu" w tej samej tabeli. Zamiast tego należy utworzyć nową tabelę w pierwszej formie normalnej przez wyeliminowanie grupy powtarzającej się (Class#), jak pokazano poniżej:

    Uczeń # Doradca Adv-Room Zajęcia #
    1022 Kowalski 412 101-07
    1022 Kowalski 412 143-01
    1022 Kowalski 412 159-02
    4123 Kowalski 216 101-07
    4123 Kowalski 216 143-01
    4123 Kowalski 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 zależy od funkcjonalności Ucznia# (klucz podstawowy), więc ta relacja nie ma drugiej normalnej formy.

    W poniższych tabelach pokazano drugą normalną formę:

    Uczniowie:

    Uczeń # Doradca Adv-Room
    1022 Kowalski 412
    4123 Kowalski 216

    Rejestracja:

    Uczeń # Zajęcia #
    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 ostatnim przykładzie Adv-Room (numer biura doradcy) jest funkcjonalnie zależny od atrybutu Advisor. Rozwiązaniem jest przeniesienie tego atrybutu z tabeli Uczniowie do tabeli Dla nauczycieli lub wykładowców, jak pokazano poniżej:

    Uczniowie:

    Uczeń # Doradca
    1022 Kowalski
    4123 Kowalski

    Wykładowcy:

    Name (Nazwa) Pokój Dept
    Kowalski 412 42
    Kowalski 216 42