数据库难懂

㈠ 大家为什么都说说OceanBase4.0开启了国产数据库新的里程碑

OceanBase 4.0重新审视数据库与分布式系统两个领域最基础的设计，全新推出业内首个单机分布式一体化架构。在单机部署时，自适应日志流技术将只触发一个日志流，用户操作不需要分布式事务，不损失性能。需要分布式部署时，自适应日志流技术将会为每台机器触发专属的日志流。实现多机性能自动扩展。可以说OceanBase 4.0打破了分布式技术的不可能，实现了首个单机分布式体化架构，真正做到可以像单机数据库一样使用。

针对这一现状，有这么一群人从开始放弃了在互联网大厂的高薪工作，历经十余年在分布式数据库的深耕取得了一个又一个突破。从0到1开创原生分布式数据库，坚持自主研发，坚持长期主义，坚持开放，从根本上去解决海量数据管理的问题。历经12年时间，OceanBase4.0通过海量的业务场景打磨，产品不断选代，使用成本得到极大降低，部署更加便捷。OceanBase4.0开启了国产数据库新的里程碑。可单机可分布，可大可小，跟火影忍者一样，可合体可分散。

在成本上比传统数据库低50-70%大大降低中小企业的替换成本近年来数字经济迅猛发展，中小企业更加迫切的需要进行数字化转型。如何降低数字化进程中的成本，不仅是中小企业考虑的重要问题，也是OceanBase力求达到的目的。基于LSM-Tree的高压缩引擎，OceanBase 4.0实现存储成本降低70%-90%；以支付宝为例，用OceanBase原生分布式数据库替代Oracle数据库之后，单副本数据可以做到Oracle的1/7，其计算资源投入也降低为原来的1/12，相比Oracle，仅存储一项，相比Oracle节省存储成本约20亿元，相当于每账户成本节省了90%。

首次将故障恢复时间从30秒降低到8秒现在的数据中心对业务的连续性有苛刻要求，但是故障往往是不可避免的。一旦发生了故障就需要启动备份机制，确保业务的连续性。OceanBase4.0首次实现了RTO<8s，真正将故障恢复时间从分钟级（30s）降低到秒级（8s），帮助业务系统更快恢复，最大程度减少业务影响，给业务带来持续可用的能力。

㈡ 求数据库应用题

数据库语言的目标

要说清这个目标，先要理解数据库是做什么的。

数据库这个软件，名字中有个“库”字，会让人觉得它主要是为了存储的。其实不然，数据库实现的重要功能有两条：计算、事务！也就是我们常说的 OLAP 和 OLTP，数据库的存储都是为这两件事服务的，单纯的存储并不是数据库的目标。

我们知道，SQL 是目前数据库的主流语言。那么，用 SQL 做这两件事是不是很方便呢？

事务类功能主要解决数据在写入和读出时要保持的一致性，实现这件事的难度并不小，但对于应用程序的接口却非常简单，用于操纵数据库读写的代码也很简单。如果假定目前关系数据库的逻辑存储模式是合理的（也就是用数据表和记录来存储数据，其合理性与否是另一个复杂问题，不在这里展开了），那么 SQL 在描述事务类功能时没什么大问题，因为并不需要描述多复杂的动作，复杂性都在数据库内部解决了。

但计算类功能却不一样了。

这里说的计算是个更广泛的概念，并不只是简单的加加减减，查找、关联都可以看成是某种计算。

什么样的计算体系才算好呢？

还是两条：写着简单、跑得快。

写着简单，很好理解，就是让程序员很快能写出来代码来，这样单位时间内可以完成更多的工作；跑得快就更容易理解，我们当然希望更短时间内获得计算结果。

其实 SQL 中的 Q 就是查询的意思，发明它的初衷主要是为了做查询（也就是计算），这才是 SQL 的主要目标。然而，SQL 在描述计算任务时，却很难说是很胜任的。

SQL为什么不行

先看写着简单的问题。

SQL 写出来很象英语，有些查询可以当英语来读和写（网上多得很，就不举例了），这应当算是满足写着简单这一条了吧。

且慢！我们在教科书上看到的 SQL 经常只有两三行，这些 SQL 确实算是写着简单的，但如果我们尝试一些稍复杂化的问题呢？

这是一个其实还不算很复杂的例子：计算一支股票最长连续上涨了多少天？用 SQL 写出来是这样的：

• selectmax(consecutive_day)from(selectcount(*) (consecutive_dayfrom(selectsum(rise_mark) over(orderbytrade_date) days_no_gainfrom(selecttrade_date,case when closing_price>lag(closing_price) over(order by trade_date)then 0 else 1 END rise_markfrom stock_price ) )group by days\_no\_gain)



这个语句的工作原理就不解释了，反正有点绕，同学们可以自己尝试一下。

这是润乾公司的招聘考题，通过率不足 20%；因为太难，后来被改成另一种方式：把 SQL 语句写出来让应聘者解释它在算什么，通过率依然不高。

这说明什么？说明情况稍有复杂，SQL 就变得即难懂又难写！

再看跑得快的问题，还是一个经常拿出来的简单例子：1 亿条数据中取前 10 名。这个任务用 SQL 写出来并不复杂：

• SELECTTOP 10x FROMT ORDERBYx DESC



但是，这个语句对应的执行逻辑是先对所有数据进行大排序，然后再取出前 10 个，后面的不要了。大家知道，排序是一个很慢的动作，会多次遍历数据，如果数据量大到内存装不下，那还需要外存做缓存，性能还会进一步急剧下降。如果严格按这句 SQL 体现的逻辑去执行，这个运算无论如何是跑不快的。然而，很多程序员都知道这个运算并不需要大排序，也用不着外存缓存，一次遍历用一点点内存就可以完成，也就是存在更高性能的算法。可惜的是，用 SQL 却写不出这样的算法，只能寄希望于数据库的优化器足够聪明，能把这句 SQL 转换成高性能算法执行，但情况复杂时数据库的优化器也未必靠谱。

看样子，SQL 在这两方面做得都不够好。这两个并不复杂的问题都是这样，现实中数千行的 SQL 代码中，这种难写且跑不快的情况比比皆是。

为什么 SQL 不行呢？

要回答这个问题，我们要分析一下用程序代码实现计算到底是在干什么。

本质上讲，编写程序的过程，就是把解决问题的思路翻译成计算机可执行的精确化形式语言的过程。举例来说，就象小学生解应用题，分析问题想出解法之后，还要列出四则运算表达式。用程序计算也是一样，不仅要想出解决问题的方法，还要把解法翻译成计算机能理解执行的动作才算完成。

用于描述计算方法的形式语言，其核心在于所采用的代数体系。所谓代数体系，简单说就是一些数据类型和其上的运算规则，比如小学学到的算术，就是整数和加减乘除运算。有了这套东西，我们就能把想做的运算用这个代数体系约定的符号写出来，也就是代码，然后计算机就可以执行了。

如果这个代数体系设计时考虑不周到，提供的数据类型和运算不方便，那就会导致描述算法非常困难。这时候会发生一个怪现象：翻译解法到代码的难度远远超过解决问题本身。

举个例子，我们从小学习用阿拉伯数字做日常计算，做加减乘除都很方便，所有人都天经地义认为数值运算就该是这样的。其实未必！估计很多人都知道还有一种叫做罗马数字的东西，你知道用罗马数字该怎么做加减乘除吗？古罗马人又是如何上街买菜的？

代码难写很大程度是代数的问题。

再看跑不快的原因。

软件没办法改变硬件的性能，CPU 和硬盘该多快就是多快。不过，我们可以设计出低复杂度的算法，也就是计算量更小的算法，这样计算机执行的动作变少，自然也就会快了。但是，光想出算法还不够，还要把这个算法用某种形式语言写得出来才行，否则计算机不会执行。而且，写起来还要比较简单，都要写很长很麻烦，也没有人会去用。所以呢，对于程序来讲，跑得快和写着简单其实是同一个问题，背后还是这个形式语言采用的代数的问题。如果这个代数不好，就会导致高性能算法很难实现甚至实现不了，也就没办法跑得快了。就象上面说的，用 SQL 写不出我们期望的小内存单次遍历算法，能不能跑得快就只能寄希望于优化器。

我们再做个类比：

上过小学的同学大概都知道高斯计算 1+2+3+…+100 的小故事。普通人就是一步步地硬加 100 次，高斯小朋友很聪明，发现 1+100=101、2+99=101、…、50+51=101，结果是 50 乘 101，很快算完回家午饭了。

听过这个故事，我们都会感慨高斯很聪明，能想到这么巧妙的办法，即简单又迅速。这没有错，但是，大家容易忽略一点：在高斯的时代，人类的算术体系（也是一个代数）中已经有了乘法！象前面所说，我们从小学习四则运算，会觉得乘法是理所当然的，然而并不是！乘法是后于加法被发明出来的。如果高斯的年代还没有乘法，即使有聪明的高斯，也没办法快速解决这个问题。

目前主流数据库是关系数据库，之所以这么叫，是因为它的数学基础被称为关系代数，SQL 也就是关系代数理论上发展出来的形式语言。

现在我们能回答，为什么 SQL 在期望的两个方面做得不够好？问题出在关系代数上，关系代数就像一个只有加法还没发明乘法的算术体系，很多事做不好是必然的。

关系代数已经发明五十年了，五十年前的应用需求以及硬件环境，和今天比的差异是很巨大了，继续延用五十年前的理论来解决今天的问题，听着就感觉太陈旧了？然而现实就是这样，由于存量用户太多，而且也还没有成熟的新技术出现，基于关系代数的 SQL，今天仍然是最重要的数据库语言。虽然这几十年来也有一些改进完善，但根子并没有变，面对当代的复杂需求和硬件环境，SQL 不胜任也是情理之中的事。

而且，不幸的是，这个问题是理论上的，在工程上无论如何优化也无济于事，只能有限改善，不能根除。不过，绝大部分的数据库开发者并不会想到这一层，或者说为了照顾存量用户的兼容性，也没打算想到这一层。于是，主流数据库界一直在这个圈圈里打转转。

SPL为什么能行

那么该怎样让计算写着更简单、跑得更快呢？

发明新的代数！有“乘法”的代数。在其基础上再设计新的语言。

这就是 SPL 的由来。它的理论基础不再是关系代数，称为离散数据集。基于这个新代数设计的形式语言，起名为SPL（Structured Process Language)。

SPL 针对 SQL 的不足（更确切地说法是，离散数据集针对关系代数的各种缺陷）进行了革新。SPL 重新定义了并扩展许多结构化数据中的运算，增加了离散性、强化了有序计算、实现了彻底的集合化、支持对象引用、提倡分步运算。

限于篇幅，这里不能介绍 SPL（离散数据集）的全貌。我们在这里列举 SPL（离散数据集）针对 SQL（关系代数）的部分差异化改进：

游离记录

离散数据集中的记录是一种基本数据类型，它可以不依赖于数据表而独立存在。数据表是记录构成的集合，而构成某个数据表的记录还可以用于构成其它数据表。比如过滤运算就是用原数据表中满足条件的记录构成新数据表，这样，无论空间占用还是运算性能都更有优势。

关系代数没有可运算的数据类型来表示记录，单记录实际上是只有一行的数据表，不同数据表中的记录也不能共享。比如，过滤运算时会复制出新记录来构成新数据表，空间和时间成本都变大。

特别地，因为有游离记录，离散数据集允许记录的字段取值是某个记录，这样可以更方便地实现外键连接。

有序性

关系代数是基于无序集合设计的，集合成员没有序号的概念，也没有提供定位计算以及相邻引用的机制。SQL 实践时在工程上做了一些局部完善，使得现代 SQL 能方便地进行一部分有序运算。

离散数据集中的集合是有序的，集合成员都有序号的概念，可以用序号访问成员，并定义了定位运算以返回成员在集合中的序号。离散数据集提供了符号以在集合运算中实现相邻引用，并支持针对集合中某个序号位置进行计算。

有序运算很常见，却一直是 SQL 的困难问题，即使在有了窗口函数后仍然很繁琐。SPL 则大大改善了这个局面，前面那个股票上涨的例子就能说明问题。

离散性与集合化

关系代数中定义了丰富的集合运算，即能将集合作为整体参加运算，比如聚合、分组等。这是 SQL 比 Java 等高级语言更为方便的地方。

但关系代数的离散性非常差，没有游离记录。而 Java 等高级语言在这方面则没有问题。

离散数据集则相当于将离散性和集合化结合起来了，既有集合数据类型及相关的运算，也有集合成员游离在集合之外单独运算或再组成其它集合。可以说 SPL 集中了 SQL 和 Java 两者的优势。

有序运算是典型的离散性与集合化的结合场景。次序的概念只有在集合中才有意义，单个成员无所谓次序，这里体现了集合化；而有序计算又需要针对某个成员及其相邻成员进行计算，需要离散性。

在离散性的支持下才能获得更彻底的集合化，才能解决诸如有序计算类型的问题。

离散数据集是即有离散性又有集合化的代数体系，关系代数只有集合化。

分组理解

分组运算的本意是将一个大集合按某种规则拆成若干个子集合，关系代数中没有数据类型能够表示集合的集合，于是强迫在分组后做聚合运算。

离散数据集中允许集合的集合，可以表示合理的分组运算结果，分组和分组后的聚合被拆分成相互独立的两步运算，这样可以针对分组子集再进行更复杂的运算。

关系代数中只有一种等值分组，即按分组键值划分集合，等值分组是个完全划分。

离散数据集认为任何拆分大集合的方法都是分组运算，除了常规的等值分组外，还提供了与有序性结合的有序分组，以及可能得到不完全划分结果的对位分组。

聚合理解

关系代数中没有显式的集合数据类型，聚合计算的结果都是单值，分组后的聚合运算也是这样，只有 SUM、COUNT、MAX、MIN 等几种。特别地，关系代数无法把 TOPN 运算看成是聚合，针对全集的 TOPN 只能在输出结果集时排序后取前 N 条，而针对分组子集则很难做到 TOPN，需要转变思路拼出序号才能完成。

离散数据集提倡普遍集合，聚合运算的结果不一定是单值，仍然可能是个集合。在离散数据集中，TOPN 运算和 SUM、COUNT 这些是地位等同的，即可以针对全集也可以针对分组子集。

SPL 把 TOPN 理解成聚合运算后，在工程实现时还可以避免全量数据的排序，从而获得高性能。而 SQL 的 TOPN 总是伴随 ORDER BY 动作，理论上需要大排序才能实现，需要寄希望于数据库在工程实现时做优化。

有序支持的高性能

离散数据集特别强调有序集合，利用有序的特征可以实施很多高性能算法。这是基于无序集合的关系代数无能为力的，只能寄希望于工程上的优化。

下面是部分利用有序特征后可以实施的低复杂度运算：

1) 数据表对主键有序，相当于天然有一个索引。对键字段的过滤经常可以快速定位，以减少外存遍历量。随机按键值取数时也可以用二分法定位，在同时针对多个键值取数时还能重复利用索引信息。

2) 通常的分组运算是用 HASH 算法实现的，如果我们确定地知道数据对分组键值有序，则可以只做相邻对比，避免计算 HASH 值，也不会有 HASH 冲突的问题，而且非常容易并行。

3) 数据表对键有序，两个大表之间对位连接可以执行更高性能的归并算法，只要对数据遍历一次，不必缓存，对内存占用很小；而传统的 HASH 值分堆方法不仅比较复杂度高，需要较大内存并做外部缓存，还可能因 HASH 函数不当而造成二次 HASH 再缓存。

4) 大表作为外键表的连接。事实表小时，可以利用外键表有序，快速从中取出关联键值对应的数据实现连接，不需要做 HASH 分堆动作。事实表也很大时，可以将外键表用分位点分成多个逻辑段，再将事实表按逻辑段进行分堆，这样只需要对一个表做分堆，而且分堆过程中不会出现 HASH 分堆时的可能出现的二次分堆，计算复杂度能大幅下降。

其中 3 和 4 利用了离散数据集对连接运算的改造，如果仍然延用关系代数的定义（可能产生多对多），则很难实现这种低复杂的算法。

除了理论上的差异， SPL 还有许多工程层面的优势，比如更易于编写并行代码、大内存预关联提高外键连接性能等、特有的列存机制以支持随意分段并行等。

再把前面的问题用 SPL 重写一遍有个直接感受。

一支股票最长连续上涨多少天：

• stock_price.sort(trade_date).group@o(closing_price



计算思路和前面的 SQL 相同，但因为引入了有序性后，表达起来容易多了，不再绕了。

1 亿条数据中取前 10 名：

• T.groups(;top(-10,x))



SPL 有更丰富的集合数据类型，容易描述单次遍历上实施简单聚合的高效算法，不涉及大排序动作。

这里还有更多 SPL 代码以体现其思路及大数据算法：

重磅！开源SPL交流群成立了

简单好用的SPL开源啦！

为了给感兴趣的小伙伴们提供一个相互交流的平台，

特地开通了交流群（群完全免费，不广告不卖课）

需要进群的朋友，可长按扫描下方二维码

㈢ 数据库三大范式究竟是什么

数据库范式1NF 2NF 3NF BCNF(实例）
设计范式（范式,数据库设计范式,数据库的设计范式）是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。关系数据库中的关系必须满足一定的要求，即满足不同的范式。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式（3NF）就行了。下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。这样可能使数据库产生重复数据，从而导致创建多余的表。范化是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。
下面是范化的一个例子 Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25
如果上面这个表用于保存物品的价格，而你想要删除其中的一个顾客，这时你就必须同时删除一个价格。范化就是要解决这个问题，你可以将这个表化为两个表，一个用于存储每个顾客和他所买物品的信息，另一个用于存储每件产品和其价格的信息，这样对其中一个表做添加或删除操作就不会影响另一个表。
关系数据库的几种设计范式介绍

1 第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。

2 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。

3 第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。
数据库设计三大范式应用实例剖析
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
设计范式是不是很难懂呢？非也，大学教材上给我们一堆数学公式我们当然看不懂，也记不住。所以我们很多人就根本不按照范式来设计数据库。
实质上，设计范式用很形象、很简洁的话语就能说清楚，道明白。本文将对范式进行通俗地说明，并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。
范式说明
第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
例如，如下的数据库表是符合第一范式的：
字段1 字段2 字段3 字段4
而这样的数据库表是不符合第一范式的：

字段1 字段2 字段3 字段4
字段3.1 字段3.2
很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
这个数据库表不满足第二范式，因为存在如下决定关系：
(课程名称) → (学分)
(学号) → (姓名, 年龄)
即存在组合关键字中的字段决定非关键字的情况。
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
学生：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
选课关系：SelectCourse(学号, 课程名称, 成绩)。
这样的数据库表是符合第二范式的， 消除了数据冗余、更新异常、插入异常和删除异常。
另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。
第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：
关键字段 → 非关键字段x → 非关键字段y
假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。
把学生关系表分为如下两个表：
学生：(学号, 姓名, 年龄, 所在学院)；
学院：(学院, 地点, 电话)。
这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。
鲍依斯-科得范式（BCNF）：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：
(1) 删除异常：
当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常：
当仓库没有存储任何物品时，无法给仓库分配管理员。
(3) 更新异常：
如果仓库换了管理员，则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表：
仓库管理：StorehouseManage(仓库ID, 管理员ID)；
仓库：Storehouse(仓库ID, 存储物品ID, 数量)。
这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
范式应用
我们来逐步搞定一个论坛的数据库，有如下信息：
（1） 用户：用户名，email，主页，电话，联系地址
（2） 帖子：发帖标题，发帖内容，回复标题，回复内容
第一次我们将数据库设计为仅仅存在表：
用户名 email 主页 电话 联系地址 发帖标题 发帖内容 回复标题 回复内容
这个数据库表符合第一范式，但是没有任何一组候选关键字能决定数据库表的整行，唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段，即将表修改为：
用户名 email 主页 电话 联系地址 发帖ID 发帖标题 发帖内容 回复ID 回复标题 回复内容
这样数据表中的关键字(用户名，发帖ID，回复ID)能决定整行：
(用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容)
但是，这样的设计不符合第二范式，因为存在如下决定关系：
(用户名) → (email,主页,电话,联系地址)
(发帖ID) → (发帖标题,发帖内容)
(回复ID) → (回复标题,回复内容)
即非关键字段部分函数依赖于候选关键字段，很明显，这个设计会导致大量的数据冗余和操作异常。
我们将数据库表分解为（带下划线的为关键字）：
（1） 用户信息：用户名，email，主页，电话，联系地址
（2） 帖子信息：发帖ID，标题，内容
（3） 回复信息：回复ID，标题，内容
（4） 发贴：用户名，发帖ID
（5） 回复：发帖ID，回复ID
这样的设计是满足第1、2、3范式和BCNF范式要求的，但是这样的设计是不是最好的呢？
不一定。
观察可知，第4项"发帖"中的"用户名"和"发帖ID"之间是1：N的关系，因此我们可以把"发帖"合并到第2项的"帖子信息"中；第5项"回复"中的"发帖ID"和"回复ID"之间也是1：N的关系，因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余，新的设计为：
（1） 用户信息：用户名，email，主页，电话，联系地址
（2） 帖子信息：用户名，发帖ID，标题，内容
（3） 回复信息：发帖ID，回复ID，标题，内容
数据库表1显然满足所有范式的要求；
数据库表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖，即不满足第二范式的要求，但是这一设计并不会导致数据冗余和操作异常；
数据库表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖，也不满足第二范式的要求，但是与数据库表2相似，这一设计也不会导致数据冗余和操作异常。
由此可以看出，并不一定要强行满足范式的要求，对于1：N关系，当1的一边合并到N的那边后，N的那边就不再满足第二范式了，但是这种设计反而比较好！
对于M：N的关系，不能将M一边或N一边合并到另一边去，这样会导致不符合范式要求，同时导致操作异常和数据冗余。
对于1：1的关系，我们可以将左边的1或者右边的1合并到另一边去，设计导致不符合范式要求，但是并不会导致操作异常和数据冗余。
结论
满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的，在数据库表中存在1：1或1：N关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。
在我们设计数据库的时候，一定要时刻考虑范式的要求。
__________________________________________________________________
应该是第二种说法，只听说过1NF,2NF,3NF这么分的，我大学教科书上也这么写的