Jakie są normalne formularze bazy danych i czy możesz podać przykłady? [Zamknięte]

277

W projektowaniu relacyjnych baz danych istnieje koncepcja normalizacji baz danych lub po prostu normalizacji, która polega na organizowaniu kolumn (atrybutów) i tabel (relacji) w celu zmniejszenia nadmiarowości danych i poprawy integralności danych. (jak napisano na Wikipedii ).

Ponieważ większość artykułów jest nieco techniczna i dlatego trudniejsza do zrozumienia, proszę kogoś o napisanie łatwiejszego do zrozumienia wyjaśnienia na podstawie przykładów o tym, co oznaczają 1NF, 2NF, 3NF, a nawet 3.5NF (Boyce-Codd).

database database-design database-normalization

— barfoon
źródło

435

1NF jest najbardziej podstawową z normalnych form - każda komórka w tabeli musi zawierać tylko jedną informację i nie może być zduplikowanych wierszy.

2NF i 3NF polegają na uzależnieniu od klucza podstawowego. Przypomnij, że klucz podstawowy może składać się z wielu kolumn. Jak powiedział Chris w swojej odpowiedzi:

Dane zależą od klucza [1NF], całego klucza [2NF] i tylko klucza [3NF] (więc pomóżcie mi Coddowi ).

2NF

Załóżmy, że masz tabelę zawierającą kursy z danego semestru i masz następujące dane:

|-----Primary Key----|               uh oh |
                                           V
CourseID | SemesterID | #Places  | Course Name  |
------------------------------------------------|
IT101    |   2009-1   | 100      | Programming  |
IT101    |   2009-2   | 100      | Programming  |
IT102    |   2009-1   | 200      | Databases    |
IT102    |   2010-1   | 150      | Databases    |
IT103    |   2009-2   | 120      | Web Design   |

Nie ma tego w 2NF , ponieważ czwarta kolumna nie opiera się na całym kluczu - tylko na jego części. Nazwa kursu zależy od jego identyfikatora, ale nie ma nic wspólnego z tym, w którym semestrze się odbywa. Zatem, jak widać, mamy zduplikowane informacje - kilka wierszy mówi nam, że IT101 programuje, a IT102 to bazy danych. Naprawiliśmy to, przenosząc nazwę kursu do innej tabeli, gdzie CourseID jest CAŁKIM kluczem.

Primary Key |

CourseID    |  Course Name |
---------------------------|
IT101       | Programming  |
IT102       | Databases    |
IT103       | Web Design   |

Bez redundancji!

3NF

Okej, powiedzmy więc, że dodajemy również nazwisko nauczyciela kursu i kilka szczegółów na ich temat do RDBMS:

|-----Primary Key----|                           uh oh |
                                                       V
Course  |  Semester  |  #Places   |  TeacherID  | TeacherName  |
---------------------------------------------------------------|
IT101   |   2009-1   |  100       |  332        |  Mr Jones    |
IT101   |   2009-2   |  100       |  332        |  Mr Jones    |
IT102   |   2009-1   |  200       |  495        |  Mr Bentley  |
IT102   |   2010-1   |  150       |  332        |  Mr Jones    |
IT103   |   2009-2   |  120       |  242        |  Mrs Smith   |

Mam nadzieję, że teraz powinno być oczywiste, że TeacherName jest zależne od TeacherID - więc nie ma go w 3NF . Aby to naprawić, robimy to samo, co w 2NF - wyjmij pole TeacherName z tej tabeli i umieść je w swoim własnym, które ma TeacherID jako klucz.

 Primary Key |

 TeacherID   | TeacherName  |
 ---------------------------|
 332         |  Mr Jones    |
 495         |  Mr Bentley  |
 242         |  Mrs Smith   |

Bez redundancji !!

Jedną ważną rzeczą do zapamiętania jest to, że jeśli czegoś nie ma w 1NF, to nie ma też w 2NF ani 3NF. Tak więc każda dodatkowa postać normalna wymaga wszystko , że niższe normalne formy miałem, plus kilka dodatkowych warunków, które muszą wszystkie być spełnione.

— Smashery
źródło

9

Pomyśl o tym w kategoriach relacji między rzeczami. Jeśli zapytam „jak nazywa się kurs o ID IT101?”, Możesz mi odpowiedzieć, prawda? Podobnie, jeśli zapytam „jaki nauczyciel ma ID 332?” możesz mi powiedzieć, jaki to nauczyciel. Dlatego nazwa kursu zależy od jego identyfikatora.

— Smashery,

9

Nie można jednak pójść w drugą stronę - gdybym zapytał „Jaki jest identyfikator pana Jonesa?” może nie być w stanie udzielić jednoznacznej odpowiedzi, ponieważ może być dwóch Mr Joneses. Tak więc identyfikator nie jest zależny od nazwy - to nazwa zależy od identyfikatora.

— Smashery,

2

Możesz również pomyśleć o tym w ten sposób - spójrz na trzeci stolik w dół (pierwszy z Nauczycielem w nim). Co powstrzyma mnie od posiadania „Mr Jones” w pierwszym rzędzie, a następnie umieszczenia „Mr Bloggs” w drugim rzędzie? Nie powinienem tego robić, ponieważ oboje mają identyfikator 332.

— Smashery

30

@instantsetsuna - Pełne wyjaśnienie: w niektórych sądach pyta się świadka, czy powie „Prawdę, całą prawdę i tylko prawdę, więc pomóżcie mi Bogu”; ponieważ uważa się, że Bóg ma władzę, jeśli chodzi o wiedzę, czy mówisz prawdę. W przypadku baz danych możemy powiedzieć „Dane zależą od klucza, całego klucza i tylko klucza, więc pomóżcie mi Codd”. Ted Codd jest tym, który wpadł na pomysł relacyjnych baz danych - rzeczy oparte na kluczach itp., Więc byłby autorytetem w przypadku relacyjnych baz danych.

— Smashery,

5

@Smashery Jaka jest różnica między 2NF a 3NF?

— Zo ma

119

Nigdy nie miałem dobrej pamięci na dokładne sformułowanie, ale myślę, że w mojej klasie baz danych profesor zawsze mówił coś takiego:

Dane zależą od klucza [1NF], całego klucza [2NF] i tylko od klucza [3NF].

— Chris Shaffer
źródło

72

... więc pomóż mi Codd. en.wikipedia.org/wiki/Ted_Codd

— Smashery

6

Czym więc jest różnica The data depends on the key [1NF], nothing but the key [3NF]? Proszę nie mylić, ponieważ 1 sentymentalna odpowiedź nie wyjaśnia odpowiedzi, ale myli odwiedzających!

— Pratik

2

„każda komórka w tabeli musi zawierać tylko jedną informację i nie może być zduplikowanych wierszy”. - Nie rozumiem, w jaki sposób „Dane zależą od klucza” pasują do tego wszystkiego.

— Simon Forsberg

46

Oto szybka, wprawdzie zdyszana odpowiedź, ale w jednym zdaniu:

1NF: Twoja tabela jest zorganizowana jako nieuporządkowany zestaw danych i nie ma powtarzających się kolumn.

2NF: Nie powtarzasz danych w jednej kolumnie tabeli z powodu innej kolumny.

3NF: Każda kolumna w tabeli odnosi się tylko do klucza do tabeli - w tabeli nie ma kolumny opisującej inną kolumnę w tabeli, która nie jest kluczem.

Aby uzyskać więcej informacji, zobacz wikipedia ...

— Dave Markle
źródło

1

O ile mogę powiedzieć, unikanie przez 1NF powtarzających się grup nie odnosi się do powtarzających się kolumn, ale raczej pojedyncze kolumny, które reprezentują dowolną liczbę powtarzanych wartości dla tego samego atrybutu, tj. Nie są atomowe. Opieram to na np. (1) stackoverflow.com/questions/23194292/… / (2) stackoverflow.com/questions/26357276/…

— underscore_d

34

1NF: Tylko jedna wartość na kolumnę

2NF: Wszystkie kolumny klucza innego niż podstawowy w tabeli powinny zależeć od całego klucza podstawowego.

3NF: Wszystkie kolumny klucza innego niż podstawowy w tabeli powinny BEZPOŚREDNIO zależeć od całego klucza podstawowego.

Tutaj napisałem artykuł bardziej szczegółowo

— Arktur
źródło

Ponieważ nie podałeś atrybucji. Zredagowałem odpowiedź, aby podać informacje o autorze.

— Robert Harvey

O ile to możliwe, należy podać przykład w samej odpowiedzi. Przypadkowy użytkownik powinien być w stanie przeczytać twoją odpowiedź i uzyskać z niej pewną wartość bez konieczności klikania linku do bloga. Innymi słowy, odpowiedź powinna być samodzielna.

— Robert Harvey

Będę o tym pamiętać. Dziękuję :)

— Arcturus

3

Należy również zauważyć, że to pytanie ma dwa lata i ma już wysoko ocenioną odpowiedź, która została oznaczona jako zaakceptowana przez PO. Spóźnione odpowiedzi są uważniej analizowane przez społeczność, aby ocenić, czy wnoszą one dodatkową wartość do PO.

— Robert Harvey

3

@Arcturus przeczytał artykuł, wciąż jedno z lepszych wyjaśnień normalizacji.

— Olian04