数据库范式
自己开发了一个股票软件,功能很强大,需要的点击下面的链接获取:
https://www.cnblogs.com/bclshuai/p/11380657.html
数据库范式
目录
1 关键码... 1
2 依赖... 1
3 范式... 2
1 关键码
1) 超键:在关系中能唯一标识元组的属性或属性集称为关键模式的超键。
2) 候选键:不含有多余属性的超键称为候选键。也就是在候选键中在删除属性就不是键了。
3) 主键:用户选作元组标识的候选键称为主键。一般不加说明,键就是指主键。
4) 外键:如果模式R中属性K是其他模式的主键,那么K在模式R中称为外键。
2 依赖
(1)部分函数依赖:设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。
举个例子:学生基本信息表R中(学号,身份证号,姓名)当然学号属性取值是唯一的,在R关系中,(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号);
(2)完全函数依赖:设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。
例子:学生基本信息表R(学号,班级,姓名)假设不同的班级学号有相同的,班级内学号不能相同,在R关系中,(学号,班级)->(姓名),但是(学号)->(姓名)不成立,(班级)->(姓名)不成立,所以姓名完全函数依赖与(学号,班级);
(3)传递函数依赖:设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。
例子:在关系R(学号 ,学院号, 学院地址)中,(学号)->(学院号),学院号->学院地址,所以是传递函数依赖关系;
(4)多值依赖:属性值之间存在多对多的关系,如下图所示,一个课程,有多个老师上,一个课程,也有多个不同的年级要上,course多值依赖teacher,course多值依赖class。存在多对多或者一对多的关系。
3 范式
(1)第一范式(1NF):一个关系模式R的所有属性都是不可分的基本数据项。例如学生表中高三2班,这是一个复合属性,需要拆分为年级(高三)和班级(2班)之后,才满足第一范式。
(2)第二范式(2NF):关系模式R属于第一范式,存在唯一标识记录的主键,不存在非关键字段对任一候选关键字段的部分函数依赖。例如学生表的(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号);
(3)第三范式(3NF):关系模式R属于第二范式,且每个非主属性都不传递依赖于键码。例如学生关系表为Student(学号,姓名,年龄,所在学院,学院地点,学院电话),(学号)->(学院号),学院号->学院地址,所以存在传递函数依赖关系。要符合第三范式,要消除传递依赖关系,拆分为两个表格
学生:(学号,姓名,年龄,所在学院);
学院:(学院,地点,电话)。
(4) BC范式(BCNF):关系模式R属于第三范式,不存在任何字段对任一候选关键字段的传递函数依赖,相对于第三范式,就是候选关键字之间不存在传递依赖。例如(仓库ID,存储物品ID,管理员ID,数量),且有一个管理员只在一个仓库工作,一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:
(仓库ID,存储物品ID) →(管理员ID,数量)
(管理员ID,存储物品ID) → (仓库ID,数量)
所以(仓库ID,存储物品ID)和(管理员ID,存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系,不满足BCNF范式。
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
总结
第一范式:消除了复合属性,例如高三2班;
第二范式:不存在非主属性对主属性的部分依赖。例如(学号,身份证号)->(姓名);
第三范式,消除了非候选主键属性对候选主键属性的传递依赖。
BCNF范式:消除候选主键之间的传递依赖关系。
消除决定因素 | 1NF
| ↓ 消除非主属性对码的部分函数依赖
函数依赖 | 2NF
| ↓ 消除非主属性对码的传递函数依赖
| 3NF
| ↓ 消除主属性对码的部分和传递函数依赖
| BCNF
| ↓ 消除非平凡且非函数依赖的多值依赖
| 4NF
| ↓消除不是由候选码所蕴含的连接依赖
| 5NF