数据库设计范式

1. 数据库设计范式概述

　　在设计数据库时，要遵循的规范就是设计范式。

　　设计关系型数据库时，要遵循不同的规范，设计出合理的数据库。

　　目前设计范式有第一范式(1NF)到第六范式(6NF)六个等级的范式，每个范式都是呈递次规范，要做到下一范式需要先实现上一级范式(就像俄罗斯套娃似的，虽然这么比喻不是很恰当)。

　　主流的是第一范式、第二范式、第三范式，只要实现了前三个范式，基本上可以称得上是一个合理、高效且安全的数据库。因为后三种范式较为严苛，故暂不讨论。

 

2. 第一范式

　　(1) 要求

　　1) 第一范式是关系型数据库的基础，只要是不符合第一范式，就称不上关系型数据库。

　　2) 第一范式的要求是，每一列的属性都是不可分割的基本数据项，表中的属性不能有可以拆分的属性。如果出现重复的属性，就需要重新定义一个新的实体，新的实体由重复的属性构成。

　　3) 总而言之，第一范式就是禁止重复的列存在，一个实体的数据在表中只能出现一次。

　　(2) 缺陷

　　1) 存在严重的数据冗余(复用性低，不知道比喻的合不合适)。

　　2) 部分属性要加入新的数据，但又无法构成一个实体时无法增加。

　　3) 删除一个实体可能导致其他属性的丢失。

 

3. 第二范式

　　(1) 要求

　　1) 第二范式是基于第一范式的规范。

　　2) 要求数据库表中的每个实例或行必须可以被唯一地区分。要用一个单独的列来存储每个实体的唯一标识。这个唯一标识就是主键或者叫主码。

　　3) 实体的属性完全依赖于主键，不能存在仅依赖主键一部分的属性。

　　如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体。

　　4) 第二范式就是要消除部分依赖。

　　(2) 关键名词

　　1) 函数依赖：通过A属性值或一些属性可以确定唯一的B属性值，那就是B依赖于A。

　　2) 完全函数依赖：A是属性组，B属性值的确定需要依赖于A中的全部属性值。

　　3) 部分函数依赖：A是属性组，B属性值的确定只要A属性组中的一部分就可以确定。

　　4) 传递函数依赖：如果B依赖于A，C依赖于B，C也依赖于A，C能被A确定。

　　5) 码：一个属性或属性组被其他所有属性完全依赖，称之为该表的码。

　　6) 主属性：码中的所有属性。

　　7) 非主属性：除码以外的属性。

　　(3) 缺陷

　　虽然解决了第一范式中数据冗余问题，但是剩余的两个问题依旧没有解决。

　　1) 部分属性要加入新的数据，但又无法构成一个实体时无法增加。

　　2) 删除一个实体可能导致其他属性的丢失。

 

4. 第三范式

　　(1) 要求

　　1) 第三范式是基于第二范式的规范。

　　2) 一个数据库表中不包含已在其它表中包含的非主关键字信息。

　　3) 任何非主属性不依赖于其他非主属性，就是要消除传递依赖。

　　(2) 解决问题

　　解决了第二范式残留下来的两个问题。提高了数据的独立性。