ORACLE设计规范.docx

ORACLE设计规范
1、数据库模型设计方法规范
1。1、数据建模原则性规范
原则
对于涉及数据库的项目，需要构建数据库逻辑模型图，逻辑模型图是项目组成员之间在数据库层面沟通交互的依据，必须规范画图（表，主键，外键，关系）
衡量
然不符合实际，也就是任课老师不该依赖于学
生编号和学科编号，只是依赖于学科编号，也就是说任课教
师信息应该放在学科表中；
1・5、范式化3NF的规范
原则
OLTP系统的模型，需要符合第三范式
衡量
对于表在20个以上的模型，需要数据组参与设计
方法
范式化3NF要求：
3NF:满足2NF，不存在非主键属性对主键属性的传递依赖；
实施
范式化3NF常见现象：
违反3NF的情况，绝大多数是在含有外键的表中;比如A表中的外键字段Bkey是B的主键，那么依赖于Bkey的属性应当属于B表的属性，而不是A表，如果放入A表，则这些对A表的主键Akey的依赖，首先是依赖于A（BIKey），而后通过A（BKey）对A（AKey）的依赖，传递依赖于A（Akey）;三种关系（1:1,1:N，N：M）都含有外键，都很可能发生违反3NF的情况。违反3NF的后果：会导致那些问题属性插入异常，或者被误删。
违反3NF的例子：
教师和学科之间，存在着上课关系，假设一个教师上一门课而且一门课只有一个教师上，那么该关系为1:1关系，将教师表的主键教师编号在学科表中以外键形式存在就表达了该1:1关系，那么教师的“联系电话”属性该放哪里呢?如果看到
“教师编号”出现在了学科表中，就将联系电话放入学科表中，那么联系电话首先是对表中的教师编号依赖，再依据教师编号对学科的依赖，达到了学科编号的依赖，那么联系电话对学科编号的依赖就是传递依赖，违反了3NF，应该将其从学科表中拆出来放入教师表中，不然的话，会发生操作异常，比如，假设一个教师已经存在但是还没有为其分配科目，那么他的电话就无法存入库中.
1・6、反范式化冗余字段使用规范
原则
OLTP系统中在完成范式化工作之后，对某些表，可以适当反范式化增加冗余字段以提高数据访问性能；在OLAP中采用的是面向问题的设计思想，应该大量使用反范式化冗余信息
衡量
当SQL关连查询涉及到4张表时可考虑采用冗余字段
方法
常用在两个地方:（1）关系表中的冗余:在关系表中增加相关实体表的相关属性,以达到关连查询时减少表的关联数量的目的（2）层次关系中的冗余：在多层次的子父表关系中，将父表的属性存储在“子表”或者“孙子表”或者“重孙表"中；反范式化冗余字段实例：
（1）关系表中的冗余:比如在考试关系中，原本在学科表中的学分信息，可以冗余添加到考试关系表中，这样，每个学生得了多少学分，就可以直接从考试表得到，而无需关联学科表来得到；
（2）多层关系中的冗余：假设为之范畴从大到小有国家表，省份表，城市表，城区表，社区表，它们之间的层次关系是通过上一级的主键在下一级中以外键形式存在来体现的，但是，如果需要问：某个设计属于哪个国家？这样就要关连查询所有的5张表，性能会很差，这时可以将国家编号以外键形式放入到社区表中做冗余，这样直接关联国家表和社区表即可得到答案。一般的，每间隔一级增加一个冗余外键，比如将国家编号放入城市表中，将城市编号放入社区表中
实施
如何保证冗余字段数据的正确性（一致性）是反范式化的关键，需要对冗余字段详细添加注释，说明冗余了什么，以及该字段的维护方法，常用维护方法如下：
（1）如果在程序开发前设计的冗余字段，可以在正常的业务逻辑程序中一并处理（2）如果是程序完成之后增加的冗余字段，可以使用触发器维护（3）对于OLAP中大量存在冗余字段，可能需要使用单独的处理任务进行维护
1・7、数据库对象命名基本规范
第一:长度规范：凡是需要命名的对象其标识符均不能超过30个字符，也即：Oracle中的表名、字段名，函数名，过程名，触发器名,序列名，视图名的长度均不能超过30个字符；
第二:构成规范:数据库各种名称必须以字母开头，但严禁使用SYS开头；名称只能含有字母,数字和下划线“_"三类字符，“_”用于间隔名称中的各语义字段；不要使用DUAL作表名；
第三：大小写规范：构成Oracle数据库中的各种名称（表明，字段名，过程名，视图名等等）的所有字符，必须使用大写，也就是不能在脚本中，对任何名称添加双引号“”来设定字符的大小写形式，只要不采用“”限制，Oracle自动会将各名称转化成大写。
2、表的设计规范
、表的主键规范
遵循如下三点原则：第一:有无原则：除临时表和外部表，以及流水表,日志表外，其他表都要建立主键;第二：构成原则：主键不能使用含有实际语义的列,应该增加一个xx_id字段做主键，类型为n