星型图式：事实与维度之间的三重关系答案

【问题标题】：Star Schema: Triple Relations between Fact and Dimension星型图式：事实与维度之间的三重关系
【发布时间】：2018-04-10 21:53:16
【问题描述】：

我正在从 ERD 建模星型模式。数据库是一家租赁公司。我的事实表现在包含一个租赁预订。客户可以预订汽车、取车和还车。应记录发生这种情况的日期。

所以，我的星型模式现在有一个包含日/月/年的时间维度以及与事实表的三个关系。我想知道这是否是正确的做法，或者是否还有其他选择要考虑，因为我从未见过一个维度具有多个关系的星计划。

就是这样：

 Booking(Fact)
 bookingId
 bookingDate(FK)
 collectionDate(FK)
 returnDate(FK)

 Time(Dim)
 timeId
 day
 month
 year

【问题讨论】：

您的架构是正确的。事实表可以与维度表有多个关系。这有时被称为“共享层次结构”。
哦好的很高兴知道！如果您发布答案，我可以接受。
@coolMan 您如何将时间维度加入预订表？

标签： database database-design schema data-warehouse erd

【解决方案1】：

是的，您可以多次将 Fact 加入同一维度。我已经看到这尤其与时间维度一起使用。我不确定您使用什么键将 Fact 加入到 Time dim 中，但在选择数据时，您最终可能会遇到这样的查询：

select bFact.bookingID,t1.day "Booking Date",t2.day "Collection Date",t3.day "Return Date"
from Booking bFact
join Time t1 on t1.date = bFact.bookingDate
join Time t2 on t2.date = bFact.collectionDate
join Time t3 on t3.date = bFact.returnDate

【讨论】：

【解决方案2】：

这是一个试图帮助你更好理解的图表。

如果您的 bookingdate、collectiondate、returndate 都是时间维度的一部分，那么您不需要在事实表中使用它们。它们需要在维度表中。

我创建了一个图表，可以正确地展示我认为您的意思。例如，如果回报可以有不同的衡量标准，那么它需要是一个单独的维度。每个维度总是需要一个主键，并且它们总是对应于事实表中的一个外键。

有什么问题可以告诉我

【讨论】：

如果你有预订日期、取货日期和返回日期，那么这三个的id应该都是事实：这就是你区分这三个的方式。它们都会从时间（日期）维度链接到时间 ID。
@Rich 我不同意。拥有 3 个不同的日期相关维度是没有意义的，应该只有 1 个与日期相关的维度，然后所有其他维度都可以通过事实时间链接到。因此，您将有时间（包括日期）、集合（将包含集合数据，并且可以链接到时间维度以检索日期信息）以及相同的返回。持有多个维度的日期信息只会导致数据完整性问题。
@Rich 例如，如果您报告了从时间维度预订、返回或收集的所有内容，那么在您的场景中，您将丢失收集或返回维度中的所有数据，纯粹因为它们分别保存日期信息。
我同意，你应该只有一个日期维度。它描述了日期。在您的事实表中，您将有一个 BookingDateID（链接到您的一个日期维度），在同一个事实表中，您将有一个 CollectionDateID（链接到您的一个日期维度）等等。这种情况需要一个事实表来引用（而不是存储）多个日期。它是 Kimball 文学中“角色扮演维度”的常见概念。就像您在同一事实中有一个“订单输入员工”和一个“订单调度员工”一样，都指向一个维度。
@Rich 已经只有 1 个事实表。永远不应该超过一个。如果您想在集合和返回字段中存储不同的数据会发生什么？我认为他们在那个阶段需要不同的维度