【发布时间】：2017-03-18 07:59:02
【问题描述】：
假设我有一个事实表和员工“层”表。
所以事实表看起来有点像
employee_id call date
Mark 1 1-1-2017
Mark 2 1-2-2017
John 3 1-2-2017
那么需要有一个“层级”的数据结构——一个缓慢变化的维度表。我想保持简单——我可以将这个表的结构更改为任何结构，但现在我已经创建了它。
employee_id tier1_start ... tier2_start ... tier3_start
Mark 5-1-2016
John 6-1-2016 8-1-2016
Lucy 6-1-2016 10-1-2016
两个重要说明。此表的运行假设是升级只会发生一次 - 也就是不会发生降级和再升级。此外，也有可能从 1 层跳到 3 层。
我试图提出最好的查询，以便为事实表提供“层”维度（非规范化）。
例如，我想查看 2 月的第 1 层指标，或 2 月的第 2 层指标。显然，历史变化的层级维度必须联系起来。
目前我能想到的最笨拙的方法......就是使用 employee_id 将事实表加入到 tier 表中。
然后，做一个更笨拙的 case 语句：
case
when isnull(tier3_start,'0') < date then 'T3'
when isnull(tier2_start, '0') < date then 'T2'
when isnull(tier1_start, '0') < date then 'T1'
else 'other'
end as tier_level
是的，正如您所见，这非常笨拙。 我在想也许我需要稍微改变一下它的结构。
【问题讨论】：
-
会有超过 3 层吗？您已经描述了类型 3 SCD，您可能更适合使用类型 2 SCD（添加一行，而不是一列）en.wikipedia.org/wiki/Slowly_changing_dimension。这允许捕获任何变化的属性
-
不回答实际简化、连贯查询以实际连接事实数据和维度数据的问题。例如，10 月 3 日或任何时候都打了电话。这属于哪一层？并且类型 3 无效，它实际上破坏了历史生效日期。这是很多 SCD 讨论的问题。每个人都在谈论形成维度表 - 没有人真正谈论真正提升的查询！我真正拥有的是 2 型 SCD 表。写入效率最高。我需要将其转换为类型 6。对于事实表连接最有效。
-
您的维度不会为每个状态更改添加一行，因此它不是类型 2。Dw 通过使 ETL 复杂化来简化查询。不过，您似乎已经知道这一切。我不太确定这里的问题是什么。
-
一个一个实际简化的、连贯的查询就是加入你的代理键，你的答案就会从另一边出来。 SCD2 唯一没有涵盖的是员工更改状态但在此期间没有任何活动可以加入维度并使其显示。
标签： sql-server scd