次元モデリング：ファクトテーブルに外部キーが必要ですか？

Question

fact tableにキーが一切ありませんか？ または できればいいですか？ファクト表にディメンションがない場合は、どのような基準で分析されますか？

ファクトテーブルにプライマリキーのみがあり、外部キーがない場合はどうなりますか？

Answer 1

正確に言えば、外部キーはファクトテーブルをカテゴリとサブカテゴリに分割するテーブルにリンクします。

ファクトテーブルが

create table stores (id, kindOfStore, sales) 

たのであればその後kindOfStoreは、それはそれだった場合、その後、あなたはkindOfStoreのために別々のテーブルには、種類を言って無駄なスペースを除いて（やり過ぎであると主張することができ、あなたの無次元だろう店の代わりに「= 8 Kind_id」の=「食」。あなたは、サブカテゴリーをお持ちの場合はバラエティを格納するためのスペース効率の悪いスペース賢明な、専門だろう

create table kindOfStore (id, Variety, Specialization, Subspecialization) 

のように、それはdiminsionテーブルにリンクしても意味がファクトテーブルでのSubspecialization。

結果のスキーマはスタースキーマであり、データウェアハウスはこれらのスキーマを処理するように最適化されていますが、新しく高速なデータウェアハウスエンジンは非常に高速で、非スタースキーマでも非常に高速です。

DatawarehousesはOLTPデータベースと比較してファクトテーブルを非正規化（少ないテーブルを使用）していますが、決して単一のテーブルソリューションを目指す必要はありません。

Answer 2

良い設計では、すべてのテーブルにはプライマリキーがあります。

外部キーの使用は、テーブルの値を制約しようとしているものや方法によって異なります。より具体的な回答が必要な場合は、具体的な情報を提供してください。

Answer 3

Dimemnsionalモデリングは、その事実に余分な細部が含まれていることを意味し、有意義な要約情報に集約される属性を記述するように設計されています。これは、データウェアハウジング（主にREAD環境）の特徴ですが、OLTPの中では本当のトランザクションデータをモデリングすることもできます（金融取引、メモ、顧客墓石の改訂など、これらのすべてには、銀行口座の実体に共通のリンクがあります）。

TIMEとPLACEのディメンションは、通常、実際に掛かっている詳細のセットの中でプライムです。

あなたの事実が時間や空間に存在しない場合、それらの次元にはエントリがないと考えられます（私の人生は事実がそうであると分かりませんが）。

さらに、他の次元が小さく、含まれている（つまり、他の事実を共有していないことを意味する）場合、それらをENUMとして元のファクトテーブルにローリングさせることができます。

最終結果は、単一のファクトテーブルであり、複数の小さな次元がENUMSとして表されます。

しかし、本当に奇妙なデータの場合、非常に奇妙なケースです...

Answer 4

私が思い出すことのできるのは、ディメンションの一覧表示のための属性を含むテーブルを使用し、ツールがファクトテーブルとしてテーブルまたはエイリアスを設定/フラグ/識別する必要があることです。

営業データベースを想像してみてください。機会テーブルには長い属性リストが含まれています。あなたの顧客は、「私はすべての機会名、ID、そしてオーナーに割り当てられた人々のリストを入手したい」と言っています...そして論理的なデザインで別名や同義語を作成したり、同じテーブルをマップすることができます。

縮退したディメンションは別のケースかもしれません... ...テーブルは実際のファクトテーブルですが、提供される機能はほぼ同じですね。