1

最近有点疑惑，求解答。

通常，在设计数据仓库时，我们要么使用星型模型，要么使用雪花模型，要么使用混合模型，通常我们将主数据规范化为维度表（当然有时出于性能考虑，去规范化）。我的问题是，规范化成维度表，或者创建各种不同的维度表，有什么好处？

如果是为了节省空间，那么 SQL Server 不同级别的压缩已经节省了空间。 例如，在一个事实表中，有一个 varchar(max) 列，它只有 1% 的唯一值，然后将其归一化为维度表，并将 key 放入事实表中，这将有助于节省空间；但是，由于 SQL 行级压缩，理论上它的工作方式相同，而是通过您自己的设计进行规范化，SQL Server 会找到字符串模式并保存在某处，行内只是指针，因此空间使用量理论上就像钥匙。

如果是为了提高查询性能，那么对于维度表，无论维度上有什么索引，都需要至少先进行非集群索引扫描/索引查找维度表获取key，再使用key获取集群索引/或 RID，然后获取完整数据。那是 2 倍的 I/O。如果没有维度，您仍然有事实表上的索引，对应的列，由于压缩，您的索引表将与您在维度表上创建索引的大小相似。所以，当你查询时，可能也是一次非集群索引扫描/集群索引查找/然后全量数据，所以I/O可能会更小，加上没有join，查询性能可能会更快.

那么，如果我已经进行了压缩，为什么还需要维度？

4

3 回答 3

2

维度模型不仅仅与数据库的物理设计有关。如果您发现在“视图层”中创建星型模式时性能更好，下面是 3NF 表，太好了！

星型模式是为了让报告编写者和最终用户能够访问来自多个来源的数据，然后可以通过多种不同的方式对其进行聚合和分析。如果我必须写一份报告显示“x 类产品销售额 > 10000 美元的客户的平均延迟发票数量”，规范化模型将要求我转到销售系统的每个子表，可能产生一个有 10 - 50 个连接的查询！

想象一下，我是一名报告编写者，当我想做一些不同的事情时，我必须记住所有这些连接......或者更糟的是，我是一个编写基本 SQL 的业务用户，我不知道如何做这么多的加入。

因此，识别数据中的业务关系的艰苦工作是预先完成的，并且构建了事实表，将我的发票数据与与之相关的描述性数据连接在一起。现在，我只需按产品事实查询客户总销售额，然后获取结果客户集，并加入发票事实（甚至是预构建的聚合）以获得平均延迟发票数。可能有 2-4 个表连接，而且对报告作者来说更容易。

于 2013-03-16T16:49:20.057 回答
1

我不明白你为什么要关联压缩和尺寸。仓库的全部意义在于忘记压缩和规范化，并为需要最少数量的表连接的东西建模，以便尽可能快地获取数据。

假设您在桌子上放置了您未来房屋的 3D 模型。您会希望从各个角度查看模型，以便对房子有更多了解。同样，我们有维度，以便我们可以从所有可能的角度查看数据。这就是米奇说“切片和切块”时的意思。

维杰。

于 2013-03-16T14:26:07.510 回答
1

您必须考虑尺寸值的变化。

如果您的一位客户结婚并且您需要按当前婚姻状况搜索您的数据，您是否希望：

  1. 更新该客户的单个维度记录，或者...
  2. 为该客户更新事实表中的每条历史记录？

规范化的关键原则之一是您将每项信息仅保存在一个位置，并且不会随着数据仓库的变化而改变。

于 2013-03-18T13:45:07.123 回答