RDBのテーブルをグラフに移す ― 行→ノード、外部キー→関係、中間テーブル→関係

導入

既存のRDB（リレーショナルデータベース）のデータをグラフデータベースに移行したい、という場面はよくあります。ここでは、RDBの要素がグラフのどの要素に対応するかを整理します。

説明

RDBの要素	グラフの対応
テーブルの1行（レコード）	1つのノード
列（カラム）の値	ノードのプロパティ
外部キー（1対多の関係）	リレーションシップ
中間テーブル（多対多の関係）	リレーションシップ（テーブル自体は不要になる）

第3章で見た「Person」と「Friendship」の例を思い出しましょう。RDBでは、多対多の関係を表すために Friendship という中間テーブルが必要でした。

graph TB
    subgraph rdb["RDB"]
        PT["Person表<br/>id, name"]
        FT["Friendship表<br/>person_id, friend_id, since"]
    end
    subgraph graph["グラフ"]
        PA["(:Person)"] -- "KNOWS<br/>since: ..." --> PB["(:Person)"]
    end

グラフに移行すると、この中間テーブルはリレーションシップそのものに置き換わります。中間テーブルが持っていた追加の列（たとえば「知り合った日付」）は、そのままリレーションシップのプロパティ（since）として引き継げます。

一方で、1対多の関係を表す外部キー（たとえば Movie テーブルが director_id 列で Person テーブルを参照する、など）も、同じように [:DIRECTED] のようなリレーションシップに置き換えられます。

移行の際によくある注意点として、次の2つを押さえておきましょう。

RDBでは「テーブルが違えば別の実体」ですが、グラフでは同じ実体を表す情報は1つのノードに統合するのが基本です（たとえば Customer テーブルと Employee テーブルの両方に存在しうる「人」は、共通の Person ノードにまとめられないか検討する）。
RDBの正規化（重複を避けるために表を分ける設計）とグラフのモデリングは目的が異なります。グラフでは「よく一緒にたどられる情報」を意識してモデルを作るほうが、クエリのしやすさにつながります。

この章では、グラフとして考える基本の型、リレーションシップへのプロパティの持たせ方、インデックス・制約、よくある落とし穴、そしてRDBからの移行の考え方を学びました。次章では、いよいよ最短経路の探索やグラフアルゴリズム、実際のアプリケーションからNeo4jを使う方法など、より実践的な話題に進みます。