数据库原理及应用_第3篇数据库设计_第9章关系模型规范化设计理论_关系模式异常分析&函数依赖

前言

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

引入

        这章内容是用符号将关系模型(表)形式化,揭示他的底层逻辑.

        能把概念符号化,并建立起对应逻辑的,都是大师级人物.如图:

        本章是本书中最抽象的内容,对抽象内容的学习,开始时最好能具象化

        好在有前面的一些基础,在对概念理解的同时和关系(表)互相印证.

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

        本章内容有点特别,理论艰深枯燥难以理解,结合实际又不是那么难."边学边猜"来掌握

        也就是说,本章内容特点是"理论难学,应用容易"

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

9.1关系模式中可能存在的异常

9.1.1存在异常的关系模式示例

        本书P225给出了一个存在异常的关系模式,本章后面的内容也围绕其展开

                Students(Sid,Sname,Dname,Ddirector,Cid,Cname,Cscore)

        对应的中文含义

                Students(学号,姓名,系名,系主任,课程号,课程名,成绩)

        ---乍一看这个表关系比较混乱,正因为如此,用他来学习规范化设计理论

            表有三项语义:

                一个系有多个学生,每个学生只属于一个系

                一个系有一名系主任,一名系主任只在一个系任教

                一名学生可选修多门课,每门课程有多名学生选修

9.1.2可能存在的异常

        四种异常:数据冗余,插入异常,删除异常,更新异常

9.1.3关系模式中存在异常的原因

        本书P226倒数第二段:数据语义在关系模式中的具体表现是,在关系模式中的属性间存在一定的依赖关系,即数据依赖.这里给出了数据依赖的概念---关系模式(表)中的属性间存在的关系.本书P226倒数第一段:数据依赖是现实系统中实体属性间相互联系的抽象,是数据语义的体现.和上述黑体字含义差不多,指出数据依赖和数据语义的关系:语义=属性间的数据依赖.

        本书P227第三段:异常现象就是由于关系模式中存在的这些复杂的数据依赖关系所导致的.第四段:解决异常的方法是利用关系数据库规范化理论对关系模式进行相应的分解,使得每一个关系模式表达的概念单一,属性间的数据依赖关系单纯化,从而消除这些异常.

        ---从字面意思理解,属性是表达语义的,他们之间必然存在数据依赖.但复杂的数据依赖将产生异常.解决方法:分解使得关系模式(表)中的数据依赖关系单纯化.

9.2函数依赖

9.2.1函数依赖的定义

        本书P227用函数y=f(x)来解释函数依赖,很遗憾是错误的,他把因果关系弄反了.原话:y=f(x),即给定一个x值,y就确定了唯一的一个值.正确的说法:唯一的值x决定另外一个值y(值可以是集合).此时x是决定因素,y依赖于x.

        这里用一个简单的例子来说明:学号Sid和课号Cid决定某同学的成绩,形式化为(Sid,Cid)→Cscore.如下表所示(忽略表结构的不合理,新增的两列是为了看清晰),唯一确定的是学号和课程号,学生分数可以是相同的.

		成绩表
Sid	学生名	Cid	课程名	Cscore
111	张三	123	中国文学史	95
112	李四	124	外国文学史	95

函数依赖的形式化

        上面的函数依赖表达为x→y.这里的箭头"→"可以理解成"推导出",同时他和离散数学中的蕴涵式意思基本相同.如前所述,x是决定因素,y依赖于x.定义9.1表达了这个观点.

函数依赖的说明

        本书P227最后两段和P228第二段提出了两个注意的地方

        1>函数依赖是语义范畴概念,只能根据语义来确定函数依赖.

        ---语义→函数依赖.语义是前提,以语义为前提判定函数依赖.举了个例子:姓名→年龄.这个函数依赖在"姓名唯一"的情况下存在.而"姓名唯一"怎么确定呢?当插入元组时,禁止相同姓名插入.

        3>函数依赖关心的问题是一个或一组属性的值决定其他属性的值.

        ---这句话说的是研究函数依赖的目的.对应前面的知识,简单理解为函数依赖用来确定表的主键

9.2.2发现函数依赖

        发现函数依赖换个说法就是:找主键(候选键),本书列举了两种方法::根据完整的样本数据发现函数依赖:和"根据数据语义发现函数依赖".推荐第一种方式.试想自己设计一个表,根据属性之间的关系找出主键并不是太难,抓住核心:x是唯一确定.

示例说明

        本书P229例9-1,关系模式中的依赖有A→B,A→C,A→BC.

        本书P229例9-2,解答中前4个FD是根据语义推导出的.第5和第6个依赖实际上是另外加的.

9.2.3最小函数依赖集

        数据库设计的实现是基于无冗余的函数依赖集的,即最小函数依赖集.

        ---函数依赖表达属性间的决定关系,无冗余的函数依赖(最小函数依赖集)是每张表的目标

Armstrong公理和推论

        结合后面的例子,(3),(4),(5)是需要掌握的.即传递性,合并性和分解性

最小依赖集的求解步骤

综合例9-4和例9-5,得到以下求解步骤

        1>用分解性将函数依赖的右边拆成单属性

        2>去掉冗余的函数依赖.有三种情况

                1.相同的去掉,如有两个A→B,留下一个

                2.去掉传递依赖,例如A→B,B→C,A→C.将A→C去掉,留下A→B,B→C

                3.类似AB→C和B→C同时存在,去掉AB→C,留B→C.

                        解释:当B唯一存在确定C,则必然有AB唯一确定C,所以可去掉.

        3>用结合性将属性合并

                例如A→B,A→C同时存在,则用A→BC合并他们(此时没有B→C存在,否则传递依赖)

例9-3的求解

        函数依赖集F={Z→A,B→X,AX→Y,ZB→Y}

        1.结合性:Z→A,B→X,则ZB→AX,所以F={ZB→AX,AX→Y,ZB→Y}

        2.去冗余:F={ZB→AX,AX→Y}

本书没有讲如何把最小函数依赖集化成表,但也容易想到例9-3将化成2个表.

注意:最小函数依赖集的求解用在表设计之前.根据求得的最小依赖函数集,一个依赖一张表.

小结

        关系模式中的异常分析,以及函数依赖的分析