Як створити схему бази даних запитів на автобусну станцію?

У нас є дані про автовокзал, і ми хочемо створити додаток, який надасть лінію / численні лінії для даної стартової станції та кінцевої станції.

Наприклад, користувач спробує отримати пропозицію про шину від станції1 до станції2.

Якщо є автобусна лінія, яка може охоплювати і те, station1і station2цю лінію слід повернути. Результат може виглядати приблизно так:

Step1: station1 -- station2

Якщо між станцією1 та станцією2 немає прямої автобусної лінії, програма повинна спробувати знайти план обміну, наприклад, результат може виглядати так:

Step1: station1 -- exchangestation

Step2: exchangestation -- station2

Тепер у нас є дані, але ми не знаємо, як спроектувати модель даних в базі даних, як створити схему, щоб зробити запит ефективним?

===============================================

Оновлення:

Наприклад, у мене є чотири автобусні лінії (насправді дві) з різним кольором:

l1: A-B-C-D
l2: D-B-A (in fact, the l2 is the reverse of l1 except the l2 will skip station `C`.
l3: E-B-D-F
l4: F-D-B-E(reverse of l3) 

Тепер, якщо ми хочемо зберегти цю інформацію в базі даних для запиту плану лінії автобусів для даної станції до іншої, то скільки таблиць нам потрібно, і що потрібно помістити в кожну таблицю?

Я думаю, що вам потрібно створити іншу таблицю, яка визначає всі маршрути, як комбінації інших маршрутів. Потім ви запитуєте цю таблицю і приєднуєтесь до фактичних маршрутів, щоб отримати геометрію.

Якщо запит призначений для "від станції" до "до станції", і в кожному розділі є "від станції" і "до станції". Але ви хочете включити маршрути, які беруть у кілька розділів, ви можете мати ще одну таблицю "маршрути", яка має щось на зразок:

• 'назва маршруту', 'ідентифікатор маршруту', 'від станції', 'до станції'

вам також потрібна ваша оригінальна таблиця розділів, наприклад:

• "назва розділу", "Ідентифікатор розділу" тощо ...

і я думаю, що вам потрібна ще одна таблиця приєднання, наприклад:

• "ідентифікатор маршруту", "ідентифікатор розділу"

і ця таблиця зберігає співвідношення між багатьма маршрутами та таблицями розділів, тож, для вашого прикладу вище, у таблиці з'єднання є два ряди, по одному на кожен крок. Запит проводиться на таблиці маршрутів, для станцій від і до станцій. Дані, що повертаються, якщо є просторовими, - це деталі з таблиці маршруту та просторові дані з таблиці розділів. Можливо, ви складаєте рази з кожного розділу чи будь-якого іншого.

Чи має це сенс?

Ви, ймовірно, повинні вибрати інструмент для цього і дотримуватися схеми, на яку інструменти сили (наприклад, pgRouting ).

Якщо ви хочете зробити це без таблиці, вам потрібні лише дві таблиці для зберігання вершин і вузлів.

Хитрість полягає в тому, що ваше зображення показує просторовий підхід, а насправді вам потрібен тимчасовий (зображення в очікуванні). Шина не переходить від вузла A до вузла B. Шина йде від вузла A @ 12: 00 до вузла B @ 12: 10 .

Таким чином ми створюємо вузол для кожної станції + вузол на кожен час відправлення від кожної станції. Кожен вузол має 3 односторонніх ланки, що виходять з нього:

• посилання до місця призначення автобуса (вартість A A 12: 00 - B @ 12: 10: 10 хвилин)
• посилання на наступний автобус, що відправляється з цієї станції (A @ 12:00 - A @ 12: 30 вартість: 30 хвилин)
• посилання на базовий вузол (від A 12: 00 до A: 0 хвилин)

Тепер, щоб знайти з'єднання від точки А до точки С, ми вибираємо найбільш ранню узгоджувальну точку на станції А і знаходимо шлях звідти до базового вузла станції С.

Вузли:

id|station|time
---------------
1 |A      |NULL
2 |B      |NULL
3 |A      |12:00
4 |B      |12:10

вершин

id|start_node|end_node|line|cost
---------------------------
1 |3         |4       |l1  |10
2 |3         |1       |NULL|0
3 |4         |2       |NULL|0

Ось робочий приклад з використанням javascript та даних з OpenStreetMap. Модель даних може бути корисною.