数据库设计规范
- 格式：docx
- 大小：26.25 KB
- 文档页数：13
概述
目的
软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。
适用范围
术语定义
DBMS：数据库管理系统，常用的商业DBMS有Oracle, SQL
Server, DB2等。
数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
概念数据模型：概念数据模型以实体-关系(Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。可以用Sybase
PowerDesigner工具来建立概念数据模型（CDM）。
逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。可以用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或者通过CDM转换得到。
物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。可以用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者通过CDM / LDM转换得到。
数据库设计原则
按阶段实施并形成该阶段的成果物
一般符合3NF范式要求；兼顾规范与效率
使用公司规定的数据库设计软件工具
命名符合公司标准和项目标准
数据库设计目标
规范性：一般符合3NF范式要求，减少冗余数据。
高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。
紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。
易用性：数据库设计清晰易用，用户和开发人员均能容易地理解。
设计过程规范 数据库设计过程包括如下阶段：数据分析、概念设计、逻辑设计、物理设计、实施与运行维护。如下图：
数据分析阶段
在数据分析阶段（一般在项目的需求分析或者系统设计阶段进行），应注意搜集和分析数据相关的内容，并形成相关成果物，包括数据流图和数据字典等，以此作为数据库设计的基础和依据。数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。数据字典则对数据流图中的各种成分进行详细说明，作为数据流图的细节补充。数据字典一般应包括对数据项，数据结构、数据存储和数据处理的说明。
数据流图示例：
数据字典示例：
1. 数据项条目
数据项编号：D01-001
数据项名称：凭证编号
别 名：凭证流水号
符 号 名：PZBH
数 据类 型：数值型
长 度：4
取 值范 围：1~9999
其余略。
2. 数据结构条目
数据结构编号：DS01-003
数据结构名称：会计分录
别 名：分录
简 述：记帐凭证的基本组成成分
组 成：科目代码+借贷方向+金额
其余略。
3. 数据存储条目
数据存储编号：F01 数据存储名称：记账凭证
来 源：由凭证处理产生
组 成：凭证日期+凭证类别+凭证编号+附件张数+
{会计分录}+制证+主管+审核
概念设计阶段
1.1.1 目的
在数据分析的基础上，使用E-R模型技术，将现实世界中的客观对象抽象为实体和关系，形成概念数据模型（CDM）。CDM可以从更高层次地理解系统、以及技术人员可用于和用户交流，和用户达成共识，所以必须完成这一阶段的工作。
CDM示例：
1.1.2 方法和过程
使用Sybase PowerDesigner来编写CDM文档。
1、小型系统的设计
可采取集中式模式设计法。根据需求由一个统一机构或人员设计一个综合的全局模式，形成模型的单一视图。它强调统一与一致，因此适合于小型或并不复杂的系统。
2、大型系统的设计
可采取视图集成法（局部-集成方法）。将一个单位分解成若干个局部应用，先对每个局部作局部模式设计，建立各个部分的视图即分E-R图，然后以各视图为基础进行集成。集成过程需对视图作修正，然后合并成全局概念模式，这种方法能较好地反映需求，适用于大型系统的设计。
逻辑设计阶段
1.1.3 目的
将E-R模型转换DBMS支持的数据模型，包括关系模型、网状模型、层次模型、对象模型等等。常用的DBMS是关系数据库，因此要转换为关系模型。
1.1.4 方法和过程
可以用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建立面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。
1.1.6 方法和过程
可以用Sybase PowerDesigner直接将CDM/LDM转换为PDM。对于关系模型来说，进行物理数据库设计主要包括：
➢ 使用逻辑模型建立一系列的表（如果在CDM和LDM中使用中文，应在转换后使用英文）；
➢ 使用索引以提升性能；
➢ 实施约束和安全限制；
➢ 对数据进行分区和分布式处理等。 概念数据模型规范
设计原则
1.1.7 易于理解
1、实体、属性的命名要求中文名简明清晰，英文代码统一用大写，中间用下划线分隔。
2、对于同含义的实体或属性名，英文缩写要求一致。
3、命名应遵循公司标准或项目最佳实践，以增强人们对系统间信息交换和共享的理解。
4、需要在实体名中明确提示的信息可以在中文名后用括号标出。
5、各个实体类属性的排列顺序尽量遵循统一的规则，比如最前面是标识号，最后面是人员或日期等。
6、对于属性值在业务需求中有明确规定范围、列举值的，要通过约束予以反映。
7、实体间关系的命名也要遵循实体命名规则，因为这些关系可能在后续的设计中转化为一个实体。
8、对于具有强制校验的关系，要在设计工具中明确标出，复杂关系应配以文字叙述说明。
9、在多个表中冗余的字段应保持命名的一致性。不同名称之间应有较明显的区别，避免混淆和误操作。
10、对于实体自身存在相互依赖的属性，需要建立递归联系。 11、适当使用扩展依赖来补充说明实体间的联系。
1.1.8 完整性
概念数据模型应包含实体、属性、关系三部分内容。概念模型阶段的完整性原则主要是对这三要素的充分识别：
实体：包括能够被清楚辨识的事物,如保险合同，被保人，操作员等；或者需要固化的流程类信息，如任务流（需要记录一次任务完成的时点和出入口）；或者等待人工或系统处理的操作类信息，如保全申请、理赔申请等；或者计算类信息，例如针对一个理赔责任（实体1）的每个费用明细（实体2）的一次计算，此时计算结果需要作为一个实体保存下来。
关系：是实体之间的关联。有一对一，一对多，多对一，多对多这几种。对于需求中明确需要固化的联系多个实体的复杂关系，或者具有一定属性数据的关系，可以作为一个实体来处理，例如映射表和路由表。当然，这种设计也可以放到物理数据模型设计环节来做。
属性：实体具有的属性。一个实体可以由若干个属性描述。例如投保人实体有一个客户号、客户姓名、出生日期等特性。
CASE工具使用要求
1、应使用Sybase PowerDesigner工具进行概念数据模型设计（CDM模型）。
常用的几种关联如下图所示： 2、由于PowerDesigner自身的限制（如命名字段长度限制），不要求能够从CDM直接导出PDM，但应尽量细化填写工具中提供的输入域，以利于后续设计时对概念模型的理解。
3、层次布局清楚，线条间隔明显，尽量使用上下分层模式，避免网状图。
4、没有关系相联结的实体集尽量分到不同设计页面或项目，对于复杂的设计图，可以将其中相对集中的一部分抽离到单独页面（ＣＤＭ），原页面中用椭圆形图示代表。
例如下图，其中自动、人工核保有相对集中的一组实体和关系，可以单独抽离出来。
物理数据模型规范
本章实际上包含逻辑数据模型和物理数据模型设计的两部分内容。逻辑模型设计主要是将概念模型向关系型数据库转换并对其进行优化。数据库的物理模型的设计主要指确定数据存放位置和存储结构，包括确定字段（数据类型、长度、精度）、关系、索引、日志、备份等数据的存储分配合存储结构，确定系统配置等工作。
设计原则
论述从逻辑模型和物理模型设计时需要遵循的规则。 1.1.9 范式化
在针对CDM图进行细化和模式分解时，一般需符合遵循3NF，消除数据冗余、更新异常、插入异常和删除异常。
但为了满足部分查询效率，通常可以将常用字段属性在部分表中作冗余，例如销售员工号和姓名通常需要在保单信息查询中同时显示到前台，那么姓名这个字段就可以在保单表中做冗余，但应用层应在更新这些信息的实体表的同时，也将含有这些信息的关联表对应字段同时更新，以保证这些冗余信息的准确性。
另外，数据库结构特性是静态的，应留有扩充余地，使系统容易改变。
1.1.10 数据驱动
这个原则通常与系统应用层设计结合考虑。采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。这在保险系统中通常表现为各种参数表。
例如业务系统与外部系统的对账逻辑要访问外部数据源(文件、XML 文档、其他数据库等)，不妨把相应的连接和路径信息存储在参数配置表里。如果用户界面执行工作流之类的任务(发送通知书、打印发票、修改记录状态等)，那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来
