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) 数据类型的选用原则

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

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

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文件”和“创建表脚本”，便于项目实施时表结构的导入。