聊聊数据仓库中维度表设计的二三事_维度建模维度表之间的关系(4)

本文链接：https://blog.csdn.net/2401_84185951/article/details/138570808

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

采用插入新的维度列处理缓慢变化维示例

不同于前一种方法的添加一行，这种方法通过新增一列，比如用 region_previous 列表示之前的所属大区，同时新增 region_current 来表示变化后的所属大区。如果有多次变化，就需要有多个列来存储。

实际上，这三种方法都能从不同角度解决维度变化的问题，还有通过组合这三种方法形成的其他各种技术可用于处理维度变化，这里就不再赘述。

当然了，不管哪种技术，在大数据时代都不是完美的，而且有一定的处理复杂度和学习使用成本。

如何以一种最简单、直接的办法来解决维度变化呢？我们在后面会聊聊 快照技术 ，以解决大数据时代的维度变化问题。

维度层次指的是某个维度表中属性之间存在的从属关系问题。比如商品的类目可能是有层次的（一级类目、二级类目、三级类目等，尤其对于宝洁、联合利华等大的快消企业集团），同时类目、品牌和产品实际上也是有层次的。那么维度建模如何处理这些层次结构呢？

实际上有两种处理办法：

第一种其实就是星型架构，第二种是雪花架构。在维度建模中，我们采用第一种来处理维度的层级问题，这样反规范化的处理牺牲了部分存储，但是给用户使用带来了便捷，也降低了学习使用成本。

维度的层次结构通常和钻取联系在一起，所谓钻取即是对信息的持续深入挖掘。

钻取分为向上钻取和向下钻取，比如对于某零售商的年度销售报表，其年度销售总额显示增长20%，那么从时间上分析是哪个季度的增长率比较高呢？

此时可以向下分析各个季度的增长率，同样可以继续向下分析到月增长率乃至天增长率，同样的分析也可以应用到类目、品牌等，来分析到底是哪个类目的增长或者哪个品牌的增长导致了年度总销售额的增长 20% 。这就是向下钻取。

与之相对的是向上钻取，钻取的实质是增加或者减少维度，增加维度（向下钻取）从汇总数据深入到细节数据，而减少维度（向上钻取）则从细节数据概括到汇总数据。通过钻取，用户对数据能更深入地了解数据，更容易发现问题，从而做出正确的决策。

在 Kimball 的维度设计理论中，并没有物理上的数据仓库。数据仓库是在对多个主题、多个业务过程的多次迭代过程中逐步建立的，这些多个问题、多个业务过程的多次迭代过程常被从逻辑上划分为数据集市。

所谓数据集市一般由一张和多张紧密关联的事实表以及多个维度表组成，一般是部门级的或者面向某个特定的主题。数据仓库则是企业级的、面向主题的、集成的数据集合。

物理上的数据集市组合成逻辑上的数据仓库，旦数据集市的建立是逐步完成的，如果分步建立数据集市的过程中维度表不一致，那么数据集市就会变成孤立的集市，不能从逻辑上组合成一个集成的数据仓库，而维度一致性的正是为了解决这个问题。

维度一致性的意思是指：两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。

不一致既包含维度表内容的不致，也包含维度属性上的不一致。

比如对于一个电子商务公司，如果其浏览等相关主题域的商品维度表包含了该企业的所有商品的访问信息，但是由于某种原因其交易域的商品缺失了部分商品（有可能是成交在其他平台完成），那么对这些缺失商品的交易分析就无法完成。
同样如果两的商品属性不同，比如日期格式、类目划分（有可能浏览分为前天类目，成交是后台类自）等不一致，那么跨浏览域和交易域的对类目和日期的交叉分析就无法进行，因为其类目划分就不一致。

维度一致性对于数据集市成为数据仓库起着关键作用，实际数据集市设计和开发过程中，必须保证维度一致性，具体可以采用共享同一个维度表或者让其中一个维度表是另外一个维度表的子集等方式来保证一致性，从而避免孤立数据集市的出现。

实际维度表设计中，有时候会出现同一个维度表来自于多个前台业务系统的问题，此时就会带来维度整合和拆分问题。

前台的业务系统通常是比较复杂的，比如移动端交易系统和PC端交易系统的系统架构和底层数据库、表结构等完全不一致，此时就存在维度的整合问题。

在实际整合中，同一个维度整合需要考虑如下问题：

与整合相对的是拆分

对于大的集团公司来说，以中石化为例，其主业为成品油销售，但是同时其还有中石化加油站的快捷零售店（在此仅做说明问题使用），它们的商品表字段和属性由于业务的不同而存在很大的差异（石油商品和零售店销售的食品、饮料等）。

此时需要用一个统一整合的商品表么（从直觉来说是不需要的，因为业务差异巨大）？

在维度建模理论中，对于上述情况通常有两种处理办法

建一个基础的维度表，此基础维度表包含这些不同业务的共有属性，同时建立各自业务的单独维度表以包含其独特的业务属性。
比如，上述例子就可以建立一个共有的商品维度表记录商品价格、商品描述等共有属性字段，同时建立成品油销售的商品维度表记录油标号（ 92 95 97 等）等成品油独特的商品属性，另外建立一个零售商品维度表记录便利店的各种商品属性（实际操作中通常先建立两个单独的维度表，然后基于单独维度表生成共有的商品维度表或者视图）
拆分，即不合并，即各个业务差异独特性的业务各自建立完全独立的两个维度表，各自管理各自维度表和属性。

我们在实际操作中，对于业务差异大的业务，偶合在一起并不能带来很大的便利和好处，因此通常倾向于拆分（即不合并），各自管理各自的维度表。而对于业务相似度比较大的业务，则可以采用上述的第一种方法。