00:00
OK啊,那咱接下来呢,要讲的是这个数据仓库当中的这个建模理论啊,建模理论,那其实咱们提到这个建模,提到建模啊,尤其是这个数据库建模,对吧,那我们大家应该诶知道两个两个这样的建模的理论啊,一个叫做维度模型啊,或者叫做维度建模,那一个呢,叫做关系模型,或者叫做关系建模啊,这个两种建模方式呢,在咱们这个数据仓库当中,其实哎,都有用的啊,都有用的啊,而且每一个建模理论,关系建模和维度建模呢,他们各自都有一个这个支持者啊,都有一个支持者啊,或者叫做一个推推荐推崇者啊,那谁推崇这个呃维度呃,这个关系间玩呢,谁推崇啊?呃,一个老外啊叫做啊比尔伊蒙啊比尔伊蒙啊,那这个人呢,他其实呃,就是号称什么这个数数据仓库支付什么的啊,就这种东西啊,然后呢,他所支持这个数据。
01:01
物的建模方式是啊,这个关系建模啊,然后后边呢,哎,还有一个人啊,就是他推崇咱们这个维度建模,那这个人叫什么呢?呃,他那个名字叫什么我忘了,但是他的信儿是k ball啊,K ball啊叫做k ball啊,那这个人呢,推崇的是维度建模啊,那其实这两套建模方式在咱们就是书仓里边呢,都有可能会应用,但是目前啊,在咱们这个大数据的这个背景下啊,我们目前所采用的建模方式更多的应该是哪个呀?是维度建模,更多的是维度建模。啊,是这样的啊呃,然后关系模型咱们现在在哪比较常见的,现在在这个业务系统当中是很常见的啊业务系统。呃,咱比如说我们这个前面是不是给大家讲过一个采集项目,对吧,采集项目里边咱们业务系,业务系统的一个数据是不是就一大堆的数据,一大堆的表啊,对吧,那一大堆表是不是也会组成一个所谓的模型啊,对不对,那个模型就是什么模型,就是典型的关系模型。
02:03
啊,就是关系模型啊,其实大家呃,通过那个业务系统也能发现,这个关系模型是不是非常的复杂呀,对吧,里边表很多啊,表很散对不对,然后表与表之间的关系非常复杂对不对,这就是关系模型给咱们大家的第一个就是第一印象就是这样的啊,其实它确实是这样的啊,然后跟它相对的,我们这个维度模型,那它使用起来就要简单很多了啊,就是它的模型会比较清晰啊,然后表呢,没有那么多,没有那么散,表与表之间的关系呢,也非常简单啊,这是维度模型它它的特点啊的特点啊,那我们大家先把这两个模型的概念咱们先搞清楚啊啊然后咱们接下来呢,要按照这个文档顺序去讲,咱们接下来要讲一下这个范式理论,这个范式理论呢,是为谁打基础呢?是为这个我们去了解这个关系模型打基础的,也是关系模型当中呢,我们会用到范式理论啊好,那接下来咱们开始学习这个所谓的范式理论啊,当然他对咱们。
03:04
们维度建模来说没有那么重要,所以这个我们以理解为主啊,就是了解一下就行啊好,那现在我们看这个所谓的范式理论,那所谓的范式理论呢,我们呃,先来看一下这个范式什么意思啊,范式概念什么意思啊,来看一下这是它的定义,这个定义呢,好像写的就是有点不太通顺啊,咱们读一下啊,凡是可以理解成这个,呃,设计一张数据表的表结构,然后呢?呃,符合的这个呃标准级别规范和要求啊,这句话看似不太通顺是吧?啊,但其实说的没毛病啊,说没毛病其实就是什么意思啊,说白了所谓的范式啊,范式,范式就是一套规范化的模式,规范化的模式啊,那什么时候会用这套规范化的模式呢?就是我们去设计一张表的这个表结构的时候。啊,就是咱们现在我我我我我比如说要开发一个业务系统,对不对啊,我要进行关系建模啊,所以建模就是在去去决定我建哪些表,然后表的字段是什么,就是决定那些事儿,你在决定这些事儿的时候呢,可以使用这个范式啊,去指导你进行界面啊,然后呢,你只要遵循他这一套规范化的这个呃模式,那OK,你建出来的表呢,那就是符合咱们这个标志的啊,符合规范,符合要求的啊,是这样的啊啊这就是所谓的这个范式啊,那这个范式啊,那它能够起到的这个作用是什么呢?咱们刚才只是粗略了一下啊,粗略的说了一下,就是他能够对咱们的这个建表进行规范化,对吧?那规范化之后是什么样的呢?来往下看啊,它具体能够实现什么样的功能?
04:42
哎,其实主要的一个功能就是采用范式啊,咱们的主要目的就是降低数据的冗余性,降低数据的冗余性啊,那首先我们先来明确一下这个冗余性这个概念,大家理解不理解,是不是真正的理解?啊,什么叫冗余啊,什么叫冗余啊,这数据重复就要冗余对不对啊,可可以这么理解,没错啊,确实是这样的啊,那如果说在我们自己设设计好的一个这样的关系模型当中啊,就是同一条数据,同一条数据啊,相同的字段,相同的值啊,如果说我出现在了多个地方。
05:22
那这就叫做数据发生了冗余啊,什么意思?比如说用户的一个信息啊,一条用户的信息啊,那用户信息,假如说我有一张用户表,那用户表里边是不是会存储用户的姓名、性别、年龄、手机号等等等,是不是有这么多信息啊,诶在这儿会有的啊,那在另外一张表呢,比如说我这儿还有一个订单表,在订单表当中,因为咱们是不是得知道是哪个用户下的订单呀,对吧?那这时候比如说我在订单表里边,我也记录了用户的姓名、性别,然后什么年龄,手机号等等等等,诶,那你发现K是不是就是所谓的数据产生的冗余啊。就是所谓的冗余啊,所谓的冗余啊,就是说白了就是,哎,同样的一条这个数据信息在咱们整个模型当中出现了,在多个地方出现了多次,那就是数据产生冗余了啊啊,那这个数据冗余之后,它有什么样的坏处啊啊,那咱们这说了要降低数据的冗余性对不对,它有什么坏处啊。
06:18
啊,冗余了有什么不好的地方,其实最明显的一个地方,嗯,同样一条数据有没必要存多个地方,对吧,这样一来会呃,导致咱们这个占用的存储空间会增多,对吧?那所以说这是它最明显的一个缺点,但其实这个呢,还不是最啊,最致命的啊,那最致命的应该是哪个呀?那就是咱们这个数据的一致性就没有那么好保证了啊,就没有那么好保证了啊,这个怎么去理解啊,你想一想啊,如果说同一个用户的信息在咱们这个整个模型当中出现了多次啊,那你说咱们用户是不是有可能会修改个人信息对不对,那要改的话,那你是不是就得想到咱们都在哪些地方出现了这个用户的信息。
07:02
对不对,那你你都得把这些信息是不是都得去做一个修改啊,对不对,那这我得改,这儿得改,这得改,这儿也得改啊,你都得改啊,那所以说这样一来,你这个数据啊,它就一致性就没有那么好保证了啊,就没有那么好保证了啊,这实际上是咱们这个数据冗余的这个缺点啊,那我先简单问大家一下啊,你说咱们这个一致性,因为他入迷了之后,是不是有这个一致性问题啊,那你说怎么可以怎么解决这个一致性问题。可以怎么解决?怎么解决呀,哎,你可以这样做呀,哎,我我保证啊,所有的用户信息只在用户表当中存储,那其他其他的表呢,怎么做?哎,我来一个user的外键。对不对,然后呢,我去关联,我去引用这一条数据,那是不是用户的信息只在一个地方出现了,你改是不是只要改一个地方,其他地方是不是都会相当于跟着变呀,是这样的,那所以这这就能够解决这个一致性问题吗?对不对啊,那呃,而且你看啊,你如果说引用外键之后,那这个冗余性它还有吗。
08:08
是没有冗余性了呀,咱们只存一份了吗?哎,是这样的啊呃,这当然这这说的是咱们怎么去解决这个冗余性问题啊,那当然咱们经过这个规范化之后,那这个冗余性这个一致性自然就解决了,是这样的啊,那接下来就是咱们要讲的这个规范化了,好,那这边刚才咱们提到了冗余性的这个问题啊,然后下边呢,就是说咱们为什么要去降低冗余性,这个其实跟咱们跟刚才咱们分析的差不多啊,咱们来简单看一下吧,啊首先第一个啊,十几年前啊,咱们这个磁盘很贵,为了减少磁盘存储,呃,这个怎么理解啊?呃,大家要知道这个关系型数据库它是呃在什么什么样的这个情况下诞生的。啊,十几年前,那现在应该是20几年前了啊,啊就是90年代啊,那时候啊,就那个时候,呃,诞生的是这个关系数据库,那时候开始火起来的啊,就是那个时候大家都知道这个磁盘的存储空间,它确实还比较贵啊,它不像现在,你像现在你别说磁盘了,就固态硬盘是不是也没多贵了呀,对不对,但是在那个时候是非常非常贵的啊,你九你你别说90年代,你就是零几年啊,那时候如果说你要去买个呃什么,别说硬盘,就买个U盘啊,挺喜欢那U盘对吧,咱现在你买一个U盘买个什么60多G的,128G的,几十块钱对吧?啊贵点100块钱,但是那时候你就是买一个,呃,别说60多,你买一个4G的可能就得好几百啊,就是那时候还是比较贵的,而且那时候那几百块钱跟现在比它也不一样了,是吧?啊,那个时候确实存储代价比较高,所以你你要是把这个数据的容易性消失了,那我磁盘空间就能少占点,那我就能够节省一定的这个经济成本啊,这是第一点,那这个当然也不是最主要。
09:49
那主要还是什么啊,还是因为咱们这个关型数据库啊,在它诞生的年代,它那个时候还没有现在咱们这个互联网这么发达,咱们现在互联网当中的数据主要来自于谁呀,咱们现在这个年代。
10:03
咱现在互联网上数据啊,其实主要不是由咱们这个,呃,就是这个网站的运营公司提供的,应该是谁,是不是来自咱们的用户啊,对不对,你比如说你看头条,你刷什么抖音,那这些数据都来自于谁,都来自于咱们个人用户,对不对啊,当然你看的是别的用户发的啊,实际上你也可以往上发,对不对,那既然来自于咱们个人用户,所以这个数据呢,就以这种就是爆发式的这种增长啊,这个速度去增长,那所以说这个数据呢,现在是越来越大了,但是当时没有这么大的数据量,所以说没有这么大的数据量,他们根本就不会考虑对这个数据库进行这种什么所谓的分布式的设计,也就当时关系数据库最开始都是单机的,因为他根本就想不到会有这么大的数据量嘛,对吧?啊,那所以说呢,当时啊,全是单机的,那全是单机的话呢,那就会有一个问题啊,就是单机的这种服务,我扩展性肯定会比较弱。对不对,又是单机的,单机的话,那你说你扩展只能怎么做呀。
11:02
只能做所谓的纵向扩展啊,什么叫纵向扩展?呃,其实很好理解,就是你就比如说咱们是,呃,以这个咱们建一栋楼为例吧,啊,假如我现在盖了一栋楼啊,然后里边有十层,现在然后十层很快住满了,我需要扩展啊,那你只能怎么做?所谓纵向只能往上盖接着盖,但你不能一直往上盖,对吧,一个可能达到一定的这个层数之后,它开始晃悠了,你就不敢盖了,是吧?啊,那所以说这就是所谓的纵向扩展,它是有限的啊,那同理,咱们这单机版我我只能怎么做呀,我只能加加什么磁盘啊,加内存,但是你那个是不是CPU对内存对磁盘的支持也是有一定的极限的呀,你不可能一直扩展啊,这是有限的啊,那但是呢,如果说我现在是分布式的啊,是分布式,分布式我就可以怎么做呀,我就可以做所谓的横向扩展啊,所谓横向或者怎么理解呢?还是以盖楼这个事儿为例啊,我不往上涨了怎么做,我再多盖几栋楼,那这个假如咱们地球上空间非常大,对吧,你可以无限的扩展对不对,那所以说呃,这个之前呢,因为是单机版只能纵向扩展,扩展能力有限,所以说能尽量的减少存储空间就减少就可以了啊,这第二点这是,然后第三点呢,就是那个一致性的问题了啊,就是降低冗余性之后呢,那咱们这个一致性问题就比较容易保证啊是。
12:20
是这样的啊,所以说咱们啊,如果哎使用关形数据库啊,去进行这个设计,这个这个关系建模的话呢,那它这个范式呢,我们是一定要遵守的啊,一定要去降低数据容易性的啊啊行,那这是咱们讲一下这个范式的这个呃目的啊,以及就是咱们呃为什么要去降低这个哎容易性啊啊完事之后呢,咱们接着往下走啊呃往下走之后呢,就是咱们对数据模型进行规范化之后呢,咱们这儿诶有一个所谓的缺点,对吧?啊那这个缺点是什么呀。啊,确定一会儿大家能发现啊,就是你随着随着什么,随着我们这个规范化的进行,你会发现你这个数据库里面的表啊。
13:04
它会被拆开,而且会被拆的越来越细啊,拆的细了之后,那表是不是就越来越多了呀,那多了之后呢,那表与表之间的关系它就复杂了,对不对啊,就比较复杂了啊,那完之后,假如说我要想去获取这个表和这个表的数据,那你怎么办?是不是还得通过join呢,对不对,而且有时候呢,你需要join的这个层数呢,还比较多,照的层数还比较多啊,那大家都知道这个进行join的时候呢,其实是比较耗费性能的,对吧?啊,那所以说进行规范化之后呢,虽然能降低咱们的存储空间,但是呢,呃,会呃,就是在对咱们的这个查询性能造成一定的影响啊,这是它所谓的缺点啊,就是这个意思啊,那接下来呢,咱们说一下这个所谓范式的一个分类啊,范式分类,那目前咱们这个业界啊,就是比较知名的几个范式呢,有以下几个啊,来看一下分别是呃哪几个呢?就是第一个,第二个,第三个和第四个就是这个意思啊,那命名都是就是这么命名的,它叫第一范式第。
14:04
范式,第三范式,然后边呢,有一个巴斯科德啊范式,然后呢叫这当然只是一个音译啊,啊,就是有一些这个文献当中,它并不是音译成了巴斯克德,有叫其他的的啊,它只是一个音译而已,然后后边呢,有一个第四范式,有一个第五范式啊,那我们在这个关系建模的时候呢,我们其实一般情况下不会呃让他去遵循所有的范式,一般情况下我们就只遵循前三个范式。所以说我们一说到范式啊,通常就说什么呀,三范式,三分式,三范式其实说的就是第一第二第三范式是这个意思啊呃,然后给大家说一下这个几个范式,我们去遵循的时候,他这个要求是什么样的啊,我们这个几个范式之间也是有这个前后关系的啊,我们必须得在遵循第一范式的基础之上,才有资格有条件去谈第二范式啊,有遵循完第二范式之后呢,才有可能去遵循第三范式啊,是这样的啊,然后呢,你遵循的这个范式级别越高啊,遵循的越高,那咱们那个数据的冗余啊就会越少。
15:09
啊啊,遵循的这个级别越高,那冗余会越少啊,那一般情况下,咱们遵循到第三级别就够了啊,就够了啊这三分事啊,这当然说的是咱们这个,呃,比较就是规范的这个做法啊,当然就是目前啊,就是目前啊,咱们现在啊,就是即便是这种关系型关系模型,就是即便是业务系统当中啊,我们去进行关系建模的时候啊,也不一定啊,咱们都会严格的去遵守这个三盘式。啊,为什么呀。其实现在出于这样的两点考虑,第一点呢,现在咱们已经不是当初那个年代了,对吧,现在首先存储代价已经很低了,那其次呢,我们现在的关系型数据库,你像买circle Oracle,那这些东西都支持什么呢?现在啊,比如说什么分库啊,分表啊,是不是也支持所谓的这种类似于横向扩展这个东西了呀,对不对,也就说我也可以有多个数据库啊呃,有多个这个数据库的服务器嘛啊,我也可以进行这个比较,呃,比较大的扩展了,比较大扩展,那所以说这个首先存储我是能满足了啊,那再一个呢,咱们得考虑一个这样的问题啊,那什么问题啊。
16:17
啊,你如果说遵循的这个范式越严格,OK,确实我那个数据冗余性会越低,但是还会带来一个问题,什么问题啊,我的表是不是会拆的越散,那表拆的越散,你查询的时候,你招的是不是就越多,招的越多,你的查询性能呢,受影响就越大,那所以说咱们现在这个业务系统呢,很多就是为了保证我的查询性能啊,我我会怎么样,我会允许一部分数据冗余的存在啊,比如说我不遵循三分制,我遵循前两个啊是不是,那这样确实会有一部分的数据冗余,但是呢,它换来的就是我这个查询性能的提升啊,是这样的啊,所以这块呢,大家灵活的这个来理解一下就可以啊,这是咱讲的这个范式的概念啊,这概念咱就说完了啊,来把视频录一下。
我来说两句