八个提示 清楚认识数据仓库建立

　　你的应用程序必须要反映出数据仓库内的数据源所发生的变化。特别是维度表中的数据，他们更容易改变。但你要怎样维护和记录这些改变呢?

　　首先，最简单的方法是重写现有的记录而不记录变化。很幸运的是，这一方法被许多维度所接受。比如，如果一个部门的名字从"财务"变成"财务和会计"，你可能并不需要维护这一修改历史。然而，在客户或者学生维度，我们就有必要维护名称、婚姻状况、教育水平等其它属性的改变。你的应用程序应该技能取回现在值也能取回历史值。

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

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

　　到此，我们已经介绍了如何处理数据仓库维度中的值的变化。但是Analysis Services维度应该如何呢?为了反映出属性值的变化，你必须重新计算维度。但如果你完全计算了维度，就不得不重新计算多维数据集(Cube)，可是如果你拥有大量的数据时，重新计算多维数据集(Cube)是非常不现实的。所幸的是，你可以使用增量式更新(计算更新)选项来避免重新计算多维数据集(Cube)。

　　事实变化

　　通常人们会认为事实数据表中记录是静止不变的--一旦记录到数据仓库中，你的任务就完成了，对吗?不幸的是，它的回答是"它取决于……"。在一些案例中，比如一个记录病人住院的数据仓库，所有的数据通常都是静止的。如果你从1月1日到1月5日住院，那么数据并不会发生变化。

　　但是考虑到零售行业，所有的销售并不是不变的--你一定知道有些人经常以各种原因将他们购买的物品退回给商店。一些公司通过记录赊账和借帐来管理这类事务。但在一些案例中，你必须要更新或者删除事实数据表中的记录，尽管他们已经被添加到数据仓库中。比如，如果一条股票交易记录不正确，使用一条相反的记录来抵消它是无法接受的。这里有另一个问题值得考虑：你可能并不想要你的客户知道你的事务系统出现了问题。你只希望他们在数据都恢复正确以后看到它。

　　一种处理事实变化的方法是先将数据记录在暂时存储区，直到数据经过检验并符合要求后，再将其转移到数据仓库中。然而，就算在全面的测试也无法捕捉到数据源的所有错误。有时，你可能需要对多维数据集中包含不正确数据的分区进行重新计算。这就是为什么你有必要保持你的Analysis Services分区尽可能的小，一边在必要的时候相对快速进行重新计算。

　　另一种方法是通过写回分区来解决这一问题。通过多维数据集的写回，你并不是真的在关系数据仓库中修改数据，而是在一个独立分区中添加了一条记录。当一个用户查询一个特殊的度量值组，Analysis Services会将只读分区的数据和写回分区的数据相结合，然后显示出结果。当然，执行这种计算会给Analysis Server增加额外的计算时间，并造成性能的下降。

　　实现安全

　　像其它的商业应用程序一样，保证数据仓库和多维数据集的访问安全是势在必行的。依据作业名称和职责领域的不同，每一个用户可能只被允许访问数据仓库的一小部分，Analysis Services通过将Window帐户和Analysis Services角色相联系来实现安全。它是你可以在非常小的粒度级以至单独的多维数据集单元上实现安全。

　　不幸的是，为每一个用户创建一个单独的角色不仅麻烦而且还可能带来性能问题--尤其是在Analysis Services 2005以前的版本。我们建议你如果可能的话，最好将你的用户分成少数的几个角色组。如果必须要为每一个用户设置他单独的权限，那么，你有必要实现一个安全维度。一旦你拥有了这个维度，每一个MDX查询的结果都将依据现在用户的身份进行过滤。

　　当然我无法在一篇文章中覆盖所有数据仓库可能遇到的问题，也没有哪个人可以宣布他熟悉建立数据仓库解决方案所涉及的所有问题。然而，如果你打算尝试实现这一解决方案，你需要谨慎的考虑你可能面临的问题。在实施之前，请尽可能地做好准备工作。