数据库三大范式

数据库三大范式
数据库三大范式

第一范式(1NF)及进一步规范化

关系模式需要满足一定的条件,不同程度的条件称做不同的范式。最低要求的条件是元组的每个分量必须是不可分的数据项,这叫做第一范式,简称1NF,是最基本的规范化,在第一范式的基础上进一步增加一些条件,则为第二范式。以此类推,还有第三范式,Boyce-Codd 范式,等等。函数依赖X→Y不仅给出了对关系的值的限制,而且给出了数据库中应该存储的某种联系:从X的值应该知道与之联系的惟一Y值。若X不含码,则有麻烦了。码是一个元组区别于其他元组的依据,同时也是一个元组赖以存在的条件。在一个关系中,不可能存在两个不同的元组在码属性上取值相同,也不可能存在码或码的一部分为空值的元组。若某关系模式的属性间有函数依赖X→Y,而X又不包含码,那么在具有相同X值的所有元组中,某个特定的Y值就会重复出现,这是数据冗余,随之而来的是更新异常问题;某个X值与某个特定的Y值相联系,这是数据库中应存储的信息,但由于X不含码,这种X与Y相联系的信息可能因为码或码的一部分为空值而不能作为一个合法的元组在数据库中存在,这是插入异常或删除异常问题。第二范式、第三范式和Boyce-Codd范式就是不同程度地限制关系模式中X不包含码的函数依赖X→Y的存在。

(二)第二范式(2NF)

若关系模式R∈1NF,且每一个非主属性完全函数依赖于码,则R∈2NF。

2NF就是不允许关系模式的属性之间有这样的函数依赖X→Y,其中X是码的真子集,Y是非主属性。即不允许有非主属性对码的部分函数依赖。

(三)第三范式(3NF)

若关系模式R∈2NF,且每一个非主属性都不传递依赖于码,则R∈3NF。3NF就是不允许关系模式的属性之间有这样的非平凡函数依赖X→Y,其中X不包含码,Y是非主属性。X不包含码有两种情况,一种情况X是码的真子集,这是2NF不允许的,另一种情况X不是码的真子集,这是3NF不允许的。

(四)Boyce-Codd范式(BCNF)

若关系模式R∈1NF,且对于每一个非平凡的函数依赖X→Y,都有X包含码,则R∈BCNF。BCNF是3NF的进一步规范化,即限制条件更严格。3NF不允许有X不包含码,Y是非主属性的非平凡函数依赖X→Y。BCNF则不管Y是主属性还是非主属性,只要X不包含码,就不允许有X→Y这样的非平凡函数依赖。因此,若R∈BCNF,则必然R∈3NF。然而,BCNF又是概念上更加简单的一种范式,判断一个关系模式是否属于BCNF,只要考察每个非平凡函数依赖X→Y的决定因素X是否包含码就行了。1NF,2NF,3NF,BCNF的相互关系

是:BCNF’3NF’2NF’1NF在函数依赖的范畴内,BCNF达到了最高的规范化程度。

一、部分依赖归子集;完全依赖随键码——用于建立2NF

例:关系R(A,B,C,D,E,F,G)上存在函数依赖,A->BCD,E->F,AE->G,AE->BCD,AE->F

分析以上依赖可以看出,AE是键码(AE->BCD)。因为AE是键码,A是主属性,A->BCD,所以BCD是部分依赖于AE

根据部分依赖归子集的方法,因为A是AE的真子集,所以A与BCD归在一起构成一个关系模式。R1(A,B,C,D)

同理对于AE->F,有E->F所以AE->F是部分依赖,非主属性F所依赖的真子集是E,所以E 和F可以归在一个关系模式中R2(E,F)

AE->G是完全函数依赖,完全依赖随键码,所以AEG归在一个关系模式中R3(A,E,G)

因此R(A,B,C,D,E,F,G)可以分解为符合2NF的关系模式如下:

R1(A,B,C,D)

R2(E,F)

R3(A,E,G)

二、基本依赖为基础,中间属性做桥梁——用于建立3NF

例:关系R(A,B,C,D,E)上存在函数依赖,AB->C,C->D,D->E

显然中间桥梁是C->D,他构成了传递依赖链,因此,R可以分解为R1(A,B,C),R2(C,D)。分解后在R1,R2中都不存在传递依赖。

三、找违例自成一体,舍其右全集归一;若发现仍有违例,再回首如法炮制——用于建立BCNF

BCNF违例:违背BC范式的函数依赖称为BC范式违例

例:关系R(A,B,C,D,E)的键码是AB,有函数依赖AB->CDE,ABC->E,C->D

分析上述三个函数依赖可以看出,C->D是BCNF违例。因为它的决定因素不包含键码。我们作如下分解

违例自成一体,即CD构成一个关系模式R1(C,D)

舍其右全集归一,即从R的属性中取掉C->D的右边的属性D,其左边的属性C与其他所有属性构成一个新的关系R2(A,B,C,E)

新的关系模式如下:

R1(C,D)

R2(A,B,C,E)

注意:以BCNF违例为基础进行模式分解,最终得到的属于BCNF的关系模式都能实现无损连接,但未必能保持函数依赖

逻辑设计例一:假如有关系模式R(A,B,C,D)和函数依赖集S={B->C,B->D}。

(1)找出所有BCNF违例。

(2)如果该关系模式不是BCNF,则将它分解为BCNF

(3)找出所有的违背3NF的依赖

(4)如果该关系不是3NF,则将它分解为3NF

步骤一:找出R在S上的所有非平凡依赖,首先计算封闭集

单属性封闭集:A+=A,B+=BCD,C+=C,D+=D

双属性封闭集:AB+=ABCD,AC+=AC,AD+=AD,BC+=BCD,BD+=BCD,CD+=CD

三属性封闭集:ABC+=ABCD,ABD+=ABCD,BCD+=BCD,ACD+=ACD

四属性封闭集:ABCD+=ABCD

步骤二:根据计算所得的封闭集,找出键码和超键码

键码:AB

超键码:ABC,ABD,ABCD

步骤三:找出所有的非平凡函数依赖

B->C,B->D,AB->C,AB->D,BC->D,BD->C,ABC->D,ABD->C

其中,AB->C,AB->D,ABC->D,ABD->C不是BCNF违例,因为前两个依赖的决定因素本身就是键码,而后两个依赖的决定因素包含键码。所以,B->C,B->D,BC->D,BD->C是BCNF违例,因为它们的决定因素都不包含键码。实际上可以看出R不是2NF,因为存在部分函数依赖:ABC->D,ABD->C,AB->C,AB->D,B->C,B->D

步骤四:进行BCNF规范。BCNF违例自成一体。从以上BCNF违例中选择B->C自成一体

R1(B,C)

舍其右全集归一,即舍去B->C的右边属性C,所以得到

R2(A,B,D)

但是在R2中还存在BCNF违例B->D,因此B->D自成一体,得到R21(B,D),舍其右全集归一得到R22(A,B)

最后得到的关系模式是:R1(B,C),R21(B,D),R22(A,B)

通过关系模式分解,把一个非2NF的关系模式归范成一个BCNF。代价是,在实际操作中增加了连接操作。

(3)B->C,B->D,B不是键码也不是超键码,而C,D都是键码以外的属性,即是非主属性。所以R不是3NF。

逻辑设计例二:有关系R(A,B,C,D)和函数依赖集S={A->B,B->C,C->D,D->A}

(1)找出所有BCNF违例。

(2)如果该关系模式不是BCNF,则将它分解为BCNF

(3)找出所有的违背3NF的依赖

(4)如果该关系不是3NF,则将它分解为3NF

步骤一:找出R在S上的所有非平凡依赖,首先计算封闭集

单属性封闭集:A+=ABCD,B+=ABCD,C+=ABCD,D+=ABCD

双属性封闭集:AB+=ABCD,AC+=ABCD,AD+=ABCD,BC+=ABCD,BD+=ABCD,CD+=ABCD

三属性封闭集:ABC+=ABCD,ABD+=ABCD,BCD+=ABCD,ACD+=ABCD

四属性封闭集:ABCD+=ABCD

步骤二:找出所有非平凡函数依赖

A->B,A->C,A->D,B->A,B->C,B->D,C->A,C->B,C->D,D->A,D->B,D->C

AB->C,AB->D,AC->B,AC->D,AD->B,AD->C,BC->A,BC->D,BD->A,BD->C,CD->A,CD->B ABC->D,ABD->C,BCD->A,ACD->B

步骤三:找出键码和超键码

键码:A,B,C,D

超键码:AB,AC,AD,BC,BD,CD,ABC,ABD,BCD,ACD,ABCD

根据以上结果分析,R是3NF也是BCNF

3NF要求不存在每个非主属性对于键码的部分依赖或传递依赖

练习:对于

1.R(A,B,C,D)和函数依赖集S={AB->C,BC->D,CD->A,AD->B}

2.R(A,B,C,D,E)和函数依赖集S={AB->C,DE->C,B->D}

3.R(A,B,C,D,E)和函数依赖集S={AB->C,C->D,D->B,D->E}

(1)找出所有BCNF违例。

(2)如果该关系模式不是BCNF,则将它分解为BCNF

数据库三大范式讲解

数据库三大范式说明 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。 实质上,设计范式用很形象、很简洁的话语就能说清楚,道明白。本节课将对范式进行通俗地说明,以一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际项目中。 范式说明: 第一范式(1NF): 数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。 很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 第二范式(2NF): 数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖

于任意一组候选关键字。 假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系: (学号, 课程名称) →(姓名, 年龄, 成绩, 学分) 这个数据库表不满足第二范式,因为存在如下决定关系: (课程名称) →(学分) (学号) →(姓名, 年龄) 即存在组合关键字中的字段决定非关键字的情况。 由于不符合2NF,这个选课关系表会存在如下问题: (1) 数据冗余: 同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。 (2) 更新异常: 若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。 (3) 插入异常: 假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。 (4) 删除异常: 假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。 把选课关系表SelectCourse改为如下三个表: 学生:Student(学号, 姓名, 年龄); 课程:Course(课程名称, 学分); 选课关系:SelectCourse(学号, 课程名称, 成绩)。 这样的数据库表是符合第二范式的,消除了数据冗余、更新异常、插入异常和删除异常。 另外,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字。

数据库范式理解例题

范式分解 主属性:包含在任一候选关键字中的属性称主属性。 非主属性:不包含在主码中的属性称为非主属性。 函数依赖: 是指关系中一个或一组属性的值可以决定其它属性的值。函数依赖正象一个函数 y = f(x) 一样,x的值给定后,y的值也就唯一地确定了。 如果属性集合Y中每个属性的值构成的集合唯一地决定了属性集合X中每个属性的值构成的集合,则属性集合X函数依赖于属性集合Y,计为:Y→X。属性集合Y中的属性有时也称作函数依赖Y→X的决定因素(determinant)。例:身份证号→姓名。部分函数依赖: 设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。 完全函数依赖: 在R(U)中,如果Y函数依赖于X,并且对于X的任何一个真子集X',都有Y不函数依赖于X',则称Y对X完全函数依赖。否则称Y对X部分函数依赖。

【例】; 举个例子就明白了。假设一个学生有几个属性 SNO 学号 SNAME 姓名 SDEPT系 SAGE 年龄 CNO 班级号 G 成绩 对于(SNO,SNAME,SDEPT,SAGE,CNO,G)来说,G完全依赖于(SNO, CNO), 因为(SNO,CNO)可以决定G,而SNO和CNO都不能单独决定G。 而SAGE部分函数依赖于(SNO,CNO),因为(SNO,CNO)可以决定SAGE,而单独的SNO也可以决定SAGE。 传递函数依赖: 设R(U)是属性集U上的关系,x、y、z是U的子集,在R(U)中,若x→y,但y→x,若y→z,则x→z,称z传递函数依赖于x,记作X→TZ。 如果X->Y, Y->Z, 则称Z对X传递函数依赖。 计算X+ (属性的闭包)算法: a.初始化,令X+ = X; b.在F中依次查找每个没有被标记的函数依赖,若“左边属性集”包含于X+ ,则令X+ = X+∪“右边属性集”, 并为访问过的函数依赖设置标记。

数据库三范式

数据库三范式 1.1 第一范式(1NF)无重复的列 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。 说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 1.2 第二范式(2NF)属性完全依赖于主键[消除部分子函数依赖] 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。例如员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是属性完全依赖于主键。 1.3 第三范式(3NF)属性不依赖于其它非主属性[消除传递依赖] 满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。 II、范式应用实例剖析 下面以一个学校的学生系统为例分析说明,这几个范式的应用。首先第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS 中设计出不符合第一范式的数据库都是不可能的。 首先我们确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程、

数据库中三个范式的理解

什么是范式 简单的说,范式是为了消除重复数据减少冗余数据,从而让数据库内的数据更好的组织,让磁盘空间得到更有效利用的一种标准化标准,满足高等级的范式的先决条件是满足低等级范式。(比如满足2nf一定满足1nf) DEMO 让我们先从一个未经范式化的表看起,表如下: 先对表做一个简单说明,employeeId是员工id,departmentName是部门名称,job代表岗位,jobDescription是岗位说明,skill是员工技能,departmentDescription是部门说明,address是员工住址 对表进行第一范式(1NF) 如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。 简单的说,第一范式就是每一个属性都不可再分。不符合第一范式则不能称为关系数据库。对于上表,不难看出Address是可以再分的,比如”北京市XX路XX小区XX号”,着显然不符合第一范式,对其应用第一范式则需要将此属性分解到另一个表,如下:

对表进行第二范式(2NF) 若关系模式R∈1NF,并且每一个非主属性都完全函数依赖于R的码,则R∈2NF 简单的说,是表中的属性必须完全依赖于全部主键,所以只有一个主键的表如果符合第一范式,那一定是第二范式,而不是部分主键。这样做的目的是进一步减少插入异常和更新异常。在上表中,departmentDescription是由DepartmentName所决定,但却不能由EmployeeID 决定,故要departmentDescription对主键是部分依赖,对其应用第二范式如下表: 对表进行第三范式(3NF)

关系模式R 中若不存在这样的码X、属性组Y及非主属性Z(Z Y), 使得X→Y,Y→Z,成立,则称R ∈ 3NF。 简单的说,第三范式是为了消除数据库中关键字之间的依赖关系,在上面经过第二范式化的表中,可以看出jobDescription(岗位职责)是由job(岗位)所决定,则jobDescription依赖于job,可以看出这不符合第三范式,对表进行第三范式后的关系图为: 上表中,已经不存在数据库属性互相依赖的问题,所以符合第三范式

数据库范式(1NF2NF3NFBCNF)详解

数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、 结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。 范式说明 第一范式(1NF)无重复的列 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不 能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一 对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式 就是无重复的列。 说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一 范式(1NF)的数据库就不是关系数据库。 例如,如下的数据库表是符合第一范式的: 字段1 字段2 字段3 字段4 而这样的数据库表是不符合第一范式的: 字段1 字段2 字段3 字段4 字段字段 数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、 实数、字符型、逻辑型、日期型等。很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一 列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不 可能的。 第二范式(2NF)属性完全依赖于主键[ 消除部分子函数依赖] 如果关系模式R为第一范式,并且R中每一个非主属性完全函数依赖于R的某个候选键,则称为第二范式模式。 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被 惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。 例如员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的, 因此每个员工可以被惟一区分。

数据库范式理解例题

范式分解 主属性: 包含在任一候选关键字中得属性称主属性。 非主属性: 不包含在主码中得属性称为非主属性。 函数依赖: 就是指关系中一个或一组属性得值可以决定其它属性得值。函数依赖正象一个函数y =f(x) 一样,x得值给定后,y 得值也就唯一地确定了。 如果属性集合Y中每个属性得值构成得集合唯一地决定了属性集合X中每个属性得值构成得集合,则属性集合X函数依赖于属性集合Y,计为:Y→X。属性集合Y中得属性有时也称作函数依赖Y→X得决定因素(determinant).例:身份证号→姓名。 部分函数依赖: 设X,Y就是关系R得两个属性集合,存在X→Y,若X’就是X得真子集,存在X’→Y,则称Y部分函数依赖于X。 完全函数依赖: 在R(U)中,如果Y函数依赖于X,并且对于X得任何一个真子集X’,都有Y不函数依赖于X', 则称Y对X完全函数依赖。否则称Y对X部分函数依赖。 【例】;

举个例子就明白了。假设一个学生有几个属性 SNO 学号SNAME 姓名SDEPT系 SAGE 年龄CNO班级号G 成绩 对于(SNO,SNAME,SDEPT,SAGE,CNO,G)来说,G完全依赖于(SNO,CNO),因为(SNO,CNO)可以决定G,而SNO与CNO都不能单独决定G。 而SAGE部分函数依赖于(SNO,CNO),因为(SNO,CNO)可以决定SAGE,而单独得SNO也可以决定SAGE。 传递函数依赖: 设R(U)就是属性集U上得关系,x、y、z就是U得子集,在R(U)中,若x→y,但y→x,若y→z,则x→z,称z传递函数依赖于x,记作X→TZ。 如果X—>Y, Y—〉Z, 则称Z对X传递函数依赖。 计算X+(属性得闭包) 算法: a、初始化,令X+ = X; b、在F中依次查找每个没有被标记得函数依赖,若“左边属性集”包含于X+,则令 X+ = X+∪“右边属性集",并为访问过得函数依赖设置标记。 c、反复执行b直到X+不改变为止。 检验给定得任意函数依赖A1A2、、、An->B就是否蕴含于依赖集S: 分析:

数据库的三个范式

数据库规范化三个范式应用实例 5. 通俗地理解三个范式 通俗地理解三个范式,对于数据库设计大有好处。在数据库设计中,为了更好地应用三个范式,就必须通俗地理解三个范式(通俗地理解是够用的理解,并不是最科学最准确的理解): 第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解; 第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性; 第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余. 没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余。 规范化为什么重要?目前很多的数据库由于种种原因还没有被规范化。本文中解释了其中一些原因,并用不同形式的范式(normal form)规范化了一个保险公司的理赔表。在这个过程中表的改变以及添加的一些附加表使数据库效率更高、错误更少、更容易维护。 数据库的规范化是优化表的结构和把数据组织到表中的实践,这样做数据才能更明确。规范化使你能够改变业务规则、需求和数据而不需要重新构造整个系统。 通过改变存储数据的方式--仅仅改变一丁点--并改变访问这些信息的程序,你就可以消除很多错误或垃圾数据出现的机会并减轻更新信息所必要的工作量。 公司现实存在的一个问题可以用一句话概括"我们一般都这样做"。我们一般像采用那种方式存储信息;我们一般允许人们把任何信息写入;我们一般采用那种方式编程。这通常是一件坏事,特别是对于年轻的和正在学习的公司来说。但是,当有新的系统和更好的完成任务的途径的时候,有时"采用那种方式任务完成得很好"这句话可能需要重新探讨和修改。规范化数据就是公司常常采用的有益的方式之一。 尽管对于cobol程序(例如任何cobol程序员都熟悉的文件布局)使用数据来说,把它们(数据)存储在关系数据库中与存储在平面文件中很相似,但是存储在平面文件中的方法并不是完成任务的必要的最好的途径,特别是由于你不了解两者之间的差别或害怕改变,而简单地把过去的观念带入到现在的方式。 注意:https://www.360docs.net/doc/916727438.html,是这样定义规范化的:"使其标准,特别使导致它符合某种标准或规范。"或"某种标准的强制接受"。webopedia认为规范化是"在关系数据库设计中,组织数据以最小化冗余的过程。规范化通常包括把一个数据库分成两个或多个表并定义表之间的关系。其目标是隔离数据,这样添加、删除和修改某个字段只需要在一个表中进行,接着可以通过定义的关系传递到数据库中剩余的表中"。我更喜欢这个定义。 术语 在你了解现实世界中的一个保险公司的例子之前,你需要了解一些在讨论中会用到的术语。处理数据库的时候,特别是在处理规范化问题的时候,下面一部分讲到的一组新的关键字很有作用: ·关系(relation):从本质上说,关系是一个包含行和列的二维表或数组。 ·关联(relationship):关联是不同表之间的数据彼此联系的方法。关联同时存在于形成不同实体的数据项之间和表实体本身之间,构成了数据库规范化的基本核心问题。数据关联有三种基本的类型,对它们有所了解是很重要的:

数据库-部分函数依赖,传递函数依赖,完全函数依赖,三种范式的区别

数据库-部分函数依赖,传递函数依赖,完全函数依赖, 三种范式的区别 要讲清楚范式,就先讲讲几个名词的含义吧: 部分函数依赖:设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。 举个例子:学生基本信息表R中(学号,身份证号,姓名)当然学号属性取值是唯一的,在R关系中,(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号); 完全函数依赖:设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。例子:学生基本信息表R(学号,班级,姓名)假设不同的班级学号有相同的,班级内学号不能相同,在R关系中,(学号,班级)->(姓名),但是(学号)->(姓名)不成立,(班级)->(姓名)不成立,所以姓名完全函数依赖与(学号,班级); 传递函数依赖:设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。 例子:在关系R(学号 ,宿舍, 费用)中,(学号)->(宿舍),宿舍!=学号,(宿舍)->(费用),费用!=宿舍,所以符合传递函数的要求;

在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 所谓第一范式(1NF)是指数据库表的每一列(即每个属性)都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之,第一范式就是无重复的列。 2、第二范式(2NF) 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是唯一的,因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是非主属性依赖于主关键字。

数据库复习资料数据库范式(1NF 2NF 3NF BCNF)详解

数据库范式(1NF 2NF 3NF BCNF)详解 数据结构设计模式编程制造 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。 范式说明 1.1 第一范式(1NF)无重复的列 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。 说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 包括整型、实数、字符型、逻辑型、日期型等。很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS 中设计出不符合第一范式的数据库都是不可能的。 1.2 第二范式(2NF)属性完全依赖于主键 [ 消除部分子函数依赖 ] 如果关系模式R为第一范式,并且R中每一个非主属性完全函数依赖于R 的某个候选键,则称为第二范式模式。 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。 例如员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此每个员工可以被惟一区分。 简而言之,第二范式(2NF)就是非主属性完全依赖于主关键字。 所谓完全依赖是指不能存在仅依赖主关键字一部分的属性(设有函数依赖 W→A,若存在XW,有X→A成立,那么称W→A是局部依赖,否则就称W→A是完全函数依赖)。如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。 假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系: (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

数据库三大范式详解

数据库三大范式详解 设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。 目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴德斯科范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。 第一范式(1NF)无重复的列 所谓第一范式(1NF)是指在关系模型中,对域添加的一个规范要求,所有的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。即实体中的某个属性有多个值时,必须拆分为不同的属性。在符合第一范式(1NF)表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之,第一范式就是无重复的域。 说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的设计基本要求,一般设计中都必须满足第一范式(1NF)。不过有些关系模型中突破了1NF的限制,这种称为非1NF的关系模型。换句话说,是否必须满足1NF的最低要求,主要依赖于所使用的关系模型。 第二范式(2NF)属性 在1NF的基础上,非码属性必须完全依赖于主键[在1NF基础上消除非主属性对主码的部分函数依赖] 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组,作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分,该身份证号码即为候选键,任何一个候选键都可以被选作主键。在找不到候选键时,可额外增加属性以实现区分,如果在员工关系中,没有对其身份证号进行存储,而姓名可能会在数据库运行的某个时间重复,无法区分出实体时,设计辟如ID等不重复的编号以实现区分,被添加的编号或ID选作主键。(该主键的添加时在ER设计时添加,不是建库是随意添加) 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之

数据库设计三大范式应用实例剖析

数据库设计三大范式应用实例剖析

数据库设计三大范式应用实例剖析 引言 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。 设计范式是不是很难懂呢?非也,大学教材上给我们一堆数学公式我们当然看不懂,也记不住。所以我们很多人就根本不按照范式来设计数据库。 实质上,设计范式用很形象、很简洁的话语就能说清楚,道明白。本文将对范式进行通俗地说明,并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。 范式说明

第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。 例如,如下的数据库表是符合第一范式的:字段1 字段2 字段3 字段4 而这样的数据库表是不符合第一范式的: 字段1 字段2 字段3 字段4 字段3.1 字段3.2 很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现

有的DBMS中设计出不符合第一范式的数据库都是不可能的。 第二范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。 假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系: (学号, 课程名称) →(姓名, 年龄, 成绩, 学分) 这个数据库表不满足第二范式,因为存在如下决定关系: (课程名称) →(学分)

数据库三种范式

数据库的三个范式 第一范式:关系模式中,每个属性不可再分。属性原子性 第二范式:非主属性完全依赖于主属性,即消除非主属性对主属性的部分函数依赖关系。第三范式:非主属性对主属性不存在传递函数依赖关系。 BNCF范式:在第三范式的基础上,消除主属性之间的部分函数依赖 关系数据库设计之时是要遵守一定的规则的。尤其是数据库设计范式现简单介绍1NF(第一范式),2NF(第二范式),3NF(第三范式)和BCNF,另有第四范式和第五范式留到以后再介绍。在你设计数据库之时,若能符合这几个范式,你就是数据库设计的高手。 第一范式(1NF):在关系模式R中的每一个具体关系r中,如果每个属性值都是不可再分的最小数据单位,则称R是第一范式的关系。例:如职工号,姓名,电话号码组成一个表(一个人可能有一个办公室电话和一个家里电话号码)规范成为1NF有三种方法: 一是重复存储职工号和姓名。这样,关键字只能是电话号码。 二是职工号为关键字,电话号码分为单位电话和住宅电话两个属性 三是职工号为关键字,但强制每条记录只能有一个电话号码。 以上三个方法,第一种方法最不可取,按实际情况选取后两种情况。 第二范式(2NF):如果关系模式R(U,F)中的所有非主属性都完全依赖于任意一个候选关键字,则称关系R 是属于第二范式的。 例:选课关系SCI(SNO,CNO,GRADE,CREDIT)其中SNO为学号,CNO为课程号,GRADEGE 为成绩,CREDIT 为学分。由以上条件,关键字为组合关键字(SNO,CNO) 在应用中使用以上关系模式有以下问题: a.数据冗余,假设同一门课由40个学生选修,学分就重复40次。 b.更新异常,若调整了某课程的学分,相应的元组CREDIT值都要更新,有可能会出现同一门课学分不同。 c.插入异常,如计划开新课,由于没人选修,没有学号关键字,只能等有人选修才能把课程和学分存入。 d.删除异常,若学生已经结业,从当前数据库删除选修记录。某些门课程新生尚未选修,则此门课程及学分记录无法保存。 原因:非关键字属性CREDIT仅函数依赖于CNO,也就是CREDIT部分依赖组合关键字(SNO,CNO)而不是完全依赖。 解决方法:分成两个关系模式SC1(SNO,CNO,GRADE),C2(CNO,CREDIT)。新关系包括两个关系模式,它们之间通过SC1中的外关键字CNO相联系,需要时再进行自然联接,恢复了原来的关系 第三范式(3NF):如果关系模式R(U,F)中的所有非主属性对任何候选关键字都不存在传递信赖,则称关系R是属于第三范式的。 例:如S1(SNO,SNAME,DNO,DNAME,LOCATION)各属性分别代表学号, 姓名,所在系,系名称,系地址。 关键字SNO决定各个属性。由于是单个关键字,没有部分依赖的问题,肯定是2NF。但这关系肯定有大量的冗余,有关学生所在的几个属性DNO,DNAME,LOCATION将重复存储,插入,删除和修改时也将产生类似以上例的情况。 原因:关系中存在传递依赖造成的。即SNO -> DNO。而DNO -> SNO却不存在,DNO -> LOCATION, 因此关键辽SNO 对LOCATION 函数决定是通过传递依赖SNO -> LOCATION 实现的。也就是说,SNO不直接决定非主属性LOCATION。

数据库原理与应用期末复习(综合全含名词解释)

名词解释 实体完整性 实体完整性要求每一个表中的主键字段都不能为空或者重复的值。 事务的原子性 事务的原子性指的是,事务中包含的程序作为系统的逻辑工作单位,它所做的对数据修改操作要么全部执行,要么完全不执行。 X封锁 若事务T对数据对象A加上X锁,则只允许T读取和修改A,其他事务都不能再对A加任何类型的所。直到T释放A上的锁。可见X锁只允许一个事务独锁某个数据,具有排他性。 两段锁协议 两段锁协议是指每个事务的执行可以分为两个阶段:生长阶段(加锁阶段)和衰退阶段(解锁阶段)。数据字典 数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述,其目的是对数据流程图中的各个元素做出详细的说明,使用数据字典为简单的建模项目。 DBA 数据库管理员 数据库管理系统 数据库管理系统(Database Management System)是一种操纵和管理数据库的大型软件,用于建立、使用和维护数据库,简称DBMS 实体 数据库实体就是数据库管理系统中的不同管理对象。 简答题 简述事务所具有的ACID特性。 原子性、一致性、隔离性、持久性 关系模型有何特点? 1.关系模型与非关系模型不同,它是建立在严格的数学概念基础上的。 2.关系模型的概念单一,无论实体或实体之间的联系都用关系表示。 3.存取路径对用户透明。 4.关系必须是规范化的关系。 什么是事务,事务有哪些特性? 事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。 事务是恢复和并发控制的基本单位。 事务应该具有4个属性:原子性、一致性、隔离性、持续性。这四个属性通常称为ACID特性。 什么是视图,它与表的区别是什么? 视图是外模式一级数据结构的基本单位。它是从一个或几个基本表中导出的表,是从现有基本表中抽取若干子集组成用户的“专用表” 区别:1、视图是已经编译好的sql语句。而表不是 2、视图没有实际的物理记录。而表有。 3、表是内容,视图是窗口 4、表只用物理空间而视图不占用物理空间,视图只是逻辑概念的存在,表可以及时四对它进行修改,但视图只能有创建的语句来修改 5、表是内模式,试图是外模式 6、视图是查看数据表的一种方法,可以查询数据表中某些字段构成的数据,只是一些SQL语句的集合。

数据库范式详解

第一范式(1NF): 定义:当关系模式R的所有属性都不能在分解为更基本的数据单位时,称R是满足第一范式的,简记为1NF。 列1唯一确定列2, 列3, 列4, ...,即列2, 列3, 列4, ...不能再分裂出其它列。 (简易理解:表中的每列的属性不可再分,每一列(每个字段)必须是不可拆分的最小单元) 举例说明: 上表中,可以看到(就读信息)这一列,其实可以分解为年级和专业,也因为(就读信息)这一属性可以再分,故不满足第一范式 修改:

第二范式(2NF): 定义:如果关系模式R满足第一范式,并且R得所有非主属性都完全依赖于R 的每一个候选关键属性,称R满足第二范式,简记为2NF。 满足2NF的前提是必须满足1NF。此外,关系模式需要包含两部分内容,一是必须有一个(及以上)主键;二是没有包含在主键中的列必须全部依赖于全部主键,而不能只依赖于主键的一部分而不依赖全部主键。 简易理解:满足1NF后,要求表中的所有列,都必须依赖于所有主键,而不能有任何一列与任一主键没有关系。 举例说明: 上表中,可以看到(教师姓名、成绩)两个属性都依赖于(学号)和(课程),但是(学生姓名、专业)这一属性却只依赖于(学号),不依赖于(课程),即:只需要知道(学号)便可得知(学生姓名、专业)。所以,导致非主属性(学生姓名、专业)不完全依赖于主键(学号、课程),故不符合第二范式。

修改: 将原表拆分为两张表,即可实现让它的非主属性都完全依赖于主键,即可符合第二范式(2NF) (成绩)和(教师姓名)两个非主属性都依赖于主键(学号、课程)

第三范式(3NF): 定义:设R是一个满足第一范式条件的关系模式,X是R的任意属性集,如果X 非传递依赖于R的任意一个候选关键字,称R满足第三范式,简记为3NF。 满足3NF的前提是必须满足2NF。另外关系模式的非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列m既依赖于全部主键,又依赖于非主键列n的情况。 简单理解:必须先满足第二范式(2NF),要求表中的每一列只与主键直接相关而不是间接相关,列与列之间无关联(表中的每一列只能依赖于主键)。 举例说明: 上表中,表中的非主属性都依赖于(学号),满足了第二范式。 但是,(班主任性别、年龄)这两个属性是直接依赖于(班主任姓名)这一属性的,与(学号)属于间接依赖。 这就导致了表中的非主属性存在着依赖关系,不符合第三范式。

数据库的一二三范式

数据库的第一,二,三范式 博客分类: 数据库 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。 设计范式是不是很难懂呢?非也,大学教材上给我们一堆数学公式我们当然看不懂,也记不住。所以我们很多人就根本不按照范式来设计数据库。 实质上,设计范式用很形象、很简洁的话语就能说清楚,道明白。本文将对范式进行通俗地说明,并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。 范式说明 第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。 例如,如下的数据库表是符合第一范式的: 字段1 字段2 字段3 字段4 而这样的数据库表是不符合第一范式的: 字段1 字段2 字段3 字段4 字段3.1 字段3.2 很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS

中设计出不符合第一范式的数据库都是不可能的。 第二范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。 假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系: (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满足第二范式,因为存在如下决定关系: (课程名称) → (学分) (学号) → (姓名, 年龄) 即存在组合关键字中的字段决定非关键字的情况。 由于不符合2NF,这个选课关系表会存在如下问题: (1) 数据冗余: 同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。 (2) 更新异常: 若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。 (3) 插入异常:

数据库设计三大范式结合实际项目讲解

为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库,必须满足一定的范式。 在实际开发中最为常见的设计范式有三个: 1.第一范式(确保每列保持原子性) 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。 第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性,本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分,那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式,如下表所示。 上表所示的用户信息遵循了第一范式的要求,这样在对用户使用城市进行分类的时候就非常方便,也提高了数据库的性能。 2.第二范式(确保表中的每列都和主键相关)

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。 比如要设计一个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所示。 订单信息表 这样就产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。 而如果把这个订单信息表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示。

数据库三范式经典实例解析

数据库三范式经典实例解析 (2007-09-27 15:30) 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。 设计范式是不是很难懂呢?非也,大学教材上给我们一堆数学公式我们当然看不懂,也记不住。所以我们很多人就根本不按照范式来设计数据库。 实质上,设计范式用很形象、很简洁的话语就能说清楚,道明白。本文将对范式进行通俗地说明,并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。 范式说明 第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。 例如,如下的数据库表是符合第一范式: 而这样的数据库表是不符合第一范式的: 很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 第二范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。 假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系: (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满足第二范式,因为存在如下决定关系: (课程名称) → (学分) (学号) → (姓名, 年龄) 即存在组合关键字中的字段决定非关键字的情况。 由于不符合2NF,这个选课关系表会存在如下问题: (1) 数据冗余: 同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。 (2) 更新异常: 若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。

数据库设计准则(第一、第二、第三范式说明)

数据库设计准则(第一、第二、第三范式说明) I、关系数据库设计范式介绍 1.1 第一范式(1NF)无重复的列 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。 说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 1.2 第二范式(2NF)属性完全依赖于主键[消除部分子函数依赖] 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。例如员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是属性完全依赖于主键。 1.3 第三范式(3NF)属性不依赖于其它非主属性[消除传递依赖] 满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。 II、范式应用实例剖析 下面以一个学校的学生系统为例分析说明,这几个范式的应用。首先第一范式(1NF):

相关文档
最新文档