1.数据库范式
1.1 知识准备
1.1.1 函数依赖
完全函数依赖
设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。 例子:学生基本信息表R(学号,班级,姓名)假设不同的班级学号有相同的,班级内学号不能相同,在R关系中,(学号,班级)->(姓名),但是(学号)->(姓名)不成立,(班级)->(姓名)不成立,所以姓名完全函数依赖与(学号,班级);
部分函数依赖
设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。 举个例子:学生基本信息表R中(学号,身份证号,姓名)当然学号属性取值是唯一的,在R关系中,(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号);
传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。 例子:在关系R(学号 ,宿舍, 费用)中,(学号)->(宿舍),宿舍!=学号,(宿舍)->(费用),费用!=宿舍,所以符合传递函数的要求;
1.1.2 码
码是数据系统中的基本概念。所谓码就是能唯一标识实体的属性,是整个实体集的性质,而不是单个实体的性质。它包括超码,候选码,主码。
超键(super key):在关系中能唯一标识元组的属性集称为关系模式的超键候选键(candidate key):不含有多余属性的超键称为候选键 主键(primary key):用户选作元组标识的一个候选键程序主键 外键(foreign key)如果关系模式R1中的某属性集不是R1的主键,而是另一个关系R2的主键则该属性集是关系模式R1的外键。
1.2 范式规范
1.2.1 范式的提出是为了解决什么?
解决关系模式中存在的问题
下表为解释示例 Table Students
学号 | 院系 | 姓名 | 课程号 | 成绩 | 系主任 |
---|
S1 | 计算机系 | 小明 | C1 | 95 | 光头强 | S2 | 计算机系 | 小红 | C1 | 90 | 光头强 | S3 | 计算机系 | 小绿 | C1 | 90 | 光头强 |
1.数据冗余
比如,一个系的系主任名字重复出现,重复次数与该系所有学生的记录相同,浪费了大量的存储空间
2.更新异常
由于数据冗余,当更新数据库中的数据时,系统要付出很大的代价来维护数据库的完整性,否则会面临数据不一致的危险。比如,某系更换系主任后,必须修改与该系学生有关的每一个元组。
3.插入异常
如果一个系刚成立,尚无学生,则无法把这个系及其系主任的信息存入数据库
4.删除异常
如果某个系的学生全部毕业了,则在删除该系学生信息的同时,这个系及其系主任的信息也会丢掉。
1.2.2 范式的种类
对于Java程序员来说,了解1NF,2NF,3NF即可
高一级的范式依赖于低一级的范式
1.2.3 1NF
满足关系型数据库的最低要求即可,比如不可表中有表等
1.2.4 2NF
属于1NF,且每一个非主属性完全函数依赖于任何一个候选码(即消除表中的部分函数依赖)
解决了插入异常和删除异常,但依旧存在修改复杂的问题
1.2.5 3NF
属于2NF,且每一个非主属性既不传递依赖于码,也不部分依赖于码(即在2NF基础上消除表中传递依赖)
解决了修改复杂的问题
2.数据库的设计
2.1 一对一关系
如:人和身份证 分析:一个人只有一个身份证,一个身份证只能对应一个人
实现方式 一对一关系实现,可以在任意一方添加唯一外键指向另一方的主键。
2.2 一对多关系
如:部门和员工 分析:一个部门有多个员工,一个员工只能对应一个部门
实现方式
在多的一方建立外键,指向一的一方的主键
2.3 多对多关系
如:学生和课程 分析:一个学生可以选择很多门课程,一个课程也可以被很多学生选择
实现方式
多对多关系实现需要借助第三张中间表。中间表至少包含两个字段,这两个字段作为第三张表的外键,分别指向两张表的主键
|