关系数据理论（回顾关系模式、数据依赖、不规范的关系模式存在的问题、函数依赖、非平凡函数依赖/平凡函数依赖、完全函数依赖/部分函数依赖定义、传递函数依赖，码）

本文链接：https://blog.csdn.net/m0_56501550/article/details/124653933

关系数据库的规范化理论是数据库逻辑设计的一个有力工具。

1、回顾关系模式

第2章中已经讲过，一个关系模式应当是一个五元组:

R(U，D，DOM，F)

(1)R 关系名

(2)U 一组属性(属性的集合)

(3)D 属性组U中属性所来自的域（每个属性都来自一个域，这些域的集合就是D）

(4)DOM 属性到域的映射

(5)F 属性组U上的一组数据依赖
由于(3)、(4)对模式设计关系不大，因此本章中把关系模式看作是一个三元组: R(U，F)

当且仅当U上的一个关系r满足F时，r 称为关系模式 R(U，F) 的一个关系。

作为关系，一个基本要求:

每一个分量(属性)必须是不可分的数据项。满足了这个条件的关系模式属于第一范式(1NF 必须大写)。即：第一范式：每个属性必须是不可分的数据项

2、数据依赖

数据依赖是一个关系内部属性与属性之间的一种约束关系。

它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。

人们已经提出了多种类型的数据依赖，其中最重要的是函数依赖（此处只讨论函数依赖）和多值依赖（涉及到第四范式）。

函数依赖普遍存在于现实生活中。

比如描述一个学生的关系，可以有学号，姓名，所在系等属性。一个学号对应一个学生，一个学生只在一个系学习。因而当学号值确定之后，学生的姓名及所在系的值也就被唯一确定。

属性间的这种依赖关系类似于数学中的函数 y=f(x) ，自变量 x 确定之后，相应的函数值 y 也就唯一的确定了，即 sname=f(sno) , sdept=f(sno) ，即sno函数决定sname，sno函数决定sdept，或者说， sname和sdept函数依赖于sno（倒着说），记作:

sno->sname，sno->sdept
/*读作 sno函数决定于sname，反过来说sname 函数依赖于sno */

3、不规范的关系模式存在的问题

例:

有一个关系(不规范)，涉及学生的学号sno，姓名sname，所在系sdept，系主任姓名，课程号cno和成绩grade。

该关系模式的属性集合:U={sno，sdept，mname，cno，grade对该问题的现实世界的语义:
一个系有若干学生，一个学生只属于一个系;

一个系只有一名主任;
一个学生可以选修多门课程，每门课程有若干学生选修;

每个学生所学的每门课程都有一个成绩

        于是得到属性U上的一组函数依赖F
        F={sno->sdept，sdept->mname，(sro，cno)->grade}
        该关系模式student<U，F>下的一个数据表如教材pl79所示。

但这个关系模式存在以下问题:

1)数据冗余太大

每一个系的系主任姓名重复出现，重复次数与该系所有学生的所有课程成绩出现次数相同。浪费大量的存储空间。
2)更新异常

由于数据冗余，当更新数据时，维护数据完整性代价大。

例如，某系更换系主任后，系统必须修改与该系学生有关的每一个元组。

3)插入异常

如果一个系刚成立，尚无学生，就无法把这个系及其系主任的信息存入数据库。

4)删除异常

如果某个系的学生全部毕业了，在删除该系学生信息的同时，把这个系及其系主任的信息也丢掉。

由于上述问题，Student关系模式不是一个好的模式。

一个好的关系模式应当不会发生插入异常、删除异常、更新异常，数据冗余应尽可能少。

究其原因，是这个模式中的函数依赖存在某些不好的性质。

        假如把这个单一的模式改造一下(分解一下):
        S(Sno，Sdept，Sno→Sdept);（学号函数决定所在系）
        sc(Sno，Cno，Grade，(Sno，Cno)→Grade);（学号和课程号联合函数决定成绩）
        dept(Sdept，Mname，Sdept→Mname)（系函数确定系主任）

这三个关系模式都不会发生插入异常、删除异常、更新异常的问题，数据冗余也得到控制。

规范化理论正是用来改造关系模式，通过分解关系模式来消除

规范化

研究内容:

研究关系属性间不同的依赖情况（通过函数依赖）:

研究如何根据属性依赖（函数依赖）情况来判定关系是否具有某些不合适的性质;

研究如何将具有不合适性质的关系转换为合适的形式;

研究按属性间依赖情况来区分关系规范化的程度的第一范式、第二范式、第三范式、BCNF、第四范式。

4、函数依赖（需要掌握）

定义:

设R(U)是属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称“X函数确定Y”或“Y函数依赖于X”，记作X→Y。

        说明:
        函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件。
        函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。

例如“姓名一年龄”这个函数依赖只有在不允许有同名人的条件下成立。
数据库设计者可以对现实世界作强制的规定。例如规定不允许同名人出现，函数依赖“姓名→年龄”成立。所插入的元组必须满足规定的函数依赖，若发现有同名人存在，则拒绝装入该元组。

例:

对于关系模式Student(SnoSnameSsexSageSdept)，假设不允许重名，则有:

        Sno→Sname
        Sno → Ssex

        Sno→Sage

        Sno→Sdept

        Sname→Sno

        Sname→ Ssex

        Sname→Sage         

        Sname→Sdept

一些术语和记号:

(1)非平凡函数依赖/平凡函数依赖（1NF（第一范式）基础）

        →如果X→Y，但Y不是X的子集，则称 X→Y 是非平凡的函数依赖，
                例，在关系模式sc(Sno，Cno，Grade)中(Sno，Cno)→Grade非平凡函数依赖
        →若X→Y，但Y是X的子集，则称X→Y是平凡的函数依赖。
                例，在关模式sC(Sno，Cno，Grade)中(Sno，Cno)→Sno平凡函数依赖
        对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义。

这里讨论非平凡的函数依赖。
若X→Y，则X称为这个函数依赖的决定属性组，或决定因素。

若X→Y，并且Y→X，则记为X<->X。

若Y不函数依赖于X，则记为X!→Y(应该再箭头上打一个斜号)。

(2)完全函数依赖/部分函数依赖定义（2NF（第二范式）基础）

在关系模式R(U)中，如果X→Y，并且对于X的任何一个真子集X’，都有Y不函数依赖于X’，则称Y完全函数依赖于X，记作X→Z（箭头上加一个F）。

结论：单个属性的决定因素一定是完全函数依赖，原因就是一个元素没有真子集，真子集不包含空集和自身

若X→Y，但Y不完全函数依赖于X，则称Y部分函数依赖于X，记作x→y(箭头上加个p)。

例:在关系模式student(sno，sdept，mname，cno，grade)中，

(Sno，Cno)->(箭头上加F)Grade是完全函数依赖;

原因：Sno的子集有：sno 、cno 而Grade不能函数依赖于sno 也不能函数依赖于cno

(Sno，Cno)→Sdept是部分函数依赖（箭头上加上p）。

原因：Sno的子集有：sno 、cno 而 Sdept是函数依赖于sno的，所以依赖于X(Sno,Cno)的真子集。所以是部分函数依赖。

(3)传递函数依赖（3NF（第三范式）的基础）

在关系模式R(U)中，如果X→Y(Y不是X的子集)，Y→Z，且Y不函数确定X，Y函数依赖Z，Z不是Y的真子集，则称Z传递函数依赖于X，记为:X->Z(箭头上加“传递”)。

例:

在关系模式student(sno，sdept，mname，cno，grade)中，

Sno→Sdept，Sdept→Mname，则Mname传递函数依赖于Sno

加上条件“Y不函数确定X”，是因为如果Y→X，则X←→Y，实际上是Z直接函数依赖X，而不是传递函数依赖。

码

        这里用函数依赖的概念来定义码：
        设K为关系模式R<U，F>中的属性或属性组合。若U完全函数依赖K，则K称为R的一个侯选码(CandidateKev)。若关系模式R有多个候选码，则选定其中的一个作为主码(Primarykey)。
        主属性和非主属性。包含在任何一个候选码中的属性，称为主属性，不包含在任何码中的属性称为非主属性或非码属性。