ファクトテーブルの優先カラム数はありませんか？

Question

ポリシーデータを含むファクトテーブルを持っています&ポリシー製品の詳細を倉庫に追加します。 1つのポリシーは異なるタイプの製品を取得し、値も動的です。

例：Policy01には2つの製品Building &が含まれています。ここで合計保険額は1000 & 500です。そしてPolicy02は750の建物だけを取得します。

利用可能な商品は30種類ありますが、合計保険金額、ポリシーごとの各商品の総額は&です。 したがって、製品タイプごとに別々の列をファクト表に追加すると、ライブ120個の列が追加されます（現在は23列あります）。ポリシーごとに最大5つのプロダクトがあるので、20列には値が含まれます。&他は空のままです。

ファクトテーブルに100以上の列を持つことはできますか？これは、行の中に多くの空の値を保持してもよろしいですか？ これを解決できる他の方法はありますか？

私はDWHの初心者で、誰かが私のファクトテーブルにこれらの文字を追加する方法を教えてくれることを願っています。

Answer 1

一つのアプローチは、製品の次元を追加することです：

あなたは、ポリシーによって合計を返すことができます。

SELECT 
    PolicyKey 
    SUM(PolicyProductValue) AS PolicyValue 
FROM 
    Fact.PolicyProductValue 
GROUP BY 
    PolicyKey 
; 

または製品：

SELECT 
    ProductKey, 
    SUM(PolicyProductValue) AS ProductValue 
FROM 
    Fact.PolicyProductValue 
GROUP BY 
    ProductKey 
; 

または両方：

SELECT 
    PolicyKey, 
    ProductKey, 
    SUM(PolicyProductValue) AS PolicyProductValue 
FROM 
    Fact.PolicyProductValue 
GROUP BY 
    PolicyKey, 
    ProductKey 
; 

この方法では、製品を列から行に移動します。

この手法にはいくつかの利点があります。

1. 列よりも新しい行を追加することが容易です。
2. Dim.Productに一般的なフィルタを追加できます。
3. Dim.Productは、製品階層を作成する場所です。例：

| Product Key | Product Name | Product Group | | ----------- | ------------ | --------------------| | 0 | Building | Building & Contents | | 1 | Contents | Building & Contents |

Answer 2

それは、ファクトテーブル内の100の+の列を持ってしても大丈夫ではありません。間違ったデータモデルの症状です（欠落した値についても同じことですが、うまく設計されたファクトテーブルには何もありません）。

ファクトテーブルデザインのロジックは、次のとおりです。 最初に、「粒度」テーブルに含まれるデータの最も細かいレベルを判断します。あなたのケースでは、データ細分性はポリシー番号+製品によって定義されます。一緒に使用すると、利用可能な最も詳細な情報が一意に識別されます。

次に、「ファクト」を特定します。通常、ファクトは集計できるデータの一部です（合計、数、平均など）。あなたのケースでは、Insured_Value、Gross_Premium、Net_Premiumです。

最後に、これらのファクト（ディメンション）のビジネスコンテキストを定義します。あなたのケースでは、それらはポリシーと製品です（ほとんどの場合、ある種のDateもあります）。

あなたの結果のファクトテーブルは次のようなものになります。

• をPolicy_Date
• Policy_Number
• PRODUCT_ID
• Insured_Value
• Gross_Premium
• Net_Premium

Policy_Dateは「カレンダー」ディメンションへの接続を提供し、Product_IDは「Product」ディメンション（30個の製品とその説明を含むテーブル）に接続します。

ポリシーナンバーは、「縮退ディメンション」と呼ばれるものです。通常、ディメンションには接続されていないIDです（ただし、必要に応じて使用できます）。これはファクトテーブルにリファレンスとして格納されています。モデルに「ポリシー」ディメンションを追加する人もいますが、通常はデザインミスです。そのようなディメンションはファクトテーブルに匹敵する大きさで、モデルのパフォーマンスが大幅に低下する可能性があります。通常は、ポリシー属性を複数の小さな次元に分割し、ポリシー番号を縮退した次元にしておく方がよいでしょう。

したがって、5つの製品の標準ポリシーは、5つのフィールドを持つ1つのレコードではなく、ファクトテーブルの5つのレコードとして表されます。これは重要な違いです。ファクトテーブルフィールドの名前に情報（ケースの製品）を保存することは決してありません。