数据库建设规范文档格式.docx
《数据库建设规范文档格式.docx》由会员分享，可在线阅读，更多相关《数据库建设规范文档格式.docx（13页珍藏版）》请在冰豆网上搜索。
可以是本地的、远程的或带参数的；
其数据可以
来源于一个或多个表，或者其他视图；
它是可更新的，可以引用远程表；
它可以
更新数据源。
视图是基于数据库的，因此，创建视图的前必须有数据库。
3.5外键
外键是一个关系中的一组属性（一个或多个列），它同时也是某种（相同的
或其它的）关系中的主键。
它是关系之间的逻辑链接。
3.6约束
数据库管理系统必须提供一种机制来检查数据库中的数据，看其是否满足语
义规定的条件，这些加在数据库数据之上的语义规范，称为约束。
约束又可以分
为完整性约束、唯一性约束等。
3.7主键
每张表都应该包含相同的一个或一组字段，它们都是保存在表中的、每一条
记录的唯一标识，通常这些字段（即主键）需要在建立数据表时就设定并标记。
4.命名规范
4.1规范约定
命名采用26个英文字母（一律大写）和0－9这十个自然数，加上下划线“_”
组成，共63个字符，不能出现其他字符（注释除外）。
数据库对象包括表、视图、存储过程、函数、触发器、字段、数据库文档。
对象名字由前缀和实体名称组成，长度不超过30个字符。
前缀描述对象类型，
实体名称包括系统标识等信息尽量详尽描述实体的内容，不以数字或下划线开头，对象名称中的标识用下划线“_”进行分隔。
其中“[]”内的内容表示是可选内容。
4.2表名
T_[<
系统标识>
_][<
…….>
_]<
表标识>
如：
T_NPCP_ORDER
4.3视图
V_[<
视图标识>
V_NPCP_ORDER
4.4存储过程
P_[<
][<
_]<
存储过程标识>
[_<
存储过程行为标识>
]
P_NPCP_ORDER_ADD
4.5函数
F_[<
函数标识>
函数行为标识>
F_NPCP_ORDER_ADD
4.6触发器
TR_[<
触发标识>
TR_NPCP_ORDER_ADD
4.7字段
[<
外键表标识>
字段标识>
ORDER_ID
4.8索引
IN_[<
索引标识>
IN_NPCP_ORDER_NAME
5.数据库建设过程规范
5.1概述
建库过程建议参考以下的建库流程如图1所示。
需求分析阶段综合各科学数据用户的应用需求，形成规范的需求调查表、需求规格书、功能需求表。
概念设计阶段形成独立于机器特点、独立于各个数据库管理系统产品的概念模式，用E-R图来描述。
逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。
然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图形成数据的外模式。
数据可以分为两大类：
关系数据和非关系数据，在物理设计阶段根据数据库管理系统的特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
最后进行数据（或元数据）录入。
建库过程的每一步都是对其前一步
骤的检验，对于发现的错误或偏差需要进行及时的评估，并进行修正完善。
对由
于数据库的设计而在应用当中的造成的不良影响及出现数据误差等现象进行修
缮、更新、完善。
图1数据库建设过程
5.2需求分析阶段
需求分析阶段可以分为两个步骤：
需求调查和内容分析。
数据大概分为两类数据：
关系型数据和非关系型数据（如文件，文档）。
在需求分析阶段可以对这两种数据进行不同的处理和分析。
5.2.1需求调查
数据信息来源有以下几种方法，分析系统需求分析报告书，组织调查会，咨询业务专家。
非关系型数据要分析哪几类类型，如文件的格式。
5.2.2内容分析
需求收集和分析，结果得到数据字典描述的数据需求，数据流图描述的处理需求。
数据项
数据项含义
数据类型
长度
取值范围
可选性
注释
表1数据字典规范模式
图2数据流图的表达方式
5.3概念结构设计阶段
这个阶段的任务确定建模目标，开发建模计划，组织建模队伍，收集数据资源，制定约束和规范。
5.2.1定义实体
找出潜在的实体，形成初步实体表，然后再进行必要的调整。
满足下述两条准则的事物，一般均可作为属性对待。
（1）作为“属性”，不能再具有需要描述的性质。
“属性”必须是不可分的数据项，不能包含其他属性。
（2）“属性”不能与其他实体具有联系，即E－R图中所表示的联系是实体之问的联系。
5.3.3定义关系
模型中只允许二元联系，n元联系必须定义为n个二元联系。
根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强制的或可选的）还是非确定关系、分类关系。
如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。
非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。
如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。
即在这一步工作中确定任意有关联的两个实体之间的关系类型。
5.3.4定义属性
从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。
定义非主键属性，检查属性的非空及非多值规则。
此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主键属性必须依赖于主键、整个主键、仅仅是主键。
5.3.5定义键
通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选键属性，以便唯一识别每个实体的实例，再从侯选键中确定主键。
为了确定主键和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。
找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图，确定关系中的主键和外键等。
键选择规范：
1）键设计原则：
为关联字段创建外键;
所有的键都必须唯一;
避免使用复合键;
外键总是关联唯一的键字段。
2）使用系统生成的主键,设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。
这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。
采用系统生成键作为主键还有一个优点：
当拥有一致的键结构时，找到逻辑缺陷很容易。
3）不要采用用户可编辑的字段作键（不让主键具有可更新性）在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。
通常的情况下不要选择用户可编辑的字段作为键。
4）可选键有时可做主键,把可选键进一步用做主键，可以拥有建立强大索引的能力。
5.3.6定义索引
索引是从数据库中获取数据的最高效方式之一。
95%的数据库性能问题都可
以采用索引技术得到解决。
1）如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这
组）属性上建立索引（或组合索引）；
2）如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个
属性上建立索引；
3）如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这
个（或这组）属性上建立索引；
4）逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的
非成组索引，对任何外键列采用非成组索引。
考虑数据库的空间有多大，表如何
进行访问，还有这些访问是否主要用作读写。
5）大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它
们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
6）不要索引MEMO（备注）字段，不要索引大型字段（有很多字符），这样作
会让索引占用太多的存储空间。
7）不要索引常用的小型表。
不要为小型数据表设置任何键，假如它们经常
有插入和删除操作就更别这样作了。
对这些插入和删除操作的索引维护可能比扫
描表空间消耗更多的时间。
5.3.7定义其他对象和规则
定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。
定义触发
器、存储过程、视图、角色、同义词、序列等对象信息。
最后形成的概念模型用E-R图进行表示。
5.4逻辑结构设计阶段
将概念结构转换为某个数据库管理系统所支持的数据模型（例如关系模
型），并对其进行优化。
设计逻辑结构应该选择最适于描述与表达相应概念结构
的数据模型，然后选择最合适的数据库管理系统，形成数据库文档。
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的
联系转化为关系模式。
关系模型的逻辑结构是一组关系模式的集合。
E-R图则
是由实体、实体的属性和实体之间的联系三个要素组成的。
所以将E-R图转换
为关系模型实际上就是要将实体、实体的属性和实体之间的联系转换为关系模
式，这种转换要遵循如下规范原则：
1）一个实体型转换为一个关系模式。
实体的属性就是关系的属性。
实体的
标识对应关系模型的候选码。
2）一个m:
n联系转换为一个关系模式。
与该联系相连的各实体的码以及联
系本身的属性均转换为关系的属性。
而关系模型的候选码为各实体标识的组合。
3）一个1:
n联系可以转换为一个独立的关系模式，也可以与n端对应的关
系模式合并。
如果转换为一个独立的关系模式，则与该联系相连的各实体的标识
以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
4）一个1:
1联系可以转换为一个独立的关系模式，也可以与任意一端对应
的关系模式合并。
5）三个或三个以上实体间的一个多元联系转换为一个关系模式。
与该多元
联系相连的各实体的标识以及联系本身的属性均转换为关系的属性。
而关系模型
的候选码为各实体码的组合。
6）同一实体集的实体间的联系，即自联系，也可按上述1:
1、1:
n和m:
n三
种情况分别处理。
7）具有相同码的关系模式可合并。
为了进一步提高数据库应用系统的性能，通常以规范化理论为指导，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。
确定数据依赖。
消除冗余的联系。
确定各关系模式分别属于第几范式。
确定是否要对它们进行合并或分解。
一般来说将关系分解为3NF的标准，即：
表内的每一个值都只能被表达一次。
表内的每一行都应该被唯一的标识（有唯一键）。
表内不应该存储依赖于其他键的非键信息。
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的数据
升级会员 