グラフデータベースを使用したマスタデータ管理

Question

私は、顧客に関するすべての関連情報を保存するためのマスターデータベースを構築しています。私はNeo4jを使用しています。

以下は、私たちのモデルのサンプルです。我々はPersonを持っており、3つのモバイルアプリケーションに登録することができます。 （App.01、App. 02、App. 03 - 私たちはCPFキーを使用します、それはSSNのようです）。これらのアプリでは、ユーザーは電子メールで登録することができます。したがって、Emailエンティティによって表されます。これらのユーザーは、Addressエンティティで表される複数のアドレスを持つことができます。

質問です： 私は誰かが人に関するすべての「ベスト」な情報を求めてMDMデータベースを照会する場合、私は例えば返す、IMO、マスタデータを構築していたよう： 名：ジョン ベスト電子メール：EMAIL2（それはそれを使用して2つのアプリを持っているので） ベストアドレス：ADDR1（それはそれを使用して牽引のアプリを持っているので）

だから私は「最高」、電子メールであるかを定義するためにいくつかのheuristisを構築するつもりですがと住所。この目的のために

、私はいくつかのオプションがあります。

1. 私はJohnからemail2にしてaddr1にエッジを作成することができます。だから、MDMのユーザーがJohnから "最高の"アドレス/電子メールを取得することは容易になるだろう。

2. 私は残りのAPIエンドポイントを作成し、クエリ時にこのヒューリスティックを作成することができました。

グラフデータベースまたはデザインMDMデータベースの使用経験がある人はいますか？ それは良いアプローチですか？

この質問は質問に対する補数である：Using Neo4j to build a Master Data Management

Answer 1

アプローチ1（Nは人の数である2N余分な関係、について）基本的に冗長な情報の多くを追加し、また、より複雑なコーディングが必要になります人のアプリへの変更を処理するまた、情報が重複して保存されるときはいつものように、矛盾が入り組んでいないことに特に注意する必要があります。しかし、「最良の」連絡先情報を照会する方が速いはずです。

アプローチ2は、DBを同じサイズに保ちますが、 "最高の"連絡先情報を取得するには、より複雑で低速なクエリが必要です。しかし、人のアプリや連絡先を変更するのは簡単です。

どのアプローチを使用するかを決定するには、DBサイズが問題であるかどうかを検討し、ユースケースとその頻度を検討する必要があります。

ここでは、DBサイズが問題でない場合の簡単なヒューリスティックです。 Gは人の「最高の」連絡先情報を取得する頻度で、Mはあなたのアプリや連絡先情報を変更する頻度です。上記の考慮事項を考慮して、G/Mの値があるしきい値（K）を超えている場合は、アプローチ1を選択します。