Если вы действительно собираетесь поддерживать сложные расписания всех этих типов, я не уверен, что будет хорошей идеей попытаться изобрести одинаково сложную схему реляционных БД для всех деталей этих расписаний.
Я хотел бы рассмотреть вопрос о разработке схемы XML для деталей расписаний и, если вам действительно нужно хранить расписания в реляционной базе данных, хранить данные XML в столбце. Вы можете использовать столбцы для тех атрибутов расписаний, которые применимы к расписанию любого типа (например, имя расписания или кто изменил его в последний раз и когда).
Например, предполагая, что расписание может использоваться для более чем одного отчета, вы можете сделать что-то вроде этого:
Table: Schedule
---------------
Columns:
ID - Surrogate key to refer to schedules
from other tables.
Name - Short textual description of the schedule
(to be shown in GUI).
...
Details - XML containing all the details of
the schedule (frequency, exceptions,
complex combinations of simple schedules,
whatsoever).
Даже если ваше приложение должно отвечать на такие вопросы, как «какие отчеты должны быть представлены к определенной дате / времени», я думаю, у вас должно быть действительно очень большое количество расписаний, чтобы оправдать накладные расходы на использование реляционной схемы для хранения подробные сведения о расписании в отдельных столбцах (и, возможно, в нескольких таблицах).