为了设计出冗余较小，结构合理的数据库，在设计数据库时应遵循哪些准则？
数据库设计只有遵循一定的规则，才能设计出冗余较小、结构合理的数据库，在关系数据库中，需要遵循的准则就是我们常说的三范式，要想设计出结构合理的关系型数据库，遵循3范式是最基本的要求。
在实际开发中，最常用的的三个基本准则如下：
1.第一范式—1NF（确保每列的原子性）
所谓第一范式（1NF）是指数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值；从实体的角度来讲，就是实体不能有重复的属性或者某个属性不能有多个值。如果一个实体出现重复的属性，就可能需要重新定义一个新的实体，新的实体由重复的属性组成。第一范式（1NF）要求数据库表中的每一行只包含一个实体的信息，简而言之，第一范式就是无重复的列。在任何一个关系型数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系型数据库。
第一范式的合理性需要根据系统的实际需求来确定。比如某些数据库系统中需要用到”地址”这个属性，本来直接将”地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问”地址”属性中的”城市”部分，那么就非要将”地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。
上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。
2.第二范式—2NF（属性完全依赖于主属性）
第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一的区分，要达到这一要求，就需要保证数据库表中的每一列都需要完全依赖于主键，而不是部分依赖于主键（针对联合主键而言）。为了实现唯一的区分，通常要为表加一个列，以存储各个实例的唯一标识。例如，员工信息表加上员工编号，因为每个员工的员工编号是唯一的，因此每个员工可以被唯一的区分。这个唯一的作为唯一标识的属性列称为主关键字或者主属性、主键、主码。第二范式（2NF）是在第一范式（1NF）的基础上建立的，因此要满足第二范式（2NF）就必须先满足第一范式（1NF）。
比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示：
那么问题来了：这个表中的订单编号和商品编号作为联合主键，但表中的商品名称、单位、数量等信息，仅仅部分依赖于商品编号，而不是完全依赖于联合主键，因此违反了第二范式（2NF）的设计原则。
3.第三范式—3NF（属性不依赖于其他非主属性）
第三范式（3NF）是在第二范式（2NF）的基础上建立的，同样的，要满足第三范式（3NF）就必须先满足第二范式（2NF）。第三范式（3NF）要求属性不依赖于其他非主属性，目的是消除传递依赖，简而言之，第三范式（3NF）要求一个数据库表中不包含已在其他表中存在的非关键字属性信息。
比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表：
这样查询时，就可以使用客户信息来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减少了数据冗余。
参考文章：
— EOF — 看完了，留个脚印 ^_^
