数据仓库工具箱的考点参考

数据仓库工具箱仅作参考、必有纰漏，望指正
下文中的页数对应的教材为
清华大学出版社的数据仓库工具箱（第三版）-------维度建模权威指南
标注页码主要是我懒，没书的可以提取电子版
添加链接描述链接：https://pan.baidu.com/s/1RV6Os6lKbh8G2yDfFjWYFA
提取码：aust

最终版本 链接如下 蓝奏云直接下载

https://wws.lanzous.com/i33e2i9m89g

1A什么是数据仓库

数据仓库，英文名称 Data Warehouse，简写为DW。数据仓库顾名思义，是一个很大的数据存储集合，出于企业的分析性报告和决策支持目的而创建，对多样的业务数据进行筛选与整合。它为企业提供一定的BI（商业智能）能力，指导业务流程改进、监视时间、成本、质量以及控制。它是面向决策的。
数据仓库的输入方是各种各样的数据源，最终的输出用于企业的数据分析、数据挖掘、数据报表等方向。（数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。）

1B 数据仓库和普通的操作型数据库有什么区别

（1） 面向主体：操作型数据库的数据面向事务处理，各个业务系统间各自分离；数据仓库的数据按主题进行组织；
（2） 集成：面向事务处理的操作型数据库通常和某些特定的应用相关，数据库之间相互独立，往往是异构的；数据仓库的数据是对原有分散数据库数据通过抽取、清理然后经系统加工、汇总、整理得到，消除了源数据中的不一致性。
（3） 相对稳定：操作型数据库中的数据是实时更新的；数据仓库的数据用来查询，只有少量的修改和删除操作，通常只需定期加载、刷新。
（4） 反映历史变化：操作型数据库主要关心当前某一个时间段内的数据；数据仓库的数据通常包含历史信息。
（操作型数据库：面对很多用户，并发事务很多。多是插入，更新操作。对数据的插入，更新性能要求更高，因此数据多是规范化的，规范化是指冗余度比较少。字段都拆开了。往往针对当前数据。
数据仓库：往往面对比较少的用户，进行分析查询。就是比较复杂的sql了。select操作比较多。数据往往需要一些冗余度，就是要反规范化。往往针对当前数据和历史数据。
数据仓库往往是在操作型数据库基础之上形成的专门用于分析的数据。
但是，数据仓库和操作型数据库的分离度越高越好。
由于数据仓库的构建过程中，往往需要有新的应用和主题加入。所以需要有较好的扩展性。
针对管理者提供的操作性界面。以及提供分析结果的流程。也要尽量简洁。易于理解。）

2，什么是事实表

在多维数据仓库中，保存度量值的详细值或事实的表称为“事实表”。事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性纬度表的主键，而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息，也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据

3，什么是维度表

维度表维度表可以看作是用户来分析数据的窗口，纬度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。例如，包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构，这些产品中的每一类进一步多次细分，直到各产品达到最低级别。添加链接描述
（https://www.cnblogs.com/wufengtinghai/archive/2013/05/04/3060265.html）二三详细地址

4，什么是支架表（对维度表建立的维度）(维度的维度)（书P72）

当一个属性集合（例如日期、地点）在某个维度或多个维度表中反复出现时，就可以考虑使用支架表添加链接描述（https://www.jianshu.com/p/a2fe0c3095a0）深入详细解释

二三四集合
事实表描述业务过程的度量、以可加数据为主题，每一行代表一个可以观察的实体或事件。主要的是发生了业务过程，如卖出一件商品，用户购买一件商品，这都触发了业务过程。卖出的商品有商品属性、有卖出的门店、有出货记录，有购物者信息等等。
维度表描述事实所处的环境、面向分析，代表针对事实的一种分类。直白点，维度表就是用来描述事实的。还以卖出商品为例，卖出的商品，商品有属性，包括颜色、尺码、风格、季节等多种属性，这些属性组合在一起就构成了描述商品的维度表。

对维度表再建立更细的维度，称为支架表。支架表是维度表的维度表，支架表是去冗余的产物，在星型模型中，对冗余很宽容。所以支架并不是必须的，并且应该尽量少用。合适的方法是：将支架表合并到和事实表直接连接的维度表。添加链接描述
（https://m.toutiao.com/i6880450117431001612/?traffic_source=CS1114&in_ogs=2&utm_source=HW&source=search_tab&utm_medium=wap_search&prevent_activate=1&original_source=2&in_tfs=HW&channel=）引用地址

五．什么是代理键

代理键是指在关系型数据库设计中，当资料表中的候选键都不适合当主键时，例如资料太长，或是意义层面太多，就会用一个attribute来当代理主键，此主键可能是用流水号，来代替可辨识唯一值的主键

六．什么是自然键

由现实世界中已经存在的属性组成的键。例如，美国公民被分配了一个唯一（不保证一定正确，但实际上非常接近唯一）的社会保险号（SSN）。如果隐私法允许的话，SSN可能被用作Person实体的自然键（假设组织的人员范围仅限于美国）。
五六解释不到位 自行看下链接
①添加链接描述（https://blog.csdn.net/yimubanggong/article/details/68922016?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param）
②添加链接描述（https://blog.csdn.net/haiross/article/details/21388997）

事实表中的数组度量分三种：1.可加事实，2.半可加事实，3.不可加事实

七．可加事实

可加事实指的是该度量可以按照和事实表关联的任一维度进行汇总。比如商品的单价，可以按照品类维度进行汇总，按照店铺维度进行汇总等等。

八．半可加事实

指的就是该度量在某些维度下不可进行汇总，或者说汇总起来没有意义，比如说价差额，价差额在时间维度下的汇总就没有意义。
记录静态数据（库存数据，金融账户余额）的所有度量针对于日期属性以及其它可能维度天然具有非可加性，但是例如库存数据针对产品种类或者商店汇总，是可加的，所以这种数据就是半可加事实。

九．不可加事实

指的是该度量在所有与该事实表关联的维度下都不可进行汇总，比如说比率型数据，对于这种数据，如果确实是有汇总的必要，可以将其分子分母分别存储，然后在最后汇总之后再进行除法操作，从而得到“汇总”后的比率型数据

十．粒度

在事实表中存放的每一行最小的单位叫粒度 按照每一个客户每一次购买的每一次具体的商品数量之和金额作为的存储单位，叫做粒度。粒度一方面控制了维度表，维度表里面时间上的粒度具体到某一天或者某一时刻。产品的粒度具体到品牌，还是品牌下的型号。粒度和维度表相关和事实表也相关

十一．微型维度

十二．ETL 抽取变化转换

ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础
ETL数据通常分为两大类，一，开始的第一次数据仓库加载，需要进行数据装载 二，在日常中，数据仓库的更新（按照每天一次或每月一次或按照数据库）把数据从操作型数据库中抽出数据放在数据仓库里面。。这就是ETL
{在数据仓库里面的工作一般分为两个。一搭建数据仓库，二写程序做ETL，剩下的就是用户根据数据仓库的数据用各种工具进行分析}

十三．下钻 上卷 切片

数据进行数据查询，按照部门进行查询，部门下有各个子部门的工作，根据子部门进行查询 按照年2019 2020查询，查询结束后接着下钻，按照2019每个月进行查询，2020每个月，再进行分析 越来越详细

十四．杂项维度（书P33 2.3.12）

维度表中（数据仓库中）有很多的维度，其中有维度有较少的（如两到三个）属性，这类的不保存的话可能后面会用到，保存了维度多了就比较乱；对于这类维度合并起来叫做杂项维度

十五．雪花维度（书P33 2.3.13）

一个太阳和周边众多的星星模式的叫星型 一个中心，有分支，分支上面还有分支，叫做雪花

十六．总线矩阵（书P35）

十七．退化维度（书P32 2.3.5）

什么是退化维度（Degenerate Dimension,DD），就是那些看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表，其中，事实表的粒度就是文档本身或文档中的一个分列项。
具体怎么理解呢？在传统的父子关系型数据库中，事务编号是事物标题记录的关键字，比如订单编号、发票编号，这样的纪录包含了诸如事务日期、供应商标示这样在总体上对事务有效的所有信息。但在给出的维度模型中，已经将这些令人感兴趣的标题信息抽取出来放到其它维度中去了。但这个事务编号仍然十分有用，因为它可以作为组关键字而将单个事务中处理的明细集中在一起。
尽管这个事务维度看起来是一个维度关键字，但当把事务维度所有的描述性项目进行剔出后，形成维度为空。诸如这种事务编号、固有的操作型票据编号，应该自然的放入事实表中，而不用连接到维度表。退化维度在事实表粒度表示单个事务或事务分列项目时是很常见的，因为它标示父实体的惟一标示。订单号，发票号与提货单编号等几乎总是以退化维度的形式出现在维度模型之中。
同时，退化维度在事实表主关键字方面也有一定作用。比如将订单事实表主关键字可以由退化的订单编号和产品组关键字组成。

十八．蜈蚣事实表（书P38 2.7.2）（P72）

是中间有个事实表，周围有很多维度（维度很多）（年维度，月维度等）看起来像蜈蚣一样。蜈蚣事实表是需要避免的，如何处理蜈蚣事实表，把维度整合

十九．代理键 日期智能代理键区别

二十．代理键 事实表代理键（书P32 P69）

Q：事实表可不可以使用代理，键事实表代理键有什么好处（可以使用，方便了做事实的加载的规模和目的）

二十一．事实事务表

二十二．周期快照事实表（P30）（书P82）

二十三．累积快照事实表（P30）（书P82）

二十四．缓慢变化维度方法（书P113 5.5图5-17）

二十五．维度建模设计的过程

①确定业务（流程）②确定粒度③设计维度表④设计事实表
搞清楚业务流程，达成共识确定粒度（根据粒度来设计维度表事实表）
维度评判标准；下钻上卷切片时可以看见哪些数据
事实表设计，可加事实半可加事实如何处理
（参考：第一步 选取业务处理
业务处理过程是机构中进行的一般都由源系统提供支持的自然业务活动。听取用户的意见是选取业务处理过程的效率最高的方式。在选取业务阶段，数据模型设计者需要具有全局和发展的视角，应该理解整体业务流程的基础上，从全局角度选取业务处理。
要记住的重要一点是，这里谈到的业务处理过程并不是指业务部门或者职能。通过将注意力集中放在业务处理过程方面，而不是业务部门方面，就能在机构范围内更加经济地提交一致的数据。如果建立的维度模型是同部门捆绑在一起的，就无法避免出现具有不同标记与术语的数据拷贝的可能性。多重数据流向单独的维度模型，会使用户在应付不一致性的问题方面显得很脆弱。确保一致性的最佳办法是对数据进行一次性地发布。单一的发布过程还能减少ETL的开发量，以及后续数据管理与磁盘存储方面的负担。
第二步 定义粒度
粒度定义意味着对各事实表行实际代表的内容给出明确的说明。粒度传递了同事实表度量值相联系的细节所达到的程度方面的信息。它给出了后面这个问题的答案:“如何描述事实表的单个行?”。
粒度定义是不容轻视的至关重要的步骤。在定义粒度时应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子型数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。通过在最低层面上装配数据，大多原子粒度在具有多个前端的应用场合显示出其价值所在。原子型数据是高度维结构化的。事实度量值越细微并具有原子性，就越能够确切地知道更多的事情，所有那些确切知道的事情都转换为维度。在这点上，原子型数据可以说是维度方法的一个极佳匹配。
原子型数据可为分析方面提供最大限度的灵活性，因为它可以接受任何可能形式的约束，并可以以任何可能的形式出现。维度模型的细节性数据是稳如泰山的，并随时准备接受业务用户的特殊攻击。
当然，可以总是给业务处理定义较高层面的粒度，这种粒度表示最具有原子性的数据的聚集。不过，只要选取较高层面的粒度，就意味着将自己限制到更少或者细节性可能更小的维度上了。具有较少粒度性的模型容易直接遭到深入到细节内容的不可预见的用户请求的攻击。聚集概要性数据作为调整性能的一种手段起着非常重要的作用，但它绝对不能作为用户存取最低层面的细节内容的替代品。遗憾的是，有些权威人士在这方面一直显得含糊不清。他们宣称维度模型只适合于总结性数据，并批评那些认为维度建模方法可以满足预测业务需求的看法。这样的误解会随着细节性的原子型数据在维度模型中的出现而慢慢地消逝。
第三步 选定维度
维度所引出的问题是，“业务人员将如何描述从业务处理过程得到的数据?”应该用一组在每个度量上下文中取单一值而代表了所有可能情况的丰富描述，将事实表装扮起来。如果对粒度方面的内容很清楚，那么维度的确定一般是非常容易的。通过维度的选定，可以列出那些使每个维度表丰满起来的离散的文本属性。常见维度的例子包括日期、产品、客户、账户和机构等。
第四步 确定事实
设计过程的第四步同时也是最后一步，在于仔细确定哪些事实要在事实表中出现。事实的确定可以通过回答“要对什么内容进行评测”这个问题来进行。业务用户在这些业务处理性能度量值的分析方面具有浓厚的兴趣。设计中所有供选取的信息必须满足在第2步中定义的粒度要求。明显属于不同粒度的事实必须放在单独的事实表中。通常可以从以下三个角度来建立事实表[2]：
1、针对某个特定的行为动作，建立一个以行为活动最小单元为粒度的事实表。最小活动单元的定义，依赖于分析业务需求。比如用户的一次网页点击行为、一次网站登录行为，一次电话通话记录。这种事实表，主要用于从多个维度统计，行为的发生情况，主要用于业务分布情况，绩效考核比较等方面的数据分析。
2、针对某个实体对象在当前时间上的状况。我们通过对这个实体对象在不同阶段存储它的快照，比如账户的余额、用户拥有的产品数等，通过这种可以统计实体对象在不同的生命周期中的关键数量指标。
3、针对业务活动中的重要分析和跟踪对象，统计在整个企业不同业务活动中的发生情况。比如会员，可以执行或参与多个特定的行为活动。这种事实表是以上两种事实表的一个总结和归纳。它主要用于针对我们业务中的活动对象进行跟踪和考察。）

二十六．星型模型 雪花模型的区别

一个太阳和周边众多的星星模式的叫星型 一个中心，有分支，分支上面还有分支，叫做雪花

这里是引用
当今数据仓库建模主要分为两类：范式建模和维度建模
范式建模是基于三范式标准进行建模，好处是高度集成，易于管理和维护，但坏处是结构死板，周期过长
维度建模是依据事实表和维度表结合应用所产生的一种模型结构，好处是构建迅速，最快看到回报，坏处是不好维护，结构复杂
实际应用中一般是范式建模和维度建模相结合，这里讲下维度模型下的两个主要分类：雪花模型和星型模型
星型模型：由一个事实表和一组维表直接组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的外键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表，优点是所有字段均已连接，方便OLAP，缺点是数据可能会造成冗余；

雪花模型：事实表与一组维度表组成，但维度表不一定全部直接关联于事实表，形状如雪花一样，好处是数据不会冗余，坏处是数据关联join太多，不利于OLAP。

通俗区别：看是否所有的维度表都全部直接关联在事实表上，如果是则为星型，反之为雪花。简单来说星型模型是明细表，雪花模型是主表

添加链接描述