数据仓库维度建模知识讲解
数据仓库多维数据模型的设计
1、数据仓库基本概念1.1、主题（Subject）主题就是指我们所要分析的具体方面。
例如：某年某月某地区某机型某款App的安装情况。
主题有两个元素：一是各个分析角度（维度），如时间位置；二是要分析的具体量度，该量度一般通过数值体现，如App安装量。
1.2、维（Dimension）维是用于从不同角度描述事物特征的，一般维都会有多层（Level：级别），每个Level 都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。
1.3、分层（Hierarchy）OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。
所以我们一般会在维的基础上再次进行分层，维、分层、层级的关系如下图：每一级之间可能是附属关系（如市属于省、省属于国家），也可能是顺序关系（如天周年），如下图所示：1.4、量度量度就是我们要分析的具体的技术指标，诸如年销售额之类。
它们一般为数值型数据。
我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。
1.5、粒度数据的细分层度，例如按天分按小时分。
1.6、事实表和维表事实表是用来记录分析的内容的全量信息的，包含了每个事件的具体要素，以及具体发生的事情。
事实表中存储数字型ID以及度量信息。
维表则是对事实表中事件的要素的描述信息，就是你观察该事务的角度，是从哪个角度去观察这个内容的。
事实表和维表通过ID相关联，如图所示：1.7、星形/雪花形/事实星座这三者就是数据仓库多维数据模型建模的模式上图所示就是一个标准的星形模型。
雪花形就是在维度下面又细分出维度，这样切分是为了使表结构更加规范化。
雪花模式可以减少冗余，但是减少的那点空间和事实表的容量相比实在是微不足道，而且多个表联结操作会降低性能，所以一般不用雪花模式设计数据仓库。
大数据分析基础——维度模型
大数据分析基础——维度模型大数据分析基础——维度模型1基本概念维度模型的概念出自于数据仓库领域，是数据仓库建设中的一种数据建模方法。
维度模型主要由事实表和维度表这两个基本要素构成。
1.1维度维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。
维度属于一个数据域，如地理维度(其中包括国家、地区、省以及城市等级别的内容)、时间维度(其中包括年、季、月、周、日等级别的内容)。
维度是维度建模的基础和灵魂。
在维度建模中，将度量称为“事实” ，将环境描述为“维度”，维度是用于分析事实所需要的多样环境。
例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。
维度所包含的表示维度的列，称为维度属性。
维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。
1.2事实表事实表是维度模型的基本表，每个数据仓库都包含一个或者多个事实数据表。
事实数据表可能包含业务销售数据，如销售商品所产生的数据，与软件中实际表概念一样。
事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。
事实表中一条记录所表达的业务细节程度被称为粒度。
通常粒度可以通过两种方式来表述:一种是维度属性组合所表示的细节程度:一种是所表示的具体业务含义。
作为度量业务过程的事实，一般为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型。
相对维度来说，通常事实表要细长，行的增加速度也比维度表快的多，维度表正好相反。
事实表有三种类型 :1.事务事实表：事务事实表用来描述业务过程，眼踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为“原子事实表\周期快照事实表”。
2.周期快照事实表：周期快照事实表以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。
3.累积快照事实表：累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。
数据仓库建模方法论
数据仓库建模方法论数据仓库建模是指将数据仓库中的数据按照某种标准和规范进行组织和管理的过程。
数据仓库建模方法论包括了多种方法和技术，用于帮助用户理解和分析数据仓库中的数据，从而支持决策制定和业务分析。
一、维度建模方法维度建模方法是数据仓库建模的核心方法之一，它以维度为核心，将数据按照维度进行组织和管理，从而提供给用户灵活和高效的数据查询和分析能力。
1.1 星型模型星型模型是最常见和简单的维度建模方法，它将数据仓库中的事实表和多个维度表通过共享主键的方式进行关联。
事实表包含了衡量业务过程中的事件或指标，而维度表包含了用于描述和过滤事实记录的属性。
星型模型的结构清晰，易于理解和使用，适用于绝大部分的数据仓库场景。
1.2 雪花型模型雪花型模型是在星型模型的基础上进行扩展和优化的一种模型，它通过拆分维度表中的属性，将其拆分为多个维度表和子维度表，从而使得数据仓库更加灵活和高效。
雪花型模型适用于维度表中的属性比较复杂和层次结构比较多的情况。
1.3 天际线模型天际线模型是一种比较先进和复杂的维度建模方法，它通过将事实表和维度表按照一定的规则进行分组和划分，从而实现多个星型模型之间的关联。
天际线模型适用于数据仓库中包含多个相互关联的业务过程和多个不同的粒度的情况。
二、多维建模方法多维建模方法是在维度建模方法基础上进行进一步抽象和简化的一种方法，它通过创建多维数据立方体和维度层次结构来组织和管理数据。
2.1 数据立方体数据立方体是多维建模的核心概念，它将数据按照事实和维度进行组织和管理，从而提供给用户直观和高效的数据查询和分析能力。
数据立方体包含了多个维度和度量，用户可以通过选择和组合维度和度量进行数据分析和挖掘。
2.2 维度层次结构维度层次结构是多维建模的关键技术，它通过将维度进行分层和组织，从而实现维度之间的关联和上下级关系。
维度层次结构可以有效地减少数据的冗余和复杂性，提高数据仓库的查询和分析效率。
三、模式设计方法模式设计方法是在维度建模方法和多维建模方法的基础上进行进一步的抽象和规范的一种方法，它通过定义模式和规则来组织和管理数据仓库中的数据。
通俗易懂数仓建模—Inmon范式建模与Kimball维度建模
通俗易懂数仓建模—Inmon范式建模与Kimball维度建模在数据仓库领域，有两位大师，一位是“数据仓库”之父B i l l I n m o n，一位是数据仓库权威专家R a l p h K im ba l l，两位大师每人都有一本经典著作，I n m o n大师著作《数据仓库》及K im ba l l大师的《数仓工具箱》，两本书也代表了两种不同的数仓建设模式，这两种架构模式支撑了数据仓库以及商业智能近二十年的发展。
今天我们就来聊下这两种建模方式——范式建模和维度建模。
本文开始先简单理解两种建模的核心思想，然后根据一个具体的例子，分别使用这两种建模方式进行建模，大家便会一目了然！一、两种建模思想对于In mo n和K i m ba l l两种建模方式可以长篇大论叙述，但理论是很枯燥的，尤其是晦涩难懂的文字，大家读完估计也不会收获太多，所以我根据自己的理解用通俗的语言提炼出最核心的概念。
范式建模范式建模是数仓之父In mo n所倡导的，“数据仓库”这个词就是这位大师所定义的，这种建模方式在范式理论上符合3N F，这里的3N F与O L T P中的3N F还是有点区别的：关系数据库中的3N F是针对具体的业务流程的实体对象关系抽象，而数据仓库的3N F是站在企业角度面向主题的抽象。
I n m o n模型从流程上看是自上而下的，自上而下指的是数据的流向，“上”即数据的上游，“下”即数据的下游，即从分散异构的数据源-> 数据仓库-> 数据集市。
以数据源头为导向，然后一步步探索获取尽量符合预期的数据，因为数据源往往是异构的，所以会更加强调数据的清洗工作，将数据抽取为实体-关系模型，并不强调事实表和维度表的概念。
维度建模K i m b al l模型从流程上看是自下而上的，即从数据集市-> 数据仓库-> 分散异构的数据源。
K i mb a l l是以最终任务为导向，将数据按照目标拆分出不同的表需求，数据会抽取为事实-维度模型，数据源经E T L转化为事实表和维度表导入数据集市，以星型模型或雪花模型等方式构建维度数据仓库，架构体系中，数据集市与数据仓库是紧密结合的，数据集市是数据仓库中一个逻辑上的主题域。
数据仓库 Chapter 11 维度建模：高级专题
用新的值覆盖维度表中的旧数值 属性的旧值不需要保留 对维度表没有其他修改 维度表种的键或任何其他键值均不受影响 这类修改是最容易实施的
Example：
维度表的更新
第1类修改：改正错误
键重构 3315 K1235
之前 客户键 客户名称 客户代码 婚姻 地址 省 PC. 3315 Susane Lee K1235 Single XMU，Xiamen Fujian 361005
第1类修改
客户代码：K1235 客户名称：Susan Lee
之后
3315 Susan Lee K1235 Single XMU，Xiamen Fujian 361005
维度表的更新
第2类修改：保存历史数据
键重构 3315 3316 8800 之前 客户键 客户名称 客户代码 婚姻 地址 省 PC. 第2类修改 K12356 客户代码：K1235 婚姻：Married 地址：NWPU，xian 省：Shaanxi PC.710072 8800 Susan Lee K1235 Married NWPU，Xian Shaanxi 710072 2000.11.1后
一般原则
他们通常与源系统的临时修改相关 需要利用新旧属性的值跟踪历史数据 新旧两个值用于比较改变所带来的效果 他们提供了前向和后向的跟踪能力 对受影响的属性，在维度表中加入“旧的”字段 将“现有”字段的值赋给“旧的”字段 将新值赋给“现有”字段 加入一个“现有”有效日期 记录的键不受影响 不需要增加新的维度表记录 现有的查询可以无缝转移到“现有”的值 所有使用到“旧的”值的查询需要作相应的修改 这种技术对一次只做一个临时修改适用（修改多了？？？） 如果还有后续的修改，则需要使用更复杂的技术
维度建模粒度的概念
维度建模粒度的概念
维度建模是一种数据建模的方法，主要用于数据仓库的构建。
在维度建模中，粒度是一个重要的概念，它决定了数据仓库中数据的细化程度。
粒度是指数据仓库的数据单位中保存数据的细化程度的级别。
简单来说，粒度是指事实表中存储的数据的汇总程度。
如果事实表中存储的是具体的每一笔销售记录，则粒度较小；如果存储的是每种商品的日销售总额的记录，则粒度较大。
选择合适的粒度，可以决定数据仓库的规模，并影响分析查询的计算量。
在数据仓库构建中，通常会分为两层：一层是操作数据存储（ODS），存储粒度较小的细节数据；另一层是数据仓库，在ODS的基础上，存储粒度较大
的汇总数据。
因此，粒度是维度建模中一个重要的概念，它决定了数据仓库中数据的详细程度和汇总程度，进而影响数据分析和查询的效果。
如需更多关于“维度建模粒度”的信息，建议咨询统计学专家或查阅统计学相关书籍。
数仓学习-维度建模
数仓维度建模（如有侵权请联系删除）一、什么是维度建模按照事实表，维度表来构建数据仓库，数据集市。
将数据结构化的逻辑设计方法，它将客观世界划分为度量和上下文。
二、维度建模的优势和原则1、优势和缺点a) 维度建模是可预测的标准框架。
允许数据库系统和最终用户查询工具在数据方面生成强大的假设条件，这些数据主要在表现和性能方面起作用。
b) 星型连接模式的可预测框架能够忍受不可预知的用户行为变化。
c) 具有非常好的可扩展性，以便容纳不可预知的新数据源和新的设计决策。
可以很方便在不改变模型粒度情况下，增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变而重新编码。
较好的扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的结果。
但是，维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。
而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。
而在这些与处理过程中，往往会导致大量的数据冗余。
另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
2、维度建模的原则原则1、载入详细的原子数据到维度结构中维度建模应该使用最基础的原子数据进行填充，以支持不可预知的来自用户查询的过滤和分组请求，用户通常不希望每次只看到一个单一的记录，但是你无法预测用户想要掩盖哪些数据，想要显示哪些数据，如果只有汇总数据，那么你已经设定了数据的使用模式，当用户想要深入挖掘数据时他们就会遇到障碍。
当然，原子数据也可以通过概要维度建模进行补充，但企业用户无法只在汇总数据上工作，他们需要原始数据回答不断变化的问题。
原则2、围绕业务流程构建维度模型业务流程是组织执行的活动，它们代表可测量的事件，如下一个订单或做一次结算，业务流程通常会捕获或生成唯一的与某个事件相关的性能指标，这些数据转换成事实后，每个业务流程都用一个原子事实表表示，除了单个流程事实表外，有时会从多个流程事实表合并成一个事实表，而且合并事实表是对单一流程事实表的一个很好的补充，并不能代替它们。
维度建模和指标体系构建
维度建模和指标体系构建01数仓建模综述数据建模是数据开发工作中的核心与基石，好的模型体系好处很多：•降低成本：优秀的模型设计能够提升数据复用性，减少计算/存储资源浪费•提升开发效率：优秀的模型设计能够降低数据使用门槛，减少工作量•提升质量：优秀的模型设计能够保证数据口径一致，降低bug率数据建模的实现方式有很多，常用的比如ER模型，Data Vault模型等。
目前业界使用最多的模型是Ralph Kimball 在《数据仓库工具》中提出的维度建模模型，其中典型的代表如星型模型，雪花模型。
一个典型的维度建模一般需要经过如下几个步骤：1.业务调研：调研需要建模的业务形态，划分基本的业务线/数据域2.层次设计：定义数仓层级，保证各层级之间职责明确，划分清晰3.规范设计：定义数仓中表/字段的命名规范，建立统一的指标体系4.事实表设计：根据单一/复合业务过程确定事实表主题，确定最小粒度5.维度表设计：根据业务确定实体，补充实体属性字段优秀的层次设计可以保证数仓表数量在可控范围内增长，同时保证数据产出流逻辑清晰，便于后期维护和扩展。
良好的规范设计规定了统一的命名规则，保证各个业务过程的实体/指标的完备和唯一性。
02设计原则按照《大数据之路——阿里巴巴大数据实战》，维度建模应该符合以下几个规范1.高内聚，低耦合：从业务流程和数据访问特性两个角度考虑，针对业务粒度相近，业务流程相近的数据应该放在同一个表中（例如广告数仓中通常会把广告的点击/曝光/转化多个业务过程数据放在同一个宽表中），针对经常要在同一个场景下访问的数据，也应该放在同一个表内。
2.公共处理逻辑下沉和单一：公用的逻辑应该封装在底层表中，避免公用逻辑直接暴露给上层，同一个公共逻辑需要收敛，避免在多个地方同时存在3.适当冗余：考虑到mr/rdd计算框架下join运算的资源损耗，可以通过适当冗余字段处理减少join操作4.命名一致/可理解：同一个业务含义的字段命名必须相同，且直观可读。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
▪ 数据仓库团队经常绕过这个看似不必要的步骤 ▪ 一个不合适的粒度定义将会使维度建模感觉无从下手四步Leabharlann －2.定义粒度(2)❖ 原则：
▪ 优先考虑具有原子粒度的业务信息，这些数据不能再 做进一步的细分
▪ 数据仓库中存储汇总的、概要性的数据主要是基于数 据库性能上的考虑
▪ 汇总数据不能成为最底层细节数据的替代品
利润
日期维度
日期关键字(PK) 待定日期属性
商场维度
商场关键字(PK) 待定商场属性
POS零售营销事务事实
日期关键字(FK) 产品关键字(FK) 商场关键字(FK) 促销关键字(FK) POS事务编号 销售量 销售额 成本额 毛利润金额
产品维度
产品关键字(PK) 待定产品属性
促销维度
促销关键字(PK) 待定促销属性
实例－2.定义粒度
❖ 定义粒度：
▪ 你还记得刚才的粒度定义原则吗？ ▪ 在这个连锁店我们应该使用什么样的粒度？即事实表
要详细到什么程度？
实例－3.选定维度
❖ 选定维度：
▪ 如何得出基本维度？ ▪ 什么是附加维度？
▪ 通过粒度的判断我们可以得出事实表的基本维度为： 日期、产品、商店与促销
日期维度
日期关键字(PK) 待定日期属性
四步曲－3.选定维度
❖ 误区：
▪ 没有定义粒度就开始选定维度
❖ 原则：
▪ 在粒度确认后，选取能从各个角度，充分描述问题的 维度
▪ 为每个维度添加丰富的维度属性
❖ 示例：
▪ 常见维度包括日期、产品、顾客、事务类型和状态
四步曲－4.确定事实
❖ 误区：
▪ 没有第2步的粒度确认，就开始确定事实 ▪ 将含有不同粒度的事实放在了同一个事实表中
维度表属性－促销维度
❖ 促销维度属性
▪ 是否还可以列出其它属性
促销维度
促销关键字(PK) 促销名称 促销媒体类型 促销开始日期 促销结束日期 。。。及其它
Kimbal极力反对的做法
❖ 极力反对的做法
▪ 维度模型的规范化处理（雪花模型） ▪ 事实表拥有太多的维度
商场维度
商场关键字(PK) 待定商场属性
POS零售营销事务事实
日期关键字(FK) 产品关键字(FK) 商场关键字(FK) 促销关键字(FK) POS事务编号 待定事实
产品维度
产品关键字(PK) 待定产品属性
促销维度
促销关键字(PK) 待定促销属性
实例－4.确定事实
❖ 确定事实：
▪ 是否还记得确定事实的基本原则？ ▪ 按照基本原则你认为事实表中应该包含哪些事实？ ▪ 是否应该在事实表中存放计算列？ ▪ 实例中事实应包括销售量、销售额与成本价，当然也可以包括毛
维度表属性－产品维度
❖ 产品维度属性
▪ 是否还可以列出其它属性
产品维度
产品关键字(PK) 产品描述 SKU编号 商标描述 子类描述 分类描述 部门描述 包装类型 包装尺寸 含脂量 。。。及其它
维度表属性－商场维度
❖ 商场维度属性
▪ 是否还可以列出其它属性
商场维度
商场关键字(PK) 商场名称 商场编号 商场所在行政区 商场所在地区 首次开业日 最后重修日 。。。及其它
❖ 原则：
▪ 针对业务流程进行维度建模 ▪ 确保某个业务流程中的核心数据只被抽取一次 ▪ 保证数据仓库中业务数据一致性
四步曲－2.定义粒度(1)
❖ 粒度的解释：
▪ 粒度传递了同事实表度量值相联系的细节所达到的程 度方面的信息。
▪ 简单的说，反映了事实表的明细程度
❖ 粒度举例：
▪ 超市小票上的购物清单 ▪ 医生的处方药品清单 ▪ 仓库每种产品库存值的月快照
▪ 1.选取要建模的业务流程 ▪ 2.定义业务流程中的数据粒度 ▪ 3.选定用于每个事实表行的维度 ▪ 4.确定用于形成每个事实表行的数字型事实
四步曲－1.选取业务流程
❖ 误区：
▪ 不针对业务流程而针对业务部门进行维度建模 ▪ 将注意力放在业务部门身上，而不关注业务流程 ▪ 为某个部门建立单独的维度模型
❖ 原则：
▪ 确定用于形成每个事实表行的数字可加型事实 ▪ 在需求调研时我们可以通过提出“您需要对哪些指标
进行统计？”这样的问题来确定事实。 ▪ 具有不同粒度的事实必须放在不同的事实表中 ▪ 事实一般在各维度上都有良好的可加性
四步曲－总结
❖ 维度建模总原则：
▪ 数据驱动和需求驱动相结合
业务需求
维度模型 1.业务处理 2.粒度 3.维度 4.事实
实例－1.选取业务流程
❖ 选取业务流程：
▪ 你能列出该连锁店急待解决的问题吗？ ▪ 是否有系统能提供解决问题所需要的数据？ ▪ 该系统对应的业务流程你清楚吗？
❖ 注意：
▪ 建立的第一个维度模型应该是一个最有影响的模型， 即它应该能对最紧迫的业务问题做出正面回答，并且 要保证有足够的操作型数据源的支持。
▪ 数据仓库维度建模就是大厦的框架建设工作 ▪ 数据仓库ETL过程，就是为大厦添砖加瓦的过程 ▪ 优秀数据访问工具则是大厦整体装修的最佳工具
❖ 框架的重要性
▪ 地基打多深决定大厦能做多高。 ▪ 钢筋混凝土结构还是刚结构决定了大厦的稳定性 ▪ 维度建模是数据仓库框架建设的重要技术
维度建模四步曲
❖ 四步维度建模步骤：
维度表属性
❖ 添加维度表属性
▪ 这是维度建模的最后修补工作 ▪ 增加的维度属性会为用户带来更多的查询条件 ▪ 丰富的维度属性将使查询变得更加灵活
维度表属性－日期维度
❖ 日期维度属性
▪ 是否还可以列出其它属性
日期维度
日期关键字(PK) 日期 星期 日历周结束日期 日历月 日历年月 日历季度 日历年季度 日历半年度 节假日指示符 。。。及其它
数据仓库维度建模
学习目的
❖ 在课程结束后应该知道：
▪ 数据仓库维度建模分哪几个步骤？ ▪ 每个步骤都有哪些原则，和哪些误区？ ▪ 掌握维度建模方法 ？ ▪ 维度表属性在维度模型中起到什么样的作用？ ▪ Kimball极力反对哪些建模方法？
一个比喻
❖ 比喻：
▪ 如果将数据仓库建设看作是一个高楼大厦建造过程的 话
实际数据
零售业案例背景
❖ 背景：
▪ 设想一下在一家大型杂货连锁店，其业务覆盖分布在 美国5个州范围内的100多家杂货店。
▪ 每个商店都有完整的配套部门，包括各类人员，并有 大致60000多个品种的产品放在货架上。
▪ 各杂货店的POS系统记录了每位顾客交易详的细信息 ▪ 定价与促销是管理层重要决策之一 ▪ 如何使各种形式的促销活动所产生的效能清晰可见？