Neo4j: The Definitive Guide

第4章. モデリングとリファクタリングのパターン

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

グラフ・モデリングの原則をマスターしたところで、他のモデリング・パターンを探求する準備ができた。これらのパターンをいつ適用すべきかを認識し、その長所と短所を吟味することを学ぶ。遅かれ早かれ、ユースケースやモデルの進化に伴ってグラフのリファクタリングも必要になるだろう。そこで、この章の後半では、リファクタリング・パターンを実践的なアプローチで説明する。

ハイパーゲッジNウェイ関係

新しいトレンドがある-誰もが曲のカバーに興味を持っているようだ。ElectricHarmonyは、リスナーが自分の好きな曲のカバーを簡単に発見できる新機能を導入することで、この流行に乗りたいと考えている。この機能は、お気に入りの曲が本当にカヴァーなのか、もしそうならオリジナル・アーティストは誰なのかを発見するのにも役立つはずだ。あなたは、このユースケースをモデル化するために、もう一度チームとホワイトボードに向かうことになる。

図4-1のように、アーティストの録音したトラックがカヴァーであるかどうかを、Track のARTIST の関係で指定することから始めるのが、最もわかりやすい方法である。

図4-1. ARTIST リレーションシップを定量化して、トラックがカバーかどうかを示す

良いモデリングプラクティスには、既存のユースケースを再検討し、リファクタリングがそれらに（おそらく不利な）影響を与えていないかどうかを確認することが含まれる。あなたはすぐに、重要なユースケースであるトラック・アーティストのフェッチを思い出す。これまでのところ、ElectricHarmonyは常にトラックのオリジナルアーティストを表示する方向に傾いており、あなたはそれを変えたくない。しかし、この情報がリレーションシップのプロパティにコンテナされているため、Neo4jは、TRACK からすべてのARTIST リレーションシップをトラバースし、cover プロパティの値を調べ、大部分を破棄するという余分な作業を行っている。それは大きな問題ではないが（トラックが極端に多くのアーティストを持つことは稀であるため）、あなたのチームはこれが正しい解決策であるとは感じていない。

その代わりに、前章で学んだリレーションシップの粒度に基 づいて、新しいリレーションシップ・タイプを導入することにした：COVERED_BY （図4-2参照）。

図4-2. COVERED_BY は、アーティストがトラックをカヴァーしたという事実を表すために導入された新しいリレーションシップ・タイプである。

これにより、重要なユースケースは変更されない。Neo4jがカヴァーをフェッチする、あるいは逆に、特定のアーティストがカヴァーしたすべてのトラックを発見する必要があるとき、COVERED_BY リレーションシップを横断する。

そのトラックのどのバージョンを演奏したアーティストでも発見する場合はどうだろうか？パターンに両方のリレーションシップ・タイプを含めるだけで、Neo4jは両方をトラバースする： ...