Ogólnie

 

Opracowanie zatwierdzone przez dr Kacperskiego, ponoć norma 4 jest nieużywana i nie powinno jej być w pytaniu, ale no cóż...

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.

Normalizacja

 

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.

Weźmy nieznormalizową tablicę jako przykład

NrStudentaDoradcaPok-DorKlasa1Klasa2Klasa3
1022Nowak412101-07143-01159-02
4123Kowalski216201-01211-02214-01

Pierwsza postać normalna

 

Relacja jest w pierwszej postaci normalnej, jeśli wartości atrybutów są elementarne (atomowe, niepodzielne) - są to pojedyncze wartości określonego typu, a nie zbiory wartości. Tabela reprezentująca tę relację nie zawiera powtarzających się grup informacji. Każda kolumna jest wartością skalarną (atomową), a nie macierzą lub listą czy też czymkolwiek, co posiada własną strukturę.

  • 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

NrStudentaDoradcaPok-DorNrKlasy
1022Nowak412101-07
1022Nowak412143-01
1022Nowak412159-02
4123Kowalski216201-01
4123Kowalski216211-02
4123Kowalski216214-01

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

Druga postać normalna

 

Aby przejść do drugiej postaci normalnej baza musi być w pierwszej postaci normalnej oraz kolumna nie należąca do klucza nie może być zależna od części klucza głównego ,czyli: każdy atrybut niekluczowy jest w pełni zależny funkcyjnie od całości klucza głównego.

  • Utwórz oddzielne tabele dla zestawów wartości, odnoszących się do wielu rekordów
  • Ustal powiązania tabel za pomocą klucza obcego

Studenci:
NrStudentaDoradcaPok-Dor
1022Nowak412
4123Kowalski216

Rejestracja:
NrStudentaNrKlasy
1022101-07
1022143-01
1022159-02
4123201-01
4123211-02
4123214-01

We wcześniejszej 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.

Trzecia postać normalna

 

Aby przejść do trzeciej postaci normalnej baza musi być w drugiej postaci normalnej oraz każda kolumna nie należąca do klucza nie może być zależna od innej kolumny nie należącej do klucza, czyli: każdy niekluczowy atrybut musi być bezpośrednio zależny od klucza głównego.

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

Studenci:
NrStudentaDoradca
1022Nowak
4123Kowalski

Wydział:
NazwaPokójWydział
Nowak41242
Kowalski21642

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

Czwarta postać normalna

 

Relacja jest w czwartej postaci normalnej, jeżeli zawsze wtedy kiedy zbiór atrybutów X określa wartościowo Y, to zachodzi jeden z następujących warunków:

  • Y jest puste lub zawiera się w X,
  • suma zbiorów X i Y jest pełnym zbiorem atrybutów,
  • X zawiera klucz.