Loading article…
ディメンションとは、ユーザーがビジネス上の質問に答えられるように、事実と尺度を分類する構造です。一般的に使用されるディメンションは、人、製品、場所、時間です。 [1] [2]（注：人と時間はディメンションとしてモデル化されない場合があります。）
データ ウェアハウスでは、ディメンションは、順序付けられていない数値メジャーに構造化されたラベル情報を提供します。ディメンションは、重複しない個別のデータ要素で構成されたデータ セットです。ディメンションの主な機能は、フィルタリング、グループ化、ラベル付けの 3 つです。
これらの機能は、しばしば「スライス アンド ダイス」と呼ばれます。一般的なデータ ウェアハウスの例では、売上がメジャーとして含まれ、顧客と製品がディメンションとして使用されます。各売上で、顧客は製品を購入します。データは、調査対象のグループを除くすべての顧客を削除してスライスし、製品ごとにグループ化してダイスすることができます。
次元データ要素は、統計におけるカテゴリ変数に似ています。
通常、データ ウェアハウス内のディメンションは、内部的に 1 つ以上の階層に編成されます。「日付」は一般的なディメンションであり、次のような複数の階層が可能です。
- 「日（は月（は年）にグループ化されます）」
- 「日（は週（は年）にグループ化されます）」
- 「日（は月（は四半期（は年）にグループ化されます）」
- 等
種類
ゆっくりと変化する次元
ゆっくり変化するディメンションとは、定期的に変化するのではなく、一定期間にわたってゆっくりと変化するデータ属性のセットです（例：住所や名前）。これらの属性は一定期間にわたって変化する可能性があり、ゆっくり変化するディメンションとして組み合わされます。これらのディメンションは、次のタイプに分類できます。[3]
- タイプ 0 (オリジナルを保持) : 属性は変更されません。履歴はありません。
- タイプ 1 (上書き) : 属性の古い値は新しい値で上書きされます。履歴はありません。
- タイプ 2 (新しい行の追加) : 開始日/終了日または新しい値のバージョンのいずれかを使用して新しい行が作成されます。これにより履歴が作成されます。
- タイプ 3 (新しい属性の追加) : 新しい値に対して新しい列が作成されます。履歴は、履歴データを格納するために指定された列の数に制限されます。
- タイプ 4 (履歴テーブルの追加) : 1 つのテーブルに現在の値が保持され、履歴は 2 番目のテーブルに保存されます。
- タイプ 5 (組み合わせアプローチ 1 + 4) : タイプ 1 とタイプ 4 の組み合わせ。履歴は 2 番目の履歴テーブルを通じて作成されます。
- タイプ 6 (組み合わせアプローチ 1 + 2 + 3) : タイプ 1、タイプ 2、タイプ 3 の組み合わせ。履歴は個別の行と属性を通じて作成されます。
- タイプ7（ハイブリッドアプローチ）：代理キーと自然キーの両方が使用されます。[4]
適合寸法
適合ディメンションとは、同じキー値を使用して複数のデータベース テーブルで物理的に参照され、同じ構造、属性、ドメイン値、定義、概念を参照するデータ属性のセットです。適合ディメンションは、多くのファクトにまたがります。
ディメンションは、完全に同じ (キーを含む) か、一方が他方の適切なサブセットである場合に適合します。最も重要なのは、同じ適合ディメンションから 2 つの異なる回答セットで生成された行ヘッダーが完全に一致する必要があることです。'
適合ディメンションは、最も粒度が細かく詳細なディメンションと同一か、または厳密な数学的サブセットです。属性のラベルが異なっていたり、属性に異なる値が含まれていたりすると、ディメンション テーブルは適合しません。適合ディメンションにはいくつかの種類があります。最も基本的なレベルでは、適合ディメンションは、結合されるすべてのファクト テーブルでまったく同じ意味を持ちます。売上ファクトに接続された日付ディメンション テーブルは、在庫ファクトに接続された日付ディメンションと同一です。[5]
ジャンクディメンション
ジャンク ディメンションは、通常、カーディナリティの低いフラグとインジケーターを便利にグループ化したものです。抽象ディメンションを作成することにより、これらのフラグとインジケーターはファクト テーブルから削除され、便利なディメンション フレームワークに配置されます。[6]ジャンク ディメンションは、ファクト テーブルまたは既存のディメンション テーブルのいずれにも属さない属性で構成されるディメンション テーブルです。これらの属性の性質は通常、テキストまたはさまざまなフラグ (非汎用コメントや単純なはい/いいえまたは真/偽インジケーターなど) です。これらの種類の属性は通常、ビジネス プロセスのすべての明らかなディメンションが識別された後に残り、そのため設計者は、他のディメンションに属さないこれらの属性をどこに配置するかという課題に直面します。
1 つの解決策は、残りの属性ごとに新しいディメンションを作成することですが、その性質上、膨大な数の新しいディメンションを作成する必要があり、その結果、ファクト テーブルに非常に多くの外部キーが含まれることになります。設計者は、残りの属性をファクト テーブルに残すことも決定できますが、たとえば属性が長いテキスト文字列である場合、テーブルの行の長さが不必要に大きくなる可能性があります。
この課題の解決策は、すべての属性を識別し、それらを 1 つまたは複数のジャンク ディメンションに入れることです。1 つのジャンク ディメンションには、互いに相関関係のない複数の true/false または yes/no インジケーターが保持される可能性があるため、インジケーターをより説明的な属性に変換すると便利です。例として、パッケージが到着したかどうかを示すインジケーターが挙げられます。ジャンク ディメンションでは、これを「はい」または「いいえ」として示す代わりに、「到着済み」または「保留中」に変換します。設計者は、他のすべてのインジケーターとともに発生するすべてのインジケーターを保持するようにディメンション テーブルを構築して、すべての組み合わせをカバーできます。これにより、テーブル自体の固定サイズが設定されます。これは 2 x行 ( xはインジケーターの数) になります。このソリューションは、設計者がさまざまな組み合わせに遭遇すると予想し、可能な組み合わせが許容レベルに制限されている状況に適しています。指標の数が多く、非常に大きなテーブルを作成する場合や、設計者がいくつかの可能な組み合わせに遭遇すると予想している場合は、新しい組み合わせに遭遇するたびにジャンク ディメンションの各行を構築する方が適切です。テーブルのサイズを制限するために、さまざまな指標間の相関関係によっては、複数のジャンク ディメンションが適切な場合もあります。
ジャンクディメンションは、ファクトテーブルからの非一般的なコメントなどの属性を配置するのにも適しています。このような属性は、顧客が注文をする際にオプションのコメントフィールドからのデータで構成される可能性があり、その結果、多くの場合空白になる可能性があります。したがって、ジャンクディメンションには、空白を表す1行が、ファクトテーブルで空白のコメントフィールドとともに返されるすべての行に使用される代理キーとして含まれている必要があります。[7]
退化した次元
縮退ディメンションとは、トランザクション番号、請求書番号、チケット番号、船荷証券番号などの属性を持たないキーであり、実際のディメンション テーブルには結合されません。縮退ディメンションは親の一意の識別子を表すため、ファクト テーブルの粒度が単一のトランザクション項目または明細項目を表す場合に非常によく使用されます。縮退ディメンションは、ファクト テーブルの主キーで重要な役割を果たすことがよくあります。[8]
ロールプレイングの側面
ディメンションは、同じデータベース内の複数のアプリケーションで再利用されることがよくあります。たとえば、「日付」ディメンションは、「販売日」だけでなく、「納品日」や「雇用日」にも使用できます。これは、「ロール プレイング ディメンション」と呼ばれることがよくあります。これは、同じディメンション テーブル上のビューを使用して実装できます。
アウトリガー寸法
通常、ディメンション テーブルは外部キーを介して他のディメンションを参照しません。この場合、参照されるディメンションはアウトリガー ディメンションと呼ばれます。アウトリガー ディメンションはデータ ウェアハウスのアンチパターンと見なされます。2 つのディメンションを関連付けるファクト テーブルを使用する方がよいと考えられています。 [9]
縮小された次元
適合された寸法は、元の寸法の行および/または列のサブセットを含む場合、縮小された寸法と呼ばれます。[10]
カレンダー日付ディメンション
特別なタイプのディメンションを使用して、1 日の粒度で日付を表すことができます。日付は、ファクトテーブルで日付ディメンションの外部キーとして参照されます。日付ディメンションの主キーは、代理キーまたは YYYYMMDD 形式を使用した数値にすることができます。
日付ディメンションには、年間の週や、営業日、休日などを表すフラグなどの他の属性を含めることができます。また、不明な日付やまだ定義されていない日付を表す特別な行を含めることもできます。日付ディメンションは、必要なすべての日付、たとえば今後 10 年間の日付、必要に応じてそれ以上の日付、または過去のイベントを処理する場合は過去の日付で初期化する必要があります。
代わりに、時間は通常、ファクトテーブル内のタイムスタンプとして表現するのが最適です。 [11]
ISO表現用語の使用
ISO/IEC 11179などのメタデータレジストリからデータを参照する場合、通常、「インジケーター」(ブール値の true/false 値)、「コード」(重複しない列挙値のセット) などの表現用語がディメンションとして使用されます。たとえば、 National Information Exchange Model (NIEM) を使用する場合、データ要素名は「PersonGenderCode」になり、列挙値は「男性」、「女性」、および「不明」になります。
寸法表
データ ウェアハウスでは、ディメンション テーブルはファクト テーブルに付随する一連のテーブルの 1 つです。
ファクト テーブルには、ビジネス ファクト (またはメジャー) と、ディメンション テーブル内の 候補キー(通常は主キー)を参照する外部キーが含まれます。
ファクト テーブルとは異なり、ディメンション テーブルには、通常はテキスト フィールド (またはテキストのように動作する個別の数値) である説明的な属性 (またはフィールド) が含まれます。これらの属性は、クエリの制約やフィルタリング、およびクエリ結果セットのラベル付けという 2 つの重要な目的を果たすように設計されています。
ディメンション属性は次のようになります。
- 詳細（完全な単語で構成されるラベル）
- 説明的
- 完全（欠損値なし）
- 離散値（ディメンション テーブル行ごとに 1 つの値のみを持つ）
- 品質保証（スペルミスや不可能な値がない）
ディメンション テーブルの行は、単一のキー フィールドによって一意に識別されます。キー値は意味がなく、ファクト テーブルとディメンション テーブル間のフィールドを結合する場合にのみ使用されるため、キー フィールドは単純な整数にすることをお勧めします。ディメンション テーブルでは、代理キーでもある主キーがよく使用されます。代理キーは、多くの場合、自動生成されます (例: Sybase または SQL Server の「ID 列」、PostgreSQL または Informix のシリアル、Oracle SEQUENCE、または MySQL で AUTO_INCREMENT で定義された列)。
代理ディメンション キーを使用すると、次のようないくつかの利点が得られます。
- パフォーマンス。単一のフィールド（代理キー）を使用することで、結合処理の効率が大幅に向上します。
- 運用上のキー管理方法からのバッファリング。これにより、長期間使用されていない自然キーが再利用または再割り当てされたときに、削除されたデータ行が再び表示される状況が防止されます。
- 異なるソースを統合するためのマッピング
- 不明または該当しない接続の処理
- ディメンション属性値の変更の追跡
代理キーの使用はETLシステムに負担をかけますが、パイプライン処理は改善可能であり、ETL ツールには改善された代理キー処理が組み込まれています。
ディメンション テーブルの目的は、企業のデータ ウェアハウス環境全体で共有できる標準化された適合ディメンションを作成し、さまざまなビジネス プロセスを表す複数のファクト テーブルへの結合を可能にすることです。
適合ディメンションは、次のことを促進するため、DW/BI システムのエンタープライズ特性にとって重要です。
- 一貫性。すべてのファクト テーブルは一貫してフィルター処理されるため、クエリの回答には一貫したラベルが付けられます。
- 統合。クエリは、異なるプロセス ファクト テーブルに個別にドリルダウンし、共通のディメンション属性で結果を結合できます。
- 市場投入までの開発時間を短縮。共通のディメンションは再作成せずに使用できます。
時間の経過とともに、ディメンション テーブル内の特定の行の属性が変化することがあります。たとえば、会社の配送先住所が変わることがあります。Kimball はこの現象を「ゆっくり変化するディメンション」と呼んでいます。この種の変化に対処するための戦略は、次の 3 つのカテゴリに分けられます。
- タイプ 1: 古い値を上書きするだけです。
- タイプ 2: 新しい値を含む新しい行を追加し、タプル バージョン管理手法を使用して行を区別します。
- タイプ 3: 既存の行に新しい属性を追加します。
一般的なパターン
日時
出典: [12]
データ ウェアハウス内のファクト テーブルの多くは観測の時系列であるため、1 つ以上の日付ディメンションが必要になることがよくあります。日付ディメンションを持つ理由の 1 つは、カレンダーの知識をアプリケーションにハードコードするのではなく、データ ウェアハウスに配置することです。単純な SQL日付タイムスタンプは、ファクトが記録された時間に関する正確な情報を提供するのに役立ちますが、休日、会計期間などに関する情報は提供できません。SQL 日付タイムスタンプは、正確な計算を可能にするため、ファクト テーブルに格納すると便利です。
日付と時刻の両方を同じディメンションに持つと、数百万行の巨大なディメンションになりがちです。詳細度を高くする必要がある場合は、通常、日付と時刻を 2 つ以上の別々のディメンションに分割することをお勧めします。1 日の秒単位の粒度の時間ディメンションには、86,400 行しかありません。日付/時刻ディメンションの詳細度は、必要に応じて選択できます。たとえば、日付ディメンションは年、四半期、月、または日単位の精度にすることができ、時刻ディメンションは時間、分、または秒単位の精度にすることができます。
経験則として、時間帯ディメンションは、階層的なグループ化が必要な場合、または 1 日の時間帯について意味のあるテキスト説明がある場合にのみ作成する必要があります (例:「夕方のラッシュ」または「最初のシフト」)。
ファクト テーブル内の行が複数のタイム ゾーンから取得される場合、日付と時刻をローカル時間と標準時間の両方で保存すると便利な場合があります。これは、必要な日付/時刻ディメンションごとに 2 つのディメンション (ローカル時間用と標準時間用) を用意することで実現できます。日付/時刻をローカル時間と標準時間の両方で保存すると、ローカル設定とグローバル設定の両方でファクトがいつ作成されたかを分析できます。選択する標準時間は、グローバル標準時間 (例: UTC )、企業の本社のローカル時間 (例: CET )、または使用に適したその他のタイム ゾーンにすることができます。
参照
参考文献
- ^ 「Oracle Data Warehousing Guide」、Oracle Corporation、2014 年 6 月 9 日閲覧
- ^ 定義: ディメンション" Search Data Management、TechTarget、2014 年 6 月 9 日取得
- ^ Says, Kalyn (2014 年 10 月 9 日)。「ディメンション テーブルの種類 | データ ウェアハウス トレーニング」。Edureka。2022年1月 12 日閲覧。
- ^ Ross, Margy (2013 年 2 月 5 日). 「デザイン ヒント #152 ゆっくりと変化するディメンション タイプ 0、4、5、6、7」. Kimball Group . 2022 年1 月 12 日閲覧。
- ^ Ralph Kimball、Margy Ross、『データ ウェアハウス ツールキット: ディメンショナル モデリングの完全ガイド』第 2 版、Wiley Computer Publishing、2002 年。ISBN 0471-20024-7、82-87ページ、394
- ^ Ralph Kimball、Margy Ross、『データ ウェアハウス ツールキット: ディメンショナル モデリングの完全ガイド』第 2 版、Wiley Computer Publishing、2002 年 。ISBN 0471-20024-7、202、405ページ
- ^ Kimball, Ralph他(2008): データ ウェアハウス ライフサイクル ツールキット、第 2 版、Wiley Publishing Inc.、インディアナポリス、インディアナ州。263-265 ページ
- ^ Ralph Kimball、Margy Ross、『データ ウェアハウス ツールキット :ディメンショナル モデリングの完全ガイド』第 2 版、Wiley Computer Publishing、2002 年。ISBN 0471-20024-7、50、398ページ
- ^ ラルフ・キンボール、マージー・ロス (2013)。データウェアハウスツールキット第3版。ワイリー。50ページ。ISBN 978-1-118-53080-1。
- ^ ラルフ・キンボール、マージー・ロス (2013)。データウェアハウスツールキット第3版。ワイリー。p.51。ISBN 978-1-118-53080-1。
- ^ ラルフ・キンボール、マージー・ロス (2013)。データウェアハウスツールキット第3版。ワイリー。p.48。ISBN 978-1-118-53080-1。
- ^ Ralph Kimball、『データウェアハウスツールキット』第2版、Wiley Publishing, Inc.、2008年 。ISBN 978-0-470-14977-5、253-256ページ