有効な倉庫管理戦略？タイプ6？

Question

データベースユーザーとして、仕事中のテーブルのデータを解釈する際に問題があります。私がデータチームに質問したとき、ソリューションアーキテクトは、「タイプ6」テーブルであるため、この方法で目的を達成したと教えてくれました。私の限られたグーグルから

、私はタイプ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   | 
+--------------+------------------+------------------+------------+------------+---------------------+ 

問題の活動は、それが2017年5月18日に1から2に変更する方法Customer_Attrib1、です。

私は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   | 
+--------------+------------------+------------------+------------+------------+---------------------+ 

私がどれだけ問題を抱えているか見てみましょうe customer_attrib1は2016年の3月中でしたか？

注：そこはがprevious_customer_attrib1列があるが、それはまた、質量、私は私が上にそれを追加しなかった理由である全体のポイントを取得するのに十分小さなテーブルを、維持したい1の値に更新されます。

大きな質問：有効な倉庫管理戦略ですか？これは実際にタイプ6とは何ですか？あるいは、私のソリューションアーキテクトが間違っています。

続きを読む：customer_attrib1が別のテーブルの外部キーであった場合の回答は異なりますか？

Answer 1

最初の例は、普通のタイプ2のSCDのようです。 2番目の例は、属性1にタイプ1（上書き）、属性2にタイプ2 SCDのように見えます。

表示されているタイプ6もありません。最初の例のようにタイプ2の方法で変更するだけでなく、現在の値の別の列を保持するか、現在のレコードにリンクするなどして、現在の値も変更します。以前のattrib 1カラムについて言及しましたが、それはタイプ6であるために重要です。しかし、それも一括更新することは期待できません。さもなければ、以前の1つの値を得て、変更を見ることはありませんその前に。

異なる人々は、異なるものを意味するタイプ6を指します。タイプ6で必要とされるのは、値そのもの（その時の行に適用されます）と現行の値（変更があったときに一括更新されます）だけでなく、タイプ2の作成方法各変更の新しい行

あなたの質問に答えるために、私はあなたに与えられたデザインにどのくらいの問題があるかを見ることができます。ビジネス要件を満たしている場合に限り、有効な戦略です。これらのテクニックは、ビジネスニーズを満たすのに役立ちます。

アトリビュートが外部キーである場合、それはもう少し難しくなります。外部キーテーブルが履歴を追跡していたため、その変更が何か変わるかどうかを知る必要があります。