为什么需要规范化理论?数据库设计根据需求分析规划出概念模型,把 E-R 图转换为关系模型,是不是数据库设计就完成了呢?
事情并不是这个样子的,如果随意设计E-R图,也就是随意设计表结构,那么会带来很多麻烦的。例如:
student1(sno(学号),sdept(所在系),dname(系主任),cname(课程名),grad(成绩))
| sno | sdept | dname | cname | grade |
|---|---|---|---|---|
| S1 | 计算机系 | 张三 | 数学 | 85 |
| S1 | 计算机系 | 张三 | 英语 | 92 |
| S1 | 计算机系 | 张三 | 物理 | 88 |
| S2 | 电子系 | 李四 | 数学 | 79 |
| S2 | 电子系 | 李四 | 英语 | 88 |
| S2 | 电子系 | 李四 | 化学 | 91 |
| S3 | 计算机系 | 张三 | 数学 | 92 |
| S3 | 计算机系 | 张三 | 英语 | 86 |
| S4 | 生物系 | 王五 | 化学 | 90 |
| S4 | 生物系 | 王五 | 历史 | 87 |
| S5 | 地理系 | 赵六 | 物理 | 94 |
| S5 | 地理系 | 赵六 | 化学 | 89 |
在这个表中,每行代表了一个学生的一门课程成绩。包含的字段包括学生编号(sno)、所在系(sdept)、系主任(dname)、课程名(cname)和成绩(grade)。这个表结构虽然简单,但是存在大量冗余数据,如果有多个学生都选了同一门课程,这门课程的课程名、授课教师、所在系和系主任的信息都需要在表中重复存储,导致存储空间的浪费和数据冗余的问题。因此,这种表结构不符合第三范式的要求。
除此之外,一张表囊括很多数据的设计方式会导致其他的问题,比如说更新异常,插入异常,删除异常等等,具体如下:
(1) 更新异常。由于数据冗余,因此更新数据的时候也有可能会导致数据不一致例如,当某个学生转系,那么这个学生的所有记录都需要修改;再如,换届选举更改系主任,那么所有记录的系主任信息全部都需要修改,若某些行没有发生修改,则会出现数据不一致的情况。
(2)插入异常。插入数据时,如果主属性为空,就不能添加数据,如在 student1 模式中,主键为学号和课程名,当来了一个新生,如果没有选课,就无法插入数据;如果新成立一个系,尚无学生,就无法将这个系的信息存入数据库;如果新开设一门课程,还没有学生选修,同样也无法将课程信息插入据库。
(3)删除异常。当删除数据时,所有的学生信息都没有了,课程信息、系、系主任的信息都随着丢失。这些问题是怎么造成的呢?因为存在数据依赖,即属性之间存在值相互制约、相互影响的关系,某部分属性的值决定其他属性的值。
总结: 不遵守设计范式设计出来的表结构会有很多问题,问题包括数据冗余、增删改异常。