ファクト テーブルの説明などのテキスト フィールドを使用できる場合はありますか?
私は現在、日付、クライアント、場所などの多数のディメンションを持つ会議イベント (粒度: 会議ごとの行) のファクト テーブルを持っています。会議の件名をファクト テーブルに入れる必要があります。対策ではないのですが、これでいいのでしょうか（例は見たことがありません）。事実と常に同じサイズ (行数) になるため、別の次元に移動することはできません。
過去の経験からのアイデアやアドバイスはありますか？
ありがとう
5862 次
2 に答える
2
「縮退ディメンション」の形式で、テーブルを作成する必要がないほど重要でないディメンションを作成できます。一般的な例は請求書番号です。これらはメトリックではありませんが、非常に一意であるため、128ビットのCHAR（16）フィールドを持つ請求書テーブルに32ビットのFKを設定するのは誤った経済です。ファクトテーブルと同じ数のレコード。ファクトテーブルの行が広くなるため、これは慎重に行う必要があります。
縮退したディメンションが2つ以上ある場合は、通常、ジャンクディメンションの方が適しています。もちろん、代わりにテキストを合理的に添付できるディメンションがある場合は、それでもなお良いでしょう。
于 2012-03-02T23:22:18.173 に答える
1
あなたが説明していることは、ファクトテーブルではなく、他のディメンションから派生したディメンションのように聞こえます。私はこれを何度も行いました。主キーの構造、外部キーの組み合わせ、および名前を示す文字列列があります。例として、製品定義が思い浮かびます。配送場所（さまざまなルックアップが関連付けられている）は、別のものとして提供されます。
次の例を考えてみましょう。場所：フォートローダーデール、ウェストパームビーチ、マイアミ
各場所には、複数の配送場所がある場合があります。出荷場所には、梱包システム、コンベヤーベルトシステム、製品の重量範囲、集荷の種類など、さまざまな属性があります。これらはすべてルックアップテーブルにあります。
したがって、次の列を持つShippingLocationというテーブルがあります-ShippingLocationId（
PK）
-PackagingSystemId （FK）-ConveyorBeltTypeId（
FK
）-ProductWeightRangeId（FK）
-ShippingLocationName VarChar（200）
配送場所の名前が、配送場所が定義され、その属性が定義されているのと同じ場所にあることは、私には非常に論理的に思えます。ここで見られる唯一の可能な正規化は、1対1のテーブルにそれを取ることができるということです。IMO、それは役に立たない正規化です。
于 2009-06-25T21:49:57.497 に答える