Как реализовать графики, связанные с бизнесом, в реляционных базах данных (например, графики сотрудников, назначения, курсы и т. Д.)

Question

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

Часть, в которой я не уверен, состоит в том, как изменить количество дней в разных расписаниях.Я понимаю, что это отношения один ко многим;однако я не уверен, как мне настроить его в этом сценарии.А как насчет високосного года?

Мой подход заключается в создании таблицы месяца / дня, таблицы года и таблицы сроков с внешними ключами в таблице расписания.Чтобы обратиться к високосному году, я бы просто сделал таблицу месяца / дня 366 дней.Я не уверен, что эта идея излишня, я ищу самое элегантное решение для обработки любых практических изменений в расписании.

Я прошу прощения, если я далеко, я пытался научитьЯ сам занимаюсь разработкой реляционных баз данных, но я только начинаю.

I would like the schedule to output partly like this:

Example Class A Schedule:
01/02/2011 1:00pm-3:00pm
01/03/2011 2:00pm-4:00pm
01/04/2011 1:00pm-3:00pm
01/05/2011 2:00pm-5:00pm
01/08/2011 1:00pm-4:00pm

Example Class B Schedule:
01/02/2011 1:00pm-3:00pm
01/03/2011 2:00pm-4:00pm

Answer 1

Вот некоторые из бизнес-правил;они похожи на колледж:

• Расписание занятий не должно ограничиваться каким-либо шаблоном
• Расписания классов должны хранить каждую дату и время проведения занятий
• Расписание занятий должно включать время начала и окончания
• Классы могут или не могут быть связаны с термином
• Расписания могут создаваться и храниться в базе данных задолго до того, как класс будет предложен
• Учащиеся должны иметь возможность просматривать расписание предлагаемых занятий
• Учащиеся должны иметь возможность доступа к расписанию для классов, на которые они зарегистрированы

Answer 2

Я придумал дизайн, основанный на том, что вы упомянули, я включил его ниже.

* Primary Key
~ Foreign Key

Classes_Table
*ClassID
 ClassName
 ClassNumber
~ScheduleID

Schedules_Table
*ScheduleID
~ClassID

Class_Schedule_Table (There Would Be Many Of These Tables, 1 For Each ScheduleID)
*DayID
 Date
 StartTime
 EndTime
~TermID
~ClassID
~ScheduleID

Terms_Table
*TermID
 TermName

Students_Table
*StudentID
 StudentName

Student_Schedules_Table
*RegistrationID
~StudentID
~ClassID
~ScheduleID

Answer 3

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

Если ваше расписание основано на чередующемся расписании произвольного числа дней, например, «День 1» - «День 6» и т. П., То это заслуживает отдельной таблицы, тогда вхождения классов становятся пересечением между день ротации и занятия. Каждое пересечение будет иметь дату и время, а также внешние ключи к классу и дню ротации.

В зависимости от ваших бизнес-правил Условия могут подключаться либо над классом, либо над произвольным дневным графиком. Таблица терминов, вероятно, должна в любом случае включать даты начала и окончания.

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

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