《数据库设计规范》(参考Word)

神州泰岳数据库设计规范北京神州泰岳软件股份有限公司2010年11月11日文档属性文档变更文档送呈目录1 前言 (6)2 数据库的设计方法及流程 (7)2.1 设计方法 (7)2.2 设计流程 (8)2.2.1 需求分析阶段 (8)2.2.2 概念结构设计阶段 (9)2.2.3 逻辑设计阶段 (9)2.2.4 物理设计阶段 (9)2.2.5 数据库实施阶段 (10)2.2.6 数据库运行维护阶段 (10)2.2.7 建模工具 (10)3 数据库设计规范 (11)3.1 数据库规范化的五个要求 (11)3.1.1 要求一：表中应该避免可为空的列 (11)3.1.2 要求二：表不应该有重复的值或者列 (11)3.1.3 要求三：表中记录应该有一个唯一的标识符 (12)3.1.4 要求四：数据库对象要有统一的前缀名 (12)3.1.5 要求五：尽量只存储单一实体类型的数据 (12)3.2 对象命名规范 (13)3.2.1 规则 (13)3.2.2 表命名规范 (14)3.2.3 字段命名规范 (14)3.2.4 索引命名规范 (15)3.2.5 分区命名规范 (16)3.2.6 视图/物化视图命名规范 (16)3.2.7 触发器/函数/存储过程命名规范 (17)3.3 数据库编程规范 (17)3.3.1 书写规范 (17)3.3.2 注释规范 (20)3.3.3 语法规范 (23)3.3.4 SQL性能规范 (26)3.3.5 JOB使用规范 (34)3.4 索引使用规范 (34)3.4.1 创建索引原则 (34)3.4.2 索引使用建议 (35)3.4.3 总结 (40)3.5 分区表使用规范 (40)3.6 物理设计规范 (41)3.6.1 环境配置 (41)3.6.2 数据库配置 (41)3.6.3 其他参数配置 (42)3.6.4 控制文件 (42)3.6.5 日志文件 (43)3.6.6 表空间及数据文件设计原则 (43)4 数据库安全规范 (45)4.1 用户密码规范 (45)4.2 用户权限规范 (48)4.2.1 不同应用分配不同帐号 (48)4.2.2 删除或锁定无关帐号 (48)4.2.3 限制SYSDBA远程登录 (48)4.2.4 限制业务用户权限 (48)4.2.5 对用户的属性进行控制， (48)4.2.6 启用数据字典保护 (48)4.3 数据库监听规范 (49)4.3.1 需要时为监听设置密码 (49)4.3.2 需要时设置信任IP集 (49)5 数据库评审 (50)5.1 评审范围 (50)5.2 评审标准 (50)6 附录 (53)6.1 用户权限分配规范 (53)6.2 数据库安装文档 (53)6.3 分区实践文档 (53)1 前言为明确公司项目中数据库逻辑设计及物理设计的内容和流程，特制定本规范，供数据库设计、开发及维护人员参考。

本规范属于参考性规范，由DBA组制定。

2 数据库的设计方法及流程2.1 设计方法数据库设计方法目前可分为四类：直观设计法、规范设计法、计算机辅助设计法和自动化设计法。

其中，新奥尔良法是目前公认的比较完整和权威的一种规范设计法。

新奥尔良法将数据库设计分成需求分析（分析用户需求）、概念设计（信息分析和定义）、逻辑设计（设计实现）和物理设计（物理数据库设计）。

目前，常用的规范设计方法大多起源于新奥尔良法，并在设计的每一阶段采用一些辅助方法来具体实现。

以下是两种常用的规范设计方法：一、基于E-R模型的数据库设计方法。

该方法是由P.P.S.chen于1976年提出的数据库设计方法，其基本思想是在需求分析的基础上，用E-R（实体—联系）图构造一个反映现实世界实体之间联系的企业模式，然后再将此企业模式转换成基于某一特定的DBMS的概念模式。

二、基于3NF的数据库设计方法。

该方法是由S·Atre提出的结构化设计方法，其基本思想是在需求分析的基础上，确定数据库模式中的全部属性和属性间的依赖关系，将它们组织在一个单一的关系模式中，然后再分析模式中不符合3NF的约束条件，将其进行投影分解，规范成若干个3NF关系模式的集合。

其具体设计步骤分为五个阶段：a)设计企业模式，利用规范化得到的3NF关系模式画出企业模式；b)设计数据库的概念模式，把企业模式转换成DBMS所能接受的概念模式，并根据概念模式导出各个应用的外模式；c)设计数据库的物理模式（存储模式）；d)对物理模式进行评价；e)实现数据库。

2.2 设计流程以规范性设计为例，把数据库设计流程分为以下几个阶段：A.需求分析阶段：综合各个用户的应用需求(现实世界的需求)。

B.概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。

C.逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。

然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。

D.物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。

E.数据库实施阶段F.数据库运行与维护阶段2.2.1 需求分析阶段需求收集和分析，得到数据字典描述的数据需求和数据流图描述的处理需求。

需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。

需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。

常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。

分析和表达用户需求的方法：主要包括自顶向下和自底向上两类方法。

采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。

数据流图（Data Flow Diagram，DFD）表达了数据和处理过程的关系。

系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。

2.2.2 概念结构设计阶段概念模型用于信息世界的建模。

概念模型不依赖于某一个DBMS支持的数据模型。

通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。

概念模型可以转换为计算机上某一DBMS支持的特定数据模型。

概念模型特点：1)具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。

2)应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。

2.2.3 逻辑设计阶段将概念结构转换为某个DBMS所支持的数据模型(例如关系模型)，并对其进行优化。

将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：一个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。

一个多对多的联系转换为一个关系模式，两个实体的码和联系本身的属性就是关系的属性，两个实体的码就是关系的码。

数据模型的优化，确定数据依赖，消除冗余的联系，确定各关系模式分别属于第几范式。

确定是否要对它们进行合并或分解。

一般来说将关系分解为3NF的标准。

2.2.4 物理设计阶段为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。

根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。

2.2.5 数据库实施阶段运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。

数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库、编制与调试应用程序、数据库试运行。

2.2.6 数据库运行维护阶段在数据库系统运行过程中必须不断地对其进行评价、调整与修改。

内容包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。

2.2.7 建模工具为加快数据库设计速度，目前有很多数据库辅助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。

3 数据库设计规范3.1 数据库规范化的五个要求3.1.1 要求一：表中应该避免可为空的列虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。

数据库在处理的时候，需要进行特殊的处理。

如此的话，就会增加数据库处理记录的复杂性。

当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。

所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。

若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。

一是通过设置默认值的形式，来避免空字段的产生。

二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。

而且，这些列在大部分情况下，都是可有可无的。

若数据库管理员遇到这种情况，建议另外建立一张副表，以保存这些列。

然后通过关键字把主表跟这张副表关联起来。

将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。

3.1.2 要求二：表不应该有重复的值或者列如进销存管理中，还需要对客户的联系人进行管理。

而一个客户的联系人可能有多个，为了解决这个问题，有多种实现方式。

若设计不合理的话在，则会导致重复的值或者列。

我们可以这么设计，把客户信息、联系人都放入同一张表中。

为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。

若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。

可是这么设计的话，会产生一系列的问题。

如客户的采购员流动性比较大，在一年内换了六个采购员。

直接修改又不利于追踪。

所以，在数据库设计的时候要尽量避免这种重复的值或者列的产生。

建议，若数据库管理员遇到这种情况，可以改变一下策略。

如把客户联系人另外设置一张表。

然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。

也就是说，尽量将重复的值放置到一张独立的表中进行管理。

然后通过视图或者其他手段把这些独立的表联系起来。

3.1.3 要求三：表中记录应该有一个唯一的标识符在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。

每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。

另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。

否则的话，很容易产生ID值不统一的情况。

另外，在数据库设计的时候，最好还能够加入行号。