前回「ICカードこれひとつ「バスの系統」協力募集」で、系統情報の暫定的な仕様を定め、開発に着手しました。実際にデータを登録してみて、保守性を確保するために用意した情報がかなり問題になりました。無駄になることは最初から想定済みでしたが、全体としての分量が想定以上に多くなりデータベースが大きくなりすぎることが分かってきました。そこで、よりシンプルで分かり易い仕様とするため、改めて設計をし直すことにしました。情報」と「停留所の情報」は分離する。ルート」→「停留所」という階層構造で表現できそうなことが分かってきたので、概ねこの階層構造でデータベースを作るものとする。事業者だけのデータベースは不要なので、系統以下の3種類のデータベースに分割することになる。系統情報データベース各社の系統情報を1系統1レコードとして用意する。同じ系統番号でも、若干経由地が異なったり、途中で車庫入りする等で部分的な運行となるルートがある場合は、どうするかは都度考える。ルート情報データベースルートは往復ある場合で2ルートということになる。夜など、途中で車庫入りするため途中で運転打ち切りになるルートなどもありうる。曜日によって運行されるルートが変わることもある。いった情報ごとにルート番号を変更して記録し、このDBにはそのルート情報を格納する。停留所情報データベースルートごとに、存在する停留所の一覧を記録するデータベースとする。※は検索用情報で、うち一部はKEYとなる。免許維持路線ルート情報データベースルート情報データベースは、主としてそのルートの起点終点および運行日が記録される。(年1など)運行曜日は日=0、土=6の数字で記述する。毎日なら「0123456」、平日のみなら「12345」、土日のみなら「06」など免許維持ダイヤは、DBには英字で記述し、アプリ側で特別な対応をするものとする。「SYUNBUN」10月1日のみ、など特定の日付の場合、これは英字のみで表現する方法を模索する必要がある。停留所情報データベースルートごとに、その停留所を記録する。最低限必要なものはDB自体の検索キーと停留所番号のみだが、系統名や停留所名などがないと保守性が著しく低下するため、TSVファイルにはメモとして記載し、スクリプトで抜き取ってから実DBを作成するものとする。△はデータファイルのみの項目で、抜き取って加工してからDB化する。することで保守性を確保しながら無駄を排除し、停留所名などの二重管理も不要とした。(1からスタートの10進数とする。自由乗降区間(CI-CA以外)●方向1ルートを1文字で表現する。そもそも経由しない2ルート程度までまとめて記載可能とすることでデータベースサイズをコンパクトにできないか、暫定的な措置を講じる実験。上りのみ停車(下りは別の道を通る等で経由すらしない)無理そうなら、諦めて往路、復路でデータを分けるものとする。記号で表わす奈良交通の21系統を例とする。変更があれば、この系統DBのメモとしての記載も変更することにはなるが、してもしなくてもデータベースには入らないので影響はない。問題と課題DBが3つに別れてしまいましたが、これを維持管理するのは本当に大変そうです。本当にこの仕様を維持できるのでしょうか。主として「ICカードこれひとつ」や「文字、文字コード」処理、時々C++などについて記述しています。フォームお知らせコメント等お気軽にどうぞ。気に入ったら拍手して頂けると、今後の記事を書く際の参考や励みになります。■お仕事を募集しておりますソフトウェア製造の仕事や、原稿執筆の仕事などを随時受け付けております。お気軽にご相談下さい■初めての方へこまごまと更新しているため、他にも関連する記事があるかもしれません。「月別アーカイブ」「検索フォーム」「カテゴリ」などをお試し下さい。トップページはこちら。