[转载] 第二篇 数据仓库与数据集市建模

阅读目录

• 前言
• 维度建模的基本概念
• 维度建模的三种模式
• 实例：零售公司销售主题的维度建模
• 更多可能的事实属性
• 经典星座模型
• 缓慢变化维度问题
• 数据仓库建模体系之规范化数据仓库
• 数据仓库建模体系之维度建模数据仓库
• 数据仓库建模体系之独立数据集市
• 三种数据仓库建模体系对比
• 小结

回到顶部

前言

        数据仓库建模包含了几种数据建模技术，除了以前在数据库系列中介绍过的ER建模和关系建模，还包括专门针对数据仓库的维度建模技术。

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

回到顶部

维度建模的基本概念

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

        它自己属于一种关系建模方法，但和以前在操做型数据库中介绍的关系建模方法相比增长了两个概念：

        1. 维度表(dimension)

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

        2. 事实表(fact table)

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

        注：在数据仓库中不须要严格遵照规范化设计原则(具体缘由请看上篇)。本文示例中的主码，外码均只表示一种对应关系，此处特别说明。

回到顶部

维度建模的三种模式

        1. 星形模式

        星形模式(Star Schema)是最经常使用的维度建模方式，下图展现了使用星形模式进行维度建模的关系结构：

        能够看出，星形模式的维度建模由一个事实表和一组维表成，且具备如下特色：

                a. 维表只和事实表关联，维表之间没有关联；

                b. 每一个维表的主码为单列，且该主码放置在事实表中，做为两边链接的外码；

                c. 以事实表为核心，维表围绕核心呈星形分布；

        2. 雪花模式

        雪花模式(Snowflake Schema)是对星形模式的扩展，每一个维表可继续向外链接多个子维表。下图为使用雪花模式进行维度建模的关系结构：

        星形模式中的维表相对雪花模式来讲要大，并且不知足规范化设计。雪花模型至关于将星形模式的大维表拆分红小维表，知足了规范化设计。然而这种模式在实际应用中不多见，由于这样作会致使开发难度增大，而数据冗余问题在数据仓库里并不严重。

        3. 星座模式

        星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式：

 

        前面介绍的两种维度建模方法都是多维表对应单事实表，但在不少时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

        4. 三种模式对比

        概括一下，星形模式/雪花模式/星座模式的关系以下图所示：

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

回到顶部

实例：零售公司销售主题的维度建模

        在进行维度建模前，首先要了解用户需求。而笔者在数据库系列的第一篇就讲过，ER建模是当前收集和可视化需求的最佳技术。所以假定和某零售公司进行屡次需求PK后，获得如下ER图：

        随后可利用建模工具将ER图直接映射到关系图： 

        需求搜集完毕后，即可进行维度建模了。本例采用星形模型维度建模。但不论采起何种模式，维度建模的关键在于明确下面四个问题：

        1. 哪些维度对主题分析有用？

        本例中，根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是很是有帮助的；

        2. 如何使用现有数据生成维表？

                a. 维度PRODUCT可由关系PRODUCT，关系VENDOR，关系CATEGORY链接获得；

                b. 维度CUSTOMER和关系CUSTOMER相同；

                c. 维度STORE可由关系STROE和关系REGION链接获得；

                d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离获得；

        3. 用什么指标来"度量"主题？

        本例的主题是销售，而销量和销售额这两个指标最能直观反映销售状况；

        4. 如何使用现有数据生成事实表？

        销量和销售额信息能够由关系SALESTRANSACTION和关系SOLDVIA，关系PRODUCT链接获得；

        明确这四个问题后，便能轻松完成维度建模：

        细心的读者会发现三个问题：1. 维表不知足规范化设计(不知足3NF)；2. 事实表也不知足规范化设计(1NF都不知足)； 3. 维度建模中各维度的主码由***ID变成***Key；

        对于前两个问题，因为当前建模环境是数据仓库，而没有更新操做，因此不须要严格作规范化设计来消除冗余避免更新异常。

        所以虽然能够以雪花模型进行维度建模，以下所示： 

        但这样会加大查询人员负担：每次查询都涉及到太多表了。所以在实际应用中，雪花模型仅是一种理论上的模型。星座模型则出如今"维度建模数据仓库"中，本文后面将会讲到。

        对于第三个问题，***Key这样的字段被称为代理码(surrogate key)，它是一个经过自动分配整数生成的主码，没有任何其余意义。使用它主要是为了可以处理"缓慢变化的维度"，本文后面会仔细分析这个问题，这里不纠结。

回到顶部

更多可能的事实属性

        除了对应到维度的外码和度量属性，事实表中还经常考虑另外两个属性：事务标识码(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属性与事实表关联。

回到顶部

数据仓库建模体系之规范化数据仓库

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

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

        该建模体系首先对ETL获得的数据进行ER建模，关系建模，获得一个规范化的数据库模式。而后用这个中心数据库为公司各部门创建基于维度建模的数据集市。各部门开发人员大都从这些数据集市提数，一般来讲不容许直接访问中心数据库。    

回到顶部

数据仓库建模体系之维度建模数据仓库

        非维度建模数据仓库(dimensionally modeled data warehouse)是一种使用交错维度进行建模的数据仓库，其整体架构以下图所示：

        该建模体系首先设计一组经常使用的度集合(conformed dimension)，而后建立一个大星座模型表示全部分析型数据。若是这种一致维度不知足某些数据分析要求，天然也可在数据仓库之上继续构建新的数据集市。

回到顶部

数据仓库建模体系之独立数据集市

        独立数据集市的建模体系是让公司的各个组织本身建立并完成ETL，本身维护本身的数据集市。其整体架构以下图所示：

 

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

回到顶部

三种数据仓库建模体系对比

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

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

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

回到顶部

小结

        数据仓库建模是一个综合性技术，须要使用到ER建模、关系建模、维度建模等技术。并且当企业业务复杂的时候，这部分工做更是须要专门团队与业务方共同合做来完成。所以一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。

 

文章出处：http://www.cnblogs.com/muchen/p/5310732.html