如何避免星型模式中的复杂连接？

Posted 2023-03-29

【中文标题】如何避免星型模式中的复杂连接？

【英文标题】：How do I avoid complex joins in star schema?

【发布时间】：2010-06-29 13:31:27

【问题描述】：

我的事实表包含用户在他参加的课程中的分数。我必须在报告中显示的课程的一些细节来自不止一个表（在实际的 OLTP 数据库中）。 我是否在维度表中创建该课程条目的非规范化版本？ 还是我只是将事实表直接连接到课程表连接到描述该课程的其他表（课程类型，创建该课程的教师等）

【参考方案1】：

雪花或桥接表确实使联接更加复杂，不仅从编码的角度来看，它还使 BI 用户变得不那么简单。

在大多数情况下，我会将这些直接放在现有的或附加的维度表中。

例如，您有一个分数事实表，它在一个维度中包含用户详细信息，该维度可能包含也可能不包含用户的人口统计数据（也许它只是一个桥梁）。有时最好将人口统计信息分开。因此，即使性别和年龄可能与用户实体相关联，但在维度模型中，这些可能是单独的维度或集中到单个维度中 - 这一切都取决于使用场景。

也许您的分数附加到一个州，并且州有区域（雪花）。直接链接区域维度而不是通过状态维度进行分析可能更有效。

我想你会发现维度模型是一种非常实用的非规范化方法。不可协商的主要事情是事实 - 之后维度的选择在很大程度上取决于数据的行为，您对常见使用场景的预见 - 并避免陷入维度太少和维度太多的问题。

【参考方案2】：

也许我不明白你的问题，但星型模式中的事实表应该连接到它周围的维度表。 如果您不想进行联接，只需创建一个视图，然后使用该视图进行报告。

如果您要发布模型（模式），评论/帮助会更容易。

【讨论】：

我对单步加入维度没有任何问题。但是假设这个维度包含更多的外键，这意味着我必须进一步将 dimension 表连接到一些查找表甚至更多表。

听起来像雪花设计。这没什么错，只要 DW 设计师有充分的理由要下雪花。

【参考方案3】：

通常的做法是将多个维度合并在一起，牺牲标准化以提高性能。这通常在您的典型查询需要所有维度一起使用时完成（而不是针对不同的用例使用不同的位）。

还请记住，虽然您会减少连接开销，但也有一些缺点：

失去灵活性，这可能会随着仓库的扩展而阻碍开发 全表扫描需要更长的时间（在传统的基于行的 RDBMS 中，例如 SQL Server） 磁盘空间消耗

您必须分别考虑每种情况。

如果您的 RDBMS 提供了创建物化视图的选项，那么考虑创建物化视图的选项可能也是值得的。

【参考方案4】：

我们通常将雪花模式作为物理 DWH 设计，但添加了一个报告视图层，将雪花模式扁平化为星型模式。

通过这种方式，您的 OLAP 多维数据集变得更加简单且易于管理。