スタースキーマの「ディメンション」テーブルとリレーショナルデータベースの「ルックアップ」テーブルの違いは何ですか？
スタースキーマファクトテーブルとそれを囲むいくつかのディメンションテーブルを設計しようとしています。 customer_keyとfact_tableの両方でdim_customerという自然キーを再利用すると、薄暗いものとルックアップテーブルの呼び出しに違いが見られません。さらに、customer_nameをすべて更新する必要がある場合は、録音時にこの事実を表した履歴データが失われます。薄暗いテーブルとファクトテーブルをモデル化しようとすると、何が欠けていますか？
リレーショナル「ルックアップ」テーブルテクニックとデータウェアハウス「ディメンション」テーブルの違いを知りたいのですが。
fact_table dim_customer dim_product
------------- ------------ -----------
customer_key customer_key product_key
product_key name name
units_sold email description
unit_price
この質問で私が示すかもしれない無知を許してください。私はデータウェアハウスの初心者です。
これらのテーブルしかない場合は、datawarehouseスタースキーマと実際のスキーマにほとんど違いはありません。
ただし、おそらくはるかに複雑なリレーショナルスキーマがあり、顧客グループまたはアイテムタイプもあり、スキーマは次のようになります。
ファクトテーブル->顧客テーブル->顧客グループテーブル
ファクトテーブル->アイテムテーブル->アイテムタイプテーブル
スタースキーマに向けて作業しているときは、スキーマを非正規化して、顧客グループの説明を顧客ディメンションテーブルに、項目タイプの説明を項目ディメンションテーブルに含めます。
スタースキーマの基本は、ファクトテーブルがあり、すべてのディメンションがファクトテーブルから1ステップだけ離れた単一のテーブルであることです。
方法 kimballが説明しています ：
スタースキーマは、主キー/外部キーの関係を介して関連するディメンションテーブルにリンクされたファクトテーブルで特徴的に構成されています。
ディメンションを単一ディメンションテーブルに非正規化しないと、スノーフレークスキーマになります。スノーフレークは良い考えのように思えるかもしれませんが、クエリのパフォーマンスが低下することが多く、特にデータウェアハウスの上にキューブを構築する場合は特に、さまざまな問題が発生する可能性があります。
もう一度 Kimballに投稿があります：
通常、スノーフレーキングではなく、多対1の階層関係を単一のディメンションテーブルで処理することをお勧めします。スノーフレークは、経験豊富なOLTPデータモデラーには最適に見えますが、DW/BIクエリのパフォーマンスには最適ではありません。リンクされたスノーフレークテーブルは、テーブル構造に直接さらされているユーザーに複雑さと混乱をもたらします。ユーザーがテーブルからバッファリングされている場合、スノーフレークにより、クエリを解決するために数百のテーブルをリンクする必要があるオプティマイザの複雑さが増します。スノーフレークは、ETLシステムに負荷をかけ、正規化されたテーブルをリンクするキーを管理します。スノーフレークは、繰り返されるテキスト文字列をコードに置き換えることで一部のスペースを節約できますが、特に追加のETL負担とクエリの複雑さに対して支払われる価格を考慮すると、節約は無視できます。
「緩やかに変化するディメンション」を使用することで解決されるデータウェアハウスでの、顧客データの変更と履歴の喪失に関する質問について。
基本的にいくつかのタイプの緩やかに変化するディメンションがありますが、トランザクションのときに有効だった行を選択できるように、ディメンション行にvalid_fromとvalid_toの日付を格納することになる「タイプ2」をおそらく探しています。 。
プライマリサロゲートキーに加えて、タイプ2の処理中のディメンションに5つのフィールドを追加することをお勧めします。これらのフィールドを図1に示します。日時は、変更が有効になってから次の変更が有効になるまでの期間を表すフルタイムスタンプです。タイプ2ディメンションレコードの終了有効日時は、そのディメンションメンバーの次の変更の開始有効日時と正確に等しくなければなりません。
これはカバーする幅広い主題ですが、これで基本事項の正しい方向に進んで、将来正しい用語を使用できるようになることを願っています。
Kimballサイトは、次元モデリングのための優れたリソース（そして多くの場合、リファレンスと呼ばれています）なので、 用語集 と 設計のヒントセクション を参照することをお勧めします。
ディメンションテーブル：ディメンションテーブルはスタースキーマに存在し、ファクトテーブルのオブジェクトを記述する属性/ディメンションを格納します。ディメンションは、測定可能なイベントに関する情報のグループであり、ファクトと呼ばれ、ファクトテーブルに格納されます。ディメンションは、データウェアハウスのファクトとメジャーを分類して、すべてのビジネス上の質問に対する有意義な回答をサポートします。
記述属性は、データウェアハウスによってディメンションテーブルの列として編成されます。すべてのディメンションテーブルには、主キーを含む列があり、ディメンションの各行を一意に識別します。ディメンションテーブルは、主キーを使用してファクトテーブルにリンクされます。
ルックアップテーブル：略してLUTとしても知られるルックアップテーブルは、実際にはコンピュータプログラミングで使用される配列です。このテーブルには、計算が必要な値が含まれています。ルックアップテーブルを手動で入力するのは簡単です。プログラムの作成中に行われます。プログラムは、値を計算するときにテーブルに値を入力する場合もあります。将来これらの値が必要になった場合、プログラムはそれらを簡単に検索してCPUリソースを節約できます。