Эх, назвался груздем – лезу… То есть садюсь умничать.
И, хотя «базенку» не выложу – по причине полной моей недееспособности на сей предмет – не умею, я словей вместо этого напишу… С постраничной выдачей. С разложением, слегка отличающимся от дневного (в сторону упрощения, определяемого характером задачи).


вот пару только предварительных наблюдений
1)
автор
как проверять - десятый вопрос


Мда… И это говорит поборник нормализации и защитник Кодда…
А ЗАЧЕМ тогда про реляционные связи?


2)
автордискретность все равно останется по общему делителю - минуте
мне лично поразительно было бы самому читать все что дальше будет написано. Поскольку в цитированной фразе сказано ВСЕ., что дальше проистечет на нескольких страницах.
Позволю же все-таки "вывалить" нижеследующее по двум причинам
1) Санычу обещал, что спою.
2) Не всякий "автор" понимает насколько велик. У меня во всяком случае не сложилось ясного представления, что автор вышецитированнолй гениальной фрази кристально-отчетливо понимает смысл им же самим сазанного.
(Пардон - все дальнейшее почти исключительно из графоманских побуждений)

----------------

Начнем, покурив и оправившись.
По возможности будем следовать разложению от YBW, с необходимыми упрощениями и исправлениями.
Денормализации в этой задаче (мне) не избежать. Здесь это будет не столько метод ускорения поиска/сокращения объема хранилища, сколько метод упрощения пользовательского интерфейса в «духе Акцесс». Первая денормализация достается по наследству – «справочника» «предметов занятий помещения», следуя образцу, не заводим, считая причину занятия помещения «неклассифицированным строковым доменом». Простых справочника остается два - tblGroup, в котором кроме id нас ничего интересовать не будет, и tblLocation, в котором тоже есть id.

Можно переходить к расписанию – tblSchedule.
В нем определенно есть:
- id – в терминологии YBW – идентификатор события (расписания)
- groupID – идентификатор группы – вписан сюда по причине, которая будет прояснена ниже (возможно неявно).

Ну а дальше? Кто чего нарисует? LocationID – идентификатор помещения - будем сюда вписывать или нет?.
Прежде чем дать свой ответ, сделаю большое отступление.
Поговорим о пресловутом времени.
Атрибутный домен, в том числе «время» в «sql-базах» определяется как множество, на котором, как правило, определено отношение порядка: ([«Иванов» < «Ивановский»] - (с) Саныч) и отношение равенства («Иванов» = «Иванов»). В этом смысле, стандартный домен образует простое (быть может - упорядоченное) множество точек. Наличие «нормализующего справочника», ограничивающего множество допустимых значений, означает еще и нумерацию – развешивание целых чисел. «Поддержка целостности через ФК и УИ» сводится к проверке наличия числа в таком «справочнике». Для реализации которой как раз достаточно определения отношений равенства и порядка. Что и позволяет им с успехом работать (уникальным индексам и внешним ключам).

В «нашей» задаче по постановке требуется на этапе ввода данных проверять «занятость» помещения. Занятость естественным образом формулируется в терминах попадания (пробного МОМЕНТА времени) в (занятый) ИНТЕРВАЛ

Время как множество точек («простой» домен datetime – определяющий множество мгновений, а не интервалов) для данного случая недостаточно, поскольку НЕОБХОДИМО определить как минимум отношение принадлежности. А, может быть, еще и операцию пересечения. То есть операции характерные для множеств а не для значений. Второе умение (определять пересечения) может быть представлено как выводимое из первого (определять попадание точки в интервал ).

Если окажется под рукой такой механизм поддержки интервалов, который позволит решить задачу «проверки» (= поддержки целостности) интервалов на включение/пересечение, с использованием стандартных механизмов уникальных индексов и внешних ключей, то это, как минимум, облегчит программирование соответствующих пользовательских интерфейсов. Позволю себе думать, что в этом заключался (сакраментальный) вопрос Саныча – «Как проверять?».
Поскольку работают желанные нам индексы и внешние ключи на «точечных» доменах, то и нашу интервальную задачу рано или поздно придется ПРИВЕСТИ к «точечному виду в множественном выражении».
Интервал (времени) – это самостоятельная сущность. В общем случае, требующая самостоятельного определения. Разнотипность (в смысле масштаба, например) наблюдаемых интервалов времени определяется разнотипностью привязанных к ним событий. Все они (наблюдаемые интервалы) наложены на физическое время.
Получаем следующий предварительный итог_1. Чтобы «заработали» средства «проверки», предоставляемые (реляционной) СУБД – интервалы надо перенумеровать. Чтобы не потерять привязку к физическому времени – его тоже ПРИДЕТСЯ перенумеровать – свести к ЦЕЛЫМ числам. При наличии разномасштабных интервалов физическое время придется квантовать величинами, не крупнее самого мелкого из интересующих интервалов. Дробление физического времени на интервалы осуществляется в календарных таблицах. Наложение логических (=событийных, =наблюдаемых) интервалов на (квантованное) физическое время осуществляется в квалендарных таблицах. Квалендарные таблицы – это таблицы, определяющие временную последовательность «проведенных наблюдений», отображающую логические интервалы наблюдений на физическое время. Дневную шутку оставляю здесь как термин, предлагая считать в рамках данного опуса составным словом - квалендарных=квази+календарных.
-))
В простых (учетных) задачах наблюдаемые интервалы а) вложенные, и, б) события , как правило, естественным образом привязываются к самому мелкому логическому интервалу. Дробление физического времени имеет соответствующий шаг. В «нашей» задаче дробить физическое время придется мельче самого мелкого логического интервала. Указанное дробление позволяет (полу)автоматически решить задачу «проверки».

Ближе к баранам.
Пусть в нашей задаче определены два типа интервалов – «стандартная пара» и «часовое занятие».( В действительности задачу катастрофически упрощает предположение о наличии по крайней мере еще одного расписания – расписания звонков, но мы не будем этого требовать). Предположим, мы хотим обеспечить ввод времени оператором с точностью до минуты и не знаем ничего, кроме того, что интервал занятости имеет тип1 (длительность в единицах использованного шага дробления физического времени (минутах) известна и является реквизитом соответствующего логического интервала) и тип2. Весь объем наблюдаемого времени укладывается в неделю, поэтому для (поминутного) квантования физического времени потребуется не более 10080 значений (= записей).
Наблюдать нам, кроме как за занятостью помещений, больше не за чем.
Поэтому сам интересующий нас логический интервал будем представлять в (единственной) (квалендарной) таблице с составным первичным ключем tblOccupation следующей структуры.

- timePoint – integer – метка деления времени. Первое поле Первичного ключа – номер минуты в неделе
- LocationID – идентификатор (занятого) помещения (номер комнаты) – Второе поле первичного ключа.
- EventID – идентификатор события (элемент расписания) – FK на ID таблицы tblSchedule
С заявленным КАСКАДНЫМ УДАЛЕНИЕМ. При удалении ведущей строки из tblSchedule СУБД должна гарантировать удаление всех строк из tblOccupation.

У tblOcupation тройное назначение – она совмещает в себе 1) функции календарной таблицы, разбивающей физическое время (timePoint – PK), 2) является продолжением таблицы tblSchedule – в ней живет хвост элемента расписания, только разложенный на 3) ВРЕМЯ ЗАНЯТОСТИ ПОМЕЩЕНИЯ – квалендарное описание интервала наблюдения.

Работает tblOccupation в паре с tblSchedule следующим образом:
Оператор вводит время начала события и длительность (как справедливо настаивают критики), которая может быть выбрана из «справочника допустимых интервалов» (не рассматриваем) .
[
В целях упрощения программирования интерфейса немедленно проводим денормализацию таблицы tblSchedule, вводя в нее поля, соответствующие вводимым оператором значениям. ( по вкусу – например
-numDayOfWeek – integer – день недели
-inervalTypeID – integer – тип интервала – определяет его длительность, так или иначе пересчитанную в минуты.
-IntervalTimeStart – Date – физический момент старта наблюдаемого интервала.
)
На заявленных 3х полях хорошо определяется индекс, определяющий правильность заполнения элемента расписания. Правильность для последующий генерации занятого интервала.
]
(Например) на afterInsert в форме, заполняющей элемент расписания, генерируется (в цикле, содержащемся в той же транзакции) гроздь записей в tblOccupation.

Желанные проверки выполняются автоматически –
Insert в tblOccupation провалится, если там уже найдется хотя бы одна строка из вновь сгенерированного диапазона для данного помещения. Автоматом выполнились провеки на включение в диапазон и на пересечение множеств.
При удалении записи из ведущей таблицы – каскадно удаляются записи из ведомой, освобождая тем замым помещение.
Остается возможность провести исправление – перетереть ранее произведенное занятие, однако в общем случае апдейт здесь выглядит вырожденно, полностью заменяясь комбинацией делет-инсерт.

За сим, - закругляюсь с дополнительными извинениями.


ЗЫ0 С одной стороны - данной задаче (применились) множественные упрощения(=оптимизации). Не всегда так хорошо получается.
С другой стороны – очевидно что «SQL разложения интервалов» разочаровывающее ресурсоемки в смысле объемов , а значит на больших задачах – рано или поздно времени обработки. Выводы и следствия отсюда без меня очевидны. (Честно говоря не совсем понимаю- зачем все это писал. Буду считать – что на понт повелся)


ЗЫ1
Конечно, можно было вместо всех словей - отправить к техническим мануалам. Однако там ТАКИХ словей, наверно, не нашлось бы… Впрочем, как тут пишут – не четал.

)))

ЗЫ2
Zhaina – боюсь в качестве «реферата» сии словья не сгодятся – погонют… И правильно сделают.

ЗЫ3 нашедшие силы дочитать до конца могут начинать смеяться…