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

我的事实表保存了一个他参加的课程的用户分数。我必须在报告中显示的课程的一些细节来自多个表（在实际的OLTP db中）。
我是否在维度表中创建该课程条目的非规范化版本？

---

或者我只是将事实表直接连接到课程表连接到描述本课程的其他表（课程类型、创建本课程的教员等）

也许我不理解你的问题，但是星型模式中的事实表应该连接到围绕它的维度表。 如果不想进行连接，只需创建一个视图，并使用该视图进行报告

---

如果要发布模型（模式），注释/帮助会更容易。

降雪表或桥接表确实会使连接更加复杂，而且不仅仅是从编码角度来看，它还使BI用户不那么简单

在大多数情况下，我会将这些直接放在现有或其他维度表中

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

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

---

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

将多个维度合并在一起是一种常见做法，为了性能而牺牲规范化。这通常是在您的典型查询需要将所有维度放在一起时完成的（而不是在不同的用例中使用不同的位）

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

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

你必须分别考虑每一种情况。

---

如果您的RDBMS提供这种能力，也可以考虑创建物化视图的选项。

< P>我们通常有一个雪花模式作为物理DWH设计，但是添加一个报告视图层，将雪花模式变为星型架构。

---

这样，您的OLAP多维数据集变得更简单、更易于管理。

我对维度的单步连接没有问题。但是假设这个维度包含更多的外键，这意味着我必须进一步将维度表连接到一些查找表或更多的表。听起来像雪花设计。这没什么错，只要DW设计师有充分的理由解释为什么会雪花飘落。