ファクト テーブルにキーがまったくないことはありますか? またはそれができる場合、それは良いデザインですか？ファクト テーブルにディメンションがない場合、どのような基準で分析されますか?
ファクト テーブルに主キーのみがあり、外部キーがない場合はどうなりますか?
質問する
7150 次
4 に答える
2
不正確に言えば、外部キーは、ファクトテーブルをカテゴリとサブカテゴリに分割するテーブルにリンクします。
したがって、ファクトテーブルが
create table stores (id, kindOfStore, sales)
次に、kindOfStoreがディメンションになります。その場合、kindOfStoreの別のテーブルは過剰であると主張できます（「Kind_id=8」ではなく「kindofstore="Food」と言って無駄になるスペースを除く。サブカテゴリ、次のようなディメンションテーブルにリンクすることは理にかなっています
create table kindOfStore (id, Variety, Specialization, Subspecialization)
ファクトテーブルにVariety、Specialization、およびSubspecializationを格納することは、スペース的に非効率的なスペースになります。
結果として得られるスキーマはスタースキーマであり、データウェアハウスはこれらのスキーマを処理するように最適化されていますが、新しく高速なデータウェアハウスエンジンは非常に高速であるため、スター以外のスキーマでもかなり高速です。
データウェアハウスは、OLTPデータベースと比較してファクトテーブルを非正規化します（使用するテーブルが少なくなります）が、単一のテーブルソリューションを目指す必要があるという意味ではありません。
于 2009-06-25T19:48:44.213 に答える
2
次元モデリングは、ファクトに追加の詳細を追加できるように設計されており、「ロールアップ」して意味のある要約情報に集約できる属性を記述します。これはデータ ウェアハウジング (主に READ 環境) の特徴ですが、OLTP に配置することもでき、主要な事実 (金融取引、メモ、顧客のトゥームストーンの改訂など、銀行口座に対する取引を考えてみてください。これらはすべて、銀行口座エンティティに戻る共通のリンクを持っています)。
通常、事実から切り離された一連の詳細の中で重要なのは、時間と場所のディメンションです。
あなたの事実が時間または空間に存在しない場合、おそらくそれらの次元へのエントリなしで存在する可能性があります（ただし、事実がいつそのようになるかは、私の人生ではわかりませんが）.
さらに、他のディメンションが小さく含まれている場合 (他のファクトがそれらを共有していないことを意味します)、それらを ENUM として元のファクト テーブルにローリングすることで回避できます。
最終結果は、ENUMS として表される複数の小さなディメンションを持つ単一のファクト テーブルになります。
しかし、本当に奇妙なデータの場合、それは非常に奇妙なケースになるでしょう...
于 2009-06-25T19:59:44.693 に答える
0
優れた設計では、すべてのテーブルに主キーがあります。
外部キーの使用は、テーブルの値を何/どのように制約しようとしているかによって異なります。より具体的な回答が必要な場合は、状況に関するより具体的な情報を提供してください
于 2009-06-25T19:35:50.230 に答える
0
私が思い出すことができるケースは、ディメンション リストの目的で属性を含むテーブルを使用し、ツールがテーブルまたはエイリアスをファクト テーブルとして設定/フラグ付け/識別する必要がある場合です。
営業データベースを想像してみてください。商談テーブルには長い長い属性のリストが含まれていますよね? あなたの顧客は、「すべての商談名、ID、および商談所有者として割り当てられた人のリストを取得したい」と言います... 次に、エイリアスまたはシノニムを作成するか、論理設計で同じテーブルをマップできます。
縮退したディメンションは別のケースかもしれません...テーブルは実際のファクトテーブルですが、提供される機能はほとんど同じですよね?
于 2009-07-09T21:19:12.043 に答える