У мене проблема з другою нормальною формою (2NF), і я не зміг її вирішити за допомогою Google. Мене це зводить з розуму, бо я вчитель, і я не хочу викладати студентам неправильні речі.

Давайте мати таблицю з 5 полями.

Оцінки = {StudentName, SubjectCode, SubjectName, #Exam, Grade}

Залежності такі:

StudentName, SubjectCode, #Exam -> Оцінка

SubjectCode -> SubjectName

SubjectName -> SubjectCode

Тому ключовим ключем 1 є {StudentName, SubjectCode, #Exam}, а ключовим ключем 2 є {StudentName, SubjectName, #Exam} .

Основними атрибутами є {StudentName, SubjectCode, SubjectName, #Exam}, а не-простими атрибутами є клас

Відповідно до визначення другої нормальної форми, атрибут non-прости не може залежати від частини ключа-кандидата. Єдиний непримітний атрибут (Оцінка) не залежить від частини ключа-кандидата, тому ця таблиця здається в 2NF.

Проблема в тому, що я думаю, що щось не так (і я можу помилитися). Я думаю, що предмети повинні мати власну таблицю.

Оцінки = {StudentName, код предмета, #Exam, клас}

Subjects = {Код теми, ім'я суб'єкта}

Але 2NF цього не виробляє. 3NF - це залежність між атрибутами, які не є простими, тому це також не створює. Але мені здається, що це правильний результат, оскільки він не має надмірності.

Я думаю, якщо атрибут, який не є простим, був визначений як "атрибут, який не є ключовим ключем", 2NF дасть бажаний результат. Але я перевіряв це ще раз і знову, і непримітний атрибут визначається як "атрибут, який не БІЛЬНІН до ключа-кандидата".

Що я роблю неправильно?

Ваше співвідношення знаходиться в 3NF (і не тільки в 2NF), оскільки, як ви кажете, єдиний непритаманний атрибут - Оцінка , яка відображається лише в правій частині ваших FD.

Співвідношення немає у BCNF, оскільки ліва частина двох малих FD не є надлюдина.

Однак ви можете без втрат розкласти відношення до ( SubjectCode , SubjectName ) та або ( StudentName, SubjectCode, #Exam, Grade ) або ( StudentName, SubjectName, #Exam, Grade )

Цей розклад дає два відношення BCNF і зберігає всі функціональні залежності. Це не завжди можливо (ви завжди можете розкласти відношення до 3NF, але не обов'язково до BCNF).

2NF

Якщо ви хочете прикладу 2NF (а не 3NF), ваше відношення повинно містити перехідні залежності.

Наприклад, скажімо, що у вас є стовпець "Оцінка". Інтуїтивно оцінюючи-> Оцінка, оскільки всі іспити з однаковим балом повинні отримувати однаковий бал (це було б досить несправедливо), але зауважте, що ми не можемо сказати Оцінка-> Оцінка, оскільки декілька балів можуть мати однаковий бал (11% та 12% ймовірно, наприклад, "Fail", наприклад).

Тепер ваше відношення:

Оцінки ( StudentName, SubjectCode, SubjectName, #Exam, Score, grade )

і у вас є нова форма надмірності, оскільки кожен раз, коли ви вводите результат з тим же балом, що й інший запис оцінок, ви також повинні повторювати відповідний клас. Таким чином, ви можете дістатися до 3NF

ScoreGrades ( бал, оцінка )

з Оцінка як ключ, і

Оцінки ( StudentName, SubjectCode, SubjectName, #Exam, Score )

Ви маєте рацію у всьому, що говорите. Код предмету, SubjectName потрібно зайти у власну таблицю, щоб застосувати потрібні залежності. Це хороший приклад того, чому 2NF та 3NF недостатньо для створення гарних конструкцій баз даних - замість цього вам потрібна нормальна форма Boyce Codd (BCNF).

2NF і 3NF витісняються BCNF, що практично робить ці менші НФ застарілими *. BCNF є більш важливим і, мабуть, простішим для пояснення та застосування. Як вчитель я пропоную вам витратити більше часу на BCNF і менше на 2NF та 3NF. Якщо таблиця задовольняє вимогам BCNF, то вона також задовольняє 2NF та 3NF.

* 3NF - це не найвища нормальна форма, що зберігає залежність. Елементарний ключ Нормальна форма (EKNF) є. Власне кажучи, саме EKNF, а не BCNF, робить 3NF застарілим, але EKNF несправедливо нехтують, і більшість підручників і курсів навіть не згадують про це. Що таке одне і те саме - це спроектувати BCNF, а потім перевірити, чи всі потрібні залежності та будь-які інші правила цілісності можуть бути належним чином виконані - якщо ні, то модифікувати дизайн. Жоден з НФ не є повноцінним рішенням цілісності даних, але BCNF, як правило, наближається і є найпростішим для пояснення та використання.

Я не скажу, як довго минуло, коли я вперше все це дізнався. Але я пам’ятаю, що у мене був професор, який, після того, як ми навчили нас правильному значенню «функціональної залежності» та «непростого атрибута» та всіх інших модниць, дав нам ряд простих запитань, щоб поставити питання, чи є конкретна нормальна була досягнута форма. Подивимось, чи можу я згадати це далеко ...

Ми визначили ключові ключі-кандидати, тому ми задаємо це питання решти непростіх атрибутів. У цьому випадку існує лише одне: оцінка.

Який абсолютний мінімум інформації нам потрібен, щоб однозначно визначити оцінку? Нам потрібно знати студента, тему та іспит, який здають. Добре, це один із кандидатів.

РЕДАКТ: VVV

Але відповідь так само могла бути іменем студента, назвою предмета та іспитом. Це відповідало б другому ключу кандидата.

Якщо припустити, що SubjectCode і SubjectName - обидва кандидатні ключі для суб'єкта Subject, немає жодних причин для обох цих полів тут. Одного унікального посилання на рядок у таблиці Тематики цілком достатньо. Тож ми можемо спокійно позбутися поля SubjectName взагалі, не приносячи шкоди цілісності моделі.

Однак у своїй оригінальній відповіді, бажаючи показати інший рівень нормалізації, я проігнорував, що SubjectName був використаний у ключі-кандидата і вважав це лише черговим непримітним атрибутом. Я думаю, це було для мене настільки очевидним, що це марне поле, я думав, що це буде так само очевидно для всіх, і оскільки в будь-якому випадку ми позбулися поля, що це мало значення?

Але замість того, щоб видаляти цю частину відповіді, я зроблю це для порівняння.

ЗАКОННИЙ РЕДАКТ: ^ ^ ^

Який абсолютний мінімум інформації нам потрібен, щоб однозначно ідентифікувати назву теми?

SubjectName залежить лише від SubjectCode - підмножини ключа-кандидата. Тож цей кортеж не в 2nf. SubjectCode повинен бути первинним ключем таблиці предметів, щоб це місце було правильним для розміщення SubjectName. Видаліть його з цього кортежу, і він зараз знаходиться в 2nf.

Якщо ми задаємо питання атрибуту, а відповідь - не все або частина ключа-кандидата, то кортеж не в 3nf. Але цей кортеж також тривіально в 3nf і далі, оскільки у нас не вистачає полів, щоб задати питання. ;)

Примітка: коли ми кажемо «нормалізувати», ми маємо на увазі процес, який застосовується до логічної сутності. Оскільки поданий кортеж здається визначенням сутності, яке називається "клас", то ми можемо його нормалізувати. Однак я в один момент сказав, що "цей кортеж не в 2nf", що правильніше повинно було бути, "ця сутність не в 2nf". Прошу вибачення, якщо це спричинило плутанину.

Єдиний непримітний атрибут (Оцінка) не залежить від частини ключа-кандидата, тому ця таблиця здається в 2NF.

Це в 2NF.

Проблема в тому, що я думаю, що щось не так (і я можу помилитися). Я думаю, що предмети повинні мати власну таблицю.

Немає підстав очікувати, що суб'єкти повинні мати свою власну таблицю для декомпозиції вихідної таблиці на 2NF . Ви плутаєте якесь розпливче поняття «слід» з тим, що насправді дає вам будь-яка конкретна нормальна форма.

3NF - це залежність між атрибутами, які не є простими, тому це також не створює.

"3NF - це залежність між непримітними атрибутами", це не правильне визначення 3NF, тому "так що це також не виробляє", не є надійним висновком. Хоча застосування фактичного визначення дійсно показує, що таблиця в 3NF, не потрібна таблиця студентів. Але знову ж таки, немає підстав сподіватися, що це буде.

Але мені здається, що це правильний результат, оскільки він не має надмірності.

Знову ж таки, "надмірність" виявляється нечітко розпливчастою, тому очікування вашого "тому" та студентського столу є неправдивим. Різні нормальні форми не містять особливих видів аномалій і пов'язані з ними "надмірністю". Але інші «надмірності», не врегульовані нормалізацією, можуть залишатися.

Ця таблиця відсутня в BCNF, оскільки вона має FD, які не виходять із CK. Розкладання його за BCNF призводить до того, щоб мати студентський стіл. BCNF - це найвища нормальна форма для роботи з JD (приєднатися до залежностей), які супроводжують FD. Однак інші СД можуть бути проблематичними (тобто не "маються на увазі СК") і повинні бути усунені шляхом нормалізації до 5NF.

PS Оригінальна таблиця також задовольняє FD {StudentName, SubjectName, #Exam} -> Оцінка.

Залежності такі:

Що це повинно означати? Незрозуміло.

Ви маєте на увазі: "Це всі нетривіальні ФД, які є"? Ні, тому що вони мають на увазі четверте. "Ось кілька FD, які зберігаються"? Ні, це означає, що FD в транзитивному режимі закриття утримується, але це не говорить про те, що інші не мають права, але ви змогли визначити CK. "FD, які утримуються, - це саме ті, що перебувають у транзитивному закритті"? Якби ви це мали на увазі , ви знали б це тільки якби ви це показали , тобто вам довелося б виявити це закриття (як правило, через мінімальний / канонічний обкладинка), а потім показали б, що немає інших FD; ти? Незалежно від того, що ви просто написали, це не означає. Тож я очікую, що ви не обгрунтовано міркуєте про ситуацію з FD & CK.

Ви праві, предметам потрібна своя таблиця. Якщо ви виберете один із ключів свого кандидата, він subject_codeабо subject_nameстає основним ключем кандидата. Потім ви видаляєте поле не первинних предметів із таблиці оцінок.

Ви маєте функціональну залежність від теми, для якої у вас є два унікальних ідентифікатори. Це демонструється перехідною залежністю між subject_codeта subject_name. Це вказує на вимогу створити таблицю, що містить ці два поля, і видалити одне з цих полів з усіх інших таблиць. Ця таблиця цілком може мати додаткові залежні стовпці, хоча я не бачу жодного в цьому прикладі. У 3-й звичайній формі ви обрали.

оцінка залежить від інших трьох полів (кандидатський ключ) у новій таблиці оцінок. Як зазначалося вище, вам потрібно вибрати одне з кандидатських полів для таблиці предметів. Зазвичай це буде значення коду, якщо воно є, оскільки вони, як правило, більш стабільні. Отримана модель знаходиться в 3nf, оскільки всі не-ключові поля повністю залежать від полів у первинному ключі.

Подальший аналіз проблеми (вимог), ймовірно, дасть таблицю сеансів, проти якої застосовуються позначки. Поточна модель навряд чи охопить студента, який повторює курс. Це буде висвітлено у подальшому уроці.

Студенти також, ймовірно, стануть окремою таблицею, оскільки можливо мати кілька учнів з однаковою назвою. Це, ймовірно, буде вирішено додаванням синтетичного первинного ключа (номер студента?).

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

Я готуюсь видалити це, оскільки це вважається неправильним

Назва предмета також є атрибутом, що не є простим, і це залежить від частини первинного ключа Тема коду (правило перерви - не повинно бути часткової залежності жодного стовпця від первинного ключа).

Це заборонено у 2-й звичайній формі, і, якщо ви підозрюєте, розміщуйте його у власній таблиці.

Я думаю, де ви відклеїлися, це виявлення двох наборів ключів-кандидатів, коли ви створюєте таблицю, ви повинні вибрати один набір ключів-кандидатів, щоб зробити первинний ключ. Решта стовпців стають атрибутами, які не є простими, тобто, якщо ви вибрали свій другий ключ-кандидат, Код предмета стає неатрибутивним атрибутом, залежним від частини первинного ключа (Назва теми), і його слід розмістити у власній таблиці.

Важливо навчати 1-й, 2-й та 3-й нормальні форми для того, щоб вони будувались один на одному. BCNF також по суті є продовженням до 3-ї нормальної форми, тому важливе сильне розуміння на нижчих рівнях.

Далі; досвідчений розробник не буде враховувати незалежні рівні нормалізації, оскільки багато правил стають інтуїтивними.

Вони також будуть знати, коли порушувати норми нормування для вирішення певних проблем проектування та оптимізації. Нормалізація повинна трактуватися як настанова щодо гарного дизайну, а не суворе правило, я вважаю, що це також буде хорошим навчальним моментом.