数据库范式

 

最近的课程是讲数据库设计的三大范式，这里也简单说一下三大范式的浅显理解。

设计范式（范式,数据库设计范式,数据库的设计范式）是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。关系数据库中的关系必须满足一定的要求，即满足不同的范式。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式（3NF）就行了。下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
    在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。这样可能使数据库产生重复数据，从而导致创建多余的表。范化是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。

关系数据库的几种设计范式介绍

1 第一范式（1NF）

    在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
    所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如有一个人员信息表，里面有一个地址字段，如果字段的值是“中国广州”，那么我们认为不满足第一范式，因为里面包含了两个信息：国家和城市。所以需要将他们拆分为两个字段：国家   所在城市。这就符合了第一范式了。

2 第二范式（2NF）

    第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。

3 第三范式（3NF）

    满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。也就是说在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递依赖则符合第三范式。

数据库设计三大范式应用实例剖析

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

    第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

    例如，如下的数据库表是符合第一范式的：

    字段1 字段2 字段3 字段4

    而这样的数据库表是不符合第一范式的：    
    字段3.1 字段3.2 
    第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

    假定有一个描述客房的表room(房间号, 房间状态, 房间类型, 床位数, 入住人数, 价格)，关键字为组合关键字(房间号)，因为存在如下决定关系：
    (房间类型→ (床位数, 入住人数, 价格) 

    这个数据库表不满足第二范式，因为在这里面描述了三件事：客房信息，房间状态，房间类型。
    由于不符合2NF，这个客房表会存在如下问题：
    (1) 数据冗余：
    多间客房都是同一类型，床位数, 入住人数, 价格就重复n-1次；
    (2) 更新异常：
    若需要更新床位数或者入住人数或者价格，其它的值者一起更新，否则会出现同一客房类型价格不同的情况。
    (3) 插入异常：
    假设要需要增加一种客房类型，但是还没有决定房间号那就造成房间号为null，不能增加。造成插入异常。
    (4) 删除异常：
   假设某一间房需要另做他用，有可能删除了这一条数据的同时也删除了房间类型，造成类型的删除异常。

    把room改为如下三个表：
    客房：room(房间号, 房间状态id, 房间类型id, 床位数, 入住人数, 价格)；
    房间状态：roomState(状态ID, 状态名称)；
    房间类型：roomType(类型id,类型名称)。

    这样的数据库表是符合第二范式的， 消除了数据冗余、更新异常、插入异常和删除异常。
    另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。

第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：
    关键字段 → 非关键字段x → 非关键字段y ，我们刚刚看到的那个表已经符合第二范式了，但是他是否也符合第三范式呢？我们可以看到：
 客房：room(房间号, 房间状态id, 房间类型id, 床位数, 入住人数, 价格)；

这里面存在了这样的关系：

（客房号）→（客房类型）

（客房类型）→（床位数,价格），这就是传递依赖了。它不符合第三范式。   
    它也会存在数据冗余、更新异常、插入异常和删除异常的情况 

所有现最终我们把客房表为如下三个表：
    客房：room(房间号, 房间状态id, 房间类型id, 入住人数)；
    房间状态：roomState(状态ID, 状态名称)；
    房间类型：roomType(类型id,类型名称，床位数, , 价格)。 

    这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。

    满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的，在数据库表中存在1：1或1：N关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。
 在我们设计数据库的时候，一定要时刻考虑范式的要求。