Решение о проектировании базы данных, переводящее требования в реляционные модели

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

  1. Учебное заведение предлагает несколько курсов.

  2. Курсы имеют название и описание.

  3. Курсы организованы по уровням. На каждом уровне есть несколько курсов.

  4. У курсов также есть требования (т. е. другие курсы, которые необходимо пройти в первую очередь).

  5. Студент завершает уровень, когда он прошел все курсы этого уровня.

  6. Если студент не может пройти курс, он может повторять его столько раз, сколько хочет/необходимо.

  7. Студенты могут пройти только один курс в семестр.

  8. Неактивный студент — это тот, кто не зачислен в текущем семестре.

  9. Учителя будут преподавать только один курс в семестр. Учителя могут преподавать разные курсы каждый семестр.

  10. Могут быть семестры, которые учитель не преподает.

Теперь это моя реляционная модель.

![https://dl.dropbox.com/u/10900918/rmodels.jpg][1]

Мои вопросы:

  1. Столов не хватает?

  2. Глядя на semester + semester_code_description: это лучший способ сделать это? Если предположить, что в году 2 семестра и что каждый семестр имеет одинаковые месяцы начала и окончания (например, семестр 1: август — декабрь, семестр 2: январь — май), действительно ли необходима таблица semester_code_description?

  3. Как я могу улучшить дизайн?

Извините, я не добавил стрелок. Программа, которую я использую, беспорядок.

Большое спасибо за ваше драгоценное время заранее.


database relational models
person ecr    schedule 19.12.2012    source источник
comment
Это домашнее задание?   -  person Ciarán    schedule 19.12.2012
comment
Нет. Это волонтерская работа в образовательном служении церкви, которую я посещаю. У них есть карточка с информацией о каждом ученике. Каждый семестр они должны обновлять каждую карточку вручную. Они просто хотели оцифровать процесс, чтобы сэкономить место для архивирования и бумагу.   -  person ecr    schedule 19.12.2012

Ответы (1)


arrow_upward
0
arrow_downward

1) Хорошая работа над вашим дизайном. Я не вижу отсутствующих таблиц — похоже, вы выполнили все свои требования.

2) Таблица semester_description имеет для меня смысл, нужна она вам или нет, зависит от того, планируете ли вы что-то делать с этими данными.

3) Требование «студенты могут проходить только один курс в семестр» подразумевает, что первичный ключ отношения Has_Taken должен быть (student_id, semester_id). В нынешнем виде я мог бы вставить два разных курса для одного и того же студента и семестра. Аналогично для отношения Has_Teached.

Некоторые другие мысли:

Столбцы «last_whatever» в некоторых ваших таблицах вызовут дополнительную обработку вашего фактического приложения. Вам понадобится какой-то механизм для их мониторинга/обновления. Другим вариантом было бы получить их из ваших таблиц. Я могу получить last_semester студента, найдя семестр с максимальным годом/кодом.

И последнее соображение: насколько стабильны эти курсы/описания/уровни? Я работал в университете в течение нескольких лет, и наши курсы менялись в течение семестра, что вынуждало нас сохранять полную копию записей курса для каждого изменения, потому что мы хотим, чтобы запись студента отражала то, что он фактически изучил в то время.

Вот небольшой пример в вашем приложении. Допустим, я закончил уровень 1. Затем, через год, церковь добавляет новый курс (Курс А) к уровню 1. Я фактически не закончу обучение, потому что теперь есть курсы уровня 1, которых у меня нет (Курс А). ).

Это может не иметь значения для вас, если ваши курсы довольно стабильны. Удачи!

person jeff    schedule 20.12.2012