ジャンクディメンション
スタースキーマを設計する際、ディメンションテーブルの属性をどのようにグループ化するかについては、「ディメンションのグループ化」で説明した。
通常、関連性の高い属性は 1 つのテーブルにまとめることが望ましいが、時として、互いに直接的な関連性のない属性を 1 つのテーブルに含めることが便利な場合がある。このように、無関係な属性を 1 つのディメンションテーブルに集約したものを「ジャンクディメンション」と呼ぶ。経験則では、トランザクションテーブルに含まれる雑多な属性がこれに該当する。
ジャンクディメンションを適切に活用することで、以下のようなメリットが得られる。
- データモデルのシンプル化: 無関係な属性を 1 つのテーブルにまとめることで、テーブルの数が減り、データモデルを理解しやすくなる。
- クエリのパフォーマンス向上: 関連する属性が 1 つのテーブルに存在することで、結合の数が減り、クエリの実 行速度が向上する。
- データの管理とメンテナンスの効率化: 属性が 1 つのテーブルに集約されていると、データの更新や保守作業がシンプルになり、データの整合性を保ちやすくなる。
ただし、ジャンクディメンションの設計には十分な注意が必要であり、適切な属性の選択と粒度の設定が求める。
本記事では、以下のような注文のソーステーブルを例にしてジャンクディメンションの設計方法ついて解説する。設計時の留意点やサンプルなどを通じて、ジャンクディメンションの理解を深めてほしい。
設計方法
ポイント
ジャンクディメンションは、互いに直接的な関連性のない属性を 1 つのディメンションテーブルに集約したものである。これは、ジャンクディメンションにナチュラルキーが存在しないことを意味しており、属性の組み合わせ（デカルト積）を全て含むようにテーブルを作成する必要がある。
今回の例では、以下の 3 つの属性がジャンクディメンション（dim_order_info）に該当する。
| 属性 | 要素 |
|---|---|
| order_kbn | ネット注文、電話注文 |
| order_status | 未発送、発送済み、キャンセル |
| payment_method | クレジット、振込、代引き |
これらの属性の組み合わせ（デカル ト積）は、2 × 3 × 3 = 18 通りであり、このジャンクディメンションには 18 行のデータが格納される。ジャンクディメンションにはナチュラルキーが存在しないので、各行の値を使用してウェアハウスキーを作成する。
| order_info_key | order_kbn | order_status | payment_method |
|---|---|---|---|
| hash(ネット注文||未発送||クレジット) | ネット注文 | 未発送 | クレジット |
| hash(ネット注文||未発送||振込) | ネット注文 | 未発送 | 振込 |
| hash(ネット注文||未発送||代引き) | ネット注文 | 未発送 | 代引き |
| ... | ... | ... | ... |
| hash(電話注文||キャンセル||代引き) | 電話注文 | キャンセル | 代引き |
完成形
ジャンクディメンションのウェアハウスキーとファクトテーブルの雑多な属性の組み合わせのハッシュ値を関連付ける。
余談だが、ジャンクディメンションを使用しない場合のディメンションデザインは、以下の通りである。関連性の無い雑多な属性が増えるたびにテーブルを作成しなければいけないので、ジャンクディメンションの使用をオススメする。
注意点
ジャンクディメンションは、定型的な値の組み合わせを管理するためのディ メンションテーブルである。「備考」や「メモ」のような自由記述形式のデータは、通常ジャンクディメンションには含めない。理由は以下の通りである。
- データ量の増大: 自由記述形式の列は、値の種類が多岐にわたるため、テーブルサイズが肥大化してしまう可能性がある。
- パフォーマンスへの影響: テーブルサイズが大きくなると、クエリのパフォーマンスが低下する可能性がある。
- 分析での活用が難しい: 自由記述形式の列は、分析での集計や比較が難しいため、あまり役に立たない。
- メンテナンスの難しさ: 自由記述形式の列は、データの整合性を保つためのメンテナンスが難しくなる。
以上のことから、自由記述形式の列は、以下のような方法で管理するのが良い。
- 自由記述形式から行動属性を作成し、ジャンクディメンションに格納する
- パフォーマンスへの影響が少ない場合は、degenerate dimension としてファクトテーブルに直接含める
まとめ
ジャンクディメンションは、属性の組み合わせ（デカルト積）でテーブルを作成するので、属性の粒度を注意しなければならない。
属性の粒度が細かいほど、生成される行数が多くなり、テーブルサイズが大きくなる。これは、パフォーマンスに影響を与える可能性があるため、属性の粒度を設定する際は注意が必要である。
一方で、属性の粒度を粗くすると、ジャンクディメンションの行数を 減らすことはできるが、分析の柔軟性が失われる可能性がある。そのため、分析要件とのバランスを考慮しながら、適切な粒度を設定することが重要である。