数据库范式
网络深处的易某某 2024-08-28 13:31:29 阅读 80
相关概念
函数依赖
这里我纯白话解释了,纯概念去百度查。
我们设 R(U) 是属性集合 U 的一个关系模式,可以理解为一张表就算关系 R,里面的属性的集合就是 U。
其中 U = {学号,姓名,年龄,身份证号,系名,系位置,课号,成绩}。
名词
| 概念解释
| 示例(基于属性集合 U)
|
函数依赖
| 通过属性(组) A 必能得出属性(组) B,就可以说 B 依赖于 A,用 A→B 表示。
| 学号→{姓名,年龄}
|
完全函数依赖
| 通过{A,B}能得出C,但是A 或 B单独得不出C,则 C 完全依赖于{A,B}。
| {学号,课号}→成绩,学号或课号单独无法确定成绩。
|
部分函数依赖
| 通过{A,B}能得出C,A 或 B单独也能得出C,则 C 部分依赖于{A,B}。
| {学号,身份证号}→姓名,学号或身份号单独也能确定姓名
|
传递函数依赖
| 通过 A 得出 B,通过B 得出 C,但是 C 得不到B,B 得不到 A,则 C 传递依赖于 A。
| 学号→系名,系名→系位置,但是反过来无法得出。
|
码的相关概念
名词
| 说明
|
元组
| 二维表的每行数据,就是一个元组,每列就是一个属性。
|
数据库码
| 又称数据库关键码,是数据库中唯一能标识一个记录值的内部记录标志符。
|
候选码
| 如果关系中的某一属性(组)的值能唯一地标识一个元组,则称该属性组为候选码。
|
主码
| 就主键,一个关系中有多个候选码,选定其中一个为主码。
|
外码
| 就是外键。一个关系中的一个属性是另外一个关系中的主码则这个属性为外码。
|
主属性
| 候选码中的属性称为主属性。
|
非主属性
| 不包含在任何候选码中的属性称为非主属性。
|
实体的完整性
| 每个数据表都必须有主键,而作为主键的所有字段,其属性必须是唯一且非空。
|
约束类型
| 主键约束、唯一约束、自动增长列
|
第一范式(1NF)
【概述】
确保每列保证原子性,保证这个属性(字段)不能在被分割。
【示例】
下表中院系可以分割为系名和位置,故该设计不符合第一范式。
系号
| 院系
| 老师
|
X001
| 计算机系在逸夫楼
| 图灵
|
X002
| 金融系在尚贤楼
| 巴菲特
|
应修改为:
系号
| 系名
| 位置
| 老师
|
X001
| 计算机系
| 逸夫楼
| 图灵
|
X002
| 金融系
| 尚贤楼
| 巴菲特
|
第二范式(2NF)
【概述】
在第一范式的基础上,消除了非主属性对于主键的部分函数依赖,也就是说非主属性必须完全依赖于主键,一般针对多字段组成的主键才会违反该范式。
【示例】
下表已满足第一范式,主键只能是{学号,课程号},其他的字段都是非主属性。其中{学号,课程号}→姓名,并且学号→姓名,这就构成了姓名部分依赖于{学号,课程号},故违反第二范式。
学号
| 姓名
| 院系
| 年龄
| 课程号
| 课程名
| 学分
|
S001
| 张三
| 计算机
| 20
| K001
| 数据库
| 4
|
S002
| 李四
| 物理
| 22
| K002
| 光学
| 2
|
应进行拆分两张表:
学生表
|
| 课程表
| |||||
学号
| 姓名
| 院系
| 年龄
| 课程号
| 课程名
| 学分
| |
S001
| 张三
| 计算机
| 20
| K001
| 数据库
| 4
| |
S002
| 李四
| 物理
| 22
| K002
| 光学
| 2
|
第三范式(3NF)
【概述】
第三范式在第二范式的基础之上,消除了非主属性对于候选码的传递函数依赖
。就是说非主属性之间不能有依赖关系,它们是互相独立的。
【示例】
下表已满足第二范式,主键是学号。其他字段都是非主属性,均完全依赖于主键,都能直接通过主键获取。但是,这里存在传递依赖关系为,学号→专业编码→专业名称/专业位置。其中,专业编码、专业名称、专业位置之间存在依赖关系,故违反第三范式。
学号
| 姓名
| 年龄
| 专业编码
| 专业名称
| 专业位置
|
S001
| 张三
| 20
| J001
| 计算机
| 逸夫楼
|
S002
| 李四
| 22
| W001
| 物理
| 尚贤楼
|
应拆分为:
学生表
| 专业表
| ||||||
学号
| 姓名
| 年龄
| 专业编码
| 专业编码
| 专业名称
| 专业位置
| |
S001
| 张三
| 20
| J001
| J001
| 计算机
| 逸夫楼
| |
S002
| 李四
| 22
| W001
| W001
| 物理
| 尚贤楼
|
反范式
有时候我们想要对查询效率进行优化,反范式化也是一种优化思路,我们可以通过在数据表中增加冗余字段来提高数据库的读性能。
比如我们才独去员工表时,经常需要获取该员工的部门名称,根据三范式,员工表中只要存储员工的部门编码就好,这样我们就需要频繁的联表查询,效率会低。这时冗余部门名称字段就可以减少频繁的联表查询。
BC范式
【概述】
BC范式(BCNF):对于关系模式R,若 R为第一范式,且每个属性都不是部分依赖于候选键也不是传递依赖于候选键,则R称之为BC范式。
也可理解为在第三范式的基础上,进一步消除了主属性对候选码的部分函数依赖和传递函数依赖。
什么意思呢?就是说表中的候选码不止主键一个,出现了其他字段,这时候就出现主属性部分依赖于候选键,违反 BC 范式,造成造成了字段冗余。
【示例】
例如,关系模式STJ(S,T,J)中,S表示学生,T表示老师,J表示课程。其中,每一个老师只教一门课程,每门课程有一个老师,某个学生选修某个教师的课就确定了所选课的名称。
候选码:(S,J)、(S,T)
函数依赖:(S,J)→T,(S,T)→J,T→J;
主属性:学生、老师、课程;
非主属性:无。
因为没有任何非主属性对码传递依赖或部分依赖,故STJ是3NF,但T是决定因素而T不包含码,故STJ不是BCNF关系。
声明
本文内容仅代表作者观点,或转载于其他网站,本站不以此文作为商业用途
如有涉及侵权,请联系本站进行删除
转载本站原创文章,请注明来源及作者。