дизайн реляционной базы данных (нормализация сопоставлений «многие ко многим»)

Вариант 3)

students table - (student_id, student_name)
classes table - (class_id, class_name)
students_classes table - (student_class_id, student_id, class_id, grade)

Оценка является атрибутом студенческого класса.

Если только у Grade нет возможности стать полноценной сущностью. В таком случае:

Вариант 4)

students table - (student_id, student_name)
classes table - (class_id, class_name)
students_classes table - (student_class_id, student_id, class_id)
grades table - (grade_id, grade, student_class_id)

Я бы выбрал вариант 2 лично. Нет ничего плохого в составном первичном ключе для оценок, и он фиксирует необходимую информацию в вашей модели данных.

В варианте 1 student_classes не служит никакой цели, кроме как иметь суррогатный ключ.

Изменить, увидев другие ответы:

• 2NF: оценка (неключевая) зависит исключительно от учащегося/класса (ключевая)
• 3NF: не применяется. У вас нет неключевых на неключевых зависимостях
• BCNF: не применяется, у вас есть только один ключ-кандидат

Вариант 2 правильный, за исключением того, что он должен называться student_class, отражая его функцию n::n или Enrollment как сущность. и (student_id, class_id)является ПК.

Оценка (как вы это показали) является зависимостью 1::1 от этого составного ключа (не от того или иного элемента) и ни от чего другого, поэтому она является атрибутом student_class.

И поэтомуstudent_classнаходится в 3НФ.

Если бы люди не начали слепо прикреплять столбцы Idiot ко всему, что движется, как вы сделали с Вариантом 1, они смогли бы лучше понимать данные и, таким образом, лучше нормализовать их. Это (столбец Idiot в Варианте 1 в качестве отправной точки) мешало вашей интуиции, что (student_id, class_id) был Идентификатором; не было необходимости в дополнительном столбце Idiot с его дополнительным индексом. Затем, когда вы приступили к оценкеgrade, его зависимость от этого PK очевидна.

Столбцы Idiot наносят ущерб реляционным возможностям базы данных. Если у вас, скажем, три таблицы в иерархии, и вам нужно получить несколько столбцов из верхней и нижней таблиц, вам придется пройти через среднюю таблицу. Если бы у вас были реляционные идентификаторы, вместо столбцов Idiot вы попадали бы из нижней таблицы в верхнюю таблицу с необходимостью чтения средней таблицы.

То, что в «нормализованной» базе данных так много соединений, верно только наполовину. Полная правда в том, что поскольку база данных не нормализована правильно, да, вы вынуждены выполнять намного больше соединений, чем необходимо. В действительно нормализованной базе данных с теми же таблицами код требует гораздо меньше объединений.

Вот >Модель данных для колледжа‹< /strong> из недавнего задания, упрощенная версия.