最近我有一些疑问，寻找答案。
通常，在设计数据仓库时，要么使用星型模型，要么使用雪花模型或混合型，通常我们将主数据规范化为维度表（当然有时需要考虑性能，去标准化）。我的问题是，规范化到维度表，或创建各种不同的维度表，有什么好处？
如果为了节省空间，那么SQL Server不同的压缩级别已经节省了空间。 例如，在一个事实表中，有一个varchar（max）列，它只有1％的唯一值，然后将其规范化为维度表，并将key放在事实表中，这将有助于节省空间;但是，由于SQL行级别压缩，它在理论上以相同的方式工作，而不是由您自己的设计规范化，SQL Server将找到字符串模式并保存在某处，行内只有指针，因此空间使用在理论上就像键。
如果要提高查询性能，然后使用维度表，无论您在维度上有什么索引，您都需要至少首先使用非群集索引扫描/索引来查找维度表以获取键，然后使用键获取集群索引/或RID，然后获取完整数据。这是I / O的2倍。如果没有维度，您仍然具有事实表的索引，相应的列，由于压缩，您的索引表将与您在维度表上创建索引时的大小相似。所以，当你查询时，可能它也是一次非集群索引扫描/集群索引寻找/然后是完整数据，所以I / O可能甚至更小，加上没有连接，查询性能可能更快。
那么，如果我已经有压缩，为什么还需要尺寸？
答案 0 :(得分：2)
维度模型并非完全与数据库的物理设计有关。如果您在“视图层”中创建星型模式并且下面是3NF表时发现性能更好，那就太棒了！
星型模式允许报表编写者和最终用户能够访问来自多个源的数据，然后可以通过多种方式进行聚合和分析。如果我必须编写一份报告，显示“x类别产品销售额> 10000美元的客户的延迟发票平均数量”，则标准化模型将要求我转到销售系统的每个子表，可能导致查询10 - 50个连接！
想象一下，我是一名报告撰稿人，当我想做一些与众不同的事情时，我必须记住所有这些联接...或者更糟糕的是，我是一个编写基本SQL的商业用户，我没有第一个线索如何做这么多连接。
因此，预先完成识别数据中业务关系的艰苦工作，并构建事实表，将发票数据与相关的描述性数据连接在一起。现在，我只是按产品事实查询客户总销售额，然后获取最终的客户组，并加入发票事实（甚至是预建的聚合）以获得平均晚期发票数。也许2-4个表连接，在报表编写器上更容易。
答案 1 :(得分：1)
我不明白为什么要关联压缩和尺寸。仓库的重点是忘记压缩和规范化，并对需要最少数量的表连接的内容进行建模，以便尽可能快地获取数据。
假设您将未来房屋的3D模型保存在桌面上。您可能希望从各个角度看模型，以便您了解有关房屋的更多信息。同样，我们有尺寸，以便我们可以从各个角度查看数据。这就是米奇在说“切片和切块”时的意思。
维杰。
答案 2 :(得分：1)
您必须考虑更改尺寸值。
如果您的某个客户结婚并且您需要按当前婚姻状况搜索您的数据，您是否希望：
规范化的一个关键原则是，您只能在一个位置保存每项信息，而且不会随数据仓库而改变。