00:00
好,接下来呢,我们看一下第二章啊,第二章的内容呢,是非常重点的啊,一定要认真听啊,虽然说是纯理论,但是呢,属于整个数仓的一个核心啊。来看第一个式的一个概念。啊,叫范式理论是吧,一听范式感觉是范式中举那种感觉啊,不是这样的哈,来看一下它定义范式呢,可以理解为设计一张表啊,数据表的表结构符合标准的一个级别,其实就是规范和要求,你可以这样理解规范和要求。比如说你建一张表的时候,你得按照这个有一定这个规则,就像刚才那个数上命名似的,你必须得有规矩,咋样的去设计这个表表结构啊,你要遵循它相应的一些要求啊,这就是范式哈,按照要求去办事,那它有什么优点呢?来关型模型,关系型模型往往指的就是my circlel Oracle这种JAVA1后台的这种关系型数据库,遵照一定的规范要求,目的呢在于降低数据的冗于性。
01:04
就是关系数据库啊,它的设计原则呢,就是尽量的去降低冗余。不让他在数据在这个MYSQ里面产生重复的数据。这是它一个非常大的一个原则哈,那为什么要降低这个勇于性呢?啊,这里面是有历史背景的哈,在这个十几年前,那时候呢,就已经有了Java了,对吧,而且那时候呢,服务器的特点啊,磁盘很贵,你觉得现在这个磁盘可能很便宜,那当年那时候那个磁盘也是很贵的。那你你的如果这个买Q里面有大量的永福数冗余数据,比如说用户数据。有一张表里面有用户,另一张表里面还有用户。只不过呢,这里面是有用户,这里面加上一个商品。对吧,啊,多了几个字段。啊,有略微有些区别,略微有区别,我就就备份了一份,那这种呢,就会就叫勇于,那我们希望怎么做呢?哎,希望呢,把这个用户抽取出来。
02:00
然后呢,商品再抽取出来,然后我只放了一个用户ID。我放一个用户ID不就行了吗?画个图吧。以前呢,Java这个Java后台它是这样的,比如说这里面有这个用户啊。还有商品,还有什么其他的支付啊等等都可以啊这么几类,然后呢,另一张表里面呢。用户信息,然后还有什么呢?还有其他的像那个架构吧,加购。啊,加入购物车评论,假如说是这样的啊,假如说这样,那这样的话呢,他觉得这个用户啊,我放在这张表里面进行预算,相对来说会比较方便,什么用户买了哪个商品,对他进行支付了,然后这里面的说哪个用户加入到购物车,然后对这个商品进行评价了,预算起来肯定都方便了。
03:01
哎,那就但是呢,这叫产生了有余数据。那产生有些数据,那怎么办呢?哎,就想办法把它。对吧,哎。剥离出去,那剥离出去的话,那这块,那这张表里面放什么呢?这里面只放一个。用户表的ID对吧,放用户表ID就可以了,那你如果日后的话想用,想查对应的数据。哎,你这就可以查了,那这张表呢,放在这。这里面是用户。哎,用户信息你说这样去做,你想读数据的时候,哎,你关联它,然后关联它对吧?哎这样呢就比较简单,你说加VA1后台呢,往往它是这样去做的哈,这样做,那么他这样做的目的呢,是家庭永用性,家庭永用性的原因一个是十几年前吃饭比较贵,你可以减少10万空间。对吧,另一个呢,是以前的没有这种分布式系统,都是单机的哈,我说的是很久很久以前了,那只能增加磁盘,磁盘的个数呢是有限。
04:10
什么意思?比如说你在这个公司当中啊,以前呢,这是一台一台服务器。他很少有这种服务器的这种通讯,就集群间内跨跨服务器通讯,你像那个新代版时候有这种叫这个微服务对吧?啊微服务这种方式啊,也有一定的这个集群,但是以前不行,以前的话经常情况就靠这种单机,而且那时候叫小型机,大家听没听过啊叫小型机。啊强机这一个小型机啊,都好几百万啊,至少100万起,它这个性能呢,各方面呢都会啊比较好一些啊,当然对应的价格就比较贵,但是呢,它这个支持这个这个服务器之间通讯的性能也不是特别好。那如果吃饭不够怎么办呢?那只能加吃饭。哎,只能往这里面一个一个C,那这个磁盘啊,这个你像磁盘是有插槽的,你假如说就有四个插槽,那你插到第四块硬盘,四块硬盘的时候,那这里面就插不下了。
05:07
啊,他也说受受这方面的一个硬件条件的一个限制哈,那当然现在这个啊,没有这种情况,那下面呢,现在呢,会出现这种情况。就是一次修改需要修改多个表,很难保证数据一致性。这是一个新债,也是一直保持着这个尽量降低永的一个原因。在这你看。看啊还是看这张图,这张图呢,如果原来的话,原来的话这里面有用户表,这里面有用户表。那突然有一天张三说我要改名字是吧?啊,张三改手机号吧,修改手机号。张三,他修改了手机号,那他需要呢,去哎查一下这张表,把手机号修改,同时要查一下这张表,把手机号修改了。那你就发现你就会改很多地方,那这是一个张三,那还有李四张王五赵六呢,对吧,那你最好的方式是什么呢?哎,直接在这里面对吧,张森修改手机号,我直接在这修改,修改完毕之后,那你这跟这一点影响没有,我只是放了ID。
06:11
对吧,啊,你要用的时候我就关联它就行了,所以说只要在一处修改,那处处都已经全部完事了啊,这也跟我们之前那个把一些全局变量是吧,就那个库。啊,提取出来是一样的,你否则的话,其他地方都用的是这个绝对路径,那你要改这个路径的话,那全全都能改,那现在呢,我只需要在这个地方把它这个路径你改啊,全局全部改掉啊,是这么一个原因啊行,那这时候关系数据库呢,它尽量的是降低勇于,那降低勇于的话,它就会相当于把这个表,你看拆分出是不多多一张表啊,以前的话,你这是一张表,这是两张表。那现在呢,又来了第一张,第三张表。他会把这里面全部都放成类似这种ID。Did用的时候就各种关联,那关联的话用到的语法不就是噪音吗。
07:02
对吧,按照ID相同进行相应的一个招引处理哈行那范式的缺点呢,就是说获取数据的时候呢,需要通过噪音拼接出最后的数据。你表越多,那你拼的就越多啊,是这样哈,行。那范式的这个分类哈,我们来说一下,目前业界的范式有第一范式,第二范式,第三范式,什么巴斯克德范式,第四范式,第五范式,一堆范式。啊,这么多这么多范式呢,那刚才说了范式呢,就是这个规范要求。就是它的规范和要求,那很简单了,也就说你满足第一范式,你相当于满足了第一啊,这个他的一个要求,满足这个方式呢,就满足他的要求,再往上满足他的要求啊,你越往后满足,那其实呢,相对来说越规范一些。当然那这个大家都不愿意去受这个约束,对吧,那肯定会带来一些不爽的地方。啊,就是日后尤其这块,那你需要各种大量的这个噪音操作哈。
08:03
行啊,简单了解一下啊,这是三范四啊个范四啊,四里面主要解决的就是数据有余问题啊,尽量的把数据呢进行一个拆开独立出来,现在呢,只剩下这条,就是解决的是数据的一致性问题,像磁盘空间这一块目前不存在,以前是有这种情况的,那那它的缺点呢,就是日后呢,我再想获取数据的时候呢,需要大量的招引。然后呢,业界呢,有这个范式呢,有第一范式,一直到这个第五范式有很多,但是呢,目前企业当中的范式呢,主要是这个前三范式。那下面我们后面会讲具体这3万式的一个,呃,规则要求。
我来说两句