Opis podstaw normalizacji bazy danych

W tym artykule opisano terminologię normalizacji bazy danych dla początkujących. Podstawowa wiedza na temat tej terminologii jest przydatna podczas omawiania projektu relacyjnej bazy danych.

Opis normalizacji

Normalizacja to proces organizowania danych w bazie danych. Obejmuje 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 dzięki wyeliminowaniu nadmiarowości i niespójnej zależności.

Nadmiarowe dane marnuje miejsce na dysku i powoduje problemy z konserwacją. Jeśli dane, które istnieją w więcej niż jednym miejscu, muszą zostać zmienione, dane muszą zostać zmienione w dokładnie taki sam sposób we wszystkich lokalizacjach. Zmiana adresu klienta jest łatwiej zaimplementowana, jeśli te dane są przechowywane tylko w tabeli Customers i nigdzie indziej w bazie danych.

Co to jest "niespójna zależność"? Chociaż użytkownikowi intuicyjnie przychodzi do głowy szukać w tabeli Customers adresu konkretnego klienta, może nie mieć sensu szukać tam wynagrodzenia pracownika odwiedzającego tego klienta. Pensja pracownika jest związana z pracownikiem lub uzależniona od niego, a tym samym powinna zostać przeniesiona do tabeli Pracownicy. Niespójne zależności mogą utrudnić dostęp do danych, ponieważ ścieżka do znalezienia danych może być brakująca lub uszkodzona.

Istnieje kilka reguł normalizacji bazy danych. Każda reguła jest nazywana "formą normalną". Jeśli pierwsza reguła zostanie zaobserwowana, baza danych jest uważana za "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 forma normalna jest uważana za najwyższy poziom niezbędny dla większości aplikacji.

Podobnie jak w przypadku wielu formalnych zasad i specyfikacji, rzeczywiste scenariusze nie zawsze pozwalają na idealną zgodność. Ogólnie rzecz biorąc, normalizacja wymaga dodatkowych tabel, a niektórzy klienci uważają to kłopotliwe. Jeśli zdecydujesz się naruszyć jedną z trzech pierwszych reguł normalizacji, upewnij się, że aplikacja przewiduje wszelkie problemy, które mogą wystąpić, takie jak nadmiarowe dane i niespójne zależności.

Poniższe opisy zawierają przykłady.

Pierwsza postać normalna

• Eliminowanie powtarzających się grup w poszczególnych tabelach.
• Utwórz oddzielną tabelę dla każdego zestawu powiązanych danych.
• Zidentyfikuj każdy zestaw powiązanych danych przy użyciu klucza podstawowego.

Nie używaj wielu pól w jednej tabeli do przechowywania podobnych danych. Na przykład aby śledzić element spisu, który może pochodzić z dwóch możliwych źródeł, rekord spisu może zawierać pola dla kodu dostawcy 1 i kodu dostawcy 2.

Co się stanie po dodaniu trzeciego dostawcy? Dodawanie pola nie jest odpowiedzią; wymaga modyfikacji programów i tabel i nie jest bezproblemowo dostosowany do dynamicznej liczby dostawców. Zamiast tego umieść wszystkie informacje o dostawcach w oddzielnej tabeli o nazwie Dostawcy, a następnie połącz spis z dostawcami za pomocą klucza numeru towaru lub dostawców do spisu za pomocą klucza kodu dostawcy.

Druga postać normalna

• Utwórz oddzielne tabele dla zestawów wartości, które mają zastosowanie do wielu rekordów.
• Powiąż te tabele z kluczem obcym.

Rekordy nie powinny zależeć od niczego innego niż klucz podstawowy tabeli (w razie potrzeby klucz złożony). Rozważmy na przykład adres klienta w systemie księgowości. Adres jest potrzebny w tabeli Klienci, ale także w tabelach Zamówienia, Wysyłka, Faktury, Należności i Kolekcje. Zamiast przechowywać adres klienta jako oddzielny wpis w każdej z tych tabel, zapisz go w jednym miejscu w tabeli Customers lub w oddzielnej tabeli Adresy.

Trzecia postać normalna

• Wyeliminuj 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 rzecz biorąc, zawsze, gdy zawartość grupy pól może być stosowana do więcej niż jednego rekordu w tabeli, rozważ umieszczenie tych pól w oddzielnej tabeli.

Na przykład w tabeli Rekrutacji pracowników może zostać uwzględniona nazwa i adres uczelni kandydata. Ale potrzebujesz pełnej listy uniwersytetów do wysyłki grupowej. Jeśli informacje o uniwersytecie są przechowywane w tabeli Kandydaci, nie ma możliwości wyświetlania listy uniwersytetów bez obecnych kandydatów. Utwórz oddzielną tabelę Uniwersytety i połącz ją z tabelą Kandydaci przy użyciu klucza kodu uniwersytetu.

WYJĄTEK: Przestrzeganie trzeciej normalnej formy, choć teoretycznie pożądane, nie zawsze jest praktyczne. Jeśli masz tabelę Customers i chcesz wyeliminować wszystkie możliwe zależności między polami, musisz utworzyć oddzielne 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 realizacji. Jednak wiele małych tabel może obniżyć wydajność lub przekroczyć otwarte pojemności plików i pamięci.

Bardziej możliwe może być zastosowanie trzeciego normalnego formularza tylko do danych, które często się zmieniają. Jeśli niektóre pola zależne pozostaną, zaprojektuj aplikację, aby wymagać od użytkownika zweryfikowania wszystkich powiązanych pól po zmianie.

Inne formy normalizacji

Czwarta forma normalna, nazywana również Boyce-Codd Formą Normalną (BCNF) i piątą formą normalną istnieją, ale rzadko są brane pod uwagę w praktycznym projektowaniu. Lekceważenie tych reguł może spowodować, że projekt bazy danych jest mniejszy niż doskonały, ale nie powinien mieć wpływu na funkcjonalność.

Normalizacja przykładowej tabeli

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

1. Tabela nienormalizowana:

   Student#	Opiekun	Adv-Room	Klasa1	Klasa 2	Klasa3
   1022	Jones	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 uczeń ma kilka klas, te zajęcia powinny być wymienione w oddzielnej tabeli. Pola Class1, Class2 i Class3 w powyższych rekordach wskazują na problemy projektowe.

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

   Student#	Opiekun	Adv-Room	Klasa#
   1022	Jones	412	101-07
   1022	Jones	412	143-01
   1022	Jones	412	159-02
   4123	Borkowski	216	101-07
   4123	Borkowski	216	143-01
   4123	Borkowski	216	179-04

3. Druga normalna forma: Eliminowanie 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 numeru studenta (klucz podstawowy), więc ta relacja nie znajduje się w drugiej postaci normalnej.

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

   Studenci

   Student#	Opiekun	Adv-Room
   1022	Jones	412
   4123	Borkowski	216

   Rejestracja:

   Student#	Klasa#
   1022	101-07
   1022	143-01
   1022	159-02
   4123	101-07
   4123	143-01
   4123	179-04

4. Trzecia normalna forma: Eliminowanie danych, które nie są zależne 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 Students do tabeli Wydział, jak pokazano poniżej:

   Studenci

   Student#	Opiekun
   1022	Jones
   4123	Borkowski

   Wydział:

   Nazwa	Pokój	Dział
   Jones	412	42
   Borkowski	216	42