グラフデータモデルダイヤグラム(GDMD)

# はじめに
自分が認識している限り、グラフデータベースでは、リレーショナルデータベースの正規化のようなデータベースの設計論らしきものが確立されていません。Neo4jの公式ドキュメントのデータモデリングに関する説明を読んでみても、いくらかの例示は出されていますが、それに至る方法論や手順については十分な説明がなされていません。

関係者一同が集まってホワイトボードを取り囲んで図柄を書きながら議論を重ねていくと、自ずとグラフの原型が出てくると説明しています。確かにそうかも知れませんが、もう少しに論理的な説明がほしいところです。

聞いた話によると、海外のエンジニア達も上位レベルではOODの方法論を用いて、後は経験と勘で埋めていくそうです。それでは、グラフデータベースの実践に大きな問題があります。概念、つまり考えるための道具が揃っていないと、何から始めて、どのように進めていくのか、分からないために、コツを掴むまでかなりの無駄が発生します。

そこで、とにかく自分の理解や進め方をまとめてみることにしました。

* どのように対象を理解し、グラフの原型を書いていけばいいのか、方法や手順を経験に基づいて考えてみる。
* それぞれの過程に名前を付ける。


#グラフデータモデルダイヤグラム(GDMD:Graph Data Model Daigram)
まず、データモデリングのアウトプットに名前を付けてみました。それは、グラフデータモデルダイヤグラム(GDMD)です。グラフデータモデルダイヤグラムは、グラフデータベースで情報を蓄積していくための原型になるユニークなグラフ構造です。

![movie-data-model.png](https://qiita-image-store.s3.amazonaws.com/0/69832/a73f06d3-f0ad-f202-610b-b56c4e52e32e.png)

グラフデータベースでは、単にデータを蓄積していくわけではありません。それは、他のデータベースと決定的に異なる点です。グラフデータベースでは、ノードとノードの間を意味あるインフォーメーションで繋くことにより、ネットワークを構築していきます。

そのためには、何から初めて、どのように考え、どのように進めればいいのでしょうか。ここでは、映画データベースを例に挙げて考えてみたいと思います。

#　グラフデータモデルダイヤグラム(GDMD)の作成手順

* ステージ1:コンテキストの分析
* ステージ2:インフォーメーションチェインの分析
* ステージ3:グラフデータモデルダイヤグラム(GDMD)の作成
* ステージ4:ドメインの定義
* ステージ5:属性の定義

## ステージ1:コンテキスト分析
ステージ1では、対象の様々な事柄を短文や表、図形等を用いて網羅的な分析していきます。この段階では、抽象化や多少の重複を気にする必要はありません。例えで言うと、木を一本一本書いていくことで、やがて森の絵を完成するようなイメージですが、重要なことはすべて木を描くことより、すべての種類の木を描くことです。

生のデータや状況、事柄を観察したり、分析したりすることはとても重要ですが、物理的にすべてを吟味しようとして、意味のない反復に時間を取られないようにすべきです。漏れなく、ユニークに事象の集合として全体を網羅できれば理想です。なお、場合によって事実関係だけではなく、あるべき姿や推測などを仮置きするようなこともあり得ます。表現の方法は、単文・複文や表、図形などです。

* 俳優aが映画Aに出演した
* 俳優bが映画Aに出演した
* 俳優aが映画Aを監督した
* 監督cが映画Cを監督した
* dさんが映画Aプロヂュースした
* eさんが映画Cの脚本を書いた
* fさんdさんをフォローしている
* dさんaさんをフォローしている
等々

次のような図で表現することも可能でしょう。

![neo4j-datamodeling-1.png](https://qiita-image-store.s3.amazonaws.com/0/69832/488358ab-2b9c-0bb8-9f48-44c3c6086a9d.png)


## ステージ2:インフォーメーションチェインの分析
ステージ2では、ステージ1のコンテキストの分析に基づいて実体をユニークな対象に抽象化していきます。リレーションシップは、抽象化された実体(object)と実体の間に存在し、2つの実体を繋いて、すべての関係者に意味のあるグラフを形成するためのインフォーメーションのチェインです。

この段階で重要なことは、すべてのインフォーメーションチェインをユニークでありながら網羅的に定義することです。ここでインフォーメーションチェインは、ノードとノード間に置かれることによって、そのグラフが単独で完成されたインフォーメーションであるべきです。

表現の方法は、単文・複文や図形、表が用いられても結構です。もちろん、大に迷いもあるでしょう。どのレベルまで抽象化すべきでしょうか。俳優や監督、脚本家などを一塊で「人」と抽象化してしまってもいいのでしょうか。それは、対象とするグラフがどんな問題を解決しようとするかにもよるもので、「人」が関わる問題はすべて「人」に抽象化すべきだと、一概には言えないと思います。

* 人が映画に出演した。
* 人が映画を監督した
* 人が映画をプロヂュースした
* 人が映画の脚本を書いた
* 人が映画をレビューした 
* 人が人をフォローしている

 ![stage2.png](https://qiita-image-store.s3.amazonaws.com/0/69832/52e1b2fc-5a0f-bedd-d42b-d4f89aceef62.png)

この図で見るように人と映画の間にどのようなインフォーメーションチェイン（リレーションシップ）を引っ掛けるのかによってグラフの意味が変わります。つまり、異なる情報になります。

## ステージ3:グラフデータモデルダイヤグラム(GDMD)の作成
ステージ3では、ステージ2の分析に基づいてグラフデータモデルダイヤグラムを完成します。通常、グラフデータモデルダイヤグラムでは、属性までは記入しませんが、必要であれば主要な属性を記入しても構いません。

![movie-data-model.png](https://qiita-image-store.s3.amazonaws.com/0/69832/a73f06d3-f0ad-f202-610b-b56c4e52e32e.png)


ステージ1からステージ3までは、ステージ3に集約され、ほぼ同時並行的に進められることもあります。それは、モデリング対象に関する十分な理解が互いに共有されている場合や問題があまりにも単純すぎる場合などです。

## ステージ4:ドメインの定義
ステージ4では、ステージ3のグラフデータモデルダイヤグラムに従って、具体的にノードのラベル、リレーションシップのタイプなどの名称をユニークに定義します。物理設計と言っていいかもしれません。

Person-[ACTED_IN]->Movie
Person-[DIRECTED]->Movie
Person-[PRODUCED]->Movie
Person-[REVIEWED]->Movie
Person-[WRITE]->Movie
Person-[FOLLOWS]->Person

## ステージ5:属性の定義
ノードのラベルやリレーションシップのタイプ毎に属性キーの定義や説明を表などでまとめます。
**人(:Person)**

|属性キー|名称|説明|
|-------|----|---|
|born|出生年度|YYYY|
|name|名前|　|


#まとめ
この内容は、自分自身や他人に説明できるようにするということをゴールにしています。自分の不便を解消するために書き始めたので、別に支持を求めているわけでもありません。役に立つのであれば使って頂いて結構です。なお、この内容は、ネオテクノロジー社や所属社クリエーションラインとは一切関係のない、独自の解説です。その点はご了承ください。