1 编写目的

本文的目的是提出针对Oracle数据库的设计规范，使利用Oracle数据库进行设计开发的系统严格遵守本规范的相关约定，建立统一规范、稳定、优化的数据模型。

参照以下原则进行数据库设计：

1) 方便业务功能实现、业务功能扩展；

2) 方便设计开发、增强系统的稳定性和可维护性；

3) 保证数据完整性和准确性；

4) 提高数据存储效率，在满足业务需求的前提下，使时间开销和空间开销达到优化平衡。

2 数据库策略

1) 数据模型全局单一，所有公共的数据模型得到共享。

2) 数据库建模要基于统一的元数据管理机制。

3) 数据库设计遵循关系数据库的规范化理论。

4) OLTP与OLAP分开设计。

2.1 数据库对象长度策略

数据库字段的长度要考虑业务对象的类型、数据库所用字符集、时间格式来设定出相对准确的长度，满足业务需要，同时保证数据库的高效，避免不必要的开销。

2.2 数据完整性策略

1) 必须遵循数据库设计的第二范式，根据业务需要尽量满足第三范式。

2) 数据完整性尽量通过业务逻辑实现，数据库设计应尽量避免使用大量的外键约束，避免使用触发器。

2.3 规范化设计与性能之间的权衡策略

数据的标准化有助于消除数据库中的数据冗余。如果数据冗余低，数据的一致性容易得到保证，如无特殊理由，OLTP系统的设计应当遵循第三范式，对于OLAP系统，为了减少表间连接查询的操作，提高系统的响应时间，合理的数据冗余是必要的。

2.4 字段类型的定义与使用策略

1) 数据类型的选用原则

数据类型

使用说明

CHAR

根据业务数据的特征决定是否使用CHAR类型，例如静态编码、固定年月日的时间字段等，避免数据变长的情况下使用CHAR类型

VARCHAR2(N)

Oracle数据库VARCHAR2类型，根据业务数据特征定义适当的长度，定义成偶数长度。

REAL、FLOAT、INTEGER、NUEBER

Oracle数据库必须使用NUEBER

NUMBER(P,S)、NUMERIC (P, S)、DECIMAL (P, S)

Oracle数据库必须使用NUMBER

DATE

时间类型必须使用DATE

BLOB（二进制数据）、CLOB（字符数据）

2) 数据类型长度的选用参考：

如果以下字段类型和长度能满足设计要求，必须遵循以下字段选用原则

数据类型

常用类型

CHAR

CHAR(1)本规范不推荐长度不为1的字段使用char类型

VARCHAR2(N)

VARCHAR2(2)

VARCHAR2(4)

VARCHAR2(8)

VARCHAR2(10)

VARCHAR2(16)

VARCHAR2(20)

VARCHAR2(30)

VARCHAR2(40)

VARCHAR2(50)

VARCHAR2(100)

VARCHAR2(200)

VARCHAR2(400)

VARCHAR2(1000)

VARCHAR2(2000)

NUMBER

NUMBER(P,S)

DATE

BLOB

3) 常用字段定义：

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_code，建议在业务表中增加该字段，表示操作员工号;

l opt_date，建议在业务表中增加该字段，表示操作时间;

l remark,建议在业务表中增加该字段，作为备用字段;

l stand,建议在业务表中增加该字段，作为备注;

l 描述“是、否”类型的字段命名，避免使用“IS_”开头。

3 命名规范3.1 数据库命名规则

数据库命名规则如下：

项目简称+1位数据库类型代码+识别代码+序号

数据库类型代码：

1) T：业务型数据库

2) A：分析型数据库

3) H：历史数据库

识别代码：

1) DEV：开发数据库

2) TEST：测试数据库

如果一种类型的数据库一个数据库，则不加序号，否则末尾增加序号。

如果是生产库则不加识别代码，否则需要增加爱识别代码DEV或TEST

如果只作历史库，部分生产、开发或者测试，则只需要项目简称+H+序号

举例：

出入系统业务生产库：AOCT、AOCT1、AOCT2

出入系统业务开发库：AOCTDEV、AOCTDEV1、AOCTDEV2

出入系统业务测试库：AOCTTEST、AOCTTEST1、AOCTTEST2

3.2 数据库对象命名的一般原则

数据库对象的命名应该以最少的字母达到最容易理解的意义。如果没有特殊规定，数据库对象及其属性的命名应满足如下条件：

1) 命名不推荐使用保留字；

2) 数据库实体统一采用英文命名；

3) 对象命名长度最好不要超过18个字符，缩写要易于理解，符合通用的习惯，例如部门编码缩写：dept_code,组织机构编码缩写：org_code。

4) 前导字符为A至Z

5) 非前导字符可以为：

l A至Z

l 0至9

l _（下划线字符）

3.3 表空间(Tablespace)命名规则

1) 表空间

l 表空间的描述规则统一为：TS_业务规则。

l 例如：TS_CRM等

2) 临时表空间

临时表空间的描述规则统一为：TS_TMP_业务规则。

3.4 表(Table)命名规则

1) 业务数据库中的数据表

命名规则：子系统简称_业务含义

2) 分析型数据库中的数据表

操作型数据存储区中的数据表：ODS_业务规则。

事实表：FACT_业务规则。

维表数据：DIM_业务规则。

中间表：MID_业务规则。

3.5 字段命名规则

1) 主键与外键必须使用相同的字段名和数据类型(含数据精度);尽量少使用联合主键；主键的命名有一定的含义，不要只写成“ID”之类的字段名；主键的生成规则有一定的含义，比如前缀+流水号规则，不要使用自增主键，不要使用数字类型。

2) 凡与业务含义无关的主键一律加_ID后缀。如PARTY_ID;

3) 凡是具有业务含义的编码（或代码）等字段一律加_CODE后缀。如PARTY_CODE;

4) 凡是名称、姓名等字段一律加_NAME后缀。如PARTY_NAME;

3.6 视图(View)命名规则

命名规则：VW_子系统简称_业务含义。

3.7 序列(Sequence)命名规则

命名规则：SEQ_表名。

3.8 存储过程(Procedure)的命名规则

命名规则：PRC_子系统简称_业务含义。

3.9 函数(Function)的命名规则

命名规则：FUN_子系统简称_业务含义。

3.10 索引(Index) 命名规范

命名规则：IDX_表名_有关字段。不允许使用自动生成的索引。

3.11 约束(Constraint) 命名规范

主键(Primary Key Constraint)：PK_表名，需要考虑主键长度太长无法创建的情况，表名部分要尽量简化且易于区分。

外键(Foreign Key Constraint)：FK_表名_字段_被参照 (referenced) 表名,需要考虑外键长度太长无法创建的情况，表名部分要尽量简化且易于区分。

4 数据模型产出物规范

1) PDM文件

数据模型产出物统一为PDM文件。各个项目根据情况，可以区分概念模型和物理模型；

2) XML文件

数据模型需要产出相应的XML文件，通过PDM进行转换，具体xml使用说明参照附录A。

3) 建表脚本

数据库的建表脚本作为数据库设计的规范产出物，需要严格进行版本控制，有统一的命名规范，命名规范如下：

l 创建表脚本：项目简称_create_table.sql。

l 修改表脚本：项目简称_alter_table.sql，在原有表的基础上做的修改，增加字段、主键、外键、索引等。

l 创建存储过程脚本：项目简称_create_prc.sql，所有涉及存储过程的创建和修改，必须实时更新此文件。

l 创建函数脚本：项目简称_create_fun.sql，所有涉及函数的创建和修改，必须实时更新此文件。

l 创建视图脚本：项目简称_create_view.sql, 所有涉及视图的创建和修改，必须实时更新此文件，并且如果在PDM文件中有视图的创建，需要更新PDM文件。

注：修改表脚本只作为备忘，所有表结构的修改，都必须实时更新“PDM文件”和“创建表脚本”，便于项目实施时表结构的导入。