If you really are going to support complex schedules of all those types, I am not sure it is a good idea to try to invent an equally complex relational DB schema for all the details of those schedules.
I would consider designing an XML schema for schedules' details and, if you really need to store schedules in a relational database, storing the XML data in a column. You could use columns for those attributes of schedules that are applicable to a schedule of any type (like schedule name or who modified it last time and when).
For example, assuming that a schedule can be used for more than one report, you could do something like this:
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).
Even if your application has to answer questions like "what reports are supposed to be due by a given date/time", I think you must have really, really large number of schedules to justify the overhead of using relational schema to store nitty-gritty schedule details in separate columns (and, perhaps, in multiple tables).