有效的仓储策略？六型？

Question

作为一名数据库用户，我在解释我们 table 工作中的数据时遇到了问题。当我询问数据团队时，解决方案架构师告诉我这是故意这样做的，因为它是 "Type 6" table.

根据我有限的谷歌搜索，我认为 Type 6 应该是这样的：

+--------------+------------------+------------------+------------+------------+---------------------+
| Customer_Key | Customer_Attrib1 | Customer_Attrib2 | Start_Date | End_Date   | Record Updated Date |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 1                | A                | 1/1/2001   | 6/8/2004   | 6/9/2004            |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 1                | A                | 6/9/2004   | 4/11/2016  | 4/12/2016           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 1                | A                | 4/12/2016  | 4/3/2017   | 4/4/2017            |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | B                | 4/4/2017   | 5/18/2017  | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | B                | 5/19/2017  | 12/31/9999 | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+

问题中的 activity 是 Customer_Attrib1，它是如何在 2017 年 5 月 18 日从 1 变为 2 的。

我喜欢这种风格，因为我可以通过使用开始日期和结束日期来计算customer_attrib1在任何时间点是什么:

select customer_attrib1 
from table 
where customer_key=123 
and '2017-03-01' between start_date and end_date;

然而...

table本身实际上是在拖欠更新，看起来像这样：

+--------------+------------------+------------------+------------+------------+---------------------+
| Customer_Key | Customer_Attrib1 | Customer_Attrib2 | Start_Date | End_Date   | Record Updated Date |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | A                | 1/1/2001   | 6/8/2004   | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | A                | 6/9/2004   | 4/11/2016  | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | A                | 4/12/2016  | 4/3/2017   | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | B                | 4/4/2017   | 5/18/2017  | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+
| 123          | 2                | B                | 5/19/2017  | 12/31/9999 | 5/19/2017           |
+--------------+------------------+------------------+------------+------------+---------------------+

如果我想去查找 2016 年 3 月的 customer_attrib1 是什么，你能看到我遇到了多少麻烦吗？

注意：是一个previous_customer_attrib1列，但它也被大量更新为值1。我想保留table小到足以说明要点，这就是我没有在上面添加它的原因。

大问题：这是有效的仓储策略吗？这真的是Type 6吗？或者是我的解决方案架构师错了。

跟进问题：如果 customer_attrib1 是另一个 table 的外键，答案会有所不同吗？

Answer 1

你的第一个例子看起来像一个普通的 ol Type 2 SCD。第二个示例看起来像是属性 1 上的类型 1（覆盖）和属性 2 上的类型 2 SCD。

既不是呈现的类型 6，您可以在其中查看更改历史记录（按照您的第一个示例，以类型 2 的方式）以及当前值，通常通过为当前值保留一组单独的列，或通过链接到当前记录。您提到了前面的 attrib 1 列，这对于它成为 Type 6 至关重要。但是您不希望它也被批量更新，否则您只会得到一个以前的值，而您看不到任何变化在那之前。

不同的人对 Type 6 有不同的含义。在类型 6 中，您需要的只是值本身（当时适用于行）和当前值（发生更改时批量更新），以及（当然）类型 2 的创建方法每次更改的新行。

回答你的问题，是的，我可以看到你对给你的设计有多少麻烦。当且仅当它满足业务需求时，它才是有效的策略。这些技术仅用于帮助满足业务需求。

如果属性是外键，那么它会变得有点棘手，我们需要更多关于外键 table 如何跟踪历史记录的信息，以便能够回答这是否改变了什么。

有效的仓储策略？六型？

Valid Warehousing Strategy? Type6?

database

database-design

etl

data-warehouse

database-schema