8.1问题的提出
数据库逻辑设计的一个强有力的工具--关系数据库的规范化理论。
一个关系既可以用来描述一个实体及其属性,又可以用来描述实体间的联系。
关系模式是用来定义关系的。
一个数据库包含一组关系,定义这些关系的关系模式的全体就构成了该数据库的模式,建成模式Scheme。
数据依赖指数据间的相互关联(主要体现于值的是否相等)。
关系模式应当是一个五元组:
R<U,D,DOM,F>
(1)关系名R它是符号化的元组语义;
(2)一组属性U;
(3)属性组U中属性所来自的域D;
(4)属性到域的映射DOM;
(5)属性组U上的一组数据依赖F。
数据依赖分类:函数依赖(Function Dependency)、多指依赖(Multivalued Dependency)。
函数依赖:如学号(S#)、姓名(SN)、系名(SD)。一个学号对应一个学生,一个学生只能在一个系。就像自变量X确定后,相应的函数值f(x)也就唯一确定了一样。我们说S#函数决定SN、SD或者说SN、SD函数依赖于S#,记为S# ->SN,s#->SD。1:1单调函数,n:1费单调函数。
例如:现在建一个数据库描述学校中的情况,面临的对象有:学生(用学号S#描述),系(用系名SD描述),系主任(用姓名MN描述),课程(用课程名CN描述)和成绩(G)。于是得到了一组属性。
U={S#,SD,MN,CN,G}
根据现实需求:
1.一个系有若干学生,一个学生只能属于一个系。
2.一个系只有一个系主任。
3.一个学生可以选多门课,一门课可以供多个学生选修。
4.每个学生选修一门课有一个成绩。
于是得到了属性组U上的一组函数依赖:F={S#->SD,SD->MN,(S#,CN)->G}
如果只考虑函数依赖,得到一个关系模式S<U,F>。
在一个关系模式中,必然存在一个属性组E,对于该关系模式的任何一个关系,当E的值确定之后,关系中别的属性的值也唯一地被确定了,并且E的任何一个真子集不再具有这样的性质。那么E就是这个关系模式的一个码,或叫做候选码。一个关系模式可有多个候选码,指定其中一个作为主码。在上面的关系模式中只有唯一码(S#,CN)。
以上例子有三个“毛病”:
1.如果系刚成立,还没有学生,或者有学生但是没有安排课程。则无法把该系及其负责人的信息存入数据库。这叫插入异常。
2.反过来,如果某系学生全部毕业,我们在删除该系同学的时候把这个系及其负责人的信息也删除了,这叫删除异常。
3.冗余太大。每一个系负责人的信息与该系每一个学生的每门课成绩出现一样多次数。浪费存储空间,维护困难。如换系主任了,逐一更改每一个学生选课元组。
分析原因,函数依赖X->Y不仅给出了对关系的一个完整性约束,而且给出了数据库用作存储的某种联系:从X的信息应该知道Y的信息。若X不含码,就不能从X确定其他信息。即从存储的观点看,一个关系只能反映出码函数决定关系中别的属性的函数依赖。于是,本来S#->SD,SD->MN,但由于他们都不是码,这些信息就无法依附于S#或SD在数据库中存在,而必须让他们依附于(S#,CN)这个属性组(码)存在。这样就导致了三个“毛病”。
解决办法就是使模式中的各个关系模式打到某种程度的“分离”。可以把关系模式S分成三个关系模式:SD<S#,SD,S#->SD>,SG<S#,CN,G,(S#,CN)->G>,D<SD,MN,SD->MN>。这就是一事一地的原则(one fact one place)一种关系值用来描述一个实体或实体间的属性。下面介绍规范化理论就是基于这样一个简单的概念。
8.2规范化(Normalization)
上节的例子说明并非所有满足1NF的关系都能很好的描述现实世界,必须做进一步的分析,以确定如何设计一个好的、反应显示世界的模式。本节描述如何将具有不合适性质的关系转换为更合适的形式。
完全函数依赖:R(U)中,若X->Y,且对X的任何真子集X'均有X'->Y不成立,则,Y对X完全函数依赖。
主属性:包含在任何一个候选码中的属性,叫做主属性。不包含在任何码中的属性叫做非主属性。
传递依赖:R(U)中,若X->Y,(Y不是X的子集)Y->X不成立(n:1),Y->Z,则称Z对X传递函数依赖。若X<->Y(1:1)则X->Z,不是传递依赖了。
全码:整个属性集U作为码。属性间多对多对多的关系为全码。
范式:通常按照属性间的依赖情况区分关系规范化的程度为1NF,2NF,3NF,4NF,4NF等。
投影运算:简单的说便是在关系中选择某些属性列。
规范化:一个低一级范式的关系模式,通过投影运算可以转换为若干个高一级范式的关系模式的集合,这种过程就叫做规范化。
2NF:若R∈1NF,且每一个非主属性完全函数依赖于码。-----不要有联合主键就满足2NF
如:上一节的例子码为(S#,C#),函数依赖有:
(S#,C#)->G,S#->SD, (S#,C#)->SD, (S#,C#)->SL,S#->SL,SD->SL(因为每个系只住一个地方)。 (S#,C#)为码,决定G,SD,SL。可实际上S#就可以决定SD,SL。因此非主属性部分依赖于码。
不满足2NF就会产生插入异常,删除异常,冗余太大。
解决办法,用投影运算把关系模式分解为两个模式,SC=S-L-C[S#,C#,G];SL=S-L-C[S#,SD,SL]这样,均满足2NF。
3NF:每个非主属性既不部分依赖于码(2NF),也不传递依赖于码。
上例中SC∈3NF,SL不∈3NF,SL中有传递依赖。传递依赖会产生于2NF相似的问题。
解决办法,用投影运算分解S-L为S-D[S#,SD]与D-L[SD,SL]。
BCNF:关系模式R(U,F)∈1NF,若X->Y且Y不包含于X时,X必包含有码(表中(非主,主)属性必须依赖于码),则R<U,F>∈BCNF。BCNF比3NF又进一步。为修正的第三范式,有时也称第三范式。
属性间关系:1:1X<->Y ; 1:nX->Y; n:n无函数依赖关系; 1:1:n X<->Y->Z; 1:m:mn X->Y->Z传递依赖
3NF和BCNF是在函数依赖的条件下对模式分解所能达到的分离程度的度量。一个模式中的关系模式如果都属于BCNF,n那么在函数依赖范畴,已经实现了彻底分离,已经消除了插入和删除异常。3NF的不彻底性表现在可能存在主属性对码的部分依赖和传递依赖。
BCNF是否就完美了呢?在函数依赖范畴内完美了,可是没有考虑多值依赖。
多值依赖:设R(U)是属性集U上的一个关系模式,X、Y是U的子集。若对R(U)的任一关系R,对于X的一个给定值,存在Y的一组值与其对应。而Y的这组值又不以任何方式与U-X-Y中的属性值相关,那么就说Y多值依赖与X,记为X->->Y(n:m或1:n)。当Y的这组值的个数总为1时,X->->Y就成了X->Y。
多值依赖具有对称性,若X->->Y,则x->->Z,其中Z=U-X-Y(多值依赖定义中的蓝字)。函数依赖可以看作是多值依赖的一种特殊形式。在关系模式中,若删除一些元组,则多值依赖可能被破坏。
若X->->Y,而Z=∅,则称X->->Y为平凡的多值依赖。
多值依赖与函数依赖的比较:
首先,在关系模式R(U)中函数依赖X->Y的有效性仅决定于X、Y这两个属性集的值。只要在R(U)的任何一个关系R中,元组在X和Y上的值满足定义8.1,则函数依赖X->Y在任何属性集W(XY包含于W包含于U)上成立。也就是说X->Y在R[W](XY包含于W包含于U)上成立的充要条件为X->Y在R[XY]上成立。
而多值依赖并非如此。X->->Y在U上是否成立,不仅要检查X、Y上的值,而且要检查Z=U-X-Y上的值。因此若X->->Y在w(w包含于U)上成立,而在U上则不一定成立。所以多值依赖的有效性与属性集的范围有关。X->->Y在U上成立则在W(XY包含于W包含于U)上成立,反之则不然。
4NF:关系模式R<U,F>∈1NF,如果对于R的每个非平凡多值依赖X→→Y(Y X),X都含有候选码,则R∈4NF。(X→Y)如果R ∈ 4NF, 则R ∈ BCNF4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。因为根据定义,对于每一个非平凡的多值依赖X→→Y,X都含有候选码,于是就有X→Y,所以4NF所允许的非平凡的多值依赖实际上是函数依赖。
总结:
在关系数据库中,对关系模式的基本要求是满足第一范式。这样的关系模式就是合法的、允许的。但是,人们发现有些关系模式存在插入、删除异常、修改复杂,数据冗余等毛病。人们寻找解决这些问题的方法,这就是规范化的目的。
规范化的基本思想是逐步消除数据依赖中不合适的部分,使模式中的各关系模式达到某种程度的‘分离’,即‘one fact one place’的模式设计原则。让一个关系描述一个概念,一个实体或者实体间的一种联系。若多于一个概念就把它‘分离出去’。因此所谓规范化实质上是概念的单一化。关系模式的规范化过程是通过对关系模式的分解来实现的。用投影运算把低一级的关系模式分解为若干个高一级的关系模式。这种投影分解不是唯一的。投影运算的原则下节会介绍。
按照one fact one place的原则构造关系模式(建表)。
1.建表不要定义联合主键,避免违反2NF。
2.one fact one place,表中的码只能取一到两个,再多就要拆表了,避免违反3NF的传递依赖。
3.两个以上多值依赖就拆分表,变成4NF。
4.拿不准具体属性的表,用本章的规范化方法,画图,分析依赖关系,符合BCNF,投影运算,拆表,多值依赖变成4NF。
分享到:
相关推荐
数据库系统概论是一门深入研究数据管理、存储和检索的核心课程,主要涵盖了关系数据库理论、数据库设计、数据库管理系统实现以及数据库应用开发等多个方面。电子版的《数据库系统概论》通常以PDF格式提供,便于读者...
6. **第06章-关系数据库理论**:这部分可能包含关系理论的深入探讨,如Codd的12条规则、关系数据范式(1NF、2NF、3NF、BCNF等)以及数据库设计的规范化过程。 7. **第07章-数据库设计(2)**:数据库设计是数据库系统...
### 数据库系统概论复习总结 #### 一、文件系统与数据库系统的区别和联系 - **区别**: - **面向对象**:文件系统通常针对单一应用程序设计,而数据库系统面向整个组织或多个应用程序。 - **数据共享**:文件...
4. **范式理论**:范式是衡量关系数据库合理性和规范化程度的标准,包括第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)和第四范式(4NF)等。遵循更高的范式可以减少数据冗余,提高数据...
书中会介绍规范化理论,如第一范式(1NF)、第二范式(2NF)、第三范式(3NF)以及BCNF(巴斯-科德范式),帮助读者理解如何消除数据冗余,提高数据库效率。 4. 数据库安全性与完整性:这一部分会讨论如何保护...
7. **第8章 数据库编程**: 数据库编程主要涉及如何在应用程序中使用SQL与数据库交互,如JDBC(Java Database Connectivity)或ODBC(Open Database Connectivity)。可能还会涵盖存储过程、触发器和游标等高级编程...
4. **范式理论**:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)等,是数据库规范化设计的基础,防止数据冗余和更新异常。 5. **数据库设计**:包括需求分析、概念设计、逻辑设计和物理设计四个阶段,确保...
规范化理论在此过程中起到重要作用,如第一范式(1NF)、第二范式(2NF)、第三范式(3NF)和BCNF(博科斯范式)等。 6. 数据库安全性与完整性:数据库的安全性涉及用户权限控制、数据加密等,以防止未授权访问和...
2. **关系数据库理论**:详细解析关系数据模型,如关系代数、元组演算和域演算,以及关系数据库的规范化理论,如第一范式(1NF)、第二范式(2NF)、第三范式(3NF)和BCNF。 3. **数据库设计**:涵盖需求分析、...
关系模式A的规范化程度最高达到2NF,因为A关系模式A满足第二范式的条件,即每个非主属性都完全函数依赖于候选键。 3. 将关系模式A分解为两个关系模式A1(C,T),A2(H,R,S),则其中A1的规范化程度达到(D) 将...
5. **数据库设计**:这部分讲述了数据库设计的过程,包括需求分析、概念设计(ER模型)、逻辑设计(关系模式)和物理设计,强调了数据库的规范化理论,如第一范式(1NF)、第二范式(2NF)、第三范式(3NF)和BCNF...
理解范式理论,如第一范式(1NF)、第二范式(2NF)、第三范式(3NF)和BCNF,以及反规范化(Denormalization)的概念。 5. 数据库安全性与完整性:理解权限、角色、视图等概念,掌握如何设置和管理用户访问权限。...
数据库设计是本课件的另一个重点,第八章和第九章对此进行了全面的阐述。本部分从需求分析开始,讲述了如何根据实际需求进行逻辑设计和物理设计。同时,本部分还关注数据库性能的优化问题,这是数据库设计过程中不可...
重点是规范化理论,如第一范式(1NF)、第二范式(2NF)到第三范式(3NF),以及BCNF(博科斯范式)等,以减少数据冗余和提高数据一致性。 6. **事务处理**:数据库事务是一系列数据库操作的逻辑单元,具有原子性、...
第八章和第九章则关注数据库的安全性与完整性问题。这包括了权限管理、角色定义、数据加密以及完整性约束等内容。安全性与完整性是数据库系统设计和应用中的核心考量,只有确保了数据的准确性和安全性,数据库系统...
此外,还会讲解规范化理论,如第一范式(1NF)、第二范式(2NF)和第三范式(3NF),这些是确保数据库高效、无冗余的关键。 第7章通常会讲解查询处理和优化。在这个阶段,你将学习到查询解析、查询计划生成以及执行...
5. **第6章 关系数据理论**:这一章深入到关系数据理论,可能包括关系的规范化理论,如第一范式(1NF)、第二范式(2NF)、第三范式(3NF)和BCNF(Boyce-Codd范式),以及消除数据冗余和提高数据库效率的方法。...
《数据库系统概论》第三版是一本深入浅出地介绍数据库系统理论与实践的专业教材。这本书涵盖了数据库领域的核心概念、设计原则以及应用技术,对于学习和理解数据库有极高的指导价值。作为一本针对中文读者的教材,它...
本篇文章将根据《王珊数据库系统概论(第五版)》第1到11章的PPT讲义,带领读者深入理解数据库系统的核心概念和知识点。 首先,第一章向我们介绍了数据库系统的基本概念。我们首先需要明白什么是数据、数据库、...