架构师学习笔记-数据库范式等

版权声明:本文为博主原屙文章,喜欢你就担走。 https://blog.csdn.net/leftfist/article/details/82025470

一、三级模式-两级映射
这里写图片描述
通俗地说,
内模式看到的是数据库文件,关心数据如何存放;
概念模式是表
外模式是视图

二、关系代数




笛卡尔积
投影 :select 列
选择:条件过滤
联接:相同列合并,默认等值联接,即只保留两者的相同行

这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述

三、函数依赖
比如,学号可以确定学生姓名,就说姓名依赖学号。

1、部分函数依赖
主键为(学号 + 课程号),则字段“姓名“部分依赖于学号。

2、传递函数依赖

学号 宿舍 费用
062201 A 900
062230 B 1200
062240 B 1200
学号确定宿舍、宿舍确定费用,且有学号不包含宿舍,宿舍不确定学号,符合传递函数依赖条件。费用传递依赖于学号。

四、规范化理论的价值与用途
这里写图片描述

五、求候选关键字
这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述

六、范式
这里写图片描述

提升范式能消除数据冗余、插入异常、更新异常、删除异常等弊端;但范式并非越高越好,范式越高,数据的粒度就越小,有可能会带来管理、性能的问题。通常,到达范式三就差不多了。

范式是递增的。要达到高范式,一定是已经满足了低范式。

范式的判别有条件可供判断,条件满足,或者条件不存在,范式都成立

1、第一范式
这里写图片描述

2、第二范式
这里写图片描述
学分部分依赖主键(只依赖课程号),所以不符合第二范式。解决方法是拆分,将课程从此表中拆分出去,仅保留课程号。事实上, 改造为更高范式,通常都是拆分。

3、第三范式
这里写图片描述
主键只有一个,肯定不存在部分依赖情况,所以肯定符合第二范式。但表中存在传递依赖:学号确定系号,系号确定系名和地址,所以不是第三范式。办法:拆分。

4、BC范式
这里写图片描述
图中没有非主属性,肯定符合第三范式。但因为罗列出来的依赖表达式中,有属性T不是候选键,所以不是BC范式。

七、模式分解
表拆分其实就是模式分解。

1、保持函数依赖分解
这里写图片描述
分解之前有哪些函数依赖,分解之后,它们依然存在。
如图所示,模式R(A,B,C)有A->B,B->C,A->C,分解为R1(A,B),R2(B,C),此为保持函数依赖分解(A->C可由A->B,B->C传递推导出来)。但如果拆分为 R1(A,B)和R3(A,C),则不是保持函数依赖分解,因为B->C没有了。

2、无损分解
这里写图片描述

1)表格法
这里写图片描述

列为关系模式的属性
行为分解模式
a代表分解模式中拥有原模式中的属性
当有两行中某列为同为a,则可根据函数依赖,将不为a的列改为b。如果最后能得到一行
全为a,则是无损分解。
这里写图片描述

2)运算法
这里写图片描述
适合分解为两个模式的情况。
将这两个模式分别求交集、互相求差,如果有交集确定任一差,则为无损分解。

猜你喜欢

转载自blog.csdn.net/leftfist/article/details/82025470