「夫を成功」へ導く妻の秘訣 座談会

データベースのテーブル設計を考えています。
多数の「ノード」があり、「エッジ」(そのノード同士の関係)をデータベースに記録したいと思っています。

例えば、A, B, C, D, E という5つのノードがあり、
「AとBは関係がある(関係の分類:X)」
「BとCは関係がある(関係の分類:X)」
「CとDは関係がある(関係の分類:X)」
「DとAは関係がある(関係の分類:X)」
「AとEは関係がある(関係の分類:Y)」
「BとDは関係がある(関係の分類:Z)」
という事を表現したいのです。

図:等幅フォントでないと崩れてしまうと思いますが、一応…。
E +---+
| | |
A-B-C-D
| |
+-----+

ここで私が考えたのは、テーブル「node」と「edge」を用意します。nodeには、"ノードID", "ノード名"(A~E等) フィールドを作り、edgeには "ノードID1", "ノードID2", "関係" フィールドを作ります。

node :
1, A
2, B
3, C
4, D
5, E

edge :
1, 2, X
2, 3, X
3, 4, X
4, 1, X
1, 5, Y
2, 3, Z

このように記録しておけば、ネットワーク図をデータベース化することができると思います。
ただ、この場合、edgeテーブルで 1,2,X と 2,1,X は、同じ関係を違う表現で表記してしまうので、混乱の元になってしまいそうです。また、edgeテーブルから「Aと関係があるノードをリストアップしたい」場合も、何だかスマートではない気がするのです。

こういった事例では、どのようにデータベースを設計すると良いのでしょうか?

# MySQLカテゴリで質問させて頂きましたが、Postgresの独自機能により解決できるパターンもありましたらご指摘頂ければ幸いです。

このQ&Aに関連する最新のQ&A

A 回答 (2件)

No1です。


すいません関係にたいしてさらに分類があるんですね。
この場合【edge関係】の中に持つ分類(x,y,z)をさらに外だしにして別テーブルにすると正規化完了かと思いますが、
物理テーブルの時には使い勝手を考えると正規化を崩したほうがいいかもしれませんね。
    • good
    • 0

すいません、スペースが詰まっているので、まちがっているかもしれませんが、


edgeに方向性がないとするならば、
A->BとB->Aが冗長だということですよね?

ならばedgeごとにIDを付与して、そのedgeIDに対してノードがかならず二つぶら下がるという関係にしてはどうでしょうか?
【】←これがエンティティだとして。

【edge】1--2【edge関係】n--1【ノード】

こんな感じですが。
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す


人気Q&Aランキング