维度模型数据仓库（二） —— 维度模型基础

（一）维度模型基础
        既然维度模型是数据仓库建设中的一种数据建模方法，那不妨先看一下几种主流的数据仓库架构。

        1. Kimball的DW/BI架构

图（一）- 1

        2. Inmon企业信息工厂架构

图（一）- 2
        3. 混合型架构

图（一）- 3

        从图中可以看出，每种架构中都有数据集市。数据集市就是面向终端用户的数据库。数据集市通常使用维度模型来建模，并根据报表和分析的需求而优化。Kimball和Inmon架构最大的区别就是是否需要一个企业级的数据仓库（EDW）。Inmon架构中有EDW，Kimball架构中没有。EDW本质上就是一个大的数据仓库，包括了从企业各个数据源集成过来的所有的历史数据。EDW不能由终端用户直接访问，仅用来存储和报表相关的，用于审计的各种历史数据。Inmon认为EDW位于业务系统和数据集市之间，也是数据集市的唯一数据来源。至于混合型架构则是结合了Kimball与Inmon架构的产物。

        以上这些方法论的东西简单描述了几种数据仓库总体架构的异同之处。除了架构层面，还有两种主要的建模方法，即规范化模型和维度模型。规范化模型用于EDW建模，而维度模型用于数据集市建模。规范化模型对于数据库设计者来说非常熟悉，通常业务数据库、OLTP系统都采用规范化模型。简单地说，1NF就是消除重复元组，并保持列的原子性，具体到数据库设计上就是每个表都要有一个主键来唯一标识一行记录。2NF就是在1NF的基础上消除了部分依赖，即非键属性必须完全依赖于主键。3NF在2NF基础上消除了传递依赖，即非键属性只能完全依赖于主键。一般数据库设计需要满足3NF。在《构建Oracle高可用环境》这本书里有一个很好的例子讲述数据库范式设计。而对于维度模型最简单的描述就是，按照事实表、维度表来构建数据仓库、数据集市。这种方法被人们熟知的有星型模式和雪花模式。

        星型模式是部署在关系数据库管理系统之上的多维结构，主要包含事实表，以及通过主键/外键关系与之关联的维度表。在星型模式实施中，所有维度级别的维度数据存储在单个表或视图中。雪花模就是将维度层次进一步规范化为子维度。在雪花模式实施中，使用多个表或视图来存储维度数据。单独的数据库表或视图存储与维中每个级别相关的数据。

        看一下以上星型模式的定义，问题来了：既然事实表与维度表也是以主键/外键的方式相互关联，换句话说，3NF和维度模型都能用实体/关系图（ERD）表示，那么两者的根本区别是什么呢？答案就是：3NF的本质是消除数据冗余，那么维度模型与其根本区别就是数据冗余程度不同。随着规范化程度的提高，必然会使得表和表之间的关系越来越多。而维度模型虽然常应用在关系数据库管理系统之上，但是并不要求必须满足3NF，也就是说维度模型允许可控的数据冗余。这样做简少了表和表间关系的数量，同时提高了查询速度。下面引用《数据仓库设计》书中的一个例子，进一步说明3NF与维度模型的差异。

图（一）- 4

        左边是一个销售订单的典型的规范化表示。订单（Order）实体描述有关订单文档的信息，订单明细（Order Line）实体描述有关订单明细的信息，两个实体都包含描述订单和它的状态的信息。右边是一个订单状态维（Order Status Dimension），该维描述与订单和订单明细中对应的状态编码值的唯一组合。它包括在实体模型的订单和订单明细实体中都出现的属性。当销售订单事实行被装载时，参照在订单状态维中的适合的状态编码的组合设置它的外键。

        维设计的整体观点是要简化和加速查询。例如，假设有100万订单，每个订单有10条明细，订单状态和订单明细状态各有10种。如果用户要查询某种状态特性的订单，按3NF模型，逻辑上需要关联100万与1000万的两个大表，然后过滤两个表的状态值得到所要的结果。另一方面，事实表（图中并没有画出）按最细数据粒度有1000万记录，3NF里的订单表属性在事实表里是冗余数据，状态维度有100条数据，只需要关联1000万与100的两个表，再进行状态过滤即可。

原文：https://blog.csdn.net/wzy0623/article/details/49529751