数据库范式与关系模式示例

数据库范式1NF2NF3NFBCNF（实例）通俗易懂的讲解本⽂对⼤多数初学数据库原理的同学绝对是个⼤福利，哈哈，完完整整的看完此篇博⽂⼀定能够清晰地理解数据库的四⼤范式。

不懂者留⾔相互讨论。

设计范式（范式,数据库设计范式,数据库的设计范式）是符合某⼀种级别的关系模式的集合。

构造数据库必须遵循⼀定的规则。

在关系数据库中，这种规则就是范式。

关系数据库中的关系必须满⾜⼀定的要求，即满⾜不同的范式。

⽬前关系数据库有六种范式：第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。

满⾜最低要求的范式是第⼀范式（1NF）。

在第⼀范式的基础上进⼀步满⾜更多要求的称为第⼆范式（2NF），其余范式以次类推。

⼀般说来，数据库只需满⾜第三范式（3NF）就⾏了。

下⾯我们举例介绍第⼀范式（1NF）、第⼆范式（2NF）和第三范式（3NF）。

在创建⼀个数据库的过程中，范化是将其转化为⼀些表的过程，这种⽅法可以使从数据库得到的结果更加明确。

这样可能使数据库产⽣重复数据，从⽽导致创建多余的表。

范化是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项⽬这些初始⼯作之后的⼀个细化的过程。

下⾯是范化的⼀个例⼦ Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25如果上⾯这个表⽤于保存物品的价格，⽽你想要删除其中的⼀个顾客，这时你就必须同时删除⼀个价格。

范化就是要解决这个问题，你可以将这个表化为两个表，⼀个⽤于存储每个顾客和他所买物品的信息，另⼀个⽤于存储每件产品和其价格的信息，这样对其中⼀个表做添加或删除操作就不会影响另⼀个表。

关系数据库的⼏种设计范式介绍1 第⼀范式（1NF）在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。

• 3、关系模式R（U，F），其中U={A，B，C，D，E}， 、关系模式R ），其中U={A， E}， F={AC->E,E->D,A->B,B->D},请判断如下两个分解是否 F={AC->E,E->D,A->B,B->D},请判断如下两个分解是否 无损连接。 • （1）P={R1（AC），R2（ED），R3（AB）} P={R1（AC），R2（ED），R3（AB） • （2）P={R1（ABC），R2（ED），R3（ACE）} P={R1（ABC），R2（ED），R3（ACE）
• 其中每一个数据项是不可再分的，所以关系 其中每一个数据项是不可再分的， 模式First 1NF的 First是 模式First是1NF的。
• 1NF存在的问题（见表7-8） 1NF存在的问题 见表7 存在的问题（ • （1）冗余度大
• Sno,Sname,Status,City这些信息，要与其供应 Sno,Sname,Status,City这些信息， 这些信息 的零件种类一样多。 的零件种类一样多。 又如：多个学生选修同一门课程是经常出现的， .又如：多个学生选修同一门课程是经常出现的， 如果一个课程有n个学生选修，就意味着（ 如果一个课程有n个学生选修，就意味着（学生 姓名，课程名，教师姓名，老师地址）会出现n 姓名，课程名，教师姓名，老师地址）会出现n 次。
• 规范化——将低一级范式的关系转化为高 规范化——将低一级范式的关系转化为高 一级范式的关系的过程，称为规范化。 一级范式的关系的过程，称为规范化。
1、1NF（第一范式） 1NF（第一范式）
• 定义
• 若关系模式R的每一个分量是不可再分的数 若关系模式R 据项，则关系模式R属于第一范式（1NF）。 据项，则关系模式R属于第一范式（1NF）。

补充讲义一、范式举例BCNF.如：课程号与学号）例4：R(X,Y,Z),F={XY->Z},R为几范式？BCNF。

例5：R(X,Y,Z),F={Y->Z，XZ->Y},R为几范式？3NF。

R的候选码为{XZ,XY}，（R中所有属性都是主属性，无传递依赖）二、求闭包数据库设计人员在对实际应用问题调查中，得到的结论往往是零散的、不规范的（直观问题好办，复杂问题难办了），所以，这对分析数据模型，达到规范化设计要求，还有差距，为此，从规范数据依赖集合的角度入手，找到正确分析数据模型的方法，以确定关系模式的规范化程度。

例1．已知关系模式R(U、F)，其中，U={A,B,C,D,E}; F={AB→ C, B→ D, EC → B , AC→B} ,求（AB）+F.解：设X(0)=AB○1计算X(1),在F中找出左边为AB子集的FD,其结果是：AB→C,B→D∴X(1)=X(0)UB=ABUCD=ABCD 显然，X(1)≠X(0)○2计算X(2),在F中找出左边为ABCD子集的FD，其结果是：C→E,AC→B∴X(2)=X(1)UB=ABCDUBE=ABCDE 显然，X(2)=U所以，（AB）+ F=ABCDE.（等于U，所以AB是唯一候选关键字）例2．设有关系模式R(U、F)，其中U={A,B,C,D,E，I};F={A→D,AB→E,B→E,CD→I,E→C},计算（AE）+解：令X={AE},X(0)=AE○1在F中找出左边是AE子集的FD,其结果是：A→D,E→C∴X(1)=X(0)UB=X(0)UDC=ACDE 显然，X(1)≠X(0)○2在F中找出左边是ACDE子集的FD，其结果是：CD→I∴X(2)=X(1)UI=ACDEI显然，X(2)≠X(1)，但F中未用过的函数依赖的左边属性已含有X(2)的子集，所以不必再计算下去，即（AE）+=ACDEI.因为，X（3）＝X（2），所以，算法结束。

函数依赖关系是属性间的一种多对一的关系。 函数依赖关系是属性间的一种多对一的关系。 如果X →Y， X←Y， 是一对一关系。 如果X →Y，且X←Y，则X和Y是一对一关系。
如学号与身份证号。 如学号与身份证号。
7.2
函数依赖
SQL Server 2000
三、函数依赖的几种特例
1、平凡函数依赖与非平凡函数依赖 、 如果X→Y， 如果X→Y，且Y X→Y 若Y 由于Y 由于Y 称为非平凡函数依赖。 X，则X→Y 称为非平凡函数依赖。
7.1
关系模式的评价
SQL Server 2000
教学（学号，姓名，年龄，系名，系主任，课程名，成绩） 教学（学号，姓名，年龄，系名，系主任，课程名，成绩）
学号 98001 98001 98002 98002 98003 98003 99001 姓名 李华 李华 张平 张平 陈兵 陈兵 陆莉 年龄 21 21 22 22 21 21 23 系名 计算机 计算机 计算机 计算机 数学 数学 物理 系主任 王民 王民 王民 王民 赵敏 赵敏 王珊 课程名 C语言 高等数学 C语言 高等数学 高等数学 离散数学 普通物理 成绩 90 80 65 70 95 75 85
7.1
关系模式的评价
SQL Server 2000
对于有问题的关系模式， 对于有问题的关系模式，可以通过模式分解的方法使之 规范化， 规范化，上述关系模式如果分解为如下三个关系则可以克服 以上出现的问题。 以上出现的问题。 学生（学号，姓名，年龄，系名） 学生（学号，姓名，年龄，系名） 系（系名，系主任） 系名，系主任） 选课（学号，课程名，成绩） 选课（学号，课程名，成绩） 如何分解关系模式，分解的依据是什么？ 如何分解关系模式，分解的依据是什么？下二节将讨论 这些问题。 这些问题。

数据库范式分解例题及解析数据库范式是一种设计数据库表结构的理论，旨在减少数据冗余并确保数据的一致性和完整性。

数据库范式分解是指将一个不符合范式要求的关系模式分解成若干个符合范式要求的关系模式的过程。

下面我将以一个简单的例题来解析数据库范式分解的过程。

假设有一个学生信息管理系统，其中有一个包含学生姓名、年龄、性别和所在班级的关系模式（表）StuInfo。

现在我们来分解这个关系模式，使其符合第三范式（3NF）的要求。

首先，我们观察到StuInfo表中存在部分数据冗余。

比如，一个班级内可能有多个学生，如果将班级信息也包含在StuInfo表中，就会导致班级信息的重复。

因此，我们需要将班级信息从StuInfo表中分离出来，创建一个新的班级信息表ClassInfo，包含班级ID和班级名称两个字段。

接下来，我们需要考虑学生信息之间的函数依赖关系。

假设学生姓名和年龄之间存在函数依赖关系，即一个学生的姓名唯一确定其年龄，那么我们需要将这部分数据分离出来，创建一个新的学生信息表Student，包含学生ID、姓名和年龄三个字段。

最后，我们再来看性别字段。

由于性别是一个固定的取值范围（男或女），不会因为其他属性的变化而改变，因此性别并不依赖于其他属性。

所以，性别字段可以留在StuInfo表中，不需要再进行分解。

通过以上分解过程，我们将原来的StuInfo表分解为了三个符合3NF的表，Student表、ClassInfo表和经过部分分解的StuInfo 表。

这样的设计能够减少数据冗余，确保数据的一致性和完整性，提高数据库的性能和可维护性。

总的来说，数据库范式分解是一个重要的数据库设计过程，通过合理的分解可以使数据库表结构更加规范化，减少数据冗余，确保数据的一致性和完整性。

在实际应用中，需要根据具体的业务需求和数据特点来进行范式分解，以达到最佳的数据库设计效果。

3nf关系模式例子
假设我们有一个关于公司员工的数据库。

我们希望设计一个符合第三范式（3NF）的关系模式。

以下是一个例子：
员工（员工号，姓名，出生日期，性别，电话号码，邮件地址）部门（部门号，部门名称，部门经理）
岗位（岗位ID，岗位名称，薪水）
员工部门（员工号，部门号，开始日期，结束日期）
员工岗位（员工号，岗位ID，开始日期，结束日期）
通过上述关系模式，我们可以分解数据，将其存储在多个表中，以减少数据冗余和提高数据一致性。

每个表都有一个主键，确保数据的唯一性。

员工表包含有关员工的基本信息，部门表包含有关部门的信息，岗位表包含有关岗位的信息。

员工部门表和员工岗位表则用于表示员工与部门以及员工与岗位之间的关系，同时还包含了关联的时间信息。

这就是一个符合第三范式的关系模式的例子。

通过这种设计，我们可以更好地组织和管理数据，并确保数据的准确性和一致性。

关系模式的范式
1. 第⼀范式
第⼀范式是最基本的规范形式，即关系中每个属性都是不可再分的简单项。

定义如果关系模式R所有的属性均为简单属性，即每个属性都是不可再分的，则称R属于第⼀范式，简称1NF，记住R属于1NF。

把满⾜1NF的关系称为规范化。

在关系数据库系统中只讨论规范化的关系，凡是⾮规范化的关系模式必须转化成规范化的关系。

因此，1NF是关系模式应具备的最起码的条件。

在⾮规范化的关系中去掉组合项就能转化成规范化的关系。

⼀个关系模式仅仅属于第⼀范式是不适⽤的。

它可能具有⼤量的数据冗余，存在插⼊异常、删除异常和更新异常等弊端。

2. 第⼆范式
定义如果关系模式R属于1NF，且每个⾮主属性都完全函数依赖于R的主关系键，则R属于第⼆范式，简称2NF，记作R属于2NF。

两个结论：
（1）从1NF关系中消除⾮主属性对关系键的部分函数依赖，则可得到2NF关系；
（2）如果R的关系键为单属性，或R的全体属性均为主属性，则R属于2NF。

仍然存在着下⾯⼀些问题：
（1）数据冗余
（2）插⼊异常
（3）删除异常
（4）更新异常
3. 第三范式
定义如果关系模式R属于2NF，且每个⾮主属性都不传递函数依赖于R的主关系键，则称R属于第三范式，简称3NF，记作R属于3NF。

数据库三大范式举例理解
数据库三大范式是指在数据库设计中，通过规范化设计，确保数据库表结构的合理性
和一致性。

三大范式是从第一范式（1NF）开始逐步优化实现的，每一级范式的约束条件都是在前一级基础上建立的。

第一范式（1NF）：原子性
第一范式要求每一列都具有原子性，即每一列的数据都是不可拆分的最小单元。

如果
一列数据可以细分成更小的数据单元，就需要将其拆分成不同的列。

例如，一个订单表中
的“商品名称”列如果包含多个商品名字，就应该把它拆分成多个单独的“商品名称”列。

这样可以保证数据的精确性和可用性。

第二范式要求每个非主键列完全依赖于主键，而不是部分依赖于主键。

即，一个表中
的每个非主键列只与主键有关，而不受其他非主键列影响。

例如，一个订单表中，包含商
品ID、商品名称、商品价格、订单数量等信息。

这时候，商品名称和商品价格这两个属性只与商品ID有关，与订单数量无关，因此需要把它们拆分成另一张表，以确保表中的数据不重复，避免出现数据冗余和不一致的情况。

第三范式（3NF）：消除传递依赖
综上所述，数据库三大范式是数据库设计过程中的基本原则，依次达到三大范式可以
提高数据库表结构的合理性和一致性，使数据查询和管理更加方便和高效。

数据库范式例题范式是一种关系型数据库设计的规范，它是通过对表结构进行优化来消除冗余数据、提高数据存储和操作的效率的。

常见的数据库范式有1NF、2NF、3NF等。

以下是一个例题：假设我们有一个学生信息表，包含以下字段：- 学生编号（Student_ID）- 姓名（Name）- 性别（Gender）- 年龄（Age）- 班级编号（Class_ID）- 班级名称（Class_Name）- 班主任姓名（Teacher_Name）这个表中存在冗余数据，比如班级编号、班级名称和班主任姓名都与班级相关，而不是与学生本身相关。

因此，可以使用范式将这个表优化为更好的结构。

首先，我们可以使用第一范式（1NF）来消除重复的数据，把表分成两个表：学生表和班级表。

学生表包含以下字段：- 学生编号（Student_ID）- 姓名（Name）- 性别（Gender）- 年龄（Age）- 班级编号（Class_ID）班级表包含以下字段：- 班级编号（Class_ID）- 班级名称（Class_Name）- 班主任姓名（Teacher_Name）接下来，我们可以使用第二范式（2NF）来消除部分依赖，即确保每个非主键字段完全依赖于主键。

在学生表中，班级名称和班主任姓名都只与班级相关，因此我们可以把它们从学生表中移除，放到班级表中。

最后，我们使用第三范式（3NF）来消除传递依赖，即确保每个非主键字段都不依赖于其他非主键字段。

在班级表中，班主任姓名只与班级编号相关，而不是与班级名称相关，因此我们可以把班主任姓名从班级表中移到另一个表中。

最终，我们将这个结构优化为三个表：学生表包含以下字段：- 学生编号（Student_ID）- 姓名（Name）- 性别（Gender）- 年龄（Age）- 班级编号（Class_ID）班级表包含以下字段：- 班级编号（Class_ID）- 班级名称（Class_Name）教师表包含以下字段：- 班级编号（Class_ID）- 班主任姓名（Teacher_Name）通过以上的优化，我们消除了冗余数据、提高了存储和操作的效率，并且让数据库结构更加清晰和规范。

定义:在关系模型中的每一个具体关系R中， 如果每个属性 都是不可再分的，则称R属于 第一范式（1NF），记作R∈1NF。
第一范式（1NF）：数据库表中的字段 都是单一属性的，不可再分。
字段1
字段2
字段3
字段4
第一范式(1NF)
• 例如，如下的数据库表是符合第一范式的：
字段1 字段第2 一范式字(段13NF) 字段4
第二范式举例
• 假定选课关系表为SelectCourse(学号, 姓名, 年 龄, 课程名称, 成绩, 学分)，关键字为组合关键字( 学号, 课程名称)，因为存在如下决定关系： (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
这个数据库表不满足第二范式，因为存在如下决 定关系：
(课程名称) → (学分) (学号) → (姓名, 年龄)
关系模式规范化的作用
•
关系数据库的设计主要是关
系模式设计。关系模式设计的好
坏直接影响到数据库设计的成败
。将关系模式规范化，是设计较
好的关系模式的惟一途径。
•
关系模式的规范化主要是
由关系范式来完成的。
关系范式
所谓范式（Normal Form,NF）是指规 范化的关系模式。由规范化程度不同，就产 生了不同的范式。根据满足条件的不同，经 常称某一关系模式Ｒ为“第几范式”。
• 原则：遵从概念单一化 “一事一地”原则，即一个关系 模式描述一个实体或实体间的一种联系。
• 方法：将关系模式投影分解成两个或两个以上的关系模式 。
• 要求：分解后的关系模式集合应当与原关系模式“等价” ，即经过自然联接可以恢复原关系而不丢失信息，并保持 属性间合理的联系。
关键字段 → 非关键字段x → 非关键字段y

范式分解主属性：包含在任一候选关键字中的属性称主属性。

非主属性：不包含在主码中的属性称为非主属性。

函数依赖：是指关系中一个或一组属性的值可以决定其它属性的值.函数依赖正象一个函数 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+不改变为止。

数据库四⼤范式⼀、概念在创建⼀个数据库的过程中，必须依照⼀定的准则，这些准则被称为范式，从第⼀到第六共六个范式。

⼆、背景数据库的规范化（上⼀篇博客有写到）的程度不同，便有了这么多种范式。

数据库范式是数据库设计必不可少的知识，没有对范式的理解，就⽆法设计出⾼效率、优雅的数据库，甚⾄设计出错误误的数据库。

三、⽬标⼀般数据库设计只要遵循第⼀范式，第⼆范式，和第三范式就⾜够了，满⾜这些规范的数据库是简洁的、结构明晰的，同时，不会发⽣插⼊（insert）、删除（delete）和更新（update）操作异常。

使⽤正确的数据结构，不仅有助于对数据库进⾏相应的存取操作，还可以极⼤地简化应⽤程序中的其他内容(查询、窗体、报表、代码等)，按照“数据库规范化”对表进⾏设计，其⽬的就是减少数据库中的数据冗余，以增加数据的⼀致性。

四、概念1、候选键：唯⼀识别该表的属性或属性组。

⽽其任何、⼦集都不能再标识，则称该属性组为（超级码）候选码。

例如：在学⽣实体中，“学号”是能唯⼀的区分学⽣实体的，同时⼜假设“姓名”、“班级”的属性组合⾜以区分学⽣实体，那么{学号}和{姓名，班级}都是（超级码）候选码。

2、所谓依赖，就是函数依赖，就是映射。

可以⼀对⼀，可以⼀对多，可以多对多。

五、六⼤范式第⼀范式（1NF）：属性不可拆分或⽆重复的列⼀个属性不允许再分成多个属性来建⽴列。

事实上，在⽬前的DBMS中是不可能拆分属性的，因为他们不允许这么做。

如果出现重复的属性，就可能需要定义⼀个新的实体，新的实体由重复的属性构成，新实体与原实体之间为⼀对多关系。

第⼀范式的模式要求属性值不可再分裂成更⼩部分，即属性项不能是属性组合或是由⼀组属性构成。

简⽽⾔之，第⼀范式就是⽆重复的列。

例如，由“职⼯号”“姓名”“电话号码”组成的表(⼀个⼈可能有⼀部办公电话和⼀部移动电话)，这时将其规范化为1NF可以将电话号码分为“办公电话”和“移动电话”两个属性，即职⼯(职⼯号，姓名，办公电话，移动电话)。

数据库范式例题1. 介绍数据库范式是一种规范，用于设计和组织关系型数据库中的表结构。

它定义了关系型数据库中各个属性之间的关系和依赖。

范式分为一至五个等级，每个等级都有其独特的规则和要求。

范式的目标是最大程度地减少冗余和数据插入、更新和删除的异常。

在本文中，我们将通过一个例题来说明数据库范式的概念、规则和应用。

我们将讨论如何将一个未经范式化的数据库转化为符合第三范式的数据库。

2. 范例数据库设计假设我们有一个关系型数据库，用于存储学生和课程的相关信息。

该数据库包含以下表格：Students（学生）学生编号姓名课程编号课程成绩1 张三 1 851 张三2 902 李四 2 953 王五 1 80Courses（课程）课程编号课程名称1 数学2 英语3 物理3. 第一范式（1NF）根据第一范式的要求，每个属性的值都应该是原子性的，不可再分的。

在我们的范例数据库中，符合第一范式的要求，因为每个表格中的每个属性都是原子性的。

4. 第二范式（2NF）根据第二范式的要求，非键属性必须完全依赖于键属性。

在我们的范例数据库中，如果我们将学生表拆分成学生表和学生成绩表，可以更好地满足第二范式的要求。

学生表学生编号姓名1 张三2 李四3 王五学生成绩表学生编号课程编号课程成绩1 1 851 2 902 2 953 1 805. 第三范式（3NF）根据第三范式的要求，非键属性不应该存在传递依赖关系。

在我们的范例数据库中，学生表和学生成绩表已经符合第三范式的要求，因为它们没有属性之间的传递依赖关系。

6. 总结通过以上示范，我们了解了数据库范式的概念和应用。

范式化的数据库设计可以提高数据的一致性、完整性和可维护性。

在实际应用中，根据数据的特点和需求，我们可以选择适当的范式等级来设计和优化数据库结构。

范式化并不是唯一的选择，有时候为了提高数据库的查询性能，我们需要进行冗余设计，但也需要权衡冗余带来的数据更新复杂度。

在设计数据库时，我们需要根据实际情况综合考虑各种因素，以达到最佳的数据库设计方案。

关系模式举例关系模式是关系数据库中的基本概念之一，用于描述实体之间的关系。

以下是符合标题内容的十个关系模式示例：1. 学生-课程-教师这个关系模式描述了学生、课程和教师之间的关系。

一个学生可以选修多门课程，每门课程都由一个教师教授。

一个教师可以教授多门课程，每门课程都可以被多个学生选修。

2. 订单-商品-供应商这个关系模式描述了订单、商品和供应商之间的关系。

一个订单可以包含多个商品，每个商品都由一个供应商提供。

一个供应商可以提供多个商品，每个商品可以被包含在多个订单中。

3. 医生-病人-疾病这个关系模式描述了医生、病人和疾病之间的关系。

一个医生可以治疗多个病人，每个病人可能患有多种疾病。

一个疾病可以被多个病人患有，每个病人可以被多个医生治疗。

4. 作者-文章-期刊这个关系模式描述了作者、文章和期刊之间的关系。

一个作者可以发表多篇文章，每篇文章可能发表在不同的期刊上。

一个期刊可以发表多篇文章，每篇文章只能由一个作者发表。

5. 员工-部门-经理这个关系模式描述了员工、部门和经理之间的关系。

一个员工可以属于一个部门，每个部门由一个经理管理。

一个经理可以管理多个部门，每个部门可以有多个员工。

6. 客户-订单-销售员这个关系模式描述了客户、订单和销售员之间的关系。

一个客户可以下多个订单，每个订单由一个销售员负责处理。

一个销售员可以处理多个订单，每个订单只能由一个客户下。

7. 角色-权限-用户这个关系模式描述了角色、权限和用户之间的关系。

一个角色可以拥有多个权限，每个权限可以被赋予多个用户。

一个用户可以拥有多个角色，每个角色可以拥有多个权限。

8. 车辆-驾驶员-路线这个关系模式描述了车辆、驾驶员和路线之间的关系。

一个车辆可以由多个驾驶员驾驶，每个驾驶员可以行驶多条路线。

一条路线可以被多个驾驶员行驶，每个驾驶员只能驾驶一个车辆。

9. 商品-库存-仓库这个关系模式描述了商品、库存和仓库之间的关系。

一个商品可以存放在多个库存中，每个库存对应一个仓库。

• ACD
• 因为 AC→B • 所以 AC→ACB • 所以 ACD→ABCD • 所以R的候选码是ACD
• 设有关系模式R（U,F），其中 U={A,B,C,D,E,I} F={A->D,AB->E,BI>E,CD->I,E->C}
• 计算(AE)的闭包
• 设有关系模式R（U,F），其中 U={A,B,C,D,E,I} F={A->D,AB->E,BI>E,CD->I,E->C}
• 计算(AE)的闭包
• 在F中找出左边是AEDC子集的函数依赖， 其结果是CD->I，所以X(2)=ACDEI，但F中 未用过的函数依赖的左边属性已没有X(2)的 子集，即(AE)的闭包=ACDEI
• 设有关系模式R（A,B,C,D,E,F）其函数依 赖集为F＝｛E→D,C→B,CE→F,B→A,求候 选码
• 设有关系模式R（A,B,C,D,E,F）其函数依 赖集为F＝｛E→D,C→B,CE→F,B→A,求候 选码
• L: C,E
• R:A,D,F
• LR:B • N:无
• 设有关系模式R（A,B,C,D,E,F）其函数依 赖集为F＝｛E→D,C→B,CE→F,B→A,求候 选码
候选键，且为唯一候选键。 • 对于LR类，求出其闭包，若包含所有属性，则为候选键，
若不包含，在找出其中一个属性结合。 • 对于N类，直接加至候选键即可。
• 其中U＝{W,X,Y,Z},F={WX→Y,W→X, X→Z,Y→W} • L:无
• R:Z • LR:w，x，y • N:无 • 先排除z • 在LR中，w的闭包为{w，y，z，x} • x的闭包为{x，z} • y的闭包为{y，w} • wx的闭包为{w，x，y，z} • wy的闭包为{w，y} • xy的闭包为{x，y，z，w} • wxy的闭包为{x，z，y，w} • 由此可见，候选键为{w，wx，xy，xyw} • 可从候选键中选取一个作为主键。

数据库BC范式举例假如有关系模式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,BCH-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->CABC->D,ABD->C其中:AB->C,AB->D,ABC->D,ABD->C而:B->C,B->D,BC->D,BD->C是 BCNF违例步骤四:进行 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)AB是键码，所以A,B是主属性，而C,D都是键码以外的属性，所以C,D都是非主属性。

4
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
在这个数据库表中，有某些依赖不满足第二范式的 要求，分析以下关系哪些符合第二范式哪些不符合：
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"学分"值都要 更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。这样，由于 还没有"学号"关键字，课程名称和学分也无法记录入数据库。
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从 数据库表中删除。但是，与此同时，课程名称和学分信息也被删 除了。很显然，这也会导致插入异常。
(课程名称) → (学分) (学号) → (姓名, 年龄) (学号, 课程名称) → (成绩)
解决办法：将部分依赖的属性和这个被部分依赖的主属 性从原表中分离，形成一个新表。
5
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个 学生选修了m门课程，姓名和年龄就重复了m-1次。
7
为下表找出关键字组，并分析它是否符 合第二范式：
课程号 教师号 课程名 教师名 所在教室 上课时间
8
第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式 （2NF）。
第三范式（3NF）要求一个数据库表中不包含 已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有 部门编号（dept_id）、部门名称、部门简介 等信息。那么在员工信息表中列出部门编号后