緩やかに変化するディメンションのタイプを選択する
一般的な SCD タイプは、スター スキーマの設計理論で参照されます。 最も一般的なのはタイプ 1 とタイプ 2 です。 実際には、ディメンション テーブルで、タイプ 3 とタイプ 6 を含めた、履歴追跡メソッドの組み合わせがサポートされている場合があります。 これらの SCD タイプの違いについて説明しましょう。
種類 1 の SCD
タイプ 1 の SCD では常に最新の値が反映され、ソース データの変更が検出されると、ディメンション テーブルのデータが上書きされます。 この設計手法は、顧客の電子メール アドレスや電話番号などの補足値を格納する列では一般的なものです。 顧客の電子メール アドレスまたは電話番号が変更されると、ディメンション テーブルで顧客の行が新しい値で更新されます。 顧客が常にこの連絡先情報を持っているかのように見えます。 ファクト テーブルのレコードが、更新された顧客レコードに自動的にリンクされるように、CustomerID などのキー フィールドは同じにします。
種類 2 の SCD
タイプ 2 の SCD は、ディメンション メンバーのバージョン管理をサポートしています。 多くの場合、ソース システムにはバージョンが格納されていないため、ディメンション テーブル内の変更の検出と管理は、データ ウェアハウスの読み込みプロセスで行われます。 この場合、ディメンション テーブルでは、ディメンション メンバーの "バージョン" への一意の参照を提供するために、代理キーを使用する必要があります。 また、バージョンの有効期間の日付範囲 (StartDate や EndDate など) を定義する列と、場合によってはフラグ列 (IsCurrent など) が含まれます。これらは、現在のディメンション メンバーで簡単にフィルター処理するためのものです。
たとえば、Adventure Works では販売員を販売地域に割り当てます。 販売員が地域を再配置した場合、新しいバージョンの販売員を作成し、履歴ファクトを元の地域に関連付けたままにする必要があります。 販売員ごとの売上の正確な履歴分析をサポートするには、ディメンション テーブルに販売員のバージョンと、それらに関連付けられている地域 (複数可) を格納する必要があります。 テーブルには、有効期間を定義するための開始日と終了日の値も含まれている必要があります。 現在のバージョンでは、空の終了日 (または 12/31/9999) を定義できます。これは、その行が現在のバージョンであることを示します。 ビジネス キー (この場合は、従業員 ID) が一意ではないため、テーブルで代理キーも定義する必要があります。
ソース データにバージョンが格納されていない場合は、中間システム (データ ウェアハウスなど) を使用して変更を検出し、格納する必要があることを理解しておくことが重要です。 テーブルの読み込みプロセスでは、既存のデータを保持し、変更を検出する必要があります。 変更が検出された場合、テーブルの読み込みプロセスで現在のバージョンを期限切れにする必要があります。 EndDate 値を更新し、前の EndDate 値から始まる StartDate 値を使用して新しいバージョンを挿入することで、これらの変更が記録されます。 また、関連するファクトでは、時間ベースの参照を使用して、ファクトの日付に関連するディメンション キー値を取得する必要があります。
タイプ 3 の SCD
タイプ 3 の SCD を使用すると、ディメンション メンバーの 2 つのバージョンを別々の列として格納できます。 メンバーの現在の値に加え、メンバーの元または以前のいずれかの値の列をテーブルに含めます。 このため、タイプ 3 では、タイプ 2 の SCD のように変更のたびに追跡するための追加行を格納するのではなく、履歴の 1 つのキー インスタンスを追跡するための追加列を使用します。
このタイプの追跡は、ディメンション テーブル内の 1 つまたは 2 つの列に対して使用できます。 同じテーブルの多くのメンバーに使用するのは一般的ではありません。 多くの場合、タイプ 1 またはタイプ 2 のメンバーと組み合わせて使用されます。
タイプ 6 の SCD
タイプ 6 の SCD は、タイプ 1、2、3 を組み合わせたものです。 タイプ 2 のメンバーに変更が発生したとき、適切な StartDate と EndDate を含む新しい行を作成します。 タイプ 6 の設計では、現在の値がそのエンティティのすべてのバージョンに格納されるため、現在の値または履歴値について簡単にレポートできます。
販売地域の例を使用して、Region 列を CurrentRegion と HistoricalRegion に分割します。 CurrentRegion には常に最新の値が表示され、HistoricalRegion には、StartDate から EndDate までの間に有効だった地域が表示されます。 そのため、同じ販売員にとっては、すべてのレコードの CurrentRegion に最新の地域が設定され、HistoricalRegion はタイプ 2 の SCD の例の地域フィールドとまったく同じように機能します。
