БД-Продажа билетов (ж\д) ERWIN 7, Firebird 2.5, IBExpert 2008

[al-s]

Задача – информационная поддержка деятельности транспортных касс (выбрать вид транспорта). Система должна осуществлять:
 ведение списка рейсов и билетов на них с указанием класса;
 учёт забронированных мест;
 ведение архива пассажиров за последний месяц.
Необходимо предусмотреть:
 продажу билетов в оба конца;
 поиск места на рейс в соответствии с требованиями заказчика;
 получение списка свободных мест на рейс;
 выдачу информации по конкретному рейсу;
 получение списка проданных мест;
 проверку наличия брони по имени клиента и/или названию организации.

Логическая модель, физическая модель, БД.
Логическую модель я сделал, по физической и дальше имеются вопросы.

[Streletz]

по физической и дальше имеются вопросы.

Какие именно?

[al-s]

V1 делал на лабе, а вот дома не могу сделать V2. Да и в типах данных и размерах не уверен.

[al-s]

На сколько я понимаю V1, V2 - это будут таблицы БД.

[Utkin]

Чего такое V1 и V2?
V2 практически повторяет persons, какой смысл? Потом все равно будете делать нормализацию базы. V1 дублирует Train... Или вы так запросы оформляете?

[phomm]

Сообщение от al-s

Задача – информационная поддержка деятельности транспортных касс (выбрать вид транспорта). Система должна осуществлять:
 ведение списка рейсов и билетов на них с указанием класса;
 учёт забронированных мест;
 ведение архива пассажиров за последний месяц.
Необходимо предусмотреть:
 продажу билетов в оба конца;
 поиск места на рейс в соответствии с требованиями заказчика;
 получение списка свободных мест на рейс;
 выдачу информации по конкретному рейсу;
 получение списка проданных мест;
 проверку наличия брони по имени клиента и/или названию организации.

Это порядка 20 таблиц минимум. И то высокие накладные расходы, на поддержку координации работы между разными станциями (почти во всех таблицах надо будет делать поля вроде "станция с которой производилась операция", "станция на которой будет реализована реальная работа"). Я как бы не понаслышке знаю.

Сообщение от al-s

Логическую модель я сделал

Если кратко - то Вы неправы.

У вас даже нет банально сущности "билет", хотя вроде как V_2 напоминает его. В V_1 вообще поле кода поезда дважды, вообще для чего она? Почему именование неадекватное?
Не продумана фиксация продажи (бронь не подразумевает оплату сразу, но подразумевает занятие места).
Как выше сказал - ноль действий в сторону "дистанционной продажи" (в "оба конца") - это когда на двух станциях производится одновременное занятие мест (для чего потом используются поля по станциям, описанные выше). Обычно такую работу, включающую передачу данных на другую станцию, выполняет хранимая процедура или джоб на сервере или "сервер приложений" при 3х-звенной архитектуре.
Рейсы также бессмысленны у Вас. Кто их должен создавать ? Человек каждый раз заново ? Нет. Должна быть статичная "маршрутная информация" (почти неизменная) - станции и их связи, "маршруты" состоящие из списка станция-время(несколько разных)-расписание в днях. По ним создаётся динамическая картина - на конкретные дни, эта картина даже может меняться (в отличие от статичной) в смысле возможности вручную корректировать конкретные отправления.
Также нет ничего касательно типов вагонов/мест - всякие вместимость, разбивка по вагону/купе, разные виды комфорта и соответственно, тарифы (об этом говорят слова "с учётом класса", "с учётом требований заказчика").

Лично у нас, если отбросить не относящиеся к постановке задачи сущности, на такую работу порядка 40-50 таблиц и сотни хранимых процедур.

В общем, чисто на мой взгляд, сложновато для лабы, а упрощать если, то какое-то убожество будет.

[Utkin]

Не представляю как будет работать Station_Train согласно связям на картинке.... И вообще составных ключей намешано.

[al-s]

phomm, вы безусловно правы логическая модель сделана из-за не понимания, как ее на самом деле нужно делать (да и как понять за 4 пары занятий). БД нужна упрощенная, а не как вы описали (как в жизни). Пытаюсь разобраться.