做完教务系统的需求分析,接下来就是对数据库的设计.数据库设计是web开发中特别重要的一个环节,好的数据库设计不仅能让我们实现软件时得心应手.对后期的维护,升级也是至关重要的.

记得牛腩在新闻发布系统中这样说过,数据库设计完成了,那么这个软件也就完成了70%的工作.可见其重要性.

 

对数据库的设计,主要是依赖界面设计来做的.界面反映了用户的直接需求.把这些需求转换成数据库中的表.再为这些表添加主键,外键等约束.以确保数据关系的合理性.然后再根据业务的流程去梳理数据库数据的流向是否得当.

 

在这里我解释一下自己做数据库设计的一些思路和体会.

对数据库字段的确定,主要是依赖界面中需要添加那些信息,需要处理那些信息,将对应信息分类到相应的表中.这里不说如何确定和提取字段了,因为自己感觉也说不清楚,当你见得数据库多了,你就会自然而然的把他们分出来.

 

这里主要说一下对数据库三范式的理解和应用.

 

第一范式:数据库表中的字段都是单一属性的，不可再分

对于第一范式,还是比较好理解的,说白了就是说一个列不能有多个值,每一个字段都是不可拆分的.比如数据库有这样一个字段:父母.显然这是不行的.因为父母属于两个独立的个体,完全可以拆分.如果把他们设置为一个字段.结果就是对于这个字段来说,我们是不方便应用的.因为父母可能有原因只有一个或者其他情况,这样对于数据库来说,一个字段就是不完整的.对于数据的查询,显示都是有问题.

 

第一范式比较容易理解,一般人不会犯这样的错误.

 

第二范式:

数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

首先对关键字是做一些说明:

超关键字 :

二维表中，能够惟一确定记录的一个字段或几个字段的组合被称为“超关键字”。“超关键字”虽然能唯一确定记录，但是它所包含的字段可能是有多余的。

候选关键字:

如果一个超关键字去掉其中任何一个字段后不再能唯一地确定记录，则称它为“候选关键字”（Candidate Key）。候选关键字既能唯一地确定记录，它包含的字段有是最精炼的。也就是说候选关键字是最简单的超关键字。

比如:在一个学生选课表中

学号　姓名　性别　课程名称　成绩　学分

这里的关键字为组合关键字，（学号　课程名称）

出现的问题就是有：

１：姓名　性别　依赖于学号这个候选关键字

２：学分　依赖于课程名称这个候选关键字

显然是不符合第二范式的．

那么不符合第二范式会产生什么结果呢？　一般说来，不符合数据库三范式会引起插入异常，更新异常，删除异常．

１：插入异常：比如要新开一门课程，如果没有人选的话，这么课程就插入不到数据库，因为它没有学号，姓名，性别这些信息．

２：更新异常：如果要修改一门课程的学分，那么所有的学分字段都要修改，否则出现同一课程不同学分的情况

３：删除异常：如果某门课程取消了，要删除课程的时候，这个学生的信息也会被删除．

当然，不合理的数据库设计会造成大量的数据允余：

比如某个学生选择了ｎ门课程，学生的姓名　性别就会重复ｎ次．

如果把这个表拆分成三个：

学号　姓名　性别

课程　学分

学号　课程　成绩

这样就不违反第二范式，也就是说，也肯定不会违反第二范式，因为他们没有组合关键字，可以看出，有组合关键字的可能违反第二范式．

第二范式也可以理解为：主键确定一条唯一记录，也就是说关键字在数据库表中唯一出现一次．

 

第三范式：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系．

 

比如：

学号　姓名　所在学院　学院名称

这里的学院名称完全依赖于学院，和关键字学号没有关系．这样就是传递依赖

违反第三范式也会产生数据库异常和允余．这里就不再分析．

 

在基础信息的数据库设计中，第一次设计很多违反了第三范式，这些主要是对界面的过分依赖造成的．也就是说，你看到的界面信息，很可能是来自不同的数据库，如果你把他们放到一个数据库，就会违反数据库三范式．

数据库设计是非常重要的．也是对自己的数学逻辑理解的考验．关系型数据库的设计，最后就是一个对数学函数的模拟．