第3章. モデルの決定を再検討する
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
グラフモデリングは直感的なプロセスであるが、ビジネスにおけるユースケースを明確に理解する必要がある。リレーショナルスキーマの設計とは異なり、柔軟性があり、固定規則がないため、最初は戸惑うかもしれないが、プロセスに慣れてくると、やりがいのある練習であることがわかるだろう。
第1章で作成したグラフを使って、この後のクエリを試してみよう。
依存関係
曲、アルバム、アーティスト、そしてそのジャンルを含むデータセットが与えられ、リレーショナルデータベース管理システム(RDBMS)用のスキーマを設計したいとしよう。あなたはおそらく、おなじみの正規化規則を適用し、似たような構造モデルに行き着くだろう。1を適用し、図3-1のような類似性のある構造モデル(テーブルとカラムの名前付けは異なるかもしれない)を作成することになるだろう。
図 3-1. RDBMSのスキーマ
これをグラフとしてモデル化するにはどうすればよいだろうか?熟練したグラフモデラーとしてのあなたの答えは、「依存関係だ!」であろう。本当か?そうだ。図3-2から図3-4は、3つのグラフモデルを示している。
図3-2. モデルAはジャンルをアーティストのプロパティとしてモデル化する。
図3-3. モデルBでは、ジャンルはノードで、アルバムはプロパティである。
図3-4. モデルCでは、TRACK_VERSION ノードとラベルとしてのジャンルがある。
データセットにエンティティを追加すれば、可能なモデルの数は増える。どのモデルも間違ってはいない。その適否はユースケースに依存する。だからこそ、ベテランのグラフモデラーとして次に言うことは、"グラフにどんな質問に答えてほしいのか?"なのだ。ユースケースによって、どのモデルがグラフに求める質問に答え、効率的なクエリを実行するのに最適化されるかが決まる。
ヒント
他のことと同様に、シンプルにすることを強く勧める。十分なモデルを作るが、それ以上は作らない。
グラフモデルはいつでもリファクタリングすることができる。グラフモデルは、ビジネスの変化に合わせて常に進化していかなければならない。リファクタリングが必要になるのは、主に以下のような場合である:
-
新しい種類のデータ
-
新しいユースケース
-
データ量が急増する
-
ビジネスドメインが進化または変化する
図3-2から図3-4のモデルがすべて有効だとしたら、どれを選ぶべきか?どれが「正しい」のか?それはユースケースに依存する!今、あなたの主なユースケースは次のようなものだ: ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access