数据库设计的三范式

来源:互联网 发布:淘宝导出所有宝贝链接 编辑:程序博客网 时间:2024/05/18 00:20

自己对于数据库设计的三种范式的理解,阅读过很多相关的博客。例子的引用可能有相同,忘原作者谅解。

本文按照自己的语言来下定义,总结。理解不是很透彻,肯定有不当或者错误的地方,希望大家指导,谢谢。




一:第一范式

实体的属性唯一存在且不能再分。关系数据库是建立在第一范式的基础上的,也就是说正常情况下建立的表已经满足第一范式的要求。

不满足第一范式的示例:

学号姓名年龄联系方式10001张三20电话:137000000 QQ:10……10002李四21电话:186000000 QQ:100……

上表中联系方式属性中存储了不唯一的两个属性,这样就不符合第一范式。

修改为:学号姓名年龄电话QQ10001张三2013700000010……10002李四21186000000100……


二:第二范式

满足第二范式需要在满足第一范式的基础上增加两个条件:1.不存在部分依赖,都是完全依赖。 2.每个非主属性都能由属性决定。

不满足第二范式要求的

表一:如下 :学号姓名年龄学校学院专业1001张三20清华大学计算机学院软件工程1002李四21浙江大学经济管理学院经济管理

这个表不满足两个条件中的第二个:即:每个非主属性都能由主键决定。 这个表中主属性是学号,根据学号可以决定姓名,决定 年龄,但是不能决定学校以及之后的字段,因为别的学校也在用比如1001这个学号。 所以不符合第二范式。

为了符合第二范式,可以将后三个字段放在一个表中,并且添加编号主键, 在上表中添加存储该主键的外键。

表二:

学生课程教师教师职称教材教室上课时间张三C#王老师教授C#程序设计3018:00李四java李老师副教授java程序设计30210:00

这个表符合两个条件中的第二个 ,即:每个非主属性都能由主键决定。 

我们把学生跟课程作为符合主属性,则根据【学生,课程】能够确定 教师,教师职称,等属性。

但是该表不符合第一个属性,即 不满足“不存在部分依赖,都是完全依赖” 该表中 课程 可以决定 教材,也就是说教材部分依赖主属性。所以该表
不符合第二范式。

如表二的设计存在的不足跟异常:

1:数据冗余

如果有多个人选择了C#这门课,则对应的后边的都要存储。

2:插入异常

现在增加了一门课程,但是没有学生选课,那么这门课就不能插入,因为主键中缺少学生。


3:删除异常:

假设现在把上边的两条数据删除了,那么我想知道C#这门课用什么教材就不能查询了。

第二个表可以改成:

表2-1
学生课程教师教师职称教室上课时间张三C#王老师教授3018:00李四java李老师副教授30210:00表2-2
课程教材C#C#程序设计javajava程序设计

这样就符合第二范式要求了。


三:第三范式

在满足第二范式的基础上,非主属性之间不存在函数依赖,即除了主属性之外的其他属性之间不能存在 由一个属性决定另一个属性的情况。即不存在传递依赖。

如上表2-1中 除了主属性【学生,课程】 之外, 教师 这个属性可以决定 教师职称,所以就存在主属性【学生,课程】------>教师————>教师职称。

这样就存在传递依赖。 

这样也会存在不足与异常。

可以改成:以下两个表学生课程教师教室上课时间          教师教师职称    


四;其他

有三个表

表4-1
学号姓名性别年龄1001张三男201002李四女21表4-2
课程代码ID课程名学分book0001C#4book0002java4表4-3
学号课程ID成绩1001book0001901002book000290显然上表是符合第三范式要求的,但是有一个绩点的字段,可以由 成绩跟学分来确定,而绩点在平时使用的非常多。那么这个时候就要考虑是否需要加这个字段呢?

如果加了就不符合第三范式,如果不加的话可能会比较麻烦。

其实数据库设计不用非得按照第三范式,很多情况下按照第三范式进行设计会对数据处理的效率还有编码的复杂度影响很大。需要根据实际情况考虑多种因素选择一个折中的设计方案。


以上仅仅是初步的了解,更深刻的了解还需在提高编码经验与设计经验的基础上更进一步去体会。

原创粉丝点击