布莱恩·贝瑞|2015年3月4日
在我的最后一篇文章中，我在实施主数据管理解决方案时讨论了五个最关键的成功因素。在列表的顶部是警告：“不要创建另一个信息筒仓。”这意味着什么？为什么这重要？我们称之为“MDM”的新系统是什么不同的？
我将“信息孤岛”定义为具有以下特征的应用程序：
- 该应用程序有自己的数据库。
- 数据库是高度标准化的，因为数据模型的设计者努力减少数据复制。
- 身份在数据库中发明，因为客户，产品，用户都需要主键来标识系统内的记录。
- 域逻辑控制大多数，如果不是全部，数据质量要求，因为封装了数据库外的业务逻辑促使重复使用。
这些原则中的每一个都对自定义应用程序具有完美的意义。但是如果在主数据管理解决方案中使用它们，您将制作另一个信息筒仓，您将在您开始的地方返回。
当然，我们的主数据管理解决方案将包括一个数据库“MDM Hub”，它将是系统中数据驻留的中心位置。但我们需要设计一种不同的数据库模型，这与我们为企业设计的许多其他系统不同。这个数据模型应该是什么样子的?有三种建模方法需要考虑。我会解释每一种，然后告诉你哪种是最好的，以及为什么。
一种注册表方法是轻量级模型，其中仅将指针存储在主数据集线器中。我们在具有此模式中仅捕获集线器中的最小属性，并且需要使用数据的消费者在其他地方寻找权威数据源。基本上，这种MDM模式旨在存储任何内容，仅识别消费者在哪里获取数据。当实现数据治理时，这效果不佳，因为MDM系统未定义数据治理团队的管辖权。
一种事务方法代表了来自注册表的频谱的另一端，它有助于解决对“垃圾进出的垃圾，垃圾出来”的常见恐惧，这是如此多的初级计时器的体验。交易的想法是，应在紧密控制的环境中创建主数据，这在主数据创建过程上强加严格，并确保所有数据都在前面收集。这种方法听起来很值得，直到你考虑建立这样一个系统的东西：你可以建立一个新的ERP系统。这是直接到另一个信息筒仓的经典陷阱！
一种联邦方法表示注册中心和事务之间的中间地带。认为这是“保持本色”的选择,因为我们要把主数据的来源与尽可能少的翻译需要,我们要利用源在MDM身份,将源系统的名称与源系统的标识符。联合方法认识到，为了让数据治理团队进行有效治理，它需要足够的主数据属性来辨别MDM hub的关键差异，但不是全部。
这是联合模型如何工作的示例。假设我们有五个客户主数据来源：3个ERP（JD Edwards Enterprise One，SAP和Dynamics AX），1个CRM（Salesforce）和一个网站使用的自定义SQL解决方案。联邦设计将决定：
- 名为“源系统”的实体，其成员将定义数据源(即JDE、SAP、AX、SFDC、SQL)
- 名为“Customer”的实体，其成员的标识将是源系统的实际Id值的组合，并以源系统代码本身为前缀(即“JDE-100054”，“SAP-000005478”，“SQL-1”)。如果使用实际的源系统Id，那么这些MDM标识符在联邦模型中是唯一的。
- 如果这些记录代表公共客户，则帮助主数据的管制的一些附加属性。这需要由业务利益相关者定义，而不是数据库管理员。
- 在MDM解决方案中创建金色记录的解决方案。此解决方案应根据匹配规则匹配成员，并将其作为所提出的单位组合在一起。这些记录的共同分组是对金色记录的参考。例如，解决方案应作为源的父母呈现具有金色记录的层次结构。
- mdm - 100:“必威电子BlumShapiro”
- JDE-100054：“Blum Shapiro＆Co”
- SAP-0000005478：“Bl必威电子umshapiro”
- SQL-1：“Bloom Shapiro”
这种工作方式的优点包括:
- 因为我们“按原样”引入源数据，所以可以快速将数据加载到MDM hub中。
- 联合MDM解决方案可以生成绑定传统报告的报告，因为它们使用相同的主数据。
- 您的数据管理团队按原样处理数据，不需要转换或标准化，并且有足够的数据开始定义数据质量规则。
- 解决方案很好地定位源系统同步，因为MDM和目标的权威记录之间存在一对一的关系。
您的主数据管理程序的联合MDM数据模型是最接入门的最佳方法。设计简单，易于企业用户掌握，并避免创建另一个数据筒仓。事实上，它只是从筒仓聚合并分组用于匹配，协调和一致性。最重要的是，这种方法很快就能得到一些东西。它让你的治理团队他们可以触摸和感受。MDM倡议必须快速向业务提供价值，并执行此操作必须尽快相关。
下次，我会讨论MDM如何与CRM不同，以及为什么您应该将CRM视为“只是另一个主数据来源”。
