「バスの系統」データベース再設計

前回「ICカードこれひとつ「バスの系統」協力募集」で、系統情報の暫定的な仕様を定め、開発に着手しました。

実際にデータを登録してみて、保守性を確保するために用意した情報がかなり問題になりました。
無駄になることは最初から想定済みでしたが、全体としての分量が想定以上に多くなりデータベースが大きくなりすぎることが分かってきました。
そこで、よりシンプルで分かり易い仕様とするため、改めて設計をし直すことにしました。

細かな機能の実装は今後の課題となりますが、基本的な処理の作り直しを無事終えたので、メモ代わりに書いておきます。


方針


階層構造


「系統の情報」と「停留所の情報」は分離する。

系統は、「事業者」→「系統」→「ルート」→「停留所」という階層構造で表現できそうなことが分かってきたので、概ねこの階層構造でデータベースを作るものとする。

事業者だけのデータベースは不要なので、系統以下の3種類のデータベースに分割することになる。


系統情報データベース


各社の系統情報を1系統1レコードとして用意する。
同じ系統番号でも、若干経由地が異なったり、途中で車庫入りする等で部分的な運行となるルートがある場合は、どうするかは都度考える。

ルート情報データベース


ルートは往復ある場合で2ルートということになる。
夜など、途中で車庫入りするため途中で運転打ち切りになるルートなどもありうる。
曜日によって運行されるルートが変わることもある。

そういった情報ごとにルート番号を変更して記録し、このDBにはそのルート情報を格納する。


停留所情報データベース


ルートごとに、存在する停留所の一覧を記録するデータベースとする。


データベース構造


各項目の意味
※は検索用情報で、うち一部はKEYとなる。マークなしは原則として表示用

系統情報データベース


1 ※事業者番号
2 ※系統ID
3 内部利用のフラグ (未使用では0としておく)
4 ※有効期限開始日 (YYYYMMDD、特に指定がないばあいはオール0とする)
5 ※有効期限終了日 (YYYYMMDD、特に指定がないばあいはオール9とする)
6 バス=B
7 事業者名 (日本語名と英名は|で区切って併記する)
8 営業所名 (日本語名と英名は|で区切って併記する)
9 コミバスなどの名称 (日本語名と英名は|で区切って併記する)
10 系統のフラグ
11 系統の特性(表示用) (急行・特急・臨時などの情報をおく)
12 路線番号(表示用) (系統番号とは別に存在する場合用)
13 路線名(表示用)(日本語名と英名は|で区切って併記する)
14 系統番号(表示用)

●系統のフラグ(暫定仕様)
助 = 国・自治体・沿線住民等からの補助路線
免 = 免許維持路線



ルート情報データベース


ルート情報データベースは、主としてそのルートの起点終点および運行日が記録される。

1 ※事業者番号
2 ※系統ID
3 ※ルート番号 (0からスタートで9までの最大10種類、足りない場合があれば再検討)
4 内部利用のフラグ (未使用では0としておく)
5 ※有効期限開始日 (YYYYMMDD、特に指定がないばあいはオール0とする)
6 ※有効期限終了日 (YYYYMMDD、特に指定がないばあいはオール9とする)
7 ※ルートの運行条件
8 系統の起点(表示用)
9 系統の終点(表示用)
10 系統の経由地(表示用)



●ルートの運行条件

日本の公共交通のダイヤは次の種類がある

・日常的なダイヤグラム
1. 平日ダイヤ
2. 金曜ダイヤ (沖縄県など)
3. 土曜ダイヤ
4. 日曜祝日ダイヤ
・その他のダイヤグラム
5. 臨時ダイヤ
6. 免許維持ダイヤ (年1など)

運行曜日は日=0、土=6の数字で記述する。
毎日なら「0123456」、平日のみなら「12345」、土日のみなら「06」など

免許維持ダイヤは、DBには英字で記述し、アプリ側で特別な対応をするものとする。

例: 春分の日のみ (京都バス) 「SYUNBUN」


10月1日のみ、など特定の日付の場合、これは英字のみで表現する方法を模索する必要がある。




停留所情報データベース


ルートごとに、その停留所を記録する。
最低限必要なものはDB自体の検索キーと停留所番号のみだが、系統名や停留所名などがないと保守性が著しく低下するため、TSVファイルにはメモとして記載し、スクリプトで抜き取ってから実DBを作成するものとする。
△はデータファイルのみの項目で、抜き取って加工してからDB化する。

こうすることで保守性を確保しながら無駄を排除し、停留所名などの二重管理も不要とした。

1 ※事業者番号
2 ※系統ID
3 ※ルート番号 (0からスタートで9までの最大10種類、足りない場合があれば再検討)
4 ※停留所連番 (1からスタートの10進数とする。系統の停留所数が10以上の場合は01、100以上の場合は001のように頭に0を付けて桁数を合わせるとソートしやすい)
5 内部利用のフラグ (未使用では0としておく)
6 ※有効期限開始日 (YYYYMMDD、特に指定がないばあいはオール0とする)
7 ※有効期限終了日 (YYYYMMDD、特に指定がないばあいはオール9とする)
8 方向
9 ※リレーション用の停留所番号(バス停DBのキー)
△10 事業者名
△11 路線番号+路線名+系統番号
12 停留所のフラグ(自由乗降などを表わすフラグ類おきば)
△13 停留所名1
△14 停留所名2
△15 停留所名3


●停留所のフラグ(暫定仕様)
臨 = 臨時駅・停留所
自 = 自由乗降区間(CI-CA)
由 = 自由乗降区間(CI-CA以外)


●方向
1ルートを1文字で表現する。

v = 下り線が停車する停留所
^ = 上り線が停車する停留所
| = 通過
* = そもそも経由しない


2ルート程度までまとめて記載可能とすることでデータベースサイズをコンパクトにできないか、暫定的な措置を講じる実験。

往復(2ルート)を1情報としてまとめる場合

v^ = 双方向
v| = 下りのみ停車(上りも経由はする)
|^ = 上りのみ停車(下りも経由はする)
v* = 下りのみ停車(上りは別の道を通る等で経由すらしない)
*^ = 上りのみ停車(下りは別の道を通る等で経由すらしない)

無理そうなら、諦めて往路、復路でデータを分けるものとする。

実際のデータ例


ここではタブコードを ‣ 記号で表わす

奈良交通の21系統を例とする。

系統情報データベース


0E51‣31-21‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣‣‣‣大和町線‣21


ルート情報データベース


0E51‣31-21‣0‣0‣00000000‣99999999‣01234567‣学園前駅(南)‣学園大和町五丁目‣


停留所情報データベース


事業者名、系統名、停留所名は全てメモに過ぎない。変更があれば、この系統DBのメモとしての記載も変更することにはなるが、してもしなくてもデータベースには入らないので影響はない。
0E51‣31-21‣0‣01‣0‣00000000‣99999999‣v^‣033B‣奈良交通|Nara Kotsu‣大和町線21‣‣学園前駅(南)‣‣
0E51‣31-21‣0‣02‣0‣00000000‣99999999‣v^‣0121‣奈良交通|Nara Kotsu‣大和町線21‣‣学園南三丁目‣‣
0E51‣31-21‣0‣03‣0‣00000000‣99999999‣v^‣0123‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町‣(奈良西警察署)‣
0E51‣31-21‣0‣04‣0‣00000000‣99999999‣v^‣0139‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町二丁目‣‣
0E51‣31-21‣0‣05‣0‣00000000‣99999999‣v^‣5F29‣奈良交通|Nara Kotsu‣大和町線21‣自‣自由乗降指定地‣(大和町①)‣
0E51‣31-21‣0‣06‣0‣00000000‣99999999‣v^‣013A‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町三丁目‣‣
0E51‣31-21‣0‣07‣0‣00000000‣99999999‣v^‣5F2A‣奈良交通|Nara Kotsu‣大和町線21‣自‣自由乗降指定地‣(大和町②)‣
0E51‣31-21‣0‣08‣0‣00000000‣99999999‣v^‣013B‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町四丁目‣‣
0E51‣31-21‣0‣09‣0‣00000000‣99999999‣v^‣5F2B‣奈良交通|Nara Kotsu‣大和町線21‣自‣自由乗降指定地‣(大和町③)‣
0E51‣31-21‣0‣10‣0‣00000000‣99999999‣v^‣013C‣奈良交通|Nara Kotsu‣大和町線21‣‣学園大和町五丁目‣‣


本当の問題と課題


DBが3つに別れてしまいましたが、これを維持管理するのは本当に大変そうです。
本当にこの仕様を維持できるのでしょうか。

2019/05/26(日)02:37 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

コメント

コメントの投稿

「くしろバス」「阿寒バス」の「WAON」調査について ホーム 磁気式などの電子マネーを管理するアプリの開発
トラックバック

この記事にトラックバックする(FC2ブログユーザー)
▲ページトップ

カレンダー

07 | 2019/08 | 09
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

プロフィール

miraicorp

Author:miraicorp
未来情報産業(株) 社長

主として「ICカードこれひとつ」や「文字、文字コード」処理、時々C++などについて記述しています。

twitterマストドン

管理用

検索フォーム

お知らせ

コメント等お気軽にどうぞ。

気に入ったら拍手して頂けると、今後の記事を書く際の参考や励みになります。

■お仕事を募集しております
ソフトウェア製造の仕事や、原稿執筆の仕事などを随時受け付けております。
お気軽にご相談下さい

■初めての方へ
こまごまと更新しているため、他にも関連する記事があるかもしれません。
「月別アーカイブ」「検索フォーム」「カテゴリ」などをお試し下さい。
トップページはこちら

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

このブログをリンクに追加する

RSSリンクの表示

QRコード

QR