剖析数据库设计三范式

概要

早就听说三范式了,记得第一次做机房收费系统的时候,只是为了简单的完成数据的增删改查,并没有去想数据库如何设计,现在不同了,第二遍设计数据库,要求提高了嘛，我们需要的是根据需求来更加合理的设计数据库,要遵循数据库的基本原则三范式,三范式刚开始听起来觉得懵懂,后来通过学习渐渐的明朗起来,首先介绍一下三范式的大致内容:

三范式的目的

为了建立合理结构的数据库，减少数据冗余，设计数据库必须要遵循一定的规则，在关系型数据库中这种规则叫做范式，想设计一个结构合理的关系型数据库，必须要满足一定的范式，我们把一个项目中用到的数据库分别建立多个表并建立表中间的关系，可以消除很多错误或者垃圾数据并减少我们的工作量、减少数据的不完整性，是数据库设计的更加规范。

详细剖析

范式达到五个，但是对于我们来说，三个范式已经很高了，（后期再逐渐的深入学习）

第一范式（1NF）：就是能分就分，分到不能分为止（所有字段值都是不可分解的原子值）

第一范式（1NF），（一个字段不能包含多个列，即每个列和记录包含一个仅包含一个值的表）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。第一范式的合理遵循需要根据系统的实际需求来定

例如：实例1

不满足第一范式，学院、年级、班都是还可以再往下分的

改进后：

第二范式（2NF）：要求实体的属性完全依赖于主关键字（函数不能部分依赖）。

第二范式在第一范式的基础上，要保证数据库表中的每一列都和主键相关，完全依赖主键，所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字（一种表只能保存一种数据，不可以把多种数据保存在同一张数据库表中）

对于自己第一遍的机房收费系统数据库学生信息表，当时就是为了表减少,调用方便现在现在看起来很是冗余。例如下图：

根据第二范式的要求修改后为信息基本信息表和卡信息表

学生基本信息表：

卡信息表：

每个表创建了数据自己表的主键，其他字段完全依赖于主键而存在，在这两个表之间我们建立了外键的约束关系。显得很是清晰：

3．第三范式3NF：(确保每列都和主键列直接相关,而不是间接相关)

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关，消除字段冗余。

一个UserID依赖于CardID和StudentID，而一个Role依赖于CardID，这就是传递依赖间接相关，第三范式就是要消除这种依赖，我们可以改进为下图：

和

凡是都有利弊,贵在把握的粒度，由于范式的设计使后期我们的查询遇到了很大的麻烦，操作困难，例如上下机记录：学号、卡号、学生姓名等字段需要从多个数据表中来读取得需要从多个表调出数据，而且范式越高灵活性能就会越差，到达三个范式就可以了，有利于数据的管理

总结:

数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。