Kimball维度建模常见考点

什么范式建模和维度模型？还有其他哪些建模方式？

一、范式建模

这种建模方式在范式理论上符合 3NF，这里的 3NF 与 OLTP 中的 3NF 还是有点区别的：关系数据库中的 3NF 是针对具体的业务流程的实体对象关系抽象，而数据仓库的 3NF 是站在企业角度面向主题的抽象。

Inmon 模型从流程上看是自上而下的，自上而下指的是数据的流向，“上”即数据的上游，“下”即数据的下游，即从分散异构的数据源 -> 数据仓库 -> 数据集市。以数据源头为导向，然后一步步探索获取尽量符合预期的数据，因为数据源往往是异构的，所以会更加强调数据的清洗工作，将数据抽取为实体-关系模型，并不强调事实表和维度表的概念。

二、维度建模

Kimball 模型从流程上看是自下而上的，即从数据集市-> 数据仓库 -> 分散异构的数据源。Kimball 是以最终任务为导向，将数据按照目标拆分出不同的表需求，数据会抽取为事实-维度模型，数据源经 ETL 转化为事实表和维度表导入数据集市，以星型模型或雪花模型等方式构建维度数据仓库，架构体系中，数据集市与数据仓库是紧密结合的，数据集市是数据仓库中一个逻辑上的主题域。

参考：通俗易懂数仓建模—Inmon 范式建模与 Kimball 维度建模 - 知乎

三、其他建模方法

• Data Vault模型
• Anchor模型

 参考：一篇文章讲清楚数据仓库模型设计！-阿里云开发者社区

什么是三方式（3NF）？

设计关系型数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

目前关系型数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）和第五范式（5NF，又称完美范式）。一般来说，数据库只需要满足第三范式就行了。

第一范式(1NF)：属性不可分割，即每个属性都是不可分割的原子项。(实体的属性即表中的列)

• 确保列的原子性

第二范式(2NF)：满足第一范式；且不存在部分依赖，即非主属性必须完全依赖于主属性。(主属性即主键；完全依赖是针对于联合主键的情况，非主键列不能只依赖于主键的一部分)

• 确保只描述一个事情，剔除冗余

第三范式(3NF)：满足第二范式；且不存在传递依赖，即非主属性不能与非主属性之间有依赖关系，非主属性必须直接依赖于主属性，不能间接依赖主属性。（A -> B, B ->C, A -> C）

• 确保只描述一个事情，剔除冗余

参考：数据库三范式是什么？(3NF详解)-CSDN博客

数据集市和数据仓库的区别

什么星型模型和雪花模型？

据事实表和维度表之间的关系，我们将常见的模型分为星型模型和雪花模型。

雪花模型去除了冗余，设计复杂，可读性差，关联的维度表多，查询效率低，但是可扩展性好。
星型模型冗余度高，设计简单，可读性高，关联的维度表少，查询效率高，可扩展性低。

一、星型模型
星型模型：当所有的维度表都是和事实表直接相连的时候，整个图形看上去就像是一个星星，我们称之为星型模型。星型模型是一种非正规化的架构，因为多维数据集的每一个维度都和事实表直接相连，不存在渐变维度，所以有一定的数据冗余，因为有数据的冗余，很多的统计情况下，不需要和外表关联进行查询和数据分析，因此效率相对较高。

二、雪花模型
雪花模型：当有多个维度表没有直接和事实表相连，而是通过其它的维度表，间接的连接在事实表上，其图形就像是一个雪花，因此我们称之为雪花模型，雪花模型的优点是减少了数据冗余，在进行数据统计或分析的时候，需要和其他的表进行关联。

三、区别
星型模型和雪花模型最根本的区别就是，维度表是直接连接到事实表还是其他的维度表。
1）星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花模型要高。
2）星型模型不用考虑很多正规化的因素，设计和实现都比较简单。
3）雪花模型由于去除了冗余，有些统计就需要通过表的连接才能产生，所以效率不一定有星型模型高。
4）正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。

四、总结
有时候规范化和效率是一组矛盾。一般我们会采取牺牲空间（规范化）来换取好的性能，把尽可能多的维度信息存在一张“大表”里面是最快的。通常会视情况而定，采取折中的策略。

具体问题具体分析，如时间维度，年，季就没必要做雪花，而涉及到产品和产品的分类，如果分类信息也是我们需要分析的信息，那么，要建关于分类的查找表，也就是采用雪花模式。

什么是支架表？与星型模型和雪花模型的区别？

支架表定义：

当一个属性集合（例如日期、地点）在某个维度或多个维度表中反复出现时，就可以考虑使用支架表。

注意：通常将支架表的外键放入事实表中，而不是放置在基本维度中。

星型模型

支架表

雪花模型

什么是维度退化和维度下沉？

维度退化：数据仓库不保留维度表，首先数据量太大，没必要用一张维度表来进行存储，其次没有数据仓库需要的任何数据时，因此退化维度的维度表可以被剔除。比如说订单id，券领取记录id, 进行数据查询或者数据过滤的时候又非常需要，就直接退化到事实表中作为一个字段；

kimball维度建模中描述退化维度如下：操作型事务控制号码，例如：订单号码、发票号码、提货单号码，券领取id退化维度。

维度退化的优点：

• 减少事实表和维度表的关联
• 该技术减少维度的数量， 简化维度数据仓库模式。 简单的模式比复杂的更容易理解， 也有更好的查询性能。
• 如果存在退化维，ETL的过程会变得非常容易
• 可以让group by 等操作变得更快

维度退化的缺点：

• 增加了冗余

维度下沉：数据仓库仍然保留维度表，比如商品维度表，业务经常按照类目进行聚合操作，为减少维度的表关联，提升查询效率，需要把商品的类目属性下沉到事实表中方便业务聚合分析；另外商品id也会冗余在事实表里面，作为关联商品维度表的外键存在，它有对应的维度表，所以它不属于退化维度；

总结：维度退化没有对应的维表，没有修饰它的属性，通过它你可以获取一些信息，一些事实，比如说订单编号，你可以获得这个订单里面包含哪些商品，对应的商家是谁，下单的用户是谁；分析商品，商家的进行分组统计订单数。

什么是桥接表？

实际例子：

淘宝类目设计：https://www.cnblogs.com/volcao/p/13604853.html

美团配送组织设计：美团配送数据治理实践 - 美团技术团队

简述桥接表是如何将维度表和事实表进行关联的？

答：桥接表（Bridge Table）是维度建模中的一类比较特殊的表。

在数据仓库的建模时，会遇到具有层次结构的维度表，对于这样的表有一种建模方式是建立父子表，即每条记录上包括一个指向其父记录的字段。这种父子表的建立在层级深度可变时尤其有用，是一个紧凑而有效的建模方式。但是这种建模方式也有缺点，就是用标准SQL很难对递归结构进行操作。

与这种递归结构的父子表不同，桥接表采用不同的建模方式也可以表示这种层级结构。桥接表是建立在维度表和事实表中间的一个具有较多冗余信息的表，其中的记录包含层级结构中节点到其下面每个节点的路径。表结构如下所示：

父关键字

子关键字

父层数

层名

底端标识

顶端标识

在桥接表中，节点与其下面的任意一个节点都建立一个关联记录保存在表中，即父子关系不再局限在相邻层，如第一层与第三层同样有父子关系，通过父层数可以区分相隔了几层。这样，可以通过父层数和父子关系来进行层级结构的查询。

当然，桥接表也不是一个完备的解决方案，它只能是在某些情况下是查询变得容易。

​多对多维度或多值维度​

维度表和事实表之间的标准关系是一对多关系，这意味着维度表中的一行记录会连接事实表中的多行记录，但是事实表中的一行记录在维度表中只关联一行记录。这种关系很重要，因为它防止了重复计数。幸运的是，在大多数情况下都是这种一对多关系。
在现实世界中还存在比一对多关系更复杂的两种常见情况：
事实表和维度表之间的多对多关系。
维度表之间的多对多关系。
这两种情况本质是相同的，但事实表和维度表之间的多对多关系少了唯一描述事实和维度组的中间维度。
对于这两种情况，我们介绍一种称为桥接表的中间表，以支持更复杂的多对多关系。

1. 事实表和维度表之间的多对多关系

在多个维度表的值可以赋给单个事实事务时，事实表和维度表之间通常是多对多关系。一个常见的示例是多个销售代表可以参与给定的销售事务，这种情形经常发生在涉及大宗交易的复杂销售事件中(例如计算机系统)。精确地处理这种情况需要创建一个桥接表，将销售代表组合成一个组。SalesRepGroup桥接表如图2-4所示。
​
ETL过程需要针对每条引入的事实表记录中的销售代表组合，在桥接表中查找相应的销售代表组键。如果该销售代表组键不存在，就添加一个新的销售代表组。注意图2-4所示的桥接表有重复计数的风险。如果按照销售代表累加销售量，那么每个销售代表都会对总销售量做出贡献。对某些分析而言结果是正确的，但对于其他情况仍会有重复计数的问题。要解决这个问题，可以向桥接表中添加加权因子列。加权因子是一个分数值，所有的销售代表组的加权因子累加起来为1。将加权因子和累加事实相乘，以按照每个销售代表在分组中的比重分配事实。
注意可能需要在Orders和SalesRepGroup之间添加一个SalesRepGroupKey表，以支持真正的主键-外键关系。这会把这个事实-维度实例变成维度-维度实例。

2．维度之间的多对多关系

从分析的角度来看，维度之间的多对多关系是一个很重要的概念，大多数维度都不是完全相互独立的。维度之间的独立性是连续的，而不是有或没有这两种截然不同的状态。例如在连续的一端，零售店这条链状关系的库存维度和产品维度是相对独立的，而不是绝对独立的。一些库存方式不适合某些产品。其他维度之间的关系则紧密得多，但是由于存在多对多关系，因此很难将其组合成单个维度。例如在银行系统中，账户和顾客之间有直接关系，但不是一对一的关系。一个账户可以有一个或多个签名确认的顾客，一个顾客也可有多个账户。银行通常从账户的角度来处理数据；MonthAccountSnapshot(月账快照)是金融机构中常见的一种事实表。因为账户和顾客之间存在的多对多关系，这种更多关注账户的系统就很难按照顾客来查看账户。一种方法是创建CustomerGroup桥接表来连接事实表，例如前面多对多示例中的SalesRepGroup表。较好的方法是利用账户和顾客之间的关系，如图2-5所示。
​
账户和顾客维度之间的AccountToCustomer桥接表可以捕获多对多关系，并且有几个显著的优点。首先，源系统中的关系是已知的，因此创建桥接表比手动构建SalesRepGroup维度表更容易。其次，账户-顾客关系自身就非常有趣。AccountToCustomer桥接表可以回答诸如”每个顾客的平均账户数量是多少？”这样的问题，而无须连接任何事实表。
桥接表经常是底层业务过程的标志，特别是在需要跟踪桥接表随时间而产生的变化(即关系本身是类型2变化)时。对顾客和账户来说，业务过程可能称为账户维护，其中一项事务可能称作”添加签名人”。如果3个顾客与同一个账户关联，在源系统中该账户就会有3个”Add(添加)”事务。通常这些事务和它们表示的业务过程还不是很重要，不需要在DW/BI系统中通过它们自身的事实表来跟踪。然而，这些关系和它们产生的变化对分析业务来说是相当重要的。我们在维度模型中把它们包含为渐变维度，在一些情况下包含为桥接表。

如何进行数据模型设计？

参考：阿里数据仓库架构与模型设计-CSDN博客