モデルのグレーンを決定したら、そのグレーンを満たすディメンションを特定します。
スノーフレーク用の列、階層、および事例を作成します。
ディメンション表を特定するときには、以下のメタデータが収集されます。
- ディメンション名
- ビジネス定義
- 階層
- ディメンションの変化の処理
- ロードの頻度と統計
- 使用量の統計
- アーカイブの規則と統計
- パージの規則と統計
- データの品質と正確さ
- 主キーおよび外部キー、およびキーの生成方法
- データ・ソース情報
- ファクト
ディメンションを特定する
モデルのグレーンを満たすディメンションを特定します。
ディメンション表には、ファクト表内のファクト・レコードを説明する列が含まれます。
これらの列の一部には記述情報が含まれ、
その他の列には、役に立つ情報提供のために、ファクト表内のデータがどのように要約されているるかが指定されています。
ディメンション表には、データの要約に役立つ階層が含まれます。
ディメンション表は、より小さな非正規化の参照表であり、照会の定義時に参照される説明の列が含まれています。
ディメンション表の詳細は、『ディメンション表とエンティティー』を参照してください。
ディメンションを特定するには、次のステップを実施します。
- グレーン定義を使用して、使用できるディメンションを見つけます。
- このグレーンに関連付けられているすべてのディメンションをリストアップします。
そのディメンションに組み込む詳細さのレベルを定義します。
- ディメンションの主キーに対する代理キーを作成します。
代理キーの詳細は、『代理キー』を参照してください。
共有ディメンションを特定する
ディメンションを再設計する代わりに、使用可能なすべての共有ディメンションを特定します。
使用されているディメンションが、エンタープライズ・データウェアハウスまたはディメンション・モデルのどちらに存在するかを特定します。
共有ディメンションの詳細は、『
共有ディメンション』を参照してください。
共有ディメンションを特定するには、次のステップを実施します。
- ディメンションが存在するかどうかを特定します。
ディメンションが存在する場合、そのディメンションを使用する必要があります。
ディメンションが存在する場合、そのディメンションのディメンション属性は特定しません。
1 次ディメンションの属性のサブセットしか共有ディメンションに含まれない場合でも、既存のディメンションとの間でディメンションを共有します。
- ディメンションが存在しない場合、企業全体で使用するディメンションを作成します。
ディメンション・モデルが、存在しないディメンションを必要とする場合、新規のディメンションを設計します。
そのディメンションを設計する場合、対象分野の専門家に問い合わせて、そのディメンションをどのように使用する予定であるかを確かめます。
ディメンションのディメンション列および階層を特定する
ディメンションを特定したら、そのディメンションに列を追加します。
記述列を使用して、照会の制限基準を定義します。
ディメンションの設計時には、次のような点に配慮します。
- ソース・システム・キーを保持する
- ディメンション表内の別のエントリーを使用して、ソース・システムで使用されているエンティティーの本来のソース・システム・キーを保持します。
- 代理キーを使用する
- ディメンションの主キーに対する代理キーを使用します。
代理キーは分析しません。
代理キーの詳細は、『代理キー』を参照してください。
- モデル内で固有の記述列を作成する
ディメンションの列は潜在的な関心領域を反映しており、データを集約したり制約および報告書の切れ目を作成したりするのに使用できます。
説明的で、分かりやすい列を作成します。
列が特定の項目に該当しない場合や、その値が不明の場合に NULL 値を入れられる列を定義します。
モデル内で固有の列名を定義します。
異なるディメンション表内で重複する名前がある場合は、区別をつけます。
例えば、Address Type Code という名前の列が複数ある場合、一方の列を Beneficiary Address Type Code という名前に、もう一方の列を Premium Address Type Code という名前に変更します。
すべての列を適切に文書化します。
- コードを処理する
- ディメンション内でコードを使用する場合、そのコードの説明を含めます。
例えば、支店コードによって支店を特定する場合に、各コードが支店名を表すときは、コードと名前の両方を含めます。
列を定義したら、ディメンションの階層を定義することができます。
階層とは、連続した、一連の多対 1 の関係のことです。
階層にはさまざまなレベルが含まれ、それぞれがディメンション属性に対応します。
階層の詳細は、『階層』を参照してください。
日時ディメンションの細分度を特定する
日時ディメンションの細分度を特定します。
日時ディメンションは、ディメンション・モデル全体の細分度と、そのモデルに保管される情報のレベルを判別するのに役立ちます。
日付または時間のいずれかのディメンションに誤ったグレーンを定義すると、重要なディメンションを除外してしまう可能性があります。
例えば、注文管理システム用のディメンション・モデルを設計し、日付ディメンションのグレーンを四半期として設計すると、他の多くのディメンション (Time や Employee など) を除外してしまう可能性があります。
モデルが日付ディメンションのグレーンを日単位のレベルに定義していれば、これらその他のディメンションを含めることができます。
- 日付ディメンション
- すべてのディメンション・モデルは時間単位をベースにしているので、どのデータマートにも日付ディメンションがあります。
例えば、ある期間のビジネスの活動状況を測定することができます。
ディメンション・モデルは、複数の日付ディメンションを含むことができます。
日付ディメンションには、通常、ディメンションに関連付けられた OLTP ソース・システムはありません。
ディメンション・モデルを設計する前に、日付ディメンションを開発することができます。
日付ディメンションを作成するには、次のステップを実施します。
- 必要なすべての列を特定します。
- SQL ステートメントを使用して、Date、Day、Month、Year などの列のデータを日付ディメンション表に追加します。
特別な列には手動でデータを入力する必要があるかもしれません。
例えば、休業日 (休日など) を追跡している場合、Christmas や Boxing Day を手動で入力する必要があります。
また、会計年度の日付、会計年度の月、会計年度の四半期、会計年度の年などの日付も、手動で入力する必要があります。
日付データは多くの場合、以下の 2 つの理由で (ファクト表内の Date 列ではなく) 別個の日付ディメンションに保管されます。
- SQL 日付関数がサポートしていない日付属性がいくつかある。
該当する関数には、会計年度の期間、祝日、季節、平日、週末、国家行事などが含まれます。
日付ディメンションの作成時には、各種の会計年度および日付関連の属性にわたって、ビジネスのパフォーマンス標識を調べることができます。
SQL の日付または時刻列をファクト表内で使用すると、パフォーマンス標識が明確でなくなります。
- 複雑な SQL 関数を使ってレポートのロジックを作成するより、日付表から列をドラッグする方がはるかに簡単です。
- 時間ディメンション
ディメンション・モデリング内の時間は、次の 2 とおりの方法で処理することができます。
- 時刻を別個のディメンションにする
- 時刻をファクトにする
時間データは、ファクト表内のファクトではなく、ディメンション表内で処理する必要があります。
レポートおよび分析目的で、さらに要約されたグループへの期間の集約をサポートする必要がある場合は、時間ディメンションを作成する必要があります。
例えば、次のような要約グループの時間ディメンションを作成します。
- 時
- ビジネス固有の時間グループ (平日の朝、深夜シフト、または夕方)
また、測定する時間に対してそれぞれ異なる階層を表す場合も、時間ディメンションを作成する必要があります。
例えば、標準時と 24 時間時計に対して別々の階層を作成します。
ただし、時刻グループの集約やフィルタリングを行わない場合、時間をファクト表内のファクトとして表します。
その場合、時間は、タイム・スタンプ・データ型の単純な数値ファクトとして扱われます。
注: 時間をファクト表内のファクトとして表した場合、長期間保管されていたデータを分析する際のレポート作成と要約のプロセスが困難になります。
別の時間ディメンションを作成すれば、データの要約とレポート作成を簡単に行うことができます。
緩やかに変化するディメンションを特定する
緩やかに変化するディメンションを特定し、変化するデータの処理方法を決定する必要があります。
緩やかに変化するディメンションとは、時間の経過とともに漸次変化するレコード属性を持つディメンションのことです。
例えば、社内での社員の配置転換を追跡記録しなければならない場合があります。
ワークベンチは、次のタイプの緩やかに変化するディメンションをサポートします。
- タイプ 0
- ディメンションに対して変更は加えられません。
- タイプ 1
- 新規データによって旧データが上書きされます。
変更履歴は追跡されません。
- タイプ 2
- この方法では、2 つの別々の項目が作成されます。
元のレコードと新規レコードの両方が、表内に存在します。
新規行には、独自の主キー (代理キー) が設定されます。
- タイプ 4
- 履歴データの一部または全部を保管するための別の表が作成されます。
1 つの表にのみ現行データが格納され、更新が発生すると、古いデータは履歴表に移動されます。
- タイプ 6
- タイプ 1、タイプ 2、およびタイプ 3 (同一表内の別々の列にデータが保管される) が結合されます。
通常、古いデータは別のレコードおよび列に移動され、新規データが元のレコードに保管されます。
スノーフレーク化ディメンションの事例を特定する
スター・スキーマ内でディメンション表を正規化および拡張する場合、スノーフレーク・スキーマ設計を作成します。
ディメンション内の低カーディナリティー属性を除去して正規化済みの表を分離した後に、それらの正規化済みの表を元のディメンション表に再結合すると、ディメンション表はスノーフレーク化されます。
注: ディメンション・モデル環境でのスノーフレーク化は、推奨されていません。
スノーフレーク化は、ディメンション・モデルの理解を難しくします。
結合する必要のある表が増えるため、スノーフレーク化はパフォーマンス低下の原因になる可能性もあります。
ディメンション・モデル内でのディメンションのスノーフレーク化は、次のような 2 つのケースでのみ行ってください。
- ディメンション表に、異なるグレーンで情報を定義している複数の属性セットが含まれる場合。
- 異なるソース・システムを介して同一のディメンション表の一連の属性にデータを追入力する場合。
1 つのディメンション表の階層を別々の表にスノーフレーク化しないでください。
階層は、ディメンション表にのみ所属する必要があります。
階層をスノーフレーク化しないでください。
複数の階層が同一のディメンションに所属できるのは、そのディメンションが最低限の詳細さで設計されている場合です。
階層を別々の表に分割すると、より多くの結合が必要になるため、パフォーマンスに影響します。
場合によっては、主表の階層をスノーフレーク化することができます。
ファクト表を集約して使用する場合、より大きなディメンション表への結合を避けるために、ディメンションを階層でのみスノーフレーク化します。
例えば、製品のディメンション表からブランド情報を分離する場合、Brand スノーフレーク化ディメンションを作成します。このディメンションにはブランドごとに 1 行含まれるため、Product ディメンション表よりも少ない行数を使用することになります。
注: スノーフレーク・スキーマで使用する表が多すぎると、設計が複雑になりすぎます。
ディメンション・モデリングの目的は、単純で分かりやすいモデルを作成することです。
表が増えると、より多くの結合を作成する必要があります。
より多くの結合を作成する場合、パフォーマンスが低下します。