Проектные предложения для учителей, предметы и база данных классов
Как часть задачи проектирования базы данных для средней школы, я как бы застрял с таблицей классов. Таблицы, созданные на данный момент:
Students
--------------
Id
name
Grades (grade 1,2,....9,10)
------------------
id
description
term
Subjects (science,maths...)
-------------------
id
name
grade_subject (subjects tought in grades)
----------------
id
grade_id
subject_id
teacher
---------------------
id
name
teacher_subject (teachers who are assigned to teach subjects in particular grade)
---------------------
id
teacher_id
grade_subject_id
Я не уверен в дизайне таблицы таблицы teacher_subject. Эта таблица использует идентификатор grade_subject_id, который может (не) быть хорошим дизайном. Должны ли в этой таблице два FK, один grade_id и subject_id?
Кроме того, мне также необходимо хранить количество уроков, проводимых по конкретному предмету и классу конкретным назначенным учителем.
Подойдет ли эта таблица в этом случае:
Class (stores daily teaching schedule)
-----------------------------------
id
*teacher_id
grade_id
subject_id*
*or only teacher_subject_id from teacher_subject table*
date
start_time
end_time
status ( conducted/cancelled/postponed)+
И, наконец, таблица для хранения информации о том, кто посещал занятия
attandants
--------------------
student_id
class_id
Любые предложения будут с благодарностью.
2 ответа
Моделирование данных - это искусство представления реального мира в диаграмме отношений. Ваш режим правильный, но так ли это?
Считайте, что такое КЛАСС? Это УЧИТЕЛЬ, ПРЕДМЕТ и СОРТ. Это ваши отношения. Кроме того, вы хотите обеспечить соблюдение правил, которые ПРЕДМЕТ подходит для этой СОРТЫ и чтобы УЧИТЕЛЬ мог обучать этому СУБЪЕКТУ в этой СОРТЕ.
Я думаю, что ваша проблема заключается в использовании суррогатных ключей в таблицах пересечений. Это таблицы, которые представляют ваши отношения "многие ко многим": teacher_subject, grade_subject, В любом случае это синтетические таблицы, и в любом случае они состоят только из ключей. Следовательно, достаточно составного первичного ключа.
Суррогатные первичные ключи не имеют смысла, поэтому нам нужно определить уникальное ограничение для grade_subject(subject_id, grade_id) чтобы убедиться, что у нас нет двух записей для ('PHYSICS', 'YEAR 2'). При условии grade_subject таблица пересечений без других столбцов, добавление суррогатного ключа не имеет смысла. Ценность суррогатных ключей заключается в том, чтобы минимизировать влияние изменения бизнес-ключа. Но grade_subject не имеет бизнес-ключа, только два суррогатных ключа, subject_id а также grade_id,
Это имеет преимущество, когда дело доходит до определения ссылочной целостности.
Поэтому я бы подошел к вашей проблеме следующим образом:
grade_subject
----------------
grade_id
subject_id
primary key (grade_id, subject_id)
foreign key (grade_id) reference grade (grade_id)
foreign key (subject_id) reference subject (subject_id)
teacher_subject
---------------------
teacher_id
grade_id
subject_id
primary key (teacher_id,grade_id, subject_id)
foreign key (grade_id) reference grade (grade_id)
foreign key (subject_id) reference subject (subject_id)
foreign key (teacher_id) reference teacher (teacher_id)
foreign key (grade_id,subject_id) reference grade_subject (grade_id,subject_id)
Class
-----------------------------------
id
teacher_id
grade_id
subject_id
primary key (id)
foreign key (grade_id) reference grade (grade_id)
foreign key (subject_id) reference subject (subject_id)
foreign key (teacher_id) reference teacher (teacher_id)
foreign key (grade_id,subject_id) reference grade_subject (grade_id,subject_id)
foreign key (teacher_id,grade_id,subject_id) reference teacher_subject (teacher_id,grade_id,subject_id)
Это может выглядеть как куча внешних ключей, и я могу представить некоторые аргументы на этапе проверки. (Я включаю внешний ключ на grade_subject так что мне есть что уступать, что меня не волнует так много, и поэтому я могу уступить).
Но мне не нравится, когда важные отношения с данными, такие как CLASS_SUBJECT, скрываются за счет применения через вспомогательные отношения, такие как TEACHER_SUBJECT. Я не хочу присоединяться к TEACHER_SUBJECT и SUBJECT_GRADE, чтобы присоединиться к CLASS к SUBJECT.
Теперь, почему я выбираю включение ограничений ссылочной целостности для таблиц с одним родителем и таблицы пересечений, когда последняя косвенно обеспечивает выполнение первой? Потому что это делает отношения более четкими в модели. Я подчеркиваю в модели, потому что в физической базе данных я мог бы опустить внешние ключи одной таблицы или отключить их и доверять реляционной целостности таблицы пересечений.
Что-то в трехкомпонентном композите меня беспокоит, и я думаю, что это так: оно недостаточно нормализовано. У вас может быть особый случай, но более общей моделью будут два правила: TEACHER_SUBJECT и TEACHER_GRADE. Это будет выглядеть так
teacher_subject
---------------------
teacher_id
subject_id
primary key (teacher_id, subject_id)
foreign key (subject_id) reference subject (subject_id)
foreign keye (teacher_id) reference teacher (teacher_id)
teacher_grade
---------------------
teacher_id
grade_id
primary key (teacher_id,grade_id)
foreign key (grade_id) reference grade (grade_id)
foreign key (teacher_id) reference teacher (teacher_id)
Class
-----------------------------------
id
teacher_id
grade_id
subject_id
primary key (id)
foreign key (grade_id) reference grade (grade_id)
foreign key (subject_id) reference subject (subject_id)
foreign key (teacher_id) reference teacher (teacher_id)
foreign key (grade_id,subject_id) reference grade_subject (grade_id,subject_id)
foreign key (teacher_id,subject_id) reference teacher_subject (teacher_id,subject_id)
foreign key (teacher_id,grade_id) reference teacher_grade (teacher_id,grade_id)
Конечно, если вы все еще хотите применить правило, согласно которому мистер Друри может обучать математике только четвертых и физиков шестым, вам понадобится таблица TEACHER_SUBJECT_GRADE.
Одна вещь, которую ваша модель данных не решает, это проблема планирования. Школьные расписания должны быть в сетке, поэтому классы должны вписываться в заранее определенную сетку. Возможно, вам нужно определить временные интервалы расписания как отдельную таблицу и связать с ней класс CLASS. Классы также нуждаются в классах. Это еще один стол.
Эта модель типична для разработчиков баз данных, когда они начинают изучать, как создавать реляционные модели. Загляните на этот сайт, он содержит множество образцов и некоторые из них применимы к проблеме, которую вы пытаетесь решить.
http://www.databaseanswers.org/data_models/
Проверьте раздел 218 Образование