数据库设计规范

1、目的软件研发数据库设计规范作为数据库设计的操作规范， 详细 描述了数据库设计过程及结果， 用于指导系统设计人员正确理解 和开展数据库设计。适用范围术语定义DBMS数据库管理系统，常用的商业DBMS有 Oracle, SQLServer, DB2 等。数据库设计：数据库设计是在给定的应用场景下，构造适用 的数据库模式， 建立数据库及其应用系统， 有效存储数据， 满足 用户信息要求和处理要求。概念数据模型：概念数据模型以实体 - 关系 （Entity-RelationShip, 简称 E-R） 理论为基础， 并对这一理论进 行了扩充。 它从用户的观点出发对信息进行建模， 主要用于数据 库概念级别的

2、设计，独立于机器和各DBMF品。可以用SybasePowerDesigner 工具来建立概念数据模型（ CDM）。逻辑数据模型： 将概念数据模型转换成具体的数据库产品支 持的数据模型，如关系模型，形成数据库逻辑模式。可以用Sybase PowerDesigner工具直接建立逻辑数据模型（ LDM，或 者通过CDM转换得到。物理数据模型：在逻辑数据模型基础上，根据DBMS!点和处理的需要， 进行物理存储安排， 设计索引， 形成数据库内模式。 可以用 Sybase PowerDesigner 工具直接建立物理数据模型(PDM，或者通过 CDM / LDM转换得到。数据库设计原则按阶段实施并形成该阶

3、段的成果物一般符合3NF范式要求；兼顾规范与效率使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准数据库设计目标规范性：一般符合 3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应用系 统的性能要求。紧凑性：例如能用 char(10) 的就不要用 char(20) ，提高存 储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。易用性：数据库设计清晰易用，用户和开发人员均能容易地 理解。设计过程规范数据库设计过程包括如下阶段：数据分析、概念设计、逻辑 设计、物理设计、实施与运行维护。如下图：数据分析阶段在数据分析阶段（一般在项目的需求分析或者系统设计阶段

4、进行），应注意搜集和分析数据相关的内容， 并形成相关成果物，包括数据流图和数据字典等，以此作为数据库设计的基础和依 据。数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。 数据字典则对数据流图中的各 种成分进行详细说明，作为数据流图的细节补充。数据字典一般 应包括对数据项，数据结构、数据存储和数据处理的说明。数据流图示例：数据字典示例：1. 数据项条目数据项编号：D01-001数据项名称：凭证编号别名：凭证流水号符号名：PZBH数据类型：数值型长度：4取 值范 围：19999其余略。2. 数据结构条目数据结构编号：DS01-003数据结构名称：会计分录别名：分录

5、简述：记帐凭证的基本组成成分组成：科目代码+借贷方向+金额其余略。3. 数据存储条目数据存储编号：F01数据存储名称：记账凭证来源：由凭证处理产生组成：凭证日期+凭证类别+凭证编号+附件张数+会计分录+制证+主管+审核概念设计阶段1.1.1目的在数据分析的基础上，使用 E-R模型技术，将现实世界中的客观对象抽象为实体和关系，形成概念数据模型（CDM。CDM可以从更高层次地理解系统、以及技术人员可用于和用户交流， 和用户达成共识，所以必须完成这一阶段的工作。CDM示例：1.1.2方法和过程使用 Sybase PowerDesigner 来编写 CDM文档。1、小型系统的设计可采取集中式模式设计法

6、。根据需求由一个统一机构或人员设计一个综合的全局模式， 形成模型的单一视图。 它强调统一与 一致，因此适合于小型或并不复杂的系统。2、大型系统的设计可采取视图集成法（局部-集成方法）。将一个单位分解成 若干个局部应用，先对每个局部作局部模式设计，建立各个部分 的视图即分E-R图，然后以各视图为基础进行集成。集成过程需对视图作修正，然后合并成全局概念模式， 这种方法能较好地反 映需求，适用于大型系统的设计。逻辑设计阶段1.1.3目的将E-R模型转换DBM豉持的数据模型，包括关系模型、网 状模型、层次模型、对象模型等等。常用的DBMSI关系数据库， 因此要转换为关系模型。1.1.4方法和过程可以用

7、 Sybase PowerDesigner 直接将 CDM专换为LDM从理论上来说，转换过程一般有7个步骤：转换强实体转换弱实体转换1:1关系转换1： N关系转换M N关系转换多值属性(Multi-Valued Attribute )转换 n 元关系(n-ary Relation )E-R模型和关系模型的映射如下:E-R模型关系模型实体类型关系1： 1或1： N关系类型外键M N关系类型两个外键n兀关系类型n个外键简单属性属性复合属性简单属性的集合多值属性关系和外键关键属性主键/唯键物理设计阶段1.1.5目的基于给定的DBMS建立面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不

8、但与具体的DBMS有关，而且还与操作系统和硬件有关。1.1.6方法和过程可以用 Sybase PowerDesigner 直接将 CDM/LDlM专换为 PDM 对于关系模型来说，进行物理数据库设计主要包括：使用逻辑模型建立一系列的表（如果在CDM和LDM中使用中文，应在转换后使用英文）；使用索引以提升性能；实施约束和安全限制；对数据进行分区和分布式处理等。概念数据模型规范设计原则1.1.7 易于理解1、实体、属性的命名要求中文名简明清晰，英文代码统一 用大写，中间用下划线分隔。2、对于同含义的实体或属性名，英文缩写要求一致。3、命名应遵循公司标准或项目最佳实践，以增强人们对系 统间信息交换和

9、共享的理解。4、需要在实体名中明确提示的信息可以在中文名后用括号 标出。5、各个实体类属性的排列顺序尽量遵循统一的规则，比如 最前面是标识号，最后面是人员或日期等。6、对于属性值在业务需求中有明确规定范围、列举值的， 要通过约束予以反映。7、实体间关系的命名也要遵循实体命名规则，因为这些关 系可能在后续的设计中转化为一个实体。8、对于具有强制校验的关系，要在设计工具中明确标出， 复杂关系应配以文字叙述说明。9、在多个表中冗余的字段应保持命名的一致性。不同名称 之间应有较明显的区别，避免混淆和误操作。10、对于实体自身存在相互依赖的属性， 需要建立递归联系11、适当使用扩展依赖来补充说明实体间的

10、联系。1.1.8 完整性概念数据模型应包含实体、属性、关系三部分内容。概念模 型阶段的完整性原则主要是对这三要素的充分识别：实体：包括能够被清楚辨识的事物 , 如保险合同，被保人， 操作员等； 或者需要固化的流程类信息， 如任务流 （需要记录一 次任务完成的时点和出入口） ；或者等待人工或系统处理的操作 类信息， 如保全申请、理赔申请等； 或者计算类信息， 例如针对 一个理赔责任（实体 1）的每个费用明细 （实体 2）的一次计算， 此时计算结果需要作为一个实体保存下来。关系：是实体之间的关联。有一对一，一对多，多对一，多 对多这几种。对于需求中明确需要固化的联系多个实体的复杂关 系，或者具有一

11、定属性数据的关系，可以作为一个实体来处理， 例如映射表和路由表。 当然，这种设计也可以放到物理数据模型 设计环节来做。属性：实体具有的属性。一个实体可以由若干个属性描述。 例如投保人实体有一个客户号、客户姓名、出生日期等特性。CASE工具使用要求1、应使用 Sybase PowerDesigner 工具进行概念数据模型设 计（CDM模型）。常用的几种关联如下图所示：2、由于 PowerDesigner 自身的限制 （如命名字段长度限制） ， 不要求能够从CDM直接导出PDM,但应尽量细化填写工具中提供 的输入域，以利于后续设计时对概念模型的理解。3、层次布局清楚，线条间隔明显，尽量使用上下分层

12、模式， 避免网状图。4、没有关系相联结的实体集尽量分到不同设计页面或项目， 对于复杂的设计图， 可以将其中相对集中的一部分抽离到单独页 面（CDM），原页面中用椭圆形图示代表。例如下图，其中自动、人工核保有相对集中的一组实体和关 系，可以单独抽离出来。物理数据模型规范本章实际上包含逻辑数据模型和物理数据模型设计的两部 分内容。逻辑模型设计主要是将概念模型向关系型数据库转换并 对其进行优化。 数据库的物理模型的设计主要指确定数据存放位 置和存储结构， 包括确定字段 （数据类型、 长度、 精度） 、关系、 索引、日志、 备份等数据的存储分配合存储结构， 确定系统配置 等工作。设计原则论述从逻辑模型

13、和物理模型设计时需要遵循的规则。1.1.9 范式化在针对CDM图进行细化和模式分解时，一般需符合遵循3NF, 消除数据冗余、更新异常、插入异常和删除异常。但为了满足部分查询效率， 通常可以将常用字段属性在部分 表中作冗余， 例如销售员工号和姓名通常需要在保单信息查询中 同时显示到前台，那么姓名这个字段就可以在保单表中做冗余， 但应用层应在更新这些信息的实体表的同时， 也将含有这些信息 的关联表对应字段同时更新，以保证这些冗余信息的准确性。另外，数据库结构特性是静态的，应留有扩充余地，使系统 容易改变。1.1.10 数据驱动这个原则通常与系统应用层设计结合考虑。 采用数据驱动而 非硬编码的方式，

14、 许多策略变更和维护都会方便得多， 大大增强 系统的灵活性和扩展性。这在保险系统中通常表现为各种参数 表。例如业务系统与外部系统的对账逻辑要访问外部数据源 （ 文 件、XML文档、其他数据库等），不妨把相应的连接和路径信息 存储在参数配置表里。如果用户界面执行工作流之类的任务（ 发送通知书、打印发票、修改记录状态等 ） ，那么产生工作流的数 据也可以存放在数据库里。 角色权限管理也可以通过数据驱动来完成。事实上， 如果过程是数据驱动的， 将非常方便流程类需求 变更的修改和实现。1.1.11 完整性1. 使用主键实现实体的完整性。 主键尽量不要使用用户录入 的值， 而是系统生成的值， 因为一旦录

15、错， 既影响新值进入数据 库，也不方便修改旧值， 通常只能删除整条记录， 影响了用户响 应效率和增加数据库维护负担。2. 使用外键实现参照完整性。对于固有规则，从数据库层面 来保证数据的完整性更加严谨， 但要注意对于违背外键约束而不 能进入数据库的数据要在系统实现时考虑如何返回详细的错误 信息。另外，需给必要的常用的外键建立索引。3. 使用约束和触发器实现用户定义完整性。如非空、限定范 围或者机构号等数据集检索。4. 使用查找控制数据完整性控制数据完整性的最佳方式就是限制用户的选择。 只要有可 能都应该提供给用户一个清晰的键值列表供其选择。 这样将减少 键入代码的错误和误解同时提供数据的一致性。 某些公共数据特 别适合查找：国家代码、状态代码等。1.1.12 灵活性和效率1. 适当建立视图，视图名称应以“v_”开头。2. 如果两个实体之间存在多对一关系， 而且还有可能转化为 多对多关系， 那么最好一开始就设置成多对多关系。 否则从现有 的多对一关系转变为多对多关系相对复杂。3. 对地址和电话考虑采用多个字段。4. 选择数字类型和文本类型的字段长度应尽量充足。5. 物理模型考虑对于大数据量的表，增加机构、日期等字段 方便后续做数据分片或集群。6. 如果业务数据采用分库存储， 不同库中的表名尽量不要重 复，以便需要时建立跨库