Trzecia postać normalna - Third normal form

Trzecia forma normalna ( 3NF ) to podejście do projektowania schematów baz danych dla relacyjnych baz danych, które wykorzystuje zasady normalizacji w celu zmniejszenia duplikacji danych, uniknięcia anomalii danych , zapewnienia integralności referencyjnej i uproszczenia zarządzania danymi. Został on zdefiniowany w 1971 roku przez Edgar F. Codd , komputerem naukowca angielskiego który wynalazł model relacyjny do bazy danych zarządzania.

Relacja bazy danych (na przykład tabeli bazy danych ) mówi się spotkać trzecie normalne standardy formularz, jeśli wszystkie atrybuty (np kolumn bazy danych ) są funkcjonalnie zależny na wyłącznie na klucz podstawowy . Codd zdefiniował to jako relację w drugiej postaci normalnej, w której wszystkie atrybuty inne niż pierwsze zależą tylko od kluczy kandydujących i nie mają przechodniej zależności od innego klucza.

Hipotetycznym przykładem niespełnienia trzeciej normalnej formy byłaby szpitalna baza danych zawierająca tabelę pacjentów, która zawierała kolumnę z numerem telefonu ich lekarza. Numer telefonu jest zależny od lekarza, a nie od pacjenta, dlatego lepiej by był przechowywany w tabeli lekarzy. Negatywnym skutkiem takiego projektu jest to, że numer lekarza zostanie zduplikowany w bazie danych, jeśli ma wielu pacjentów, zwiększając w ten sposób zarówno ryzyko błędu wejściowego, jak i koszt i ryzyko aktualizacji tego numeru w przypadku zmiany (w porównaniu z trzecim normalnym model danych zgodny z formularzem, który przechowuje numer lekarza tylko raz na stole lekarza).

Codd później zdał sobie sprawę, że 3NF nie wyeliminował wszystkich niepożądanych anomalii danych i opracował silniejszą wersję, aby rozwiązać ten problem w 1974 roku, znaną jako postać normalna Boyce-Codda .

Definicja trzeciej postaci normalnej

Trzecia forma normalna (3NF) jest formą normalną używaną w normalizacji baz danych . 3NF został pierwotnie zdefiniowany przez EF Codda w 1971 roku.

Definicja Codda mówi, że stół jest w 3NF wtedy i tylko wtedy, gdy spełnione są oba poniższe warunki:

• Związek R (tabela) w drugiej postaci normalnej (2NF).
• Każdy niepierwszy atrybut R jest nieprzechodnie zależny od każdego klucza R.

Drugorzędnych atrybut R jest cechą, która nie należy do jakiegokolwiek klucza kandydata R. A zależności przechodniego jest funkcjonalna zależność , w którym X → Z ( X określa Z ) pośrednio na podstawie X → Y i Y → Z (gdzie nie jest tak, że Y → X ).

Definicja 3NF, która jest równoważna definicji Codda, ale wyrażona inaczej, została podana przez Carlo Zaniolo w 1982 roku. Definicja ta stwierdza, że ​​tabela jest w 3NF wtedy i tylko wtedy, gdy dla każdej z jej zależności funkcjonalnych X → A , przynajmniej jedna z poniższych spełnia warunki:

• X zawiera A (czyli A jest podzbiorem X , co oznacza, że X → A jest trywialną zależnością funkcjonalną),
• X to superklucz ,
• każdy element A  \  X , różnica między A i X , jest atrybutem pierwszym (tj. każdy atrybut w A  \  X jest zawarty w jakimś kluczu kandydującym ).

Definicja Zaniolo daje jasny obraz różnicy między 3NF a bardziej rygorystyczną formą normalną Boyce-Codda (BCNF). BCNF po prostu eliminuje trzecią alternatywę („Każdy element A  \  X , ustawiona różnica między A i X , jest atrybutem głównym”).

„Nic poza kluczem”

Przybliżenie definicji 3NF podanej przez Codda, odpowiadające tradycyjnemu zobowiązaniu się do złożenia prawdziwych zeznań w sądzie, zostało podane przez Billa Kenta: „[każdy] niekluczowy [atrybut] musi zawierać fakt dotyczący klucza, całego klucza, i tylko klucz". Powszechna odmiana uzupełnia tę definicję o przysięgę „tak mi dopomóż Codd ”.

Wymaganie istnienia „klucza” zapewnia, że ​​tabela jest w 1NF ; wymaganie, aby atrybuty niekluczowe były zależne od „całego klucza” zapewnia 2NF ; dalsze wymaganie, aby atrybuty niekluczowe były zależne od „nic prócz klucza” zapewnia 3NF. Chociaż to zdanie jest użyteczną mnemoniką, fakt, że wymienia tylko jeden klucz oznacza, że ​​definiuje pewne konieczne, ale niewystarczające warunki, aby spełnić drugą i trzecią formę normalną. Zarówno 2NF, jak i 3NF dotyczą w równym stopniu wszystkich kluczy kandydujących w tabeli, a nie tylko jednego klucza.

Chris Date odwołuje się do podsumowania Kenta jako „intuicyjnie atrakcyjnej charakterystyki” 3NF i zauważa, że ​​przy niewielkiej adaptacji może służyć jako definicja nieco silniejszej postaci normalnej Boyce-Codd : „Każdy atrybut musi reprezentować fakt dotyczący klucza, całość klucz i tylko klucz." Wersja 3NF definicji jest słabszy niż zmienności BCNF data, tak jak były dotyczy jedynie zapewnienie, że zakaz kluczowe atrybuty zależą od kluczy. Atrybuty pierwsze (które są kluczami lub częściami kluczy) nie mogą być w ogóle zależne funkcjonalnie; każdy z nich reprezentuje fakt dotyczący klucza w sensie dostarczenia części lub całości samego klucza. (Ta reguła ma zastosowanie tylko do atrybutów zależnych funkcjonalnie, ponieważ zastosowanie jej do wszystkich atrybutów domyślnie zabroniłoby złożonych kluczy kandydujących, ponieważ każda część takiego klucza naruszałaby klauzulę „cały klucz”).

Przykładem tabeli 2NF, która nie spełnia wymagań 3NF jest:

Ponieważ każdy wiersz w tabeli musi informować nas, kto wygrał dany Turniej w danym Roku, klucz złożony {Tournament, Year} to minimalny zestaw atrybutów gwarantujących jednoznaczną identyfikację wiersza. Oznacza to, że {Tournament, Year} jest kluczem kandydującym do stołu.

Naruszenie 3NF występuje, ponieważ atrybut non-prim (data urodzenia zwycięzcy) jest przejściowo zależny od klucza kandydata {Tournament, Year} przez atrybut non-prime Winner. Fakt, że data urodzenia Winnera jest funkcjonalnie zależna od Winnera, sprawia, że ​​tabela jest podatna na logiczne niespójności, ponieważ nic nie stoi na przeszkodzie, aby ta sama osoba była pokazywana z różnymi datami urodzenia w różnych rekordach.

Aby wyrazić te same fakty bez naruszania 3NF, konieczne jest podzielenie tabeli na dwie:

Anomalie aktualizacji nie mogą wystąpić w tych tabelach, ponieważ w przeciwieństwie do poprzednich zwycięzca jest teraz kluczem kandydującym w drugiej tabeli, co pozwala tylko na jedną wartość daty urodzenia dla każdego zwycięzcy.

Obliczenie

Relację można zawsze rozłożyć w trzeciej postaci normalnej, to znaczy, że relacja R zostaje przepisana na rzuty R ₁ , ..., R _n, których połączenie jest równe relacji pierwotnej. Co więcej, ta dekompozycja nie traci żadnej funkcjonalnej zależności , w tym sensie, że każda funkcjonalna zależność od R może być wyprowadzona z funkcjonalnych zależności, które utrzymują się na rzutach R ₁ , ..., R _n . Co więcej, taki rozkład można obliczyć w czasie wielomianowym .

Wyprowadzenie warunków Zaniolo

Definicja 3NF podana przez Carlo Zaniolo w 1982 r. i podana powyżej jest udowodniona w następujący sposób: Niech X → A będzie nietrywialnym FD (tzn. takim, w którym X nie zawiera A) i niech A będzie atrybutem niekluczowym. Niech Y będzie również kluczem R. Wtedy Y → X.

Normalizacja poza 3NF

Większość tabel 3NF jest wolna od anomalii związanych z aktualizacją, wstawianiem i usuwaniem. Niektóre typy tabel 3NF, rzadko spotykane w praktyce, są dotknięte takimi anomaliami; są tabele, które albo krótki Boyce-Codda (BCNF) lub, jeżeli spełniają one BCNF, nie spełniają wyżej zwykłych postaci 4nF lub 5NF .

Uwagi dotyczące stosowania w środowiskach raportowania

Chociaż 3NF był idealny do przetwarzania maszynowego, segmentowy charakter modelu danych może być trudny do wykorzystania przez użytkownika. Analizę za pomocą zapytań, raportów i pulpitów nawigacyjnych często ułatwiał inny typ modelu danych, który zapewniał wstępnie obliczoną analizę, taką jak linie trendu, obliczenia od początku do końca (od miesiąca do dnia, od początku kwartału, od początku roku, dotychczas), obliczenia skumulowane, podstawowe statystyki (średnia, odchylenie standardowe, średnie ruchome) i porównania z poprzednim okresem (rok temu, miesiąc temu, tydzień temu) np. modelowanie wymiarowe i poza wymiarowe, spłaszczanie gwiazd przez Hadoop i naukę o danych .

Zobacz też

• System atrybut-wartość

Bibliografia

Dalsza lektura

Zewnętrzne linki

• Wskazówki Litta: Normalizacja
• Podstawy normalizacji baz danych autorstwa Mike'a Chapple'a (About.com)
• Wprowadzenie do normalizacji baz danych autorstwa Mike'a Hillyera.
• Samouczek dotyczący pierwszych 3 normalnych form autorstwa Freda Coulsona
• Opis podstaw normalizacji baz danych firmy Microsoft
• Trzecia forma normalna z prostymi przykładami przez exploreDatabase