欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

关系数据库设计

程序员文章站 2024-02-16 17:23:10
...

1. 基本设计规范 构造数据 库 必 须 遵循一定的 规则 。在 关 系数据 库 中, 这种规则 就是范式。范式是符合某一 种级别 的 关 系模式的集合。 关 系数据 库 中的 关 系必 须满 足一定的要求,即 满 足不同的范式。目前 关 系数据 库 有六 种 范式:第一范

1.基本设计规范

构造数据遵循一定的规则。在系数据中,这种规则就是范式。范式是符合某一种级别系模式的集合。系数据中的系必须满足一定的要求,即足不同的范式。目前系数据有六范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。足最低要求的范式是第一范式(1NF)。在第一范式的基步满足更多要求的称第二范式(2NF),其余范式以次推。一般来,数据只需足第三范式(3NF)就行了。下面我们举例介第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。

1.1 第一范式(1NF

在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。例如,职工号,姓名,电话号码组成一个“员工信息表”(一个人可能有一个办公室电话和一个家里电话号码),不能将员工信息都放在一列中显示,也不能将其中的两列或多列在一列中显示;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表中只出现一次。

按照1NF采取三方法进行规范:

一是重储职工号和姓名。这样关键字只能是电话
二是工号为关键字,电话为单电话和住宅电话两个属性
三是工号为关键字,但记录只能有一个电话
以上三个方法,第一方法最不可取,按实际情况取后两情况。

而言之,第一范式就是无重的列。

1.2 第二范式(2NF

第二范式(2NF)是在第一范式(1NF)的基上建立起来的,即足第二范式(2NF)必足第一范式(1NF)。第二范式(2NF)要求数据表中的例或行必可以被唯一地区分。为实现区分通常需要表加上一个列,以存各个例的唯一标识。例如在工信息表中加上了号(emp_id)列,因为每工的号是唯一的,因此工可以被唯一区分。个唯一属性列被称关键字或主、主。第二范式(2NF)要求体的属性完全依于主关键字。所完全依是指不能存在关键字一部分的属性,如果存在,那么这个属性和主关键字的一部分应该分离出来形成一个新的体,新体与原体之是一多的系。为实现区分通常需要表加上一个列,以存各个例的唯一标识

例如:假定选课关系表SelectCourse包含(学号, 姓名, , 程名称, , 学分)字段,关键为组关键(学号, 程名称),因存在如下决定系:

   (学号, 程名称) → (姓名, , , 学分)

   个数据表不足第二范式,因存在如下决定系:

   (程名称) → (学分)

   (学号) → (姓名, )

   即存在关键字中的部分字段决定非关键字的情况。

   由于不符合2NF选课关系表会存在如下问题

   (1) 数据冗余:

   同一门课程由n个学生修,"学分"就重n-1次;同一个学生修了m门课程,姓名和年就重m-1次。

   (2) 更新异常:

   若整了某门课程的学分,数据表中所有行的"学分"都要更新,否会出同一门课程学分不同的情况。

   (3) 插入异常:

   假开设新的程,暂时还没有人修。这样,由于没有"学号"关键字,程名称和学分也无法记录入数据

   (4) 除异常:

   假一批学生已完成程的修,记录应该从数据表中除。但是,与此同程名称和学分信息也被除了。很然,也会致插入异常。

   要解决上述问题把选课关系表SelectCourse如下三个表:

   学生:Student(学号, 姓名, )

   程:Course(程名称, 学分)

   选课关系:SelectCourse(学号, 程名称, )

   这样的数据表是符合第二范式的,消除了数据冗余、更新异常、插入异常和除异常。

   另外,所有单关键字的数据表都符合第二范式,因不可能存在关键字。

而言之,第二范式就是非主属性非部分依于主关键字。

1.3 第三范式(3NF

足第三范式(3NF)必足第二范式(2NF)。在第二范式的基上,数据表中如果不存在非关键字段任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依,指的是如果存在"A → B → C"的决定系,C传递函数依A。因此,足第三范式的数据应该不存在如下依赖关系:

   关键字段关键字段x → 关键字段y

   例如:假定学生系表Student(学号, 姓名, , 所在学院, 学院地点, 学院电话)关键为单关键"学号",因存在如下决定系:

   (学号) → (姓名, , 所在学院, 学院地点, 学院电话)

   个数据是符合2NF的,但是不符合3NF,因存在如下决定系:

   (学号) → (所在学院) → (学院地点, 学院电话)

   即存在非关键字段"学院地点""学院电话"对关键字段"学号"传递函数依

   它也会存在数据冗余、更新异常、插入异常和除异常的情况,者可自行分析得知。

   把学生系表分如下两个表:

   学生:(学号, 姓名, , 所在学院)

   学院:(学院, 地点, 电话)

   这样的数据表是符合第三范式的,消除了数据冗余、更新异常、插入异常和除异常。

而言之,第三范式就是属性不依于其它非主属性。第三范式(3NF)要求一个数据表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部信息表,其中个部有部门编号(dept_id)、部名称、部门简介等信息。那
工信息表中列出部门编号后就不能再将部名称、部门简介等与部的信息再加入工信息表中。如果不存在部信息表,根据第三范式(3NF)也应该构建它,否就会有大量的数据冗余。

1.4依斯-科得范式(BCNF

如果系模式RUF)的所有属性(包括主属性和非主属性)都不传递R的任何候选关键字,那R是属于BCNF的。或是系模式R,如果个决定因素都包含关键字(而不是被关键字所包含),RCNF系模式。
例:配件管理系模式 WPEWNOPNOENOQNT)分仓库号,配件号,工号,数量。有以下条件:

a.一个仓库有多个工。
b.
一个在一个仓库工作。
c.
仓库里一型号的配件由负责,但一个人可以管理几配件。
d.
同一型号的配件可以分放在几个仓库中。
分析:

由以上得 PNO 不能确定QNT,由合属性(WNOPNO)来决定,存在函数依WNOPNO -> ENO。由于仓库里的一配件由负责,而一个人可以管理几配件,所以有合属性(WNOPNO)才能确定负责人,有(WNOPNO-> ENO。因 一个在一个仓库工作,有ENO -> WNO。由于仓库里的一配件由负责,而一个在一个仓库工作,有(ENOPNO-> QNT

找一下候选关键字,因WNOPNO -> QNT,(WNOPNO-> ENO ,因此 (WNOPNO)可以决定整个元,是一个候选关键字。根据ENO->WNO,(ENOPNO->QNT,故(ENOPNO)也能决定整个元另一个候选关键字。属性ENOWNOPNO 主属性,只有一个非主属性QNT。它任何一个候选关键字都是完全函数依的,并且是直接依,所以该关系模式是3NF

分析一下主属性。因ENO->WNO,主属性ENOWNO的决定因素,但是它本身不是关键字,只是关键字的一部分。就造成主属性WNO另外一个候选关键字(ENOPNO)的部分依,因ENOPNO-> ENO但反来不成立,而P->WNO,故(ENOPNO-> WNO 也是传递

然没有非主属性选关键字传递,但存在主属性选关键字的传递,同也会来麻。如一个新工分配到仓库工作,但暂时处实习阶段,没有独立负责对某些配件的管理任。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全,除配件的同时该职工也会被除。
解决法:分成管理EPENOPNOQNT),关键字是(ENOPNO)工作EWENOWNO)其关键字是ENO
缺点:

分解后函数依的保持性差。如此例中,由于分解,函数依WNOPNO-> ENO 失了, 因而原来的语义有所破坏。没有体仓库里一部件由负责。有可能出一部件由两个人或两个以上的人来同管理。因此,分解之后的系模式降低了部分完整性束。

一个系分解成多个系,要使得分解有意,起的要求是分解后不失原来的信息。些信息不包括数据本身,而且包括由函数依所表示的数据之的相互制行分解的目是达到更高一范化程度,但是分解的同两个问题:无损联接性和保持函数依。有往往不可能做到既有无损联接性,又完全保持函数依。需要根据需要衡。

1.5

目地:范化目的是使构更合理,消除存异常,使数据冗余尽量小,便于插入、除和更新
:遵从概念一化 "一事一地",即一个系模式描述一个体或的一种联系。范的实质就是概念的一化。
方法:将系模式投影分解成两个或两个以上的系模式。
要求:分解后的系模式集合当与原系模式"等价",即经过自然接可以恢系而不失信息,并保持属性合理的系。

注意:一个系模式结这分解可以得到不同系模式集合,也就是分解方法不是唯一的。最小冗余的要求必以分解后的数据表达原来数据所有信息前提来实现。其根本目省存,避免数据不一致性,提高对关系的操作效率,同时满用需求。实际上,并不一定要求全部模式都达到BCNF不可。有故意保留部分冗余可能更方便数据查询。尤其于那些更新度不高,查询频度极高的数据更是如此。

系数据中,除了函数依之外有多接依问题,从而提出了第四范式,第五范式等更高一范化要求。在此,以后再。通常的数据库设计,很少有人做到很符合以上几个范式的,一般来,第一范式大家都可以遵守,完全遵守第二第三范式的人很少了,遵守的人一定就是设计数据的高手了,BCNF的范式出机会少,而且会破坏完整性,你可以在做设计不考它,当然在ORACLE中可通器解决其缺点。以后我共同做设计,也希望大家遵守以上几个范式。