标签：模型 数据仓库 建模 维度 数据 事实

DataWareHouse数据建模

文章目录

• DataWareHouse数据建模
• • 什么是数据建模？
  • • 什么是数据模型？
    • 数据仓库模型的组成
    • 为什么需要数据模型？
    • • 数据仓库的发展大致经历了三个过程
    • 数据仓库数据模型架构
    • 最后引出什么是数据建模？
  • 维度表的分类
  • • 事实表
    • 维度表
    • 总结
    • 数据组织类型
    • • 星型模型
      • 雪花模型
      • 星座模型
  • 怎么数据建模？
  • • 范式建模法(其实就说关系建模)
    • 维度建模法
    • 实体建模法

什么是数据建模？

顾名思义就是建立数据仓库模型，所以我们要先了解以下的问题

什么是数据模型？

数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体和实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射

在这里，数据模型表现的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际业务中具体的业务关系。

数据仓库模型是数据模型中针对特定的数据仓库应用系统的特定模型

数据仓库模型的组成

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tL90WPCV-1637819772648)(C:/Users/yunqi/AppData/Roaming/Typora/typora-user-images/image-20211124114827923.png)]

组成

1. 业务模型
2. 领域模型
3. 逻辑模型
4. 物理模型

建立下面四个模型的好处

1. 业务模型，主要解决业务层面的分解和程序化。
2. 领域模型，主要对业务模型进行抽象处理，生成领域概念模型。
3. 逻辑模型，主要将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
4. 物理模型，主要解决逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题

• 业务模型
  • 主要解决业务层面的分解和程序化
    • 划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
    • 深入了解各个业务部门的内具体业务流程并将其程序化。
    • 提出修改和改进业务部门工作流程的方法并程序化。
    • 数据建模的范围界定，整个数据仓库项目的目标和阶段划分
• 领域概念模型
  • 主要对业务模型进行抽象处理，生成领域概念模型。
    • 抽取关键业务概念，并将之抽象化。
    • 将业务概念分组，按照业务主线聚合类似的分组概念。
    • 细化分组概念，理清分组概念内的业务流程并抽象化。
    • 理清分组概念之间的关联，形成完整的领域概念模型。
• 逻辑模型
  • 主要将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
    • 业务概念实体化，并考虑其具体的属性
    • 事件实体化，并考虑其属性内容
    • 说明实体化，并考虑其属性内容
• 物理模型
  • 主要解决逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
    • 针对特定物理化平台，做出相应的技术调整
    • 针对模型的性能考虑，对特定平台作出相应的调整
    • 针对管理的需要，结合特定的平台，做出相应的调整
    • 生成最后的执行脚本，并完善之。

为什么需要数据模型？

我们都知道，我们会用一个东西，肯定是它在某些方面，帮我们解决了问题，或者是优化了什么？那么数据模型到底可以为我们解决那些问题呢？有什么优点首先我们需要了解整个数据仓库的建设的发展史。

数据仓库的发展大致经历了三个过程

• 简单报表阶段
  • 这个阶段，系统的主要目标
    • 主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据
  • 这个阶段的大部分表现形式
    • 这个阶段的大部分表现形式为数据库和前端报表工具。
• 数据集市阶段
  • 这个阶段，系统的主要目标
    • 主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
• 数据仓库阶段
  • 这个阶段，系统的主要目标
    • 主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据
    • 为领导决策提供全面的数据支持

通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义

解释一下什么是数据集市？

数据集市是数据仓库里面的常见的概念描述之一

• 数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。数据
  集市可以分为两种

• 数据仓库和数据集市处理的还都是结构化的数据但是大数据处理最多的还是非结构化的数据

• 数据集市是一个结构概念，它是企业级数据仓库的一个子集，主要面向部门级业务，并且只面向某
  个特定的主题

分类

• 独立数据集市，这类数据集市有自己的源数据库和ETL架构；
• 非独立数据集市，这种数据集市没有自己的源系统，它的数据来自数据仓库

应用场景

• 数据集市是数仓之上更聚焦的业务主题合集，更偏向于应对业务数据快速高效应用的需求，一
  般用于商业智能系统中探索式和交互式数据分析应用

一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题

• 进行全面的业务梳理，改进业务流程
  • 在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理
  • 通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化
  • 同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产
• 建立全方位的数据视角，消灭信息孤岛和数据差异
  • 通过数据仓库的模型建设，能够为企业提供一个整体的数据视角
    • 不再是各个部门只是关注自己的数据
  • 而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题
  • 更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有效解决。
• 解决业务的变动和数据仓库的灵活性
  • 通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现
  • 当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性
• 帮助数据仓库系统本身的建设
  • 通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。

数据仓库数据模型架构

• 系统记录域：数据仓库业务数据存储区，模型保证了数据的一致性。（继续使用Oracle？）

• 内部管理域：也就是元数据模型的存储管理。（工具待定）

• 汇总域：系统记录域的汇总数据，数据模型保证的主题分析的性能，满足部分报表查询。

• 分析域：用于各个业务部分的具体的主题分析。也就是数据集市。

• 反馈域：针对前端反馈的数据，根据业务需求而定

最后引出什么是数据建模？

数据建模指的是对现实世界各类数据的抽象组织，确定数据库需管辖的范围、数据的组织形式等直至转化成现实的数据库

维度表的分类

事实表

• 什么是事实表？

  • 联系事实与维度表的数字度量值和键，事实数据表包含描述业务内特定事件的数据
  • 是数据聚合后依据某些维度生成的结果表

• 事实表里存放了能体现实际数据或详细数据

  • 举个例子比如说京东上的手机的价格，7200元，这个放到维度表里面，想打折之后的价格，会员价格等等，这些会变的放到事实表里面
  • 再举个例子：一张表里存放了商品类型，商品编码，商品名字等等这些都属于商品的属性，这张就是张维度表。另一张表里存放了商品的销售数量，成本额，销售额等等这张表就是张事实表。

• 组成

  • 一般由维度编码和事实数据组成。
  • 每个维度表都有一个维作为主键，所有这些维的主键组合成事实表的主键

• 特征

  • 非常的大
  • 内容相对的窄
  • 经常发生变化，每天新增很多
  • 定时更新 不保留历史数据

• 事实表分类

  • 事务型事实表
    • 以每个事务或事件为单位
    • 一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新
  • 周期型快照事实表
    • 不会保留所有数据，只保留固定时间间隔的数据
  • 累积型快照事实表
    • 用于跟踪业务事实的变化，覆盖过程的整个生命周期
    • 通常具有多个日期字段来记录关键时间点

维度表

• 什么是维度表？

  • 相当于存放数据的属性，就是你对数据分析时所用的量
  • 比如分析产品销售情况，可以选择按商品类型，销售区域等等来分析
  • 这样按…来分析就构成了一个维度
  • 另外每个维度还可以有子维度（称为属性），例如类别可以有子类型，产品名等属性。
  • 一般把能够分类的属性单独列出来，成为维度表
  • 在事实表中维护事实与维度的引用关系

• 组成

  • 维度表就是存放了具有独立属性，层次结构的数据，一般由维度编码和对应的维度说明组成

• 维度表特征

  • 维度表的范围很宽（具有多个属性、列比较多）
  • 跟事实表相比，行数较少，（通常小于10万条）
  • 内容相对固定

• 维度建模四部曲

  • 选择业务处理过程
    • 选择感兴趣的业务线，如下单，支付，退款，活动
  • 定义粒度
    • 确定数据单位的综合程度
    • 一行代表信息：一条订单？一天的订单？一周的订单？ 选择最小粒度
    • 在同一事实表中，必须具有相同的粒度
  • 选择维度
    • 粒度已经确定了一个基本的维度集合，根据需要再添加其他相关的维度
    • 牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能
      出现重复数据，应使维度主键唯一
  • 确定事实
    • 度量值：如个数，件数，金额
    • 最实用的事实就是数值类型和可加类事实

• 设计原则

  • 维度属性尽量丰富，为数据使用打下基础
  • 给出详实的、富有意义的文字描述
  • 区分数值型属性和事实
  • 沉淀出通用的维度属性，为建立一致性维度做好铺垫
  • 一方面，可以提高下游使用的方便性，减少复杂度
  • 另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致

• 三种维度

  • 退化维度
    • 这种维度指的是直接把一些简单的维度放在事实表中
    • 退化维度一般在分析中可以用来做分组使用
  • 缓慢变化维
    • 随时间发生变化的维度我们一般称之为缓慢变化维
    • 缓慢变化维一般使用代理键作为维度表的主健(代理键是在当资料表中的候选键都不适合当主键时来代替可辨识唯一值的主键。)
      • 维度里的数据是可能发生变化的，业务系统((CRM、OA等))往往并不会保留历史数据，但在分析角度，我们是一定要保留这些改变的痕迹，这种随着时间可能会缓慢变化的维度，就是 缓慢变化维
        • 常见的处理方法(kimball 整理的处理方法一共有 8 种，但往往只有 3 种被详细使用kimball 整理的处理方法一共有 8 种，但往往只有 3 种被详细使用)
          • 类型1 重写
          • 类型2 增加新行
          • 类型3 增加当前值属性
          • 剩下的 5 种类型基本都不被采用，但值得一提
            • 类型0 不做调整
              • 绝不允许 ETL 对该维度进行更新——你真要改的话就手动改表吧
              • 例如数仓中的代理键
            • 类型4 微型维度
            • 类型5 类型1+微型维度
            • 类型6 类型1+类型2+类型3
            • 类型7 双类型1+类型2

SCD类型	维度表行动	对事实分析的影响
类型0	属性值无变化	事实与原始值相关联
类型1	重写属性值	事实与当前值相关联
类型2	为新属性值增加新行	事实与发送时的有效值关联
类型3	增加新列来存储当前和原先值	事实与当前和先前值关联
类型4	增加对快速变化维的微型维度	事实与有效的变化范围关联
类型5	增加类型4和主维度表的类型1外键	事实与有效的变化范围关联
类型6	用类型3方法新增列，历史值用类型2处理，当前值用类型1处理	事实与有效的变化范围，当前值关联
类型7	增加储存最新值的维度表或视图	事实与有效的变化范围，当前值关联

总结

1、事实表就是你要关注的内容；
2、维度表就是你观察该事务的角度，是从哪个角度去观察这个内容的。
例如，某地区商品的销量，是从地区这个角度观察商品销量的。事实表就是销量表，维度表就是地区表。

数据组织类型

维度模型按数据组织类型划分可分为星型模型、雪花模型、星座模型

星型模型

• 组成
  • 由一个事实表和一组维表组成
  • 每个维度表都有一个维作为主键，所有这些维的主键组合成事实表的主键
• 优点
  • 维度更少，减少表连接的次数，可以显著提升查询效率
• 缺点
  • 星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，所以数据有一定的冗余

雪花模型

• 组成
  • 由一个事实表和一组维表组成
  • 一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上
• 优点
  • 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余

星座模型

• 组成
  • 由多个事实表和一组维表组成
  • 星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合
  • 星座模型只反映是否有多个事实表，他们之间共享一些维度表

怎么数据建模？

范式建模法(其实就说关系建模)

• 数据仓库之父Bill Inmon推崇，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。

• 一般遵循3NF范式。

  • 列不可再分
  • 所有的列必须依赖主键
  • 如果出现部分列不依赖主键，将这些列重新构建一张表

• 优点：

  • 从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。
  • 采用关系型设计的数据库一般具有较强的灵活性和多功能性
  • 规范性较好，冗余小，数据集成和数据一致性方面得到重视

• 缺点：

  • 由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求
  • 需要全面了解企业业务、数据和关系；实施周期非常长，成本昂贵；对建模人员的能力要求也非常高，容易烂尾。

• 它更多是面向数据的整合和一致性治理

维度建模法

• 数据仓库领域大师Ralph Kimball 倡导
• 按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式
  • 星型模式之所以广泛被使用，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等
  • 通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对 3NF的建模方法，星型模式在性能上占据明显的优势
• 维度建模法的另外一个优点
  • 维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。
  • 同时还有较好的大规模复杂查询的响应性能，更直接面向业务。
  • 技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能
• 缺点：
  • 由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作
  • 而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理
  • 而在这些与处理过程中，往往会导致大量的数据冗余
  • 如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性
  • 而且在数据仓库的底层，不是特别适用于维度建模的方法。
  • 维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。
• 维度建模的领域主要适用与数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题，解决用户如何更快速完成分析需求，
  • 一个大的中心事实表加一系列的维表。
  • 这种模型一般是有比较高的访问性

这里记住一个结论：关系模型对数据仓库是理想的基础，而星形模型对于数据集市是最佳的

实体建模法

实体建模认为任何业务都可以看成3个部分

• 实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。
• 事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。
• 说明，主要是针对实体和事件的特殊说明

举个例子：小明开车去学校上学，就以这个业务事实为例，我们可以把小明，学校，看成是实体，上学描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。

由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。

缺点：由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。

标签：模型,数据仓库,建模,维度,数据,事实
来源： https://blog.csdn.net/qq_58732706/article/details/121536184

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。