数据库设计

1.相关概念

（1）实体（entity）：我们用数据库要描述的对象，可以是具体的，也可以是抽象的。比如“一个学生”、“一本书”、“一门课”等等；当然也可以是“学生与老师的关系”。

（2）字段（fields）：就是我们看到的列（column），代表了我们要描述实体的属性。

（3）记录（record）：就是我们平常所说的行（row），代表了我们要描述不同的具体实体。

（4）码（key）：表中可以唯一确定一个元组的某个属性（或者属性组），我们在数据表中叫做键。

（5）主键（primary key）：用于唯一标识一个表中的一条记录的键。

（6）外键（foreign keys）：对连接父表和子表的相关记录的主键字段的复制。

（7）完全函数依赖（full functional dependency）：次属性完全依赖一个主属性，或者一个主属性组

（8）部分函数依赖（partial functional dependency）：次属性依赖于主属性组中的某一个属性

（9）依赖表（dependent table）：也称为弱实体（weak entity）是需要用父表标识的子表。

（10）关联表（associative table）：是多对多关系中两个父表的子表。

2.数据设计参考范式

2.1第一范式（1NF）：属性不可拆分



图2.1.1“邮箱”属性的值被分为两列，不符合第一范式。而图2.2.2“邮箱”的属性被分割，也不符合第一范式。更改后的图2.1.3则符合了第一范式，属性不可拆分。

2.2第二范式（2NF）：去除部分依赖，保留完全依赖

姓名	课程	分数	教材	价格
小王	英语	91	英语书	10
小魏	数学	85	数学书	9
小王	数学	96	数学书	9
小魏	语文	100	语文书	8
图2.2.1：符合第一范式，但不符合第二范式

现在我们有一张符合第一范式的表，但他仍然会给我们带来很多麻烦。

如果想要增加一门课程，如何操作？

姓名	课程	分数	教材	价格
小王	英语	91	英语书	10
小魏	数学	85	数学书	9
小王	数学	96	数学书	9
小魏	语文	100	语文书	8
	物理		物理书
	物理		物理书
	物理		物理书
图2.2.2：插入异常

每次插入“物理”都要插入一次“物理书”。而且，主要的“姓名”字段为空，这个叫插入异常。

姓名	课程	分数	教材	价格
小王	英语	91	英语书	10
小魏	数学	85	数学书	9
小王	数学	96	数学书	9
图2.2.3：删除异常

由于高年级不再需要“语文课”，那么我们先把含有“语文”的记录都删除掉，这个时候我们同样把“课程”和“教材”关系也删除了，我们就不知道“语文”这门课要用什么“教材”了。这个叫删除异常。

姓名	课程	分数	教材	价格
小王	英语	91	英语书	10
小魏	数学	85	数学书	9
小王	数学	96	数学书	9
小魏	语文	100	语文书	8
图2.2.4：更改异常

我们要把“数学书”这个教材换成“高级数学书”，那么所有的先关记录都要更改一遍，是不是很麻烦？这个叫更改异常。

为了解决上述三个问题，我们就引入了第二范式（2NF）

（姓名，课程）>>（分数）

（姓名，课程）>>（教材）

由于“姓名”和“课程”这两个字段能确定剩下的字段，我们就称这样的字段组合为“码”，而码中的每个字段我们称之为“主属性”。非码的字段我们称之为“次属性”。

我们注意到，在（姓名，课程）>>（教材）的这个关系中，存在（课程）>>（教材）。就是课程可以单独确定教材，那么“老师”这个字段，对“姓名”和“课程”键的依赖就叫做部分依赖（因为它部分依赖与组合键中的“课程”字段）。而“教室”、“时间”则完全依赖于“姓名”和“课程”的组合键。

通过拆分表，我们消除“部分依赖”。



上述三个问题是不是都解决了？在以后的学习中我们会学习到如何把两个表关联起来。

2.3第三范式（3NF）：符合2NF，并且消除“传递依赖”



每学期学校都会购书，而每年的书的价格都不一样，比如今年“数学书”涨价卖“11”块，我们就要把所有的含有数学书的记录的价格都更改一遍，还是存在异常？

在这里，“课程”>>“教材”>>“价格”，那么“价格”对“课程”就是“传递依赖”。这个时候我们需要把“课程”表再次拆分，消除“传递依赖”。



最终我们得到了满足三个范式的表格。即图2.3.1（拆分1）、图2.3.3（拆分3）、图2.3.4（拆分4）所组成的表格。



对比一下我们最初的表，是否很整洁呢？



3.结束语

数据库设计的三个范式是我们在设计数据库时可以参考的规则，但并不是我们必须要做的规范。所有的技术都要服务于我们的具体业务，而不应该为了好的技术而技术。

同样做数据库也是如此，比如如我我们是为了维护网站，或者做销售系统，主要是为了储存信息，即On-Line Transaction Processing联机事务处理过程（OLTP），三个范式则给我们提供了比较好的参考依据；但是我们如果只是为了做数据分析，即Online Analytical Processing联机分析处理过程（OLAP），则完全可以抛弃三个范式。