だから、私はディメンションに何を入れるか、ファクトテーブルに何を入れるか、そしてこれをどのように達成するかを理解したと思います。ここで、このディメンション「product」とディメンション「productProperties」があるという問題が発生しました。これを分割する必要がありました。そうしないと、「製品」の自然キーが一意でなくなります。私は この質問でこれを尋ねました。
したがって、私の「productProperties」ディメンションテーブルは次のようになっているはずです。素材| サイズ
1.）これを実現するには、「色」、「素材」、「サイズ」などの値の可能なすべての順列を作成する必要がありました。
これは2億行をはるかに超えていたので、これを分割することにしました。現在、ディメンション「Color」があります。これは、実際には「color」、「colorFront」、「colorBack」の列で構成されています。
2.）それは問題ないと思いますが、「surrogate_key」列と「value」列のみで構成されるディメンション「size」についてはどうでしょうか。
私は（他の質問で与えられた読み方の推奨事項で）「縮退ディメンション」について読みました。これは、ファクトテーブルの「単一列ディメンション」を1列にすることを意味します。ファクトテーブルに約5〜6の余分な列が追加されるため、これは私には少し実用的ではないようです。
これを行う必要がある場合はどうなりますか？
3.）これらの縮退したディメンションはファクトテーブルの主キーの一部ですか？
最も重要な質問：ファクトテーブルに製品のエントリがありますが、ディメンションのすべての列に一致しないか、すべてのディメンションにまったく一致しません。つまり、「color」プロパティを持つエントリ/製品がある可能性がありますが、「colorFront」または「colorBack」はありません。'color'、'colorFront'、および'colorBack'のすべての順列を作成したので、ファクトテーブルにデータを入力しようとすると、製品にプロパティ'color'しかない場合、複数の代理キーが取得されます。ファクトテーブルでしょ？
4.）ファクトテーブルをクエリするときに、これらの重複を除外する必要がありますか？それともこれはまったく間違っていますか？
もちろん、次元「色」を3次元に分割することもできます。しかし、その後、いくつかの列にNULL値を持つエントリを取得します。一部の寸法をまったく使用しないエントリ/製品についても同じことが言えます。
5.）これらのNULL値を処理する方法は？
助けてくれてありがとう。
