1：Redundancy(冗余)，可能带来的问题：冗余存储（redundant storage）,插入/删除/更新异常（insert/delete/update anomalies）
冗余来源于完整性约束（Integrity constraints）, 特别是函数依赖（functional dependencies）
2：函数依赖（functional dependency简写为FD）的定义：在一个关系模式R的所有关系实例中任取两个元组，如果他们的X属性的投影完全相同，则Y一定相同，则有X决定Y，或称Y依赖于X，用关系代数表示为：
for every allowable instance r of R:
例：Hourly_Emps (ssn, name, lot, rating, hrly_wages, hrs_worked)，以下简写为Hourly_Emps（SNLRWH），的一个函数依赖为：S--> SNLRWH 3：关于函数依赖的三个定理及两个推论：
Armstrong’s Axioms：
自反律: 如果Y X，则有X—>Y
增广律: 如果X→Y，则对于任意的Z有XZ→YZ
传递律: 如果X→Y and Y→Z,则X→Z
推论：
两个推论的证明：
（1）：Union：可以直接使用定义证明。设r是R的任意一个关系，s，t是r的任意两个元组，若s[X]=t[X]，由X→Y可得s[Y]=t[Y]，
由X→Z可得s[Z]=t[Z]，则有s[YZ]=t[YZ]，即当s[X]=t[X]时一定可以得到s[YZ]=t[YZ]，则根据函数依赖的定义可以有X→YZ。
（2）：Decomposition：
Y?YZ，由自反律得YZ→Y，又X→YZ，由传递律得X→Y
同理可证X→Z。
4：函数依赖集的闭包：
5：属性闭包的定义：
X的属性闭包记为+X，是一个属性集合，集合中的元素A要求
X→A 在函数依赖F的属性闭包中（求属性闭包要注意是在哪个函数依赖的基础上求的）。
6：计算属性闭包的算法：
为什么需要属性闭包：对于函数依赖闭包的求解是一个NP难度问题，经常不需要求一个函数依赖的属性闭包，而只需要判断一个函数依赖
是否属于函数的依赖闭包，如判断A→E是否属于F的依赖闭包，只需求出A的属性闭包，若F属于此属性闭包则可以判断A→E属于F 的依赖闭包，否则不属于。
7关键字的重新定义：
设有关系模式R(A1,A2,…,An)，F是它的函数依赖集,X是{A1,A2,…,An}的一个子集.如果:（两个条件都要满足）
1) X→A1A2…An 属于F的闭包，
2)不存在X的真子集Y使得Y→A1A2…An成立,且Y A1A2…An 属于F 的闭包.
则称X是R的一个候选关键字.
8：三种范式（normal forms 简写为NF）
（1）：如果一个关系模式R的每一个具体关系r的每个属性值都是不可再分的数据单位,则称R为第一范式,简称1NF，关系型数据库一定是1NF
（2）：BC范式（BCNF），对于所有的在F +中的函数依赖X→A有A∈X (平凡依赖)，或者
X包含R的一个关键字属性。
注：对于某一个确定的函数依赖，只要满足上面的一个条件即可。
（3）：3范式（3NF）对于所有的在F +中的函数依赖X→A有A∈X (平凡依赖)，或者
X包含R的一个关键字属性，或者
A是某个关键字属性的一部分。
对于某一个确定的函数依赖，只要满足上面的一个条件即可。
ＢＣ范式是没有任何冗余的范式，３范式允许冗余的存在，一个数据库是ＢＣ范式则一定是３ＮＦ。定义中是要求对F+中的所有函数依赖都进行判断；实际操作的时候只需对Ｆ中的函数依赖进行判断即可９：decomposition（分解）：要求：
（１）Each new relation scheme contains a subset of the attributes of R and no attributes that do not appear in R
（２）Every attribute of R appears as an attribute of one of the new relations.
简单来说，关系的分解就是要求分解后的关系与原来关系中所包含的属性一样的多，不能多属性也不能少属性。
１０：分解可能带来的问题：
（１）：分解的太彻底造成某些查询语句的复杂度太高，分解不彻底又存在冗余问题，所以第一个问题是需要由需求来定的（２）：分解需要具有无损连接性，即：
（３）：依赖保持性（如何判定在后面讲述）。
１１：判断分解的无损连接性：
（１）对于分解成两个关系的情况，假设分解成了（Ｘ和Ｙ）ａ：如果Ｘ∩Ｙ→Ｘ或者Ｘ∩Ｙ→Ｙ则，具有无损连接性。
ｂ：特别的，如果Ｕ→Ｖ对于Ｒ成立，则分解UV和R – V具有无损连接性。
ｃ：如果有R上的函数依赖X→Y成立,且X与Y的交集是空集,则分解R-Y和XY是无损连接分解
ｄ：设一个关系R无损连接分解为R1和R2,接着有将R1无损连接分解为R11和R12.这样将关系R分解为R11,R12和R2是无损连接的.
（２）对于分解成多个关系且不知道分解顺序的情况，判断算法：关系模式R(A1,A2,A3,…,An),它的函数依赖集F,以及分解
ρ={R1,R2,…,Rk} ，判断ρ是否具有无损连接性.
1)构造一个k行n列的表,第i行对应于关系模式Ri,第j列对应
于属性Aj,如果Aj属于Ri,则在第i行第j列上放符号ai,否则放
符合bij.
2)逐个地检查F中的每一个函数依赖,并修改表中的元素.其方
法为:取得F中一函数依赖X Y,在X的分量中寻找相同的行,然
后将这些行中的Y的分量改为相同的符号.如果其中有ai的则
将bij改为ai;若其中无ai,则改为bij.
3)这样反复进行,如果发现某一行变成a1,a2,…,an,则分
解具有无损连接性.
１２：依赖保持性，定义：
假如Ｒ被分解成了Ｘ和Ｙ，如果(F X union F Y ) + = F+，则此分解具有依赖保持性。
13:分解成BC范式，依据：如果X Y不满足BC范式的条件，则将R 分解成R – Y和XY，分解的结果肯定满足无损连接性，但是依赖保持性不能确保，以上步骤完成后可以以下方法检验依赖保持性：
例：
如果分解完后发现不满足依赖保持性，将丢失的函数依赖加进来再进一步分解。
13：最小函数依赖集，与原函数依赖集等价的最小的函数依赖集，课件上的定义为：
要求：（1）函数依赖的右边是单属性
（2）除掉各个依赖左边的多余属性
要判断在XY→A中Y是否为多余属性,只要在F求X的属性闭包,若A包涵在X的属性闭包中则Y为多余属性,否则不是
（3）删除依赖集中多余的依赖。从第一个依赖开始,从F中除掉它(假设该依赖为X→Y),然后在剩下的依赖中求X的闭包,如果Y包涵在闭包当中,则删除X→Y这个依赖,否则保留
14：根据最小依赖集进行三范式分解算法：
15：候选关键字求解：
（1）关系模式R(A1,A2,…,An)和函数依赖集F,可将R的属性分为四类
1)只出现在F的函数依赖左部的属性为L类
2)只出现在F的函数依赖右部的属性为R类
3)在F的函数依赖左右两边都未出现的属性为N类
4)在F的函数依赖左右两边都出现的属性为LR类
（2）如果一个函数依赖集F中的所有函数依赖左右两边都是单个属性,则该函数依赖集为单属性函数依赖集否则为多属性函数依赖集
因果函数依赖图G是一个有序二元组(R,F),记作G=(R,F),建成依赖图.其中:
1) R={A1,A2,..An}是一个有限空集,Ai(i=1,..,n)是G的结点,它们表示对应关系模式R(A1,A2,…,An)的属性,R表示其属性全集.
2)F是G的边集,其元素是G的一条有向线段(即边),每条边(Ai,Aj)表示
一个函数依赖Ai Aj,F是R的单属性最小依赖集.
图G是一个有向图,简称为FDG.
（3）：开路/回路:在一条路{Ai0,Ai1},…{Ail-1,Ail}中,若Ai0<>Ail,则称该路为开路否则为回路.
引入线/引出线:若结点Ai到Aj是连接的,则边(Ai,Aj)是Ai的引出线,同时也是Aj的引入线.
原始点:只有引出线无引入线的结点.它表示L类属性
终结点:只有引入线无引出线的结点.它表示R类属性
孤立结点:即没有引入线没有引出线的结点.
独立回路:不能被其他结点到达的回路为独立回路.
关键点/关键属性:原始点,孤立点称为关键点.关键点对应的属性称为关键属性.
（4）单属性依赖集候选关键字算法
1)求F的最小依赖集F’
2)作函数依赖图FDG
3)从图中找出关全部键属性集X(X可以为空)
4)查看G中有无独立回路,若无则X为R的唯一候选关键字,结束.否则转5)
5)从各独立回路中各取一结点对应的属性与X组成一候选关键字,并重复这一过程取尽所有可能组合,即为R的候选关键字.
（5）多属性依赖集候选关键字算法
1)求F的最小依赖集F’
2)将R的属性分为L,R,N,LR四类,并令X代表L,N两类,Y代表R类.
3)求X+.若X+包含了R的全部属性,则X为R的唯一候选关键字,结束.否则转4)
4)在Y中取一属性A,求(XA)+.若它包含R的全部属性,转5).否则,调换一属性反复进行这一过程,直到试完所有Y中的属性.
5)如果已经找出所有候选关键字,则结束.否则在Y中一次取两个,三个,….求它们的属性闭包,直到其闭包中包含R的全部属性.
数据库三大范式说明 数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（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的值由X决定的时候，我们就说Y函数依赖于X，这就类似于一个 线性方程：Y=X+1;类似的ERD图中，我们这样表示，很清楚的看 到表Category，中的主键是CategoryID，他决定着其他字段的值Name和Pic， 我们就说Name或者Pic 函数依赖于CategoryID，他们之间就是一个函数依赖关 系。 ●决定因素：如上例中，CategoryID就是一个决定因素，他决定其他字段的值，Y=X +1中，X就决定着Y的值，虽然加了一个常量。
什么是范式 简单的说，范式是为了消除重复数据减少冗余数据，从而让数据库内的数据更好的组织，让磁盘空间得到更有效利用的一种标准化标准，满足高等级的范式的先决条件是满足低等级范式。(比如满足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
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。 范式说明 1.1 第一范式（1NF）无重复的列 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 例如，如下的数据库表是符合第一范式的： 而这样的数据库表是不符合第一范式的： 数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 1.2 第二范式（2NF）属性完全依赖于主键[ 消除部分子函数依赖] 如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的某个候选键，则称为第二范式模式。 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。
范式分解 主属性：包含在任一候选关键字中的属性称主属性。 非主属性：不包含在主码中的属性称为非主属性。 函数依赖： 是指关系中一个或一组属性的值可以决定其它属性的值。函数依赖正象一个函数 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+∪“右边属性集”, 并为访问过的函数依赖设置标记。
Database Systems --Unt6. the Relational Theorem ?苏向阳
6. the Relational Theorem 知识点5 Normalization Based on FD
?A relational schema R is in first normal form(1NF)if the domains of all attributes of R are atomic. NO composite attributes, such as: customer( customer-id, name(first-name, middle-initial, last- name), date-of-birth ) Each attribute as an unit, even they have several part that have individual information. A tuple has only one value at each attribute.
?A schema R not in 1NF, then it’s NOT a relational schema. ?A relation R is in 1NF is not ‘good’ enough. For relation: Employee( emp_id, emp_name, emp_phone, dept_name, dept_phone, dept_mgrname, skill_id, skill_name, skill_date, skill_lvl) ?Is in 1NF ?Has Insert Anomaly, Delete Anomaly, Update Anomaly and Data Redundancy .
数据库规范化三个范式应用实例 5. 通俗地理解三个范式 通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)： 第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解； 第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性； 第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余. 没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。 规范化为什么重要？目前很多的数据库由于种种原因还没有被规范化。本文中解释了其中一些原因，并用不同形式的范式（normal form）规范化了一个保险公司的理赔表。在这个过程中表的改变以及添加的一些附加表使数据库效率更高、错误更少、更容易维护。 数据库的规范化是优化表的结构和把数据组织到表中的实践，这样做数据才能更明确。规范化使你能够改变业务规则、需求和数据而不需要重新构造整个系统。 通过改变存储数据的方式--仅仅改变一丁点--并改变访问这些信息的程序，你就可以消除很多错误或垃圾数据出现的机会并减轻更新信息所必要的工作量。 公司现实存在的一个问题可以用一句话概括"我们一般都这样做"。我们一般像采用那种方式存储信息；我们一般允许人们把任何信息写入
设计数据表： a）发现领域中的概念，理清领域中概念之间的关系，将其映射成表 b）尽量遵循数据库设计范式 1. 第一范式：有主键，具有原子性，列不可分割 2. 第二范式：完全依赖，没有部分依赖 3. 第三范式：没有传递依赖 c）主键设计最好采用单一主键，最好不要采用复合主键，尽量使用没有业务语段作为主键（如：Oracle的Sequence来维护一个主键），主键一般建议使用数值型，提高检索效率 d）最好假如外键约束（在开发阶段最好不要设置外键约束，运行阶段加上外键约束） e）关于冗余字段的问题，应该根据需求的具体情况是否加入 f）如果做通用性产品，最好不是使用数据库特性的功能，除非特殊情况。 g）如果数据量非常大，并且频繁的根据相关字段查询，最好建立索引。 范式标准： 基本表及字段之间的关系，应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到空间换时间的目的。 实例：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。 在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。 表1 商品表的表结构 商品名称商品型号单价数量金额 电视机29吋2,500 40 100,000 主键与外键： 当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。
1：Redundancy(冗余)，可能带来的问题：冗余存储（redundant storage）,插入/删除/更新异常（insert/delete/update anomalies） 冗余来源于完整性约束（Integrity constraints）, 特别是函数依赖（functional dependencies） 2：函数依赖（functional dependency简写为FD）的定义：在一个关系模式R的所有关系实例中任取两个元组，如果他们的X属性的投影完全相同，则Y一定相同，则有X决定Y，或称Y依赖于X，用关系代数表示为： for every allowable instance r of R: 例：Hourly_Emps (ssn, name, lot, rating, hrly_wages, hrs_worked)，以下简写为Hourly_Emps（SNLRWH），的一个函数依赖为：S--> SNLRWH 3：关于函数依赖的三个定理及两个推论： Armstrong’s Axioms： 自反律: 如果Y X，则有X—>Y 增广律: 如果X→Y，则对于任意的Z有XZ→YZ 传递律: 如果X→Y and Y→Z,则X→Z 推论： 两个推论的证明： （1）：Union：可以直接使用定义证明。设r是R的任意一个关系，s，t是r的任意两个元组，若s[X]=t[X]，由X→Y可得s[Y]=t[Y]，
由X→Z可得s[Z]=t[Z]，则有s[YZ]=t[YZ]，即当s[X]=t[X]时一定可以得到s[YZ]=t[YZ]，则根据函数依赖的定义可以有X→YZ。 （2）：Decomposition： Y?YZ，由自反律得YZ→Y，又X→YZ，由传递律得X→Y 同理可证X→Z。 4：函数依赖集的闭包： 5：属性闭包的定义： X的属性闭包记为+X，是一个属性集合，集合中的元素A要求 X→A 在函数依赖F的属性闭包中（求属性闭包要注意是在哪个函数依赖的基础上求的）。 6：计算属性闭包的算法： 为什么需要属性闭包：对于函数依赖闭包的求解是一个NP难度问题，经常不需要求一个函数依赖的属性闭包，而只需要判断一个函数依赖
数据库系统原理试题一（A卷） 一、选择题（每小题1分，共10分） 1．数据库系统与文件系统的主要区别是。 A. 数据库系统复杂，而文件系统简单； B. 文件系统不能解决数据冗余和数据独立性问题，而数据库系统可以解 决； C. 文件系统只能管理程序文件，而数据库系统可以管理各类文件； D. 文件系统管理的数据量较少，而数据库系统可以管理庞大的数据量。 2. 属于BCNF范式的关系模式。 A. 已消除插入和删除异常； B. 已消除插入、删除异常和数据冗余； C. 依然存在插入和删除异常； D. 在函数依赖的范畴内，已消除插入和删除异常。 3. 单个用户使用的数据视图的描述称为。 A. 外模式 B. 概念模式 C. 内模式 D. 存储模式 4. SQL语言中，删除记录的命令是。 A DELETE B DROP C CLEAR D REMORE 5. ODBC定义的API符合性级别共有级。 A.3 B．4 C．5 D．6 6. 数据库系统三级结构的描述放在中。 A．用户数据库 B．运行日志 C．数据库管理系统 D．数据字典 7. 弱实体的主键。 A．与其父实体的主键完全一致 B．一部份或全部从其父实体的主键获得 C．全部从其父实体的非主键属性获得 D．与其父实体无关 8. 在SQL的语句中，ALTER的作用是。 A．修改基本表的结构 B．修改基本表中的数据 C．删除基本表 D．修改视图 9. 在以下函数依赖中，是平凡的函数依赖。 A．A→ABCD B．ABCD→A C．A→BCD D．BCD→A 10. 在DB恢复时，对已经提交但更新未写入磁盘的事务执行。 A．REDO处理 B．UNDO处理 C．ABOUT处理 D．ROLLBACK处理 二、填空题（每空1分，共10分）
数据库三范式 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 中设计出不符合第一范式的数据库都是不可能的。 首先我们确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程、
1、请简述满足1NF、2NF和3NF的基本条件。并完成下题：某信息一览表如下， 第一范式的关系应满足的基本条件是元组中的每一个分量都必须是不可分割的数据项。 第二范式，指的是这种关系不仅满足第一范式，而且所有非主属性完全依赖于其主码。 第三范式，指的是这种关系不仅满足第二范式，而且它的任何一个非主属性都不传递依赖于任何主关键字。 考生情况（考生编号，姓名，性别，考生学校） 考场情况（考场号，考场地点） 考场分配（考生编号，考场号） 成绩（考生编号，考试成绩，学分） 2、某信息一览表如下，其是否满足3NF，若不满足请将其化为符合3NF的关系。 配件关系：（配件编号，配件名称，型号规格） 供应商关系（供应商名称，供应商地址） 配件库存关系（配件编号，供应商名称，单价，库存量） 3、简述满足1NF、2NF和3NF的基本条件。并完成下题：已知教学关系， 教学(学号，姓名，年龄，性别，系名，系主任，课程名，成绩)，试问该关系的主键是什么，属于第几范式，为什么？如果它不属于3NF，请把它规范到3NF。 4、请确定下列关系的关键字、范式等级；若不属于3NF，则将其化为3NF 。 例1.仓库（仓库号，面积，电话号码，零件号，零件名称，规格，库存数量）例1答案： 仓库号+零件号；1NF； 仓库（仓库号，面积，电话号码）
零件（零件号，零件名称，规格） 保存（仓库号，零件号，库存数量） 例2. 报名（学员编号，学员姓名，培训编号，培训名称，培训费，报名日期），每项培训有多个学员报名，每位学员可参加多项培训。 例2答案： 学员编号+培训编号；1NF； 学员（学员编号，学员姓名） 培训（培训编号，培训名称，培训费） 报名（学员编号，培训编号，报名日期） 5、请确定下列关系的关键字、范式等级；若不属于3NF，则将其化为3NF，要求每个关系写一条记录。 （部门编号，部门名称，所在城市，员工编号，员工姓名，项目编号，项目名称，预算，职务，加入项目的日期） [注]职务指某员工在某项目中的职务。 部门（部门编号，部门名称，所在城市） 员工（员工编号，员工姓名，部门编号） 项目（项目编号，项目名称，预算） 工作（员工编号，项目编号，职务，加入项目的日期）
数据库三大范式详解 设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。 目前关系数据库有六种范式：第一范式（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(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系： (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满足第二范式，因为存在如下决定关系： (课程名称) → (学分) (学号) → (姓名, 年龄) 即存在组合关键字中的字段决定非关键字的情况。 由于不符合2NF，这个选课关系表会存在如下问题： (1) 数据冗余： 同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。 (2) 更新异常： 若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。 (3) 插入异常：
第一章 P8 P13 第二章 P42 P46 1．名词解释： 超键：能惟一标识元组的属性或属性集，称为关系的超键。 候选键：不含有多余属性的超键，称为候选键。 实体完整性规则：实体的主键值不允许是空值。 参照完整性规则：依赖关系中的外键值或者为空值，或者是相应参照关系中某个主键值。 函数依赖：设有关系模式R(U)，X和Y是属性集U的子集，若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称X函数确定Y或Y函数依赖（Functional Dependency，简记为FD）于X，记作X→Y。 无损分解：当对关系模式R进行分解时，R的元组将分别在相应属性集进行投影而产生新的关系。如果对新的关系进行自然连接得到的元组集合与原关系完全一致，则称该分解为无损分解。 2NF：如果关系模式R属于1NF，且它的每一个非主属性都完全函数依赖于R的候选键，则称R属于第二范式，简记为R∈2NF。 3NF：如果关系模式R属于1NF，且每个非主属性都不传递依赖于R的候选键，那么称R属于第三范式，简记为R∈3NF。 2．为什么关系中的元组没有先后顺序，且不允许有重复元组？ 答：由于关系定义为元组的集合，而集合中的元素是没有顺序的，因此关系中的元组也就没有先后的顺序(对用户而言)。这样既能减少逻辑排序，又便于在关系数据库中引进集合论的理论。 3．笛卡尔积、等值连接和自然连接三者之间有什么区别？ 答：笛卡儿积是一个基本操作，而等值连接和自然连接是组合操作。 设关系R的元数为r，元组个数为m；关系S的元数为s。，元组个数为n。 那么，R×S的元数为r+s，元组个数为m×n； 的元数也是r+s，但元组个数小于等于m×n； 的元数小于等于r+s，元组个数也小于等于m×n：
第一范式（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），要求表中的每一列只与主键直接相关而不是间接相关，列与列之间无关联（表中的每一列只能依赖于主键）。 举例说明： 上表中，表中的非主属性都依赖于（学号），满足了第二范式。 但是，（班主任性别、年龄）这两个属性是直接依赖于（班主任姓名）这一属性的，与（学号）属于间接依赖。 这就导致了表中的非主属性存在着依赖关系，不符合第三范式。
第七章补充讲义一、式举例 例1：已知R，请问R为几式？ BCNF。（25改成15还是BCNF.如：课程号与学号） 例2：已知R，请问R为几式？ 2NF。有部分依赖。
例3：已知R，请问R为几式？ 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），所以，算法结束。 三、求最小依赖集 最小依赖集是对函数依赖集合进行规的结果，这样才能对一般关系模式进行准确分析。 例1．设函数依赖集F={AB→CE,A→C,GP→B,EP→A，CDE→P,HB→P,D→HG,ABC→PG},求与F等价的最小函数依赖集。 解：○1将F中依赖右部属性单一化：
一、选择题60(选择一个最合适的答案，在答题纸上涂黑) 1．一个事务中的一组更新操作是一个整体，要么全部执行，要么全部不执行。这是事务的：A.原子性B.一致性 C.隔离性 D.持久性 2．在数据库的三级模式结构中，描述一个数据库中全体数据的全局逻辑结构和特性的是：A．外模式B．内模式C．存储模式D．模式 3．关于联系的多重性，下面哪种说法不正确？ A.一个多对多的联系中允许多对一的情形。 B.一个多对多的联系中允许一对一的情形。 C.一个多对一的联系中允许一对一的情形。 D.一个多对一的联系中允许多对多的情形。 4．考虑学校里的"学生"和"课程"之间的联系，该联系的多重性应该是： A. 一对一 B. 多对一 C. 一对多 D. 多对多 5．下面哪种约束要求一组属性在同一实体集任意两个不同实体上的取值不同。 A. 键(key)约束。 B. 单值约束。 C. 参照完整性。 D. 域(domain)约束 6．关系模型要求各元组的每个分量的值必须是原子性的。对原子性，下面哪种解释不正确：A.每个属性都没有内部结构。 B.每个属性都不可再分解。 C.各属性值应属于某种基本数据类型。 D.属性值不允许为NULL。 7．对于一个关系的属性(列)集合和元组(行)集合，下面哪种说法不正确： A.改变属性的排列次序不影响该关系。 B.改变元组的排列次序不影响该关系。
C.改变元组的排列次序会改变该关系。 D.关系的模式包括其名称及其属性集合。 8．若R是实体集R1与R2间的一个多对多联系，将其转换为关系R'，哪种说法不正确： A.R'属性应包括R1与R2的所有属性。 B.R'属性应包括R1与R2的键属性。 C.R1与R2的键属性共同构成R'的键。 D.R'的属性应包括R自身定义的属性。 9．关于函数依赖的判断，下面哪种说法不正确？ A.若任意两元组在属性A上一致，在B上也一致，则有A →B成立。 B.若任意两元组在属性A上一致，在B上不一致，则A →B不成立。 C.若任意两元组在属性A上不可能一致，则不管在B上是否一致，有A →B成立。 D.若任意两元组在属性A上不可能一致，则A →B不成立。 10．若某关系R的属性集A函数决定R中所有其它属性，则A为关系R的一个： A.键。 B.主键。 C.超键。 D.外键。 11．当且仅当函数依赖A→BC，则有A→B和A→C。此规则是 A.分解/合并规则。 B.平凡依赖规则。 C.传递规则。 D.增长规则。 12．对于某关系R的某个属性集A，下面哪种说法不正确： A.若属性集A是R的键，则闭包A+是R中所有属性集合。 B.若闭包A+是R中所有属性集合，则属性集A是R的键。 C.若闭包A+是R中所有属性集合，则属性集A是R的超键。 D.当且仅当属性集A是R的超键，闭包A+是R中所有属性集合。 13．某关系R(A, B, C, D)有函数依赖A→B, BC→D, D→A，R总共有几个超键？ A.3 B.4 C.6 D.7 14．某关系R(A, B, C, D)有函数依赖A→B, BC→D, D→A，下面哪个函数依赖不蕴含于已知依赖？ A. D→B B. AC→BD C. BC→AD D. BD→AC 15．某关系R(A, B, C, D)有函数依赖A→B, BC→D, D→A，该关系若违背BCNF，则应分解成几个关系才能
第三范式具有如下性质： 1．如果R3NF，则R也是2NF。 证明：3NF的另一种等价描述是：对于关系模式R，不存在如下条件的函数依赖，X→Y （Y X），Y→Z，其中X是键属性，Y是任意属性组，Z是非主属性，Z Y。在此定义下，令Y X，Y是X的真子集，则以上条件X→Y，Y→Z就变成了非主属性对键X的部分函数依赖，X Z。但由于3NF中不存在这样的函数依赖，所以R中不可能存在非主属性对键X的部分函数依赖，R必定是2NF。 2．如果R2NF，则R不一定是3NF。 例如，我们前面由关系模式SCD分解而得到的SD和SC都为2NF，其中，SC3NF，但在SD中存在着非主属性MN对主键SNO传递依赖，SD3NF。对于SD，应该进一步进行分解，使其转换成3NF。 BCNF具有如下性质： 1．满足BCNF的关系将消除任何属性（主属性或非主属性）对键的部分函数依赖和传递函数依赖。也就是说，如果R BCNF，则R也是3NF。 证明：采用反证法。设R不是3NF。则必然存在如下条件的函数依赖，X→Y（Y X），Y→Z，其中X是键属性，Y是任意属性组，Z是非主属性，Z Y，这样Y→Z函数依赖的决定因素Y不包含候选键，这与BCNF范式的定义相矛盾，所以如果R BCNF，则R也是3NF。 2．如果R3NF，则R不一定是BCNF。 现举例说明。设关系模式SNC（SNO，SN，CN0，SCORE），其中SNO代表学号，SN代表学生姓名并假设没有重名，CNO代表课程号，SCORE代表成绩。可以判定，SNC 有两个候选键（SNO，CNO）和（SN，CNO），其函数依赖如下： SNO SN (SNO，CNO)→SCORE (SN，CNO)→SCORE 唯一的非主属性SCORE对键不存在部分函数依赖，也不存在传递函数依赖。所以SNC 3NF。 但是，因为SNO SN，即决定因素SNO或SN不包含候选键，从另一个角度说，存在着主属性对键的部分函数依赖：（SNO，CNO)SN，（SN，CNO）SNO，所以SNC不是BCNF。 正是存在着这种主属性对键的部分函数依赖关系，造成了关系SNC中存在着较大的数据冗余，学生姓名的存储次数等于该生所选的课程数。从而会引起修改异常。 比如，当要更改某个学生的姓名时，则必须搜索出现该姓名的每个学生记录，并对其姓名逐一修改，这样容易造成数据的不一致问题。 解决这一问题的办法仍然是通过投影分解进一步提高SNC的范式等级，将SNC规范到BCNF。