数据库范式设计指导.doc

数据库规范设计指导规范 第 1 页 共 7 页 目 录 数据库规范设计指导规范 ............................................................................................................... 1 1 范式说明 ................................................................................................................................... 3 1.1 1.2 1.3 1.4 第一范式（1NF）:................................................................................................... 3 第二范式（2NF） .................................................................................................... 4 第三范式（3NF） .................................................................................................... 5 反范式数据库设计 ................................................................................................... 6 第 2 页 共 7 页 1 范式说明 数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。在常规数据库设计中，一般只需要知道前三种范式就可以了。 1.1 第一范式（1NF）: 在关系模式R中的每一种具体关系中r中，如果每个属性值都是不可再分的最小数据库单位，则成为R是第一范式关系。 第一范式简单来说，就是属性具有原子性，不可再分性。表2-1是一个简单的例子。 表2-1 从表中可以看出，在课程选修表中，选修科目设计为一个字段，选修内容用逗号（,）隔开，好像也没什么问题，但是，如果想要统计那些人选修了哪门课，将变得非常困难，如果想统计哪些人选修了美术，可能用到如下语句： Select count(*) from course where subject ‘%美术%’； 除了这个影响，更新的影响也非常大，如，想要给王五选修科目中增加一门生物，就必须先读出以前的科目，然后在科目后面合并一个生物，这个表就不满足第一范式。 那么，为了满足第一范式，可以做一个简单的修改（见表2-1） 表2-1 第 3 页 共 7 页 作了以上修改就可满足第一范式了，如果想要统计哪些人选修了美术，sql语句可以修改为： Select count(*) from course where subject = ‘美术’； 如果想要给王五增加一门生物，只需要insert就可以了。 1.2 第二范式（2NF） 如果关系模式R（U,F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R是属于第二范式。 第二范式简单的说，就是表示每个表都有一个主键，其他字段完全依赖于该主键。 还以上面的表为例，现在满足了第一范式，但是不满足第二范式，也就是没有一个可以唯一确定的主键，如果王五同学想把课程地理课改修为天文，他不得不把所有的字段作为查询条件来更新记录。那好，增加一个主键ID（pk），如表2-3所示： 表2-3 有了主键，如果能确定哪一行需要修改，用主键就可以确定该行。如王五同学想把课程地理改为天文学，那么更新语句根据主键来更新： 第 4 页 共 7 页 Update course set subject =’天文学’ where id=9; 这样，以上的表复合第二范式了吗，其实还没有，我们可以看到，编号依赖于ID，但姓名是依赖于编号的，没有唯一的主键，还不符合第二范式，那会有什么问题呢？如张三要换一个名字，就要更改这表中的四条记录，如果涉及上万条记录呢，就需要更新上万条记录。 这也仅仅是其中一个问题，还有，如果要统计有多少个学生，从课程表中是很难获得的，因为可能有的学生没有选修课，就是全部选修了，也要distinct，大大影响了