91_尚硅谷_业务数仓_范式理论

好，接下来呢，我们看一下这个2.3范式理论啊范式理论，那我们来看一下概念描述，关系型数据库设计时遵守一定的规范要求，关系型数据库通常指什么数据库？啊买或者or这种数据库啊啊，目的在于降低数据的有余性，目前业界范式有第一范式，第二范式，第三范式啊，什么巴斯克德范式，第四范式，第五范式啊一般多种范式，那么范式呢，你可以理解为是一张表数，呃数据表的表结构符合的设计标准的级别，满足哪一种要求原则。啊，这个意思。比如说第一范式，它满足的是这个叫属性不可切割，满足这一条条件啊，那第二范式呢，满足的是这个叫啊，不存在这个部分还依赖。啊，某满足某种规则，那它就符合了这个范式啊，属于一种要求哈，好，那下面来看使用范式的这个根本目的是什么？你说为什么我要定义这个范式，它能解决什么事？那如果你定义这个范式越高，那说明你遵守这个原则越多，那它就能减少数据的永离，尽量让每一个数据只出现一次。

啊，比如说什么呢？呃，比如说有一张有张表订单表，那在这个订单表里面，你看我们之前在这张表里描述的是不是把这个定商品ID放在里面了啊，还有这个用户ID放里面了。那他为啥不把这个商品信息放里面，用户用户信息也放在整个的订单里面去呢。那么大家问题如果都放在这里面，别个订单里面也有，突然间有一天我要改这个用户的信息。

那我是要改多少表啊，那如果你把这个用户信息抽取出来一张表。那是好，我的感觉信息是不是只在这里面改就行了，那你经常查我的时候，就用ID去查我这里面具体的信息是不是就OK了。哎，是这样的一个原因，那也说它减少了数据的冗余，尽量让每个数据只出现一次，你说改的时候是改一次。同时他还保证了数据的一致性，那这怎么理解呢？你这个订单，这个订单，然后这里面有用户信息，这里面也有用户信息，那有的时候你改这个订单，诶只在这个订单里面改了信息，这个忘忘改了。那就会导致这个数据不一致，风险很高，所以说尽量也是抽取出来啊，都抽取出一个一个的小表啊，然后日后呢，在用的时候再进行造影。啊，关联好，那它的缺点是什么呢？获取数据的时候需要交把它拼接在一起，通过某一个ID或者外键啊经过来在一起啊，这种方式好，那这是范式啊，大家初步了解一下啊，它有好处，一呢是减少了数据的冗余，尽量只要数据出现一次，另一方面呢，保证了数据的一致性啊好，那下面来看几个概念啊，第一个概念呢，叫函数依赖啊，讲真正的范式之前，先说一下函数依赖。

那来看这是一张。学生的表成绩表对吧？啊，他是某一个院系的啊，系主任是什么啊？课程是什么，每个课程呢，他得了多少分啊，左侧的这是学号。好，那首先看一下什么叫完全函数依赖，能看懂吗？直接有的是吧，啊，这是机器语言啊，来一个能看懂的啊，人类语言，人类语言，但是比如说通过这个学号和课程。

通过他和他，我们就能推出分数。能吧，比如说张三他的高等数学95分唯一标识啊，然后李四他的这个普通化学记六分能够唯一标识。对吧，啊，但是单独用学号推断公式分数，比如说我用这个这个。这是三个人，我这是一个人对吧，那他有这么多科，我单独说这个人能推出他得多少分吗？不能啊，那好，我单独说这个高等数学，高等数学这一学科我能推出多少分吗？因为它上面还有多少数学，我前面必须得指定唯一的学号。啊才能唯一的决定糖，那这种比如说学号和课程能推出分数，但是单独学号推断不出分数。

啊，单独课名也推断出分数，那我们就认为分数是完全依赖于学号和课程。啊，这叫完全还不一样。那从这个逻辑上讲的话，就是AB能得出C，但是呢，AB单独得出出C，那我们就说C是完全依赖于A。啊，看着比较绕啊，但是还好啊，这个理解起来，那下面来看部分函数一样，上来一看看不太懂，下面来看这个。人类语言，比如说通过学号和课程能够推出姓名。这学号课程能够推出姓名没问题吧，因为学号就能唯一的标识出姓名啊，好，那其实直接就可以通过学号推出姓名，所以这个姓名是部分依赖于学号课程，为什么是说呢？因为你学号和课名推出姓名，那我单独用课名能不能推出这个姓名呢？不能吧啊，推不出来，只是完全用这个学号能推出他。

那我们就认为这是姓名部分依赖于学号和课程。那通过这个物理表达式上啊，逻辑上说AB能得到C，通过AB也能得出C，或者通过B也能得出C，那我们就说C是部分依赖于AB，也是依赖于AB的一部分。啊，并不是全部的。那再来传递函数以外。人类与比如说通过学号能够推出姓名，学号能够推出你是哪个系的没问题，同时通过系名能够推出他的系主任，系名能够推出他的系主任叫什么名。但是系主任推出学号，比如说你这么推没问题，那从系主任往回推。

啊，系边它垂直系零，那系边往回推能推动吗？啊，得不出来这个对应的学号，那就说明系主任是传递函数依赖于学号。啊，相当于是一个传递的关系。那这里面对应的逻辑表达式A得到B，通过B得到C，但是C得不到啊，那么说C传递依赖于A。啊，这就是这个函数依赖这么三种啊，一个叫完全依赖，部分依赖，还有传递依赖啊三种，好，有了这三种的基本概念之后，下面我们来真正的去说一下这个范式啊，跟这函数依赖有关系啊，来看。300。那首先第一个第一范式的要求是。属性不可切割什么叫属性不可切割呢？来看一下，这是一张数据库里的表。

买生活数据的表，那这样做能不能满足我们日常的一个需求？很明显，上图所示的表格设计是不符合第一方式的。比如说商品列表中的数据不是原子数据项，什么叫原子？原子数不可切割呀，啊原不能切割的，那你看这条能不能切割。可以切割，那是五台电脑。那比如说你要这么去，请问兄弟的话，那张三说我要买这是五台电脑，没问题，李四我说我要买三台电脑。那这一条这一条就没法没法做了，对吧？啊没法做了，因为大家偶在一起了。那怎么办呢？哎，你可以把它拆开，拆开成商品，那比如说是电脑那数量是五，那我日后再更新这个数量的时候，那就容易多了啊，你买三台还是五台还是十台。

都可以进行搞定啊，啊，那这里面实际上一范式是所有关系数据库的最基本要求啊，最基本。必须满足的。啊，你在关于数据库系统中，比如说这个就是每色中创建数据表时，如果数据表的设计不符合这一最基本的要求，那么这个操作一定是不成功的，你说要求关联数据库是必须满足属性不可切割这一条。啊，但是目前啊，真的没有不满足这个啊，那这个就没法玩了啊啊这是第一般是技术是属性不可切割，那下边再来。那第二范式的核心要求叫不存在部分函数依赖，那不函数的依赖逻辑表达式是AB能得出C，然后A或者B都可以推出C，那就说C是完全的部分依赖于。

AB啊，部分依赖也是他俩任何一个只要有一个人的推出，它不需要另一个，那就说明是部分依赖，好那我们来看一下，那这上面是表格啊，那这里面的主见呢，是学号和课名啊，那分数呢，这是完全依赖于它，就分数类没问题，但是呢，姓名还是这个姓名，姓名它就是部分依赖于序号分名，因为它和它确实能推出它。但是呢，学号自己也能登上啊，跟这课程没关系，那这种就是不满的，那这种就不符合数据库设计的第二范式原则，那你要对它进行一个修改。那怎么修改呢？嗯，那既然这样，那我就把这个课名。

和学号啊，不做这个说单独分开，这样他们两个就能唯一决定分数啊，至少这张表是不是目前为止满足第三啊第二函是啊，你说不存在部分函数依赖。因为这两个它它俩的唯一决定分数好，那就把这个课名。把这个姓名放到另一张表里面了，那另一张表里面的只有学号，学号就能唯一决定姓名啊，微信的姓名好，那这个其实还不是完整的，不是我们想要的，还需要对它进一步的一个处理。只能说前面这张表符合第二范式，后边这还不行啊，还不行啊，再继续第三范式。第三派是核心要求不能存在传递函数依赖。

那就是这样，刚才这张表我们说需要对他进一步的处理啊，因为这里面存在学号能够推出姓名，姓名能够推出系主任，但是系主任往回推，推不动啊，推不动。好，那这是不能存在传递函数一的，那我们就把上面这张表再进一步的拆解啊，那我就学号能够推出姓名啊，姓名能够推出姓名啊，再拆，那把这个姓名和系主任又放到一张脚表里边了啊，让他不存在这个传建函数里来啊，其实准确来说这是不是还可以再拆啊，还可以再拆啊，那拆完之后最终的结果你会发现。是不是我把所有的表都拆成不能再拆的各种小表了，只要拆成最细的，那就满足了第三范式。

啊，三大。那就尽可能的拆，猜猜猜猜啊，全是小表，那么小表的特点呢，就是啊，刚才说了它有优势，优势的数据不存在勇于啊，同时呢，还有个什么。还有一个特点叫保证数据的一致性啊，这么两个优点，那么它有缺点，缺点呢就是在查数据的时候要进行各种照引啊照应啊，那在真正的这个买次或数据库当中啊，绝大多数都满足三范式的一个实要求，但在数场里面。啊，大多数都不完，为什么呢？因为大数据里面场景最不擅长的就是噪音，对吧？啊都瓣反音挺很慢啊，很慢。好，那我们再来回顾一下，三范是理论当中第一半是要求属性不可切割，第二派是不能存在部分函数依赖，第三代词不能存传递函数依赖，OK，这就OK了，在面试时候他就说OK。