Mam problem z drugą normalną formą (2NF) i nie udało mi się go rozwiązać za pomocą Google. Doprowadza mnie do szału, ponieważ jestem nauczycielem i nie chcę uczyć niewłaściwych rzeczy dla moich uczniów.

Zróbmy stół z 5 polami.

Oceny = {StudentName, SubjectCode, SubjectName, #Exam, Grade}

Zależności są w ten sposób:

StudentName, SubjectCode, #Exam -> Grade

SubjectCode -> SubjectName

SubjectName -> SubjectCode

Dlatego kluczem kandydata 1 jest {StudentName, SubjectCode, #Exam}, a kluczem kandydata 2 jest {StudentName, SubjectName, #Exam} .

Główne atrybuty to {StudentName, SubjectCode, SubjectName, #Exam}, a atrybuty inne niż Prime mają ocenę

Zgodnie z definicją drugiej postaci normalnej atrybut niepierwotny nie może zależeć od części klucza kandydującego. Jedyny atrybut niepierwotny (klasa) nie zależy od części klucza kandydującego, więc ta tabela wydaje się w 2NF.

Problem polega na tym, że myślę, że coś jest nie tak (i ​​mogę się mylić). Myślę, że badani powinni mieć własny stół.

Oceny = {StudentName, kod przedmiotu, #Exam, ocena}

Tematy = {kod podmiotu, nazwa podmiotu}

Ale 2NF tego nie produkuje. 3NF dotyczy zależności między atrybutami niepierwotnymi, więc też tego nie produkuje. Wydaje mi się jednak, że jest to właściwy wynik, ponieważ nie ma nadmiarowości.

Wydaje mi się, że gdyby atrybut niepierwotny zdefiniowano jako „atrybut, który nie jest kluczem kandydującym”, 2NF dałoby pożądany wynik. Ale sprawdzałem to raz po raz i atrybut inny niż podstawowy jest zdefiniowany jako „atrybut, który nie należy do klucza kandydującego”.

Co ja robię źle?

Twoja relacja jest w 3NF (i nie tylko w 2NF), ponieważ, jak mówisz, jedynym niepierwszym atrybutem jest Stopień , który pojawia się tylko po prawej stronie twoich FD.

Relacja nie występuje w BCNF, ponieważ lewa strona dwóch małych FD nie jest superkluczem.

Możesz jednak bezstratnie rozłożyć relację na ( SubjectCode , SubjectName ) i albo ( StudentName, SubjectCode, #Exam, Grade ) lub ( StudentName, SubjectName, #Exam, Grade )

Ten rozkład daje dwie relacje BCNF i zachowuje wszystkie zależności funkcjonalne. Nie zawsze jest to możliwe (zawsze można rozłożyć relację do 3NF, ale niekoniecznie do BCNF).

2NF

Jeśli chcesz przykład 2NF (a nie 3NF), twoja relacja musi zawierać zależności przechodnie.

Załóżmy na przykład, że masz kolumnę wyników. Intuicyjnie Wynik-> Ocena, ponieważ wszystkie egzaminy z tym samym wynikiem powinny uzyskać tę samą ocenę (w przeciwnym razie byłoby to niesprawiedliwe), ale należy pamiętać, że nie możemy powiedzieć Ocena-> Ocena, ponieważ kilka wyników może mieć tę samą ocenę (11% i 12% to na przykład „Fail”).

Teraz twoja relacja to:

Oceny ( StudentName, SubjectCode, SubjectName, #Exam, Score, Grade )

i masz nową formę redundancji, ponieważ za każdym razem, gdy wpisujesz wynik z takim samym wynikiem, jak inny rekord Gradings, musisz również powtórzyć odpowiednią ocenę. Aby dostać się do 3NF, możesz się zatem rozpakować

ScoreGrades ( wynik, ocena )

z nik jako klucz i

Wyniki ( StudentName, SubjectCode, SubjectName, #Exam, Score )

Masz rację we wszystkim, co mówisz. Kod podmiotu, nazwa podmiotu muszą znajdować się we własnej tabeli, aby wymusić pożądane zależności. To dobry przykład, dlaczego 2NF i 3NF nie są wystarczające do stworzenia dobrych projektów baz danych - zamiast tego potrzebujesz Boyce Codd Normal Form (BCNF).

2NF i 3NF są zastępowane przez BCNF, co praktycznie czyni te mniejsze NF przestarzałymi *. BCNF jest ważniejszy i prawdopodobnie łatwiejszy do wyjaśnienia i zastosowania. Jako nauczyciel sugeruję, abyś spędzał więcej czasu na BCNF, a mniej na 2NF i 3NF. Jeśli tabela spełnia wymagania BCNF, to również spełnia również 2NF i 3NF.

* 3NF nie jest najwyższą zachowującą zależność formą normalną. Podstawowym formularzem normalnej formy (EKNF) jest. Ściśle mówiąc, to EKNF, a nie BCNF, sprawia, że ​​3NF jest przestarzały, ale EKNF jest niesprawiedliwie zaniedbywany, a większość podręczników i kursów nawet o nim nie wspomina. To samo sprowadza się do zaprojektowania BCNF, a następnie sprawdzenia, czy wszystkie pożądane zależności i wszelkie inne reguły integralności mogą być odpowiednio egzekwowane - jeśli nie, to zmodyfikuj projekt. Żadna z NF nie jest kompletnym rozwiązaniem dla integralności danych, ale BCNF zasadniczo jest najbliżej i jest najłatwiejszy do wyjaśnienia i użycia.

Nie powiem, ile czasu minęło, odkąd nauczyłem się tego wszystkiego. Ale pamiętam, że miałem profesora, który po obowiązkowym nauczeniu nas właściwego znaczenia „zależności funkcjonalnej” i „atrybutu non-prime” oraz wszystkich innych modnych słów, zadał nam serię prostych pytań, aby sprawdzić, czy jest jakaś normalna forma została osiągnięta. Zobaczmy, czy pamiętam tak daleko ...

Zidentyfikowaliśmy klucze kandydujące, dlatego zadajemy to pytanie o pozostałe atrybuty inne niż podstawowe. W tym przypadku jest tylko jedna ocena.

Jakich absolutnych minimalnych informacji potrzebujemy, aby jednoznacznie zidentyfikować ocenę? Musimy znać ucznia, przedmiot i zdawany egzamin. Dobra, to jeden z kluczy kandydujących.

EDYCJA: VVV

Ale odpowiedzią może być równie dobrze imię i nazwisko studenta, nazwa przedmiotu i egzamin. To by pasowało do drugiego klucza kandydata.

Zakładając, że zarówno SubjectCode, jak i SubjectName są kluczami kandydującymi do encji podmiotu, nie ma powodu, aby mieć tutaj oba te pola. Wystarczy jedno unikalne odniesienie do wiersza w tabeli Tematy. Możemy więc bezpiecznie całkowicie pozbyć się pola SubjectName bez poświęcania jakiejkolwiek integralności modelu.

Jednak w mojej pierwotnej odpowiedzi, chcąc wykazać kolejny poziom normalizacji, zignorowałem fakt, że nazwa podmiotu została użyta w kluczu kandydującym i uznałem to za kolejny atrybut niepierwotny. Wydaje mi się, że było to dla mnie tak oczywiste, że było to bezużyteczne pole. Pomyślałem, że będzie tak samo oczywiste dla wszystkich, a ponieważ w każdym razie pozbyliśmy się tego pola, jakie to miało znaczenie?

Ale zamiast usunąć tę część odpowiedzi, zachowam ją dla porównania.

KONIEC EDYCJI: ^ ^ ^

Jakich absolutnych minimalnych informacji potrzebujemy, aby jednoznacznie zidentyfikować nazwę przedmiotu?

SubjectName jest zależny tylko od SubjectCode - podzbioru klucza kandydującego. Więc tej krotki nie ma w 2nf. SubjectCode powinien być podstawowym kluczem tabeli Subjects, aby była to odpowiednia lokalizacja do umieszczenia SubjectName. Usuń go z tej krotki i będzie teraz w 2nf.

Jeśli zadamy pytanie o atrybut, a odpowiedź nie zawiera całości lub części klucza kandydującego, to krotki nie ma w 3nf. Ale ta krotka jest również trywialnie w 3nf i później, ponieważ zabrakło nam pól do zadawania pytań. ;)

Uwaga: kiedy mówimy „normalizuj”, mamy na myśli proces zastosowany do logicznej jednostki. Ponieważ dostarczona krotka wydaje się być definicją bytu zwanego „oceną”, możemy go znormalizować. Jednak w pewnym momencie powiedziałem: „tej krotki nie ma w 2nf”, co bardziej właściwie powinno być, „tej istoty nie ma w 2nf”. Przepraszam, jeśli spowodowało to zamieszanie.

Jedyny atrybut niepierwotny (klasa) nie zależy od części klucza kandydującego, więc ta tabela wydaje się w 2NF.

Jest w 2NF.

Problem polega na tym, że myślę, że coś jest nie tak (i ​​mogę się mylić). Myślę, że badani powinni mieć własny stół.

Nie ma powodu oczekiwać, że badani powinni mieć własną tabelę do rozkładu oryginalnej tabeli do 2NF . Mylicie jakieś niejasne pojęcie „powinieneś” z tym, co faktycznie daje ci jakaś konkretna normalna forma.

3NF dotyczy zależności między atrybutami niepierwotnymi, więc też tego nie produkuje.

„3NF dotyczy zależności między atrybutami niepierwotnymi” nie jest właściwą definicją 3NF, więc „więc też tego nie produkuje” nie jest dobrym wnioskiem. Chociaż zastosowanie faktycznej definicji pokazuje, że tabela jest w formacie 3NF, nie jest potrzebna tabela ucznia. Ale znowu nie ma powodu, aby oczekiwać, że tak będzie.

Wydaje mi się jednak, że jest to właściwy wynik, ponieważ nie ma nadmiarowości.

Ponownie, „redundancja” jest nieprecyzyjnie niejasna, więc twoje oczekiwania „bo” i oczekiwania uczniów nie są uzasadnione. Różne normalne formy są wolne od określonych rodzajów anomalii i związanych z nimi „nadmiarowości”. Ale mogą pozostać inne „nadmiarowości”, których nie dotyczy normalizacja.

Ta tabela nie znajduje się w BCNF, ponieważ ma FD, które nie są poza CK. Rozkładanie go według BCNF prowadzi do posiadania tabeli ucznia. BCNF jest najwyższą normalną formą postępowania z JD (zależnościami łączenia) towarzyszącymi FD. Jednak inne JD mogą być problematyczne (tj. „Nie sugerowane przez CK”) i powinny zostać usunięte poprzez normalizację do 5NF.

PS Oryginalna tabela spełnia również wymagania FD {StudentName, SubjectName, #Exam} -> Grade.

Zależności są w ten sposób:

Co to ma znaczyć? To nie jest jasne.

Czy masz na myśli: „Są to wszystkie nietrywialne FD, które się utrzymują”? Nie, ponieważ implikują czwartą. „Oto niektóre posiadające FD”? Nie, to znaczy, że FD w przejściowym zamknięciu są wstrzymane, ale to nie znaczy, że inne nie utrzymują, ale udało ci się ustalić CK. „FD, które posiadają, są dokładnie tymi, które przechodzą przez okres przejściowy”? Jeśli miałeś na myśli to, wiedziałbyś o tym tylko , gdybyś to pokazał , tzn. Musiałbyś znaleźć to zamknięcie (zazwyczaj poprzez minimalną / kanoniczną ochronę), a następnie wykazać, że nie ma innych FD; czy ty? Niezależnie od tego, co napisałeś, nie oznacza tego. Spodziewam się więc, że nie zastanawiasz się poważnie nad sytuacją FD i CK.

Masz rację, przedmioty wymagają własnego stołu. Jeśli wybierzesz jeden z kluczy kandydujących, albo subject_codeczy subject_namestaje się non-klucz podstawowy kandydatem. Następnie usuwasz pole przedmiotów innych niż podstawowe z tabeli ocen.

Masz funkcjonalną zależność od tematu, dla którego masz dwa unikalne identyfikatory. Wskazuje na to zależność przechodnia między subject_codei subject_name. Wskazuje to na konieczność utworzenia tabeli zawierającej te dwa pola i usunięcia jednego z tych pól ze wszystkich innych tabel. Ta tabela może mieć dodatkowe kolumny zależne, chociaż nie widzę żadnej w tym przykładzie. W trzeciej normalnej formie, którą wybrałeś.

ocena zależy od pozostałych trzech pól (klucz kandydata) w nowej tabeli ocen. Jak wspomniano powyżej, musisz wybrać jedno z pól kandydujących do tabeli przedmiotów. Zwykle byłaby to wartość kodu, jeśli jest dostępna, ponieważ są one bardziej stabilne. Wynikowy model ma wartość 3nf, ponieważ wszystkie pola niekluczowe są całkowicie zależne od pól w kluczu podstawowym.

Dalsza analiza problemu (wymagań) prawdopodobnie da tabelę sesji, do której stosowane są oceny. Obecny model raczej nie obejmuje ucznia powtarzającego kurs. Zostanie to omówione w późniejszej lekcji.

Uczniowie prawdopodobnie również staną się oddzielną tabelą, ponieważ możliwe jest posiadanie wielu uczniów o tej samej nazwie. Problem zostałby prawdopodobnie rozwiązany poprzez dodanie syntetycznego klucza podstawowego (numer studenta?).

subjects --->  sessions ---+--> grades
students  -----------------+

Przygotowuję się do usunięcia tego, ponieważ jest to uważane za nieprawidłowe

Nazwa podmiotu jest także atrybutem niepierwotnym i zależy od części kodu podmiotu klucza podstawowego (zasada łamie - nie może być częściowej zależności żadnej kolumny od klucza podstawowego).

Jest to zabronione w 2. Zwykłej Formie i dlatego należy je umieścić we własnej tabeli, jak podejrzewasz.

Wydaje mi się, że odkąd utknąłeś w identyfikacji dwóch zestawów kluczy kandydujących, kiedy tworzysz tabelę, musisz wybrać jeden zestaw kluczy kandydujących, aby zrobić klucz podstawowy. Pozostałe kolumny stają się atrybutami niepierwotnymi, tzn. Jeśli wybierzesz swój drugi klucz kandydujący, kod podmiotu stanie się nieprzypisanym atrybutem zależnym od części klucza podstawowego (Nazwa podmiotu) i powinien zostać umieszczony we własnej tabeli.

Ważne jest, aby uczyć 1., 2. i 3. normalnej formy, aby budowały się nawzajem. BCNF jest także zasadniczo przedłużeniem trzeciej normalnej postaci, dlatego bardzo ważne jest mocne uchwycenie niższych poziomów.

Dalej; doświadczony programista nie weźmie pod uwagę niezależnych poziomów normalizacji, ponieważ wiele reguł staje się intuicyjnych.

Będą również wiedzieć, kiedy złamać zasady normalizacji, aby rozwiązać niektóre problemy projektowe i optymalizacyjne. Normalizację należy traktować jako przewodnik po dobrym projekcie, a nie surową zasadę, uważam, że byłby to również dobry punkt do nauczenia.