さまざまな種類の受取人に支払いを行っていますが、各種類の受取人のディメンションを作成してファクト テーブルに複数の外部キーを設定するか、type 属性を介してさまざまな種類の受取人を統合し、単一の FK を使用するかを考えています。 PayeeDim.Type の特定の値に対して PayeeDim テーブルで意味をなさない属性を持つことを犠牲にして、PaymentFact テーブルで...
これらの状況は通常どのように処理されますか?
TIA-e
さまざまな種類の受取人に支払いを行っていますが、各種類の受取人のディメンションを作成してファクト テーブルに複数の外部キーを設定するか、type 属性を介してさまざまな種類の受取人を統合し、単一の FK を使用するかを考えています。 PayeeDim.Type の特定の値に対して PayeeDim テーブルで意味をなさない属性を持つことを犠牲にして、PaymentFact テーブルで...
これらの状況は通常どのように処理されますか?
TIA-e
次元モデリングの場合と同様に、答えは「場合による」です。代替手段が 15 ~ 20 のディメンションを持つファクト テーブルである場合は、通常、多数の空の属性を持つディメンションを使用することをお勧めします。
ビジネスにとって、受取人が受取人であり、複数の受取人タイプがある場合、受取人次元を持つことは理にかなっています。しかし、1 つの支払いレコードを複数の異なる「タイプ」の受取人に関連付けることができる場合は、各ディメンションが事実に関する独自のキーを取得する必要があります。
1 つのオプションは、2 つのディメンションを使用することです。1 つは Payee 情報を含み、もう 1 つは Payee_Type 情報を含みます。