有效的仓储策略？ 6型？答案

【问题标题】：Valid Warehousing Strategy? Type6?有效的仓储策略？ 6型？
【发布时间】：2017-06-16 20:31:15
【问题描述】：

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

根据我有限的谷歌搜索，我认为 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           |
+--------------+------------------+------------------+------------+------------+---------------------+

有问题的活动是 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;

不过……

表格本身实际上是延迟更新的，如下所示：

+--------------+------------------+------------------+------------+------------+---------------------+
| 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 的值。我想保持表格足够小以理解这一点，这就是为什么我没有不要在上面添加。

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

后续问题：如果 customer_attrib1 是另一个表的外键，答案是否会有所不同？

【问题讨论】：

当您说“customer_attrib1 在 2016 年 3 月期间是什么”时，根据数据库的哪个状态/日期？这与使用第二张桌子有什么不同？每个记录更新日期都有一个版本。您没有解释“像这样”是什么意思，但记录更新日期是什么意思，如果进行了更新或更正，不，您不能“在任何时候通过使用来确定 customer_attrib1 是什么没有它的开始和结束日期”。 PS Type 6 怎么样？
类型 6 表中的某些字段始终显示当前值（这些是类型 1 字段 - 被更改覆盖）。示例：数据仓库仅包含当前联系电话号码 - 以防止呼叫旧/错误号码。建议您咨询您的数据团队，为什么他们不保留 Customer_Attrib1 中的旧值。他们可能试图阻止某些行为/结果。
我同意@Rich。一旦您通过了 type-5，这些名称就不会在整个行业中一致使用。您的数据团队应该能够提供类型 6 的定义。

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

【解决方案1】：

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

所展示的类型 6 都不是，您可以在其中查看更改的历史记录（根据您的第一个示例，以类型 2 的方式）以及当前值，通常通过持有当前值的单独列集，或通过链接到当前记录。您提到了之前的属性 1 列，这对于它是类型 6 至关重要。但是您不会期望它也会被批量更新，否则您只会获得一个先前的值，而您看不到任何更改在此之前。

不同的人提到类型 6 意味着不同的事物。您在类型 6 中需要的只是值本身（适用于当时的行）和当前值（在发生更改时批量更新），以及（当然）类型 2 的创建方法每次更改都有新行。

要回答您的问题，是的，我可以看到您对提供给您的设计有多大的麻烦。当且仅当它满足业务需求时，它才是有效的策略。这些技术只是为了帮助满足业务需求。

如果属性是外键，那么它会变得有点棘手，我们需要更多关于该外键表如何跟踪历史的信息，以便能够回答这是否会发生任何变化。

【讨论】：