用SQL Server 2005构建高性能数据仓库

核心提示： 三．表的设计对于数据仓库（它的数据直接被最终用户消费）的物理设计通常有两种方法，第一种方式是保留源数据的三种通常的表格设计，用SQL Server 2005构建高性能数据仓库(6)，这个设计对操作性的报表很好，在第三方的源码系统的情况下，但是如果更新能够像它们所需要的那样被得到很好的控制，

三．表的设计

对于数据仓库（它的数据直接被最终用户消费）的物理设计通常有两种方法，第一种方式是保留源数据的三种通常的表格设计。这个设计对操作性的报表很好。在第三方的源码系统的情况下，这种数据库能够满足应用报表。

第二种方式是空间的设计，这通常作为一个星型或者雪花型的方式提及。这种方法的主要好处是简单而且性能良好。这个模型的简单使得它变得更加容易，并且终端用户掌握和浏览它更加快速。空间数据在相关的设计的性能上能够在实际的测试中被观察到。

接下来的一个设计问题是实现星型还是雪花型方式的设计。这在过去存在一个具有争论性的辩论，但是雪花型方式获得了越来越多人的支持。传统的对于雪花型的争论是数据模型复杂度和性能缺陷。

在SQL Server环境中，星型跟雪花型的设计比起来，性能很少是一个大问题。甚至在更大一点的维度，例如客户的维度，来自雪花型设计的结果的更窄的表通常为额外的连接进行了补偿。这个再一次能够在你自己环境中的测试情景中观察到。

1. 声明式的具有参考作用的集成度和限制

在数据仓库中，需要维护在数据集成度和性能需要中的很好的平衡。虽然数据集成度极端重要，对数据仓库的更新通常通过周期性（通常为每日或每小时）的批量ETL过程得到很好的控制。星型或雪花型模型严格上意味着那些低级别的维度表包含一个主键，这个主键是一个代理键。源系统没有它们的代理键的信息，因此它必须在ETL中通过寻找业务键来获得。定义声明式的具有参考作用的集成度很大程度上降低了ETL代码的性能，并且在这种情况下是冗余的。

此外，数据集成度得到了优先权，但是如果更新能够像它们所需要的那样被得到很好的控制，推荐在实际的表和空间的表中，以声明式的外键/主键关系方式出现的具有参考作用的集成度能能够被忽略。