第2章关系数据库电子课件 MySQL数据库管理与应用.pptx

《第2章关系数据库电子课件 MySQL数据库管理与应用.pptx》由会员分享，可在线阅读，更多相关《第2章关系数据库电子课件 MySQL数据库管理与应用.pptx（89页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第2章关系数据库电子课件 MySQL数据库管理与应用第2章 关系数据库主要内容2.1 关系模型2.2 关系代数2.3 关系数据库设计2.4 本章小结2.1 关系模型E.F.Codd,1970关系模型的三要素关系数据结构关系数据操作关系的完整性约束条件2.1.1 关系模型的三要素关系数据结构关系模型的数据结构非常单一，即关系。现实世界中的实体以及实体之间的各种联系统一用关系表示。在用户看来，一个关系就是一张二维表。l行：元组（记录）l列：属性（字段）2.1.1 关系模型的三要素关系数据操作查询和更新（插入、修改、删除）两大类集合操作方式（set-at-a-time）高度非过程化种类2.1.1 关

2、系模型的三要素关系的完整性约束条件实体完整性参照完整性用户定义的完整性实体完整性和参照完整性是关系模型必须满足的完整性约束条件，被称为关系的两个不变性，应由关系系统自动支持。具体的应用领域还可能存在一些特定的语义约束，用户可以相应地定义一些完整性约束条件，这些完整性约束条件一经用户定义也应由关系系统自动支持。2.1.2 关系数据结构域（Domain）一组具有相同数据类型的值的集合。在关系中，域用来作为属性的取值范围。l学号属性所取的由11位数字组成的字符串集合l年龄属性所取的大于14且小于40的正整数集合l性别属性所取的由“男”和“女”这两个值组成的集合笛卡尔积（Cartesian Produ

3、ct）给定了一组域 ，这些域的笛卡尔积定义为：每一个元素称为一个n-元组（n-tuple），简称元组（Tuple）。元组中的每一个值称为一个分量（Component）。2.1.2 关系数据结构若干域的笛卡尔积可表示成一张二维表，表中的每一行对应于笛卡尔积的每一个元素或元组，表中的每一列对应于笛卡尔积的每一个域。例如，给定了以下三个域：姓名集合(name)=张林，李宏年龄集合(age)=20，21专业集合(major)=计算机科学与技术，软件工程则它们的笛卡尔积为：(张林，20，计算机科学与技术)，(张林，20，软件工程)，(张林，21，计算机科学与技术)，(张林，21，软件工程)，(李宏，20

4、，计算机科学与技术)，(李宏，20，软件工程)，(李宏，21，计算机科学与技术)，(李宏，21，软件工程)2.1.2 关系数据结构该笛卡尔积一共有 个元组，可表示成如表2.1所示的一张二维表。显然，如表2.1所示的笛卡尔积中有很多元组是没有任何实际意义的。2.1.2 关系数据结构关系（Relation）从相关域的笛卡尔积中抽取的具有实际意义的若干元组所构成的集合。作为笛卡尔积的子集，关系同样可以表示成二维表的形式。假设所有学生都不会同名，且每名学生只属于一个专业，那么表2.1中只有两个元组具有实际意义。假设张林和李宏的年龄分别是21和20岁，分别是计算机科学与技术和软件工程专业的学生，相应的两

5、个元组就构成了描述学生年龄及其所属专业的一个关系，如表2.2所示。2.1.2 关系数据结构关系（Relation）关系的每一行就是关系的一个元素或元组（Tuple），描述一个具体的实体或实体之间的一个具体联系，通常用t表示。关系的每一列就是关系的一个属性（Attribute）或字段（Field），其值来自相应的域。在关系的所有属性中，可以唯一确定一个元组的属性或属性的最小组合称为该关系的码（键，Key）或候选码（候选键，Candidate Key）。如果候选码多于一个，则选取其中一个候选码作为主码（主键，Primary Key）。包含在任一候选码中的属性称为主属性（Primary Attrib

6、ute）。不包含在任何候选码中的属性称为非主属性（Non-Primary Attribute）或非码属性（Non-Key Attribute）。2.1.2 关系数据结构关系（Relation）关系模型要求关系必须是规范的，即要求关系必须满足一定的规范性条件，满足一定规范性条件的关系模式的集合称为范式（Normal Form，简称NF）。最基本的规范条件就是关系的每一个分量都必须取不可再分的原子值。2.1.2 关系数据结构关系模式（Relation Schema）对关系的结构及其特征的抽象描述，相对稳定。形式化表示为一个五元组R(U,D,dom,F)lR为关系名。lU为组成该关系的属性名集合。l

7、D为U中各属性来自的域集合。ldom为属性到域的映射集合，用来确定U中的每一个属性分别来自D中的哪一个域。lF为属性间的数据依赖集合，用来限定组成该关系的各元组必须满足的完整性约束条件，体现了关系的元组语义。通常简记为：R(U)或R(A1,A2,An)l表2.2中的student关系可抽象描述为：student(name,age,major)关系模式与关系：型（Type）与值（Value）2.1.3 关系的完整性约束条件实体完整性（Entity Integrity）若属性A是关系R的主属性，则属性A不能取空值。所谓空值（null）是指“不知道”或“不存在”的值。由于主属性是用来唯一标识实体的基

8、本属性，若主属性取空值，就说明这个实体不能被唯一标识，这与现实世界的要求和实体能被相互区分是背离的。实体完整性要求所有主属性都不能取空值。lstudent(name,age,major)l选修（学号，课程号，成绩）2.1.3 关系的完整性约束条件参照完整性（Referential Integrity）现实世界中实体与实体之间往往存在着某种联系，表现在关系数据库中就是关系与关系之间的属性引用。学生、专业实体以及它们之间的一对多的属于联系可以用下面两个关系表示：l学生（学号，姓名，性别，年龄，专业号）l专业（专业号，专业名，专业负责人）学生和专业之间的属于联系表现为这两个关系之间的属性引用，即学生

9、关系的“专业号”属性引用了专业关系的主码“专业号”。2.1.3 关系的完整性约束条件参照完整性（Referential Integrity）学生关系中的“专业号”值必须是确实存在的某个专业的专业号，即专业关系中的某个“专业号”值，专业关系中不存在的“专业号”值是毫无意义的。在这样的属性引用中，学生关系中“专业号”属性的取值需要参照专业关系中主码“专业号”的取值。2.1.3 关系的完整性约束条件参照完整性（Referential Integrity）在学生关系中，“专业号”属性虽然不是主码，但它却引用（或参照）了专业关系的主码，这样的属性引用不但可以表达学生和专业之间的属于联系，而且还使它的取值

10、受到了一定的限制，这样的属性称为外码或外键。外码：设F是关系R的一个（或一组）属性，但不是关系R的码，若F引用（或参照）了关系S的主码Ks，则称F是R的外码（外键，Foreign Key）。显然，外码F和主码Ks必须定义在同一个（或同一组）域上。2.1.3 关系的完整性约束条件参照完整性（Referential Integrity）参照完整性：若属性（或属性组）F是关系R的外码，引用（或参照）的是关系S的主码Ks，则R中每个元组在F上的取值l要么为空值；l要么为S中某个元组的Ks值。和实体完整性约束主属性的取值不同，参照完整性约束的是外码的取值，用来保证外码对相应主码的正确引用，以体现客观对象

11、之间的各种联系，从而实现了数据的整体结构。l级联删除l级联修改按照参照完整性，学生关系中的“专业号”属性l要么取空值，表示该生尚未分配专业或者不知道他的专业；l要么取专业关系中的某个“专业号”值，表示该生已属于某个确实存在的专业。2.1.3 关系的完整性约束条件参照完整性（Referential Integrity）学生（学号，姓名，性别，年龄，专业号）课程（课程号，课程名，学分）选修（学号，课程号，成绩）选修关系和学生、课程关系之间都存在属性的引用。因此，选修关系有两个外码：学号和课程号。2.1.3 关系的完整性约束条件参照完整性（Referential Integrity）按照参照完整性l

12、选修关系的“学号”属性要么取空值，要么取学生关系中的某个“学号”值，即某名学生的学号。l选修关系的“课程号”属性要么取空值，要么取课程关系中的某个“课程号”值，即某门课程的课程号。当然，这两个属性都不能取空值。为什么？2.1.3 关系的完整性约束条件用户定义的完整性（User-defined Integrity）除了实体完整性和参照完整性外，具体的应用领域还可能存在一些特定的语义约束。l大学生的年龄限定在1440岁之间l课程名要求不重复l大学生的不及格门次限定在3门以下l成绩的取值范围为0100l 为了使数据能正确反映这些语义约束，从而真实地模拟现实世界，用户可以相应地定义一些完整性约束条件。

13、这些完整性约束条件一经用户定义，也应和实体完整性、参照完整性一样由关系系统自动支持，而不应像文件系统那样由应用程序来承担这一功能。2.2 关系代数用对关系的运算即代数方式来表达查询的一种抽象的查询语言。运算对象是一个或多个关系运算结果也是一个新的关系 运算符：8个2.2.1 传统的集合运算并（Union）交（Intersection）差（Difference）很显然，条件：R和S具有相同的属性个数，并且对应的属性来自同一个域，即它们的结构是兼容的。RS2.2.1 传统的集合运算假设由所有2019级学生构成的关系为student_2019（如表2.5所示），由所有获得一等奖学金的学生构成的关系为

14、student_first（如表2.6所示）。2.2.1 传统的集合运算广义笛卡尔积（Extended Cartesian Product）l 表示R中元组 和S中元组 拼接而成的一个新元组。2.2.2 专门的关系运算选择（Selection）又称限制（Restriction），是一个单目运算，其结果是从参与运算的关系中选择满足给定条件的那些元组所构成的一个新关系。F为选择条件，是由逻辑运算符（and）、（or）或（not）连接各比较表达式组成的一个逻辑表达式。就是从关系R中选择使条件F为真的那些元组。2.2.2 专门的关系运算假设学生选课数据库包括学生关系、课程关系和选修关系。2.2.2 专

15、门的关系运算【例2-1】查询0101号专业所有学生的基本情况。或2.2.2 专门的关系运算【例2-2】查询年龄小于或等于20岁的0101号专业所有学生的基本情况。或 2.2.2 专门的关系运算投影（Projection）单目运算，其结果是从参与运算的关系中选择给定的若干属性所构成的一个新关系。A为R中的属性（或属性组）。和选择操作不同，投影操作是从属性（列）的角度进行运算。【例2-3】查询所有学生的学号和姓名。或 2.2.2 专门的关系运算【例2-4】查询学生表中有哪些专业。或由于只保留了关系的部分列，因此可能会出现重复行，投影结果应消除这些重复行，如表2.19所示。2.2.2 专门的关系运算

16、连接（Join）广义笛卡尔积会产生大量无效元组，为了避免出现无效元组，只有满足一定条件才允许将对应的元组进行拼接，这就是连接操作。连接，也称 连接，是从两个关系的广义笛卡尔积中选择属性间满足一定条件的元组所构成的一个新关系。或者说，两个关系的元组只有相应分量的取值满足一定条件时才能拼接成为新关系中的元组。其中，A和B分别为R和S中可比较的属性（组），是比较运算符。R中元组 在属性（组）A上的取值 和S中元组 在属性（组）B上的取值 只有满足条件 时才能拼接成为 中的元组 。2.2.2 专门的关系运算两种最常用的连接l等值连接（Equi-Join）l自然连接（Natural Join）自然连接是

17、一种特殊的等值连接。自然连接要求两个关系中进行等值比较的属性（组）必须是相同的属性（组）。自然连接的结果要把重复的属性去掉。2.2.2 专门的关系运算【例2-5】设有如图2.4(a)和图2.4(b)所示的两个关系R和S，则不同连接的结果分别如图2.4(c)图2.4(e)所示。2.2.2 专门的关系运算【例2-6】查询选修了课程的学生及其选修课程的基本情况。2.2.2 专门的关系运算除（Division）若要查询选修了某些课程的学生，并且这些课程不能明确地一一列举出来，而只是满足了给定特征（或具有了相同性质）的一组课程，如“刘丽”选修的全部课程，这种情况下仅用选择操作是远远不够的，因为选择条件无

18、法明确给出，这时可以用除运算。给定关系R(X,Y)和S(Y,Z)，即R和S具有相同的属性（组）Y，R与S的除运算得到一个新关系P(X)，P是R中满足以下条件的元组在属性（组）X上的投影：元组在X上的取值x对应的Y值集合（记作x映射到Y上的象集Yx）包含S在Y上投影的集合。2.2.2 专门的关系运算【例2-7】查询至少选修了101和202两门课程的学生学号。若要用选择运算，需要用到集合的交运算，即有：若要用除运算，需要先将查询条件中的不同课程号组建为一个临时关系（集合）K：2.2.3 综合实例【例2-8】查询选修了“数据结构”课程的学生学号。解法一：解法二：选择哪个？2.2.3 综合实例【例2-

19、9】查询选修了全部课程的学生学号和姓名。【例2-10】查询没有选修202号课程的学生学号。数据库设计是针对一个具体的应用环境，设计优化的数据库逻辑结构和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储、管理和利用数据，满足各种用户的应用需求（包括数据需求、处理需求、安全性和完整性需求等）。数据库设计不但要建立数据库，而且还要建立基于数据库的应用系统，即设计整个数据库应用系统，这是对数据库设计的广义理解。本书主要讨论狭义的数据库设计，即设计数据库本身，或者说，设计数据库的各级模式并据此建立数据库。2.3 关系数据库设计2.3 关系数据库设计结构（数据）设计和行为（处理）设计相结合数据库

20、中存储什么样的数据以及它们以什么样的结构组织在一起决定了应用系统能够实现哪些功能以及它们的执行效率如何。具体应用需求还能用来对数据库的结构进行有针对性的优化。l为提高登录操作的执行效率（它对用户的满意度影响很大），可以把该操作涉及到的用户名和密码这2个属性从用户表中分解出来单独建表。l为经常放在一起查询的不同表中的属性考虑是否能将其合并并存储在同一个节点上。l为经常出现在查询条件中的属性建立索引。2.3.1 数据库设计的步骤按照规范设计法，目前人们通常把数据库设计的全过程分为以下6个基本阶段：需求分析概念结构设计逻辑结构设计物理结构设计数据库实施数据库运行和维护在这六个阶段中，需求分析和概念结

21、构设计可以独立于任何数据库管理系统，因此，在设计的初期，并不急于确定到底采用哪一种数据库管理系统，从逻辑结构设计阶段开始才需要选择一种具体的数据库管理系统。2.3.1 数据库设计的步骤数据库的设计需要多种人员在不同阶段参与进来，包括系统分析人员、数据库设计人员、数据库管理员、应用开发人员和用户。系统分析人员和数据库设计人员是数据库设计的核心人员，他们将自始至终参与数据库的设计，他们的水平直接决定了数据库系统的质量。由于需要对数据库进行全面的管理、控制和维护，数据库管理员也需要参与数据库设计的全过程。应用开发人员（包括程序员和操作员）在数据库实施阶段参与进来，负责编制程序和准备软硬件环境。用户在

22、需求分析阶段和概念结构设计阶段参与进来，使设计人员能准确把握用户的各种需求，并设计出用户认可的概念模型；此外，设计出来的数据库最终还要交给用户正式运行，因此，用户还要参与数据库的运行和维护阶段。2.3.1 数据库设计的步骤需求分析阶段进行数据库设计首先必须准确了解和分析各种用户的应用需求。需求分析是整个设计过程的基础和起点，需求分析做得是否充分与准确，决定了在此基础上建立的数据库能否有效地实现既定目标。通过调查、搜集和分析，获得用户对数据库的以下需求：l数据需求l处理需求l安全性与完整性需求对用户的以上需求进行分析和表达之后，必须提交给用户，征得用户的认可。需求分析阶段的一个重要而困难的任务是

23、搜集将来应用可能涉及到的数据，设计人员应充分考虑到应用的可扩充性，使系统易于扩充。2.3.1 数据库设计的步骤概念结构设计阶段概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳和抽象，形成独立于任何数据库管理系统的概念模型，通常用E-R图表达。在需求分析阶段得到的应用需求首先应抽象为信息世界中的概念模型，这样才能更准确地用某一数据库管理系统支持的数据模型来实现这些需求。l和数据模型相比，概念模型更容易被用户理解，能让用户积极地参与到数据库设计中来，是数据库设计成功的关键。2.3.1 数据库设计的步骤逻辑结构设计阶段逻辑结构设计是将概念模型转换为某一数据库管理系统支持的数据模型（

24、如关系模型），并对其进行优化。除模式外，逻辑结构设计还要根据用户对数据的不同需求建立必要的视图，即外模式。2.3.1 数据库设计的步骤物理结构设计阶段物理结构设计是为数据模型选取一个最适合应用环境的物理结构，包括存储结构和存取方法，这依赖于具体的数据库管理系统。不同的数据库管理系统提供的物理环境、存取方法和存储结构有很大差别，为此，需要对在数据库上运行的各种事务进行详细分析，根据所用数据库管理系统提供的存储结构和存取方法，选取一个最适合应用环境的物理结构，使得在数据库上运行的各种事务的总体（或期望）响应时间小、存储空间利用率高、事务吞吐率大。2.3.1 数据库设计的步骤物理结构设计阶段为了提高

25、数据的存取效率l可以为某些属性（如用于表连接的属性、经常出现在查询条件中的属性以及经常需要排序的属性等）建立必要的索引。l可以通过分区、条带化存储、冗余存储等机制利用并行处理技术来提高数据的存取效率。l根据实际情况将数据的易变部分和稳定部分、经常存取部分和存取频率较低部分分开存放。在物理结构设计过程中，需要对时间效率、空间效率和维护代价这3个方面的因素进行权衡（它们常常是相互矛盾的），可以产生多种方案，数据库设计人员应对其进行细致的评价，从中选取一个较优的方案作为数据库的物理结构。2.3.1 数据库设计的步骤数据库实施阶段根据逻辑结构设计和物理结构设计的结果，开发人员使用数据库管理系统提供的数

26、据定义语言（如SQL中的CREATE命令）建立数据库，并编制、调试应用程序，组织数据入库，进行试运行。在协商一致的前提下，分期分批地组织数据入库，逐步增加数据量，逐步完成运行评价。在试运行阶段，首先应调试运行数据库管理系统的转储和恢复功能，做好数据库的转储和恢复工作，尽量减少故障对数据库的破坏。2.3.1 数据库设计的步骤数据库运行和维护阶段数据库试运行合格后，就可以交付给用户正式运行了。由于应用环境的不断变化，对数据库的维护工作将是一项长期任务。在数据库运行阶段，对数据库经常性的维护工作主要由数据库管理员负责完成，包括以下内容：l数据库的转储和恢复l数据的安全性和完整性控制l数据库性能的监督

27、、分析与改造l数据库的重组织和重构造设计一个完善的数据库应用系统往往需要以上6个阶段的不断反复。2.3.1 数据库设计的步骤2.3.2 概念结构设计概念结构设计是将用户需求抽象为概念模型（或称概念结构）的过程，是整个数据库设计的关键。从客观世界中抽取系统需要记录的众多实体（进一步抽象为实体型）及其联系，然后以用户容易理解的格式（如E-R图）表达出来，以便征得用户的认可。依托E-R图进行数据库设计的方法就是人们常用的基于E-R图的数据库设计方法。2.3.2 概念结构设计概念结构设计通常有以下四种方法：自顶向下自底向上逐步扩张混合策略其中，最常用的策略是自底向上方法，即自顶向下地进行需求分析，然后

28、再自底向上地设计概念模型。2.3.2 概念结构设计概念结构设计可分为以下两个步骤:根据需求分析的结果，为每一个局部应用（或称之为子系统）设计相应的局部概念模型（仅是局部用户的数据视图，有时又称局部视图），相应的E-R图被称为分E-R图；将这些局部概念模型集成为一个全局概念模型（即总E-R图，对系统中数据的整体结构进行描述），并对其进行验证，以确保该全局概念模型的一致性，满足需求分析阶段确定的所有用户需求，并最后征得用户的认可。2.3.2 概念结构设计 下面以学生信息管理系统为例具体说明概念结构设计的全过程。为简单起见，本系统仅考虑第1章所述的教务部门、学工部门和团学部门分别使用的学生选课信息管

29、理、学生个人信息管理和学生社团信息管理3个子系统。2.3.2 概念结构设计学生选课信息管理子系统主要用于教务部门对学生的选课及成绩信息进行管理。首先，分析潜在的实体。其次，确定实体之间的联系。2.3.2 概念结构设计学生个人信息管理子系统主要用于学工部门对学生的个人信息及其奖惩情况进行管理。2.3.2 概念结构设计学生社团信息管理子系统主要用于团学部门对学生参加社团的信息进行管理。2.3.2 概念结构设计分E-R图的集成合并。解决各分E-R图之间的冲突，将各分E-R图合并起来，生成初步E-R图。修改和重构。消除不必要的冗余，生成总E-R图。集成后的总E-R图（这里省略了各个实体的属性）2.3.

30、2 概念结构设计将局部概念模型集成为一个全局概念模型后，还需要对这个全局概念模型作进一步的验证，以确保它能满足以下三个条件：全局概念模型内部具有一致性，不存在相互矛盾的表达。全局概念模型应能准确反映原来的每一个局部概念模型。全局概念模型应能满足需求分析阶段确定的所有用户需求。2.3.3 逻辑结构设计概念模型是独立于任何一种数据库管理系统的、更加抽象的模型，若要在计算机上实现数据库，还需选择一种具体的数据库管理系统，将概念模型（即概念结构设计阶段得到的总E-R图）转换为数据库赖以计算机实现的、由该数据库管理系统支持的逻辑模型（如关系模型）。由于目前设计的数据库应用系统大都采用关系数据库管理系统，

31、因此，这里只讨论E-R图向关系模型的转换。2.3.3 逻辑结构设计E-R图向关系模型的转换需要遵循以下原则：实体的转换l一个实体型转换为一个关系模式，关系模式的属性就是该实体的属性，关系模式的码就是该实体的码。二元联系的转换一对一联系l转换为一个独立的关系模式，关系模式的属性包括与该联系相连的两端实体的码以及联系本身的属性，关系模式的码可以是任何一端实体的码。l可以和任何一端实体转换得到的关系模式合并，即在被合并的关系模式中增加与该联系相连的另一端实体的码（将作为外码存在于被合并的关系模式中）以及联系本身的属性，合并后的关系模式的码保持不变。l和哪一端的关系模式合并会更好一些呢？2.3.3 逻

32、辑结构设计E-R图向关系模型的转换需要遵循以下原则：二元联系的转换一对多联系l转换为一个独立的关系模式，关系模式的属性包括与该联系相连的两端实体的码以及联系本身的属性，关系模式的码只能是n端实体的码。l可以和n端实体转换得到的关系模式合并，即在n端实体转换得到的关系模式中增加与该联系相连的另一端实体（即1端实体）的码（将作为外码存在于被合并的关系模式中）以及联系本身的属性，合并后的关系模式的码保持不变。2.3.3 逻辑结构设计E-R图向关系模型的转换需要遵循以下原则：二元联系的转换多对多联系l转换为一个独立的关系模式，关系模式的属性包括与该联系相连的两端实体的码以及联系本身的属性，关系模式的码

33、由这两个实体的码共同组成，在这个独立的关系模式中，它们也都是外码。2.3.3 逻辑结构设计E-R图向关系模型的转换需要遵循以下原则：多元联系的转换l转换为一个独立的关系模式，关系模式的属性包括与该联系相连的各端实体的码以及联系本身的属性，关系模式的码由这些实体的码共同组成，在这个独立的关系模式中，它们也都是外码。一元联系的转换l同一个实体型内部各实体之间联系（一对一、一对多、多对多）的转换规则和二元联系（一对一、一对多、多对多）的转换规则相同。具有相同码的关系模式可以合并l具有相同码的关系模式是否合并，主要看能否提升重要操作或数据库总体（或期望）的执行效率。2.3.3 逻辑结构设计根据以上转换

34、原则，学生信息管理系统的关系模型由以下7个关系模式组成：学生（学号，姓名，性别，出生日期，民族，政治面貌，联系电话，班级，专业，年级，家庭住址，家长姓名，家长联系电话）课程（课程号，课程名，学分）奖励（奖励编号，时间，级别，内容，等级，授予单位，学号）惩罚（惩罚编号，时间，原因，等级，撤销时间，学号）社团（社团名称，社团宗旨，成立时间）选修（学号，课程号，成绩）参加（学号，社团名称，参加时间，身份）2.3.3 逻辑结构设计除了设计全局逻辑模型外，逻辑结构设计阶段还要为具有不同数据需求的用户设计相应的外模式。目前的关系数据库管理系统都提供了视图的概念，用视图来设计外模式。和模式不同，在设计外模式

35、时，主要考虑数据的安全性和用户的使用习惯。为了进一步提高数据库应用系统的性能，还应根据具体的应用需求对设计出来的数据模型进行适当的调整，这就是数据模型的优化。关系模型的优化通常以规范化理论作为指导。对某些关系模式进行合并或分解，在操作效率和潜在问题之间进行权衡。2.3.4 规范化理论规范化理论不但可以用来指导关系模型的优化，而且还可以直接用来设计关系模式，这就是基于3NF的数据库设计方法。针对一个具体应用，在设计数据库的逻辑结构时，首先要考虑的基本问题就是：应该设计几个关系模式，每个关系模式应该由哪些属性组成，设计好的关系模式是不是一个“好”的关系模式等。针对这些问题，人们提出了关系数据库的规

36、范化理论。该理论可以用来判断一个关系模式设计是否合理（规范），以及如何提高其规范程度进而降低潜在的异常问题等，从而成为指导数据库逻辑结构设计的一个有力工具。2.3.4 规范化理论关系模型要求关系必须是规范的，即要求关系必须满足一定的规范性条件。满足一定规范性条件的关系模式的集合称为范式（Normal Form，NF）。前面提到的每一个分量都必须取不可再分的原子值只是其中最基本的规范性条件，满足这一规范性条件的关系属于第1范式（1NF），是规范程度最低的关系。这样的关系会存在一些潜在的异常问题，因此还不能称其为一个“好”的关系。2.3.4 规范化理论现实世界的已知事实限定了关系模式必须满足一定的

37、完整性约束，这些约束或者通过对属性取值范围的限定，或者通过属性间取值的相互依赖关系反映出来，后者称为数据依赖，是判定关系模式是否规范的关键。数据依赖是通过一个关系中各属性间取值的相等与否体现出来的数据间的相互依赖关系，是对现实世界中普遍存在的客观联系的抽象，是语义的体现。函数依赖（Functional Dependency，简称FD）多值依赖（Multivalued Dependency，简称MVD）连接依赖（Join Dependency，简称JD）在关系模式的5元组R(U,D,dom,F)中，F就是属性间的数据依赖集合，这里把关系模式简记为R(U,F)。2.3.4 规范化理论假设要建立一个

38、描述学生基本情况的数据库，涉及的数据包括：学生的学号sno、姓名sname、所属的专业号mno、专业名mname、专业负责人mman、选修的课程号cno、课程名cname及其成绩grade。如果采用单一的关系模式student(U,F)，则有：U=sno,sname,mno,mname,mman,cno,cname,grade2.3.4 规范化理论现实世界存在以下语义：每名学生都只有唯一的一个学号。每个专业都只有唯一的一个专业号。每门课程都只有唯一的一个课程号。一个专业只有一名专业负责人，一名专业负责人只管理一个专业。一个专业有若干名学生，但一名学生只属于一个专业。一名学生可以选修多门课程，一

39、门课程可由多名学生选修。每名学生选修每门课程只会有一个成绩。据此可以得到U上的一组数据依赖，具体地说是函数依赖：F=snosname,snomno,mnomname,mnomman,mnanmno,cnocname,(sno,cno)grade该关系模式只有(sno,cno)这么一个候选码。2.3.4 规范化理论单一的关系模式student(U,F)会存在以下问题：插入异常删除异常 数据冗余度大和更新异常由于存在以上3个问题，该关系模式是一个“不好”的关系模式。如果按“一事一地”原则将其分解为以下4个关系模式：student(sno,sname,mno,snosname,snomno)majo

40、r(mno,mname,mman,mnomname,mnomman,mmanmno)course(cno,cname,cnocname)score(sno,cno,grade,(sno,cno)grade)就可以解决以上3个问题了。2.3.4 规范化理论通过对关系模式的分解，使一个关系只描述一个实体型或实体间的一种联系（和前面介绍的基于E-R图的数据库设计方法殊途同归），可以提高其规范程度，达到消除异常的目的，这一过程就是规范化，从理论上讲，就是用一组等价（不破坏原有数据）的规范程度更高的关系模式代替原来的规范程度较低的关系模式。关系模式规范程度的判定取决于其中存在什么样的数据依赖，是否存在不

41、合适的数据依赖，如果存在，是哪些不合适的数据依赖。2.3.4 规范化理论函数依赖假设存在一个关系模式R(U)，X和Y是U的子集，若对于任一元组在X上的每一个值，都有Y上的唯一值与之对应，或者说，不存在两个元组在X上的值相等但在Y上的值不等，则称X函数决定Y，或称Y函数依赖于X，记作：XY。X称为决定属性集或决定因子（Determinant）。若XY，且YX，则X与Y等价，记作：XY。若X不函数决定Y，或Y不函数依赖于X，记作：XY。函数依赖是语义范畴的概念，需要根据具体语义来确定函数依赖。确定函数依赖可以从分析属性间的联系类型入手。2.3.4 规范化理论由函数依赖的定义可知，函数依赖具有以下性

42、质：若XY，XZ，则XYZ（合并性）若XYZ，则XY，XZ（分解性）若XY，YZ，则XZ（传递性）若XY，则XZYZ（增广性）2.3.4 规范化理论若XY，且 ，则称XY是非平凡的函数依赖；而若XY，且 ，则称XY是平凡的函数依赖。在关系score(sno,cno,grade)中存在函数依赖：(sno,cno)sno(sno,cno)cno(sno,cno)(sno,cno)(sno,cno)grade除了最后一个函数依赖是非平凡函数依赖外，前3个函数依赖都是平凡函数依赖，在任何一个关系中都必然成立，不反映任何新的语义。若不作特殊说明，我们将只讨论非平凡函数依赖。2.3.4 规范化理论在关系模

43、式R(U)中，若XY，并且对于X的任何一个真子集X，都有XY，则称Y对X完全函数依赖，记作：XY；而若XY，但Y不完全函数依赖于X，即存在X的一个真子集X，有XY，则称Y对X部分函数依赖，记作：XY。在student(sno,sname,mno,mname,mman,cno,cname,grade)中存在完全函数依赖：snosname，snomno，mnomname，mnomman，mnanmno，cnocname，(sno,cno)grade据此，我们还可以推导出以下部分函数依赖：(sno,cno)sname，(sno,cno)mno，(sno,cno)mname，(sno,cno)mman

44、，(sno,cno)cnameF P 2.3.4 规范化理论在关系模式R(U)中，若XY（），YX，YZ（），则称Z对X传递函数依赖。加上条件YX，是因为如果YX，则有XY，那么Z对X就是直接函数依赖，而非传递函数依赖。加上条件 和 ，说明Y对X和Z对Y都是非平凡的函数依赖。在关系student(sno,sname,mno,mname,mman,cno,cname,grade)中有snomno和mnomman，根据函数依赖的传递性有snomman，因为mnosno，所以mman对sno是传递函数依赖。2.3.4 规范化理论在关系模式R(U,F)中，若存在属性（或属性组）K，使KU成立，则称K是

45、R的候选码。包含在任一候选码中的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。F 2.3.4 规范化理论范式 范式级别较低的关系模式可以通过分解转换为等价的具有较高范式级别的若干个关系模式，从而达到消除上述异常问题的目的，这一过程就称为规范化。2.3.4 规范化理论2NF若R1NF，且每一个非主属性都完全函数依赖于候选码，则R2NF。也就是说，2NF不允许非主属性对候选码部分函数依赖。在关系score(sno,cno,grade)中，候选码只有一个，即(sno,cno)。因此，只有grade是非主属性，因为(sno,cno)grade，所以score2NF。在关系stude

46、nt(sno,sname,mno,mname,mman,cno,cname,grade)中，候选码也只有一个，即(sno,cno)。因此，它的非主属性有sname、mno、mname、mman、cname和grade。除了grade外的其它非主属性都部分函数依赖于候选码(sno,cno)，因此，student2NF。F 2.3.4 规范化理论关系student(sno,sname,mno,mname,mman,cno,cname,grade)不属于2NF，所以存在上述异常问题。解决的办法就是对该关系模式进行分解，以消除其中存在的非主属性对候选码的部分函数依赖，使之成为2NF关系模式：stude

47、nt(sno,sname,mno,mname,mman)course(cno,cname)score(sno,cno,grade)可以证明，student2NF，course2NF，score2NF。通过分解，上述异常问题可以得到部分解决。关系student(sno,sname,mno,mname,mman)依然存在上述异常问题，因为它不属于3NF。2.3.4 规范化理论3NF若R2NF，且每一个非主属性都不传递函数依赖于候选码，则R3NF。也就是说，属于3NF的关系模式中不存在任何非主属性对候选码的部分或传递函数依赖。在关系student(sno,sname,mno,mname,mman)中

48、，非主属性mname对候选码sno传递函数依赖，因此，student3NF。关系student仍然存在上述异常问题，解决的办法就是将其分解，以进一步消除非主属性对候选码的传递函数依赖：lstudent(sno,sname,mno)lmajor(mno,mname,mman)可以证明，student3NF，major3NF，并且可以圆满地解决上述异常问题。2.3.4 规范化理论对于一般的数据库应用系统来说，设计出属于3NF的关系模式就够了，已经能够消除大多数情况下的数据冗余和各种异常问题，获得比较满意的结果，这就是人们常用的基于3NF的数据库设计方法。但是，2NF和3NF都没有涉及到主属性对候选

49、码的依赖关系，所以有时还会产生一些异常问题，解决这些异常问题就要进一步消除主属性对不包含它的候选码的部分或传递函数依赖，这就是BCNF（修正的3NF）。在函数依赖的范畴内，BCNF是规范程度最高的范式，能实现信息的彻底分离，从而彻底消除由函数依赖带来的异常问题。2.3.4 规范化理论有时人们还会讨论多值依赖和4NF以及连接依赖和5NF，函数依赖是多值依赖的特殊情况，多值依赖又是连接依赖的特殊情况，这里不再予以讨论。需要指出的是，规范化理论为数据库逻辑结构设计提供了理论的指南和工具，但也仅仅是指南和工具。并不是规范程度越高越好，规范程度越高，潜在的异常问题也就越少，但随之而来的连接代价也是相当大

50、的。因此，必须结合具体的应用环境和应用需求合理地选择数据库模式的范式级别。一般情况下，设计到3NF就够了。2.3.4 规范化理论前面我们用基于E-R图的数据库设计方法得到了学生信息管理系统的关系模型，我们同样可以用基于3NF的数据库设计方法通过不断的规范化（模式分解）过程来设计学生信息管理系统的关系模型，二者的结果是一样的。2.4 本章小结掌握关系模型的三要素掌握关系和关系模式的基本概念。掌握关系模型的三种完整性约束条件。学会用关系代数表达对数据的查询请求。掌握数据库设计的基本步骤掌握E-R图的设计方法及其向关系模型的转换原则。理解规范化理论在数据库逻辑结构设计中的作用学会如何判定一个关系模式