Normalizacja w MYSQL

Co to jest normalizacja w MySQL i w jakim przypadku i jak z niej korzystać?

Author: Usama Abdulrehman, 2009-08-11

5 answers

[[4]}staram się tutaj wyjaśnić normalizację w kategoriach laickich. Po pierwsze, jest to coś, co dotyczy relacyjnej bazy danych (Oracle, Access, MySQL), więc nie jest to tylko dla MySQL.

Normalizacja polega na upewnieniu się, że każda tabela ma tylko minimalne pola i pozbyciu się zależności. Wyobraź sobie, że masz kartotekę pracowniczą, a każdy pracownik należy do działu. Jeśli przechowujesz dział jako pole wraz z innymi danymi pracownika, masz problem - co dzieje się, jeśli dział zostanie usunięty? Musisz zaktualizować wszystkie pola działu i jest szansa na błąd. A co jeśli niektórzy pracownicy nie mają działu (być może nowo przydzielonego?). Teraz będą wartości null.

Tak więc normalizacja, w skrócie, polega na unikaniu pól, które byłyby null i upewnieniu się, że wszystkie pola w tabeli należą tylko do jednej domeny opisywanych danych. Na przykład w tabeli pracowników pola mogą być id, name, social numer ochrony, ale te trzy pola nie mają nic wspólnego z Wydziałem. Tylko identyfikator pracownika określa, do którego działu należy pracownik. Oznacza to więc, że w którym dziale Znajduje się pracownik, powinien znajdować się w innej tabeli.

Oto prosty proces normalizacji.
EMPLOYEE ( < employee_id >, name, social_security, department_name)

To nie jest znormalizowane, jak wyjaśniono. Postać znormalizowana może wyglądać jak

EMPLOYEE ( < employee_id >, name, social_security)

Tutaj tabela pracowników jest odpowiedzialna tylko za jeden zestaw danych. Więc gdzie przechowujemy który dział pracownik należy do? W innej tabeli

EMPLOYEE_DEPARTMENT ( < employee_id >, department_name )
To nie jest optymalne. A jeśli zmieni się nazwa Wydziału? (dzieje się to w rządzie USA cały czas). Dlatego lepiej to zrobić
EMPLOYEE_DEPARTMENT ( < employee_id >, department_id )
DEPARTMENT ( < department_id >, department_name )

Istnieją pierwsza postać normalna, druga postać normalna i trzecia postać normalna. Ale jeśli nie studiujesz kursu DB, zwykle wybieram najbardziej znormalizowaną formę, jaką mogę zrozumieć.

Mam nadzieję, że to pomoże.
 82
Author: Extrakun,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-08-25 04:59:27

Normalizacja Nie dotyczy tylko MYSql. To ogólna koncepcja bazy danych.

Normalizacja jest procesem efektywne organizowanie danych w baza danych. Istnieją dwa cele proces normalizacji: eliminacja nadmiarowych danych (np. przechowywanie te same dane w więcej niż jednej tabeli) i zapewnienie zależności danych sprawiają sense (przechowuje tylko Powiązane Dane w tabela). Oba te cele są godne ponieważ zmniejszają ilość miejsca a baza danych zużywa i upewnij się, że dane jest logicznie przechowywany.

Normalne formularze w SQL są podane poniżej.

Pierwsza postać normalna (1NF): relacja jest mówi się, że jest w 1NF, jeśli ma tylko atrybuty o jednej wartości, ani dozwolone jest powtarzanie tablic nor.

Druga postać normalna (2NF): relacja mówi się, że jest w 2NF, jeśli jest w 1NF i każdy Nie kluczowy atrybut jest w pełni funkcjonalna zależna od podstawowej klucz.

Trzecia postać normalna (3NF): mówimy, że a relacja jest w 3NF jeśli jest w 2NF i nie ma zależności przechodnich.

Boyce-Codd postać normalna (BCNF): A relacja mówi się, że jest w BCNF, jeśli i tylko wtedy, gdy każdy wyznacznik w relacja jest kluczem kandydata.

Czwarta postać normalna (4NF): relacja mówi się, że jest w 4NF, jeśli jest w BCNF i nie zawiera wielowartościowej zależności.

Piąta postać normalna (5NF): relacja jest mówi się, że w 5NF wtedy i tylko wtedy, gdy każdy zależność join w relacji jest implikowana według klucza kandydata relacji.

Domain-Key Normal Form (DKNF): mówimy że relacja jest w DKNF, jeśli jest wolne od wszelkich anomalii modyfikacji. Wstawianie, usuwanie i aktualizacja anomalie ulegają modyfikacji anomalie

Zobacz też

Podstawy Normalizacji Baz Danych

 14
Author: rahul,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-11 07:51:56

Jest to technika zapewniająca spójność danych poprzez wyeliminowanie powielania. Tak więc baza danych, w której te same informacje są przechowywane w więcej niż jednej tabeli, nie jest znormalizowana .

Zobacz artykuł w Wikipedii na temat normalizacji bazy danych.

(jest to ogólna technika relacyjnych baz danych, nie specyficzna dla MySQL.)

 3
Author: RichieHindle,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-11 06:45:43

Podczas tworzenia schematu bazy danych dla aplikacji należy upewnić się, że informacje nie są przechowywane w więcej niż jednej kolumnie w różnych tabelach.

Ponieważ każda tabela w Twoim DB identyfikuje istotny element w Twojej aplikacji, unikalny identyfikator jest dla nich kolumną obowiązkową.

Teraz, decydując o schemacie przechowywania, identyfikowane są różnego rodzaju relacje między tymi podmiotami (tabelami), a mianowicie jeden do jednego, jeden do wielu, wiele do wielu.

  1. dla relacji jeden do jednego (np. A Student posiada unikalną rangę w klasy), ta sama tabela może być użyta do przechowuj kolumny (z obu tabel).
  2. dla relacji jeden do wielu (np. Semestr może mieć wiele kursy), klucz zagraniczny jest utworzone w tabeli nadrzędnej.
  3. dla relacji wielu do wielu (np. Prof. uczęszcza do wielu studentów i vice-versa), trzecia tabela musi być tworzone (przy pomocy klucza podstawowego z obie tabele jako klucz złożony), oraz powiązane dane obu tabel będą być przechowywane.

Gdy zajmiesz się tymi wszystkimi scenariuszami, twój schemat db zostanie znormalizowany do 4NF.

 2
Author: a6hi5h3k,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-11 07:11:52

W dziedzinie relacyjnej bazy danych projektowanie, normalizacja jest systematycznym sposób zapewnienia, że baza danych struktura nadaje się do zapytania ogólnego przeznaczenia i wolne od pewne niepożądane charakterystyka-wstawianie, aktualizacja i usuwanie anomalii-które mogą prowadzić do utrata integralności danych.[1] E. F. Codd, wynalazca relacyjnego model, wprowadził pojęcie normalizacji i to, co obecnie znamy jako pierwsza normalna forma w 1970 roku.[2] Codd poszedł na zdefiniuj drugi i trzeci formy normalne w 1971 r. [3] i Codd oraz Raymond F. Boyce zdefiniował Boyce-Codd normalna forma w 1974 roku.[4] Wyższe formy normalne zostały określone przez inni teoretycy w kolejnych latach, najnowsza jest szósta normalna forma wprowadzona przez Chris Date, Hugh Darwen i Nikos Lorentzos w 2002.[5]

Nieformalnie, relacyjna baza danych tabela (reprezentacja komputerowa relacji) jest często opisywany jako "znormalizowany", jeśli jest w trzeci postać normalna (3NF).[6] Większość tabel 3NF są wolne od wstawiania, aktualizacji i nieprawidłowości usuwania, tj. w większości przypadków Tabele 3NF są zgodne z BCNF, 4NF i 5NF (ale zazwyczaj nie 6NF).

Standardowy element projektu bazy danych wskazówki, że projektant powinien Stwórz w pełni znormalizowany projekt; selektywna denormalizacja może następnie należy wykonać dla powody wydajności.[7] jednak niektóre dyscypliny modelarskie, takie jak modelowanie wymiarowe podejście do dane projekt magazynu, polecam wzory niestandardowe, czyli wzory które w dużej części nie przylegają do 3NF.[8]

Edit: Source: http://en.wikipedia.org/wiki/Database_normalization

 0
Author: Jonik,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-11 06:54:25