数据库原理及应用_第3篇数据库设计_第9章关系模型规范化设计理论_关系模式规范化

前言

        "<数据库原理及应用>(MySQL版)".以下称为"本书"中第9.4节内容

引入

        9.3节讲候选键,用前面的知识, 纯理论的东西就此略过

        本书P234:关系模式的好坏衡量标准:关系模式的范式.

关系模式的回顾

        其中,非主属性可由主属性推导得出,即:主属性→非主属性

        注意:候选键是由主属性组成,候选键之间的主属性可以交叉,如有三个主属性A,B,C,则(AB),(AC)都可以做候选键.

9.4.1范式及规范化

范式概念

        范式(Normal Form,NF)指关系模式的规范形式.

        关系模式的范式有6个,即1NF(第一范式,以下类同),2NF,3NF,BCNF,4NF和5NF

        范式之间是包含关系,高级范式是低级范式的特例.如2NF相对于1NF是高级别范式,以此类推.

规范化

        将一个给定的关系模式转换成某种范式的过程称为关系模式的规范化过程.

        规范化一般采用分解的办法,将低级别范式向高级别范式转换,使关系的语义单纯化.目的是消除异常

        理想的规范化程度是范式级别越高,规范化程度越高.但也不是越高越好.设计关系模式时,一般达到3NF或BCNF即可.

9.4.2完全函数依赖,部分函数依赖和传递函数依赖

        这部分是研究关系模式范式的基础,结合图来进行理解.示例图如下(AB是联合候选键):

主属性			非主属性
候选键1		候选键2	\	\
A	B	C	D	E

        示例图的函数依赖有:(A,B)→DE,C→DE(AB和C之间的没有函数依赖)

        定义9.4 设R是一个具有属性集合U的关系模式,X和Y是U的子集.

1.完全函数依赖

        如果X→Y,并且对于X的任何一个真子集Z,Z→Y都不成立,则称Y完全函数依赖于X

        ---对于完全函数依赖,示例图中不能有A→DE或者B→DE存在.

2.部分函数依赖

        如果X→Y,对于X的任何一个真子集Z,Z→Y都成立,则称Y部分函数依赖于X.

        ---对于部分函数依赖,示例图中有A→DE或者B→DE存在.

=============================内容分割线↓===================================

        对定理中的"任何一个",按字面意思是A→DE和B→DE两者同时存在,但实际上有一个真子集存在就可以了.

=============================内容分割线↑===================================

完全函数依赖和部分函数依赖举例

        例9-10给了函数依赖:1.(学号,课程号)→成绩,2.(学号,课程号)→系名

        分析:1是完全函数依赖,学号和课程号唯一,确定成绩.

                2是部分函数依赖,学号唯一,确定系名.课程号和系名无关.根据函数依赖的推导,2的写法不算错

3.传递函数依赖

        定义9.5 设R是一个具有属性集合U的关系模式,X,Y,Z是U的子集且是不同属性集,如果X→Y,Y→X不成立,Y→Z,则称Z传递函数依赖于X.记号略.

        ---对于传递函数依赖,示例图中表示: (A,B)→D,D→E.

直接函数依赖

        在传递函数依赖的概念中,提到了直接函数依赖:X→Y,Y→X同时成立.

        概念和离散数学中的"等价于"相似

        ---这种情况很容易解决,单独列一张表即可.举例:系名和系主任皆唯一的情况.

三种函数依赖的比较

        完全函数依赖是一种"理想"的表,没有数据冗余.部分函数依赖有部分数据冗余.注意,如本书前面所述,数据冗余并不是完全不可以.

9.4.3以函数为依赖的范式     

第一范式(1NF)         

        本书P235中间,定义9.6所在段落后的第二段:如果要将非第一范式的关系转换为1NF关系,只需将复合属性变为简单属性即可.

        ---前面帖子https://blog.csdn.net/jllws1/article/details/152211009?spm=1011.2124.3001.6209提到的将复合属性化成简单属性的两种方法,这里是第一种"摊开".不过帖子中提到第二种方法建立表也可以选择.因为第一范式是最基本的要求,所以没有多少可讲的内容.

第二范式(2NF)

        本书P236:定义9.7 如果关系模式R是1NF,而且R中所有的非主要属性都完全函数依赖于任意一个候选键,则称R是第二范式,记作2NF.

        2NF实质是不存在非主属性"部分函数依赖"于候选键的情况.消除表中的部分函数依赖.

        ---2NF的目的是消除表中的部分函数依赖,撇开晦涩的理论,书上的例子可以看.笔者用示例图和Armstrong公理推导如下:        

        1.示例图如果(A,B)→(C,D),同时存在A→C和B→D(部分函数依赖),则原表分解成两张表

        2.Armstrong公理推导

        现在有张表,函数依赖为AX→BY,同时存在A→B和X→Y.原表形式如下:

主属性		非主属性
主键		\	\
A	B	X	Y

        1)根据本书P230中的B2分解性:AX→BY推导出:AX→B和 AX→Y,

        2)根据A→B,可以删除AX→B,根据X→Y,可以删除 AX→Y(源自于例9-4和例9-5中的推导).所以函数依赖变成A→B和X→Y.

第三范式(3NF)

        本书P237:定义9.8 如果关系模式R是2NF,而且R中所有的非主要属性对任何候选键都不存在传递函数依赖,则称R是第三范式,记作3NF.

        2NF关系向3NF转换的原则是消除传递函数依赖.

        ---本书例9-14的例子是很典型的例子,背下来也可以.

            用法:当传递函数依赖:A→B,B→C,A→C同时存在,去掉A→C,留下A→B,B→C

            注意:细节,经过3NF分解,得到一个主表,被分解的表成为一个从表,可以和前面的知识联系.

BCNF范式

        本书P238定义9.9讲了BCNF范式,可以看看.

        ---3NF关系向BCNF转换的原则是消除主属性对候选键的部分和传递函数依赖.

            例9-15是个典型例子,理解了之后也就会用BCNF范式了,本书P238列出了例9-15函数依赖,这里用到了离散数学中的推导方法,如下表

函数依赖代号	Sid	Cid	Grade	Tname
自定义代号	A	B	C	D

        根据已知函数依赖,写出代号:

                (AB)→C,(AD)→C,D→B

        这样看得很清楚,根据D→B,前两项可以略去一项.本书略去了(AD)→C,留下了(AB)→C,因为符合平常的习惯:根据学号和课号就能查到课目的成绩.实际上用另一种方法也不会出错,不过这种更好.

        例9-16是个综合例子,分析了3NF的写法

多值依赖及第四范式(4NF)

        根据本书说明,数据库设计到3NF或BCNF基本上能满足需要了.从另一个角度来说,到了BCNF,关系模式不会有多长(属性个数不多),所以分解的工作量也不大.下面的内容从4NF到5NF有兴趣可以深入.

        笔者认为"硬凑"(一个一个去试)也可以.."严谨"是编程学习是一个基本要求,这样"玩"的机会属实不多

        BCNF→分解→4NF

小结

        根据E-R图设计关系模式,关系模式需要分析其函数依赖,并将关系模式规范化.本章内容的理论深,但用起来也不是太难.