标签：范式 理论 实体 数据仓库 建模 id 维度 模型 ER
1、数仓建模的目标
访问性能： 能够快速查询所需的数据， 减少数据I/O；
数据成本： 减少不必要的数据冗余， 实现计算结果数据复用， 降低大数据系统中的存储成本和计算成本；
使用效率： 改善用户应用体验， 提高使用数据的效率；
数据质量： 改善数据统计口径的不一致性， 减少数据计算错误的可能性， 提供高质量的、 一致的数据访问平台。
2、数据仓库建模理论
1、关系模式范式
关系型数据库设计时， 遵照一定的规范要求， 目的在于降低数据的冗余性
和数据的一致性， 目前业界范式有：
- 第一范式(1NF)
- 第二范式(2NF)
- 第三范式(3NF)
- 巴斯-科德范式(BCNF)
- 第四范式(4NF)
- 第五范式(5NF)
2、第一范式(1NF)
域（表中字段）都应该是原子性的， 即数据库表的每一列都是不可分割的原子数据项
| id | 商品 | 商家 |
|---|---|---|
| 1 | 4件毛衣 | yyds公司 |
其中，4件毛衣可以分割，不符合第一范式，应该改为
| id | 商品名 | 数量 | 商家 |
|---|---|---|---|
| 1 | 毛衣 | 4 | yyds公司 |
3、第二范式(2NF)
在1NF的基础上， 实体的属性完全依赖于主关键字， 不能存在仅依
赖主关键字一部分的属性。
| 学生 id | 所属系 | 系主任 | 所修课程 | 分数 |
|---|---|---|---|---|
| 1 | 生物系 | 张三 | 001 | 99 |
| 1 | 生物系 | 张三 | 002 | 100 |
上表主关键字是学生id和所修课程，由此可以确定唯一的分数；但是，所属系、以及系主任只是依赖于学生id，不符合第二范式。如果，此学生转入到别的系中，此表的所属系和系主任就要大量修改，另外还由数据冗余的缺点。
可以拆成两个表：
| 学生 id | 所修课程 | 分数 |
|---|---|---|
| 1 | 001 | 99 |
| 1 | 002 | 100 |
和
| 学生 id | 所属系 | 系主任 |
|---|---|---|
| 1 | 生物系 | 张三 |
4、第三范式(3NF)
在2NF的基础上， 任何非主属性不依赖于其它非主属性。
| id | 商品id | 商品颜色 | 商家 | 用户id |
|---|---|---|---|---|
| 1 | 00001 | 白色 | yyds公司 | 001 |
上表中，商品颜色是依赖于商品id的，不符合第三范式。
可以分解为：
| id | 商品id | 商家 | 用户id |
|---|---|---|---|
| 1 | 00001 | yyds公司 | 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； 而星型模型， 一般采用降维的操作， 利用冗余来避免模型过于复杂， 提高易用性和分析效率。
雪花、 星型模型对比
- ETL： 雪花模型符合业务ER模型设计原则， 在ETL过程中相对简单， 但是由于附属模型的限制， ETL任务并行化较低； 星型模型在设计维度表时反范式设计， 所以在ETL过程中整合业务数据到维度表有一定难度， 但由于避免附属维度， 可并行化处理。
- 性能： 雪花模型由于存在维度间的关联， 采用3NF降低冗余， 通常在使用过程中， 需要连接更多的维度表， 导致性能偏低； 星型模型反三范式， 采用降维的操作将维度整合， 以存储空间为代价有效降低维度表连接数， 性能较雪花模型高。
- 冗余： 雪花模型符合业务逻辑设计， 采用3NF设计， 有效降低数据冗余； 星型模型的维度表设计不符合3NF， 反规范化， 维度表之间不会直接相关， 牺牲部分存储空间。
5、dataVault模型
DataVault模型
包含三种基本结构
Ø 中心表-Hub
唯一业务键的列表， 唯一标识企业实际业务， 企业的业务主体集合
Ø 链接表-Link
表示中心表之间的关系， 通过链接表串联整个企业的业务关联关系
Ø 卫星表- Satellite
历史的描述性数据， 数据仓库中数据的真正载体
Data Vault模型更容易设计， ETL过程中更易配置化实现。Hub想像成人体的骨架， 那么Link就是连接骨架的韧带组织，而satelite就是骨架上的血肉。
Data Vault是对ER模型更近一步的规范化， 由于对数据的拆解和更偏向于基础数据组织， 在处理分析类场景时相对复杂，适合数仓低层构建， 目前实际应用场景较少。
标签：范式,理论,实体,数据仓库,建模,id,维度,模型,ER 来源： https://blog.csdn.net/qq_44665283/article/details/121025681
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。