回去好好恶补了下基础知识,才知道原来自己基础有多么糟糕,很多问题都想不明白是因为知识不够,所谓学而不思则罔,思而不学则殆。
好了,开始记录几天的学习历程
数据库设计过程中的关键的问题是如何把现实世界表达成适合他们的关系模型
设计一个教学管理系统数据库
x
学生学号 | 学生姓名 | 学生年龄 | 学生所在系别 | 系主任姓名 | 课程号 | 成绩 |
S1 | 张三 | 17 | 计算机 | 刘伟 | C1 | 90 |
S1 | 张三 | 17 | 计算机 | 刘伟 | C2 | 85 |
S2 | 张三 | 17 | 信息 | 孙斌 | C5 | 80 |
S2 | 李四 | 18 | 信息 | 孙斌 | C6 | 70 |
S2 | 李四 | 18 | 信息 | 孙斌 | C7 | 75 |
S2 | 李四 | 18 | 信息 | 孙斌 | C5 | 50 |
S3 | 王五 | 20 | 信息 | 孙斌 | C1 | 0 |
S3 | 王五 | 20 | 信息 | 孙斌 | C2 | 65 |
S3 | 王五 | 20 | 信息 | 孙斌 | C4 | 95 |
S4 | 赵六 | 21 | 自动化 | 刘伟 | C1 | 85 |
怎么样确定一条记录呢,由上面表可以看出是由学生学号和课程号组合(学生学号,课程号)联合主键来确定一条记录
看看此表中的数据会发现几个问题
1 数据冗余
由于主键是学生学号和课程号,所有会造成数据有学生学号*课程号那么多,而如此多的记录对应重复学生姓名和年龄,浪费了存储空间
2插入异常
如果只有系名和系主任的信息,而没有学生信息,就无法完成插入,因为没有学生意味着没有学生学号和课程号,没有主键记录 当然不能插入数据
3删除异常
删除学生信息时,会相应的删除系名称,此时如果本系的学生全部删除,那么将不存在这个系,很明显学生删除会影响系的存在,这很不合理
4更新异常
如果学生改名,将会逐一更改学生姓名,又比如某个系换主任,则属于该系的学生都要更换主任,稍有不慎,就会漏改。
综上所述,原因是这一条记录包含了太多的信息
如何讲这些信息分离,将复杂的关系分解成简单的关系,将不好的关系设计成好的关系,就是数据的规范化。 也就是我们所说的数据库范式
终于到正题了^_^
第一范式(不满足第一范式的就不是关系数据库)
数据库中的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果有重复属性,就需要定义一个新实体,新实体与原实体为一对多的关系。
举个例子
部门 | 员工 | 员工 | 员工 |
生产部 | 小王 | 小花 | 小妹妹 |
部门对应多个员工,出现重复属性,不满足组范式1
第一范式要满足不能将部门中的信息都放在一列中显示,也不能将其中的两列或者多列在一列中显示,说白了,一列就只能放置一个值。 列无重复
同时,部门信息表的每一行只表示一个部门信息,一个部门信息在信息表中只出现一次。
数据库中的字段都是单一属性,不可再分
第二范式(主键唯一)
数据库表中的每一个实例或行必须可以被唯一地区分,为实现唯一区分,一般都会加入一个唯一标识列。
第二范式要求实体的属性完全依赖主关键字。如果不完全依赖于关键字,就会出现最上面图的情况。
(学号,课程名称)->(姓名,年龄,成绩,学分)
应改为
(课程名称)->(学分)
(学号)->(姓名,年龄)
第三范式(消除非主属性依赖)
第三范式要求每一个非主属性既不部分依赖,也不传递依赖于码
(学号)->(姓名,年龄,所在学院,学院地点,学院电话)
符合第二范式,但不符合第三范式
存在
(学号)->(所在学院)->(学院地点,学院电话)
出现非主属性传递依赖,不是直接依赖于码(学号),而是依赖于所在学院。