数据库设计规范.docx
- 文档编号:23759980
- 上传时间:2023-05-20
- 格式:DOCX
- 页数:18
- 大小:24.02KB
数据库设计规范.docx
《数据库设计规范.docx》由会员分享,可在线阅读,更多相关《数据库设计规范.docx(18页珍藏版)》请在冰豆网上搜索。
数据库设计规范
保密级别:
□绝密□机密□秘密■内部公开
数据库设计规范
变更记录
版本号
修改点说明
变更日期
变更人
审批人
V1.0
创建
修改点说明的内容有如下几种:
创建、修改(+修改说明)、删除(+删除说明)
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)常用字段定义:
●涉及销售额等金额的数值:
NUMBER(16,2)
●涉及税率、比例、分成的数值:
NUMBER(10,6)
●涉及货物单价的数值:
NUMBER(16,6)
●涉及人数的数值:
NUMBER(10)
●涉及人名的:
VARCHAR2(50)
●涉及单位名称、地址的:
VARCHAR2(100)
●涉及说明、理由、意见的:
VARCHAR2(200)
●optr_code,建议在业务表中增加该字段,表示操作员工号;
●opt_date,建议在业务表中增加该字段,表示操作时间;
●remark,建议在业务表中增加该字段,作为备用字段;
●stand,建议在业务表中增加该字段,作为备注;
●描述“是、否”类型的字段命名,避免使用“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)非前导字符可以为:
●A至Z
●0至9
●_(下划线字符)
3.3表空间(Tablespace)命名规则
1)表空间
●表空间的描述规则统一为:
TS_业务规则。
●例如:
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)命名规范
主键(PrimaryKeyConstraint):
PK_表名,需要考虑主键长度太长无法创建的情况,表名部分要尽量简化且易于区分。
外键(ForeignKeyConstraint):
FK_表名_字段_被参照(referenced)表名,需要考虑外键长度太长无法创建的情况,表名部分要尽量简化且易于区分。
4数据模型产出物规范
1)PDM文件
数据模型产出物统一为PDM文件。
各个项目根据情况,可以区分概念模型和物理模型;
2)XML文件
数据模型需要产出相应的XML文件,通过PDM进行转换,具体xml使用说明参照附录A。
3)建表脚本
数据库的建表脚本作为数据库设计的规范产出物,需要严格进行版本控制,有统一的命名规范,命名规范如下:
●创建表脚本:
项目简称_create_table.sql。
●修改表脚本:
项目简称_alter_table.sql,在原有表的基础上做的修改,增加字段、主键、外键、索引等。
●创建存储过程脚本:
项目简称_create_prc.sql,所有涉及存储过程的创建和修改,必须实时更新此文件。
●创建函数脚本:
项目简称_create_fun.sql,所有涉及函数的创建和修改,必须实时更新此文件。
●创建视图脚本:
项目简称_create_view.sql,所有涉及视图的创建和修改,必须实时更新此文件,并且如果在PDM文件中有视图的创建,需要更新PDM文件。
注:
修改表脚本只作为备忘,所有表结构的修改,都必须实时更新“PDM文件”和“创建表脚本”,便于项目实施时表结构的导入。
附录A:
xml文件使用说明
表结构设计文件是指在进行表,视图,以及约束的设计过程中所产生的文件。
格式:
xml文件
✧
xml-stylesheettype=“text/xsl”href=“ui/TL_Schema.xsl”?
>
✧
DOCTYPEapp-dataSYSTEM“ui/TL_Schema.dtd”>
上面两行格式固定,主要用于数据结构的列表展示,每一个表结构文件都要引用
✧
✧
✧
✧文件三级节点,指项目设计中的模块,name和chineseDescription必须维护。
下面允许有多个
✧
文件四级节点,指项目设计中的模块,name和chineseDescription必须维护。
下面允许有多个