如何避免星型模式中事实表之间的连接？

Question

我尝试使用星型模式对数据仓库进行建模，但我有一个问题是要避免事实表之间的连接。
为了解决我的问题，我想收集操作系统上发生的所有事件。因此，我可以创建一个包含event或datetime等维度的事实表user。问题是我想收集不同类型的事件：硬件事件和软件事件 问题是那些事件的维度不同。例如，对于硬件事件，我可以有physical_component或related_driver维度，对于软件事件，software_name或online_application维度（这只是一些示例，要记住的一个想法是event可以专门用于具有特定维度的特定事件。） 在关系模型中，我将有3个表组织如下：
问题是：如何处理星型模式中事实表之间的连接？

---

我想到了4个想法，但我不确定其中一个是否适合这种情况 第一个是保留关系数据库中使用的模型，并添加如下维度表：

在这种情况下，问题是我们仍然在事实表之间进行连接，并且需要在所有查询中使用JOIN SQL语句。

---

第二个是仅创建2个将复制共享维度（日期时间和用户）的事实表，并创建汇总所有事件的物化视图事件：

这里的问题是：如果我想在物化视图上进行查询会发生什么？根据我在Oracle文档中读到的内容，我们不必直接在物化视图上进行查询，但我们必须让查询重写过程能够正常工作。

---

第三个是仅创建一个事实表，其中包含事件（硬件或软件）可能的所有信息：

这次，问题是我的事实表将包含很多NULL值。

---

最后一个是创建3个事实表（这次没有物化视图），如下所示：

这一次，问题是事实表event和它自己的表中都存在所有事件。因为我们将存储大量数据，所以我不确定这种重复是一个好主意。
那么什么是最好的解决方案？或者它是否存在第五种解决方案？

Answer 1

从您的描述和随后的评论到其他答案，我会说选项2或选项4是从维度建模角度对事物进行建模的正确方法。每个事实都应该是业务流程的衡量标准，软件和硬件事件的维度似乎是完全不同的，它们需要单独存储。

然后，还有一种情况是将单独的事件表存储为视图，物化视图或存储常见事物的普通表。

一旦你确定这是“按逻辑”模拟事物的正确方法，那么你需要平衡性能，可维护性，可用性和存储。 对于维度建模，查询的可用性和性能是最重要的（否则您可能根本不使用维度模型），ETL中的额外工作以及所需的额外空间是值得付出的价格。

非实体化视图会以性能价格为您节省空间，但可能是您可以为其提供足够强大的索引或两个可以减轻这种情况的索引。物化视图将以存储价格为您提供性能。

我很想用索引和非物化视图创建两个事实表，并在采取进一步的性能增强步骤之前看看它的表现是什么样的。 1000万个事实行并不是那么糟糕，它可能仍在执行。

可以直接查询物化视图。但是，如果您愿意，可以使用Oracle的查询重写功能，以便在查询原始表时，将Materialized视图用作性能增强器，如索引。 有关详细信息，请参阅此处：http://www.sqlsnippets.com/en/topic-12918.html 您是选择在查询重写模式中使用它还是仅在视图中使用它取决于您是否希望用户知道这个额外的表，或者只是作为一个有用的朋友坐在后台。

Answer 2

在您的方案中似乎没有理由组合或链接这两种类型的事件。话虽如此，您可能有一些原因没有描述（例如，从许多系统收集日志并希望轻松地将它们放在一起）。

所以我的建议是用硬件和软件维度键制作一个事实表。其中一个总是为0或-1（=默认'n / a'记录）。

这允许您在没有UNION语句或其他复杂逻辑的情况下将它们聚合在一起，甚至可以支持在将来出现时链接到硬件和软件的事件。

Answer 3

您永远不会/很少将事实表连接在一起。您可以加入共享（一致）维度的聚合事实（即每小时的软件事件数与每小时的硬件事件数）。

对我而言，在查看维度建模时，您始终需要考虑将要提出的各种问题。

Answer 4

事件应该是一个事实。如果将它们分成两部分，您将很难在两者之间进行聚合。

如果有必要，您可以拥有单独的硬件和软件属性维度，但是您应该具有通用事件维度，即使它只是具有一些简单属性的垃圾维度，例如类型（硬件/软件），临界性（高，低）等。

在旁注中，我一般都看到带有箭头的图表来自于尺寸的事实。事实表键会查看尺寸，而不是反过来。