数据库范式使用规范-Toy模板网

这篇具有很好参考价值的文章主要介绍了数据库范式使用规范。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

好的设计会尽可能少的引入冗余数据，或做有损拆分，而是使用规范的方法找到正确的分解。而范式则是关系数据库实现设计优化的通用手段。范式与关系数据库的关系可以参考笔者之前的WIKI。

【强制】数据库设计优先满足第三范式(3NF)，如果无法满足，则尽量满足第二范式(2NF)

在进行数据库设计时，如果能够满足第三范式，要尽量保证第三范式，如果因为性能考虑，需要冗余字段，无法满足第三范式的时候，也要尽量保证第二范式。

第一范式

当关系模式满足第一范式时，该关系模式所有属性的域都是原子的。第一范式要求表中列的值具有原子性，也就是说表中列的值为不可再次拆分的最小数据单位。常见的非原子域的情况有：
(1) 组合属性具有非原子域。如包含子属性street、city、state的属性address。
(2) 使用以集合为值的属性会导致冗余存储数据的设计，进而会进一步导致不一致。如数据库设计者可能不将教师和课程安排之间的联系表示为一个单独的关系teaches，而是尝试为每一个教师存储一个课程段标志号的集合，并为每一个课程段存储一个教师标志号的集合。每当关于哪位教师讲授哪个课程段的数据发生变化时，就需同时更新两个地方：课程表的教师集合和教师表课程集合。

第二范式

关系模式R属于第二范式，如果R中的每个属性A都满足如下准则之一：
(1) 它出现在一个候选码中。
(2) 它没有部分依赖于一个候选码。
函数依赖α $\rightarrow$ β称为部分依赖(partial dependency)的条件是，存在α的真子集γ使得γ $\rightarrow$ β。我们称β部分依赖于α。
第二范式要求表中的每条记录都有唯一标识，且不存在部分依赖。所谓部分依赖，就是指所有非唯一标识字段，都必须完全依赖唯一标识，不能只依赖唯一标识的一部分。如果知道唯一标识属性的值，就可以检索到任何表记录的任何属性的任何值。
假设有关系模型R，包含如下属性(学号、课程号、课程名、姓名、学分、成绩)，表示学生的课程得分，以学号和课程号为唯一标识，这里姓名属性只依赖学号，学分属性只依赖课程号，所以这里存在部分依赖，不符合第二范式的要求。
第二范式的核心思想是关系模型的内聚，也即拆分思想。对于上面的关系模型，可以进一步细分为如下几个关系模型：
学生表：(学号、姓名)
课程表：(课程号、课程名、学分)
学生课程成绩表：(学号、课程号、成绩)

第三范式

第三范式是比BC范式弱的范式。任何满足BC范式的关系模式也满足第三范式。具有函数依赖集F的关系模式R属于第三范式(third normal form)的条件是：对 $F^+$ 中所有形如α $\rightarrow$ β的函数依赖（α $\subseteq$ R且β $\subseteq$ R），下面至少有一项是成立：
(1) α $\rightarrow$ β是平凡的函数依赖(即β $\subseteq$ α)。
(2) α是模式R的一个超码。
(3) β - α中的每一个属性A都包含于R的一个候选码中。
第三范式要求表中的每一个非主键字段都和主键字段直接相关，也就是说，表中的所有非主键字段不能依赖于其他非主键字段。举例来说，不能存在非主属性A依赖于非主属性B，非主属性B依赖于主键C的情况，即存在"A->B->C"的依赖关系。也就是说，所有非主键属性之间不能有依赖关系，必须相互独立。
假设有关系模型R，包含如下属性(学号、姓名、年龄、学院、学院电话)，因为存在传递依赖：(学号) -> (姓名) -> (学院) -> (学院电话)，所以不符合第三范式的要求。
第三范式的核心思想是消除所有基于函数依赖能够发现的冗余并保持函数依赖。对于上面的关系模型，可以进一步细分为如下几个关系模型：
学生：(学号、姓名、年龄、学院)
学院：(学院、学院电话)

【建议】在遵循范式规则的同时，也要考虑反范式设计

软件设计没有银弹，并不是说在进行数据库设计时，一定要遵循范式，在特定的场景下，可以考虑反范式设计。

违反第一范式

第一范式强调属性的域的原子性，但是特殊情况下违反第一范式也有其价值。如在含有复杂结构的实体域中，强制使用第一范式会给应用程序带来不必要的负担，如必须编写代码把数据转换成原子形式。从原子形式来回转换数据也会有运行时额外开销。所以，这种场景支持非原子的值很有用。事实上，现代数据库的确支持很多类型的非原子值。如支持创建复合属性、集合、数组等复杂数据类型。

违反第三方式

第三范式强调的是没有冗余数据，因为如果存在冗余，就意味着要保证冗余数据的一致性。但是没有冗余的数据库未必是好的数据库。有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据，达到以空间换时间的目的。

参考

https://zhuanlan.zhihu.com/p/617424106 【MySQL】数据库的设计规范（重点：三大范式）
https://blog.csdn.net/kenhins/article/details/51084815 数据库建表规则（三大范式）
https://cloud.tencent.com/developer/article/2123662 三范式与反范式
https://blog.csdn.net/Systemoutprintl/article/details/108209291 数据库的三大范式
https://www.cnblogs.com/gdwkong/p/9012262.html MySQL设计之三范式的理解文章来源地址https://www.toymoban.com/news/detail-665976.html

到了这里，关于数据库范式使用规范的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！