Уважаемый All. Подскажите новичку. Уж очень не хочется делать ошибок на этапе проектирования, а спросить не кого. Где может возникнуть засада позже?

ТЗ
Имеем несколько теплоходов выполняющих рейсы. На каждом теплоходе у нас соответсвенно есть каюты (они различаются классу). В каютах живут люди.

Делаю такую структуру. Чуствую что где-то ошибся. А понять не могу :) Как например будет выглядеть запрос о свободных каютах в одном круизе и запрос о не полностью заселенных каютах в том же круизе.
Надо ли вводить в базу понятие места в каюте? Ведь мест в каюте может быть от 1 до 4, плюс диванчик, который тоже может быть местом.

Спасибо большое за быстрый ответ. Мне тоже казалось, что надо бы делать PK из 3 полей, но в прочитанной литературе (немногочисленной пока) таких примеров не приводилось и связь многие-ко-многим всегда приводилась из двух полей. Это меня и смутило.

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

ModelR
Место вводить не обязательно, если только оно не указывается в путевке.


Или, например, позже в структуру БД будет вводится ЦЕНА за место, зависящая от категории каюты и круиза. Правильно я понимаю? Или же цены можно будет ввести другим образом? Каким например?

Еще один ламерский вопрос, если позволите...
Можно или нельзя ввести PK КодЗаселения , и избавится от составного ключа из 3 полей КодКаюты, КодКлиента, КодКруиза (читая форум, я понял, что это не всегда есть хорошо и по возможности следует избегать этой ситуации). ПОЧЕМУ?

Спасибо

СерегаА если один клиент пожелает плыть в одиночку в 4 местной каюте?

дык он и будет там один. В чем проблема то? Не понимаю. Извините, за глупый вопрос.

Валентин КА зачем ключ сотрудника и ключ клиента в каютах? зачем вообще разносить физлиц на разные справочники?

Соотрудник отвечает за проданную каюту и контролирует, например сдачу всех документов на визу. Поэтому он обязательно должен фигурировать в заселении.

Разносить может и не стоит. Не подумал так глубоко :)

СерегаВозможна ли покупка части круиза? Типа один клиент от Москвы до Астрахани, а другой обратно? Если возможно, то это в структуре не отражено.

Нет круиз продается полностью. Такая ситуация не возможна.

Мне хочется в этой структуре пока не касаться финансов, но иметь возможность позже ввести необходимые таблицы малой кровью.

Серега
По структуре одно заселение = одно место. В данном случае это будет не так. И не понятно, на какое место поселен клиент - на основное или дополнительное. А это наверное разная цена + другие условия могут быть, типа только если клиент покупает всю каюту ему может быть предоставлено доп.место для ребенка например.

По ТЗ не имеет значения на каком месте к каюте живет пассажир. Важна свзяка клиент-каюта-круиз.

Необходимо только контролировать чтобы в одной каюте в одном круизе не оказалось больше пассажиров чем того позволяют возможности каюты (ОсновныхМест+ДополнительныхМест)

СерегаИМХО, это взаимоисключающие хотения. 8-)
А если пойти путем через статусы оплаты путевки (забронировано, предоплата, полная оплата), а не через суммы?

Серега Может ТЗ надо подправить - согласовать.
Да я сам себе ТЗ :) Поправлю.

Серега
Я просто критикую (надеюсь конструктивно).

Более чем. Спасибо, Серега.

Наверно действительно введу понятие места. Позже отпишусь с ожиданием новой критики.

Серега
Вполне может быть будет достаточно ввести количество мест в "заселении".

гениально !

Серега Изнасилуй заказчика
а вот этого не надо. я сам заказчик :)

На такой схеме нужны ли обведенные связи. Что дает их наличие? Отсутствие?

Серега kochа вот этого не надо. я сам заказчик :)
Так ты "владелец заводов, газет, пароходов"? И еще программы пишешь? Ну ты и скряга.

а куда деваться
Шучу, конечно не владелец. Просто хочется помочь родной alma mater