数据库系统概论 An Introduction to Database System

数据库系统概论An Introduction to Database System 北京建筑工程学院计算机系 Beijing Architecture and Civil Engineering Institute Department of Computer Science Fall 2004 An Introduction to Database Systenm

第五章关系数据理论 5.1 问题的提出 5.2 规范化 5.3 数据依赖的公理系统 *5.4 模式的分解 5.5 小结 An Introduction to Database Systenm

关系数据理论的意义和地位 意义： • 提供分析和判断数据库模式好坏的准则； • 指导设计好的数据库设计。地位： • 本章是本书最难的部分之一，但对于应用设计十分有用。 An Introduction to Database Systenm

数据库设计的一个最基本的问题是如何建立一个好的数据库模式。数据库设计的一个最基本的问题是如何建立一个好的数据库模式。 • 即给出一组数据，如何构造一个适合于它们的数据模式，使数据库系统无论是在数据存储方面，还是在数据操纵方面都有较好的性能。 • E-R模型方法讨论了实体与实体之间的数据联系，现在来讨论实体内部属性与属性之间的数据关联，目标是要设计一个“好”的数据库模型。 An Introduction to Database Systenm

问题的提出 • 问题的提出：－－什么是不好的数据库设计 • 我们目前为止掌握的知识尚无法解决大量的具体设计问题，即关系模式该如何选择。应用数据库应该由多少个表组成，每个表有哪些字段。 • 本章即从理论上解决关系数据库的逻辑设计问题。 An Introduction to Database Systenm

需要解决的问题和手段 • 关系数据库逻辑设计 • 针对具体问题，如何构造一个适合于它的数据模式 • 数据库逻辑设计的工具──关系数据库的规范化理论 An Introduction to Database Systenm

一、概念回顾 • 二、关系模式的形式化定义 • 三、什么是数据依赖 • 四、关系模式的简化定义 • 五、数据依赖对关系模式影响 An Introduction to Database Systenm

一、概念回顾 • 关系：描述实体、属性、实体间的联系。 • 从形式上看，它是一张二维表，是所涉及属性的笛卡尔积的一个子集。 • 关系模式：用来定义关系。 • 关系数据库：基于关系模型的数据库，利用关系来描述现实世界。 • 从形式上看，它由一组关系组成。 • 关系数据库的模式：定义这组关系的关系模式的全体。 An Introduction to Database Systenm

第二章中的定义回顾 • 候选码：若关系中的某一组属性的值能唯一标识一个元组，则称该属性组为候选码。 • 主码：若一个关系中有多个候选码，选其中一个为主码。 • 主属性：主码的诸属性称为主属性。 • 非码属性：不包含在任何候选码中的属性称为非码属性。 • 全码：关系模式的所有属性组是这个关系的候选码时，称为全码。 An Introduction to Database Systenm

二、关系模式的形式化定义 • 关系模式由五部分组成，即它是一个五元组： • R(U, D, dom, F) • R：关系名，符号化的元组语义--表 • U：组成该关系的属性名集合--列的集合 • D：属性组U中属性所来自的域 • dom：属性向域的映象集合 • F：属性间数据的依赖关系集合 An Introduction to Database Systenm

三、关系模式的简化表示 • 关系模式R（U, D, dom, F），D和dom对模式设计关系不大，所以简化为一个三元组：R（U, F）。 • 关系： • 当且仅当U上的一个关系r 满足F时，r称为关系模式 R（U, F）的一个关系 An Introduction to Database Systenm

样历数据库 • 例：描述学校的数据库： • 学生的学号(Sno)、所在系(Sdept) • 系主任姓名(Mname)、课程名(Cname) • 成绩(Grade) • 单一的关系模式：Student <U、F> • U ={ Sno,Sdept,Mname,Cname,Grade} An Introduction to Database Systenm

业务规则 • 学校数据库的语义：(业务规则) • 一个系有若干学生,一个学生只属于一个系； • 一个系只有一名主任； • 一个学生可以选修多门课程,每门课程有若干学生选修； • 每个学生所学的每门课程都有一个成绩。 An Introduction to Database Systenm

系名系主任系 1 1 N N M N 选课课程学生课号名称学号姓名成绩 E-R图 An Introduction to Database Systenm

单个模式的样历数据库 An Introduction to Database Systenm

Sno Cname Grade Sdept Mname 函数依赖 • 属性组U上的一组函数依赖F： • F ＝｛ Sno → Sdept, Sdept → Mname, (Sno, Cname) → Grade ｝ An Introduction to Database Systenm

关系模式Student<U,F>中存在的问题 • 数据冗余太大 • 数据在数据库中的重复存放称为数据冗余。 • 冗余是不可避免的。在一定程度内也是合理的。但是，过度的冗余不仅浪费存储空间，重要的是在对数据进行修改时,容易造成数据的不一致性。 • 例：每一个系主任的姓名重复出现 An Introduction to Database Systenm

更新异常 • 更新异常 • 数据冗余，更新数据时，维护数据完整性代价大。 • 某系更换系主任后，系统必须修改与该系学生有关的每一个元组。一旦遗漏就使数据不一致。 • 修改某学生的基本信息，要随选课多次被修改。 An Introduction to Database Systenm

插入异常 • 插入异常 • 该插的数据插不进去 • 如果一个系刚成立，尚无学生，我们就无法把这个系及其系主任的信息存入数据库。因为该表的码是学生编号,而目前尚无学生,表中不能插入码为空值的记录。 • 即在插入一行时,此关系模式强迫同时增加关于两个实体的数据。 An Introduction to Database Systenm

删除异常 • 删除异常 • 不该删除的数据不得不删。 • 如果某个系的学生全部毕业了，我们在删除该系学生信息的同时，把这个系及其系主任的信息也丢掉了。 • 在删除一行时,删除了关于两个实体的数据。 An Introduction to Database Systenm

结论与成因分析 • 结论： • Student关系模式不是一个好的模式。 • “好”的模式： • 不会发生插入异常、删除异常、更新异常 • 数据冗余应尽可能少。 • 原因：由存在于模式中的某些数据依赖引起的 An Introduction to Database Systenm

解决方案 • 解决方法：通过分解关系模式来消除其中不合适的数据依赖。 • 如果一个关系中,存储了两个或两个以上实体的数据,一般应将它分解为多个关系,使每个关系只有一个实体。 • 将样历数据库分解为三个模式表达： • 学生关系：S(Sno,Sdept,Sno→Sdept) • 学生选课关系：SG(Sno,Cname,G,(Sno,Cname)→G) • 系别关系：Dept(Sdept,Mn,Sedpt→Mn) An Introduction to Database Systenm

书上的样历数据库 An Introduction to Database Systenm

依然存在的问题：(书中的错误) • 依然出现插入异常： • 例如：新建系尚无毕业生，最高年级为3年级，现在输入培养计划中大四的课程信息，出现插入异常。 • 依然出现删除异常： • 如果某个系的大四学生毕业了，在删除该系大四学生信息的同时，把该系的课程信息也删掉了。 An Introduction to Database Systenm

依然出现更新异常： • 如果现在由于课程名称输入错误，需要修改课程名称，系统必须修改每个选修了该门课的学生的元组。一旦遗漏就使数据不一致。 An Introduction to Database Systenm

解决的方法 • 一个大关系分解为若干个小关系。 • 如前面的SC大关系分解为第三章的 Student，SC和Course三个小关系，即可消除三类异常。 An Introduction to Database Systenm

为什么小关系比大关系好呢？现在我们要讨论的就是这个问题。为什么小关系比大关系好呢？现在我们要讨论的就是这个问题。 • 从上面的分解观察到：如果在一个关系模式内，函数依赖形式上如果只有： • 码→非主属性的形式，冗余就较小，三类异常就没有了。 An Introduction to Database Systenm

四、什么是数据依赖 • 1. 完整性约束的表现形式 • 限定属性取值范围：例如学生成绩必须在0-100之间。 • 定义属性间的相互关联，这就是数据依赖，它是数据库模式设计的关键。 An Introduction to Database Systenm

属性之间的关系 • 属性间的关系 • 前面章节讲到客观世界的事务间有着错综复杂的联系。 • 实体间的联系有两类 • 一类是实体与实体之间的联系； • 另一类是实体内部各属性间的联系。 • 在第一章中主要讨论了前一类联系,现在讨论第二类联系。 An Introduction to Database Systenm

属性之间的三种关系 • 属性间的联系可分为以下三类： • 1. 一对一关系 (1∶1) • 以学生模式为例：学生(学号,姓名,性别、年龄、系别,),如果学生无重名,则属性学号与姓名之间是1∶1关系。一个学号唯一地决定一个姓名,一个姓名也可决定唯一的学号。 • 设X、Y是关系R的两个属性(集)。如果对于X中的任一具体值,Y中至多有一个值与之对应,且反之亦然,则称X、 Y两属性间是一对一关系。 An Introduction to Database Systenm

一对多关系 • 2. 一对多关系 (1∶m) • 职工模式中，学号和性别间是一对多关系。一个学号只对应一种性别，但一种性别却可对应多个学号。 • 设X、Y是关系R的两个属性(集)。如果对于X中的任一具体值，Y中至多有一个值与之对应，而Y中的一个值却可以和X中的n个值（n≥0）相对应，则称Y对X是一对多关系。 An Introduction to Database Systenm

多对多关系 • 3. 多对多关系 (m∶m) • 在学生模式中，性别和年龄之间是多对多关系。一种性别可有多个年龄，而一个年龄中也可有多个性别。 • 设X、Y是关系R的两个属性(集)。如果对于X中的任一具体值，Y中有m(m≥0)个值与之对应，而Y中的一个值也可以和X中的n个值(n≥0)相对应，则称Y对X是多对多关系。 An Introduction to Database Systenm

数据依赖 • 上述属性间的三种关系实际上是属性值之间相互依赖又相互制约的反映,称为属性间的数据依赖。 • 是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系；学号→系别。自变量x确定，函数值f(x)就确定了。 • 是现实世界属性间相互联系的抽象； • 是数据内在的性质； • 是语义的体现； An Introduction to Database Systenm

数据依赖类型 • 3. 数据依赖的类型 • 函数依赖（记为FD）：例如：x--学号，y=f(x)--系。x→y • 多值依赖（记为MVD）：例子见书P178--例题1 • 其他：连接依赖JD An Introduction to Database Systenm

5.2 规范化理论 • 规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。 An Introduction to Database Systenm

关系的规范化 • 所谓规范化,就是用形式更为简洁、结构更加规范的关系模式取代原有关系的过程。 • 目的 • 将具有不合适关系转换为更合适的形式。 • 要求 • 掌握函数依赖的定义及判定； • 掌握1NF到BCNF的定义及判定； • 了解多值依赖，理解4NF的定义。 An Introduction to Database Systenm

5.2.1 函数依赖 一、函数依赖二、平凡函数依赖与非平凡函数依赖三、完全函数依赖与部分函数依赖四、传递函数依赖 An Introduction to Database Systenm

一、函数依赖 • 函数依赖是属性之间的一种联系。假设给定一个属性的值,就可以唯一确定（查到）另一个属性的值。 • 例如,知道学生编号的值,可以得出其对应的姓名的值。如果这种情况成立，就可以说姓名函数依赖于学生编号。 • 定义5.1 设R(U)是一个属性集U上的关系模式，X和Y是U的子集。 An Introduction to Database Systenm

函数依赖定义 • 如果对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称 “X函数确定Y” 或 “Y函数依赖于X”，记作X→Y。 • 说明：设t1,t2是关系中的任意两个元组，如果t1[x]=t2[x]，则t1[Y]=t2[Y]。 • X称为这个函数依赖的决定属性集。Y=f(x) An Introduction to Database Systenm

函数依赖的辨别 • 前面讨论的属性间的三种关系,并不是每一种关系中都存在函数依赖。 • (1) 如果两属性集X、Y间是1∶1关系，则存在函数依赖：X←→Y。如学生关系模式中，如果不允许同名学生存在，则有：学号←→姓名。 • (2) 如果两属性集X、Y间是1∶m关系，则存在函数依赖：X→Y。如：学号→性别。 • (3) 如果两属性集X、Y间是m∶n关系,则不存在函数依赖。如性别和年龄之间即如此。 An Introduction to Database Systenm

说明： • 函数依赖不是指关系模式R的某个或某些关系实例满足上述限定的约束条件，而是指R的所有关系实例均要满足的约束条件。只要有一个具体关系r不满足定义中的条件,就破坏了函数依赖,使函数依赖不成立。 An Introduction to Database Systenm

说明： • 函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。 • 例如“姓名→年龄”这个函数依赖只有在不允许有同名人的条件下成立 • 数据库设计者可以对现实世界作强制的规定。例如规定不允许同名人出现，函数依赖“姓名→年龄”成立。所插入的元组必须满足规定的函数依赖，若发现有同名人存在，则拒绝装入该元组。 An Introduction to Database Systenm

函数依赖示例 • 例：Student(Sno,Sname,Ssex,Sage, Sdept) • 假设不允许重名，则有: • Sno→Ssex, Sno→Sage, Sno→Sdept, Sno←→ Sname, Sname→Ssex, Sname→Sage, Sname→ Sdept • 但Ssex →Sage • 若X→Y,则X叫做决定因素。 • 若X→Y，并且Y→X, 则记为X←→Y。 • 在这种情况下，X和Y在R(U)中地位相同。 • 若Y不函数依赖于X, 则记为X→Y。 An Introduction to Database Systenm

二、平凡函数依赖与非平凡函数依赖 • 在关系模式R(U)中，对于U的子集X和Y • 如果X→Y，但Y  X，则称X→Y是非平凡的函数依赖 • 若X→Y，但Y  X, 则称X→Y是平凡的函数依赖 • 例：在关系SC(Sno,Cno,Grade)中， • 非平凡函数依赖： (Sno, Cno) → Grade • 平凡函数依赖：(Sno, Cno) → Sno ; (Sno, Cno) → Cno An Introduction to Database Systenm

平凡函数依赖与非平凡函数依赖 • 对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义，因此若不特别声明，我们总是讨论非平凡函数依赖。 An Introduction to Database Systenm

三、完全函数依赖与部分函数依赖 • 定义5.2 在关系模式R(U)中，如果X→Y，并且对于X的任何一个真子集X’，都有X’→Y, 则称Y完全函数依赖于X，记作X→Y。 • 若X→Y，但Y不完全函数依赖于X，则称Y部分函数依赖于X，记作X→Y f p An Introduction to Database Systenm

完全与部分函数依赖示例 • 例: 在关系SC(Sno, Cno, Grade)中，由于：Sno→Grade，Cno→Grade，而(Sno, Cno)→Grade • 因此：(Sno, Cno)→Grade f An Introduction to Database Systenm

四、传递函数依赖 • 定义5.3 在关系模式R(U)中，如果X→Y，Y→Z，且Y X，Y→X，则称Z传递函数依赖于X。 • 证明： • 如果t1[x]=t2[x]，则t1[y]=t2[y] • 如果t1[y]=t2[y]，则t1[z]=t2[z] • 得出：如果t1[x]=t2[x], 则t1[z]=t2[z],即X→Z • X→Z并不是显示地表示出来的, 而是从X→Y和Y→Z推出来的, 可表示成蕴含式: {X→Y, Y→Z} x→z An Introduction to Database Systenm

函数传递示例 • 注: 如果Y→X，即X←→Y，则Z直接依赖于X。 • 例: 在关系Std(Sno, Sdept, Mname)中，有： Sno→Sdept，Sdept→Mname Mname传递函数依赖于Sno An Introduction to Database Systenm

5.2.2 码(key) • 在前面章节中我们已对码进行了直观的定义,下面用函数依赖的概念对码作出较为精确的形式化的定义。 • 定义5.4 设K为关系模式R<U,F>中的属性或属性组合。若K→U，则K称为R的一个侯选码。即：k的属性函数决定该关系的所有其他属性。 • 若关系模式R有多个候选码，则选定其中的一个做为主码。即：键码的最小性。 f An Introduction to Database Systenm

数据库系统概论 An Introduction to Database System