Jak zaprojektować schemat bazy danych zapytań do dworca autobusowego?

Mamy dane z dworca autobusowego i chcemy zbudować aplikację, która zapewni linię / linię wielokrotną dla danej stacji początkowej i końcowej.

Na przykład użytkownik próbuje uzyskać sugestię dotyczącą linii autobusowej ze stacji 1 do stacji 2.

Jeśli istnieje linia autobusowa, która może obejmować zarówno station1i station2powinien zostać zwrócony tej linii. Wynik może wyglądać następująco:

Step1: station1 -- station2

Jeśli nie ma bezpośredniej linii autobusowej między stacją 1 a stacją 2, aplikacja powinna spróbować znaleźć plan wymiany, na przykład wynik może wyglądać następująco:

Step1: station1 -- exchangestation

Step2: exchangestation -- station2

Teraz mamy dane, ale nie wiemy, jak zaprojektować model danych w bazie danych, jak utworzyć schemat, aby zapytanie było wydajne?

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

Aktualizacja:

Na przykład mam cztery linie autobusowe (właściwie dwie), każda w innym kolorze:

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) 

Teraz, jeśli chcemy zapisać te informacje w bazie danych w celu przeszukania planu linii autobusowej dla danej stacji do drugiej, to ile tabel potrzebujemy i co należy umieścić w każdej tabeli?

Myślę, że musisz zbudować inną tabelę, która definiuje wszystkie trasy w postaci kombinacji innych tras. Następnie przeszukujesz tabelę i dołączasz do rzeczywistych tras, aby uzyskać geometrię.

Jeśli zapytanie dotyczy „od stacji” do „do stacji”, a każda sekcja ma „od stacji i” do stacji. Ale chcesz uwzględnić trasy, które biorą udział w wielu sekcjach, możesz mieć inną tabelę „trasy”, która ma coś takiego:

• „nazwa trasy”, „identyfikator trasy”, „ze stacji”, „do stacji”

potrzebujesz również oryginalnej tabeli sekcji, czegoś takiego jak:

• „nazwa sekcji”, „identyfikator sekcji” itp.

i myślę, że potrzebujesz innej tabeli łączenia, takiej jak:

• „ID trasy”, „ID sekcji”

i ta tabela przechowuje relację jeden do wielu między tabelami tras i sekcji, więc w powyższym przykładzie masz dwa wiersze w tabeli łączenia, po jednym dla każdego kroku. Zapytanie odbywa się na tablicy tras dla, od i do stacji. Zwracane dane, jeśli są przestrzenne, to szczegóły z tabeli tras i dane przestrzenne z tabeli przekrojów. Może sumujesz czasy z każdej sekcji lub czegokolwiek.

Czy to ma sens?

Prawdopodobnie powinieneś wybrać do tego narzędzie i postępować zgodnie ze schematem wymuszonym przez narzędzie (na przykład pgRouting ).

Jeśli chcesz to zrobić bez tabeli, potrzebujesz tylko dwóch tabel do przechowywania wierzchołków i węzłów.

Sztuczka polega na tym, że twój obraz pokazuje podejście przestrzenne, podczas gdy w rzeczywistości potrzebujesz tymczasowego (zdjęcie w toku). Magistrala nie jedzie od węzła A do węzła B. Magistrala jedzie od węzła A @ 12: 00 do węzła B @ 12: 10 .

Tworzymy więc węzeł dla każdej stacji + węzeł dla każdej godziny odjazdu z każdej stacji. Każdy węzeł ma 3 wychodzące z niego łącza jednokierunkowe:

• link do miejsca docelowego autobusu (koszt A @ 12: 00 - B @ 12: 10: 10 minut)
• link do następnego autobusu odjeżdżającego z tej stacji (A @ 12: 00 - A @ 12: 30 koszt: 30 minut)
• link do węzła podstawowego (A @ 12: 00 do A koszt: 0 minut)

Teraz, aby znaleźć połączenie z punktu A do punktu C, wybieramy najwcześniejszy pasujący punkt na stacji A i znajdujemy się stamtąd do węzła bazowego dla stacji C.

Węzły:

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

wierzchołki

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

Oto działający przykład z wykorzystaniem javascript i danych z OpenStreetMap. Model danych może być przydatny.