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

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

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

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

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

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


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

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

Спасибо

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

гениально !

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

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

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

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

За Дейта спасибо. Основательная книженция. Скачал 7 издание. 8-го не нашел. Кто знает их отличия?

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

я продаю место в каюте. На месте всегда живет физлицо. Заказ на это место может разместить как само физлицо проживающее на этом месте, так и организация продавшая это место физлицу и передавшая заказ мне. В заказе может быть заброниравано сразу несколько мест в различных каютах и круизах.

Мозг дымится. :) Не пойму с какой стороны начать распутывать этот клубок.

Застрял на этом этапе.

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

Господа, покритикуйте плз. Просьба отнестись с пониманием и вниманием (если конечно у вас есть для этого время). Это первая база которую я попытался спроектировать. :)

Серега, что думаешь?

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

а для этого надо ввести поля в таблице МЕСТА ЗабронированоС и ЗабронированоДо. Правильно?

или быть может, чтобы не плодить огород сделать это можно через запрос с полями ДатаНачалаКруиза и ОкокнчаниеКруиза?

Серега
Может еще типы мест и типы кают в справочники загнать.

это сделано, просто не стал отображать на схеме, дабы не отвлекать внимания от сути

господа гуру. Дайте плз комметнраии по поводу последней схемы. Для полноты картины так сказать. :)

деньги здесмь не учитываются. Учитывается только статус оплаты брони (без оплаты, предоплата, полная оплата).

Возвраты и отказы . В чем там проблема не пойму пока. ?