逻辑模型设计规范

1、目的和适用范围

1.文档目的

本文主要从“建立逻辑模型设计规范”的角度出发，着重强调和说明在逻辑数据模型的整个设计过程中应用的各种规范，期望能够从模型的可能性、规范性、稳定性等方面帮助设计人员和使用人员，最终实现逻辑数据模型的：规范性、可维护性、持续性、稳定性。

1. 适用范围

本文档适用于逻辑数据模型设计者和使用者在工作中参考使用。

2、设计规范

1.继承概念模型

为保证后期逻辑数据模型、物理数据模型的设计、维护和管理都基于统一的标准和框架体系，应该继承概念模型的设计工作和成果，充分理解，沿用概念模型中的核心内容，包括：

 主题域（包括主题的定义、内涵）；

 重要子类（每个主题的重要分类，包括层次和子类的定义等）；

 重要实体（各主题中与分类无关的重要实体）；

 重要关系（包括主题间的关系，也包括主题内的重要关系）；

 业务关键定义（对特殊、关键的业务术语、规则的定义）；

 如果在逻辑数据模型出现与概念模型不一致的情况，原则上应提交数据组做整体回顾，最终保持两者的高度一致。

2. 准确体现业务规则

逻辑数据模型的设计思路就是通过图像方式体现业务规则和逻辑，因此在整个设计过程中都需要保证业务规则的正确性和完整性，对于不同的业务规则，整理之后都应该根据具体情况转化成两种形式。

1）主外键

在逻辑模型中，数据的关联关系可以使用’主/外键’的方式表达，比如‘个人交易流水’中的‘账户号（FK）’来自‘个人存款账户’实体，所表达的业务规则‘一笔交易对应了一个账户’，‘客户’中的‘性别代码（FK）’来自‘性别代码表’，将上述业务规则转化成‘主/外键’关系时，需要注意引用的字段一定要保留‘FK’，而且必须定义cardinality（即关系的‘势’），如上述表的‘交易’和‘账户’的关系，根据具体的情况可能需要指定cardinality为1~0，1，对应的业务规则就为‘1笔交易可以不对应账户，也可以对应1个账户’，也有可能需要指定cardinality为1~1，M，对应的业务规则就为‘1笔交易一定要对应至少1个账户’。

2）关系表

除了上述可以转化成‘主/外键’关系的规则以外，还有很多业务规则体现的是多对多的关系，如‘账户’和‘客户’的关系，业务规则为‘一个客户可能没有账户，可能有1个账户，也可能有多个账户’，这种情况下可能单纯依靠‘主/外键’方式不能够完全体现，所以还需要建立‘客户和账户关系表’。体现各种可能的关系。

3.规范建立视图

随着设计工作的持续进行，模型中的实体会越来越多，相互之间的连线也会越来越复杂，因此需要进行适度的归纳，创建不同的视图便于理解和查看，一般来讲，每个主题至少要包括：

 总揽Overview

 分类Classfication

 关系Relationship

对于一些复杂，信息量比较多的主题，如客户、账户和事件等，应该根据一定的规则再做进一步的细分，如‘个人’、‘对公’、‘信用信息’等，但是需要注意，这种细分要适度，避免过于详细，人为提高模型的复杂度

4.统一符号体系

很多建模工具都会支持很多中不同的工程方法，例如ERWIN就提供了两种工程方法选择（IE和IDEF1X）,虽然本质上没有太多差异，但是如果前后不能够保持一致，会直接影响到整个模型的符号体系，并会对理解规则造成一些不必要的误会，所以应该在整个逻辑数据模型设计过程中使用统一的符号体系，比较推荐（information engineering）

5.关注美学布局

同样的模型，因为摆布和排列的不同，带给使用者的感受也会差别很多，直接影响到读者对模型的认识和理解，尽管模型中会根据很多的目的和视角将主题的实体创建不同的视图，或者进一步的细分，但是不管哪个层次的视图，因为都需要针对其中的实体摆放和布局等引起足够的重视，看是否合理和美观

6.试图级别

 命名要简单易懂：一个视图中实体不能够太多，重点要突出，最核心的实体放在最中心 的位置，非特殊的代码表尽量不保留。

 实体级别：

*‘父子’结构采用‘上.下’方式；

*‘关系’采用‘左.中.右’方式；

*‘历史’采用‘左（本）.右（历史）’方式；

 属性级别：

排列在最前面的应该是主键属性，重要、常用属性靠前排列，类似属性应集中排列；

7. 约束填写规范

模型设计会持续相当一段时间，必要的一些注释信息，对于帮助后续设计者和使用者准确理解模型非常重要，因此，需要根据项目的具体情况对模型本身以及一些重要的数据映射的填写进行规范和约束。

 模型释义

模型设计人员应该在实体和属性等不同级别上都分别撰写一些用于说明实体和属性中存储信息所包含的数据含义和业务含义。例如，‘内部机构’的实体级注释可以是‘金融机构的各级内部机构，包括对外提供服务的，也包括对内部实施管理的，也包括业务部分和业务团队等’，该实体中的‘内部机构编号’属性可注释为‘内部区机构的唯一标识，通过它可以在整个金融机构中唯一识别某个内部机构’。

 实体/属性标注

模型人员应该在进行模型设计时，对特殊实体和属性进行标注，由于模型逻辑完整性和可扩展性考虑，模型人员在定义实体时可能会设计一些没有数据来源的逻辑实体，应明确标注其为LOGICAL ONLY实体，以示区分。对于其他需要特殊标注的实体或属性，可通过模型设计工具例如颜色变更，字体变更等方式标注，也可通过文字标注说明等当时标注。

 数据映射

模型设计人员可以在实体和属性等不同级别上都分别撰写一些用于说明实体和属性中存储信息来源的重要信息，包括系统、表、甚至字段或者复杂的加工映射等。例如‘内部机构’的实体级别注释可以是‘核心系统/机构表，信贷系统/内部机构表，电子银行系统/机构代码表’，该实体中的；‘内部机构编号’属性可注释为‘核心系统/机构表/机构编号，信贷系统/内部机构表/机构代码，电子银行系统/机构代码表/机构代码’。

在处理上述两类注释信息时，应该根据具体的项目情况设计自动化工具或建立专门文档来存储和管理，可以将这些注释信息和模型统一保存在ERWIN文件中（建议实体和字段级的注释信息保存在相应级别的UDP中，实体级数据映射信息存在表级definition中，属性级别的映射信息保存在字段级notes中）然后把这些信息导出下发给所有相关人员使用；也可以不在ERWIN中进行维护，直接用外部的统一文档（excel）或者数据库方式进行填写和维护。

8.建立版本管理

除了建模工具本身提供的一些版本管理的功能以外，还应该针对模型建立一套严格的规章制度，用以支持对数据模型的维护和管理，实现专人负责，对整个逻辑数据模型的存取、修改、版本设计，审计追踪等进行严格的记录和追踪，也便于不同的人员进行工作信息的共享和任务的交接，项目具体实施过程中，可以充分利用已有的版本管理工具以及一些文件服务器等实现模型的维护、管理。

3.ERWIN模型工具使用说明

1.符号体系

ERWIN中提供两种工程方法供选择（IE和IDEFIX），这会直接影响整个模型的符号体系，在模型设计过程前应该明确符号体系。

2.Domain使用

Domain可以视为属性的数据类型，构建一个Domain组织可以方便Domain的设计和重用，增加模型设计和维护的效果的方便性，在模型设计过程中，把所有模型涉及到的属性先按照类型分类进行Domain设计，然后再按照业务含义进行分类组织，为每一类数据类型建立一个Domain，让每个实体属性选择对应的Domain，这样在修改数据类型的时候，仅仅修改Domain中的内容即可。通过Domain建立了所有属性数据类型的定义树。

3. 实体（ENTITY）

逻辑数据模型中常用实体符号约定，参见如下例图示：

 标识（Identifying）

标识关系（Identifying relationship）,即子实体依赖于父实体，父实体的键成了子实体标识的一部分。标识关系用连接两个实体间的带点实线来表示；

非标识关系（Non-identifying relationship）,即子实体不依赖于父实体，非标识关系用连接两个实体间的带点虚线来表示；

常用的标识符号约定，参见下列图标:

分类（subtype）符号表示约定，如下表中所示：

本文来源：https://www.2haoxitong.net/k/doc/8ef954372d60ddccda38376baf1ffc4ffe47e2ed.html