データベース テーブル設計について

Question

例えばの話なんですが、
鉄道駅についてのデータベースがあるとして、ある駅から一つ上った駅、下った駅を管理するテーブルが必要な時、
まず、

[駅テーブル]
駅id(PK)
名前

一つの駅からは下りも上りも複数駅ある可能性があるので、
[上り駅テーブル]
出発駅id(PK)
目的駅id(PK)

[下り駅テーブル]
出発駅id(PK)
目的駅id(PK)

となるのかなと考えました。
出発駅id、目的駅id共に駅テーブルの駅idにないものは入れられないので、
リレーションシップを組むと駅テーブル一つから上り下りテーブルそれぞれに2つリレーションシップを組むことになり１対１になります。

１対１のリレーションシップは基本的には使わないと思うのですが、
この設計は適当でしょうか？

考え方や解決方法を教えていただけると助かります。

Answer 1

乗換案内 のデータは 日本全国の鉄道時刻情報データベース を買って機能を実現しています。
このフォーマットからテーブル構造もわかるのでは？

Comments

[Onikabe]

回答ありがとうございます。
他の類似しそうなシステムを参考にするのも手ですね。
今回はほんとうにふと思いついてしまった事なのでなんですが。

[Orlofsky]

代々木→友部→新前橋→新宿で136円です。
上記のデータを買わずに調べるにはかなり大変です。

Answer 2

「上り」「下り」も区分として1つのテーブルに持った方が良いのでは。
出発、目的、区分　の３つで複合主キーと持っておくとか。

目的に合うかわかりませんけど・・。
別テーブルにするメリットは感じませんでした。

ただ、やはり「大目的」部分は必要です。
何にどのように使うのか。一般論だけ聞いてもあてはめられないことってよくあります。

Comments

[Onikabe]

回答ありがとうございます。
ただ「こういう事したい場合はどうするんだ？」と思ってしまったばっかりにの質問だったので恐縮です。
上り下りでテーブルを分けなければいけないケースもあるかもしれないし確かに一般論というものだけでは答えが出ないですね。申し訳ないです。
出発目的区分の複合テーブルにするというのは思いつきませんでした。
質問の内容に的確に回答していただいて感謝します。

[m.ts10806]

要件不明瞭な部分もあったので、これが的確かどうかは分かりません。
データだけを見るのではなく、もっとアプリケーション・システムの大目的や機能から考えた方が良さそうです。