Java教程

数据仓库建模理论

本文主要是介绍数据仓库建模理论,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

1、数仓建模的目标

访问性能: 能够快速查询所需的数据, 减少数据I/O;
数据成本: 减少不必要的数据冗余, 实现计算结果数据复用, 降低大数据系统中的存储成本和计算成本;
使用效率: 改善用户应用体验, 提高使用数据的效率;
数据质量: 改善数据统计口径的不一致性, 减少数据计算错误的可能性, 提供高质量的、 一致的数据访问平台。

2、数据仓库建模理论

1、关系模式范式

关系型数据库设计时, 遵照一定的规范要求, 目的在于降低数据的冗余性
和数据的一致性, 目前业界范式有:

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

2、第一范式(1NF)

域(表中字段)都应该是原子性的, 即数据库表的每一列都是不可分割的原子数据项

id商品商家
14件毛衣yyds公司

其中,4件毛衣可以分割,不符合第一范式,应该改为

id商品名数量商家
1毛衣4yyds公司

3、第二范式(2NF)

在1NF的基础上, 实体的属性完全依赖于主关键字, 不能存在仅依
赖主关键字一部分的属性。

学生 id所属系系主任所修课程分数
1生物系张三00199
1生物系张三002100

上表主关键字是学生id和所修课程,由此可以确定唯一的分数;但是,所属系、以及系主任只是依赖于学生id,不符合第二范式。如果,此学生转入到别的系中,此表的所属系和系主任就要大量修改,另外还由数据冗余的缺点。
可以拆成两个表:

学生 id所修课程分数
100199
1002100

学生 id所属系系主任
1生物系张三

4、第三范式(3NF)

在2NF的基础上, 任何非主属性不依赖于其它非主属性。

id商品id商品颜色商家用户id
100001白色yyds公司001

上表中,商品颜色是依赖于商品id的,不符合第三范式。
可以分解为:

id商品id商家用户id
100001yyds公司001

商品id商品颜色
00001白色

3、ER实体模型

在信息系统中, 将事物抽象为“实体” 、 “属性” 、 “关系” 来表示数据关联和事物描述;
实体: Entity, 关系: Relationship, 这种对数据的抽象建模通常被称为ER实体关系模型。
实体: 通常为参与到过程中的主体, 客观存在的, 比如商品、 仓库、 货位、 汽车,此实体非数据库的实体表。
属性: 对主体的描述、 修饰即为属性, 比如商品的属性有商品名称、 颜色、 尺寸、重量、 产地等。
关系: 现实的物理事件是依附于实体的, 比如商品入库事件, 依附实体
商品、 货位, 就会有“库存” 的属性产生; 用户购买商品, 依附实体用
户、 商品, 就会有“购买数量” 、 “金额” 的属性产品。

实体之间建立关系时, 存在对照关系:
(1)1:1 , 即1对1的关系, 比如实体人、 身份证, 一个人有且仅有一个身份证号;
(2)1:n, 即1对多的关系, 比如实体学生、 班级, 对于某1个学生, 仅属于1个班级, 而在1个班级中, 可以有多个学生;
(3)n:m, 即多对多的关系, 比如实体学生、 课程, 每个学生可以选修多门课程,同样每个课程也可以被多门学生选修。

在日常建模过程中,
“实体” 用矩形表示:
“关系” 用菱形表示:
“属性” 用椭圆形表示:
所以ER实体关系模型也称作E-R关系图。

案例:
场景: 课程管理系统
该系统主要用来管理某校教师、 学生、 课程, 其中包括课程选修、 考试、
教师授课、 学生班级管理功能, 现需要完成数据库逻辑模型设计。
1, 抽象出主体
2, 梳理主体之间的关系
3, 梳理主体的属性
4, 画出E-R关系图

  • ER模型是数据库设计的理论基础, 当前几乎所有的OLTP系统设计都采用ER模型建模的方式;

  • Bill Inom提出的数仓理论,推荐采用ER关系模型进行建模;

  • BI架构提出分层架构, 数仓底层ods、 dwd也多采用ER关系模型进行设计。

4、维度建模

Kimball推崇数据集市的集合为数据仓库, 同时也提出了对数据集
市的维度建模, 将数据仓库中的表划分为事实表、 维度表两种类型。

(1)事实表

在ER模型中抽象出了有实体、 关系、 属性三种类别, 在现实世界中, 每一个操作型事件, 基本都是发生在实体之间的, 伴随着这种操作事件的发生, 会产生可度量的值, 而这个过程就产生了一个事实表, 存储了每一个可度量的事件。
电商场景: 一次购买事件, 涉及主体包括客户、 商品、 商家, 产生的可度量值包括商品数量、 金额、 件数等.

(2)维度表

维度, 顾名思义, 看待事物的角度。 比如从颜色、 尺寸的角度来比较手
机的外观, 从cpu、 内存等较比比较手机性能;

维度表一般为单一主键, 在ER模型中, 实体为客观存在的事物, 会带有自己的描述性属性, 属性一般为文本性、 描述性的, 这些描述被称为维度。
比如商品, 单一主键: 商品ID, 属性包括产地、 颜色、 材质、 尺寸、 单价等,但并非属性一定是文本, 比如单价、 尺寸, 均为数值型描述性的,

日常主要的维度抽象包括: 时间维度表、 地理区域维度表等

雪花、 星型模型

维度建模通常又分为星型模型、 雪花模型。
星型模型和雪花模型主要区别就是对维度表的拆分, 对于雪花模型, 维度表的涉及更加规范, 一般符合3NF; 而星型模型, 一般采用降维的操作, 利用冗余来避免模型过于复杂, 提高易用性和分析效率。

雪花、 星型模型对比

  1. ETL: 雪花模型符合业务ER模型设计原则, 在ETL过程中相对简单, 但是由于附属模型的限制, ETL任务并行化较低; 星型模型在设计维度表时反范式设计, 所以在ETL过程中整合业务数据到维度表有一定难度, 但由于避免附属维度, 可并行化处理。
  2. 性能: 雪花模型由于存在维度间的关联, 采用3NF降低冗余, 通常在使用过程中, 需要连接更多的维度表, 导致性能偏低; 星型模型反三范式, 采用降维的操作将维度整合, 以存储空间为代价有效降低维度表连接数, 性能较雪花模型高。
  3. 冗余: 雪花模型符合业务逻辑设计, 采用3NF设计, 有效降低数据冗余; 星型模型的维度表设计不符合3NF, 反规范化, 维度表之间不会直接相关, 牺牲部分存储空间。

5、dataVault模型

DataVault模型
包含三种基本结构
Ø 中心表-Hub
唯一业务键的列表, 唯一标识企业实际业务, 企业的业务主体集合
Ø 链接表-Link
表示中心表之间的关系, 通过链接表串联整个企业的业务关联关系
Ø 卫星表- Satellite
历史的描述性数据, 数据仓库中数据的真正载体

Data Vault模型更容易设计, ETL过程中更易配置化实现。Hub想像成人体的骨架, 那么Link就是连接骨架的韧带组织,而satelite就是骨架上的血肉。

Data Vault是对ER模型更近一步的规范化, 由于对数据的拆解和更偏向于基础数据组织, 在处理分析类场景时相对复杂,适合数仓低层构建, 目前实际应用场景较少。

这篇关于数据仓库建模理论的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!