null許容の「親」階層レベルを作成するにはどうすればよいですか？

Question

SSASを使用して最初のディメンションデータベースをセットアップしていますが、次のような階層を必要とする[Materials]ディメンションがあります。

[PriceCode    v] --> nullable
  Price Code
  ...
[Material     v]
  Code
  AltCode
  Name
  ...
[Id           v]  --> not actually exposed as a hierarchy level
  DateInserted
  DateUpdated
  DateDeleted
  EffectiveFrom
  EffectiveTo

問題は、[PriceCode]属性がNULL可能であるということです。 DSVには[Materials]テーブルと[PriceCodes]テーブルの間にFKがあり、[Materials].[PriceCodeId]はNULL可能です。

null許容属性が親である階層を定義する方法はありますか？UnkownMemberとUnknownMemberNameおよび属性キーのNullProcessing設定ですが、ディメンションを取得できませんでしたプロセスへ。

ビジネスキーに基づいて階層レベルを作成することにより、ゆっくりと変化するディメンションの問題に正しく取り組んでいるかどうかを誰かが確認できた場合のボーナスポイント（つまり、Codeフィールド;自然キーには、現在の画像のEffectiveToであるnullフィールドが含まれます。レコード）、およびSCDメタデータを独自のレベルとして扱います。

Answer 1

実際には、1つの質問に2つの質問があります。属性について新しい質問を作成すると、それはすっきりします。その答えとして、これの半分をカットアンドペーストします:)

NULL可能親レベル

おそらく、OLAPディメンション、およびKimball 同意するようです ）にNULLsを含めたくないでしょう。

有効なディメンション行のディメンション属性に値を指定できない場合も、ヌルを回避する必要があります。ディメンション属性の値が使用できない理由はいくつかあります。

Missing Value – The attribute was missing from the source data.
Not Happened Yet – The attribute is not yet available due to source system timing issues.
Domain Violation – Either we have a data quality issue, or we don’t understand all the business rules surrounding the attribute. The data provided by the source system is invalid for the column type or outside the list of valid domain values.
Not Applicable – The attribute is not valid for the dimension row in question.

ETLプロセスとデータウェアハウスがあるかどうかによって異なりますが、「見つからない」にはさまざまな種類があります。

外部キーの違いについて考えてみてください。1つには空のフィールドがあり、もう1つには入力されたフィールドがありますが、関連するレコードが見つかりません（または見つからなくなります）。私は自分の次元でBLANKとDATA ERRORを区別するのが好きです。

あなたの例では、「価格コードなし」と「私がもう見つけられない価格コード」を区別することができます

データウェアハウスでETLプロセスがある場合は、ETLプロセスで簡単に処理できます。必要がない場合は、DSVクエリでいくつかのcaseステートメントが必要になります。

この質問は、基盤となるデータウェアハウスの問題を明らかにしているようです。議論があります スタースキーマとスノーフレークスキーマの両方に賛成と反対 しかし、個人的にはスタースキーマを好む傾向があります、必要に応じてスノーフレークを混ぜます。
いずれの場合も、DSVに到達するずっと前に、データクレンジングと欠落しているリンクをデータウェアハウスで解決する必要があります。

ゆっくりと変化するディメンション属性

Slowly Changing Dimensionに関しては、ディメンションがSCDであるため、ディメンションの階層またはキーのデータ型がどのように変化するかわかりません。これはまったく問題ではありません。 SSASディメンション定義（ ここを参照 ）によって取得されるETLのどこかに有効性ルールが必要です。ただし、作成するdimension keyについては、 代理キー を使用することをお勧めします。これは主に、代理キーがvarcharの代わりにintまたはbigintになる可能性があるためです。 パフォーマンスを大幅に向上させる 属性キーの場合でも。

文字列キー列または複合キーの代わりに数字キー列を使用すると、多くのメンバーを含む属性のパフォーマンスが向上します。このベストプラクティスは、より効率的なインデックス作成のためにリレーショナルテーブルで代理キーを使用するのと同じ概念に基づいています。数値の代理列をキー列として指定し、文字列列を名前列として使用して、属性メンバーがエンドユーザーに同じように表示されるようにすることができます。ガイドラインとして、属性に100万を超えるメンバーがある場合は、数字キーの使用を検討する必要があります。

もちろん、その数字キーは「属性」の表現であり、必ずしも有効性フィールドが含まれているとは限りません。レコードの有効性は、ディメンションテーブルのレコードで指定されますが、指定したとおり、属性キーには必要ありません。

たとえば、これはディメンションデータである可能性があります

+---------------+-------+-----------+----------+
| DIMENSION_KEY |  NAME |  NAME_KEY |  CURRENT |
+---------------+-------+-----------+----------+
| 1             | tom   | 1         | y        |
| 2             | mat   | 2         | n        |
| 3             | mat   | 2         | y        |
+---------------+-------+-----------+----------+

key attributeのキーにdimension_keyを選択でき、name属性のキーとしてnameまたはname_keyのいずれかを選択できます。

nameの手間をかける価値があるかどうかの判断は、属性に含まれるメンバーの数によって異なります（通常、キー属性にはほとんどのメンバーが含まれます）。

結局、SCDを持っているという事実と、どのキーが属性に適しているかを決定することとの間には、実際には何の関係もありません。エンドユーザーの要件がその決定を下します。ディメンションの例では、マットごとのすべての売上をマットの下に報告し、ユーザーが報告するときにメンバーに2つのマットを含めないようにします。