作者：Ralph Kimball - October 10, 2008
译者：Daniel Zhen
在IT部门缺乏预算的情况下，面向服务的架构（SOA）正蓬勃发展。简单的说，围绕SOA构建业务环境意味着采用可复用的服务，并以资源为中心通过典型的Web应用传输这些服务。其需求来自于在大型企业中服务仅加载一次的，从而节约运营成本的考虑。因为所有的通信都是通过枢纽通信协议，通常是采用WSDL-SOAP-XML，从而使服务独立于硬件和操作系统平台。
虽然，SOA所有的益处都已经得到了验证，但是早期的SOA实践者还是从中学到了些值得深思的有价值的东西。这之中包括：数据质量、数据集成和管理方式。长话短说，SOA可能会碰到如下问题：
1. SOA构建在数据质量不佳的平台上。
2. 需要共享的数据没有进行跨企业集成。
3. 在实施中对于安全性、协调和变更管理考虑不周。
SOA架构也从中学到了“运用容器隐藏细节”的理念。当服务比较简单的时候，它们可以满足SOA架构的要求，但它们并不支持基础应用中复杂的商业逻辑。
所以，数据仓库能否受益于SOA理念么?我们是否可以在数据仓库的世界中定义“抽象服务”，具有通用性验证、状态简单、独立数据源、特定业务过程和BI部署的“抽象服务”呢？我们当然可以。
想象一下维度管理者和事实提供者之间的关系。要知道维度管理者是以资源为中心定义和发布企业级的一致性维度。虽然主数据管理（MDM）资源是理论上的维度管理者，但是我们很少能拥有足够的MDM资源功能。笼统上说，数据仓库团队属于MDM下游功能，用来整合表达不一致的实体，如在数据仓库社区中发布经过清洗、统一和去重的客户维度。该维度的订阅者通常是事实表的拥有者，他们会把高质量的统一的维度加载到实事表中，从而使企业级的BI工具可以通过拥有一致内容的维度，执行跨报表钻取。如果你对以上文字中的词汇还不熟悉，你需要查阅一下相关资料。请参看《Data Warehouse Lifecycle Toolkit, 2nd Edition》，或者我去年在DMReview上发表的一系列介绍性文章。
每个维度管理和发布者，需要为他们的事实表订阅者提供相应的服务。Fetch意味着事实表提供者从维度管理者处抓取信息，Alert意味着维度管理者推送信息至事实表提供者。
- 抓取特定的维度成员（我们假设在本步骤和以下步骤中，维度记录具有代理主键，维度版本成员，被请求的信息可以在安全和隐私权限下进行连续传输）。
- 抓取所有维度成员
- 针对不同的事实表提供者，抓取与代理键对应的自然键。
- 推送提供新版维度的发布（主要的维度发布都提供的维度更新功能，因为类型1或3的变化已经被用于选定的属性）。
- 推送新加的维度成员至事实表提供者（需要事实表提供者覆写选中的事实表中的外键）。
这些服务通用于所有集成的数据仓库。在一个维度建模的数据仓库中，我们可以分别描述统管过程的步骤，而不用考虑事实表和维度表的主题。这就是为什么，用SOA的说法，维度模型很好的定义了一个参考架构作为服务的基础。
在对于SOA设计需求的符合度上，这些服务很有说服力。一个有趣的问题是，在事实表提供者和BI客户间的抽象服务也能一蹴而就？如何为客户推送KPI变化？也许这也是可能的。如果该方法得到论证，我将继续根据这一主题。同时，我推荐大家阅读《Applied SOA: Service-Oriented Architecture and Design Strategies (Rosen, et al, Wiley 2008)》一书。
原文链接：http://www.dwway.com/?uid-42816-action-viewspace-itemid-6364
译者介绍：
甄浩，北京迈思奇BI开发工程师，资深BI咨询顾问，软件工程专业硕士。
主攻数据仓库、OLAP建模、数据挖掘、企业绩效管理等技术领域，具有6年的BI项目实施和咨询经验。 |
