数据仓库与数据集市建模

• • 一、前言
  • 二、数据仓库(data warehouse)
  • • • 1. 操作型数据库(OLTP) VS 分析型数据库(OLAP)
      • 2.数据仓库定义
        
      
      
  • 三、数据集市(data mart)
  • 四、维度建模的基本概念
  • 五、 维度建模的三种模式（模型）
  • • • 1.星型模式（模型）
      • 2.雪花模式（模型）
      • 3.星座模式（模型）
      • 4.三种模式对比
        
      
      
  • 六、更多可能的事实属性
  • 七、经典星座模型
  • • • 1.共享维度
      • 2. 细节/聚集事实表
        
      
      
  • 八、缓慢变化维度问题
  • 九、规范化数据仓库
  • 十、独立数据集市
  • 十一、两种数据仓库建模体系对比
    
  
  

注：本文转自数据仓库与数据集市建模, 结合《数仓建模工具箱》作为补充，仅用于个人学习，侵权删。

一、前言

• 数据仓库建模包含了几种数据建模技术，除了ER建模和关系建模，还包括专门针对数据仓库的维度建模技术。

• 本文将详细介绍数据仓库维度建模技术，并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系：规范化数据仓库，维度建模数据仓库，以及独立数据集市。

  
  

二、数据仓库(data warehouse)1. 操作型数据库(OLTP) VS 分析型数据库(OLAP)

• 接下来本文将详细分析两类数据库的不同点：

  • ① 数据组成差别 - 数据时间范围差别

    一般来讲，操作型数据库只会存放90天以内的数据，而分析型数据库存放的则是数年内的(甚至更久)数据。这点也是将操作型数据和分析型数据进行物理分离的主要原因。

  • ② 数据组成差别 - 数据细节层次差别

    操作型数据库存放的主要是细节数据，而分析型数据库中虽然既有细节数据，又有汇总数据，但对于用户来说，重点关注的是汇总数据部分。

    操作型数据库中自然也有汇总需求，但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的，因此汇总数据会在每次查询时动态生成。

    而对于分析型数据库来说，因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)，因此它的汇总数据可考虑事先计算好，以避免重复计算。

  • ③ 数据组成差别 - 数据时间表示差别

    操作型数据通常反映的是现实世界的当前状态；而分析型数据库既有当前状态，还有过去各时刻的快照，分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。

  • ④ 技术差别 - 查询数据总量和查询频度差别

    操作型查询的数据量少而频率多，分析型查询则反过来，数据量大而频率少。要想同时实现这两种情况的配置优化是不可能的，这也是将两类数据库物理分隔原因之一。

  • ⑤ 技术差别 - 数据更新差别

    操作型数据库允许用户进行增，删，改，查；分析型数据库用户则只能进行查询。

  • ⑥ 技术差别 - 数据冗余差别

    数据的意义是什么？就是减少数据冗余，避免更新异常。而如5所述，分析型数据库中没有更新操作。因此，减少数据冗余也就没那么重要了。

    hadoop Hive里的关系表不完全满足完整/参照性约束，也不完全满足范式要求，甚至第一范式都不满足。它只提供查询接口，不提供更新接口，这就使得消除冗余的诸多措施不需要被特别严格地执行了。

  • ⑦ 功能差别 - 数据读者差别

    操作型数据库的使用者是业务环境内的各个角色，如用户，商家，进货商等；分析型数据库则只被少量用户用来做综合性决策。

  • ⑧ 功能差别 - 数据定位差别

    这里说的定位，主要是指以何种目的组织起来。操作型数据库是为了支撑具体业务的，因此也被称为"面向应用型数据库"；分析型数据库则是针对各特定业务主题域的分析任务创建的，因此也被称为**“面向主题型数据库”**。

    
    
  
  

2.数据仓库定义

• 既然分析型数据库中的操作都是查询，因此也就不需要严格满足完整性/参照性约束以及范式设计要求，而这些却正是关系数据库精华所在。这样的情况下再将它归为数据库会很容易引起大家混淆，毕竟在绝大多数人心里数据库是可以关系型数据库画上等号的。

• 那么为什么不干脆叫"面向分析的存储系统"呢？

• Bingo！~这就是关于数据仓库最贴切的定义了。事实上数据仓库不应让传统关系数据库来实现，因为关系数据库最少也要求满足第1范式，而数据仓库里的关系表可以不满足第1范式。也就是说，同样的记录在一个关系表里可以出现N次。但由于大多数数据仓库内的表的统计分析还是用SQL，因此很多人把它和关系数据库搞混了。

• 知道了什么是数据仓库后，再来看看它有哪些特点吧。某种程度上来说，这也是分析型数据库的特点
  

• 1. 面向主题

  面向主题特性是数据仓库和操作型数据库的根本区别。操作型数据库是为了支撑各种业务而建立，而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)进行分析而建立；

• 2. 集成性

  集成性是指数据仓库会将不同源数据库中的数据汇总到一起；

• 3. 企业范围

  数据仓库内的数据是面向公司全局的。比如某个主题域为成本，则全公司和成本有关的信息都会被汇集进来；

• 4. 历史性

  较之操作型数据库，数据仓库的时间跨度通常比较长。前者通常保存几个月，后者可能几年甚至几十年；

• 5. 时变性

  时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后，用户便可将其汇总，生成各历史阶段的数据分析报告；

  
  

三、数据集市(data mart)

• 数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。

• 数据集市可以分为两种，一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的"子集"。

  
  

四、维度建模的基本概念

• 维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。

• 它本身属于一种关系建模方法，但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念：

  • 1.维度表(dimension)
    表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常维度表信息比较固定，且数据量小。

    用于描述环境的维度表
    1.维度表是事实表不可或缺的组成部分。维度表包含与业务过程度量事件有关的文本环.
    境。它们用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件。
    2.维度表通常有多列，或者说包含多个属性。有50~ 100个属性的维度表并不稀奇。尽管如此，也可能存在一些只包含少量属性的维度表。
    3.与事实表比较，维度表趋向于包含较少的行，但由于可能存在大量文本列而导致存在多列的情况。
    4.维度表属性在DW/BI系统中起着至关重要的作用。因为维度表的属性是所有查询约
    束和报表标识的来源。
    ——《数仓建模工具箱》

  • 2.事实表(fact table)
    表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。

    用于度量的事实表
    1.维度模型中的事实表存储组织机构业务过程事件的性能度量结果。应该尽量将来源于同一个业务过程的底层度量结果存储于一个维度模型中。
    2.“事实”这一术语表示某个业务度量。从市场角度观察，记录销售的产品的数量单位，以及每种产品在每个销售事务中涉及的销售额。
    3.事实表中的每行对应一个度量事件。每行中的数据是一个特定级别的细节数据，称为粒度。例如，销售事务中用一行来表示每个卖出的产品。
    4.维度建模的核心原则之一是同一事实表中的所有度量行必须具有相同的粒度。牢记建立事实表时使用统一的细节级别这一原则可以确保不会出现重复计算度量的问题。
    ——《数仓建模工具箱》

    常用事实表的分类
    1.可加、半可加、不可加事实
    事实表中的数字度量可划分为三类。最灵活、最有用的事实是完全可加，可加性度量可以·按照与事实表关联的任意维度汇总。半可加度量可以对某些维度汇总，但不能对所有维度汇总。差额是常见的半可加事实，除了时间维度外，它们可以跨所有维度进行加法操作。另外，一些度量是完全不可加的，例如，比率。
    2.事务事实表
    事务事实表的一行对应空间或时间上某点的度量事件。原子事务粒度事实表是维度化及可表达的事实表，这类健壮的维度确保对事务数据的最大化分片和分块。事务事实表可以是稠密的，也可以是稀疏的，因为仅当存在度量时才会建立行。
    3.周期快照事实表
    周期快照事实表中的每行汇总了发生在某一标准周期，如某天、某周、某月的多个度量事件。粒度是周期性的，而不是个体的事务。周期快照事实表通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许存在的。
    4.累积快照事实表
    累积快照事实表的行汇总了发生在过程开始和结束之间可预测步骤内的度量事件。管道或工作流过程(例如，履行订单或索赔过程)具有定义的开始点，标准中间过程，定义的结束点，它们在此类事实表中都可以被建模。
    ——《数仓建模工具箱》

    
    

• 注：在数据仓库中不需要严格遵守规范化设计原则。本文示例中的主码，外码均只表示一种对应关系，此处特别说明。

• 维度退化：

  退化维度的技术。该技术减少维度的数量，简化维度数据仓库的模式。简单的模式比复杂的更容易理解，也有更好的查询性能。当一个维度没有数据仓库需要的任何数据时就可以退化此维度。需要把退化维度的相关数据迁移到事实表中，然后删除退化的维度。参考链接：维度退化

  
  

五、 维度建模的三种模式（模型）1.星型模式（模型）

• 星形模式(Star Schema)是最常用的维度建模方式，下图展示了使用星形模式进行维度建模的关系结构：
  
• 可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
  • ① 维表只和事实表关联，维表之间没有关联。
  • ② 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
  • ③ 以事实表为核心，维表围绕核心呈星形分布。
    
  
  

2.雪花模式（模型）

• 雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：
  
• 星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。
  

3.星座模式（模型）

• 星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式：
  
• 前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
  

4.三种模式对比

• 雪花模式是将星型模式的维表进一步划分，使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。本文后面部分将具体讲到这几种模式的使用，请读者结合实例体会。
  

六、更多可能的事实属性

• 除了对应到维度的外码和度量属性，事实表中还常常考虑另外两个属性：事务标识码(transaction identifier)和事务时间(transaction time)。

• 事务标识码通常被命名为TID，其意义就是各种订单号，事务编号… 为什么将这个属性放到事实表而不是维表中呢？一个主要原因是它的数量级太大了，这样每次查询都会耗费很多资源来Join。这种将某些逻辑意义上的维度放到事实表里的做法被称为退化维度(degenerate dimension)。

• 将事务时间维度放到事实表中的考虑也是出于相同考虑。然而这么设计又一次"逆规范化"了：事务标识码非主码却决定事务标识时间，显然违背了3NF。但现在我们是为数据仓库建模，所以这样做是OK的。另外在分布式的数据仓库中，这个字段十分重要。因为事实表的数量级非常大，Hive或者Spark SQL这类分布式数据仓库工具都会对这些数据进行分区。任何成熟的分布式计算平台中都应禁止开发人员建立非分区事实表，并默认分区字段为(当天)日期

  
  

七、经典星座模型

• 有多个事实表的维度模型被称为星座模型。星座模型主要有以下两大作用：共享维度和设置细节/聚集事实表。下面分别对这两种情况进行分析。
  

1.共享维度

• 以前文提到的零售公司为例，假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品，那么此时不需要重新维度建模，只需往模型里加入一个新的劣质产品事实表。
  

2. 细节/聚集事实表

• 细节事实表(detailed fact tables)中每条记录表示单一事实，而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。从表的字段上看，细节事实表通常有设置TID属性，而聚集事实表则无。

• 两种事实表各有优缺点，细节事实表查询灵活但是响应速度相对慢，而聚集事实表虽然提高了查询速度，但使查询功能受到一定限制。一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。这种设计方法中，聚集事实表使用和细节事实表细节事实表的维度。

  
  

八、缓慢变化维度问题

• 虽然，维表的数据比事实表更稳定。但不论如何维度在某些时候总会发生一些变化。在之前曾抛出一个问题：为什么维度建模后的关系不是ID，而是Key了。这样做的目的其实就是为了解决一种被称为缓慢维度变化(slowly changing dimension)的问题。在维度变化后，一部分历史信息就被丢掉了。比如张三是某公司会员。

• 但仅仅这么做还是不够的，代理键需要配合时间戳，以及行标识符使用才能解决缓慢维度变化的问题。如下CUSTOMER表使用该方法避免缓慢维度变化：
  

• 可以看到用户张三对应新维度的TaxBracket状态由Low变成了High。如果需要统计张三的相关行为，那么可以让所有记录用CustomerID字段Join事实表；如果要统计当前TaxBracket为Low的用户状态，则可将Row Indicator字段为Current的记录用CustomerKey字段Join事实表；如果要统计历史TaxBracket状态为Low的用户情况，则只需要将TaxBracket属性为Low的用户记录的CustomerKey属性与事实表关联。

• 更多详细信息参考：https://www.cnblogs.com/theseven/articles/4789337.html

  
  

九、规范化数据仓库

• 所谓"数据仓库建模体系"，指的是数据仓库从无到有的一整套建模方法。最常见的三种数据仓库建模体系分别为：规范化数据仓库，维度建模数据仓库，独立数据集市。很多书将它们称为"数据仓库建模方法"，但笔者认为数据仓库建模体系更能准确表达意思，请允许我自作主张一次吧：）。下面首先来介绍规范化数据仓库。

• 规范化数据仓库(normalized data warehouse)顾名思义，是规范化设计的分析型数据库，然后基于这个数据库为各部门建立数据集市。总体架构如下图所示：
  

• 该建模体系首先设计一组常用的度集合(conformed dimension)，然后创建一个大星座模型表示所有分析型数据。如果这种一致维度不满足某些数据分析要求，自然也可在数据仓库之上继续构建新的数据集市

  
  

十、独立数据集市

• 独立数据集市的建模体系是让公司的各个组织自己创建并完成ETL，自己维护自己的数据集市。其总体架构如下图所示：
  

• **从技术上来讲这是一种很不值得推崇的方式，因为将使信息分散，影响了企业全局范围内数据分析的效率。此外，各组织之间的ETL架构相互独立无法复用，也浪费了企业的开发资源。**然而出于某些公司制度及预算方面的考虑，有时也会使用到这种建模体系。

  
  

十一、两种数据仓库建模体系对比

• 规范化数据仓库和维度建模数据仓库分别是Bill Inmon和Ralph Kimball提出的方法。关于哪种方法更好，哪种方法更优秀的争论已经由来已久。但随着这两种数据仓库应用越来越多，人们也逐渐了解到两种数据仓库的优劣之处，如下表所示：

• 产生这些区别的根本之处在于规范化数据仓库需要对企业全局进行规范化建模，这将导致较大的工作量。但这一步必须完成好，才能继续往上建设数据集市。因此也就导致规范化数据仓库需要一定时间才能投入使用，敏捷性相对后者来说略差。但是规范化数据仓库一旦建立好了，则以后数据就更易于管理。而且由于开发人员不能直接使用其中心数据库，更加确保了数据质量。还有由于中心数据库是采用规范化设计的，冗余情况也会更少。

• 然而另一方面维度建模数据仓库除了敏捷性更强，而且适用于业务变化比较频繁的情况，对开发人员的要求也没有规范化数据仓库那么高。总之各有利弊，具体实施时需要仔细的权衡。