数据仓库的架构方式及其比较

数据仓库的架构方式及其比较
数据仓库的架构方式及其比较
传统的关系数据库一般采用二维数表的形式来表示数据，一个维是行，另一个维是列，行和列的交叉处就是数据元素。

关系数据的基础是关系数据库模型，通过标准的SQL语言来加以实现。

数据仓库是多维数据库，它扩展了关系数据库模型，以星形架构为主要结构方式的，并在它的基础上，扩展出理论雪花形架构和数据星座等方式，但不管是哪一种架构，维度表、事实表和事实表中的量度都是必不可少的组成要素。

下面解析由这些要素构成的数据仓库的架构方式。

1．星形架构
星形模型是最常用的数据仓库设计结构的实现模式，它使数据仓库形成了一个集成系统，为最终用户提供报表服务，为用户提供分析服务对象。

星形模式通过使用一个包含主题的事实表和多个包含事实的非正规化描述的维度表来支持各种决策查询。

星形模型可以采用关系型数据库结构，模型的核心是事实表，围绕事实表的是维度表。

通过事实表将各种不同的维度表连接起来，各个维度表都连接到中央事实表。

维度表中的对象通过事实表与另一维度表中的对象相关联这样就能建立各个维度表对象之间的联系。

每一个维度表通过一个主键与事实表进行连接，如图3-10所示。

图3-10 星形架构示意图
事实表主要包含了描述特定商业事件的数据，即某些特定商业事件的度量值。

一般情况下，事实表中的数据不允许修改，新的数据只是简单地添加进事实表中，维度表主要包含了存储在事实表中数据的特征数据。

每一个维度表利用维度关键字通过事实表中的外键约束于事实表中的某一行，实现与事实表的关联，这就要求事实表中的外键不能为空，这与一般数据库中外键允许为空是不同的。

这种结构使用户能够很容易地从维度表中的数据分析开始，获得维度关键字，以便连接
到中心的事实表，进行查询，这样就可以减少在事实表中扫描的数据量，以提高查询性能。

在AdventureWorksDW数据仓库中，若以网络销售数据为事实表，把与网络销售相关的多个商业角度（如产品、时间、顾客、销售区域和促销手段等）作为维度来衡量销售状况，则这些表在数据仓库中的构成如图3-11所示，可见这几个表在数据仓库中是以星形模型来架构的。

星形模式虽然是一个关系模型，但是它不是一个规范化的模型。

在星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中关系模式的基本区别。

使用星形模式主要有两方面的原因：提高查询的效率。

采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中，所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高，同时由于维表一般都很小，甚至可以放在高速缓存中，与事实表进行连接时其速度较快，便于用户理解；对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。

图3-11 AdventureWorksDW数据仓库中部分表构成的星形架构
2．雪花形架构
雪花模型是对星形模型的扩展，每一个维度都可以向外连接多个详细类别表。

在这种模式中，维度表除了具有星形模型中维度表的功能外，还连接对事实表进行详细描述的详细类别表，详细类别表通过对事实表在有关维上的详细描述达到了缩小事实表和提高查询效率的目的，如图3-12所示。

雪花模型对星形模型的维度表进一步标准化，对星形模型中的维度表进行了规范化处理。

雪花模型的维度表中存储了正规化的数据，这种结构通过把多个较小的标准化表（而不是星形模型中的大的非标准化表）联合在一起来改善查询性能。

由于采取了标准化及维的低粒度，雪花模型提高了数据仓库应用的灵活性。

这些连接需要花费相当多的时间。

一般来说，一个雪花形图表要比一个星形图表效率低。

在AdventureWorksDW数据仓库中，以图3-11的架构图为基础，可以扩展出雪花模型的架构，“DimProduct”表有一个详细类别表“DimProductSubcategory”，而“DimCustomer”表也有一个表示客户地区的表“DimGeograph”表作为其详
细类别表，将它们加入数据仓库后，整个数据仓库就是雪花形架构，如图3-13所示。

错误！
图3-12 雪花模型架构示意图
图3-13 AdventureWorksDW数据仓库中部分表构成的雪花形架构
3．星形与雪花形架构的比较
在3.1节的讨论中可以得知，在数据仓库中表与表之间是不必满足3个范式的，也不必考虑数据冗余，相反，为了在分析型查询中获得较好的性能，数据仓库中的表还应该尽量集中同类型的数据，同时把有些常见的统计数据进行合并。

按照这种思想，图3-13中的“DimProductSubcategory” 表和“DimGeograph”表可以并入“DimProduct”表和“DimGeograph”表中使整个数据仓库呈现星形架构，但是微软在设计 AdventureWorksDW数据仓库时并没有这样做，反而在“DimProductSubcategory”表和“DimProduct”表及“DimGeograph”表和“DimGeograph”表之间设计成满足一定范式要求的结构，下面将解释其原因。

标准的关系数据表不能满足数据的分析能力，所以对表进行非标准化处理以形成数据仓库中特有的星形架构方式，但这样一来，如果所有的分析维度都作为事实表的一个直接维度，数据的冗余是相当大的，比如将“DimProductSubcategory”表合并到“DimProduct”表中，的确能形成一个关于产品所有属性的维度，但要在一张表中表达产品类别属性和产品的属性，需要的存储空间是相当大的。

由此可以看出，在星形架构的基础上扩展出雪花形架构，实质上是在分析查询的性能和数据仓库的存储容量2方面进行权衡的结果。

表3-3具体比较了2种类型的架构差异。

只有明确了这些差异，才能在设计数据仓库时选择最合适的架构方式。

表3-3 雪花形与星形层次结构的差异
4．星座模式
一个复杂的商业智能应用往往会在数据仓库中存放多个事实表，这时就会出现多个事实表共享某一个或多个维表的情况，这就是事实星座，也称为星系模式（galaxy schema）。

在 AdventureWorksDW数据仓库中有多个事实，为了便于显示，取最重要的2个事实表“FactInternetSales”和“FactResellerSales”作为星座模式的例子。

由于对网络销售和批发商销售的分析有很多观察视角都是相同的，因而这2个事实表共享的维度表较多，比如促销手段、时间和产品等。

在数据库关系图中把它们的关系表现出来后，如图3-14所示。

图3-14 数据仓库的事实星座模式示例
5．数据集市
数据集市是在构建数据仓库的时候经常用到的一个词汇。

如果说数据仓库是企业范围的，收集的是关于整个组织的主题，如顾客、商品、销售、资产和人员等方面的信息，那么数据集市则是包含企业范围数据的一个子集，例如只包含销售主题的信息，这样数据集市只对特定的用户是有用的，其范围限于选定的主题。

数据集市面向企业中的某个部门（或某个主题）是从数据仓库中划分出来的，这种划分可以是逻辑上的，也可以是物理上的。

例如在AdventureWorksDW数据仓库中就是逻辑上划分的数据集市。

数据仓库中存放了企业的整体信息，而数据集市只存放了某个主题需要的信息，其目的是减少数据处理量，使信息的利用更加快捷和灵活。

数据仓库由于是企业范围的，能对多个相关的主题建模，所以在设计其数据构成时一般采用星系模式，AdventureWorksDW数据仓库就是这种情况。

而数据集市是部门级的，具有选定的主题，可以采用星形或雪花模式。

图3-15是数据仓库、数据集市和数据立方之间的关系，通过此图可以更好地理解这3个概念。

错误！
图3-15 数据仓库、数据集市和数据立方之间的关系
附录资料：不需要的可以自行删除
如何构建银行数据仓库
数据仓库技术作为一项数据管理领域的新技术，其精髓在于针对联机
分析处理(OLAP)提出了一种综合的解决方案，与以往很多技术不同的
是，它主要是一种概念，在此概念指导下完成系统的构造。

既没有可
以直接购买到的现成产品，也没有具体的分析规范和实现方法，也就是说没有成熟、可靠且被广泛接受的数据仓库标准。

在以往关系数据库的设计和实现中，不仅有详细的理论推导，还有无数的设计实例，无论你使用的是什么公司的数据库产品、开发工具，只要按照规范做，那么实现同一业务需求的方案都会很相似。

而现有数据仓库的实现中，出现了MOLAP方案和ROLAP方案的区别，出现了形形色色的数据仓库建模工具、表现工具，而设计人员的个人经验和素质也会在其中扮演很重要的角色。

数据仓库技术的实现方式
目前在数据仓库技术的实际应用中主要包括如下几种具体实现方式。

1、在关系数据库上建立数据仓库(ROLAP)
2、在多维数据库上建立数据仓库(MOLAP)
MOLAP方案是以多维方式来组织数据，以多维方式来存储数据；ROLAP方案则以二维关系表为核心表达多维概念，通过将多维结构划分为两类表:维表和事实表，使关系型结构能较好地适应多维数据的表示和存储。

在多维数据模型的表达方面，多维矩阵比关系表更清晰且占用的存储更少，而通过关系表间的连接来查询数据的ROLAP 系统，系统性能成为最大问题。

MOLAP方案比ROLAP方案要简明，索引及数据聚合可以自动进行并自动管理，但同时丧失了一定的灵活性。

ROLAP方案的实现较为复杂，但灵活性较好，用户可以动态定
义统计和计算方式，另外能保护在已有关系数据库上的投资。

由于两种方案各有优劣，因此在实际应用中，往往将MOLAP和ROLAP 结合使用，即所谓的混合模型。

利用关系数据库存储历史数据、细节数据或非数值型数据，发挥关系数据库技术成熟的优势，减少花费，而在多维数据库中存储当前数据和常用统计数据，以提高操作性能。

3、在原有关系库上建立逻辑上的数据仓库
由于目前正在运行的OLTP系统中已经积累了海量数据，如何从中提取出决策所需的有用信息就成为用户最迫切的需要。

新建数据仓库固然能从功能、性能各方面给出一个完整的解决方案，但需要投入大量的人力、物力，并且数据仓库的建设和分析数据的积累需要一段时间，无法及时满足用户对信息分析的迫切需要。

因此在筹建数据仓库的前期，可以采用一些合适的表现工具，在原有OLTP系统上建立起一个逻辑的数据仓库系统。

尽管由于原有OLTP系统设计上的局限性，这样的系统可能无法实现很多分析功能，但这样一个系统中数据结构固定、信息分析需求相对稳定成熟，因此数据仓库的建模、实现过程会相对容易、便捷；同时，这样的系统也会成为将来真正数据仓库建设的原型。

信息系统与数据仓库的关系
由于数据量大、数据来源多样化，在商业银行构建管理信息系统时，不可避免地会遇上如何管理这些浩如烟海的数据，以及如何从中提取
有用的信息的问题；而数据仓库的最大优点在于它能把企业网络中不同信息岛上的商业数据集中到一起，存储在一个单一的集成的数据库中，并提供各种手段对数据进行统计、分析。

因此可以说，在银行使用数据仓库构建管理信息系统，既有压力，又有数据基础，它们之间的联系是必然的，难以割舍的。

数据仓库在商业银行的应用范围包括存款分析、贷款分析、客户市场分析、相关金融业分析决策(证券、外汇买卖)、风险预测、效益分析等。

在银行信息系统构建时，由于历史情况和现实需求的不同，存在两种途径:
1、建设新系统
由于目前国内商业银行对银行内部运营的监管，缺乏很好的数据搜集机制，因此可以在构建管理信息系统时，分数据收集录入和数据汇总分析两部分来考虑。

这样的系统中由于不需考虑大量历史数据的处理问题，同时考虑到搜集过程中可能存在多个数据来源，因此可以在系统建设的同时构建数据仓库，将搜集来的各种数据通过数据抽取整合到数据仓库中。

2、完善原有系统
而对于已经存在OLTP系统，其中沉淀了大量历史数据，则可以先在原有系统上建立逻辑数据仓库，即使用数据分析的表现工具，在关系模型上构建一个虚拟的多维模型。

当系统需求稳定后，再建立物理数据仓库，这样既节省投资，又缩短开发工期。

实现中需要注意的问题
一、模型设计中的问题
模型设计(包括逻辑模型设计和物理模型设计)是系统的基础和成败的关键，在实际操作中，视实现技术的不同应分别对下列问题引起注意。

1、直接构建数据仓库
直接构建数据仓库时，必须按业务分析的要求重组OLTP系统中的数据，并要按不同侧重点分别组织，使之便于使用。

*主题的确定
主题是一个逻辑概念，它应该能够完整、统一地刻画出分析对象所涉及的各项数据以及相互联系。

划分主题的根据主要来源于两方面:对原有固定报表的分析和对业务人员的访谈。

原有固定报表能较好地反映出以往工作对数据分析的需求，而且数据含义和格式相对成熟、稳定，在模型设计中需要大量借鉴。

但仅仅满足于替代目前的手工报表还远远不应是构建管理信息系统的目标，还应该通过业务访谈，进一步挖掘出日常工作中潜在的更广、更深的分析需求。

只有这样，才能真正了解构建数据仓库模型所需的主题划分。

*分析内容的细化
主题的划分实际上是与分析内容的范围直接相关的，一旦主题划分清楚了，下一步就是细化分析的具体内容以及根据分析内容的性质确定
它在数据仓库中的位置。

通常维元素对应的是分析角度，而度量对应的是分析关心的具体指标。

一个指标究竟是作为维元素、度量还是维属性，取决于具体的业务需求，但从实际操作中可以总结出如下的概念性经验:作为维元素或维属性的通常是离散型的数据，只允许有限的取值；作为度量的是连续型数据，取值无限。

如果一定要用连续型数据作为维元素，则必须对其按取值进行分段，以分段值作为实际的维元素。

判断分析指标是作为维元素还是维属性时，则需要综合考虑这个指标占用的存储空间与相关查询的使用频度。

需要特别强调的是，在细化分析内容的过程中，务必解决指标的歧义问题。

在不同报表中以及在业务访谈中同一名称的指标，是否是在同样条件限定下，通过同样方法提取或计算得到的，它们之间的相互关系是什么，这些问题都必须从熟悉业务的分析人员那里得到准确、清晰的答案，否则将会影响到模型设计、数据提取、数据展现等多个方面。

*粒度的设计
数据仓库模型中所存储的数据的粒度将对信息系统的多方面产生影响。

事实表中以各种维度的什么层次作为最细粒度，将决定存储的数据能否满足信息分析的功能需求，而粒度的层次划分、以及聚合表中粒度的选择将直接影响查询的响应时间。

如果同一个信息系统要在大范围、多层次上同时运行，如部门级和企业级，还应考虑不同层次的数据仓库采用不同的粒度。

*模型设计中的技巧
复合指标尤其是比率类指标的定义，必须注意累加时是先加减后乘除，还是反之。

户数、笔数的计算，这类指标在分析或报表中经常出现，但不需要作为单独的指标物理存在于数据库中，但定义分析模型时一定应该准备。

度量的时间特性，针对分析指标在时间维上的不同表现，可分为可累加指标、半可累加指标和不可累加指标。

2、在原有数据基础上构建逻辑数据仓库
如果直接使用OLTP系统中的数据进行数据分析处理，会遇到许多麻烦，有时甚至是不可能实现的。

这并不是说关系数据库不好，而是因为其设计思路不适应较大规模数据分析。

因此在使用这种方法时，需要注意下列问题的处理:
*不同的时间单位
这是实现过程中最常遇到的问题，也往往是最难解决的问题。

OLTP 系统中存储的时间往往采用与实际业务发生相同的时间单位，如帐务数据单位为日期，财务报表单位为月或半年。

而面向分析时，往往要将不同时间单位的数据统一到同一个结果中，这样就必须存在适当的转换机制才能实现。

*冗余信息
所谓冗余信息，就是指不同关系表中存在的同一含义的字段，而同一含义不仅指这些字段的取得或计算方式一样，还指它们成立的条件一样，例如截止某一时间同一地区的同一贷种的贷款余额。

在OLTP系统中，这样的字段往往是基于性能考虑而设计的，而在面向分析设计模型时，为了保证结果的唯一性和准确性，就必须用且只用其中之一
的数据产生分析结果。

*表间连接
由于OLTP系统中表的设计面向业务处理，既要保证数据的完整性、一致性，又要考虑响应时间，因此表与表之间既相对独立，又相互依赖。

在设计数据仓库逻辑模型时，对表间的连接必须做出相应取舍，既要保证分析数据能通过连接取得或计算出，又要避免出现环路，造成分析数据的歧义。

另外，不同的连接途径还会出现不同的查询速度，影响数据分析的响应性能。

*统计表的设计
如果上述问题不能在原有数据库基础上得到很好的解决，那么权益之计就是构建统计表，即简单化的数据仓库，形式类似数据仓库的事实表，定时计算统计数据放入，将时间、冗余、连接等问题摈除，进行简单分析。

二、数据抽取中的问题
数据抽取是一件技术含量不高，但非常烦琐的工作，必须有专人负责数据抽取的工作。

在对其进行设计时，要注意的问题有:
1、数据抽取的规则要作为元数据进行规范和管理，抽取过程中的源表、源字段、目的表、目的字段、转换规则以及转换条件都要作好详细记录。

这样不仅便于编程人员实现，而且在抽取规则或逻辑模型发生变化时也便于修改。

2、如何记录业务数据库中的变动情况是数据抽取中一个重要的环节。

由于数据仓库中按时间保存数据，因此不同时间点之间数据的差异就
成为一个关键性因素。

通常可以利用数据库管理系统提供的手段在数据库级产生数据变动日志，根据日志再判断数据的变动情况完成抽取，这样是一个从性能、可操作性以及对原业务系统的影响等多方面综合考虑都比较理想的方法。

3、当数据仓库中同一表中的数据来自于原有系统中不同的表，甚至不同的库时，抽取时务必保证这些数据单位一致，而且都满足同一时间条件。

4、数据抽取不仅要考虑数据的提取，还要考虑抽取的时间安排和执行方式，这样才是一个完整的数据抽取方案，也才能保证抽取出来的数据准确、可用。

三、后期维护、优化中的问题
数据仓库的建设是一个长期工作，它同其他系统一样需要在运行的过程中不断进行调整、完善。

这其中包括两方面的工作:
1、性能
数据仓库涉及海量数据的查询，数据的大量写入读出，不仅对数据库系统的要求很高，而且与OLTP系统的要求极为不同，因此在系统设计、实施和维护的过程中，数据仓库系统的性能都是一个不可忽视的问题。

尤其是在运行期间，要密切关注应用对系统资源的消耗情况，针对应用的特点及时对系统进行调整，包括调整数据库参数、数据分片放置、创建特殊索引乃至提高系统配置等。

2、模型
应用与需求是相互促进、不断发展的，随着信息系统建成运行，用户
在对系统了解不断加深的过程中，也会对系统提出更新更高的要求。

如何在最小投入的前提下满足用户的需求，也是一个值得注意和潜心研究的问题。

首先要尽可能挖掘现有系统的潜力，其次考虑，对主题的增加或可在现有系统上增加少量指标就可解决的需求，对系统进行适当调整，最后才考虑对系统进行重构，尽可能减小系统建设中的投入。

数据仓库应用的深化
按照上述方法实现的应用中，主要完成了报表的生成和日常业务的分析，这并不能给企业带来真正的效益，也远远没有发挥出数据仓库的应用价值。

随着应用的深入，可以由企业的技术人员与业务人员紧密配合，规划出对企业有实际价值的应用模型，并根据实际业务的发展不断调整模型自身的参数，以期找出企业运作过程中的规律，即在数据仓库上进行数据挖掘，构建DSS系统，这样才能充分体现构建数据仓库的意义，从而最终为企业带来效益。

尽管数据仓库技术还需要不断发展、完善，但只要企业能认识到信息分析的重要性，业务人员和技术人员能真正配合起来，相信不久的将来会有更多的实用成果出现。