Czym jest normalizacja (lub normalizacja)?

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

• the key ( 1NF )
• cały klucz ( 2NF )
• i nic poza kluczem (3NF )

... Więc pomóż mi [[19]] Codd.

Co najważniejsze służy do usuwania duplikacji z rekordów bazy danych. Na przykład, jeśli masz więcej niż jedno miejsce (stoły), w którym nazwisko osoby może pochodzić, przenieść nazwę do osobnej tabeli i odwołać się do niej wszędzie indziej. W ten sposób, jeśli chcesz później zmienić nazwę osoby, musisz zmienić ją tylko w jednym miejscu.

Jest to kluczowe dla prawidłowego projektowania bazy danych i w teorii powinieneś używać jej w jak największym stopniu, aby zachować integralność danych. Jednak gdy pobieranie informacji z wielu tabel powoduje utratę wydajności i dlatego czasami można zobaczyć denormalizowane tabele bazy danych (zwane również spłaszczonymi) używane w aplikacjach o krytycznym znaczeniu dla wydajności.

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

P. S. sprawdź też ten artykuł: http://en.wikipedia.org/wiki/Database_normalization aby przeczytać więcej na ten temat i o tzw. formularze

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

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

Redundancja i zależność danych jest niepożądana, ponieważ może prowadzić do nieścisłości podczas modyfikowania danych.

[[3]} ma na celu zmniejszenie nadmiarowości danych.

Aby uzyskać bardziej formalną dyskusję, zobacz Wikipedię http://en.wikipedia.org/wiki/Database_normalization

Załóżmy bazę danych organizacji, która 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 tabela rodzin

ID, address
27 123 Main St.

Prawie kompletna normalizacja (BCNF) zwykle nie jest używana w produkcji, ale jest pośrednią krok. Po umieszczeniu bazy danych w BCNF, następnym krokiem jest zwykle de-normalizacja w logiczny sposób, aby przyspieszyć zapytania i zmniejszyć złożoność niektórych typowych wstawek. Jednak nie można tego zrobić dobrze bez odpowiedniej normalizacji go najpierw.

Idea polegająca na tym, że zbędne informacje są zredukowane do jednego wpisu. Jest to szczególnie przydatne w polach takich jak adresy, gdzie Pan Chris podaje swój adres jako Unit - 7 123 Main St. i Pani Chris wymienia Suite-7 123 Główna ulica, która pojawiłaby się w oryginalnej tabeli jako dwa odrębne adresy.

Zazwyczaj stosuje się technikę znajdowania powtarzających się elementów i wyodrębniania tych pól w inną tabelę z unikalnymi identyfikatorami oraz zastępowania powtarzających się elementów kluczem podstawowym odwołującym się do nowej tabeli.

Cytowanie daty CJ: teoria jest praktyczna.

Odejście od normalizacji spowoduje pewne anomalie w Twojej bazie danych.

Odejście od pierwszej normalnej formy spowoduje anomalie dostępu, co oznacza, że musisz rozkładać i skanować poszczególne wartości, aby znaleźć to, czego szukasz. Na przykład, jeśli jedną z wartości jest ciąg znaków "Ford, Cadillac" podany przez wcześniejszą odpowiedź, a ty szukasz wszystkich ocurrences "Ford", będziesz musiał break otwórz łańcuch i spójrz na podłańcuchy. To w pewnym stopniu podważa cel 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 tabele SQL przy użyciu relacyjnego modelu danych, tabele będą automatycznie w 1NF.

Odejście od drugiej normalnej formy i dalej spowoduje anomalie aktualizacji, ponieważ ten sam fakt jest przechowywany w bardziej niż w jednym miejscu. Problemy te uniemożliwiają przechowywanie pewnych faktów bez przechowywania innych faktów, które mogą nie istnieć, a zatem muszą zostać wymyślone. Albo gdy fakty się zmienią, być może będziesz musiał zlokalizować wszystkie plces, w których przechowywany jest fakt i zaktualizować wszystkie te miejsca, aby nie skończyć z bazą danych, która sama sobie przeczy. A kiedy przejdziesz do usunięcia wiersza z bazy danych, może się okazać, że jeśli to zrobisz, usuwasz jedyne miejsce, w którym przechowywany jest nadal potrzebny fakt.

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

Niezależnie od wartości w tym, co zostało już powiedziane, należy wspomnieć, że normalizacja jest podejściem oddolnym, a nie odgórnym. Jeśli stosujesz określone metodologie w swojej analizie danych, a w Twój intial projekt, możesz mieć gwarancję, że projekt będzie zgodny z 3NF co najmniej. W wielu przypadkach projekt zostanie w pełni znormalizowany.

Gdzie naprawdę chcesz zastosować pojęcia nauczane w normalizacji jest wtedy, gdy masz dane starsze, ze starszej bazy danych lub z plików składających się z rekordów, a dane zostały zaprojektowane w całkowitej ignorancji normalnych form i konsekwencji odchodzenia od nich. W takich przypadkach może być konieczne odkrycie odlotów od normalizacji i popraw projekt.

Ostrzeżenie: normalizacja jest często nauczana z religijnym wydźwiękiem, tak jakby każde odejście od pełnej normalizacji było grzechem, obrazą przeciwko Codd. (mały kalambur). Nie kupuj tego. Kiedy naprawdę nauczysz się projektowania baz danych, będziesz nie tylko wiedział, jak przestrzegać zasad, ale także wiedział, kiedy można je bezpiecznie łamać.

Zanim przejdziemy bezpośrednio do tematu "normalizacja bazy danych i jej typy", musimy zrozumieć redundancję danych, anomalie wstawiania/aktualizacji/usuwania, częściową zależność i przejściową zależność funkcjonalną.

Co to jest redundancja danych i anomalia aktualizacji/modyfikacji?

Redundancja danych to niepotrzebne powielanie danych w wielu tabelach w bazie danych lub nawet w tej samej tabeli. Niepotrzebnie zwiększa rozmiar bazy danych i zmniejsza wydajność bazy danych poprzez powodowanie niespójności danych.

Przykład:

Tutaj 'student_age' dla studenta Alex jest powtarzany niepotrzebnie, co naturalnie zwiększa redundancję danych. Gdy kolumna 'student_age' ma zostać zmieniona w przyszłości, aktualizacja musi zostać wykonana w obu wierszach studenta Alex, jak w powyższej tabeli. Ten scenariusz jest znany jako anomalia aktualizacji. Jeśli użytkownik aktualizuje tylko jeden wiersz i zapomni zaktualizować drugi row spowoduje niespójność danych.

Co to jest anomalia wstawiania?

Anomalia wstawiania występuje, gdy pewne wartości dla atrybutu* nie mogą być wstawione do tabeli bez istnienia dodatkowych danych związanych z tą konkretną wartością.

Przykład:

Tutaj' student_name 'i' exam_registered ' są zakładane jako złożony klucz podstawowy (klucz podstawowy, który zawiera wiele kolumn). Klucz podstawowy powinien być zawsze unikalny, nie powinien zawierać wartości NULL i musi jednoznacznie identyfikować każdy wiersz tabeli. Teraz Załóżmy, że liceum próbuje wprowadzić nowy egzamin o nazwie Chemia. Na początku żaden student nie był zarejestrowany na tym kursie. Ponieważ powyższa tabela nie akceptuje wartości NULL w kolumnie 'student_name', musimy poczekać, aż przynajmniej jeden student zostanie zarejestrowany, aby dokonać wpisu na egzamin z chemii w powyższej tabeli.

Co to jest anomalia usuwania?

Anomalia delecji występuje, gdy pewne ważne wartości atrybutu * zostaną utracone z powodu usunięcia innych, nie wymaganych wartości.

Przykład:

Tutaj' student_name 'i' exam_registered ' są zakładane jako złożony klucz podstawowy (klucz podstawowy, który zawiera wiele kolumn). Klucz podstawowy powinien być zawsze unikalny i nie powinien zawierać wartości NULL oraz musi jednoznacznie identyfikować każdy wiersz tabeli. Teraz Załóżmy, że uczeń o imieniu John odwołał swoją rejestracja na egzamin z języka angielskiego. Ponieważ kolumna 'student_name' nie może zawierać wartości NULL, będziemy zmuszeni usunąć cały wiersz, który kosztował nas utratę egzaminu o nazwie English z naszej tabeli. Mimo to liceum oferuje swoim uczniom możliwość zdawania egzaminu z języka angielskiego.

Czym jest częściowa zależność?

Mówi się, że tabela jest w częściowej zależności, gdy atrybut klucza innego niż podstawowy w tej tabeli jest w pełni zależny od części złożonej podstawowej atrybut kluczowy w tej tabeli.

Przykład:

Rozważ tabelę zawierającą 3 kolumny o nazwach "student_name", "student_age" i "exam_registered" jak powyżej. Tutaj 'student_name ' i' exam_registered ' mogą razem tworzyć złożony klucz podstawowy. Zwykle każda kolumna klucza innego niż podstawowy w dobrze znormalizowanej tabeli powinna zawsze zależeć od kompletnego zestawu złożonego klucza podstawowego. Tutaj 'student_age' zależy tylko od 'student_name' i nie jest związane z 'exam_registered' co powoduje, że ta tabela jest częściowo zależna.

Czym jest transitive functional dependency?

Mówi się, że tabela znajduje się w transitive functional dependency, gdy atrybut klucza innego niż podstawowy w tej tabeli jest silniej zależny od innego atrybutu klucza innego niż podstawowy w tej tabeli.

Przykład:

W powyższej tabeli relacja między atrybutem non primary key' postal_code ' a innym kluczem non primary atrybut 'City' jest o wiele silniejszy niż relacja między atrybutem klucza podstawowego 'student_id' a atrybutem klucza innego niż podstawowy 'postal_code'. Powoduje to, że powyższa tabela znajduje się w transitive functional dependency.

Dzięki lepszemu zrozumieniu powyższych pojęć możemy teraz zagłębić się w normalizację tabel w bazach danych.

Dane zależą od klucza [1NF], całego klucza [2NF] i nic poza klucz [3NF]

Tabela bez normalizacja

Poniżej podano przykładową tabelę denormalizowaną, która zostanie znormalizowana w krokach przyrostowych w tym artykule.

W poniższym przykładzie dla student_id=2, są 2 wpisy ze względu na różne id rodzica. tutaj możemy założyć, że Parent_id = 1 reprezentuje ojca, a Parent_id = 3 reprezentuje matkę tego ucznia, którego student_id=2.

Przykład:

Pierwsza postać normalna (1NF)

Zasady: 1. Atrybuty muszą zawierać tylko wartości atomowe 2. Brak dwóch wierszy danych musi zawierać powtarzającą się grupę informacji 3. Każdy stół musi mieć klucz podstawowy

Krok 1:

Zasada 1 jest spełniona w powyższym kroku, ale nadal nie spełnia zasady 2 i 3.

Krok 2: Poniższe tabele spełniają obecnie zasady 1, 2 I 3 1NF.

Druga Postać Normalna (2NF)

Zasady:

1. tabele powinny spełniać pierwszą normalną postać (1NF)
2. nie powinno być żadnej częściowej zależności w tabelach

Poza pierwszą tabelą wszystkie pozostałe tabele z 1NF spełniają 2NF. W pierwszej tabeli kolumna 'age' zależy tylko od Kolumny 'student_id'. Narusza to zasadę 2 2NF. Ponieważ wszystkie kolumny bez klucza powinny całkowicie zależeć od kolumn klucza głównego. Więc znormalizowane Tabele według 2NF podano poniżej.

Trzecia postać normalna (3NF)

Zazwyczaj relacyjna tabela bazy danych jest często opisywana jako 'znormalizowana', jeśli spełnia wymagania 3NF. Większość tabel 3NF jest wolna od anomalii insert, update I delete.

Zasady:

1. tabele powinny spełniać drugą normalną postać (2NF)
2. nie powinno być żadnych przechodnich zależności funkcyjnych w tabelach

Oprócz ostatniej tabeli wszystkie pozostałe tabele z 2NF spełniają 3NF. Dzieje się tak dlatego, że kolumna "miasto" silniej zależy od Kolumny "postal_code" niż klucz główny "student_id", co sprawia, że kolumna "miasto" jest funkcją przejściową zależną od Kolumny "student_id". Tak więc ostateczne znormalizowane tabele jak na 3NF są podane jak poniżej.

*atrybut:

======================================================================== proste przykłady-normalizacja bazy danych

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

W bazach danych oznacza konkretnie, że dwie (lub więcej) tabele nie zawierają tych samych danych, tzn. nie mają żadnej nadmiarowości.

Na pierwszy rzut oka jest to naprawdę dobre, ponieważ twoje szanse na problemy z synchronizacją są bliskie zeru, zawsze wiesz, gdzie są Twoje dane itp. Ale, prawdopodobnie, liczba tabel będzie rosnąć i będziesz miał problemy, aby przejść przez danych i uzyskać podsumowanie wyników.

Tak więc na końcu skończysz z projektem bazy danych, który nie jest czysto znormalizowany, z pewną redundancją (będzie to w niektórych możliwych poziomach normalizacji).

Co to jest normalizacja?

Normalizacja jest etapowym procesem formalnym, który pozwala nam na dekompresję tabel bazodanowych w taki sposób, że zarówno redundancja danych jak i Aktualizacja anomalii są zminimalizowane.

Proces Normalizacji

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 divided), a wartość każdego atrybutu zawiera tylko jedną wartość z tej domeny (przykład: - domena dla kolumny gender to: "M", "F". ).

Pierwsza postać normalna spełnia te kryteria:

• wyeliminowanie powtarzających się grup 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ąstkowych zależności tzn. wszystkie atrybuty niezwiązane z kluczem są w pełni funkcjonalne i zależą od klucza podstawowego.

Trzecia postać normalna = 2NF + brak zależności przechodnich tzn. wszystkie atrybuty niebędące kluczem są w pełni funkcjonalne zależne bezpośrednio od klucza podstawowego.

Boyce-Codd normalna forma (lub BCNF lub 3.5 NF) jest nieco mocniejszą wersją trzeciej normalnej formy (3NF).

Uwaga: - druga, trzecia i Boyce–Codd normalne formy dotyczą funkcjonalnych zależności. przykłady

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

Piąta postać normalna = 4NF + Usuń zależności join

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

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