Разработка базы данных для системы расписаний транспорта

Question

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

StationTbl
------------
  StnName
  StnCity
  StnCode -  {Primary Key}

TrainTbl
---------
  TrnName
  TrnNumber -  {Primary Key}
  SourceStn
  DestStn
  DaysofWeek 

TrainHopTbl
--------------
  TrnNumber   -  {Primary Key}
  StationCode -  {Primary Key}
  ArrTime
  DepTime
  HopIndex

Большинство полей буквенно-цифровые, за исключением полей Time и HopIndex в TrainHopTbl. Как видите, предварительный дизайн очень груб и далек от завершения.

Пользователи смогут находить поезда либо по названию / номеру поезда, либо указав источник и станцию ​​назначения. С первым запросом можно легко справиться, но у меня возникают проблемы при написании запроса для второго поиска, когда пользователь дает пару src / dest, а сервер возвращает список поездов, которые следуют по этому маршруту. Эта информация будет извлечена из TrainHopTbl, который содержит список прыжков для конкретного поезда, например, так -

TrainHopTbl
--------------
Num StnCode  ArrTime  DepTime  HopIndex
121  WDC     0900      0910        1
121  BAL     1005      1010        2
121  NYC     1145       -          3

Если пользователь вводит WDC / NYC в качестве пары src / dest, тогда запрос должен возвращать номер поезда 121, поскольку он является действительным маршрутом.

Любые советы по указателям / ссылкам / книгам по дизайну базы данных будут полезны. Черт, на этом этапе даже работающие запросы или целые перепроектирования были бы полезны, так как я, кажется, застрял в колее, из которой мне трудно выйти, и это полностью остановило мой прогресс.

Answer 1

Я бы забрал ваш SourceStn и DestStn из вашего TrainTbl - это ненужный беспорядок.

В любом случае, вы можете получить то, что ищете:

select 
    src.TrnNumber,
    srcSt.StnName as SourceStation, 
    srcSt.StnCity as SourceCity,
    src.DepTime,
    destSt.StnName as DestinationStation,
    destSt.StnCity as DestinationCity,
    dest.ArrTime,
    (abs(dest.HopIndex - src.HopIndex)) as Stops
from
    TrainHopTbl src
    inner join TrainHopTbl dest on
        src.TrnNumber = dest.TrnNumber
    inner join StationTbl srcSt on
        src.StnCode = srcSt.StationCode
    inner join StationTbl destSt on
        dest.StnCode = destSt.StationCode
where
    src.StnCode = 'WDC'
    and dest.StnCode = 'NYC'
    and src.HopIndex < dest.HopIndex
order by
    Stops asc,
    DepTime asc

Изменить: здесь я не учел переводы. В вашем вопросе упоминались только прямые поезда. Дайте мне знать, если вы хотите переводы.

Answer 2

Я еще не обдумал это, так что этот ответ может быть далеко.

Я думаю, что TrainHopTbl записывает узлы в сети, где было бы более полезно записывать ребра в сети. Край будет иметь номер поезда, станцию ​​отправления, время отправления, станцию ​​прибытия и время прибытия. И, возможно, индекс хмеля, как у вас.

Итак,

Num: 121, Hopindex: 1, DepStnCode: WDC, DepTime: 910, ArrStnCode: BAL, ArrTime: 1005

Описал бы "прыжок" из Вашингтона в Балтимор, преимущество в сети прыжков.

(Кроме того, я бы назвал прыжок "ногой", но это просто выбор имени.)

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

Недостатком этого является то, что в кодах станций немного больше избыточности. Я не выяснил, вредна ли эта избыточность или нет.

Answer 3

Похоже, вы пытаетесь решить проблему жесткого графа с базой данных. Гораздо проще добавить поле в таблицу поездов, в котором список остановок хранится в виде строки

"WDC, BAL, NYC"

Тогда вам просто нужно найти поезда, которые содержат две подстроки, которые вы ищете, в данном случае «WDC» и «NYC». Это сильно сужает ваш поиск до такой степени, что вы можете рассмотреть результирующие последовательности в коде вне SQL.

Если не проводить больше исследований, чем я готов сделать прямо сейчас, то тогда вы будете делать

SELECT откуда содержит "WDC" И содержит "NYC"

Я не знаю, как лучше всего Содержит ... комментирует кто-нибудь?