20.6.21补数据库原理笔记

摘要:
正如我前面提到的,2NF和3N似乎越来越好。只有优点,没有缺点。那么,3NF-˃BCNF是否也只有优点而没有缺点?15现在在另一个人的数据库中有五本参考书,因此我们需要替换五行内容。由此我们可以看出,多值依赖也会导致数据冗余和数据操作复杂性。我们能改善这个问题吗?然而,科学家研究数据库是很直观的。

对码有部分依赖、对码有部分依赖,如果限定在非主属性。消除不好的依赖,达到2、3NF。如果进一步扩大到主属性,则消除不好的依赖后,达到BCNF,

BCNF的例子复杂一些:

48e7c3d3d3a10073be24586870c24e8

这个是满足3NF,但是不满足BCNF的例子,运用模式分解

76cbe12141088b3ab578bf7aaa94d9e

分解之后,达到了BCNF,

是否存在什么副作用?

前边讲2NF、3N,给人的感觉似乎是越来越好

只有好处没有坏处

那么,3NF->BCNF

是否也是 只有好处没有坏处?

BCNF解决了函数依赖的所有问题,再往上

需要分析新的数据依赖,多值依赖

3912dedd6863694418eda6c32d6faa6

每门课程有一组参考书,每门课程也有一组教师,并且,参考书和教师互相独立,即,不管哪个人上课,用的一套书都一样

这个例子做成关系表,Teach(课程, 教师, 参考书)

参考书和教师互相独立

课程,->->教师,课程,->->参考书

表示一门课程可以决定一组教师,或者,一门课程可以决定一组参考书

并且,这种依赖关系不会受其它因素影响

这个就是多值依赖的含义

这里特别注意,不会受其它因素影响  这句话

如果不加这句话,就没有意义了

因为给定一个X,肯定对应了 一组Y

关键是,X对应的这一组Y

不会受到其它因素影响,直观地说

就是把一个关系的所有列分成 X、Y、Z 三部分

X决定一组Y,不受Z影响

X决定一组Y,不受Z影响 称为 X->->Y

读作,X多值决定Y或者,Y多值依赖于X

现在来看一个特例,如果把关系的所有列分成两组,X和Y

那么,会怎么样?

结论是,必然有 X->->Y,因为这时候没有Z

当然也无所谓 受Z的影响

把关系的所有列分成两组 X和Y,则必然有 X->->Y

这样的多值依赖称为平凡多值依赖

和前边 平凡函数依赖 类似

平凡多值依赖 对数据库设计没有用,所以,我们分析的都是 非平凡多值依赖

也就是,把所有属性分成三份X、Y、Z的多值依赖

接下来看上边的例子

教师对课程有 非平凡多值依赖那么会带来什么影响?

假如,数据库课程 有3位教师有5本参考书

那么,表达数据库课程信息需要几行?15

那现在换一个人上数据库有5本参考书

那么,就需要换掉5行的内容

从这里可以看出多值依赖也会造成数据冗余性和数据操作复杂

能不能改善这个问题?

答案是:可以

但是,函数依赖在这里不起作用。因为现在的问题是 多值依赖

类似前边。我们找到了 有问题的数据依赖,就针对 有问题的地方 进行模式分解

课程->->教师 有问题,我们就对这里进行分解

75e57fdb6983e3e402e8a7bfc252c97

大家看一下上边的分解

C是课程、T是教师、B是参考书

分解以后,显然 非平凡多值依赖不见了,只剩下两列,变成了 平凡多值依赖

大家再看刚才的问题:冗余度、数据操作

更换一名课程教师,这时候只需要在 R(课程,教师) 关系里

改动一行就够了,3名教师占3行

5门课程,在另一张表里占5行

这个就是,按照 非平凡多值依赖 进行模式分解

我们再观察一个现象

a3b7699957de63577061bac59287533

选出一门课,改一种画法

c4002778da43105d6e378a3e4cc1bbb

离散数学、二分图

二分图可以看出什么呢

这就是 非平凡多值依赖 的一个特征

叫做 对称性

关系的所有列分成 X、Y、Z 三部分

如果有 X->->Y

那么,同时也必然有 X->->Z

就是说, X->->Y 和 X->->Z 一定是成对出现的

所以,大家分析关系模式

就等于也发现了 X->->Z

消除了 非平凡多值依赖

就达到了更高级别的范式4NF

还有一个问题大家考虑一下

函数依赖 和 多值依赖 有什么联系?

函数依赖,X决定一个Y

多值依赖,X决定一组Y

一个 是 一组 的 特例

所以,函数依赖 一定是 多值依赖

X->Y

表达,X可以明确确定一个Y

并且隐含了不受其它因素影响

所以,可以把 函数依赖 看作是 多值依赖 的特殊情况

b9579111fac600b0a9d2c0f79b98619

假如,一张表有5列现在把这张表分解成5张

每张表1列,大家说,这样分解以后满足几范式?4NF

因为高一级范式包含了低一级范式的条件

分成5个单列表,有没有意义?

这个直观上看没有意义

我们把数据放进表,就是因为列跟列之间有联系

全都分开了,比如,你的名字和你的身高

这样对处理问题完全没有帮助。但是,这是直观的说法

研究数据库的科学家。从理论上提出了两个概念

无损连接性和 保持函数依赖

无损连接性 表示模式分解之后

分解成的小表可以通过自然连接还原成原来的大表

可以回想我们前边的例题全都是符合 无损连接性 的

也就是说找到有问题的数据依赖

从这里入手进行分解

一定满足 无损连接性

这就提醒我们模式分解不能凭感觉

分解的前提是找到有问题的数据依赖

如果你凭感觉随便分。那么,有可能分完了以后

回头做连接数据会对不上

再来看另外一项,保持函数依赖

这一项的字面意思是,原来的大表中有多少函数依赖

分解以后的小表里,函数依赖 一个都不能少

当然,具体含义更复杂一些

保持函数依赖 比较麻烦

我们现在回头看前边BCNF的例子

33d201f0a1f966659431925cc04f8ff

11fd34b726486930f819e45eabb2f32

分解前后函数依赖有没有变少?

7e0ffe3c36abd12c37b0327e6c11eff

这两个实际上是一个

因为 T->J,显然有 (S,T)->J

比如,身份证号可以决定你的身高,身份证号 再附加一个 姓名,肯定可以决定 身高

抽象地表示是 X一方可以扩大

分解前:

ee8980a9af74e4ff21600984534345f

分解后:

efc2529376e5473bba785a6a49c6f4b

分解后还有没有2bc8b0f8351177cd09b06b988c5728e

没有

直观的原因是左边(S,J)已经不在一张表里了

或者说(S,J)是原先大表里的一个 候选码

模式分解以后

这个候选码不存在了

书上并没有说 原先某个候选码不存在 和 函数依赖丢失 之间是否有什么联系

但就这个例子而言似乎是这总原因造成的

这是我的个人看法,未必正确

大家听了以后自己思考

这个例子至少提醒我们

BCNF面临的问题是

通过 主属性对码的部分依赖、传递依赖 进行分解

得到的结果

主属性,即 某一个候选码 的属性

(这种分解

可能会破坏一部分候选码

进一步破坏掉一部分函数依赖,老师个人看法)

书上只给出了一个结论:若要求分解保持函数依赖,那么模式分解一定能够达到3NF,但不一定能够达到BCNF

大家看一下这句话。意思是,函数依赖一个都不丢失,可以保证达到3NF

但是,从3NF再向BCNF走

也许在 不丢失函数依赖 的条件下可以走到,但也可能无法走到,不一定能够达到BCNF

模式分解的要求

⒈ 分解具有无损连接性

⒉ 分解要保持函数依赖

⒊ 分解既要保持函数依赖,又要具有无损连接性

无损连接性和分解保持函数依赖是两个互相独立的标准

互相独立,表示满足一个跟满足另一个无关

具有无损连接性的分解不一定能够保持函数依赖

保持函数依赖的分解也不一定具有无损连接性

若要求分解具有无损连接性,那么模式分解一定能够达到4NF

若要求分解保持函数依赖,那么模式分解一定能够达到3NF,但不一定能够达到BCNF

若要求分解既具有无损连接性,又保持函数依赖,则模式分解一定能够达到3NF,但不一定能够达到BCNF

再强调一点:根据 有问题的数据依赖 为线索,去做模式分解,一定满足 无损连接性


关系数据库最有创造性的内容 范式理论

数据库设计的核心任务=找出数据项+参照完整性+数据依赖

8bf99be745086697252ab8df9f64fc2

找出数据项这是需求分析的任务

动词在数据库设计里 表达,联系表 对 基本表 的 参照

第一步,根据 需求 的描述,把 名词、动词 分离出来

第二步,名词对应基本表,动词对应联系表

联系表 参照 基本表,所以,数据库设计的结果大体是

6d6571155696b02cd4bdb37f26faaee

数据库设计的结果

1 是一组表

2 里边的关键因素是,表之间的 参照 联系

跟你们的UML类图很象

但是比UML类图简单,因为UML里class之间的联系比较复杂

动词----联系表,名词---基本表

联系表 参照 基本表,把这个说法形象的表示

书上叫做E -R图

数据库的 参照前边讲过

本质是 数量关系

1:m表示 1个对应多个

所以,数据库设计通常提取出名词、动词以后

把它们画成E-R图的形式,容易看

当然,画E-R图不算是必须的,你也可以直接画 关系图,许多设计数据库熟练的人会采取这种做法

E-R图向关系模型的转换

⒈ 一个实体型转换为一个关系模式。

⒉ 一个m:n联系转换为一个关系模式(两边实体的主码加联系自身的属性)。

⒊ 一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。

⒋ 一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。

⒌ 三个或三个以上实体间的一个多元联系转换为一个关系模式。

⒍ 同一实体集的实体间的联系,即自联系,也可按上述1:1、1:n和m:n三种情况分别处理。

⒎ 具有相同码的关系模式可合并。

大意是:

m:n必须有独立的 联系表,而1:m,可以把 联系表 吸收进 基本表

1:m  比如,学生表,系表两张表

学生表 里有一列 系号,参照 系表

相当于,把 联系表 吸收进 学生表

你也可以不在学生表里放 系号

而是单独建一张表 R(学号,系号)

这样就把联系表独立出来

两种做法都可以

数据库设计基本工作完成

但是,这时候的表因为是凭主观设计的,可能存在 不好的表

所以,接下来,还需要用 数据依赖进行细致分析

看看有哪些表不好需要分解

数据库的物理设计:数据库在物理设备上的存储结构与存取方法的设计

数据库实施:建表,输入数据,系统访问数据库试运行

数据库运行与维护:系统日常运行与数据库维护

数据库设计=1 提取 名词、动词 2 建立 联系表 参照 基本表 3 用范式理论优化表

HOMEWORK:

bbe961785dcc5aab0c8315c2fce763e

免责声明:文章转载自《20.6.21补数据库原理笔记》仅用于学习参考。如对内容有疑问,请及时联系本站处理。

上篇在Windows10下安装TensorRT +onnxjwt 认证规则下篇

宿迁高防,2C2G15M,22元/月;香港BGP,2C5G5M,25元/月 雨云优惠码:MjYwNzM=

相关文章

数据库课程设计心得【6】总结篇

一、      实现的功能 1、              系统管理员 Ø         用户管理模块: 用户管理模块主要是对用户的属性和权限进行管理,是系统的基础模块,功能由图3可见。由管理员添加的用户默认密码和用户名相同,修改密码只能由本人或者在数据库中修改完成。 Ø         课程管理模块: 管理员可以对课程进行增,删,查,改等操作。 Ø  ...

选课 树形DP

题意/Description:     大学里实行学分。每门课程都有一定的学分,学生只要选修了这门课并考核通过就能获得相应的学分。学生最后的学分是他选修的各门课的学分的总和。   每个学生都要选择规定数量的课程。其中有些课程可以直接选修,有些课程需要一定的基础知识,必须在选了其它的一些课程的基础上才能选修。例如,《数据结构》必须在选修了《高级语言程序设计》...

Linux makefile 教程 非常详细,且易懂

Linux makefile 教程 非常详细,且易懂 陈皓 (CSDN) 概述—— 什么是makefile?或许很多Winodws的程序员都不知道这个东西,因为那些Windows的IDE都为你做了这个工作,但我觉得要作一个好的和professional的程序员,makefile还是要懂 。这就好像现在有这么多的HTML的编辑器,但如果你想成为一个专业人士,...

requireJS的使用_API(1)

之前有介绍过requireJS(模块化开发),可以看看 ,但是不详细,所以今天参考官网来详细介绍一下: 1.加载js文件: RequireJS的目标是鼓励代码的模块化,它使用了不同于传统<script>标签的脚本加载步骤。可以用它来加速、优化代码,但其主要目的还是为了代码的模块化。它鼓励在使用脚本时以module ID替代URL地址。 Requ...

Redis常见问题及处理办法(转)

Redis使用过程中要注意的事项 Redis使用起来很简单,但是在实际应用过程中,一定会碰到一些比较麻烦的问题,常见的问题有 redis和数据库数据的一致性 缓存雪崩 缓存穿透 热点数据发现 下面逐一来分析这些问题的原理及解决方案。 数据一致性 针对读多写少的高并发场景,我们可以使用缓存来提升查询速度。当我们使用Redis作为缓存的时候,一般流程如图...

SQL试题集(一)

Student(S#,Sname,Sage,Ssex) 学生表 Course(C#,Cname,T#) 课程表 SC(S#,C#,score) 成绩表 Teacher(T#,Tname) 教师表 问题: 1、查询“001”课程比“002”课程成绩高的所有学生的学号;  select a.S# from (select s#,score fro...