Czym są formularze bazy danych i czy można podać przykłady? [zamknięte]

W projektowaniu relacyjnych baz danych istnieje pojęcie normalizacji bazy danych lub po prostu normalizacji, która jest procesem organizowania kolumn (atrybutów) i tabel (relacji) w celu zmniejszenia redundancji danych i poprawy integralności danych. (jak napisano na Wikipedii ).

Ponieważ większość artykułów jest nieco techniczna i przez to trudniejsza do zrozumienia, proszę kogoś, aby napisał łatwiejsze do zrozumienia wyjaśnienie na podstawie przykładów o tym, co 1NF, 2NF, 3NF, nawet 3.5 NF (Boyce-Codd) wredny.

Author: Jax, 2009-04-07
Source

4 answers

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

2NF i 3NF są zależne od klucza głównego. Przypomnijmy, ż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 nic poza kluczem [3NF] (tak mi pomóż Codd ).

2NF

Powiedz, że masz stół Zawiera kursy, które są podejmowane w określonym semestrze, 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   |

Jest to nie w 2NF , ponieważ Czwarta kolumna nie opiera się na całym kluczu - a tylko na jego części. Nazwa kursu zależy od identyfikatora kursu, ale nie ma nic wspólnego z tym, w którym semestrze został przyjęty. Tak więc, jak widać, mamy zduplikowane informacje - kilka wierszy mówi nam, że IT101 to programowanie, a IT102 To bazy danych. Więc naprawiamy to przenosząc nazwa kursu do innej tabeli, gdzie CourseID jest całym kluczem.

Primary Key |

CourseID    |  Course Name |
---------------------------|
IT101       | Programming  |
IT102       | Databases    |
IT103       | Web Design   |
Nie ma nadmiarowości!

3NF

Dobra, Załóżmy, że dodamy również imię i nazwisko prowadzącego kurs oraz kilka szczegółów na jego 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   |

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

 Primary Key |

 TeacherID   | TeacherName  |
 ---------------------------|
 332         |  Mr Jones    |
 495         |  Mr Bentley  |
 242         |  Mrs Smith   |
Nie ma nadmiarowości!!

Jedną ważną rzeczą do zapamiętania jest to, że jeśli coś nie jest w 1NF, to nie jest w 2NF lub 3NF albo. Tak więc każda dodatkowa forma normalna wymaga wszystkiego , co miały niższe formy normalne, plus kilka dodatkowych warunków, które muszą spełnić wszystkie.

 406
Author: Smashery,
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-05-31 01:12:21

Nigdy nie miałem dobrej pamięci do dokładnego sformułowania, ale na zajęciach z bazy danych myślę, że profesor zawsze mówił coś w stylu:

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

 109
Author: Chris Shaffer,
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-04-07 02:53:01

Oto szybka, co prawda zarżnięta odpowiedź, ale w 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 Twojej tabeli - nie masz kolumny w tabeli opisującej inną kolumnę w tabeli, która nie jest kluczem.

Więcej szczegóły, patrz wikipedia...

 43
Author: Dave Markle,
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
2016-08-23 16:38:11

1NF: tylko jedna wartość w kolumnie

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 zależeć bezpośrednio od całego klucza podstawowego.

Napisałem artykuł bardziej szczegółowo nad tutaj

 27
Author: Arcturus,
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
2016-12-18 02:13:30