三范式数据库设计和反范式的思考(转)

约定不等于承诺〃 2022-08-06 01:28 275阅读 0赞

当我们拿到一个新的需求，我们把需求从头到尾搞清楚 后，就开始画流程图—>用例图—->设计数据库—->进入开发阶段—->编码—->测试—–>项目上线，至此一个项 目就算完成。

在这里我们只对设计数据库的这一块的范例进行讨论。提到范例，大家都知道第一范式，第二范式，第三范式。可是我们明白这些范式的深层含意吗？这些范式什么时候用，用它们有什么好处呢？下面我们就一起带着这些问题边想边读下面的文章。

**范式** ：英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程 中所要遵循的规则和指导方法。数据库的设计范式是数据库设计所需要满足的规范。只有理解数据库的设计范式，才能设计出高效率、优雅的数据库，否则可能会设 计出错误的数据库.目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。满足最低要求的叫第一范 式，简称1NF。在第一范式基础上进一步满足一些要求的为第二范式，简称2NF。其余依此类推。通常所用到的只是前三个范式，即：第一范式（1NF），第 二范式（2NF），第三范式（3NF）。下面就简单介绍下这三个范式。

◆ **第一范式（1NF）：** 强调的是列的原子性，即列不能够再分成其他几列。  
考虑这样一个表：【联系人】（姓名，性别，电话）  
如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 很好辨别，但是 2NF 和 3NF 就容易搞混淆。

◆ **第二范式（2NF）：** 首先要满足它是1NF，另外还需要包含两部分内容：一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。  
考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。  
因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。  
可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和 【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多 次重复的情况。

◆ **第三范式（3NF）：** 首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。  
考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。  
其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。  
通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。

**问：第二范式和第三范式如何区别？ **  
第二范式：非主键列是否依赖主键（包括一列通过某一列间接依赖主键），要是有依赖关系的就是第二范式；  
第三范式：非主键列是否是直接依赖主键，不能是那种通过传递关系的依赖的。要是符合这种就是第三范式；  
**问：范式的存在有什么好处？ **  
范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦。

范式再给我们带来的上面的好处时，同时也伴随着一些不好的地方：按照范式的规范设计出来的表，等级越高的范式设计出来的表越多。如第一范式可能设计 出来的表可能只有一张表而已，再按照第二范式去设计这张表时就可能出来两张或更多张表，如果再按第三范式或更高的范式去设计这张表会出现更多比第二范式多 的表。表的数量越多，当我们去查询一些数据，必然要去多表中去查询数据，这样查询的时间要比在一张表中查询中所用的时间要高很多。

也就是说我们所用的范式越高，对数据操作的性能越低。所以我们在利用范式设计表的时候，要根据具体的需求再去权衡是否使用更高范式去设计表。在一般的项目中，我们用的最多也就是第三范式，第三范式也就可以满足我们的项目需求，性能好而且方便管理数据；

当我们的业务所涉及的表非常多，经常会有多表发生关系，并且我们对表的操作要时间上要尽量的快，这时可以考虑我们使用“反范式”。反范式，故名思义，跟范式所要求的正好相反，在反范式的设计模式，我们可以允许适当的数据的冗余，用这个冗余去取操作数据时间的缩短。**也就是用空间来换取时间,把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联；**

如我们现在要对一个 学校的课程表进行操作，现在有两张表，一张是学生信息student（a\_id,a\_name,a\_adress,b\_id）表，一张是课程表 subject(b\_id,b\_subject)，现在我们需要一个这样的信息，把选择每个课程的的课程名称和学生姓名输出来：

SQL语句为：select  B.b\_id,B.b\_subject,A\_a\_name from student A ,subject B;

当上面的数据量不多时，我们这样去查询没有问题；当我们的两张表的数据都是在百万级的时候，我们去查上面的信息， 问题出现了，这个查询动不动就是几百毫秒，甚至更慢，这样的查询效率根本不能满足我们对于网页速度的要求（一般不能超过100毫秒），怎么办？当然要反范式，在课程表里面添加冗余字段——学生姓名，这样我们就可以通过下面的查询达到同样的目的：

SQL语句为：select  b\_id,b\_subject,a\_name from subject B;

将两个查询放在一起查看执行计划，就会发现，第一个查询开销占了92%，而第二个才8%，也就是说，第二个查询比起第一个查询，效率上优化了10倍以上，成果显著啊。

总结：

当我们开始着手一个项目后，范式的应用是这样的变化的：

第三范式数据库的设计—–>当数据量越来越大，达到百万级时，经常要对一些多表数据进行大范围高频率进行操作——->范式数据库的设计———->网站的数据量再持续增长———->范式和反范式的数据库设计

当我们的数据量非常大，目前除了对数据库的设计改动外，还可以通过对数据层进行缓存处理。如现在使用效果显著的Memcached ,一个分布式的缓存系统，我们将数据库信息以实体类的方式和图片文件等保存在Memcached里面，只要是可序列化的数据，经过装箱和拆箱，都可以保存 到Memcached中并随时可以快速的访问到这些对象，Memcached可以解决大量数据的缓存并保持多台Web Server得到的缓存数据是一致的。