Przeczytaj
Do analizy trzeciej postaci normalnej niezbędna jest znajomość dwóch pierwszych postaci – przypomnijmy krótko najważniejsze z tych zasad.
Pierwsza postać normalna:
jedna tabela opisuje jeden obiekt,
wartości atrybutów są atomowe,
tabela nie zawiera powtarzających się informacji,
znaczenie kolumn nie zależy od ich kolejności.
Druga postać normalna:
baza jest w pierwszej postaci normalnej,
każda kolumna nienależąca do klucza potencjalnego jest zależna funkcyjnie od jego fragmentu (może być zależna od całości).
Trzecia postać normalna
Trzecia postać normalna ponownie wprowadza pojedynczą nową regułę, jednocześnie wymagając, aby baza spełniała warunki poprzedniej postaci normalnej.
Tabela jest w trzeciej postaci normalnej wtedy i tylko wtedy, gdy:
jest w drugiej postaci normalnej,
każdy atrybut nienależący do klucza potencjalnegoklucza potencjalnego nie zależy funkcyjnie od innych atrybutów nienależących do klucza potencjalnego.
Dodatkowa zasada jest bardzo zbliżona do tej wprowadzonej w drugiej postaci normalnej. Czasem jest nazywana zakazem przechodniości. Nie pozwala ona, aby jakiś atrybut dał się wywnioskować z innego atrybutu.
Nazwa wynika z tego, że jeśli mamy klucz potencjalny K oraz atrybuty A i B, to według tej reguły nie może istnieć zależność K → A → B. Czyli dowolny atrybut niekluczowy może zależeć tylko od całości klucza potencjalnego, nigdy zaś od innego atrybutu czy fragmentu.
Zalety i wady
Celem trzeciej postaci normalnej ponownie jest zmniejszenie redundancji danych, a przez to zwiększenie jej integralnościintegralności. Jednak tak samo jak dzieje się to w przypadku poprzedniej postaci, osłabia ona prędkość działania bazy. Wydobycie informacji często wymaga korzystania z zapytań i widoków, które obliczają wynik przy każdym wywołaniu. Pomimo tego jest ona stosowana w dużych bazach danych – głównie ze względu na bezpieczeństwo spójności oraz łatwość tworzenia i planowania schematów baz danych w tej formie.
Czy dana tabela jest w trzeciej postaci normalnej?
Zwróć uwagę na poniższy przykład tabeli, która łamie reguły trzeciej postaci normalnej, ale jest w drugiej postaci normalnej. Dodatkowo wiemy o tej bazie danych, że nie mogą się w niej znajdować dwie osoby o tym samym imieniu i nazwisku oraz że pole Imie oraz pole Nazwisko są kluczem potencjalnym.
Imie | Nazwisko | Data_urodzenia | Znak_zodiaku |
|---|---|---|---|
Jakub | Górski | 28.09.1992 | Waga |
Sylwia | Nowak | 04.07.1989 | Rak |
Joanna | Tomaszewska | 06.01.1983 | Koziorożec |
Adrianna | Pawlak | 23.04.1999 | Byk |
Janusz | Bąk | 19.11.1985 | Skorpion |
Wiemy już, że mamy tu do czynienia z drugą postacią normalną, więc należy się zastanowić, czy pozostałe kolumny: Znak_zodiaku i Data_urodzenia zależą funkcyjnie od siebie.
Znak zodiaku wynika bezpośrednio z daty urodzenia danej osoby, niezależnie od imienia i nazwiska. Z tego powodu łamie regułę, która mówi, że kolumny niebędące częścią klucza potencjalnego nie mogą od niego zależeć funkcyjnie.
Można tutaj zauważyć przechodnią zależność funkcyjną:
Imię, Nazwisko → Data urodzenia → Znak zodiaku.
Sprowadzenie do trzeciej postaci normalnej
Polega na stworzeniu dodatkowej relacji, w której zostanie przechowana część danych z modyfikowanej relacji.
Znamy już zależność funkcyjną Data_urodzenia → Znak_zodiaku, która sprawia, że tabela nie jest w trzeciej postaci normalnej. Aby pozbyć się tej zależności, można utworzyć tabelę Znaki zodiaku, która będzie zawierała pary: Data_urodzenia – Znak_zodiaku.
W ten sposób pozbędziemy się kolumny Znak_zodiaku z oryginalnej tabeli i doprowadzimy ją do trzeciej postaci normalnej.
Data_urodzenia | Znak_zodiaku |
|---|---|
28.09.1992 | Waga |
04.07.1989 | Rak |
06.01.1983 | Koziorożec |
23.04.1999 | Byk |
19.11.1985 | Skorpion |
W nowej tabeli kluczem potencjalnym będzie teraz Data urodzenia. Dzięki temu, choć nadal będzie tam zachodzić ta sama zależność: Data_urodzenia → Znak_zodiaku, nowa tabela także będzie spełniać warunki drugiej postaci normalnej.
Oryginalna tabela po modyfikacji wygląda następująco:
Imie | Nazwisko | Data_urodzenia |
|---|---|---|
Jakub | Górski | 28.09.1992 |
Sylwia | Nowak | 04.07.1989 |
Joanna | Tomaszewska | 06.01.1983 |
Adrianna | Pawlak | 23.04.1999 |
Janusz | Bąk | 19.11.1985 |
Tego typu rozwiązanie, czyli nowa tabela z lewą stroną zależności jako kluczem potencjalnym, jest uniwersalne. Ma jednak wadę w postaci szansy na generowanie powtórzeń wartości (ale nie powtórzeń informacji – inaczej tabela nie byłaby w postaci normalnej!).
Czasem daje się znaleźć lepsze rozwiązanie. W tym przypadku przechowywane są znaki zodiaku dla każdej daty, co grozi przechowywaniem potencjalnie tysięcy wierszy.
Zamiast tego można utworzyć tabelę zawierającą: pole Poczatek, pole Koniec oraz pole Znak_zodiaku, która zawierałaby przedziały dni i miesięcy, jakim odpowiada dany znak zodiaku. Takie rozwiązanie gwarantuje, że ograniczymy się maksymalnie do 12 rekordów w tej tabeli.
Słownik
inaczej spójność; brak sprzecznych informacji w bazie danych
inaczej kandydujący; minimalny zbiór atrybutów, których zestaw wartości jest unikalny dla każdego rekordu