数据仓库维度说明

下面是一些普通的结构维：客户地理位置维这个维可提供一个根据客户所在地进行归类的层次结构。客户维的典型例子是“customer_city”、“customer_state”和“custmer_country”。这个维通常用于查看不同的地理位置在销售、利润和其他客户度量方面的不同。

时间维可表明事件发生的时间。典型的时间维应该是年、月和日。

销售人员地理位置维这个维可提供一个根据销售人员所在地域进行归类的层次结构。这个维通常用来查看工作在不同地域的销售人员的销售情况和利润等。

产品维出售的产品。这个层次结构可能包括“product_name”、“product_brand”、“product_category”和“product_department”。这个维用来查看不同类别的产品的销售利润和其他指标。

所有这些结构维都包含他们所在层次结构的属性。在结构维中层次是非常重要的，所以要在下面分别进行讨论。

信息维

信息维是计算字段建立的。用户也许想通过销售利润了解所有产品的销售总额。也许希望通过增加销售来获得丰厚的利润。然而，如果某一款商品降价销售，可能会发现销售量虽然很大，而利润却很小或几乎没有利润。从另一方面看，用户可能希望通过提高某种产品的价格获得较大利润。这种产品可能具有较高的利润空间，但销量却可能很低。因此，就利润建立一个维，就销售总量建立一个度量可以提供有用的产品信息。

用户可以对利润进行2种计算。第1种是计算每种商品的平均利润，这一方法很简单，即用销售价格减去销售人员的开销。知道了每种商品的平均利润之后，还可以用它乘以每一天的销售量从而得到每种商品每一天的总利润。

真实世界在实际应用中，也许需要进行很多项这样的计算，因为每一天的销售价格和开销都有很大差异。因此，需要一个包含每天的销售价格和每天开销情况的表。在用户查看的时间段上，每一天的销售价格和每天的开销情况都是有区别的，需要进行合计并求平均。某一天每种商品的利润乘以这一天的销售量等于当天的总利润，选定时间段的利润总和为各天的利润之和。

创建了一个包括每种商品利润和全部利润的维，就有了一个信息维。

分区维生成信息表

以同一结构生成两个或多个维时，要用到分区维。例如，用户可能要创建用于预测销售额和实际销售额的两个维。这两个维的结构相同，只是数值不同。另一个例子是时间维，每一年有相同的季度，相同的月和相同的天（除了闰年以外，而它不影响维）。在OLAP Services中，将频繁使用时间分区维来分割数据仓库中的数据。

例如：为下列结构生成两个同样的维。

the_day

the_month

the_year

一个时间维中的数据是针对1998年的，而另一个时间维中的数据针对1999年的。建立事实表时，可以把度量分割为1998年的数据和1999年的数据，这将带来许多益处。

分类维

分类维是通过对一个维的属性值分组而创建的。如果客户表中有家庭收入属性，那么，可能希望查看客户根据收入的购物方式。为此，可以生成一个含有家庭收入的分类维。

例如：如果有以下家庭每年收入的数据分组：0_{20000元、20001}40000元、40001~60 000元、60 001~100 000元和大于100 001元。现在就可以考虑如何度量，例如，从这些分类中的每一个所购买产品的数量上来看他们的收入水平怎样和购买量怎样。另外一个可能的分类是家庭成员的性别和数量。

特殊维类型

特殊的维主要是在结构上区别于常见的维度，主要有退化维、垃圾维、一致维和父子维。

退化维

当维表中的主键在事实表中没有与外键关联时，这样的维称为退化维，退化维的定义是Ralph Kimball提出来的。一般来说事实表中的外键都对应一个维表，维的信息主要存放在维表中；但是退化维仅仅是事实表中的一列，这个维的相关信息都在这一 列中，没有维表与之相关联。退化维与事实表并无关系，但用于一般在企业事件中跨越维之间查询数据时，作为约束，也就是查询限制条件（比如订单号码、出货单编号等），就是常用退化维。以销售分析而言，通常是把出货日期作为事实的时间，而把订单日期或需求日期等作为查询条件，这里，订单日期或需求日期就是退化维。

退化维的作用

1、退化维具有普通维的各种操作，比如：上卷，切片，切块等。

2、如果存在退化维，那么在ETL的过程将会变得容易。

3、它可以让group by等操作变得更快。

垃圾维

针对某企业事件，通常提供了必要的查询值，但是却没有直接映射信息对象产生的维表，这样的字段就是垃圾维。一般来说，如果OLAP系统包含杂乱的标识和文字属性，而且与时间维以外的维表没有关系，就可以使用垃圾维。唯一要注意的是，垃圾维必须是对企业决策潜在限制值非常重要的属性，通常会创建一个维表来存储这些属性。

一致维

在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。 如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。

当有好几个数据集市要合并成一个企业级的数据仓库时，可以使用一致维来集成数据集市以便确定所有的数据集市可以使用每个数据集市的事实。所以，一致维常用于属于企业级的综合性数据仓库，使得数据可以跨越不同的模式来查询。

在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。

这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。

父子维

父子维度基于两个维度表列，这两列一起定义了维度成员中的沿袭关系。一列称为成员键列，标识每个成员；另一列称为父键列，标识每个成员的父代。该信息用于创建父子链接，该链接将在创建后组合到代表单个元数据级别的单个成员层次结构中。

父子维度通俗的话来讲，这个表是自反的，即外键本身就是引用的主键；类似这样的关系，如公司组织结构，分公司是总公司的一部分，部门是分公司的一部分，当然如果定义得好的话员工是部门的一部分；通常公司的组织架构并非处在等层次上的，例如总公司下面的部门看起来就和分公司是一样的层次。因此父子维的层次通常不固定的。因为父子维的复杂的自引用关系，如果按照缓慢维度的全历史记录方式来处理，必然导致逻辑关系混乱，处理起来比较棘手；任何一个组织的变动(修改名称，更改引用，新增等等操作)将会引起其下属节点相应的变动；任何一个意外都会导致整个结构的变化，同时发生意外后所带来的逻辑关系很难理顺。因此建议按照缓慢变化维的覆盖方式解决，即只根据主键这个唯一标志进行判断是否是新增还是修改。

缓慢变化维

在以维度建模的数据仓库中，有一种概念叫做缓慢变化维，Slowly Changing Dimension。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。

处理的一般方法：

1.直接覆盖历史数据。

如果该维度数据的变化并不是你所关心的，那么可以采用直接覆盖历史数据的方法。比如，员工表中某员工的政治面貌发生变化，你不关心这一点则可以直接覆盖历史数据。

2.保留历史纪录并添加一个标志位。

该方法直接添加新纪录，并将历史纪录的标志位设为Inactive，新纪录标志位设为Active。如果需要还可以附上时间戳，表明旧纪录是何时失效的。

3.利用不同的字段保存不同值。

新加一个历史值字段，一个时间戳字段，一个新值字段。该方法若要保存若干条历史纪录则字段数会很多，不清晰明了。

4.新建一个表来保存历史纪录。

相当于把方法2中Inactive的数据保存于另外一张表中，原表中只保存Active的数据。

5.常规混合方法

这种模式是以上几种模式的混合体，相对而言此种方法更全面，更能应对错综复杂且易变化的用户需求，也是较为常用的。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新*

需要这份系统化资料的朋友，可以戳这里获取