Normalizacja to technika projektowania bazy danych, która jest używana do projektowania tabeli relacyjnej bazy danych do wyższej postaci normalnej. Proces jest progresywny i nie można osiągnąć wyższego poziomu normalizacji bazy danych, jeśli poprzednie poziomy nie zostały spełnione.
Oznacza to, że mając dane w formie nieznormalizowanej (najmniej znormalizowanej) i dążąc do osiągnięcia najwyższej poziom normalizacji, pierwszym krokiem byłoby zapewnienie zgodności z pierwszą formą normalną, drugim krokiem byłoby zapewnienie spełnienia drugiej postaci normalnej i tak dalej w kolejności wspomnianej powyżej, aż dane będą zgodne z szóstą postacią normalną.
Warto jednak zauważyć, że normalne formy poza 4NF są głównie przedmiotem zainteresowania akademickiego, ponieważ problemy, które istnieją, rzadko pojawiają się w praktyce.
Należy pamiętać, że dane w poniższym przykładzie celowo zaprojektowany, aby zaprzeczać większości normalnych form. W prawdziwym życiu całkiem możliwe jest pominięcie niektórych kroków normalizacji, ponieważ tabela nie zawiera niczego, co byłoby sprzeczne z daną formą normalną. Często zdarza się również, że naprawienie naruszenia jednej normalnej postaci naprawia również naruszenie wyższej normalnej postaci w procesie. Na każdym kroku wybrano również jedną tabelę do normalizacji, co oznacza, że pod koniec tego przykładowego procesu nadal mogą istnieć tabele niespełniające najwyższej formy normalnej.
Initial dataEdit
Niech tabela bazy danych o następującej strukturze:
| Tytuł | Autor | Narodowość autora | Format | Cena | Temat | Strony | Grubość | Wydawca | Kraj wydawcy | Typ publikacji | Identyfikator gatunku | Nazwa gatunku |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Początek projektowania i optymalizacji bazy danych MySQL | Chad Russell | American | Twarda oprawa | 49,99 | MySQL,
Baza danych, Projekt |
520 | Gruby | Apress | USA | E-book | 1 | Samouczek |
W tym przykładzie zakładamy, że każda książka ma tylko jednego autora.
Satysfakcjonujący 1NFEdit
Aby spełnić 1NF, wartości w każdej kolumnie tabeli muszą być niepodzielne. W początkowej tabeli Temat zawiera zestaw wartości tematu, co oznacza, że nie jest zgodny.
Jednym ze sposobów osiągnięcia 1NF byłoby rozdzielenie duplikatów na wiele kolumn za pomocą powtarzających się grup Temat:
| Tytuł | Format | Autor | Narodowość autora | Cena | Temat 1 | Temat 2 | Temat 3 | Strony | Grubość | Wydawca | Kraj wydawcy | Identyfikator gatunku | Nazwa gatunku |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Początek projektowania i optymalizacji bazy danych MySQL | Twarda oprawa | Chad Russell | Amerykański | 49,99 | MySQL | Baza danych | Projekt | 520 | Gruby | Apress | Stany Zjednoczone | 1 | Samouczek |
Chociaż teraz tabela formalnie jest zgodna z 1NF (jest atomowa), problem z tym rozwiązaniem jest oczywisty – jeśli książka ma więcej niż trzy tematy, nie można jej dodać do bazy danych bez zmiany jej struktury.
Aby rozwiązać problem w bardziej elegancki sposób, konieczne jest zidentyfikowanie bytów przedstawionych w tabeli i oddzielenie ich do swoich własnych tabel. W tym przypadku skutkowałoby to tabelami Book, Subject i Publisher:
| Tytuł | Format | Autor | Narodowość autora | Cena | Strony | Grubość | Identyfikator gatunku | Nazwa gatunku | Identyfikator wydawcy |
|---|---|---|---|---|---|---|---|---|---|
| Początek MySQL Projektowanie i optymalizacja bazy danych | Twarda oprawa | Chad Russell | Amerykanin | 49.99 | 520 | Gruby | 1 | Samouczek | 1 |
|
|
Zwykłe rozdzielenie danych początkowych na wiele tabel przerwałoby połączenie między danymi. Oznacza to, że należy określić relacje między nowo wprowadzonymi tabelami. Zwróć uwagę, że kolumna Identyfikator wydawcy w tabeli książki jest obcym kluczem, który określa relację wiele do jednego między książką a wydawcą.
Książka może pasować do wielu tematów, jak również temat może odpowiadają wielu książkom. Oznacza to również, że należy zdefiniować relację wiele do wielu, którą należy osiągnąć, tworząc tabelę linków:
|
Zamiast jednej tabeli w formie nieznormalizowanej są teraz 4 tabele zgodne z 1NF.
Satysfakcjonujący 2NFEdit
Tabela Book ma jeden klucz kandydujący (który jest zatem kluczem podstawowym), klucz złożony {Tytuł, Format}. Rozważ następujący fragment tabeli:
| Tytuł | Format | Autor | Narodowość autora | Cena | Strony | Grubość | Genre ID | Genre Name | Publisher ID |
|---|---|---|---|---|---|---|---|---|---|
| Początek projektowania i optymalizacji bazy danych MySQL | Twarda oprawa | Chad Russell | Amerykański | 49,99 | 520 | Gruby | 1 | Samouczek | 1 |
| Rozpoczęcie projektowania i optymalizacji bazy danych MySQL | E-book | Chad Russell | Amerykański | 22,34 | 520 | Gruby | 1 | Samouczek | 1 |
| Relacyjny model zarządzania bazami danych: wersja 2 | E-book | EFCodd | Brytyjska | 13,88 | 538 | Gruba | 2 | Popularnonaukowa | 2 |
| Relacyjny model bazy danych Ma nagement: wersja 2 | Miękka oprawa | EFCodd | Brytyjska | 39,99 | 538 | Gruby | 2 | Popularnonaukowy | 2 |
Wszystkie atrybuty, które nie są częścią klucza kandydującego, zależą od tytułu, ale tylko cena zależy również od formatu. Aby zachować zgodność z 2NF i usunąć duplikaty, każdy atrybut niebędący kluczem kandydującym musi zależeć od całego klucza kandydującego, a nie tylko jego części.
Aby znormalizować tę tabelę, utwórz {Tytuł} (prosty) klucz kandydujący (klucz podstawowy), tak aby każdy atrybut klucza innego niż kandydujący zależał od całego klucza kandydującego, i usuń cenę z oddzielnej tabeli, aby można było zachować jej zależność od formatu:
|
|
Teraz tabela Książka jest zgodna z 2NF.
Satysfakcjonujący 3NFEdit
Tabela Book nadal ma przechodnią zależność funkcjonalną ({Author Nationality} jest zależne od {Author}, który jest zależny od {Title }). Podobne naruszenie istnieje w przypadku gatunku ({Nazwa gatunku} jest zależne od {Identyfikator gatunku}, który jest zależny od {Tytuł}). W związku z tym tabela Book nie znajduje się w 3NF. Aby zrobić to w 3NF, użyjmy następującej struktury tabeli, eliminując w ten sposób przechodnie zależności funkcjonalne, umieszczając {Author Nationality} i {Genre Name} w odpowiednich tabelach:
| Tytuł | Autor | Strony | Grubość | Identyfikator gatunku | Identyfikator wydawcy |
|---|---|---|---|---|---|
| Rozpoczęcie projektowania bazy danych MySQL i Optymalizacja | Chad Russell | 520 | Gruby | 1 | 1 |
| Relacyjny model zarządzania bazami danych: wersja 2 | EFCodd | 538 | Gruby | 2 | 2 |
|
| Autor | Narodowość autora |
|---|---|
| Chad Russell | Amerykanin |
| EFCodd | Brytyjczyk |
| Gen re ID | Nazwa gatunku |
|---|---|
| 1 | Samouczek |
| 2 | Popularnonaukowa |
Satysfakcja z EKNFEdit
Podstawowa forma normalna klucza (EKNF) mieści się ściśle między 3NF i BCNF i nie jest zbytnio omawiana w literaturze. Jego celem jest „uchwycenie najistotniejszych cech zarówno 3NF, jak i BCNF” przy jednoczesnym uniknięciu problemów obu (a mianowicie, że 3NF jest „zbyt wybaczający”, a BCNF jest „podatny na złożoność obliczeniową”). Ponieważ rzadko jest wspominany w literaturze, nie jest to uwzględnione w tym przykładzie.
Satysfakcjonujący 4NFEdit
Załóżmy, że baza danych jest własnością franczyzy księgarskiej, która ma kilku franczyzobiorców posiadających sklepy w różnych lokalizacjach.Dlatego sprzedawca zdecydował się dodać tabelę zawierającą dane o dostępności książek w różnych lokalizacjach:
| Identyfikator franczyzobiorcy | Tytuł | Lokalizacja |
|---|---|---|
| 1 | Rozpoczęcie projektowania i optymalizacji bazy danych MySQL | Kalifornia |
| 1 | Rozpoczęcie projektowania i optymalizacji bazy danych MySQL | Floryda |
| 1 | Rozpoczęcie projektowania i optymalizacji bazy danych MySQL | Teksas |
| 1 | Relacyjny model zarządzania bazami danych: wersja 2 | Kalifornia |
| 1 | Relacyjny model zarządzania bazami danych: wersja 2 | Floryda |
| 1 | Relacyjny model zarządzania bazami danych: wersja 2 | Teksas |
| 2 | Początek projektowania i optymalizacji bazy danych MySQL | Kalifornia |
| 2 | Rozpoczęcie projektowania i optymalizacji bazy danych MySQL | Floryda |
| 2 | Początek projektowania i optymalizacji bazy danych MySQL | Teksas |
| 2 | Relacyjny model zarządzania bazami danych: wersja 2 | Kalifornia |
| 2 | Relacyjny model zarządzania bazami danych: wersja 2 | Floryda |
| 2 | Relacyjny model zarządzania bazami danych: wersja 2 | Teksas |
| 3 | Rozpoczęcie projektowania i optymalizacji bazy danych MySQL | Teksas |
Ponieważ ta struktura tabeli składa się ze złożonego klucza podstawowego, nie zawiera ona żadnych atrybutów niebędących kluczem i znajduje się już w BCNF (a zatem spełnia również wszystkie poprzednie formy normalne). Jeśli jednak przyjmiemy, że wszystkie dostępne książki są oferowane w każdym obszarze, możemy zauważyć, że tytuł nie jest jednoznacznie powiązany z określoną lokalizacją i dlatego tabela nie spełnia wymagań 4NF.
Oznacza to, że aby spełnić czwartą normalną postać, należy również zdekomponować tę tabelę:
|
|
||||||||||||
| Identyfikator franczyzobiorcy | Lokalizacja | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Kalifornia | ||||||||||||
| 1 | Floryda | ||||||||||||
| 1 | Teksas | ||||||||||||
| 2 | Kalifornia | ||||||||||||
| 2 | Floryda | ||||||||||||
| 2 | Teksas | ||||||||||||
| 3 | Teksas |
Teraz każdy rekord jest jednoznacznie identyfikowany przez superklucz, dlatego 4NF jest spełniony.
Zadowalający ETNFEdit
Załóżmy, że franczyzobiorcy mogą również zamawiać książki od różnych dostawców. Niech relacja podlega również następującym ograniczeniom:
- Jeśli pewien dostawca dostarcza określony tytuł
- i tytuł ten jest dostarczany franczyzobiorcy
- a franczyzobiorca jest zaopatrywany przez dostawcę,
- wówczas dostawca dostarcza franczyzobiorcy tytuł własności.
| Identyfikator dostawcy | Tytuł | Identyfikator franczyzobiorcy |
|---|---|---|
| 1 | Początek projektowania i optymalizacji bazy danych MySQL | 1 |
| 2 | Relacyjny model zarządzania bazami danych: wersja 2 | 2 |
| 3 | Nauka SQL | 3 |
Ta tabela jest w 4NF, ale ID dostawcy jest równe połączeniu jej prognoz: {{ID dostawcy, książka}, {książka, ID franczyzobiorcy}, {ID franczyzobiorcy, dostawca ID}}.Żaden składnik tej zależności łączenia nie jest superkluczem (jedynym superkluczem jest cały nagłówek), więc tabela nie spełnia wymagań ETNF i może być dalej rozłożona:
|
|
|
Dekompozycja zapewnia zgodność z ETNF.
Spełnianie 5NFEdit
Aby znaleźć tabelę niespełniającą 5NF, należy jest zwykle konieczne do dokładnego zbadania danych. Załóżmy, że tabela z przykładu 4NF z niewielkimi modyfikacjami danych i sprawdźmy, czy spełnia 5NF:
| Identyfikator franczyzobiorcy | Tytuł | Lokalizacja |
|---|---|---|
| 1 | Rozpoczęcie projektowania i optymalizacji bazy danych MySQL | Kalifornia |
| 1 | Nauka SQL | Kalifornia |
| 1 | Relacyjny model zarządzania bazami danych: wersja 2 | Teksas |
| 2 | Relacyjny model zarządzania bazami danych: wersja 2 | Kalifornia |
Jeśli zdekomponujemy tę tabelę, zmniejszymy nadmiarowość i otrzymamy następujące dwie tabele:
|
|
Co się stanie, jeśli spróbujemy dołączyć do tych tabel? Zapytanie zwróci następujące dane:
| Identyfikator franczyzobiorcy | Tytuł | Lokalizacja |
|---|---|---|
| 1 | Początek projektowania bazy danych MySQL i Optymalizacja | Kalifornia |
| 1 | Nauka SQL | Kalifornia |
| 1 | Relacyjny model zarządzania bazami danych: wersja 2 | Kalifornia |
| 1 | Relacyjny model zarządzania bazami danych: wersja 2 | Teksas |
| 1 | Nauka SQL | Teksas |
| 1 | Rozpoczęcie projektowania i optymalizacji bazy danych MySQL | Teksas |
| 2 | Relacyjny model zarządzania bazami danych: wersja 2 | Kalifornia |
Najwyraźniej JOIN zwraca o trzy wiersze więcej niż powinien – spróbujmy dodać ano tabela, aby wyjaśnić związek.Otrzymujemy trzy oddzielne tabele:
|
|
|
Co teraz zwróci JOIN? W rzeczywistości nie jest możliwe dołączenie do tych trzech stołów. Oznacza to, że nie było możliwe zdekomponowanie lokalizacji książki franczyzobiorcy bez utraty danych, dlatego tabela już spełnia 5NF.
CJ Date twierdzi, że tylko baza danych w 5NF jest naprawdę „znormalizowana”.
Satysfakcjonujący DKNFEdit
Spójrzmy na tabelę Book z poprzednich przykładów i zobaczmy, czy spełnia ona normalną formę klucza domeny:
| Tytuł | Strony | Grubość | Genre ID | Publisher ID | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Rozpoczęcie projektowania i optymalizacji bazy danych MySQL | 520 | Gruby | 1 | 1 | ||||||||||||||||||||||||||
| Relacyjny model zarządzania bazami danych: wersja 2 | 538 | Gruby | 2 | 2 | ||||||||||||||||||||||||||
| Nauka SQL | 338 | Slim | 1 | 3 | ||||||||||||||||||||||||||
| SQL Cookbook | 636 | Gruby | 1 | 3 |
|
|
W ten sposób naruszenie integralności domeny zostało wyeliminowane, a tabela jest w DKNF.
Satysfakcjonujący 6NFEdit
Prosta i intuicyjna definicja szóstej postaci normalnej jest taka, że „tabela znajduje się w 6NF, gdy wiersz zawiera klucz podstawowy i co najwyżej jeden inny atrybut”.
Oznacza to na przykład, że tabela wydawcy zaprojektowana podczas tworzenia 1NF
| Identyfikator_ wydawcy | Nazwa | Kraj |
|---|---|---|
| 1 | Apress | USA |
musi być dalej zdekomponowany na dwie tabele:
|
|
Oczywistą wadą 6NF jest mnożenie się tabel wymaganych do przedstawienia informacji o pojedynczej jednostce. Jeśli tabela w 5NF ma jedną kolumnę klucza podstawowego i N atrybutów, reprezentowanie tych samych informacji w 6NF będzie wymagało N tabel; aktualizacje wielu pól w jednym rekordzie koncepcyjnym będą wymagały aktualizacji wielu tabel; a wstawianie i usuwanie podobnie będzie wymagało operacji na wielu tabelach. Z tego powodu w bazach danych przeznaczonych na potrzeby przetwarzania transakcji online 6NF nie powinno być używane.
Jednak w hurtowniach danych, które nie pozwalają na interaktywne aktualizacje i które są wyspecjalizowane do szybkiego wyszukiwania dużych ilości danych , niektóre DBMS używają wewnętrznej reprezentacji 6NF – znanej jako kolumna składnicy danych. W sytuacjach, gdy liczba unikatowych wartości w kolumnie jest znacznie mniejsza niż liczba wierszy w tabeli, magazyn zorientowany na kolumny umożliwia znaczne oszczędności miejsca dzięki kompresji danych. Magazyn kolumnowy umożliwia również szybkie wykonywanie zapytań o zakres (np. Pokazanie wszystkich rekordów, w których dana kolumna znajduje się między X a Y lub mniej niż X).
Jednak we wszystkich tych przypadkach projektant bazy danych nie trzeba ręcznie przeprowadzić normalizację 6NF, tworząc oddzielne tabele. Niektóre systemy DBMS, które specjalizują się w magazynowaniu, takie jak Sybase IQ, domyślnie używają pamięci kolumnowej, ale projektant nadal widzi tylko jedną tabelę wielokolumnową. Inne systemy DBMS, takie jak Microsoft SQL Server 2012 i nowsze, pozwalają określić „indeks magazynu kolumn” dla konkretnej tabeli.
