建立数据仓库：入门的八个诀窍

admin

用SQL Server技术建立一个数据仓库时，你可能会面临一些挑战。我将给你一些建议来克服它们。当然，每个环境可能会给建立数据仓库所面临的挑战增添自己的难度，但是这些建议大多数都是通用的，足以应用于许多公司着手构建商业智能(BI)应用。

　　1. 管理部门的支持。这是你必须要克服的第一个，也是最重要的挑战。它困扰着技术人员(当然包括你)，因为它涉及政治而不是软件。但是让我们记住是谁签发你的薪水。如果管理部门不相信他们需要一个数据仓库，那你的所有技能都是无用的。

　　不幸的是上层管理人员至今仍经常认为数据仓库是另一个系统，他们需要投资却不能立即获得回报。你的工作就是使他们确信他们不会是在购买一些无用的东西——数据仓库会通过使企业中分散的数据关联起来，从而帮助他们做出更好、更明智的决定。在采用了数据仓库之后组织运行方式完全改变是并不罕见的。有时它会帮助建立一个概念证明模型(POC)项目来证明商业智能的力量。POC数据仓库将只包含所有数据的一小部分，并将只显示给一小部分人，以便测试。即使你并没有获准采用POC，你也应该证明数据仓库的某些部分将有益于你的用户，这么做使他们有兴趣并确信这个系统将帮助他们使他们的工作更有效。

　　2. 数据可用性。数据仓库将不一定明显或不一定容易获得的多个数据源的数据结合起来。根据公司的规模不同，你可能需要到多个办公室和许多雇员谈话来弄清楚你可以从哪获得那些用于生成你的用户想要的分析视图的必要的数据。再次，根据你的公司的政治氛围的不同，你可能发现要获得所有的必要数据元素很困难。因为你用的数据可能包含机密和高敏感性的细节。此外，一些数据可能只能通过一个外部实体所提供的报告访问，而他不会给你他们的数据源的访问权限。

　　你怎么克服这个挑战?首先，一定要说服每个人你不会取代他们的工作。数据仓库是用来补充的而不是取代任何已存在的系统。如果有管理层站在你这边，你就不会有太多内部员工的问题。但是如果你不能访问数据源——因为不可预见的原因——那么你可能就需要用创造性来解决这一问题了。如果数据只能通过报告屏幕或纸上来获得，那么你可能需要找到个方法来捕获这个数据，可能通过抓取报告屏幕或扫描文档。

　　3. 数据源的复杂性。有时你很幸运，你需要的所有的数据元素都在你选择的数据库管理系统(DBMS)中。更多时候，数据是分散在多个数据库管理系统中的，电子表格、电子邮件系统、电子文档，甚至纸张上。是的，我们是在21世纪，但是记住我的话——还是有一些其它的公司是把某些数据只保存在纸上的。这是你的工作，找出怎样从分散的数据源获得数据并转化为共同的形式，然后录入到你的数据仓库中去的方法。

　　4. 数据质量。许多交易处理应用通常是由对其使用的工具具有有限的知识或经验的人利用快速发展的技术放到一起的。这并没有贬低的意思;一个人必然要从某一处开始，而初级程序员是公司可以使用的最实惠的资源。麻烦的是如果这个应用没有验证数据那你很可能发现字符串类型的数据是缩写的、拼错了或完全遗漏了。对于交易级别的报告，这可能不是什么大问题，但是当你试图给数据分组并提供给你的用户作做决定的能力时，数据质量就是至关重要的了。

　　例如，看一下下面的用户姓名：

　　a. ACME Boot Outlet

　　b. ACME bt outlt

　　c. A.C.M.E

　　d. Boots (ACME)

　　e. A c m e boot store (outlet)

　　人眼可以很容易的辨识出上面的每一个都是指同一个事务实体。但是对于计算机程序来说，每一个值代表一个不同的用户。不幸的是利用集成服务(或者数据转移服务)包没有容易的方法来校正所有的不好的数据。SQL Server2005集成服务提供了模糊查询转化，它可以大大简化你的数据清理工作。但即使如此，你可能还是需要文职人员帮忙修正数据。

         5. 你的用户数目和技术领悟力。帮助一些用户获得他们所需的数据以便作出决策并不是一件容易的事。过去，数据仓库是给高层管理人员使用的。但是慢慢的，数据仓库转向了大多数人群。看到不一定做决策的用户使用数据仓库和商业智能应用是很平常的。

　　一旦你的用户看到了数据仓库的强大力量，他们将会想从数据访问到获取交易级报告等任何事情都使用数据仓库。你的用户群越大，保证每个人都满意并培训他们恰当使用你的应用程序就越困难。如果使用恰当，商业智能应用可以发挥很大的作用，但它并不是适合所有的商业需求。你经常得传送不好的消息，那就是数据仓库并不是满足你的用户期望的功能的可选工具。

　　6. 维度慢慢改变。你的应用必须反映出移植到仓库中的数据源所发生的数据变化。维表中的数据特别容易变化。但你怎么维护记录的历史变化呢?

　　第一个也是最简单的方法是重写现有的记录而不跟踪变动。幸运的是，这个方法被许多维度所接受。例如，如果一个部门名称从“财务”变为“财务和会计”，你很可能并不需要记录这种历史变化。但是，从客户和学生的角度看，常常有必要保持跟踪姓名、婚姻状态、教育程度和其它属性的变化——你的应用必要能够获得当前的以及历史的数值。

　　管理维度慢慢改变的第二个方法是数值发生变化时创建一个新的记录，并将旧的记录标记为旧记录。

　　第三个也是最后的一个方法是维护在维表的同一行中不同列的变化域的历史数值。

　　到此，我们已经介绍了如何处理数据仓库维度中的值的变化。但是分析服务维度怎么处理呢?要反映属性值的变化你必须重新处理维度。但是如果你完全处理维度，你就不得不也重新处理多维数据集，如果你的多维数据集包含大量数据，那这就可能不太现实了。幸运的是你可以经常使用渐进式更新(过程更新)选项来避免重新处理多维数据集。

　　7. 事实变化。通常人们认为事实表中的记录是静态的——一旦这条记录录入到了仓库中你的工作就结束了，是吗?不幸的是这个回答是“它取决于。”在某些情况下像在一个数据仓库跟踪病人的住院情况，所有的记录通常都是静态的。如果你从1月1日到2月5日住院，那这条记录不太可能改变。

　　但是考虑到零售行业，所有的销售都不是最终的——我肯定你知道有些人经常将它们购买的货物因为各种原因而退回商店。一些公司管理这种交易为一系列信用和负债来结算每笔交易。但在其它的情况下你必须更新或删除事实表记录，甚至在它们添加到了数据仓库之后。例如，如果一个股票交易记录不正确，用一个相反的交易来结算是不能接受的。还有另一个问题要考虑：你可能不希望你的客户知道你的交易系统中存在的问题。甚至你希望他们只在数据被修正后才看到数据。

　　处理事实变化的一个方法是将数据放在暂存区域直到它经过了质量检查，然后将其移植到仓库中。然而有时甚至是最全面的测试也无法捕获数据源中的所有错误，你可能需要通过处理这些包含错误数据的部分来更新多维数据集。这就是为什么有必要保持你的分析服务部分尽可能的小以便处理可以相对快一些。

　　另一个处理这个挑战的方法是采用一个回写分区。采用多维数据集回写，你没有真的改变关系数据仓库中的数据;而是在一个单独的分区中添加了一条记录。当用户查询一个特殊的测量值组时，分析服务将只读分区的数据和回写分区的数据结合起来，然后显示结果。当然，执行这样的查询计算会额外增加分析服务器的执行时间，并会造成性能下降。

　　8. 实现安全。就像任何其它的商业应用一样，必须保护对你的数据仓库和多维数据集的访问。每个用户可能只被允许看到数据仓库的一小部分，这取决于他们的工作职务或责任范围。分析服务通过可以与分析服务角色相关联的Windows帐户来保证安全。你可以以非常小的粒度级以单个多维数据集单元为单位来实行数据保护。

　　不幸的是为每一个用户创建一个单独的角色不仅麻烦而且还会引起性能问题——尤其对于分析服务2005之前的版本。建议如果可能的话你把你的用户分为较少的几种角色。如果每一个单独的用户需要有她自己的权限设置，那么你需要实现一个安全维度。一旦你有了这样的安全维度，每一个MDX查询都将根据目前的用户身份进行输出过滤。

　　当然我无法在一篇文章里介绍所有的数据仓库问题。也没有任何人可以说他熟悉建立数据仓库解决方案所遇到的每一个问题。但是，如果你打算尝试实现这样的解决方案，你应该谨慎的考虑你将要面临的是什么。做好准备工作，准备迎接挑战。