ORACLE设计规范.doc

ORACLE设计规范1、、数据建模原则性规范原则对于涉及数据库的项目,需要构建数据库逻辑模型图,逻辑模型图是项目组成员之间在数据库层面沟通交互的依据,必须规范画图(表,主键,外键,关系)衡量对于表的个数在20个以上的模型,需要数据组参与设计,并需DBA作最终审核方法对于OLTP系统,采用范式化思想进行模型设计,对于OLAP系统,采用面向问题及多级颗粒度的思想进行模型设计实施采用主流的模型设计软件工具PowerDesigner,ERStudio,、实体型之间关系认定规范原则所有实体型间的业务逻辑关系,除了语义上保留其原有的业务关系外,本质上都要转化成关系数据库的三种关系(1:1)(1:N)(N:M)衡量对于3个及以上实体型之间的“多元关系”,需要数据组参与设计方法比如实体型A和实体型B之间的关系,可以通过问两个问题来确定他们之间的关系:一个A可以对应几个B?一个B可以对应几个A?(1)一个A对应一个B,相反一个B对应一个A,那么A对B就是1:1关系;(2)一个A对应多个B,相反一个B对应一个A,那么A对B就是1:N关系;(3)一个A对应多个B,相反一个B对应对个A,那么A对B就是N:M关系;实施(1)1:1关系选取任何一个表的主键到另一个表中作为外键来体现;(2)1:N关系将1表的主键在N表中以外键形式存在来体现;(2)N:M关系采用“关系表”来体现,该关系表的主键是由相关实体表的主键组成的符合主键,各实体表主键不但组成了该关系表的主键,同时也被看作外键在该关系表中存在;(4)对于三个以上表之间的“多元关系”常需要和反范式化冗余字段结合起来设计,以保证查询速度;、范式化1NF的规范原则OLTP系统的模型,需要符合第三范式衡量对于表在20个以上的模型,需要数据组参与设计方法范式化要求:INF:列是访问的最小单位,具有原子性,不可再被分割;实施依据具体情况对相应属性进行拆分或者合并。范式化1NF常见现象:现象一:同一个属性值的不同细度把握,比如,常见的“姓名”这个属性,设计一:“姓名”是一个列,设计二:“姓”是一个列,“名”是一个列,两个列的值组合起来才表达一个“姓名”语义。两种设计方法,在不同的系统中都有应用,这主要是依据需求的细度来确定,灵活把握;现象二:把多个属性值错误的作为一个属性值存储,比如:常见的OA系统要存储员工的各种属性,包括技能信息,技能范围:Oracle,JAVA,.NET,C#,Perl,UNIX等等,一种常见的错误设计是:设计一张员工表,其中有一个技能属性字段,然后某员工所掌握的多种技能用逗号(,)间隔,然后将这个字符串存储到这个员工表的技能属性字段中。这里的错误在于将多个属性值作为一个属性值存储在一个字段中,不能满足直接遍历员工对某个技能掌握情况,而且如果再要求说明员工对个技能的掌握程度(精通,熟悉,一般等等),则再增加字段,里面的对应关系将很容易错乱,这是严重违反1NF的情况。正确的设计应该是:两个实体表:一张是员工表,一张是技能字典表,一个员工可以掌握多个技能,也就是(1:N)关系,相反一个技能可以被多个员工掌握,也是(1:N)关系,双向都是(1:N)关系,那么综合起来员工和技能之间就是“多对多关系(N:M)”,依据前述规范,应该设计一张“关系表”来存储“多对多关系”,主键为复合主键(员工主键+技能主键),该关系有一个属性“技能掌握程度”。、范式化2NF的规范原则OLTP系统的模型,需要符合第三范式衡量对于表在20个以上的模型,需要数据组参与设计方法范式化要求:2NF:满足1NF,不存在非主键属性对主键属性的部分依赖;实施范式化2NF常见现象:实体表中一般不会出现违反2NF的情况,因为都是“一个”主键列,而关系表是两个以上列的“复合”主键,故而关系表容易出现违反2NF的情况。主要是该关系表非主键外的属性,本该属于相关的某个实体表的,却放到了该关系表中,这使得该属性不能通过该关系表的复合主键唯一确定,DML操作会发生错误;如果违反了2NF,那么应该把这个属性从关系表中拆分,也许会单独形成一个表,绝大部分情况下是将该属性归并到某个相关的实体表中;违反2NF的例子:学生考试情况中,有两个实体表:学生表和学科表,学生与学科之间的考试关系就是N:M的关系,就要创建一张关系表存储该多对多的考试关系,表的主键为学生编号和学科编号,属性为考试分数;那么“任课老师”该放在那里呢?如果放到考试关系表中,那么安排任课老师,必须先进行考试,这显然不符合实际,也就是任课老师不该依赖于学生编号和学科编号,只是依赖于学科编号,也就是说任课教师信息应该放在学科表中;、范式化3NF的规范原则OLTP系统的模型,需要符合第三范式衡量对于表在20个以上的模型,需要数据组参与设计方