グラフデータベース 第2版

第3章 グラフを使ったデータモデリング グラフを使ったデータモデリング

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

これまでの章では、他のNOSQLストアや従来のリレーショナルデータベースと比較した場合のグラフデータベースの利点について説明してきた。しかし、グラフ・データベースを採用することにした以上、どのようにグラフをモデリングするのかという疑問が生じる。

この章では、グラフ・モデリングに焦点を当てる。最も広く採用されているグラフ・データ・モデルであるラベル付きプロパティ・グラフ・モデルの復習から始め、本書のコード例のほとんどで使用されているグラフ・クエリ言語の概要を説明する：Cypherである。グラフクエリ言語はいくつか存在するが、Cypherは最も広くデプロイされており、事実上の標準となっている。Cypherは、特にSQLのバックグラウンドを持っている人にとっては、学びやすく理解しやすい言語でもある。これらの基本を押さえた上で、グラフ・モデリングの例を見ていこう。最初の例では、システム管理分野に基づき、リレーショナルとグラフのモデリングテクニックを比較する。2つ目の例では、シェークスピア文学の生産と消費について、グラフを使って複数の異なるドメインを結びつけ、クエリを実行する。最後に、グラフを使ったモデリングにありがちな落とし穴と、グッドプラクティスをいくつか挙げて、この章を終わる。

モデルと目標

グラフを使ったモデリングを深く掘り下げる前に、一般的なモデルについて一言述べておこう。モデリングは、特定のニーズや目標に動機づけられた抽象化活動である。私たちがモデリングを行うのは、手に負えない領域の特定のファセットを、構造化して操作できるスペースに取り込むためである。世界を「ありのまま」に表現する自然な表現など存在しない。ただ、多くの目的を持って選択し、抽象化し、単純化するだけである。

グラフ表現もこの点では変わらない。しかし、他の多くのデータモデリングテクニックと異なるのは、論理モデルと物理モデルの親和性が高いことである。リレーショナル・データ管理テクニックでは、自然言語によるドメイン表現から逸脱することを要求される。まず論理モデルへと強制し、次に物理モデルへと強制する。このような変換は、私たちの世界の概念とデータベースのそのモデルのインスタンス化との間に意味的な不一致をもたらす。グラフデータベースを使えば、このギャップはかなり縮まる。

我々はすでにグラフでコミュニケーションしている

グラフモデリングは、私たちが円や箱を使ってドメインから詳細を抽象化し、矢印や行を使ってそれらを結合することでそれらのつながりを記述する傾向にあるのと自然に適合する。今日のグラフデータベースは、他のどのデータベース技術よりも "ホワイトボード・フレンドリー "である。問題の典型的なホワイトボード表示はグラフである。私たちが創造的かつ分析的なモードでスケッチしたものは、データベース内部で実装するデータモデルと密接にマッピングされる。

表現力という点では、グラフデータベースは、長年リレーショナルデータベースの実装を悩ませてきた、分析と実装の間のインピーダンスのミスマッチを軽減する。このようなグラフモデルで特に興味深いのは、私たちが物事をどのように関連づけて考えているかを伝えるだけでなく、私たちがドメインに対してどのような問いを投げかけたいかを明確に伝えることができる点である。