データウェアハウジングプロジェクトを開始するとき、最初に行うことは、ディメンションテーブルを定義することです。ディメンションテーブルは興味深いビットであり、その周りに測定値を作成するためのフレームワークです。彼らは多くの形とサイズで来ます。この記事では、各タイプの寸法表を詳しく見ていきます。
ディメンションテーブルは、測定するビジネスプロセスのコンテキストを提供します。彼らは私たちがイベントについて知る必要があるすべてを教えてくれます。それらはデータウェアハウス（DWH）システムの測定値（つまりファクトテーブル）に実質を与えるため、プロジェクトの他のどの側面よりも、それらの定義と識別に多くの時間を費やしています。ファクトテーブル定義 測定;次元テーブルはコンテキストを提供します。 （ファクトテーブルの詳細については、データウェアハウジング、スタースキーマ、スノーフレークスキーマ、およびファクトテーブルに関するファクトに関するこれらの投稿を確認してください）。
ディメンションテーブルの主な特徴は、多数の属性です。 。属性は、要約、フィルタリング、または集約する列です。それらはカーディナリティが低く、通常はテキストと時間です。ディメンションテーブルには、基になるビジネスキーまたは代理キーに基づく1つの主キーがあります。 。この主キーは、ディメンションテーブルを1つ以上のファクトテーブルに結合するための基礎です。
ファクトテーブルと比較して、ディメンションテーブルはサイズが小さく、保存が簡単で、パフォーマンスへの影響はほとんどありません。
次に、データウェアハウス環境で遭遇するディメンションテーブルのいくつかを見てみましょう。
一般的なディメンションテーブル：適合ディメンション
基本的なタイプである適合寸法から始めます。これらは複数の属性を保持し、複数のソーステーブルでアドレス指定できますが、同じドメインを参照します。 （顧客、契約、取引など）適合ディメンションは多くの事実とともに使用され、データウェアハウスのグレイン/ドメイン値に対して一意である必要があります。
例：
典型的なディメンションテーブル、DIM_CUSTOMER 。
定義：
-
id–ディメンションテーブルの主キー。 -
cust_natural_key–顧客にとっての自然キー。 -
first_name–顧客の名。 -
last_name–顧客の名前。 -
address_residence–お客様の住所。 -
date_of_birth–顧客の生年月日。 -
marital_status–顧客は結婚していますか？ Y（はい）またはN（いいえ）として定義されます。 gender–顧客の性別、M（男性）またはF（女性）。
ディメンションテーブルの属性は、ビジネスニーズによって異なります。このタイプのテーブルを拡張して、業界固有の情報（デフォルトの日付、アクティビティなど）を保持できます
ゆっくりと変化する次元テーブル
時間の経過とともに、ディメンションはその値を変更できます。次の段落では、履歴データを保存する（または保存しない）方法によって分類されたディメンションを調べます。
顧客の側面があるとしましょう。一部の属性は、お客様の存続期間中に変更される可能性があります。電話番号、住所、結婚歴など。このタイプのテーブルは、ラルフキンボールがゆっくりと変化する次元（SCD）と呼んでいるものです。
SCDには多くの種類があります。それらのうちの8つはかなり一般的です。これらの中で、タイプ0から4が最も多く表示されます。タイプ5、6、および7は、最初の5つのハイブリッドです。 （注：これらのSCDの番号付けスキームは、1ではなく0で始まります。）
ハイブリッドSCDは、柔軟性とパフォーマンスを向上させますが、単純さを犠牲にします。 現在の分析分析を行う必要がある場合は、これらのテーブルタイプを使用します いくつかの履歴を含むデータ 考慮事項。
SCDタイプ0：1回の充填
これは、ディメンションテーブルの最も基本的なタイプです。一度入力すると、決して入力しません。 もう一度記入してください。これを参照データと見なしてください。この典型的な例は、日付ディメンションです。すべてのDWH負荷でこの寸法を埋める必要はありません。ディメンションテーブルは時間の経過とともに変化しません。これ以上の日付を取得したり、日付を変更したりすることはできません。
ファクトテーブルは、ディメンションの元の属性に接続します。
例
時間の次元を見てみましょう：
構造は非常に単純です：
-
id–代理キー -
time_date–実際の日付 -
time_day–月の日 -
time_week–その年の週 -
time_month–1年の月 -
time_year–1年の数値表現
SCDタイプ1：データの書き換え
名前が示すように、DWHをロードするたびにこのタイプのディメンションテーブルを書き直します。それらの履歴を保持する必要はありませんが、いくつかの変更があると予想しています。
タイプ0のSCDとタイプ1の違いは、テーブルの構造にはありません。これは、データの更新と関係があります。タイプ0でデータを更新することはありませんが、タイプ1で更新する場合があります。
書き換え可能なテーブルは、変更（削除/挿入）を処理する最も簡単な方法ですが、ビジネス上の価値はほとんどありません。このようにディメンションテーブルを定義すると、履歴トレースをインストールするのは困難です。
ファクトテーブルは、ディメンションの現在の属性に接続します。
例
アカウントディメンションを見てみましょう：
その構造は次のとおりです。
-
id–テーブルの代理キー -
account_name–アカウントの名前 -
account_type–アカウントのカテゴリ -
account_activity–さまざまな種類のアクティビティにフラグを立てます
変更前のデータを見ると、次のようになります。
アカウントの種類が変更された場合、データは単に上書きされます：
SCDタイプ2：行ごとの履歴属性の追跡
これは、DWHシステムでの履歴追跡の最も一般的な形式です。 SCDタイプ2テーブルは、ディメンション属性のすべての履歴変更間に新しい行を追加します。 DWHロード 。このタイプでは、主キーを代理キーとして定義します。これは、ビジネスキーが時間の経過とともに複数の表現を持つためです。データの変更を保持する行が変更されると、ファクトテーブルの値に対応する代理キーの新しい値を定義します。少なくとも2つの列valid_fromを追加する必要があります およびvalid_to 、この方法で履歴を保存します。
ファクトテーブルは、代理キーを介してディメンションの履歴属性に接続します。集計は自然キーで行われます 。
例
2つの日付列で展開された以前の顧客ディメンションテーブルを見てみましょう：
データを見てみましょう：
考慮事項：
- 現在の行にフラグを立てるにはどうすればよいですか、
valid_to？ （通常は31.12.9999、または NULL 。） - 最初の行
valid_fromにフラグを立てるにはどうすればよいですか。 ？ （通常は01.01.1900、または最初の挿入日） - 包括的または排他的な行を定義しますか？ （上記では、包括的な
valid_fromを使用しています および排他的なvalid_to。
SCDタイプ3：列ごとの履歴属性の追跡
タイプ2SCDと同様に、このタイプは履歴値を表すために何かを追加します。ただし、この場合、新しい列を追加しています。これらは、変更前のディメンション行属性の値を表します。通常、属性の以前のバージョンのみを保持します。
注：このSCDはめったに使用されません。
ファクトテーブルは、ディメンションの現在および以前の属性に接続します。
例
今回は以前の住所で顧客の側面を見てみましょう：
この例では、新しい列previous_address_residenceを追加しました。 、顧客の古い住所を表すため。最初の例を見ると、このテーブルのデータは次のようになります。
顧客の以前の住所を除くすべての履歴情報が失われます。
SCDタイプ4：ミニディメンションの追加
このタイプのディメンションは、構造（タイプ3）または値（タイプ2）の変更に基づいていません。むしろ、モデルの設計変更に基づいています。ディメンションテーブルに揮発性の高いデータ（つまり、頻繁に変更されるデータ）が含まれている場合、ディメンションテーブルのサイズは大幅に大きくなります。
これを軽減するために、揮発性属性をミニディメンションに抽出します。 。これらのミニディメンションは、ビジネス関連のレベルに集約できます。ただし、この集計はすべきではありません ファクトの集計と混同しないでください 。この例でこれが明らかになります。
ファクトテーブルは、ディメンションの履歴属性に接続します。
例
単純な財務データマートの例を見てみましょう。特定の顧客が支払いにどれだけ遅れているかを追跡する必要があるとします。この属性を期限を過ぎた日、またはDPDと呼びましょう。タイプ2ディメンションで毎日DPDを追跡する場合、テーブルのサイズはすぐに管理可能な制限を超えて爆発します。そのため、属性を抽出し、ビジネスに関連するDPDの期間を見つけます。たとえば30日単位（0-30 DPD、30-60 DPD、60-90 DPDなど）
年齢などの他の変動性の高い属性を取得し、それらのビジネス関連の期間を構築することもできます（たとえば、20〜30歳、30〜40歳など）
顧客のミニディメンションのデータを見ると、次のようになります。
属性は次のとおりです。
-
id–代理主キー -
DPD_period–期日を過ぎた日数 -
DEM_period–人口統計期間
単純なスタースキーマは次のようになります：
両方のテーブルの属性を分析するには、ファクトテーブルを介してそれらをブリッジする必要があることに注意してください。
SCDタイプ5：書き換え可能な拡張機能を備えたミニディメンションの作成
これは、ハイブリッド次元テーブル構成の最初のものです。タイプ5SCDでは、現在のバージョンのミニディメンションデータをディメンションテーブルに追加します。 現在のみを追加することに注意する必要があります ミニディメンションのメインディメンションへの表現。
このミニディメンションエクステンションをすべての負荷で補充します（タイプ1の「書き換え可能な」SCD）。
この拡張機能の履歴化はサイズの問題につながる可能性がありますが、ミニディメンションテーブルを使用してすでに問題を軽減しています。
この手法は、分析を直接実行する場合に使用します。 ディメンションテーブルで。
例
前の例を現在のミニディメンションで拡張すると、次のようになります。
dim_mini_customer_current テーブルには、dim_customer テーブル。これで、ファクトテーブルを介さずに顧客固有の分析を実行できるようになりました（これは非常に低速です）。
ファクトテーブルは、ディメンションの履歴属性に接続します。
タイプ6：書き換え可能な属性を持つタイプ2（履歴行）ディメンション
これは非常に一般的な次元構造です。ロードするたびに書き換える1つのもの、通常は最後の既知の値を格納する属性を追加します。これにより、すべてのファクトを現在の値でグループ化でき、履歴属性にはイベントが発生したときのデータが表示されます。
ファクトテーブルは、追加の現在のディメンション値を使用して、イベント時のディメンション値に接続します。
例
current_address_residenceを使用して前の顧客テーブルを展開してみましょう 列。
これで、自然キー（cust_natural_keyを使用して現在の値に更新する属性ができました。 。
タイプ7：現在のミラーを使用したタイプ2（履歴行）の寸法
このタイプは、テーブルディメンションに自然キーがある場合にのみ使用できます。キーは変更してはいけません エンティティの存続期間中。
考え方は単純です。ディメンションテーブルの現在の表現をスノーフレークスキーマに追加します。次に、新しいディメンションの自然キーをファクトテーブルに挿入します。 （歴史的側面の代理キーはまだ存在しています。）
ファクトテーブルは、イベント時のディメンション値と現在のディメンション値に接続します。
例
顧客アカウントのスタースキーマを見てみましょう。新しいディメンションdim_current_customer 、ファクトテーブルに。このテーブルは、自然キーcust_natural_keyを介してファクトテーブルに接続されています。 。
この構造により、顧客属性の現在の値と過去の値の両方を使用して、スタースキーマに対して分析クエリを実行できます。
ドメインディメンション
ドメインディメンションは、ディメンションテーブルの単純な形式です。これは、次元属性の基礎となる測定のドメインに関する情報を保持します。これらのテーブルには、さまざまなコードと説明値が格納されています。
例
簡単な例は通貨テーブルです。
この表には、さまざまな通貨単位に関する説明情報が格納されています。
私の個人的な意見では、ドメインディメンションの最適な使用法は、DWHシステムで見つかったデータ値のドキュメントにあります。
ジャンク寸法
トランザクションソースシステムは、多くのインジケーターとフラグを生成します。これらの属性はカテゴリデータと見なすことができますが、ビジネスに関連したり、自明ではありません。これらすべてのインジケーターとフラグをジャンクディメンションと呼ばれる1つのディメンションテーブルにファイルできます。 。ジャンクディメンションは、縮退ディメンションを使用する代わりに使用できます。ファクトテーブルに多くの縮退ディメンションを負担させたくない場合は、1つのジャンクディメンションを作成します。
インジケーターとフラグのすべての可能な組み合わせを埋めるわけではないことに注意してください。ソースシステムに存在するものだけを入力します。
例
ディメンションテーブルは、データウェアハウジングの世界の骨組みです。すべてがそれらを中心に構築されています。それらはファクトテーブルほど大きくはありませんが、構造はより複雑になる可能性があります。
今説明したもの以外にも、さまざまなタイプのディメンションテーブルをまとめることができます。あなたのビジネスと業界はどうですか？ディメンションテーブルタイプを新しいものに組み合わせた場合は、それについて教えてください！