6000字详解数据模型设计方法和管理流程

数据模型是整个系统的核心，是所有开发工作的基础。所有的分析与设计都是参考数据模型进行的，数据模型的设计决定了系统的设计。

一般来说，经过多年的信息化建设，企业已经积累了众多系统的应用级数据模型，这些数据模型是企业重要的资产，若被复用和不断丰富，将会提高系统的研发效率和准确性。

本文进行了数据管理技术领域的探索，研究了数据模型的设计和管理流程，以及在设计模型时需要考虑的数据安全、数据质量、数据标准和运维需求。

01 数据项标准化

大部分企业仍有一些系统是独立建设，独立建模，不能很好地复用模型。模型不能复用的最大障碍是各系统对于同一业务概念，命名存在不相同的情况，或者虽然命名相同但数据类型定义不相同的情况。

例如对于一个实体中的“币种”属性，这个属性存储的是什么样的数据？可能各系统不同，有的系统存储币种是2位数字代码，有的存储国标的3位数字代码，有的存储国标的3位字母代码，有的可能直接存储币种的中文名称。这就是所谓“同义不同字，同字不同义，义同字不同，字同义不同”的状况。

这种状况给各系统的开发人员理解模型和系统间数据消费带来了困惑，因此，减少开发人员之间的沟通成本，提升模型复用的第一步就是进行数据项的标准化，使之命名规范、定义精确、业务含义明确。

1、英文缩写管理

一个数据项通常由多个英文单词组成，因此需要将英文单词的缩写进行标准化。英文缩写的标准化是数据项标准化的基础。

2、数据项类别管理

目前，各系统物理模型中各数据项的命名或者没有规范，或者有规范也仅仅是在该系统内使用，从其名字上无法准确判断其存储的数据的类型，例如前文提到的币种（CCY）这个数据项，从其名字难以看出存储的是什么类型的数据，因此在标准化数据项的同时需要对数据项进行分类。

在新建数据项时，必须选择其所属的数据项类别，并且数据项类别是数据项名称的前缀。对于存量的各应用的数据项，应指定这个数据项的数据项类别，但不强制数据项类别作为数据项的前缀。

通过分析研究，数据项类别可分为如下的12类：

3、敏感信息管理

在现有的数据模型设计过程中，并不标识一个字段是否保存敏感数据，因此从物理模型中并不能识别该表是否保存有敏感数据，从而提前做好应对措施。

因此在数据项设计时，应考虑敏感数据的管理。数据项应有三个跟敏感数据相关的属性：脱敏标识、脱敏级别和脱敏函数。

在进行表设计时，如果表关联了有脱敏标识的数据项，则在物理模型中很容易识别，因此可以在设计阶段考虑对存储的敏感数据的处理方式。

4、数据项标准化

标准化的数据项与数据标准、数据项取值、数据项类别、英文缩写并不是各自孤立的，而是相互有联系的。例如币种代码名称为COD_ISO_CCY，其中COD表明是编码类的，后面的英文缩写ISO表明是国际标准，CCY表示货币，整个数据项的含义就是国际标准货币编码。

标准化的数据项与数据标准、数据项取值、数据项类别、英文缩写的关系如下图：

5、数据项取值标准化

目前，各系统对于同一业务含义的数据项的取值，并没有进行统一。同一业务含义的数据项，取值范围不同的话，给后续系统间的数据交换带来了困扰。因此数据项标准化的同时，需要对其取值进行标准化。

如果企业有已发布的企业数据标准，在设计和标准化数据项时，将这些企业数据标准以基础数据项取值的方式进行管理。若一个基础数据项的取值范围是某个数据标准所规定的取值范围，则这个基础数据项与承载这个数据标准的数据项取值进行关联，通过这种方式实现企业数据标准的落地。

应用级的一般数据项并不能直接关联基础数据项取值。应用的表中字段若想引用基础数据项取值，只有如下两个方式：

• 直接引用关联了所需数据项取值的基础数据项。
• 新建应用级一般数据项，这个一般数据项引用一个基础数据项。这个基础数据项关联了所需的数据项取值。

02 数据模型管理与设计

1

逻辑设计模型

应用系统模型设计人员在构建应用级逻辑数据模型（C级）时，应按如下流程进行设计：

• 1、选择参考模型。应用系统在设计时，应先查询逻辑数据模型库中是否有可复用的模型，若有则可复用已有逻辑模型，若没有合适的C级模型可复用，也可以不选择参考模型。若应用已关联应用级逻辑模型，则应选择已有的逻辑模型，并在此基础上进行修改。
• 2、识别实体和新增数据项。应用设计人员通过对应用需求进行分析，识别出实体和数据项信息，并分析逻辑模型中哪些实体和数据项应是本次新增。若需要新增数据项，则应查询基础数据项中是否已有所需的数据项，如有则引用，若无则新增一般数据项。
• 3、绘制ER图。在完成识别实体和新增数据项之后，就可以进行逻辑模型的设计，绘制各实体之间的关系。
• 4、新增或修改逻辑模型的实体及数据项。在设计逻辑模型过程中，需要对逻辑模型中的实体进行调整，或新增或修改原有的实体。系统应对实体属性进行一致性检查，即实体属性必须来自基础数据项或本应用维护的一般数据项。
• 5、完成逻辑模型设计。在完成逻辑模型的实体调整后，再根据其业务特性，将逻辑模型与具体的业务对象进行关联，并将其归于具体的业务模块，就完成了逻辑模型的设计。

2

物理模型设计

物理模型必须源自一个本应用的应用级逻辑模型。在设计物理模型时需要对表的管理参数、表的属性及存储参数进行全面的考虑和设计。若已有所需的物理模型，则可以在原有的基础上进行修改。

在设计物理模型时，需要输入表使用方式、表的清理策略、表的备份策略、表数据预期增长数、是否热表等信息，满足中心对表的管理需求。同时还要输入与表的性能密切相关的物理属性信息和物理存储信息，例如是否VOLATILE表、APPEND标识、表组织方式等表属性信息，首次分配空间大小、二次分配空间大小、PCTFREE和FREEPAGE、PADDED等物理存储参数信息。表的属性信息和物理存储参数信息将会成为投产脚本的一部分。

因此一个应用的物理模型设计流程如下：

• 1、逻辑模型转换成物理模型。应用系统建立物理模型时，需从该应用的逻辑模型转换得到，即物理模型应遵循逻辑模型。一个逻辑模型转换为物理模型应是代码级的转换。
• 2、索引设计。将逻辑模型转换为物理模型后，物理模型仅仅具备了基本的信息，尚需根据业务需要、性能要求进行物理表的索引设计。设计索引时，需要考虑索引的字段顺序、字段升降序、是否唯一索引、是否聚簇索引等，同时对于数据量较大的表，还需要考虑索引是否分区、分区个数等。
• 3、其它性能优化设计。对于复杂的业务、数据量较多的表，还需更多的性能优化设计。例如表是否需要分区、如何分区、是否需要分表等等。对于业务数据存储具有某种特点的表，还需要设定其物理存储参数，例如表空间的存储参数来提升性能。
• 4、物理模型提交审批。完成物理模型的设计后，会提交进行审批。审批人员根据逻辑模型库和基础项信息，对应用级逻辑模型、物理模型及其所引用的数据项进行检查，检查应用级逻辑模型所引用的逻辑数据模型是否合适，物理模型的设计是否合理，应用建立的一般数据项是否必要等等。
• 5、物理模型的实施。当物理模型通过审批后，系统可以根据审批通过的物理模型信息，生成物理表的建表脚本，应用系统开发人员可对生成的SQL脚本进行适当的修改，然后在目标数据库中执行建表脚本。

3

表管理及属性参数考虑

在传统的数据模型设计中，主要考虑物理模型的表结构、主键的设计，从其数据模型设计中看不到运维相关的信息，例如表的组织方式、表是否清理和清理策略相关信息、是否备份及备份策略相关信息、表访问方式信息、物理存储相关信息等。但是这些信息跟表的访问速度，系统的整体性能息息相关，通常一个表的访问速度下降会直接影响到整个系统的响应速度和整体吞吐量。

3.1  表属性参数管理

对于在运行时，新产生的数据都是插入表的末尾的，不会插入已有数据中间的表，可以指定该表的APPEND属性为YES，让数据库直接把数据插入表的末尾，避免从已有数据块中查找可用空闲空间，从而加快该表数据的插入速度。

对于表数据大起大落，并且对该表的数据的访问方式总是通过主键访问的表，对这种类型表，通过主键访问是最优的。但在程序投产时，程序执行BIND时，由于该表几乎没有数据，数据库优化器认为全表扫描是最优的方式，就会给程序BIND为全表扫描。

对于这种类型的表，由于全表扫描不是最优的访问方式，因此在该表数据较多时，全表扫描会严重影响访问性能。因此可以设置该表的VOLATILE属性为YES，这可以强制数据库系统总是通过主键访问该表，即便对于非BIND的程序的SQL语句，数据库系统也直接按主键进行访问，避免分析这些SQL的执行计划的开销，从而提高访问速度。

表的组织方式，通常有行组织、列组织和哈希组织方式。表的组织方式，对表的访问性能有较大的影响。联机交易系统通常按行组织数据，联机分析系统按列组织数据。对于联机交易系统中，数据量较大，表数据不增长或增长缓慢，且主要是按照主键访问的表，除了传统的按行组织数据外，还有一种更好的哈希组织方式。

访问哈希组织数据的表时，DBMS先根据主键计算出一个哈希值，根据哈希值直接定位记录的物理地址，就可以访问一条记录，只需要两个GETPAGE操作，比起传统的通过主键索引访问表的方式，大大减少了GETPAGE次数，提升了表的访问性能。

3.2 表管理属性管理

下面几个问题跟表结构无关，但在进行物理模型设计时，提前进行考虑，并做好设计，才会从容应对生产运维问题。

• 1、这个表是否是是联机访问，还是联机和批量均会访问?
• 2、联机访问的并发度是多少，批量访问时并发度是多少？
• 3、表的数据是否需要清理？需要保存多长时间？清理频次是多少？在什么时间点进行清理？清理规则是多少？
• 4、表的数据是否需要备份？备份范围是什么？按什么频次进行备份？备份方式是什么？在什么时点进行备份？备份规则是什么？

对于主要是批量访问的表，则可以考虑给表多建几个索引以提升批量程序的性能，但如果主要是联机访问的表，过多的索引则会影响联机交易的性能，因此给表建立索引时，提前考虑表的访问方式很重要。

对于联机访问并发度高的热表，如果其数据修改频率较低，且数据增长量缓慢，如果这个表还满足表数据较少，例如少于一万条，则可以考虑将该表设计为内存表，让DBMS系统将该表数据都加载到缓冲区中，并且不会被替换出缓存，通过减少对物理磁盘的访问次数，来提升访问性能。

表中的数据如果仅仅保存保证满足业务运行所需的数据，将不需要的数据从表中清除，让表轻装上阵，也会提升表的访问性能。如果数据可以清理，则要考虑清理频次，如果每天产生的数据量较多，则可以考虑每天进行清理一次。

如果每天产生的数据不多，也可以考虑其它的清理频率，例如每月清理一次。如果表中数据不能清理且表中数据较多，则可以考虑进行分区或者分表。

对于表中的业务数据，如果是相对固定，即便丢失也对业务的影响较小，并且也很容易恢复，例如币别表、国别表等数据，则可以不备份表中数据。若表中数据丢失，会对业务产生较大影响的表的数据，则应考虑合适的备份策略和备份周期。

3.3 物理存储参数管理

表空间参数值设置的是否合适，也会影响表的访问性能。对于表数据很大的表，单个分区的表可能满足不了性能，就需要考虑分区。如果分区，则需要考虑如何分区，确定分区键字段，分区个数，每个分区的大小等等。

表的数据增量方式和聚簇索引字段的顺序，也会影响表空间的参数设置。若增加的表数据主要增加在表的末尾，则可以考虑将FREE PAGE的参数设置成较大的值，将PCTFREE参数的值设置为较小的值，以充分利用存储空间。

若表增长的数据是分散在表中的，则可以考虑将FREE PAGE的参数设置成较小的值，将PCTFREE参数的值设置为较大的值，减少对表进行REORG的操作，以保证DBMS在预取数据时，尽可能一次将相关数据都读入内存，减少磁盘IO次数，提升表访问性能。

建立表空间时，还需考虑磁盘分配的策略。对于表数据增加很快的表，可以考虑将每次分配的空间设置为较大的值，以避免频繁的分配空间操作。对于表数据增长缓慢的表，可以将每次分配的空间设置为较小的值，以避免空间浪费。

同时表空间的页大小也会影响表的性能。若表的记录很大，例如达到1.5KB，若将页大小设置为4K则不合适，因为每页数据存储的记录数太少，会让系统访问该表时产生较多的GETPAGE操作。

若表的记录很小，才几十字节，将页大小设置为8KB，也可能会有性能问题，因为一页中存储过多的记录，在某些数据库中也会由于产生锁竞争而影响性能。

4

表索引考虑

在传统的物理数据模型设计中，可能只会考虑建立表的主键索引。在数据架构管理系统中，在对运维参数进行管理之后，会让设计人员在考虑表的运维参数的过程中，若发现对表有针对性的新的索引需求，则在模型设计时，提前设计相应的索引。

并且表数据的增量大小、聚簇索引字段的顺序、表空间存储参数的设置，都是互相影响的，因此需要综合权衡考虑。

5

数据模型设计图形化

目前进行数据模型设计时，不能使用工具进行图形化的ER图设计，只能在系统中录入表的属性信息、表的主键和索引信息，对于表之间的关系，并不能直观地展现出来。

如果一个模型中表的数量较少，尚能通过描述信息理解表之间的关系，若模型中表的数量较多，通过描述信息来梳理表之间的关系，很容易迷失在表之间的关系之中，让人对该模型有一种只见树木不见森林的感觉，而且不能图形化表示的数据模型让数据模型的使用人员难以对模型产生一种总体上的理解，并且在后续查漏补缺时也不易发现遗漏的表之间的关系。

因此在进行数据模型设计时，需要系统提供一个图形化的ER图设计工具。使用ER图设计工具，可以很方便地在模型中建立实体和实体的属性，标识实体的主键，建立实体之间的主外键关系，并且可以标识关系的类型（1:1,1:n或m:n）。

使用ER图工具来设计模型，既可以提高设计的效率，也很容易让模型使用人员理解模型，降低了设计人员与使用人员的沟通成本，提高总体的工作效率。即便后续需求发生变更，需要调整模型时，也很容易把模型中相关的表一起修改，避免了目前修改模型时，由于修改一处表结构而遗漏对相关的表结构的同步变更而反复修改模型的问题。

03 总结与展望

系统设计人员在设计数据模型时，对业务含义相同的数据项复用已有基础数据项，从而有效消除数据异构，逐步结束“同义不同字，同字不同义，义同字不同，字同义不同”的状况，可以显著提升数据质量，进而增强数据管控和数据治理能力。

企业对数据安全、数据质量、数据标准的要求，在设计时应予以落地，同时在设计模型时从多视角进行考虑，将运维阶段数据管理要求也融入到数据模型中，保证研发和运维一体化，将以往在运维阶段才暴露的问题在设计阶段予以充分考虑和有效规避，提升数据模型的设计质量，提升系统运行的稳定性，有效规避数据架构方面的风险，提升数据架构质量。

未来，使用图形化的ER图设计工具，既可以让设计人员提高设计的效率，也可以让模型使用人员更容易理解模型，降低了设计人员与使用人员的沟通成本，提高总体的工作效率。并且即便后续需求发生变更，需要调整模型时，也很容易把模型中相关的表一起修改，避免了目前修改模型时，由于修改一处表结构而遗漏对相关的表结构的同步变更，而反复修改模型的问题。

随着各应用持续提供各细分领域参考数据模型，中心级参考模型将更为丰富，系统设计人员在进行数据模型设计时，对业务场景相似的数据模型，将有可复用的逻辑数据模型，尤其是基本信息实体，数据模型的设计和管理将更加高效。