はじめに

データエンジニアリング部のTです。

分析用途のデータウェアハウス構築において、時間の経過とともに変化するマスターデータ（ディメンションデータ）の扱い方は悩ましくも避けて通ることはできない重要な設計要素です。
住所変更,役職変更,商品カテゴリの再編など、ビジネス上のデータの変化に対して、「上書きする」「過去の履歴を残す」「過去と現在の両方の視点で集計できるようにする」といった要件に応じたモデル化が必要となります。
これらを構造化した手法が、SCD（Slowly Changing Dimension：徐々に変化するディメンション）です。
実務ではType 1（上書き）やType 2（縦持ちでの履歴保持）がよく使われますが、Kimball Groupはデータ量の増加や高度な分析要件に対応するためにType 0〜7までの全8タイプを提唱しています。

本記事では、データ更新時の表構造の変化（縦・横の拡張やテーブル分離等）にも焦点を当てつつ各Typeの特徴を整理するとともに、選定のための判断軸を整理します。

まず結論として、SCDの各Typeの比較結果はこのようになっています。

SCD全8タイプ（Type 0〜7）の解説

それでは順にSCD各タイプの仕組みと、履歴が発生した場合の表構造の変化に着目しつつ解説していきます。 複数種のキーが登場するタイプもありますのでサンプルデータ表を確認しつつ理解を深めていただければと思います。

Type 0: Retain Original（オリジナル保持）

挿入時の初期値を保持し、ソース側でどのような変更が生じてもDWH側のデータを更新・追跡しない設計です。

サンプルデータを用いた例

Type0のデータ構造の挙動と特徴

• データ構造の挙動: 行の追加（縦）も列の追加（横）も上書きも一切行いません。
• 特徴: 実装が単純で、不変属性（生年月日、初回登録国など）の保持に適しています。

Type 1: Overwrite（上書き）

既存のレコードを最新データで直接UPDATE上書きします。

サンプルデータを用いた例

Type1のデータ構造の挙動と特徴

• データ構造の挙動: 行数（縦）も列数（横）も変わらず、1エンティティ1行のままデータを最新値で差し替えます。
• 特徴: ストレージ効率は良好ですが、過去の履歴は完全に消滅します（誤字修正等に適用）。

Type 2: Add a New Row（行追加＝縦の拡張）

値の変更ごとに新しいサロゲートキー（代理キー）を発行し、新しい行として追加（表が縦に伸長）します。

サンプルデータを用いた例

Type2のデータ構造の挙動と特徴

• データ構造の挙動: テーブル構造（列）は変えず、レコード数（縦）が変更回数分増えていきます。有効期間（valid_from, valid_to）や最新フラグで期間を管理します。
• 特徴: 任意の過去時点の状態を正確に再構築できますが、更新頻度が高いと行数が爆発します。

Type 3: Add a New Column（列追加＝横の拡張）

行を追加するのではなく、テーブルに「前回値（previous_xxx）」保持用のカラムを追加して新旧の値を横持ち（表が横に伸長）します。

サンプルデータを用いた例

Type3のデータ構造の挙動と特徴

• データ構造の挙動: 行数（縦）を維持したまま、列（横）を追加して過去世代のデータを保持します。
• 特徴: 1行の中で変更前後の比較計算が容易ですが、保持できる履歴はあらかじめ用意した限定世代（通常は直近1世代）に限られます。

Type 4: Add Mini-Dimension（ミニディメンション分離）

年収階層や年齢層など、変動頻度が高い属性群を親テーブルから切り出し、別のミニディメンションテーブルとして分離管理します。

サンプルデータを用いた例

Type4のデータ構造の挙動と特徴

• データ構造の挙動: 親ディメンションの行数爆発（縦への肥大化）を防ぐため、高頻度更新属性を別表に退避させます。ファクトテーブル側に「親キー」と「ミニディメンションキー(プロファイルキー)」の2つを保持します。
• 特徴: 親テーブルは1顧客1行のまま肥大化を防げますが、親テーブル単体では「現在の最新ステータス」を参照できず、ファクトテーブル経由での結合が必要となります。

Type 5: Type 4 + Type 1（別表分離 ＋ 親テーブルに最新キーを横追加・上書き）

Type 4のミニディメンション分離構造に加え、親ディメンション側にも「現在の最新ミニDキー」のカラムを1つ保持し、変更時に上書き（Type 1）で最新キーに差し替えます。

サンプルデータを用いた例

Type5のデータ構造の挙動と特徴

• データ構造の挙動: 高頻度属性は別表管理で親表の行数爆発（縦）を防ぎつつ、親表の最新キー列を上書きすることで、ファクト非経由で親表単体から最新ステータスを取得可能にします。
• 特徴: 履歴追跡と親テーブル単体での最新プロファイル検索を両立できますが、親テーブルへのキー上書き処理が発生します。

Type 6: Combined Approach（行追加［縦］ ＋ 列追加［横］ ＋ 過去行の現在値上書き）

Type 1・Type 2・Type 3を融合させた構造です。 変更時に新しい行を追加して縦に拡張（Type 2）し、直前値や最新値を入れるカラムを横に持たせ（Type 3）、新しい変更が入るたびに過去の全履歴行の「現在値カラム」を最新値で上書き（Type 1）します。

サンプルデータを用いた例

Type6のデータ構造の挙動と特徴

• データ構造の挙動: 変更ごとに「表が縦にも横にも拡張し、全履歴行の現在値列が書き換わる」構造です。
• 特徴: ディメンション単体で「当時の属性」と「現在の属性」のカラムを両方持つため、ファクト側の構造を変えずに双方の軸での集計が可能ですが、過去全履歴行へのUPDATEにより書き込み負荷が非常に高くなります。

Type 7: Dual Type 1 and Type 2（ディメンション縦拡張 ＋ ファクト側に2キー列保持）

ディメンション側は純粋な行追加（Type 2＝縦の拡張のみ）で管理して完全な不変を保ち、ファクトテーブル側に「履歴用サロゲートキー」と「最新参照用キー」の2つの結合キー列を持たせます。

サンプルデータを用いた例

Type7のデータ構造の挙動と特徴

• データ構造の挙動: ディメンション側は不変（UPDATEなし・縦追加のみ）とし、ファクト側に2つのキー列を配置して「当時の属性」と「現在の属性」の結合を振り分ます。
• 特徴: 大量履歴行へのUPDATE負荷を排除できますが、ファクトテーブルの構造変更と2キー管理が必要となります。

実務における選定手順と判断軸

実務でSCDタイプを選択する際は、「履歴管理の範囲」に加えて「更新頻度によるデータの縦・横膨張」「DWHへのUPDATE書き込み負荷」「クエリの容易さ」のトレードオフを厳密に評価する必要があります。

1. SCD type選定フローチャート

まとめ

SCDの設計では、単に履歴を残すかどうかだけでなく、データが縦（行）や横（列）にどう拡張されるか、別表に分離するか、UPDATE処理の負荷をどこで受けるかという物理的な挙動を考慮することが重要と言えそうです。

ビジネス要件、DWHの書き込み特性、分析クエリの利便性を総合的に評価し最適なSCDタイプを選択できるように頭に入れておきたい内容でした。
高度なデータモデルの実装のハードルをAIが肩代わりしてくれる世界になった場合、Type6や7が選ばれる機会は果たして増えていくのでしょうか..

---

参考文献

• Dimension Table Core Concepts -- Kimball Group

• Design Tip #152 Slowly Changing Dimension Types 0, 4, 5, 6 and 7