关系数据库设计：谈谈规范化技术

最新推荐文章于 2024-10-12 06:00:00 发布

weixin_44519342

最新推荐文章于 2024-10-12 06:00:00 发布

阅读量232

点赞数

分类专栏：数据库文章标签： sql 数据库

原文链接：http://www.mark-to-win.com/tutorial/51663.html

版权

数据库专栏收录该内容

192 篇文章 8 订阅

订阅专栏

文章目录

    为什么需要规范化？
    第一范式
    第二范式
    第三范式
    反规范化
    关于外键
    总结

今天我们来聊聊关系数据库的规范化设计问题。本文不涉及数据库教材上晦涩难懂的各种公式，而是从实际应用出发，通过简单直白的方式介绍规范化的设计过程和常见范式。
为什么需要规范化？

很多教材和文章都是直接从第一范式开始介绍如何进行数据库设计，完全忽略了对事物前因后果的分析；从而导致我们看完之后，只知道要关系数据库要进行规范设计，但却不知道为什么要这么做。因此，我们首先来给大家介绍一下规范化之前发生了什么。

假设我们需要为某公司设计一个数据库，用于管理员工、部门、职位等相关的信息。首先从直观上考虑，可以将员工信息、所在部门以及职位信息存储到一个表中，如下图所示：
在这里插入图片描述
每一行数据对应一个员工的信息，包括他/她所在的部门、职位等。如果真的这么设计，我们在实际应用中很快就会发现以下各种问题：

数据冗余，同一个部门的信息存储了多份，这就需要占用更多的磁盘空间。另外，数据冗余有时候也可能是指在不同的表中存储了重复的信息；
插入异常，假如现在需要成立一个新的部门，由于还没有增加新的员工，因此无法录入这个部门的信息；
更新异常，如果需要修改某个部门信息，需要更新多行数据，效率低下；不小心忽略了某些记录的话，还会会导致数据不一致，尤其是当一个信息存储到多个表中时更容易出现这种情况。
删除异常，如果某个部门的所有员工都被删除，将会导致这个部门的信息也将不复存在；

关系数据库之父 Edgar F. Codd 显然意识到了这些问题，并且为此引入了规范化（Normalization）的设计过程。规范化使用范式（normal form）来定义和衡量，范式就是数据库设计时遵循的一种标准级别。Codd 最早提出了第一范式（1NF）、第二范式（2NF）以及第三范式（3NF），每个范式都基于前面的范式定义，例如第二范式需要先满足第一范式。

📝更高级别的范式包括 BC 范式（BCNF）、第四范式（4NF）、基本元组范式（ETNF）、第五范式（5NF）、DK 范式（DKNF）以及第六范式（6NF）；一般来说，满足第三范式的数据库就可以避免数据冗余和操作异常问题。

通过以上介绍，我们知道了规范化是数据库设计过程中的一系列原理和技术，使用范式来定义和衡量，主要用于减少表中数据的冗余，消除异常，提高数据完整性和一致性。

下面我们基上面的非规范化数据库结构，逐步介绍第一范式到第三范式的实现过程。
第一范式

第一范式（First Normal Form）要求满足以下条件：

表中的字段都是不可再分的单一属性;
表需要定义主键（PRIMARY KEY）。

简单来说，首先就是每个属性要有单独的字段。在上面的不规范设计中，员工的个人电话和工作电话存储在一个字段中，破坏了原子性。另外，还需要为表定义一个主键，用于唯一识别表中的每一行数据；假设每个部门中的员工不会同名，可以使用部门名称加员工姓名作为主键。

将上面的示例修改成以下结构就可以满足第一范式：
在这里插入图片描述

第一范式要求表中的字段具有不可分割的原子特性；不过我们知道，原子是化学反应不可再分的基本微粒，但在物理状态中可以分割，它是由原子核和绕核运动的电子组成。因此，我们同样需要考虑字段不可分割到底是针对什么而言。

例如，上面的“姓名”字段，实际上也可以拆分成两个字段：姓氏和名字。那么到达要不要拆分呢？显然这个取决于应用程序如何使用这些信息，一般我们将姓名作为一个字段存储；有些应用可能需要拆分，这样在给客户发送消息时可以方便地显示为“尊敬的刘先生/女生”。

另一个类似的情况是地址信息，例如“XX省XX市XX区XX小区”，存储到一个字段还是拆分成多个字段？大部分情况下，应用程序可能需要统计不同地区的用户情况，拆分成多个字段便于分析。不过这时候需要注意的是如何确保数据的标准化，因为不同的用户虽然住在相同的小区，但会输入不一致的数据；所以最好提供一组标准的数据，提供下拉列表给用于进行选择。

除了基本的数字、字符、日期等数据类型之外，SQL 还提供了一些复杂的类型，例如数组、XML、JSON 以及自定义类型等。假如我们使用一个 JSON 字段存储电话号码，数据如下所示：

{
“phoneNumbers”: [
{
“type”: “office”,
“number”: “61238888”
},
{
“type”: “mobile”,
“number”: “13612345678”
}
]
}

那么这种设计算不算违反第一范式？从定义来说这显然不属于第一范式，因为这个字段中包含了多个可以分割的属性。

但是，从 SQL 标准来说这些类型都属于原生类型，而且提供了对这种数据进行处理和查询的内置函数和方法；如果从应用程序的角度来看，例如电商平台中的产品信息、博客文章中的评论信息，可以将它们看作一个原子数据存储在 XML 或者 JSON 字段中，因为没有进行分割处理的需求。