1

我正在建立一个主数据库来存储有关我们客户的所有相关信息。我正在使用 Neo4j。

下面是我们的模型示例。我们有Person，可以在我们的 3 个移动应用程序中注册。( App.01, App. 02, App. 03- 我们使用 CPF 密钥，它就像一个 SSN)。在这些应用程序中，用户可以使用电子邮件进行注册。所以它是由Email实体表示的。这些用户可以有多个由Address实体表示的地址。

来自 John 用户的主数据

问题是：当我正在构建主数据时，IMO，如果有人查询 mdm 数据库，询问有关某个人的所有“最佳”信息，我会返回例如：姓名：John Best 电子邮件：email2（因为它有两个应用程序使用它）最佳地址：addr1（因为它有两个应用程序使用它）

因此，我将构建一些启发式方法来定义什么是“最佳”电子邮件和地址。

为此，我有一些选择：

  1. John我可以从toemail2和 to创建一个边缘addr1。因此，MDM 的用户很容易从 John 那里获得“最佳”地址/电子邮件。

  2. 我可以构建一个 REST API 端点并在查询时创建这个启发式方法。

有人有使用图形数据库或设计 MDM 数据库的经验吗？这是一个好方法吗？

这个问题是对问题的补充：Using Neo4j to build a Master Data Management

4

2 回答 2

1

图形数据模型可以很好地存储您的主数据，但是，您的主数据很可能会以维度的形式与操作和参考数据共存。如果您决定为您的 DMD 使用图形模型，请确保您有一个定义明确的语义模型，核心维度是 MDM，通常：

  1. 产品
  2. 顾客
  3. 雇员
  4. 资产
  5. 地点

这些核心维度成为节点的属性。

另外，决定你将采用哪种 DMD 架构风格，一些流行的有：

  1. 注册表 - 图表非常适合这种风格，因为您的主数据保留在 SOS（记录系统）中，并且可以很好地在图表中表示参考。
  2. 主数据中心 - 将您的记录系统从表格转换为图表所需的额外转换。
  3. 大师-大师。- 如果您没有太多依赖于您的 MDM 的旧应用程序，则此样式非常适合图表中的 MDM。
于 2019-11-02T05:49:42.030 回答
0

方法 1 会添加很多本质上冗余的信息（大约 2N 个额外的关系，其中 N 是人数），并且还需要更复杂的编码来处理对个人应用程序的更改。而且，与往常一样，当信息被冗余存储时，您必须特别小心，以免出现不一致。但是，在查询“最佳”联系信息时应该更快。

方法 2 使数据库保持相同的大小，但需要更复杂和更慢的查询才能获得“最佳”联系信息。但是，更改一个人的应用程序和联系信息很简单。

要决定使用哪种方法，您应该考虑数据库大小是否是一个问题，并且还要查看您的用例以及它们的执行频率。

如果数据库大小不是问题，这是一个简单的启发式方法。SupposeG是您需要获取某人“最佳”联系信息M的频率，也是您需要修改某人的应用程序或联系信息的频率。如果 的值G/M超过某个阈值 ，您将选择方法 1 K，您必须在考虑到上述因素的情况下做出决定。

于 2016-04-13T19:48:16.250 回答