范式设计和反范式设计 - SegmentFault 思否.pdf

张鹏

4页

0次

2024-06-13

免费下载

首页 / 专栏 / mysql / 文章详情

范式设计和反范式设计

一画先生发布于 1 月 5 日

数据表的设计和工作流程需要规范性。

范式是数据表设计的基本原则，很容易被忽视。很多时候，当数据库运行了一段时间之后，我们才发现数据表设计得有问题。重新调

整数据表的结构，可能需要做数据迁移，并且甚至可能会影响程序的业务逻辑。所以在开始设计数据库的时候，我们就需要重视数据

表的设计。

数据库的范式有哪些？

我们在设计关系型数据库模型的时候，需要对关系内部各个属性之间联系的合理化程度进行定义，这就有了不同等级的规范要求，这

些规范要求被称为范式（NF）——数据表的设计结构需要满足的某种设计标准的级别。

目前关系型数据库一共有6种范式，按照级别从低到高分别是：1NF（第一范式），2NF（第二范式），3NF（第三范式），

BCNF（巴斯-科德范式），4NF（第四范式），5NF（第五范式）.

数据库的范式设计越高阶，冗余度就越低，高阶范式一定满足低阶范式的要求。

数据表中的键

范式的定义会使用到主键和候选键（因为主键和候选键可以唯一标识元组），数据库种的键由一个或多个属性组成。

超键：能唯一标识元组的属性集叫做超键

候选键：如果超键不包括多余的属性，则这个超键就是候选键，就是说候选键一定是超键

主键：用户可以从候选键种选择其中一个作为主键

外键：如果数据表T1种的某属性集不是T1的主键，而是另外一张表T2的主键，那么这个属性集就是T1的外键

主属性：包含在任一候选键种的属性称为主属性

非主属性：跟主属性相对

从1NF到3NF

1NF是数据库表种的任何属性都是原子的，不可再分。

任何的DBMS都会满足1NF的要求，除非在设计的时候设计一个属性X，属性Y是X的前半段，属性Z是X的后半段，并且Y和Z没有什么

使用意义，我想应该没有人当这样的折磨王吧。

2NF要求数据表里的非主属性都要和这个数据表的候选键有完全依赖关系。

这里我举一个没有满足2NF的例子。

假设现在有一张球员比赛表，里面包含球员编号，姓名，年龄，比赛编号，比赛时间，比赛场地这些属性。这里的候选键和主键都是

（球员编号，比赛编号），可以通过这个候选键决定其他的属性：

（球员编号，比赛编号） → （姓名，年龄，比赛时间，比赛场地）。

但是这个表不满足2NF，因为还存在下面的关系：

（球员编号） → （姓名，年龄）

（比赛编号） → （比赛时间，比赛场地）

也就是说候选键的部分字段决定了非主属性，那这样会产生什么问题？

1. 数据冗余：球员可以参加多场比赛，那么球员的姓名和年龄就重复了多次。同样，一场比赛有多个球员参与，比赛时间和比赛

场地就重复了多次。

2. 插入异常：联盟新增了新球员，但是还在休赛期，比赛相关的字段就插入异常。就是候选键部分字段以及他们决定的非主属性

有数据，但是候选键其他部分的字段以及其他非主属性还未产生数据时，就插入异常。

3. 删除异常：如果有一场比赛只有一个球员参与，这个球员这个赛季退役了，删除这个球员的时候同时也删除了这场比赛了。

4. 更新异常：当一个球员的年龄变化了，需要更新这个球员参加的所有比赛的行。

5. 总的来说，第1个问题导致了后面3个问题，因为数据冗余，导致数据的增删改查都不对劲。

为满足2NF改正：

将这张表分为3张表

player：球员编号，姓名，年龄，队伍

game：比赛编号，比赛时间，比赛场地

player_game：比赛编号，参赛球员编号，参赛球员得分

将刚才不满足2NF的关系拆分成不同的表，并且使用第3张表进行链接他们。这样每一张表都满足2NF。

3NF在满足2NF的同时，对任何非主属性都不传递依赖于候选键

举个例子，现在有个cdn_load的表，其中有自增主键id，时间戳event_timestamp，资源类型cdn_type，加载该资源的页面名称

page_name，是不是游戏平台的域名is_game_platform，域名还是具体的链接url_type。

候选键有：（id）和（event_timestamp, cdn_type, page_name, url）

选择id作为主键时

有以上依赖关系

左边这个关系中，主键id可以决定event_timestamp，url，is_game_platform，但是这里有一个非主属性决定了另一个非主属性，url

可以决定is_game_platform，所以is_game_platform通过url传递依赖主键id。

同样右边的关系中，url_type通过url传递依赖主键id。

其实is_game_platform和url_type可以不存入DB，删除is_game_platform和url_type，直接通过程序计算所得即可，这样就满足了

3NF。

如果一定要这两个字段并且一定要满足3NF，那么拆分成两张表

cdn_request：除去is_game_platform和url_type的其他字段。

url_info：url，is_game_platform，url_type

这样两张表都满足3NF。

反范式设计

尽管围绕着数据表的设计有很多范式，但事实上我们在设计数据表的时候却不一定要参照这些标准。

我们知道越高阶的范式，数据冗余越低，但是有时候，我们在设计数据表的时候，还需要为了性能和读取效率违反范式原则。换句话

说，就是允许少量的冗余，通过空间换时间。

比如博客评论这个场景

假设设计有以下两张表：

comment：comment_id/blog_id/comment_text/time/user_id

user_id：user_id/user_name/create_time

因为在评论表中，我们不会只展示用户id，会展示用户的名称，所以查询评论列表的时候，需要连表查询，增加耗时。

0 条评论

得票 • 时间