У меня проблема со второй нормальной формой (2NF), и я не смог ее решить с помощью Google. Это сводит меня с ума, потому что я учитель, и я не хочу преподавать неправильные вещи своим ученикам.

Давайте иметь таблицу с 5 полями.

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

Зависимости таковы:

StudentName, SubjectCode, #Exam -> Grade

SubjectCode -> SubjectName

SubjectName -> SubjectCode

Следовательно, ключ-кандидат 1 - {StudentName, SubjectCode, #Exam}, а ключ-кандидат 2 - {StudentName, SubjectName, #Exam} .

Основные атрибуты: {StudentName, SubjectCode, SubjectName, #Exam}, а непростые атрибуты - Grade

Согласно определению второй нормальной формы, непростой атрибут не может зависеть от части ключа-кандидата. Единственный непростой атрибут (Grade) не зависит от части ключа-кандидата, поэтому эта таблица отображается в 2NF.

Проблема в том, что я думаю, что что-то не так (и я могу ошибаться). Я думаю, что предметы должны иметь свой собственный стол.

Оценки = {StudentName, Subject Code, #Exam, Grade}

Subjects = {Subject Code, SubjectName}

Но 2NF не производит это. 3NF - это зависимости между непростыми атрибутами, поэтому он также не производит этого. Но мне кажется, что это правильный результат, потому что он не имеет избыточности.

Я предполагаю, что если бы не простой атрибут был определен как «атрибут, который не является ключом-кандидатом», 2NF привел бы к желаемому результату. Но я проверял это снова и снова, и непростой атрибут определяется как «атрибут, который НЕ ПОДЛЕЖИТ ключу-кандидату».

Что я делаю неправильно?

Ваше отношение находится в 3NF (и не только в 2NF), поскольку, как вы говорите, единственный не главный атрибут - это Grade , который появляется только с правой стороны ваших FD.

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

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

Эта декомпозиция дает вам два отношения BCNF и сохраняет все функциональные зависимости. Это не всегда возможно (вы всегда можете разложить отношение к 3NF, но не обязательно к BCNF).

2НФ

Если вам нужен пример 2NF (а не 3NF), ваше отношение должно содержать транзитивные зависимости.

Например, скажем, у вас есть столбец Оценка. Оценка интуитивно -> Оценка, поскольку все экзамены с одинаковым баллом должны получить одинаковую оценку (в противном случае это было бы довольно несправедливо), но учтите, что мы не можем сказать, что Оценка -> Оценка, поскольку несколько баллов могут иметь одинаковую оценку (11% и 12% вероятно, будет "Fail", например).

Теперь ваше отношение:

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

и у вас есть новая форма избыточности, поскольку каждый раз, когда вы вводите результат с таким же счетом, что и у другой записи оценок, вы также должны повторять соответствующую оценку. Поэтому, чтобы попасть в 3NF, вы можете разложить на

ScoreGrades ( Оценка, Оценка )

с баллом в качестве ключа, и

Результаты ( StudentName, SubjectCode, SubjectName, #Exam, Score )

Вы правы во всем, что вы говорите. Subject Code, SubjectName должны идти в своей собственной таблице для обеспечения желаемых зависимостей. Это хороший пример того, почему 2NF и 3NF недостаточно для создания хороших проектов баз данных - вместо этого вам нужна нормальная форма Бойса Кодда (BCNF).

2NF и 3NF заменены BCNF, что фактически делает эти малые NFs устаревшими *. BCNF является более важным и, возможно, более простым для объяснения и применения. Как учитель, я предлагаю вам больше времени проводить на BCNF и меньше на 2NF и 3NF. Если таблица удовлетворяет требованиям BCNF, то она также удовлетворяет 2NF и 3NF.

* 3NF не является самой нормальной сохраняющей зависимость нормальной формой. Элементарный ключ Нормальной формы (EKNF) есть. Строго говоря, именно EKNF, а не BCNF, делает 3NF устаревшим, но EKNF несправедливо пренебрегают, и большинство учебников и курсов даже не упоминают об этом. То же самое, что спроектировать для BCNF и затем проверить, что все требуемые зависимости и любые другие правила целостности могут быть должным образом обеспечены - если нет, то измените дизайн. Ни одна из NF не является полным решением для целостности данных, но BCNF обычно подходит ближе всего и проще всего объяснить и использовать.

Я не буду говорить, сколько времени прошло с тех пор, как я впервые все это узнал. Но я помню, что у меня был профессор, который, послушно научив нас правильному значению «функциональная зависимость» и «непростой атрибут» и все другие модные слова, дал нам ряд простых вопросов, чтобы узнать, является ли конкретный нормальный Форма была достигнута. Посмотрим, смогу ли я вспомнить это далеко назад ...

Мы определили ключи-кандидаты, поэтому задаем этот вопрос об остальных непростых атрибутах. В этом случае есть только один: оценка.

Какая абсолютная минимальная информация нам нужна, чтобы однозначно определить оценку? Нам нужно знать студента, предмет и экзамен. Хорошо, это один из ключей-кандидатов.

РЕДАКТИРОВАТЬ: ВВВ

Но ответом могли быть также имя студента, название предмета и экзамен. Это будет соответствовать ключу второго кандидата.

Предполагая, что SubjectCode и SubjectName являются ключами-кандидатами для субъекта Subject, нет никаких причин иметь здесь оба этих поля. Одной уникальной ссылки на строку в таблице Subjects вполне достаточно. Таким образом, мы можем безопасно избавиться от поля SubjectName, не жертвуя при этом целостностью модели.

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

Но вместо того, чтобы убрать эту часть ответа, я оставлю ее для сравнения.

КОНЕЦ РЕДАКТИРОВАНИЯ: ^ ^ ^

Какой абсолютный минимум информации нам нужен, чтобы однозначно идентифицировать имя субъекта?

SubjectName зависит только от SubjectCode - подмножества ключа-кандидата. Так что этот кортеж не в 2nf. SubjectCode должен быть первичным ключом таблицы Subjects, чтобы он был правильным местом для размещения SubjectName. Удалите его из этого кортежа, и теперь он в 2nf.

Если мы задаем вопрос об атрибуте, а ответом является не весь ключ ключа или его часть, тогда кортеж не находится в 3nf. Но этот кортеж также тривиально в 3nf и выше, так как у нас закончились поля, чтобы задавать вопросы. ;)

Примечание: когда мы говорим «нормализовать», мы имеем в виду процесс, который применяется к логической сущности. Поскольку поставляемый кортеж, по-видимому, является определением сущности под названием «оценка», мы можем его нормализовать. Однако в какой-то момент я сказал, что «этот кортеж не в 2nf», что более правильно было бы, «этот объект не в 2nf». Я прошу прощения, если это вызвало путаницу.

Единственный непростой атрибут (Grade) не зависит от части ключа-кандидата, поэтому эта таблица отображается в 2NF.

Это в 2NF.

Проблема в том, что я думаю, что что-то не так (и я могу ошибаться). Я думаю, что предметы должны иметь свой собственный стол.

Нет никаких оснований ожидать, что у субъектов должна быть своя собственная таблица для разложения исходной таблицы до 2NF . Вы путаете какое-то смутное понятие «должен» с тем, что на самом деле дает вам любая нормальная форма.

3NF - это зависимости между непростыми атрибутами, поэтому он также не производит этого.

«3NF относится к зависимостям между непростыми атрибутами» - это не правильное определение 3NF, поэтому «так что это тоже не дает» не является обоснованным выводом. Хотя применение фактического определения действительно показывает, что таблица в 3NF, без необходимости таблицы ученика. Но опять же, нет никаких оснований ожидать, что так и будет.

Но мне кажется, что это правильный результат, потому что он не имеет избыточности.

Опять же, «избыточность» бесполезно расплывчата, поэтому ваше «потому что» и ожидание ученика несостоятельны. Различные нормальные формы свободны и подвержены определенным видам аномалий и связанной с ними «избыточности». Но может остаться другая «избыточность», не учитываемая нормализацией.

Эта таблица отсутствует в BCNF, поскольку в ней есть FD, которые не выходят из CK. Разложение его на BCNF приводит к созданию студенческого стола. BCNF - это высшая нормальная форма для работы с JD (зависимостями соединения), которые сопровождают FD. Однако другие JD могут быть проблематичными (т.е. не «подразумеваемыми CK») и должны быть удалены путем нормализации до 5NF.

PS Исходная таблица также удовлетворяет FD {StudentName, SubjectName, #Exam} -> Grade.

Зависимости таковы:

Что это должно означать? Это не ясно.

Вы имеете в виду: «Это все нетривиальные FD, которые держат»? Нет, потому что они подразумевают четвертый. «Вот некоторые ФД, которые держат»? Нет, это означает, что FD в транзитивном замыкании удерживаются, но это не говорит о том, что другие не держатся, но вы смогли определить CK. «ФД, которые держат, являются именно теми, кто находится в транзитивном закрытии этих»? Если бы вы имели это в виду , вы бы знали об этом только в том случае, если бы показали его, т. Е. Вам нужно было бы найти это замыкание (обычно с помощью минимального / канонического покрытия), а затем показать, что других FD нет; ты? Независимо от того, что вы написали, просто это не значит. Поэтому я ожидаю, что вы не рассуждаете обоснованно о ситуации с FD & CK.

Вы правы, предметам нужна своя таблица. Если выбрать один из ключей - кандидатов, либо subject_codeили subject_nameстановится неосновным ключевым кандидатом. Затем вы удаляете поле неосновных предметов из таблицы оценок.

У вас есть функциональная зависимость от предмета, для которой у вас есть два уникальных идентификатора. Это демонстрируется переходной зависимостью между subject_codeи subject_name. Это указывает на необходимость создания таблицы, содержащей эти два поля, и удаления одного из этих полей из всех других таблиц. Эта таблица вполне может иметь дополнительные зависимые столбцы, хотя я не вижу ни одного в этом примере. В 3-й нормальной форме вы выбрали.

Оценка зависит от трех других полей (ключ кандидата) в новой таблице оценок. Как отмечено выше, вам нужно выбрать одно из полей-кандидатов для таблицы предметов. Обычно это будет кодовое значение, если оно доступно, поскольку они имеют тенденцию быть более стабильными. Полученная модель имеет значение 3nf, поскольку все неключевые поля полностью зависят от полей в первичном ключе.

Дальнейший анализ проблемы (требований), скорее всего, приведет к созданию таблицы сессий, по которой применяются оценки. Нынешняя модель вряд ли охватит студента, повторяющего курс. Это будет рассмотрено в следующем уроке.

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

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

Я готовлюсь удалить это, поскольку это считается неправильным

Имя субъекта также является непростым атрибутом и зависит от части предметного кода первичного ключа (нарушает правило - не должно быть частичной зависимости какого-либо столбца от первичного ключа).

Это запрещено во 2-й нормальной форме и должно быть помещено в ее собственную таблицу, как вы и предполагали.

Я думаю, что вы открепились в идентификации двух наборов ключей-кандидатов, когда вы создаете таблицу, вы должны выбрать один набор ключей-кандидатов, чтобы сделать первичный ключ. Остальные столбцы становятся непростыми атрибутами, т. Е. Если вы выбрали второй ключ-кандидат, Subject Code становится непростым атрибутом, зависящим от части первичного ключа (имени субъекта), и его следует поместить в свою собственную таблицу.

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

В дальнейшем; опытный разработчик не будет рассматривать независимые уровни нормализации, потому что многие правила становятся интуитивными.

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