# Neo4jの機能と実践的な使い方 🎨 ホワイトボードに描いた業務の絵が、ほぼそのままデータベースのスキーマになる——それがグラフモデリングの醍醐味です。 🏷️ タイトル: グラフモデリング手法(ホワイトボードモデル → 物理モデル) 🔗 URL: 📘 概要 グラフデータモデリングは、業務ドメインの「絵」を段階的に物理グラフモデルへ落とし込む手法です。Neo4jの公式ガイドは、概念モデル → 実装 → リファクタリングという流れと、RDBモデルからの移行、性能を高める設計の選択肢を体系的に示します。設計レビューで毎回問題になる論点に答えを与えます。 ⚙️ 機能の説明 モデリングは大きく次の段階で進みます。 ・概念設計: ドメインの実体を洗い出し、ノードと、それらをつなぐリレーションシップ(動詞)を決める ・実装: ホワイトボードの絵をそのままノード・ラベル・型・プロパティに対応づける ・リファクタリング: クエリパターンに合わせて反復的にモデルを改善する 最大の判断ポイントは、イベントを「中間ノードとして具象化(reify)」するか「直接エッジ」にするかです。 ・直接エッジ(`(:User)-[:ORDERED]->(:Product)`): 関係が単純で属性が少ないとき ・中間ノード(`(:User)-[:PLACED]->(:Order)-[:CONTAINS]->(:Product)`): 1つのイベントに複数の参加者・明細・状態・時刻が絡むとき 命名は「ラベル=単数の名詞」「リレーションシップ型=大文字スネークの動詞」を基本にします。 🛠️ 実践的な使い方 注文に「数量」「価格」「ステータス」が必要なら、関係ではなく中間ノードに具象化します。 ```cypher CREATE (u:User {id: 'u1'})-[:PLACED]->(o:Order {id: 'o1', status: 'shipped', at: datetime()}) CREATE (o)-[li:CONTAINS {qty: 2, price: 9.99}]->(p:Product {sku: 'sku1'}) ``` 不正検知では「口座・デバイス・電話番号・住所」をノード化し、共有関係をエッジで張ります。 ```cypher MATCH (a1:Account)-[:USED]->(d:Device)<-[:USED]-(a2:Account) WHERE a1 <> a2 RETURN a1, a2, d ``` 💡 ユースケース 不正検知で共有デバイス・住所からリングを発見する、ECで注文を中間ノード化して明細・配送・返品まで追う、といった「業務の絵=スキーマ」の設計に直結します。 ⚠️ 注意点 ・「すべてを中間ノードに」も「すべてを直接エッジに」も極端です。クエリパターン(どう辿るか)から逆算して決めます。 ・後から大量データのリファクタリングは高コストです。主要クエリを先に想定してモデルを固めましょう。 ・RDBの正規化の癖でテーブル相当のノードを作りすぎると、トラバーサルが冗長になります。 #Neo4j# #DataModeling#