Wprowadzenie do normalizacji bazy danych Pierwsze trzy normalne formy

Celem relacyjnej normalizacji bazy danych jest osiągnięcie i poprawa integralność danych i unikaj nadmiarowość danych Aby uniknąć możliwych anomalii wstawiania, aktualizacji lub usuwania. Relacyjna baza danych jest znormalizowana poprzez zastosowanie serii reguł zwanych formami normalnymi. W tym artykule omówimy pierwsze trzy normalne formy.

W tym samouczku się nauczysz:

• Jaka jest pierwsza normalna forma
• Jaka jest druga normalna forma
• Jaka jest trzecia normalna forma

Zastosowane wymagania i konwencje oprogramowania

Pierwsza normalna forma

Załóżmy, że mamy następującą tabelę, której używamy do przechowywania informacji o niektórych filmach:

+----+--------------------+--------------------+------+ |. Id | Nazwa | gatunek | Rok | +----+--------------------+--------------------+- ----+ | 1 | Egzorcysta | Horror | 1973 | |. 2 | Zwykli podejrzani | Thriller, neo-noir | 1995 | |. 3 | Gwiezdne wojny | Space-Opera | 1977 | +----+--------------------+--------------------+------+ 

Tabela powyżej, nie zaspokaja Pierwsza normalna forma, Dlaczego? Aby pierwsza normalna forma została spełniona, każda kolumna tabeli musi zawierać atomowy (niepodzielne) dane. W drugim rzędzie naszej tabeli, który zawiera informacje o filmie „zwykłych podejrzanych”, widzimy, że gatunek muzyczny Kolumna zawiera dane, które nie są atomowe. Wymieniono dwa gatunki: thriller i neo-noir. Powiedzmy, że w naszej reprezentacji chcemy pozwolić, aby jeden film był powiązany z więcej niż jednym gatunkiem; Jak rozwiązujemy problem?

Pierwszą rzeczą, która przychodzi na myśl, może być dodanie nowego wiersza w tym samym stole, powtórzenie informacji o filmie i po prostu określenie jednego gatunku na surowe. Ten pomysł jest dość okropny, ponieważ mielibyśmy wiele zbędnych danych (powinniśmy powtarzać te same informacje o filmie za każdym razem, gdy chcemy je kojarzyć z nowym gatunkiem!).

Kolejnym nieco lepszym rozwiązaniem byłoby dodanie nowej kolumny, więc na przykład gatunek1 I gatunek2 kolumny. To jednak, między innymi, stanowiłoby limit: co, jeśli film powinien zostać wymieniony w więcej niż dwóch gatunkach?

Mądrzejszym sposobem rozwiązania tego problemu jest utworzenie nowej tabeli używanej do przechowywania informacji o gatunkach. Oto tabela „gatunku”:

+----+-------------+ |. Id | Nazwa | +----+-------------+| 1 | Horror | |. 2 | Neo-Noir | |. 3 | Space-Opera | |. 4 | Thriller | +----+-------------+ 

Teraz, ponieważ ten między gatunkiem a filmem jest wielu dla wielu związek (film może być powiązany z kilkoma gatunkami, a gatunek może być powiązany z wieloma różnymi filmami), aby wyrazić go bez nadmiarowości danych, możemy skorzystać z SO
zwany Stół skrzyżowania:

+----------+----------+ |. film_id | gatunek_id | +----------+----------+| 1 | 1 | |. 2 | 2 | |. 2 | 4 | |. 3 | 3 | +----------+----------+ 

Nasz tabelę Junction ma jedyne zadanie, aby wyrazić związek wielu do wielu filmów i gatunku bytów. Składa się tylko z dwóch kolumn: film_id i genre_id. film_id Kolumna ma Klucz obcy ograniczenie do ID Kolumna film stół i gatunek_id ma obce kluczowe ograniczenia dla ID Kolumna gatunek muzyczny tabela. Dwie kolumny razem są używane jako złożony Klucz podstawowy, więc związek między filmem a gatunkiem można wyrażać tylko raz. W tym momencie możemy usunąć kolumnę „gatunku” z tabeli „Movie”:

+----+--------------------+------+ |. Id | Nazwa | Rok | +----+--------------------+------+| 1 | Egzorcysta | 1973 | |. 2 | Zwykli podejrzani | 1995 | |. 3 | Gwiezdne wojny | 1977 | +----+--------------------+------+ 

Tabela jest teraz w pierwszej normalnej formie.

Druga normalna forma

Pierwsza normalna forma jest warunkiem wstępnym dla drugiego: aby druga normalna forma została spełniona, dane muszą już znajdować się w Pierwsza normalna forma I nie powinno być żadnych częściowa zależność atrybutów wtórnych z podzbioru dowolnego Klucz kandydata.

Jaka jest częściowa zależność? Zacznijmy od stwierdzenia, że ​​w stole może być więcej niż jeden Klucz kandydata. Klucz kandydata to jedna kolumna lub zestaw kolumn, które razem można zidentyfikować jako unikalne w tabeli: tylko jeden z
Klucze kandydatów, niż zostaną wybrane jako stół główny klucz, który jednoznacznie identyfikuje każdy rząd.

Atrybuty, które są częścią kluczy kandydatów, są zdefiniowane jako główny, podczas gdy wszyscy inni są nazywani wtórny. Aby relacja była w drugiej normalnej formie, nie powinno być żadnego wtórnego atrybutu zależnego od podzbioru
klucza kandydata.

Zobaczmy przykład. Załóżmy, że mamy tabelę, której używamy do przechowywania danych o piłce nożnej i ich wynikach dla każdego gamedaya dla fantastycznej aplikacji piłkarskiej, coś takiego:

+-----------+------------+-----------+------------+---------+-------+ |. gracz_id | First_name | Last_name | Rola | Gameday | wynik |. +-----------+------------+-----------+------------ +---------+-------+| 111 | Cordaz | Alex | Bramkarz | 18 | 6.50 | |. 117 | Donnarumma | Gianluigi | Bramkarz | 18 | 7.50 | |. 124 | Handanovic | Samir | Bramkarz | 18 | 7.50 | +-----------+------------+-----------+------------+---------+-------+ 

Rzućmy okiem na ten stół. Przede wszystkim widzimy, że spełnia pierwszą normalną formę, ponieważ dane w każdej kolumnie są atomowe. Dane zawarte w gracz_id Kolumna może być użyta do jednoznacznej identyfikacji gracza, ale
Czy można go użyć jako klucz podstawowy dla tabeli? Odpowiedź brzmi „nie”, ponieważ dla każdego gracza będzie istniał rząd dla każdego gamedaya! Tutaj moglibyśmy użyć złożony Klucz podstawowy zamiast tego wykonany przez kombinację gracz_id I dzień gry kolumny, ponieważ jeden i tylko jeden wpis może istnieć dla tego gracza dla każdego gamedaya.

Czy ta tabela spełnia drugą normalną formę? Odpowiedź brzmi nie, zobaczmy, dlaczego. Wcześniej powiedzieliśmy, że każdy atrybut, który nie jest częścią żadnych kluczy kandydatów, jest wywoływany wtórny i dla stołu, aby zaspokoić drugą normę
forma nie może zależeć od podzbiór każdego klucza kandydata, ale musi to zależeć od klucza kandydata jako całości.

Weźmy rola na przykład atrybut. Jest to atrybut drugorzędny, ponieważ nie jest częścią żadnego klucza kandydata. Możemy powiedzieć, że jest to funkcjonalnie zależne gracz_id, Ponieważ jeśli gracz się zmienia, może również potencjalnie zmienić rolę stowarzyszoną; Jednak nie jest to zależne od dzień gry, który jest drugim elementem złożonego klucza podstawowego, ponieważ nawet jeśli gameday zmienia rolę gracza, pozostaje taka sama. Możemy to powiedzieć rola jest funkcjonalnie zależny od podzbiór złożonego klucza podstawowego, dlatego druga forma normalna nie jest spełniona.

Aby rozwiązać problem, możemy utworzyć osobną tabelę używaną wyłącznie do opisania każdego gracza:

+-----------+------------+-----------+------------+ |. gracz_id | First_name | Last_name | Rola | +-----------+------------+-----------+------------ + | 111 | Cordaz | Alex | Bramkarz | |. 117 | Donnarumma | Gianluigi | Bramkarz | |. 124 | Handanovic | Samir | Bramkarz | +-----------+------------+-----------+------------+ 

Możemy teraz usunąć te informacje z tabeli wyników i sprawić, by wyglądało to w ten sposób:

+-----------+---------+-------+ |. gracz_id | Gameday | wynik |. +-----------+---------+-------+| 111 | 18 | 6.50 | |. 117 | 18 | 7.50 | |. 124 | 18 | 7.50 | +-----------+---------+-------+ 

Druga normalna forma jest teraz zadowolona.

Trzecia normalna forma

Druga normalna forma jest warunkiem wstępnym dla trzeciej formy normalnej. Aby być w trzeciej normalnej formie, tabela musi być już w drugiej normalnej formie i nie może zawierać atrybutów, które są zależne od tranzytycznie Na stole kluczowym. Co to znaczy? Możemy powiedzieć, że mamy Zależność przechodnia Gdy atrybut wtórny nie zależy bezpośrednio od klucza podstawowego tabeli, ale ma zależność od innego atrybutu wtórnego. Załóżmy, że dodamy dwie nowe kolumny do gracz Tabela powyżej, więc wygląda tak:

+-----------+------------+-----------+------------+---------+-----------+ |. gracz_id | First_name | Last_name | Rola | klub | Club_city | +-----------+------------+-----------+------------ +---------+-----------+| 111 | Cordaz | Alex | Bramkarz | Crotone | Crotone | |. 117 | Donnarumma | Gianluigi | Bramkarz | Milan | Milano | |. 124 | Handanovic | Samir | Bramkarz | Inter | Milano | +-----------+------------+-----------+------------+---------+-----------+ 

Dodaliśmy Klub I Club_city kolumny do tabeli, aby określić odpowiednio klub związany z zawodnikiem i miastem, do którego należy klub. Niestety stół teraz nie zaspokaja Trzecia normalna forma, Dlaczego? To jest dość proste: Club_city atrybut nie zależy bezpośrednio gracz_id, który jest kluczem podstawowym tabeli, ale ma od niego zależność przechodnie, poprzez inny wtórny atrybut: Klub.

Jak rozwiązać problem, aby spełnić trzecią normalną formę? Musimy tylko stworzyć inną tabelę, gdzie nagrywać informacje o każdym klubie. Oto stół „klubowy”:

+-----------+-----------+ |. Club_name | Club_city | +-----------+-----------+| Crotone | Crotone | |. Milan | Milano | |. Inter | Milano | +-----------+-----------+ 

Izolowaliśmy informacje o klubie w dedykowanej tabeli. Jako klucz podstawowy dla tabeli, w tym przypadku użyliśmy Club_name kolumna. w gracz Tabela, którą możemy teraz usunąć Club_city kolumna i dodaj ograniczenie klucza obcego do Klub kolumna, aby odnosi się do Club_name kolumna w Klub tabela:

+-----------+------------+-----------+------------+---------+ |. gracz_id | First_name | Last_name | Rola | klub | +-----------+------------+-----------+------------ + ---------+ | 111 | Cordaz | Alex | Bramkarz | Crotone | |. 117 | Donnarumma | Gianluigi | Bramkarz | Milan | |. 124 | Handanovic | Samir | Bramkarz | Inter | +-----------+------------+-----------+------------+---------+ 

Trzecia normalna forma jest teraz zadowolona.

Wnioski

W tym samouczku rozmawialiśmy o pierwszych trzech normalnych formach relacyjnej bazy danych oraz o tym, jak są one wykorzystywane do zmniejszenia nadmiarowości danych i uniknięcia anomalii wstawiania, usuwania i aktualizacji. Widzieliśmy, jakie są warunki każdej normalnej formy, niektóre przykłady ich naruszeń i jak je naprawić. Inne normalne formy istnieją po trzeciej jednak w najczęstszych zastosowaniach, osiągnięcie trzeciej normalnej formy wystarczy, aby osiągnąć optymalną konfigurację.

Powiązane samouczki Linux:

• Rzeczy do zainstalowania na Ubuntu 20.04
• Wprowadzenie do automatyzacji, narzędzi i technik Linuksa
• Mastering Bash Script Loops
• Rzeczy do zrobienia po zainstalowaniu Ubuntu 20.04 Focal Fossa Linux
• Mint 20: Lepsze niż Ubuntu i Microsoft Windows?
• Linux Pliki konfiguracyjne: Top 30 Najważniejsze
• Konfigurowanie ZFS na Ubuntu 20.04
• Ubuntu 20.04 sztuczki i rzeczy, których możesz nie wiedzieć
• Big Data Manipulacja dla zabawy i zysku Część 1
• Zagnieżdżone pętle w skryptach Bash