1.7　主数据应用场景

本节介绍元数据模型在主数据管理中的应用，以加强对元数据的理解。主数据是指在企业各个部门中可以被共享、相对稳定不经常修改、准确度要求更高、可唯一识别的数据。常见的主数据包括：组织机构、客户、码表或者数据字典等各种基础数据。数据字典的业务逻辑处理非常简单，一般将数据字典存放在两张数据库表中，提供从这两个表中读取数据的服务即可。简单数据字典的数据库表结构如图1-10所示。

图1-10　简单数据字典的数据库表结构

T_CodeTypeDef用于保存字典分类，例如，性别类型、证件类型、职业类型等，由 code、name、description三个字段构成描述一类字典类型。T_CodeDef用于保存每一类字典的值，例如，性别类型三个可选值（男、女、未知），证件类型的可选值（身份证、军人证、驾照、学生证等），也通过code、name、description描述每一个字典条目。通过这两个表基本上能够满足大部分应用中的数据字典需求，但是总有比较复杂的参数结构，超过code、name和description这三个属性可描述的范围，例如，描述职业需要如职业分类和职业风险级别等属性，还有大量可配置的参数类型、不同参数类型有不同字段（属性）等。如果超过了以上两个表提供的属性范围，通常不仅需要设计独立数据库表保存，还要单独开发服务，以访问这些个性化参数。如果这些参数比较重要，需业务人员来维护，那么还要单独开发适合业务人员的操作界面，从前台到后台都要有相应程序来支持。如果个性化参数种类比较多，开发工作量将非常大。通过元数据模型配置Dna对象，描述每一个参数的数据结构，利用同一套实例服务即可实现各类参数增删改查操作的统一管理。利用元数据定义/配置Dna对象，可以描述默认的数据字典结构，只包含code、name、description这三个基本属性，代码如下。

Dna对象mdDna是一个两层Dna结构，根节点包含四个属性。其中前面三个对应到T_CodeType表中的code、name、description，比较容易理解，这里多出来的defDnaCode（CellFixedName.DEF_DNA_CODE的常量值为“defDnaCode”）属性，用来区别其他不同结构的主数据结构，即通过defDnaCode来区分不同的Dna。

接着创建了默认的主数据值结构Dna对象mvDna，包含code、name和description三个属性。这个默认两层结构的主数据结构可以支持上述表：T_CodeTypeDef和T_CodeDef的结构。当根据需要定义更多的主数据结构时，只需修改对象mvDna。例如，职业类数据字典多出的两个属性：职业分类和风险级别，可以通过在上述Dna对象mvDna下增加两个Vd对象来实现，代码如下：

一般系统中都存在菜单管理，菜单管理也属于主数据管理范畴。菜单结构是树形递归结构，可以为菜单创建Dna，将Dna的属性cursive值设置为true，创建菜单Dna代码如下：

在该菜单定义中，每一个菜单都有code、name、description三个属性，除此之外，一个菜单有功能代码：functionCode，用于表示当菜单单击时，应该打开哪一个功能界面，也就是意味着每一个functionCode与一个实际功能的程序代码相关联。mdCode和mvCode是菜单相关联的某个主数据类型和主数据值，使得每一个functionCode关联到一个主数据值，实现对functionCode的更多扩展。

例如，实现某个Dna的实例录入功能，菜单项的功能代码functionCode无法表达哪一个Dna，这时可以通过mdCode和mvCode来设置额外的参数。不同功能代码，需要的额外信息的数据结构可能不同，因此，需要明确菜单关联哪一类扩展主数据及该扩展主数据值，由functionCode对应的功能程序解释主数据值的含义。

leaf表示该菜单项是否为叶子节点，如果是叶子节点，表示要关联到功能代码functionCode、mdCode和mvCode，否则，就是简单菜单分类组织项。

将Dna的cursive属性值设置为true，即可定义出各种递归结构，如企业组织机构、国家地址等。利用Dna可以定义出有任何层次结构的数据结构，能够表达出绝大部分应用所需要的领域模型。平常应用中的数据结构，都是有层次的树形结构（很少有环状的图结构），都可以用Dna来描述。

可能读者会问，使用Map结构也可以表示任何结构，与使用Dna表示没有本质上的区别，为什么还需要引入Dna和Inst这两个类呢？答案是，Map结构只能解决实例部分的数据结构，缺少元数据模型的定义部分，没有元数据定义部分就没法实现通用的服务。