如何創建可為空的“父”層次結構級別？
我正在使用 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]屬性可以為空；DSV 在 a[Materials]和[PriceCodes]table 之間有一個 FK，並且[Materials].[PriceCodeId]可以為空。**有沒有辦法仍然定義一個可以為空的屬性是父級的層次結構？**我擺弄了UnkownMember和UnknownMemberName以及屬性鍵的NullProcessing設置，但無法獲得要處理的維度。
如果有人可以通過基於業務鍵（即
Code欄位；自然鍵包括EffectiveTo欄位，null用於記錄的目前圖像）製作層次結構級別來確認我是否正確處理了緩慢變化的維度問題，則加分，並將 SCD 元數據視為其自身的一個級別。
您實際上在一個問題中有兩個問題。如果您為屬性創建一個新問題，它會更整潔，我將剪切/粘貼其中的一半作為答案:)
可空父級別
您可能不希望
NULLOLAP 維度中有 s，Kimball似乎也同意。當我們無法在有效維度行中為維度屬性提供值時，也應避免使用空值。維度屬性的值可能不可用的原因有多種：
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流程和數據倉庫，或者您應該如何處理它們，但是有不同類型的“未找到”。考慮一下外鍵的區別，一個有一個空欄位，另一個有一個已填充但無法（或不再）找到相關記錄的欄位。我喜歡區分我
BLANK的DATA ERROR維度。在您的範例中，您可以區分“無價格程式碼”和“我再也找不到的價格程式碼”
如果您有一個
ETL帶有數據倉庫的流程，您可以在流程中輕鬆處理該ETL流程，如果沒有，您將需要在 DSV 查詢中使用一些案例語句。*這個問題似乎揭示了底層數據倉庫的問題。*有支持和反對星型和雪花模式的爭論，但我個人傾向於星型模式，必要時混合一些雪花。
在任何情況下，數據清理和失去的連結都需要在您到達 dsv 之前很久就在您的數據倉庫中解決。
漸變維度屬性
關於您的
Slowly Changing Dimension，我看不到您維度中的層次結構或鍵的數據類型會如何變化，因為維度不知何故是SCD，這根本不重要。您只需要在您的 ETL 中某處有一個有效規則，該規則會被您的 SSAS 維度定義拾取（請參閱此處）。但是對於dimension key您創建的任何內容，我建議您使用代理鍵，主要是因為您的代理鍵可以是int或bigint代替 varchar，即使對於屬性鍵也可以大大提高性能。使用數字鍵列而不是字元串鍵列或複合鍵將提高包含許多成員的屬性的性能。此最佳實踐基於與在關係表中使用代理鍵以實現更有效的索引相同的概念。您可以將數字代理列指定為鍵列，但仍使用字元串列作為名稱列，以便屬性成員對最終使用者顯示相同。作為準則，如果屬性的成員超過一百萬，則應考慮使用數字鍵。
當然，該數字鍵將是“屬性”的表示，不一定包括有效性欄位。記錄的有效性在您的維度表中的記錄中指定，但正如您所說，您的屬性鍵不是必需的。
例如，這可能是您的維度數據
+---------------+-------+-----------+----------+ | DIMENSION_KEY | NAME | NAME_KEY | CURRENT | +---------------+-------+-----------+----------+ | 1 | tom | 1 | y | | 2 | mat | 2 | n | | 3 | mat | 2 | y | +---------------+-------+-----------+----------+您可以在其中選擇 dimension_key 作為您的鍵，
key attribute您可以選擇 name 或 name_key 作為name屬性的鍵。確定是否值得麻煩
name取決於您的屬性將擁有多少成員（並且您的關鍵屬性通常具有大多數成員）。
SCD最後，您擁有 a 的事實與您決定哪個鍵是您的屬性的好選擇之間沒有任何關係。最終使用者要求為您做出決定。在範例維度中，您希望在 mat 下報告所有按 mat 的銷售額，並且當使用者報告時，您的成員中沒有 2 個 mat。