当前位置: 首页 > news >正文

数仓理论【范式】【维度建模】

数仓理论

1 范式理论

1.1 范式概念

数据建模要遵循一定的规则,在关系建模中,这种规则就是范式

采用范式结构,可以有效的降低数据的冗余性

范式在获取数据时,需要通过join拼接出数据

范式有第一范式(1NF),第二范式(2NF),第三范式(3NF),巴斯-科德范式(BCNF),第四范式(4NF),第五范式(5NF)

一般只遵循到第三范式

1.2 函数依赖

1.2.1 完全函数依赖

通过(学号,课程)可以推断出分数,但是单独用学号或者课程都不能推断出分数,这时可以说分数完全依赖于(学号,课程)

即AB能推断出C,但是A和B单独不能推断出C,这时C完全依赖于AB

1.2.2 部分函数依赖

通过(学号,课程)可以推断出姓名,但是只通过学号就能推断出姓名,这时可以说姓名部分依赖于(学号,课程)

即AB能得出C,A或B单独也能得出C,这时C部分依赖于AB

1.2.3 传递函数依赖

学号可以推断出学院名,学院名可以推断出院长,但是院长推断不出来学号,这时可以说院长传递依赖于学号

即A得出B,B得出C,但是C得不到A,这时C传递依赖于A

1.3三范式的区分

1.3.1 第一范式

1NF的核心原则为:属性不可切割

比如下面的表格,商品列中的数据可以分割成 3台 和 电脑 ,所以下面的表格不遵循1NF

商品ID商品商家ID用户ID
0013台电脑001001

修改成遵循1NF的表格为

商品ID商品商家ID用户ID数量
001电脑0010013

1NF时关系型数据库的最基本的要求,在RDBMS中创建表时,如果不符合1NF的要求,操作是不会成功的

1.3.2 第二范式

2NF的原则为:不存在部分函数依赖

比如下面的表格,属性不可切割,满足第一范式,但是课名不完全依赖于(学号,姓名),所以不满足2NF的要求

请添加图片描述

这时将表拆分成以下两个,这时就满足了2NF

请添加图片描述

请添加图片描述

1.3.3 第三范式

3NF的原则为:不存在传递函数依赖

拿上面满足2NF的第二章表来说,系主任传递依赖于学号,所以需要进行进一步的拆解

拆分之后的如下两张表满足3NF

请添加图片描述

请添加图片描述

2 关系建模和维度建模

2.2 关系建模

关系建模将数据抽象成两个概念:实体和关系,使用规范化的方式表示出来,如图所示,关系建模较为松散。
请添加图片描述

关系建模遵循三范式,数据冗余性低,但是查询相对复杂,join操作比较多导致MR较多,查询效率较低

2.3 维度建模

维度建模以数据分析为出发点,不遵循三范式,存在一些数据冗余

面向业务,将业务用事实表和维度表的方式表现出来

查询效率较高

请添加图片描述

3 维度表和事实表

3.1 维度表

维度表一般是对事实的描述信息,比如:用户、商品、日期等

维度表很宽,具有多个属性,列多

与事实表相比,行数相对较小

内容相对固定

  • 比如:时间维度表
日期IDday of weekday of year季度
2023-2-153461
2023-2-164471

3.2 事实表

事实表中每行数据代表了一个业务事件(下单,支付等)

实时表示的是实践的度量值(次数,个数,金额等)

比如:2023年2月15日,jx在京东花了40元买了一本书

维度表存储:时间、用户、商家、商品等

实时表存储:数量、价钱(40元,一本)

一个事实表的行包括:度量值、与维度表相连的外键(通常有多个外键)

事实表非常大,相对较窄,列数较少,主要存储的是外键id和度量值

经常会发生变化,会产生很多的新增数据

3.2.1 事务型事实表

以单个事务或时间为单位

比如:一笔支付记录、一个订单记录

事实表中的一行数据,一旦事务被提交,数据被插入,就不能在进行更改

更新方式为增量同步

3.2.2 周期型快照事实表

不会保留所有的数据,只保留固定时间间隔的数据

比如:每天的营业额、每月的账户余额等

再比如:购物车随时都有可能增减商品,但是只关心每天结束时购物车的情况

3.2.3 累积型快照事实表

用于跟踪业务事实的变化

比如:要累积订单从下单开始,到订单商品打包、运输、签收的各个业务阶段的数据来追踪进展情况

这个业务进行时,事实表的记录也要不断更新

4 维度模型的分类

4.1 模型的介绍

维度模型分为三种:星型模型、雪花模型、星座模型

  • 星型模型

请添加图片描述

标准的星型模型只有一层

  • 雪花模型
    请添加图片描述

雪花模型和星型模型的区别主要在于维度的层级

雪花模型较为靠近3NF,但是无法完全遵守

  • 星座模型
    请添加图片描述

星座模型包含多个事实表,多个事实表共享维度表

多个星型模型或者雪花模型会形成星座模型

4.2 模型的选择

星座模型不用进行原则,多个事实表共享维度表是正常的,是数据仓库的常态

选择星型模型还是雪花模型,取决于是性能优先还是灵活优先,在实际的开发中不会只选择一种,需要根据情况灵活组合

星型模型维度更少,可以减少join,进而减少shuffle

http://www.lryc.cn/news/8642.html

相关文章:

  • 卷积神经网络
  • 解决Qt提示xxx.so not found( using -rpath or -rpath-link)问题
  • Blazor 托管模型 BlazorWebAssembly和Blazor Server
  • 从未想过制作数据可视化展示竟可以如此简单
  • 企业电子招投标采购系统源码之功能模块的描述
  • LeetCode-2341. 数组能形成多少数对【哈希表,计数】
  • vue-echarts实现多功能图表
  • C#快键精灵
  • 谷歌、微软、Meta?谁才是 Python 最大的金主?
  • 面向对象笔记
  • tofu:一款功能强大的模块化Windows文件系统安全测试工具
  • VS中scanf为什么会报错
  • 使用kubeadm部署k8s1.24.0版本,遇到的坑总结
  • 【C++】特殊类设计
  • 中创教育PMP如何轻松应对公司90%以上的沟通难题
  • #笨鸟先飞# 数据结构与算法基础 课程笔记 第六章 图
  • 深入浅出带你学习Apache中间件常见漏洞
  • 用多种指针方法访问数据元素,实现逆序输出
  • WebDAV之葫芦儿·派盘+NMM
  • Redis多级缓存
  • 【原创】java+swing+mysql会议室管理系统设计与实现
  • 【Redis】Redis 常用数据类型操作 ① ( 数据库操作 | Redis 数据库连接参数 | Redis 数据库个数 | Redis 访问机制 )
  • GAMES101-计算机图形学入门 LEC4: TRANSFORMATION-3D
  • robot实战:截取字符串
  • 【面经】滴滴测开一面
  • 数据治理-主数据
  • 软考-中级-软件设计师-成绩
  • 学习笔记<二> MySQL学习(3):分库、分表
  • 重生之我是赏金猎人-SRC漏洞挖掘(八)-记一次移花接木的GetShell
  • 离线数仓(五):数仓搭建