微软BI系列-设计技巧
微软BI系列-设计技巧（一）—— 使用MERGE语句进行渐变维处理
from:http://www.dwway.com/?uid-34717-action-viewspace-itemid-6709
作者：Warren Thornthwaite
译者：Daniel Zhen
很多ETL工具都提供了处理渐变维度的功能。也有些情况下，当此类工具不能满足需求时，ETL开发者将直接面对数据库，验证更新或变化了的行，并恰当的使用INSERT和UPDATE命令处理之。在“深入数据仓库生命周期”课程上，我已经演示了使用INSERT和 UPDATE语句的代码。几个月后，我的朋友Stuart Ozer告诉我，使用SQL Server 2008中的MERGE语句在代码执行方面有更好的效率。他所引用的是MSSQLTips.com上Chad Boyd的Blog，这给了我一些如何实现的启示。MERGE是INSERT，UPDATE和DELETE的组合，它有效的降低了语句的复杂度。
本例处理的是简单的客户维度，它具有两个属性：first name和last name。我们将把first name作为类型1处理，把last name看作类型二处理。记住，所谓类型1是指维度属性的旧值覆写；类型二是通过增加新值让跟踪历史纪录更具效率。
步骤1: 覆写类中的变化值
我曾尝试在整个例子中只使用一次MERGE语句，但该函数属于确定性函数，每次只能执行一次update语句，所以我在下例中分别使用了多个MERGE进行类型1更新。因为类型1定义为更新，所以也可以使用update语句直接处理。
MERGE INTO dbo.Customer_Master AS CM
USING Customer_Source AS CS
ON (CM.Source_Cust_ID = CS.Source_Cust_ID)
WHEN MATCHED AND --根据类型1更新所有已存在的行
CM.First_Name <> CS.First_Name
THEN UPDATE SET CM.First_Name = CS.First_Name
以上简版的MERGE语句，通过关联业务键，更新所有主表和原表中First_Name不一致的行，实现了Customer_Source表和Customer_Master维度的归并。
步骤 2: 处理类型2中的变化值
现在我们将使用另一个MERGE语句来处理类型2中的变化值。这是件比较棘手的事，因为在跟踪类型2变化值是会有很多的步骤。执行我们代码将需要：
1. 在截止时间前，适当并有效地插入新客户数据行。
2. 通过设置恰当的终止时间和设置current_row flag = ‘n’，标识类型2中维度属性变化的行。
3. 通过设置恰当的终止时间和设置current_row flag = ‘y’，插入类型2的变化行。
这样做会导致太多的步骤需要MERGE处理的问题。幸运的是，MERGE可以流化输出到下一个过程。我们将使用这一功能，使用SELECT从MERGE的结果中选择行并插入到Customer_Master表中，最终完成类型2变化行的插入。听上去，这是一种复杂的并容易出问题的方法，但是它的好处在在于可以一次性找到类型2中变化了的行，并可以多次使用。
代码以INSERT和SELECT语句开始，用来在MERGE语句执行后处理变化行插入。之所以把它们放在前面，是因为MERGE是包含在 INSERT嵌套中的。代码中包含很多对于当前日期的引用，代码中假设变化自昨天起有效（getdate()-1），即前天（getdate()-2）的数据可以被标识为退化。最后，我列出了代码，并根据行号进行说明：
1 INSERT INTO Customer_Master
2 SELECT Source_Cust_ID, First_Name, Last_Name, Eff_Date, End_Date, Current_Flag
3 FROM
4 ( MERGE Customer_Master CM
5 USING Customer_Source CS
6 ON (CM.Source_Cust_ID = CS.Source_Cust_ID)
7 WHEN NOT MATCHED THEN
8 INSERT VALUES (CS.Source_Cust_ID, CS.First_Name, CS.Last_Name,
convert(char(10), getdate()-1, 101), '12/31/2199', 'y')
9 WHEN MATCHED AND CM.Current_Flag = 'y'
10 AND (CM.Last_Name <> CS.Last_Name ) THEN
11 UPDATE SET CM.Current_Flag = 'n', CM.End_date = convert(char(10), getdate()-2, 101)
12 OUTPUT $Action Action_Out, CS.Source_Cust_ID, CS.First_Name, CS.Last_Name,
convert(char(10), getdate()-1, 101) Eff_Date, '12/31/2199' End_Date, 'y'Current_Flag
13 ) AS MERGE_OUT
14 WHERE MERGE_OUT.Action_Out = 'UPDATE';
代码注释
- 1-3行执行典型的INSERT语句. 将用来在最后插入类型2的变化行。
- 4-6行执行MERGE，装载Customer_Source数据进入Customer_Master维度表。
- 第7行说明如果无法匹配业务键，我们必须有一个新的客户数据加入，因此第8行执行了插入操作。你可以通过参数化有
效日期取代假设的昨天的日期。 - 9-10行定义了业务键可以进行匹配的行的子集，特别是，Customer_Master表中已有数据和类型2中 数据不同的行记录。
- 第11行通过设置的结束日期和把当前行标志设置为“n”，实现了当前行的退化。。
- 第14行限制了Customer_Master中需要更新的行，虽然相关退化的行已经在第11行进行了处理，但是我们是从第12行从Customer_Source表中输出了当前值。
总结：
MERGE语句最大的优势在于，一个数据集可以被多次处理，而不是多次请求分别处理插入和更新操作。优秀的性能优化专家会用到这一非常有效的方法。
原文链接：http://www.dwway.com/?uid-42816-action-viewspace-itemid-6338
微软BI系列-设计技巧（二）—— 数据仓库能否受益于SOA?
from:http://www.dwway.com/?uid-34717-action-viewspace-itemid-6710
作者：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
浙公网安备 33010602011771号