《数据库设计规范(19821)》由会员分享，可在线阅读，更多相关《数据库设计规范(19821)（18页珍藏版）》请在金锄头文库上搜索。
1、保密级别：绝密 机密 秘密 内部公开数据库设计规范变更记录版本号修改点说明变更日期变更人审批人V1.0创建修改点说明的内容有如下几种：创建、修改（+修改说明）、删除（+删除说明）目 录1编写目的12数据库策略12.1数据库对象长度策略12.2数据完整性策略12.3规范化设计与性能之间的权衡策略12.4字段类型的定义与使用策略13命名规范33.1数据库命名规则33.2数据库对象命名的一般原则43.3表空间(Tablespace)命名规则43.4表(Table)命名规则43.5字段命名规则53.6视图(View)命名规则53.7序列(Sequence)命名规则53.8存储过程(Procedure)
2、的命名规则53.9函数(Function)的命名规则53.10索引(Index) 命名规范53.11约束(Constraint) 命名规范54数据模型产出物规范5附录A：xml文件使用说明7附录B：保留关键字8 数据库设计规范例会制度 1 编写目的本文的目的是提出针对Oracle数据库的设计规范，使利用Oracle数据库进行设计开发的系统严格遵守本规范的相关约定，建立统一规范、稳定、优化的数据模型。参照以下原则进行数据库设计：1) 方便业务功能实现、业务功能扩展；2) 方便设计开发、增强系统的稳定性和可维护性；3) 保证数据完整性和准确性；4) 提高数据存储效率，在满足业务需求的前提下，使时间
3、开销和空间开销达到优化平衡。2 数据库策略1) 数据模型全局单一，所有公共的数据模型得到共享。2) 数据库建模要基于统一的元数据管理机制。3) 数据库设计遵循关系数据库的规范化理论。4) OLTP与OLAP分开设计。2.1 数据库对象长度策略数据库字段的长度要考虑业务对象的类型、数据库所用字符集、时间格式来设定出相对准确的长度，满足业务需要，同时保证数据库的高效，避免不必要的开销。2.2 数据完整性策略1) 必须遵循数据库设计的第二范式，根据业务需要尽量满足第三范式。2) 数据完整性尽量通过业务逻辑实现，数据库设计应尽量避免使用大量的外键约束，避免使用触发器。2.3 规范化设计与性能之间的权衡
4、策略数据的标准化有助于消除数据库中的数据冗余。如果数据冗余低，数据的一致性容易得到保证，如无特殊理由，OLTP系统的设计应当遵循第三范式，对于OLAP系统，为了减少表间连接查询的操作，提高系统的响应时间，合理的数据冗余是必要的。2.4 字段类型的定义与使用策略1) 数据类型的选用原则数据类型使用说明CHAR根据业务数据的特征决定是否使用CHAR类型，例如静态编码、固定年月日的时间字段等，避免数据变长的情况下使用CHAR类型VARCHAR2(N)Oracle数据库VARCHAR2类型，根据业务数据特征定义适当的长度，定义成偶数长度。REAL、FLOAT、INTEGER、NUEBEROracle数
5、据库必须使用NUEBERNUMBER(P,S)、NUMERIC (P, S)、DECIMAL (P, S)Oracle数据库必须使用NUMBERDATE时间类型必须使用DATEBLOB（二进制数据）、CLOB（字符数据）2) 数据类型长度的选用参考：如果以下字段类型和长度能满足设计要求，必须遵循以下字段选用原则数据类型常用类型CHARCHAR(1)本规范不推荐长度不为1的字段使用char类型VARCHAR2(N)VARCHAR2(2)VARCHAR2(4)VARCHAR2(8)VARCHAR2(10)VARCHAR2(16)VARCHAR2(20)VARCHAR2(30)VARCHAR2(40
6、)VARCHAR2(50)VARCHAR2(100)VARCHAR2(200)VARCHAR2(400)VARCHAR2(1000)VARCHAR2(2000)NUMBERNUMBER(P,S)DATEBLOB3) 常用字段定义：l 涉及销售额等金额的数值：NUMBER (16,2)l 涉及税率、比例、分成的数值：NUMBER (10,6)l 涉及货物单价的数值：NUMBER (16,6)l 涉及人数的数值：NUMBER (10)l 涉及人名的：VARCHAR2 (50)l 涉及单位名称、地址的：VARCHAR2 (100)l 涉及说明、理由、意见的： VARCHAR2 (200)l optr
7、_code，建议在业务表中增加该字段，表示操作员工号;l opt_date，建议在业务表中增加该字段，表示操作时间;l remark,建议在业务表中增加该字段，作为备用字段;l stand,建议在业务表中增加该字段，作为备注;l 描述“是、否”类型的字段命名，避免使用“IS_”开头。3 命名规范3.1 数据库命名规则数据库命名规则如下：项目简称+1位数据库类型代码+识别代码+序号数据库类型代码：1) T：业务型数据库2) A：分析型数据库3) H：历史数据库识别代码：1) DEV：开发数据库2) TEST：测试数据库如果一种类型的数据库一个数据库，则不加序号，否则末尾增加序号。如果是生产库则不
8、加识别代码，否则需要增加爱识别代码DEV或TEST如果只作历史库，部分生产、开发或者测试，则只需要项目简称+H+序号举例：出入系统业务生产库：AOCT、AOCT1、AOCT2出入系统业务开发库：AOCTDEV、AOCTDEV1、AOCTDEV2出入系统业务测试库：AOCTTEST、AOCTTEST1、AOCTTEST23.2 数据库对象命名的一般原则数据库对象的命名应该以最少的字母达到最容易理解的意义。如果没有特殊规定，数据库对象及其属性的命名应满足如下条件：1) 命名不推荐使用保留字；2) 数据库实体统一采用英文命名；3) 对象命名长度最好不要超过18个字符，缩写要易于理解，符合通用的习惯，
9、例如部门编码缩写：dept_code,组织机构编码缩写：org_code。4) 前导字符为A至Z5) 非前导字符可以为：l A至Zl 0至9l _（下划线字符）3.3 表空间(Tablespace)命名规则1) 表空间l 表空间的描述规则统一为：TS_业务规则。l 例如：TS_CRM等2) 临时表空间临时表空间的描述规则统一为：TS_TMP_业务规则。3.4 表(Table)命名规则1) 业务数据库中的数据表命名规则：子系统简称_业务含义2) 分析型数据库中的数据表操作型数据存储区中的数据表：ODS_业务规则。事实表：FACT_业务规则。维表数据：DIM_业务规则。中间表：MID_业务规则。3
10、.5 字段命名规则1) 主键与外键必须使用相同的字段名和数据类型(含数据精度);尽量少使用联合主键；主键的命名有一定的含义，不要只写成“ID”之类的字段名；主键的生成规则有一定的含义，比如前缀+流水号规则，不要使用自增主键，不要使用数字类型。2) 凡与业务含义无关的主键一律加_ID后缀。如PARTY_ID;3) 凡是具有业务含义的编码（或代码）等字段一律加_CODE后缀。如PARTY_CODE;4) 凡是名称、姓名等字段一律加_NAME后缀。如PARTY_NAME;3.6 视图(View)命名规则命名规则：VW_子系统简称_业务含义。3.7 序列(Sequence)命名规则命名规则：SEQ_表
11、名。3.8 存储过程(Procedure)的命名规则命名规则：PRC_子系统简称_业务含义。3.9 函数(Function)的命名规则命名规则：FUN_子系统简称_业务含义。3.10 索引(Index) 命名规范命名规则：IDX_表名_有关字段。不允许使用自动生成的索引。3.11 约束(Constraint) 命名规范主键(Primary Key Constraint)：PK_表名，需要考虑主键长度太长无法创建的情况，表名部分要尽量简化且易于区分。外键(Foreign Key Constraint)：FK_表名_字段_被参照 (referenced) 表名,需要考虑外键长度太长无法创建的情况，
12、表名部分要尽量简化且易于区分。4 数据模型产出物规范1) PDM文件数据模型产出物统一为PDM文件。各个项目根据情况，可以区分概念模型和物理模型；2) XML文件数据模型需要产出相应的XML文件，通过PDM进行转换，具体xml使用说明参照附录A。3) 建表脚本数据库的建表脚本作为数据库设计的规范产出物，需要严格进行版本控制，有统一的命名规范，命名规范如下：l 创建表脚本：项目简称_create_table.sql。l 修改表脚本：项目简称_alter_table.sql，在原有表的基础上做的修改，增加字段、主键、外键、索引等。l 创建存储过程脚本：项目简称_create_prc.sql，所有涉
13、及存储过程的创建和修改，必须实时更新此文件。l 创建函数脚本：项目简称_create_fun.sql，所有涉及函数的创建和修改，必须实时更新此文件。l 创建视图脚本：项目简称_create_view.sql, 所有涉及视图的创建和修改，必须实时更新此文件，并且如果在PDM文件中有视图的创建，需要更新PDM文件。注：修改表脚本只作为备忘，所有表结构的修改，都必须实时更新“PDM文件”和“创建表脚本”，便于项目实施时表结构的导入。附录A：xml文件使用说明表结构设计文件是指在进行表，视图，以及约束的设计过程中所产生的文件。格式：xml文件 上面两行格式固定，主要用于数据结构的列表展示，每一个表结构文件都要引用 文件根节点 文件二级节点，下面允许有多个元素 文件三级节点，指项目设计中的模块，na
