Каков наилучший дизайн базы данных для хранения нескольких объектов?

Question

Недавно я работаю над проектом, в котором мне нужно сохранить несколько объектов в моей базе данных, а количество предметов будет изменяться в соответствии с классом ученика. например: класс «VII» имеет 6 предметов (включенных 1 вариант предмета), класс «VIII» состоит из 8 предметов (1 включен вариант предмета) и т. д. Даже субъект выбора может отличаться в зависимости от выбора ученика.

Я использую контроль CheckedListBox. Вот скриншот.

Я использую MS SQL Server 2012 я столкнулся с трудностями, чтобы проектировать таблицу базы данных. Я не могу понять, должен ли я создавать все столбцы темы в моей студенческой таблице или ???? (наилучшим образом). Пожалуйста, помогите мне, спасибо заранее.

Answer 1

То, что вы описываете, является тем, что называется отношением от многих до многих. У многих классов есть много учеников.

У вас будет таблица учеников, таблица предметов, а затем таблица table_subject таблицы, которая связывает как первичные ключи студентов, так и таблицу предметов.

Reference: Many to Many

Answer 2

Если Student может иметь несколько Subjects, иSubject может иметь несколько Students, то это многие-ко-многим. Это означает, что для их связывания должна быть промежуточная таблица.

Пуска с таблицами для самих объектов:

Student 
---------- 
ID 
Name 
etc. 

и

Subject 
---------- 
ID 
Name 
etc. 

Поскольку эти независимые агрегатные объекты корня в домене, и ни один не владеет другими, их таблицы просто содержат информацию, которая описывает этот объект. Например, A Subject может иметь имя и описание, возможно, список предварительных условий и т. Д.

Затем вы создаете таблицу взаимосвязей между ними. Обычной практикой является просто объединить имена:

StudentSubject 
---------- 
StudentID 
SubjectID 

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

В своей простейшей ситуации вся эта таблица создает отношения между записями в основных таблицах. Тем не менее, это может потенциально стать субъектом домена сам по себе. Если есть какие-либо атрибуты, которые описывают связь между Student и Subject, они будут добавлены в эту таблицу.

Answer 3

Ваша схема базы данных должна выглядеть примерно так ...

Студенты
student_id (PK)
Student_Name
и т.д .......

Тема
subject_id (PK)
Плата
и т.д ..... .

Student_Subjects
student_id FK Студенты (student_id)
subject_id FK Subject (subject_id)
DateStarted и т.д .....