数据库设计规范

1 概述

1.1 目的

软件研发数据库设计规范作为数据库设计的操作规范，

详细描述了数据库设计过程及结果， 正确理解和开展数据库设计。 1.2 适用范围 1.3 术语定义

DBMS：数据库管理系统， 常用的商业 DBMS有 Oracle, SQL Server, DB2 等。

用于指导系统设计人员

数据库设计：数据库设计是在给定的应用场景下，构造

适用的数据库模式， 建立数据库及其应用系统， 有效存储数据，满足用户信息要求和处理要求。

概念数据模型：概念数据模型以实体

- 关系

(Entity-RelationShip, 简称 E-R) 理论为基础， 并对这一理论进行了扩充。 它从用户的观点出发对信息进行建模， 主要

用于数据库概念级别的设计，独立于机器和各

DBMS产品。

可以用 Sybase PowerDesigner

工具来建立概念数据模型

（ CDM）。

逻辑数据模型：将概念数据模型转换成具体的数据库产

品支持的数据模型， 如关系模型， 形成数据库逻辑模式。可

第 1 页

以用 Sybase PowerDesigner

工具直接建立逻辑数据模型

（ LDM），或者通过 CDM转换得到。

物理数据模型：在逻辑数据模型基础上，根据 DBMS特点和处理的需要， 进行物理存储安排， 设计索引， 形成数据库内模式。可以用 Sybase PowerDesigner 工具直接建立物理数据模型（ PDM），或者通过 CDM / LDM 转换得到。

2 数据库设计原则

按阶段实施并形成该阶段的成果物

一般符合 3NF范式要求；兼顾规范与效率

使用公司规定的数据库设计软件工具

命名符合公司标准和项目标准

3 数据库设计目标

规范性：一般符合

3NF范式要求，减少冗余数据。

高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。

紧凑性：例如能用 char(10) 的就不要用 char(20) ，提高存储的利用率和系统性能， 但同时也要兼顾扩展性和可移植性。

易用性：数据库设计清晰易用，用户和开发人员均能容

第 2 页

易地理解。

4 设计过程规范

数据库设计过程包括如下阶段：数据分析、概念设计、逻辑设计、物理设计、实施与运行维护。如下图：

第 3 页

4.1 数据分析阶段

在数据分析阶段（一般在项目的需求分析或者系统设计

阶段进行），应注意搜集和分析数据相关的内容，并形成相

关成果物， 包括数据流图和数据字典等，

以此作为数据库设

以图

计的基础和依据。 数据流图从数据传递和加工的角度， 形的方式刻画数据流从输入到输出的移动变换过程。

数据字

典则对数据流图中的各种成分进行详细说明， 作为数据流图的细节补充。 数据字典一般应包括对数据项， 数据结构、 数据存储和数据处理的说明。

数据流图示例：

数据字典示例：

1. 数据项条目

数据项编号： D01-001 数据项名称：凭证编号

第 4 页

别 符 长

其余略。

号

名：凭证流水号

名： PZBH

数 据类 型：数值型

度： 4

取 值范 围： 1~9999

2. 数据结构条目

数据结构编号： DS01-003 数据结构名称：会计分录 别 简 组

其余略。

名：分录

述：记帐凭证的基本组成成分 成：科目代码 +借贷方向 +金额

3. 数据存储条目 数据存储编号： F01 数据存储名称：记账凭证 来 组

源：由凭证处理产生

成：凭证日期 +凭证类别 +凭证编号 +附件张数 +

{ 会计分录 }+ 制证 +主管 +审核

4.2 概念设计阶段

4.2.1 目的

在数据分析的基础上，使用 E-R 模型技术，将现实世界

中的客观对象抽象为实体和关系，

形成概念数据模型 （ CDM）。

CDM可以从更高层次地理解系统、 以及技术人员可用于和用

户交流，和用户达成共识，所以必须完成这一阶段的工作。

CDM示例：

第 5 页

假期

Number

姓名 性别 年龄

人

Text Number

天数

开始时间

俱乐部

俱乐部名称

Characters (256)

教师 -人

学生 -人

成立时间 部长学号

Identifier_1

Date Number

教师 -休假

学生 - 俱乐部

教师 Number Number

Characters (256)

学生

年级 班级

学号 Identifier_1

教龄 级别

工号 Identifier_1

师生关系

Number

Characters (256)

Number

班主任

所属年级

班级号 Identifier_1

班级

Number

Number

4.2.2 方法和过程

使用 Sybase PowerDesigner

来编写 CDM文档。

1、小型系统的设计

可采取集中式模式设计法。根据需求由一个统一机构或

人员设计一个综合的全局模式， 形成模型的单一视图。 它强调统一与一致，因此适合于小型或并不复杂的系统。

2、大型系统的设计

可采取视图集成法（局部

- 集成方法）。将一个单位分解

建立各

成若干个局部应用， 先对每个局部作局部模式设计，

第 6 页

个部分的视图即分 E-R 图，然后以各视图为基础进行集成。集成过程需对视图作修正， 然后合并成全局概念模式， 这种方法能较好地反映需求，适用于大型系统的设计。

4.3 逻辑设计阶段

4.3.1 目的

将 E-R 模型转换 DBMS支持的数据模型，包括关系模型、 网状模型、层次模型、对象模型等等。常用的 DBMS是关系数据库，因此要转换为关系模型。

4.3.2 方法和过程

可以用 Sybase PowerDesigner

直接将 CDM转换为 LDM。

从理论上来说，转换过程一般有

7 个步骤：

转换强实体

转换弱实体

转换 1：1 关系

转换 1：N关系

转换 M：N关系

转换多值属性（ Multi-Valued Attribute

）

转换 n 元关系（ n-ary Relation

）

第 7 页

E-R 模型和关系模型的映射如下：

E-R 模型

关系模型

实体类型

关系

外键

两个外键 n 个外键

1： 1 或 1： N关系类型

M： N关系类型

n 元关系类型

简单属性

属性

简单属性的集合 关系和外键 主键 / 唯一键

复合属性

多值属性

关键属性

4.4 物理设计阶段

4.4.1 目的

基于给定的 DBMS建立面向计算机物理表示的模型，描

述了数据在储存介质上的组织结构，它不但与具体的 DBMS 有关，而且还与操作系统和硬件有关。

4.4.2 方法和过程

可以用 Sybase PowerDesigner

直接将 CDM/LDM转换为

第 8 页

PDM。对于关系模型来说，进行物理数据库设计主要包括：

使用逻辑模型建立一系列的表（如果在

CDM和 LDM

中使用中文，应在转换后使用英文） ；

使用索引以提升性能；

实施约束和安全限制；

对数据进行分区和分布式处理等。

5 概念数据模型规范

5.1 设计原则

5.1.1 易于理解

1、实体、属性的命名要求中文名简明清晰，英文代码

统一用大写，中间用下划线分隔。

2、对于同含义的实体或属性名，英文缩写要求一致。

3、命名应遵循公司标准或项目最佳实践，以增强人们

对系统间信息交换和共享的理解。

4、需要在实体名中明确提示的信息可以在中文名后用

括号标出。

5、各个实体类属性的排列顺序尽量遵循统一的规则，

比如最前面是标识号，最后面是人员或日期等。

第 9 页

6、对于属性值在业务需求中有明确规定范围、列举值

的，要通过约束予以反映。

7、实体间关系的命名也要遵循实体命名规则，因为这

些关系可能在后续的设计中转化为一个实体。

8、对于具有强制校验的关系，要在设计工具中明确标

出，复杂关系应配以文字叙述说明。

9、在多个表中冗余的字段应保持命名的一致性。不同

名称之间应有较明显的区别，避免混淆和误操作。

10、对于实体自身存在相互依赖的属性，需要建立递归

联系。

11、适当使用扩展依赖来补充说明实体间的联系。

5.1.2 完整性

概念数据模型应包含实体、属性、关系三部分内容。概念模型阶段的完整性原则主要是对这三要素的充分识别：

实体：包括能够被清楚辨识的事物 , 如保险合同，被保人，操作员等；或者需要固化的流程类信息，如任务流（需要记录一次任务完成的时点和出入口） ；或者等待人工或系统处理的操作类信息， 如保全申请、 理赔申请等； 或者计算

类信息，例如针对一个理赔责任（实体

1）的每个费用明细

（实体 2）的一次计算，此时计算结果需要作为一个实体保

第 10 页

存下来。

关系：是实体之间的关联。 有一对一， 一对多， 多对一，多对多这几种。 对于需求中明确需要固化的联系多个实体的

复杂关系， 或者具有一定属性数据的关系， 可以作为一个实体来处理， 例如映射表和路由表。 当然，这种设计也可以放到物理数据模型设计环节来做。

属性：实体具有的属性。一个实体可以由若干个属性描

述。例如投保人实体有一个客户号、 客户姓名、 出生日期等特性。

5.2 CASE工具使用要求

1、应使用 Sybase PowerDesigner 工具进行概念数据模

型设计（ CDM模型）。

常用的几种关联如下图所示：

第 11 页

2、由于 PowerDesigner 自身的限制（如命名字段长度

限制），不要求能够从

CDM直接导出 PDM，但应尽量细化填

写工具中提供的输入域， 以利于后续设计时对概念模型的理

解。

3、层次布局清楚，线条间隔明显，尽量使用上下分层

模式，避免网状图。

4、没有关系相联结的实体集尽量分到不同设计页面或

项目，对于复杂的设计图， 可以将其中相对集中的一部分抽

离到单独页面（ＣＤＭ） ，原页面中用椭圆形图示代表。

第 12 页

例如下图，其中自动、人工核保有相对集中的一组实体和关系，可以单独抽离出来。

6 物理数据模型规范

本章实际上包含逻辑数据模型和物理数据模型设计的两部分内容。 逻辑模型设计主要是将概念模型向关系型数据库转换并对其进行优化。 数据库的物理模型的设计主要指确

定数据存放位置和存储结构， 包括确定字段 （数据类型、 长度、精度）、关系、索引、日志、备份等数据的存储分配合存储结构，确定系统配置等工作。

6.1 设计原则

论述从逻辑模型和物理模型设计时需要遵循的规则。

第 13 页

6.1.1 范式化

在针对 CDM图进行细化和模式分解时，一般需符合遵循

3NF，消除数据冗余、更新异常、插入异常和删除异常。

但为了满足部分查询效率，通常可以将常用字段属性在部分表中作冗余， 例如销售员工号和姓名通常需要在保单信息查询中同时显示到前台， 那么姓名这个字段就可以在保单表中做冗余，但应用层应在更新这些信息的实体表的同时，

也将含有这些信息的关联表对应字段同时更新， 以保证这些冗余信息的准确性。

另外，数据库结构特性是静态的，应留有扩充余地，使系统容易改变。

6.1.2 数据驱动

这个原则通常与系统应用层设计结合考虑。采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。 这在保险系统中通常表现为各种参数表。

例如业务系统与外部系统的对账逻辑要访问外部数据

源 ( 文件、 XML 文档、其他数据库等 ) ，不妨把相应的连接和路径信息存储在参数配置表里。 如果用户界面执行工作流之类的任务 ( 发送通知书、 打印发票、 修改记录状态等 ) ，那么

第 14 页

产生工作流的数据也可以存放在数据库里。 角色权限管理也可以通过数据驱动来完成。 事实上，如果过程是数据驱动的，将非常方便流程类需求变更的修改和实现。

6.1.3 完整性

1. 使用主键实现实体的完整性。主键尽量不要使用用户 录入的值， 而是系统生成的值， 因为一旦录错， 既影响新值

进入数据库，也不方便修改旧值，通常只能删除整条记录， 影响了用户响应效率和增加数据库维护负担。

2. 使用外键实现参照完整性。对于固有规则，从数据库层面来保证数据的完整性更加严谨， 但要注意对于违背外键约束

而不能进入数据库的数据要在系统实现时考虑如何返

回详细的错误信息。 另外，需给必要的常用的外键建立索引。

3. 使用约束和触发器实现用户定义完整性。如非空、限

定范围或者机构号等数据集检索。

4. 使用查找控制数据完整性

控制数据完整性的最佳方式就是限制用户的选择。只要

有可能都应该提供给用户一个清晰的键值列表供其选择。

这 某

样将减少键入代码的错误和误解同时提供数据的一致性。

些公共数据特别适合查找：国家代码、状态代码等。

第 15 页

6.1.4 灵活性和效率

1. 适当建立视图，视图名称应以“ v_”开头。 2. 如果两个实体之间存在多对一关系，而且还有可能转 化为多对多关系， 那么最好一开始就设置成多对多关系。 否则

从现有的多对一关系转变为多对多关系相对复杂。

3. 对地址和电话考虑采用多个字段。

4. 选择数字类型和文本类型的字段长度应尽量充足。 5. 物理模型考虑对于大数据量的表，增加机构、日期等

字段方便后续做数据分片或集群。

6. 如果业务数据采用分库存储，不同库中的表名尽量不 要重复， 以便需要时建立跨库数据连接， 方便访问 SQL编写

和移植。

7. 控制每张表的字段数量，如果字段数量过多，考虑将

常用字段抽取出来单独建表，以提高访问效率。

8. 小数据量表和参数表可以不建索引，否则索引维护对

效率的影响可能高于全表扫描。

9. 接口用的数据表增加是否处理完成的状态标示以及日期，方便必要时手工运维。

第 16 页

6.2 CASE工具使用要求

应使用 Sybase PowerDesigner 工具进行物理数据模型设计（ PDM模型）。

层次布局和命名等要求参照概念数据模型。

示例：

7 附则

本规范由负责解释和修订。

本规范自发布之日起施行。

第 17 页