最近做了一个小项目完整的数据库设计,想总结一些设计上的所得,希望大家多多指教。

　　有时一个项目，普通程序员一般不会去接触数据库设计，一般都有专业的DBA或是老程序员去设计，下面是我推测的几点可能原因：

　　1：新手对项目了解不深，正好这是老鸟的长处。

　　2：新手对局部的关注往往大于整体，很难考虑的特别周全。

　　3：数据库设计的好坏在某种程度上直接影响项目的复杂度以及性能。

　　第一：我们要知道什么是范式，为什么说到数据库设计总要提到一个名词：范式。范式：符合某一种级别的关系模式的集合。设计数据库必须遵循一定的规则,在关系数据库中，这种规则就是范式。

　　第二：范式的分类。关系数据库中的关系必须满足一定的要求，目前关系数据库有六种范式：第一范式、第二范式、第三范式、第四范式、第五范式和第六范式。满足最低要求的是第一范式，其余范式以次类推。这么多的分类并不一定要求全部满足，平时我们通常是达到第三范式就行。

　　第三：范式的作用?

　　1:优点：是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。

　　2:缺点：可能使数据库产生重复数据，从而导致创建多余的表。

　　3:是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。

　　4:设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，也不会发生插入、删除和更新操作异常。反之则给编程人员制造麻烦，可能存储了大量不需要的冗余信息。

　　下面来简单介绍下前三种范式：

　　一：第一范式。是对关系模式的基本要求，不满足第一范式的数据库就不是关系数据库。  

所谓第一范是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。  

例如有一张存储文件的表,正确应该是这样：可以看到这个表包含了好几个列，如果我们把这些信息都放在一列里面那么就不满足上面定义的1NF了。　　二：第二范式:在第一范式的基础上建立起来的。要求数据库表中的每个实例或行必须可以被惟一地区分。通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。像上面的Regulations的ID列就是一个身份标识列(identity)。

　　三：第三范式:要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如：上面有了一个文件表  

Regulations,如果这个表是存储的主文件，它相应的还有n个附件信息的话，我们就需要创建另外一张附件表来存储附件。两表如何联系起来呢，我们可以把主文件表的主键随同附件信息做为一条记录插入到附件表中，这里插入的主文件表信息中只包含了主键ID，并没有插入其它信息，这种关系就满足了第三范式要求。