Ты пытаешься заложить в структуру данных некие ограничивающие правила. Вообще говоря, это не цель проектирования БД. Важно, чтобы БД умела хранить любые допустимые данные. Если она сможет хранить и недопустимые данные, то это не страшно. В ряде случаев недопустимые данные можно отсечь используя декларативные ограничения целостности, но если этого не достаточно, разработчики создают триггеры, хранимые процедуры, на крайний случай отчёты по ошибкам.

Я так понял, что тебе не удаётся ограничить распределение препода одновременно на два занятия. Сделай таблицу пар на весь планируемый период (id, дата, время начала, время окончания). Сделай таблицу связи препода с аудиторией на пару. Сделай UNIQUE ограничение на ключ (препод, пара).

Аналогично строим связь группы с аудиторией на пару.

И наконец строим связь занятия с аудиторией на пару.

Очевидно, что люди собравшиеся в одном месте в одно время будут заниматься чем то одним (хотя в маленьких сельских школах случается, что один учитель в одной аудитории рулит учениками из разных классов). Если это не так, придётся создать некую сводную таблицу связей занятий с преподами группами, парами и аудиториями. Добавить в связи роль участника (например, один препод может читать лекцию, а другой асситировать ему; на экзамине один препод выступает председателем комиссии, возможно на экзамине будет секретарь и т.п.). Но эти навороты могут быть и несущественными, если целью является просто собрать людей для проведения совместного мероприятия, а не вести детальный учёт рабочего и учебного времени.

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