MySQL教程（基础篇）之数据库设计范式及应用举例

常用术语

在这个地方，我们可能就需要接触到一些常用的术语了。虽然我们在前面已经介绍过了，这里我们再回顾一下：

• 数据库（Database）：数据库是带有相关数据的表的集合。
• 表（Table）：表是带有数据的矩阵。数据库中的表就像一种简单的电子表格。
• 列（Column）：每一列（又可以称为属性）都包含着同种类型的数据。
• 行（Row）：行（又被称为元组、项或记录）是一组相关数据。可以理解为实例化一个类，而这个类所具有的属性值。
• 实体： 每一类数据对象的个体称为实体。例如一种用户表中，用户就是一个实体，而名字，电话等就是属性。
• 冗余（Redundancy）：存储两次数据，以便使系统更快速。
• 主键（Primary Key）：主键是唯一的。同一张表中不允许出现同样两个键值。一个键值只对应着一行。
• 外键（Foreign Key）：用于连接两张表。
• 复合键（Compound Key）：复合键（又称组合键）是一种由多列组成的键，因为一列并不足以确定唯一性。
• 索引（Index）：它在数据库中的作用就像书后的索引一样。
• 引用完整性（Referential Integrity）：用来确保外键一直指向已存在的一行。

数据库范式

当我们想要设计出合理的关系型数据库时，需要遵从不同的规范要求，这些不同的规范要求就被称为范式。各种范式呈递次规范，越高的范式数据库冗余程度越小。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。但是在实际的使用中，我们只需要了解前三个范式，也就是我们常说的“数据库三范式”。

第一范式
第一范式要求所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。也就是说，当实体中的某个属性有多个值时，必须拆分为不同的属性。可以理解为：第一范式就是无重复的列。

第二范式
第二范式是在第一范式的基础上进行的，所以说要满足第二范式就必须要满足第一范式。第二范式要求：数据库表中的每个实例必须可以被唯一地区分。即实体的属性完全依赖于主键。所谓完全依赖是指不能存在仅依赖主键一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体。例如：在用户表中我们可以使用用户的身份证来作为一个用户的唯一标识，但是如果没有身份证号这样的属性时，我们可以选择增加一个不可重复的属性userId来实现。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

第三范式
第三范式又是在第二范式的基础上进行的，更准确地说，第三范式应该是第二范式的一个子集。第三范式要求：任何非主属性不依赖于其它非主属性。简而言之，第三范式要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如：假设在学生表中应该包含：学院名，学院ID,学生姓名，学生学号。 那么假设还存在一张学院表：学院名，学院ID. 那么这种情况就是第三范式所不允许的，因为这样会使用数据具有大量的冗余。但如果不存在这样的学院表，根据第三范式，就需要创建这样的学院表，并删减学生表中的冗余字段。

应用举例

需求：假设我们现在需要设计一个小型电商平台的数据库，包含:用户名字，用户电话，商品价格，商品名字等属性。

第一步：那么我们就先建立一张用户表（用户名字，用户电话，商品价格，商品名字）可以看出我们列出来的属性中，并没有重复的，所以是符合第一范式（其实，对于现在的关系型数据库来说，想要不符合第一范式基本是不可能的事，因为当你在建表时，数据库也不允许你出现重复的属性）。
第二步：根据第二范式，我们需要依赖一个主键，所以我们创建一个唯一的属性：用户ID;这时间用户表中包含：用户ID，用户名字，用户电话，商品价格，商品名字。
第三步：但是我们发现，其实商品价格和商品名字并不是完全依赖于用户ID的（因为一个商品可以被多个用户购买），所以根据第三范式我们需要建立一个商品信息表（商品ID，商品价格，商品名字），同时也要具有主键：商品ID。这时，我们删除用户表中对应的属性。
第四步： 这时你或许会问，那么怎么知道那个用户买了什么商品啊？所以，我们就需要做一个用户和商品之间的映射表，购买记录表（购买记录ID,用户ID,商品ID）,同样具有主键：购买记录ID。
那么我们就成功创建了用户表（用户ID，用户名字，用户电话），商品信息表（商品ID，商品价格，商品名字），购买记录表（购买记录ID,用户ID,商品ID）来实现我们的需求。

注意事项

在实际的开发过程中，并不是一定需要符合三个数据库范式的，而是需要根据我们实际的项目情况来决定。在实际项目开发中，我们也会发现很多“花费时间节约空间”和“花费空间节约时间”的情况发生。