MDM主数据平台之数据建模

MDM平台后续的建设思路都是围绕数据模型这个关键元数据驱动进行建设的，从数据建模再延伸到了业务规则建模，流程建模和界面建模等内容，最后扩展到外围的接口服务集成能力。建模能力是否强大，是否灵活和可扩展，往往直接影响到一个MDM平台的易用性和扩展性。

主数据原模型究竟应该是如何的？我最早画过一个元模型的图可参考：

如何进行主数据建模？对于主数据建模其本质应该是一个树状的层级可展开结构，方便进行子对象和层次的自动挂接，以适合一个主数据有多层子对象的情况。

整个主数据建模的关键过程和步骤应该如下：

1. 创建数据对象，如供应商，物料数据对象。数据对象可以有多层结构。

2. 创建数据对象的子对象，即该数据对象可以存在子对象，子对象可以并列也可以进一步缩进。

3. 创建每个数据对象或子对象的数据项信息，包括数据项目的名称，类型，其它扩展属性等。

上面三个关键步骤就能够实现基本的数据对象创建，每个数据对象和子对象对应到数据库中一张表，这个数据对象很类似我们领域设计中的领域对象。子对象单独没有存在的意义，必须连同父对象存在。对于建模中对应的各个数据项，即是实际数据表中的数据字段信息。

这样数据建模完成后可以直接形成动态Sql语句，直接创建后台的数据库表结构。

在数据对象建模中我们可以考虑增加一个文件夹创建的功能，或者说我们单独增加一个针对数据对象创建属性分组的功能，即可以将不同的属性和子对象进行分组管理。这个分组一个是方面我们进行维护和管理，一个是后续在界面建模的时候直接将不同的分组属性映射到不同的tab页签上面。

数据项本身的类型应该至少包括如下几种：

1. 简单的录入类数据类型：字符型，数字型，日期型；

2. 列表类数据类型，从下拉列表中选择：支持从数据字典中选择，也支持从独立的另外数据表对象中选型；

3. 跳窗选择型：即支持关联到另外一个外部数据表对象；

4. 文件型：支持上传文件，注意可以支持一个数据对象上传多个附件文件的能力；

5. 表格型：对于数据对象维护过程中，子对象应该默认映射到表格类型；

对于列表数据类型往往还需要支持多级分类联动模式，比如物料信息维护的时候可能出现先选择物料大类，再选择小类，再选择次小类，就存在三个小拉列表框的联动关系。

以上是最基本的数据项类型的维护能力，其次是基础的字段完整性校验能力，其中就包括了场景的是否为空检验，数字类型检验，长度检验，值大小检验，自定义脚本检验（if a>0 and b>0 then c>0）等。这些可以确保数据录入的基础完整性。

以上所有这些校验都是单条主数据记录录入的时候就可以完成的校验，其次就是多行记录之间的相互校验，最常见的就是为了避免主数据录入重复，我们需要进行相似性校验，对于相似的主数据给出提醒。比如在录入供应商录入的时候我们可以根据名称进行相似性校验，在物料信息录入的时候可以根据规格型号，参数组合进行相似性验证等。相似性校验功能既可以用于在数据清理阶段的查重，也可以用于后续的新数据录入和修改检查。

还有就是跨多个数据对象之间的校验，比如当存在在途数据的时候，供应商的类型或名称不允许变更或删除，这就是最常见的外部业务规则检验，对于这种能力也需要进行支持。

一个完整的主数据模型定义，实际是应该包括了数据类元数据，业务规则类元数据和界面类元数据，列入界面上应该展现什么样子，展现和布局规则等都属于界面元数据。这些也可以在数据模型维护的时候进行统一维护。如果按这个思路，那么买个数据项的维护应该有三大类元数据信息维护（数据类，业务规则类，界面展现类）。

而对于对象这个层面的主数据，也还需要进行额外属性信息的维护，其中包括了数据集成类（数据采集，数据分发，集成接口等），关联关系类（该数据对象和其它数据对象的管理关系），数据类（对应的数据库，数据源或数据表信息的定义）。

元数据定义完成后要达到的一个效果就是可以生成底层的数据库表，可以用来自动化生成界面，可以用来做数据此采集和集成，同时还可以根据业务规则进行主数据质量管理。