我有一个维度表,该表跟踪对类似于员工对象的对象的更改。但是,员工有一个“状态”(挂起,活动,不活动等),每个状态的开始和结束日期在源数据库的另一个表中进行跟踪。
状态可以更新多少次没有限制。它可以在状态之间来回移动。
如果要创建报表(例如在特定日期具有给定状态的员工),该如何建模。如果我将状态更改作为事实,那么我只会从员工那里获得有关状态更改日期的其他信息。
我需要创建一个事实表,该表每天更新当前的员工记录和状态吗?
或者我可以创建一个事实表,其有效日期自维度表中的某个日期起?
还是我要离开这个道路,应该以不同的方式对待它?
答案 0 :(得分:1)
您必须决定的第一件事是对员工进行民意调查还是获得员工状态变更的事件供稿。 / p>
第一个选项可以简化设计,您可以定期(例如每天一次)加载所有员工的员工状态并建立维度。
请注意,这是一个近似词,因为员工每天可以多次更改状态,但是您每天只考虑一种状态。
表如下
employee_id,
validfrom_date,
validto_date,
status
validfrom_date
是提取日期,计算validto_date
。您将丢弃状态不变的所有员工。
第二个选项涉及更多,但会产生更准确的结果。
您可以从源系统中加载具有准确时间戳的所有员工的所有状态更改,因此每天可以处理更多更改。
可能的界面是:
employee_id, change_timestamp, old_status, new_status
请注意,old_status
是多余的,该值可用于检查接口是否一致。
最终表与上一个类似,只使用timestamp
而不是date
。
employee_id,
validfrom_timestamp,
validto_timestamp,
status
同样,validfrom_timestamp
是来自接口事件的时间戳记,validto_timestamp
被计算。
在此设置中,建议定期进行尺寸一致性的检查。
问题-如果某些变更事件丢失了,您将永远无法恢复。随着时间的流逝,您可能会积累此类错误。因此,每月说一次,您检查维度的实际状态是否与源系统中的状态匹配。如果没有,您可以解决差异。
最后不要推测这是事实表还是维度表。在Kimball的模型中,它们之间没有严格的区分。如果您报告员工状态,则角色为事实表。如果使用它来连接其他事实表,则角色为维度。