类型 2 与另一个维度相关的维度变化答案

【问题标题】：Type 2 Dimension changes relating to another dimension类型 2 与另一个维度相关的维度变化
【发布时间】：2017-07-12 15:36:04
【问题描述】：

我正在尝试为具有各种类型 2 维度的招聘数据仓库建模，但我不确定我是否正确地建模了这个特定场景。以下是我目前正在做的事情：

我有 2 个维度：Dim_Person 和 Dim_Client

这两个维度通过无事实事实表 Fact_PersonEmployer 连接，其中包含两个维度的 FK，以及有效的起始日期和截止日期。

如果一个人搬到另一家公司，我会关闭将他们与旧雇主联系起来的事实行上的有效日期，并在新公司的事实表中插入一条新记录。

这看起来很简单，但是由于该人现在已经转到新雇主，我认为这需要在人员维度上进行 2 类更改，因为该人现在与用户（招聘人员/招聘经理）根本不同。

从我的角度来看，客户似乎是人员维度的类型 2 属性，因此我一直在考虑以这种方式对其进行建模。我只是不确定在不使用无事实事实表的情况下将维度连接在一起是否可以接受（我试图尽可能地坚持 Kimball 的方法）。

我应该：

a) 将他们工作的公司的 ID 作为属性保留在人员维度中，以便它可以生成类型 2 更改

或

b) 继续使用事实表将两个维度关联起来？

希望这是有道理的......

提前致谢！

【问题讨论】：

【解决方案1】：

几个点：

如果您想保留此人的历史和记录，则保留 ID 是合适的。

【讨论】：

【解决方案2】：

如果您的事实显示 DimPerson 和 DimClient 之间的雇佣关系，您不应该在 DimPerson 中拥有任何客户信息。 DimPerson 记录不需要更改，因为关系包含在 Fact 中（并且应该包含事件的日期/时间）。

但是，如果您将雇主视为雇员的属性，则不需要 Fact 表，因为关系包含在 Dim.xml 中。在这种情况下，您应该将您的客户信息非规范化为 DimPerson。日期时间将用作维度记录的生效日期和之前活动的维度记录的到期日期。

另外，最佳实践要求您的事实表描述事件。我发现 Fact_PersonEmployer 这个名字令人困惑。它捕获的事件是什么？是招聘会吗？

【讨论】：