Co to jest normalizacja (lub normalizacja)?

Dlaczego faceci od baz danych mówią o normalizacji?

Co to jest? Jak to pomaga?

Czy ma to zastosowanie do czegokolwiek poza bazami danych?

Normalizacja polega w zasadzie na zaprojektowaniu schematu bazy danych w taki sposób, aby uniknąć zduplikowanych i nadmiarowych danych. Jeśli jakaś część danych zostanie zduplikowana w kilku miejscach w bazie danych, istnieje ryzyko, że zostanie zaktualizowana w jednym miejscu, ale nie w drugim, co doprowadzi do uszkodzenia danych.

Istnieje kilka poziomów normalizacji od 1. postaci normalnej do 5. postaci normalnej. Każda normalna forma opisuje, jak pozbyć się konkretnego problemu, zwykle związanego z redundancją.

Niektóre typowe błędy normalizacji:

(1) Posiadanie więcej niż jednej wartości w komórce. Przykład:

UserId | Car
---------------------
1      | Toyota
2      | Ford,Cadillac

W tym przypadku kolumna „Samochód” (będąca ciągiem znaków) ma kilka wartości. To obraża pierwszą normalną postać, która mówi, że każda komórka powinna mieć tylko jedną wartość. Możemy znormalizować ten problem, oddzielając wiersz dla każdego samochodu:

UserId | Car
---------------------
1      | Toyota
2      | Ford
2      | Cadillac

Problem z posiadaniem kilku wartości w jednej komórce polega na tym, że trudno jest zaktualizować, trudniej jest wykonać zapytania i nie można zastosować indeksów, ograniczeń i tak dalej.

(2) Posiadanie nadmiarowych danych niebędących kluczami (tj. Danych niepotrzebnie powtarzanych w kilku wierszach). Przykład:

UserId | UserName | Car
-----------------------
1      | John     | Toyota
2      | Sue      | Ford
2      | Sue      | Cadillac

Ten projekt jest problemem, ponieważ nazwa jest powtarzana w każdej kolumnie, mimo że jest ona zawsze określana przez identyfikator użytkownika. Dzięki temu teoretycznie możliwa jest zmiana nazwy Sue w jednym wierszu, a nie w drugim, co powoduje uszkodzenie danych. Problem został rozwiązany przez podzielenie tabeli na dwie części i utworzenie relacji klucz podstawowy / klucz obcy:

UserId(FK) | Car               UserId(PK) | UserName
---------------------          -----------------
1          | Toyota            1          | John
2          | Ford              2          | Sue
2          | Cadillac

Teraz może się wydawać, że nadal mamy nadmiarowe dane, ponieważ identyfikatory użytkowników są powtarzane; Jednak ograniczenie PK / FK zapewnia, że ​​wartości nie mogą być aktualizowane niezależnie, więc integralność jest bezpieczna.

Czy to ważne? Tak, to jest bardzo ważne. Posiadając bazę danych z błędami normalizacji, stwarzasz ryzyko wprowadzenia do bazy danych nieprawidłowych lub uszkodzonych danych. Ponieważ dane „żyją wiecznie”, bardzo trudno jest pozbyć się uszkodzonych danych po ich wprowadzeniu do bazy danych.

Nie bój się normalizacji . Oficjalne techniczne definicje poziomów normalizacji są dość niejasne. Wydaje się, że normalizacja jest skomplikowanym procesem matematycznym. Jednak normalizacja jest po prostu zdrowym rozsądkiem i przekonasz się, że jeśli projektujesz schemat bazy danych przy użyciu zdrowego rozsądku, zazwyczaj będzie on w pełni znormalizowany.

Istnieje wiele nieporozumień dotyczących normalizacji:

• niektórzy uważają, że znormalizowane bazy danych są wolniejsze, a denormalizacja poprawia wydajność. Jest to jednak prawdą tylko w bardzo szczególnych przypadkach. Zazwyczaj najszybsza jest również znormalizowana baza danych.

• czasami normalizacja jest opisywana jako stopniowy proces projektowania i trzeba zdecydować, „kiedy przestać”. Ale w rzeczywistości poziomy normalizacji opisują tylko różne konkretne problemy. Problem rozwiązany przez zwykłe formy powyżej 3.NF to przede wszystkim dość rzadkie problemy, więc jest szansa, że ​​Twój schemat jest już w 5NF.

Czy ma to zastosowanie do czegokolwiek poza bazami danych? Nie bezpośrednio, nie. Zasady normalizacji są dość specyficzne dla relacyjnych baz danych. Jednak ogólny motyw przewodni - że nie powinieneś mieć zduplikowanych danych, jeśli różne instancje mogą stracić synchronizację - można zastosować szeroko. Jest to w zasadzie zasada DRY .

Zasady normalizacji (źródło: nieznane)

• Klucz ( 1NF )
• Cały klucz ( 2NF )
• i nic prócz klucza ( 3NF )

... Więc pomóż mi, Codd.

Przede wszystkim służy do usuwania duplikatów z rekordów bazy danych. Na przykład, jeśli masz więcej niż jedno miejsce (tabele), w których może pojawić się imię i nazwisko osoby, przenosisz je do oddzielnej tabeli i odwołujesz się do niego wszędzie. Dzięki temu, jeśli później zajdzie potrzeba zmiany nazwiska osoby, wystarczy zmienić je tylko w jednym miejscu.

Jest to kluczowe dla prawidłowego zaprojektowania bazy danych i teoretycznie należy jej używać w jak największym stopniu, aby zachować integralność danych. Jednak podczas pobierania informacji z wielu tabel tracisz trochę wydajności i dlatego czasami możesz zobaczyć zdenormalizowane tabele bazy danych (zwane również spłaszczonymi) używane w aplikacjach krytycznych dla wydajności.

Radzę zacząć od dobrego stopnia normalizacji i przeprowadzać de-normalizację tylko wtedy, gdy jest to naprawdę potrzebne

PS zajrzyj też do tego artykułu: http://en.wikipedia.org/wiki/Database_normalization, aby przeczytać więcej na ten temat oraz o tzw. normalnych

Normalizacja procedura stosowana w celu wyeliminowania nadmiarowości i zależności funkcjonalnych między kolumnami w tabeli.

Istnieje kilka normalnych form, ogólnie oznaczonych liczbą. Większa liczba oznacza mniej redundancji i zależności. Każda tabela SQL jest w 1NF (pierwsza normalna forma, prawie z definicji) Normalizacja oznacza zmianę schematu (często partycjonowanie tabel) w odwracalny sposób, dając model, który jest funkcjonalnie identyczny, z wyjątkiem mniejszej redundancji i zależności.

Nadmiarowość i zależność danych jest niepożądana, ponieważ może prowadzić do niespójności podczas modyfikowania danych.

Ma to na celu zmniejszenie nadmiarowości danych.

Bardziej formalna dyskusja znajduje się w Wikipedii http://en.wikipedia.org/wiki/Database_normalization

Podam nieco uproszczony przykład.

Załóżmy, że baza danych organizacji zwykle zawiera członków rodziny

id, name, address
214 Mr. Chris  123 Main St.
317 Mrs. Chris 123 Main St.

można znormalizować jako

id name familyID
214 Mr. Chris 27
317 Mrs. Chris 27

i stół rodzinny

ID, address
27 123 Main St.

Normalizacja prawie całkowita (BCNF) zwykle nie jest używana w produkcji, ale jest etapem pośrednim. Gdy już umieścisz bazę danych w BCNF, następnym krokiem jest zwykle jej zdenormalizowanie w logiczny sposób, aby przyspieszyć zapytania i zmniejszyć złożoność niektórych typowych wstawień. Jednak nie możesz tego zrobić dobrze, jeśli najpierw go nie normalizujesz.

Chodzi o to, że nadmiarowe informacje są zredukowane do jednego wpisu. Jest to szczególnie przydatne w polach takich jak adresy, w których pan Chris podaje swój adres jako Unit-7 123 Main St., a pani Chris wymienia Suite-7 123 Main Street, które pojawiłyby się w oryginalnej tabeli jako dwa różne adresy.

Zazwyczaj stosowana technika polega na znalezieniu powtarzających się elementów i wyodrębnieniu tych pól w innej tabeli z unikalnymi identyfikatorami oraz zastąpieniu powtarzających się elementów kluczem podstawowym odwołującym się do nowej tabeli.

Cytowanie CJ Data: Teoria JEST praktyczna.

Odstępstwa od normalizacji spowodują pewne anomalie w Twojej bazie danych.

Odejścia od pierwszej postaci normalnej spowodują anomalie dostępu, co oznacza, że ​​musisz rozłożyć i przeskanować poszczególne wartości, aby znaleźć to, czego szukasz. Na przykład, jeśli jedną z wartości jest ciąg „Ford, Cadillac”, jak podano we wcześniejszej odpowiedzi, i szukasz wszystkich wystąpień słowa „Ford”, będziesz musiał przerwać ciąg i spojrzeć na podciągi. W pewnym stopniu przeczy to celowi przechowywania danych w relacyjnej bazie danych.

Definicja pierwszej postaci normalnej zmieniła się od 1970 roku, ale te różnice nie muszą Cię na razie dotyczyć. Jeśli projektujesz swoje tabele SQL przy użyciu relacyjnego modelu danych, Twoje tabele zostaną automatycznie ustawione w 1NF.

Odejścia od drugiej normalnej formy i poza nią spowodują anomalie aktualizacji, ponieważ ten sam fakt jest przechowywany w więcej niż jednym miejscu. Te problemy uniemożliwiają przechowywanie niektórych faktów bez przechowywania innych faktów, które mogą nie istnieć, a zatem muszą zostać wymyślone. Lub gdy fakty się zmienią, być może będziesz musiał zlokalizować wszystkie miejsca, w których przechowywany jest fakt, i zaktualizować wszystkie te miejsca, aby nie skończyć z bazą danych, która jest sprzeczna ze sobą. A kiedy przejdziesz do usunięcia wiersza z bazy danych, może się okazać, że jeśli to zrobisz, usuniesz jedyne miejsce, w którym przechowywany jest nadal potrzebny fakt.

Są to problemy logiczne, a nie problemy z wydajnością lub przestrzenią. Czasami można obejść te anomalie aktualizacji, ostrożnie programując. Czasami (często) lepiej jest w pierwszej kolejności zapobiegać problemom, stosując się do normalnych form.

Niezależnie od wartości tego, co już zostało powiedziane, należy wspomnieć, że normalizacja jest podejściem oddolnym, a nie odgórnym. Jeśli będziesz postępować zgodnie z określonymi metodologiami w analizie danych i przy wstępnym projekcie, możesz mieć pewność, że projekt będzie co najmniej zgodny z 3NF. W wielu przypadkach projekt zostanie w pełni znormalizowany.

Tam, gdzie naprawdę możesz chcieć zastosować koncepcje nauczane w ramach normalizacji, jest to, gdy otrzymujesz dane starsze, ze starej bazy danych lub z plików złożonych z rekordów, a dane zostały zaprojektowane z całkowitym ignorowaniem normalnych formularzy i konsekwencji odejścia od nich. W takich przypadkach może zajść potrzeba odkrycia odstępstw od normalizacji i skorygowania projektu.

Ostrzeżenie: normalizacji często uczy się z religijnym podtekstem, tak jakby każde odejście od pełnej normalizacji było grzechem, obrazą Codda. (tam mała gra słów). Nie kupuj tego. Kiedy naprawdę, naprawdę nauczysz się projektowania baz danych, nie tylko będziesz wiedział, jak przestrzegać reguł, ale także wiesz, kiedy można je bezpiecznie złamać.

Normalizacja to jedno z podstawowych pojęć. Oznacza to, że dwie rzeczy na siebie nie wpływają.

W bazach danych konkretnie oznacza, że ​​dwie (lub więcej) tabele nie zawierają tych samych danych, tj. Nie mają żadnej redundancji.

Na pierwszy rzut oka jest to naprawdę dobre, ponieważ szanse na niektóre problemy z synchronizacją są bliskie zeru, zawsze wiesz, gdzie są twoje dane itp. Ale prawdopodobnie liczba tabel wzrośnie i będziesz miał problemy z krzyżowaniem danych i uzyskać podsumowanie wyników.

Tak więc na końcu zakończysz projekt bazy danych, która nie jest czysto znormalizowana, z pewną redundancją (będzie to na niektórych z możliwych poziomów normalizacji).

Co to jest normalizacja?

Normalizacja jest krokowym procesem formalnym, który pozwala nam dekomponować tabele bazy danych w taki sposób, aby zarówno nadmiarowość danych, jak i anomalie aktualizacji zminimalizować .

Proces normalizacji dzięki uprzejmości

Pierwsza postać normalna wtedy i tylko wtedy, gdy dziedzina każdego atrybutu zawiera tylko wartości atomowe (wartość atomowa to wartość, której nie można podzielić), a wartość każdego atrybutu zawiera tylko jedną wartość z tej domeny (przykład: - domena dla kolumna płci to: „M”, „F”).

Pierwsza normalna forma wymusza następujące kryteria:

• Wyeliminuj powtarzające się grupy w poszczególnych tabelach.
• Utwórz oddzielną tabelę dla każdego zestawu powiązanych danych.
• Zidentyfikuj każdy zestaw powiązanych danych za pomocą klucza podstawowego

Druga postać normalna = 1NF + brak częściowych zależności, tj. Wszystkie atrybuty niebędące kluczami są w pełni funkcjonalne zależnie od klucza podstawowego.

Trzecia postać normalna = 2NF + brak zależności przechodnich, tj. Wszystkie atrybuty niebędące kluczami są w pełni funkcjonalnie zależne BEZPOŚREDNIO tylko od klucza podstawowego.

Postać normalna Boyce'a – Codda (lub BCNF lub 3,5NF) jest nieco silniejszą wersją trzeciej postaci normalnej (3NF).

Uwaga: - Postacie normalne drugiej, trzeciej i Boyce-Codda dotyczą zależności funkcjonalnych. Przykłady

Czwarta postać normalna = 3NF + usuń zależności wielowartościowe

Piąta normalna postać = 4NF + usuń zależności łączenia

Jak mówi Martin Kleppman w swojej książce Designing Data Intensive Applications:

Literatura dotycząca modelu relacyjnego rozróżnia kilka różnych form normalnych, ale różnice te mają niewielkie znaczenie praktyczne. Zasadniczo, jeśli kopiujesz wartości, które mogą być przechowywane w jednym miejscu, schemat nie jest znormalizowany.

Pomaga zapobiegać powielaniu (i co gorsza, konfliktom) danych.

Może mieć jednak negatywny wpływ na wydajność.