Всем доброго времени суток!

Имеется фирма, продающая экскурсионные туры. Каждый тур имеет определенный маршрут(например, тур по Золотому кольцу "Ожившая старина" включает в себя города Владимир, Боголюбово и Суздаль). Покупая тур, клиент выбирает из базы для каждого пункта маршрута гостиницу, в которой он желает оставаться на время пребывания.
Если создавать БД на Access, то у меня получается примерно такая схема данных(привёл для наглядности):

То есть, по моему замыслу, после оформления договора с клиентом на покупку тура, соответствующие этому туру пункты маршрута копируются из таблицы "Маршрут" в таблицу "Гостиницы_в_туре", где уже для каждого пункта в зависимости от договора устанавливается гостиница. При этом в access'e каскадное удаление из таблицы "Гостиницы_в_туре" устанавливается без проблем.
Тем не менее в качестве СУБД мне нужен MS SQL Server(2008), где каскадное удаление и триггеры на удаление связанных записей из этой же таблицы при такой схеме работать отказываются. Все, к кому ни обращался за помощью, утверждают, что допущена ошибка в проектировании. В таком случае, может быть, найдутся те, кто предложит правильный вариант структуры для этой базы данных?

Да, Вы правы, прошу прощения. Я торопился при создании варианта в access, вот и допустил ошибки. Переделал и связал нужные таблицы:


Не нравятся мне таблицы "Маршрут" и "Гостиницы в туре". По количеству записей они практически дублируют друг друга. Но до другого решения дойти не могу :(

Хм, но как при такой структуре поддерживать целостность данных?
Предположим, что следует хранить в памяти данные о предыдущих поездках и остановках клиентов(то есть содержание таблицы "Гостиницы_в_туре"). Или, скажем, клиент купил тур и уже отправился в него. После чего возникла нужда удалить пункт маршрута в этом же туре. Самым простым было бы удалить ненужную запись из таблицы "Маршрут", но этого умная СУБД не позволит сделать, ибо тогда в таблице "Гостиницы_в_туре" появятся ссылающиеся на несуществующее значение записи. Удалять каскадно в таком случае тоже нельзя, ибо тогда удалятся связанные записи о текущих и прошлых поездках, т.е. нужная "хистори".
Возможен вариант убрать FK, идущий от сущности "Маршрут" к "Гостиницы_в_туре", и при этом вручную контролировать ввод, используя триггеры/макросы, но сомневаюсь, что преподаватели меня за такое решение по голове погладят.

Собственно, подобное и заставило меня усомниться в правильности разработанной структуры.

Спасибо Вам за ваше терпение и помощь, П-Л! Буду осуществлять удаление связанных записей при помощи написанных вручную процедур. Просто где-то вычитал, что при помощи встроенных в субд функций(в данном случае каскадного удаления) процесс будет быстрее.
Возникла ещё одна проблема. Требуется хранить историю проданных договоров и гостиницы, в которых человек останавливался в определенных пунктах своего маршрута. Но и следует каким-то образом предусмотреть возможность редактирования(а именно удаления пунктов маршрута) состава действующих туров - присутствие же связанных записей в таблице "Гостиницы_в_туре" этого сделать не даст. Можно, конечно, вместо редактирования имеющегося тура каждый раз создавать новый, но это вызовет обилие повторяющихся записей, да и пользователю забивать, допустим, 15 пунктов маршрута каждый раз, когда нужно удалить всего один, будет неудобно.