如何避免星型模式中事实表之间的连接？
Pie*_*rre 5 database-design data-warehouse star-schema
我正在尝试使用星型模式为我的数据仓库建模，但我有一个问题来避免事实表之间的连接。
为了简单了解我的问题，我想收集在我的操作系统上发生的所有事件。因此，我可以创建一个event具有某些维度的事实表，例如datetime或user。问题是我想收集不同类型的事件：硬件事件和软件事件。
问题是这些事件的维度不同。例如，对于硬件事件，我可以有physical_component或related_driver维度，对于软件事件，software_name或online_application维度（这只是一些示例，要记住的想法是事实event可以专门用于具有特定维度的某些特定事件）。
在关系模型中，我会有 3 个这样组织的表：
问题是：如何处理星型模式中事实表之间的连接？
我想象了 4 个想法，但我不确定其中一个是否适合这种情况。
第一个是保留关系数据库中使用的模型并添加如下维度表：
在这种情况下，问题是我们仍然有事实表之间的连接，并且需要
JOIN在我们所有的查询中使用SQL 语句。
第二个是仅创建 2 个将复制共享维度（日期时间和用户）的事实表，并创建一个汇总所有事件的物化视图事件：
这里的问题是：如果我想对物化视图进行查询会发生什么？根据我在 Oracle 文档中读到的内容，我们不必直接在物化视图上进行查询，但我们必须让查询重写过程发挥作用。
第三种是只创建一个事实表，其中包含事件（硬件或软件）的所有可能信息：
这一次，问题是我的事实表将包含很多
NULL值。
而最后一个是创建3个事实表（没有物化视图这段时间）是这样的：
这一次，问题是所有事件都存在于事实表
event和它自己的表中。因为我们将存储大量数据，所以我不确定这种重复是否是一个好主意。
那么最好的解决方案是什么？或者它是否存在第五个解决方案？
根据您的描述以及您随后对其他答案的评论，我认为选项 2 或选项 4 是从维度建模角度对事物进行建模的正确方法。每个事实都应该是业务流程的衡量标准，并且软件和硬件事件的维度似乎有很大不同，因此它们需要单独存储。
然后，还有一种情况是将单独的事件表存储为视图、物化视图或存储常见事物的普通表。
一旦您确定这是“逻辑地”建模事物的正确方法，您就需要平衡性能、可维护性、可用性和存储。对于维度建模，查询的可用性和性能是最重要的（否则你可能根本不使用维度模型），ETL 中的额外工作以及所需的额外空间都是值得付出的代价。
非物化视图会以牺牲性能为代价来节省空间，但您可能可以为其提供一个或两个足够出色的索引来缓解这种情况。物化视图将以存储为代价提供性能。
我很想创建两个带有索引和非物化视图的事实表，并在采取进一步的性能增强步骤之前看看其性能如何。1000 万个事实行还不错，它仍然可以执行。
可以直接查询物化视图。但如果您愿意，您可以使用 Oracle 的查询重写功能，以便在查询原始表时将物化视图用作性能增强器，例如索引。有关详细信息，请参阅此处：http://www.sqlsnippets.com/en/topic-12918.html 您选择在查询重写模式中使用它还是仅作为视图本身取决于您是否希望用户知道关于这张额外的桌子，或者让它作为一个乐于助人的朋友坐在后台。