Разработка базы данных для бронирования автобусов

Я разрабатываю модуль резервирования для автобусов, и у меня возникают проблемы при разработке подходящей структуры базы данных для него.

Давайте рассмотрим следующий случай:
Автобусы ходят от A до D с остановками в пунктах B и C. Пассажир может зарезервировать билет на любой маршрут, т.е. от A до B, от C до D, от A до D и т. д.

Таким образом, у каждого маршрута может быть много «подуровней», а более крупные содержат меньшие.

Я хочу спроектировать структуру таблиц для маршрутов и остановок таким образом, чтобы можно было легко искать свободные места. Таким образом, если кто-то зарезервирует место от А до В, то места от В до С или D все равно будут доступны.

Все идеи будут оценены.

 Mike Sherrill 'Cat Recall'11 апр. 2012 г., 01:20
Что вы пробовали? Отредактируйте свой вопрос и вставьте его в свои DDL (операторы SQL CREATE TABLE) и некоторые примеры данных в виде операторов SQL INSERT.

Ответы на вопрос(2)

С точки зрения автобусной компании:

Обычно один маршрут рассматривается как серия участков, например, от А до В, от В до С, от С до D и т. Д. Заполнение рассчитывается для каждого из этих участков в отдельности. Таким образом, если автобус отправляется из А, а люди уезжают в C, то пользователь может купить билет в C.

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

Решение Вопроса

Я бы, вероятно, пошел с "грубой силой" структура похожа на эту основную идею:

enter image description here

(There are many more fields that should exist in the real model. This is only a simplified version containing the bare essentials necessary to establish relationships between tables.)

Билет "покрывает" останавливается в таблице TICKET_STOP. Например, если заявка покрывает 3 остановки, то TICKET_STOP будет содержать 3 строки, связанные сthat билет. Если есть еще две остановки, не указанные в этом билете, то там не будет связанных строк, но ничто не мешаетdifferent билет от покрытия этих остановок.

Либеральное использование или естественные ключи / идентифицирующие отношения гарантируют, что два билета не могут покрыть ту же самую комбинацию места / остановки. Посмотрите, как LINE.LINE_ID & quot; мигрирует & quot; рядом с обоими краями ромбовидной зависимости, которая будет объединена только в ее нижней части, в таблице TICKET_STOP.

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

SELECT *
FROM
    STOP CROSS JOIN SEAT
WHERE
    STOP.LINE_ID = :line_id
    AND SEAT.BUS_NO = :bus_no
    AND NOT EXIST (
        SELECT *
        FROM TICKET_STOP
        WHERE
            TICKET_STOP.LINE_ID = :line_id
            AND TICKET_STOP.BUS_ID = :bus_no
            AND TICKET_STOP.TRIP_NO = :trip_no
            AND TICKET_STOP.SEAT_NO = SEAT.SEAT_NO
            AND TICKET_STOP.STOP_NO = STOP.STOP_NO
    )

(Replace the parameter prefix : with what is appropriate for your DBMS.)

Этот запрос по существу генерирует все комбинации остановок и посадочных мест для данной линии и автобуса, а затем отбрасывает те, которые уже "покрыты". по какому-то билету в данной поездке. Те комбинации, которые остаются "непокрытыми" свободны для этой поездки.

Вы можете легко добавить:STOP.STOP_NO IN ( ... ) или жеSEAT.SEAT_NO IN ( ... ) кWHERE пункт, чтобы ограничить поиск на определенных остановках или местах.

Ваш ответ на вопрос