了解星型結構描述及其對 Power BI 的重要性

本文適用於 Power BI Desktop 資料模型製作人員。 它描述星型架構設計及其與開發針對效能和可用性優化的Power BI語意模型相關性。

星型結構描述概觀

星型結構描述是關聯式資料倉儲普遍採用的成熟模型化方法。 模型製作人員必須將其模型資料表分類為「維度」或「事實」。

維度數據表

維度資料表會描述商務實體，也就是您模型化的「事物」。 這些實體可以是產品、人員、地點和概念 (包括時間本身)。 您會在星型結構描述中找到的最一致資料表是日期維度資料表。 維度數據表包含索引鍵數據行（或數據行），做為唯一標識元和其他數據行。 其他數據行支援篩選和分組您的數據。

事實數據表

事實數據表 會儲存觀察或事件，而且可以是銷售訂單、庫存餘額、匯率、溫度等等。 事實資料表包含與維度資料表和數值量值資料行相關的維度索引鍵資料行。 維度索引鍵資料行會決定事實資料表的維度，而維度索引鍵值則決定事實資料表的資料細微性。 例如，假設有一個事實數據表，其設計目的是儲存具有兩個維度索引鍵 Date 數據行和 ProductKey的銷售目標。 您輕易就能了解資料表具有兩個維度。 不過，如果不考慮維度索引鍵值，就無法判斷資料粒度。 在此範例中，請考慮儲存在數據行中的 Date 值是每個月的第一天。 在此案例中，資料粒度是在每月產品層級。

一般而言，維度資料表包含的資料列數目相對較少。 另一方面，事實數據表可以包含大量的數據列，並繼續隨著時間成長。

正規化與反正規化

若要瞭解本文所述的一些星型結構描述概念，請務必瞭解兩個詞彙：正規化和反正規化。

「正規化」一詞用來描述以減少重複資料的方式儲存的資料。 請考慮具有唯一索引鍵值數據行的產品數據表，例如產品索引鍵，以及其他描述產品特性的數據行，例如產品名稱、類別、色彩和大小。 當銷售資料表只儲存金鑰 (例如產品金鑰) 時，其會被視為正規化。 在下圖中，請注意，只有數據 ProductKey 行會記錄產品。

不過，如果銷售資料表儲存索引鍵之外的產品詳細資料，則會被視為反正規化。 在下圖中，請注意 ProductKey ，和其他產品相關數據行會記錄產品。

當您以匯出檔案或資料擷取作為資料來源時，它可能代表非正規化的資料集。 在此情況下，使用 Power Query 將來源資料轉換成多個正規化資料表。

如本文所述，您應該努力使用代表正規化事實和維度數據的數據表來開發優化的Power BI語意模型。 不過，有一個例外狀況是 雪花維度 可能會反正規化，以產生單一模型數據表。

與 Power BI 語意模型的星型架構相關性

星型結構描述設計及本文介紹的許多相關概念，都與開發針對效能和可用性最佳化的 Power BI 模型高度相關。

請考慮每個Power BI報表視覺效果都會產生傳送至Power BI語意模型的查詢。 一般而言，查詢會篩選、分組和摘要模型數據。 設計良好模型會提供用於篩選和群組的資料表，以及用於摘要的資料表。 此設計相當符合星型結構描述原則：

• 維度數據表可啟用 篩選 和 分組。
• 事實數據表會啟用 摘要。

沒有模型工具設定為將數據表類型設定為維度或事實的數據表屬性。 其實是由模型關聯性所決定。 模型關聯性會建立兩個數據表之間的篩選傳播路徑，而它是決定數據表類型之關聯性的基數屬性。 常見的關聯性基數包括「一對多」或相反的「多對一」。 「一」端一律是維度數據表，而「多」端一律是事實數據表。

結構良好的模型設計包含維度數據表或事實數據表的數據表。 請避免將這兩種類型混合成單一資料表。 我們也建議您努力提供正確的數據表數目，並就地提供正確的關聯性。 事實數據表一律以一致的粒紋載入數據也很重要。

最後，請務必了解最佳模型設計既是一門科學，也是一門藝術。 有時您可以在合理情況下背離良好的指引。

有許多與星型架構設計相關的概念可以套用至 Power BI 語意模型。 這些概念包含：

• 量值
• Surrogate 索引鍵
• 雪花式維度
• 角色扮演維度
• 緩時變維度
• 雜項維度
• 變質維度
• 非事實資料表

量值

在星型結構描述設計中，量值是一個事實資料表資料行，用來儲存要摘要的值。 在 Power BI 語意模型中，量值有不同的定義，但類似。 模型同時支持明確和隱含量值。

• 明確量值是明確建立的，而且是以以數據分析表達式 （DAX） 撰寫的公式為基礎，可達成摘要。 量值表達式通常會使用 、SUM、MIN、 MAX和其他等AVERAGE的 DAX 聚合函數，在查詢時間產生純量值結果（值永遠不會儲存在模型中）。 量值運算式範圍可以從簡單的資料行彙總，到覆寫篩選內容及/或關聯性傳播的更複雜公式。 如需詳細資訊，請參閱 Power BI Desktop 中的 DAX 基本概念。
• 隱含量值 是報表視覺效果或 Q&A可以摘要的數據行。 它們提供您作為模型開發人員的便利，因為在許多情況下，您不需要建立 （明確） 量值。 例如，Adventure Works 轉銷商銷售 Sales Amount 數據行可以以多種方式摘要（總和、計數、平均值、中位數、最小值、最大值等），而不需要為每個可能的匯總類型建立量值。

在 [ 數據 ] 窗格中，明確量值會以計算機圖示表示，而隱含量值則以 sigma 符號 （∑） 表示。

不過，您可能建立量值的原因有三個令人信服的原因，即使是針對簡單的數據行層級摘要：

• 當您知道報表作者會使用 多維度表達式 （MDX） 查詢語意模型時，模型必須包含明確的量值。 這是因為 MDX 無法達到資料行值的摘要。 值得注意的是，在 Excel 中執行分析時會使用 MDX，因為數據透視表會發出 MDX 查詢。

• 當您知道報表作者會使用 MDX 查詢設計工具建立 Power BI 編頁報表時，語意模型必須包含明確的量值。 只有 MDX 查詢設計工具支援伺服器彙總。 因此，如果報表作者需要以 Power BI (而非由編頁報表引擎評估) 來評估量值 ，則必須使用 MDX 查詢設計工具。

• 當您想要控制報表作者如何以特定方式摘要數據行時。 例如，可以摘要轉銷商銷售 Unit Price 數據行（代表每單位費率），但只能使用特定的聚合函數。 它不應該加總，但應該使用其他聚合函數來摘要，例如min、max或 average。 在此實例中，模型工具可以隱藏數據 Unit Price 行，併為所有適當的聚合函數建立量值。

  這種設計方法相當適用於在 Power BI 服務中撰寫的報表，以及問與答。 不過，Power BI Desktop 即時連線 可讓報表作者在 [ 數據 ] 窗格中顯示隱藏字段，這可能會導致規避此設計方法。

Surrogate 索引鍵

Surrogate 索引鍵是您新增至資料表以支援星型結構描述模型的唯一識別碼。 根據定義，它不會定義或儲存在來源資料中。 Surrogate 索引鍵通常會新增至關聯式資料倉儲維度資料表，來為每個維度資料表資料列提供唯一識別碼。

Power BI 語意模型關聯性是以一個數據表中的單一唯一數據行為基礎，它會將篩選傳播至不同數據表中的單一數據行。 當您語意模型中的維度數據表不包含單一唯一數據行時，您必須新增唯一標識符，才能成為關聯性的「一」端。 在 Power BI Desktop 中，您可以藉由新增 Power Query 索引數據行來達成這項需求。

您必須將此查詢與「多」端查詢合併，讓您也可以在其中新增索引資料行。 當您將這些查詢載入語意模型時，就可以在模型數據表之間建立一對多關聯性。

雪花式維度

雪花式維度是單一商務實體的一組正規化資料表。 例如，Adventure Works 會依照類別和子類別分類產品。 產品會指派給子類別，而子類別會轉而指派給類別。 在 Adventure Works 關聯式資料倉儲中，已將產品維度標準化並儲存至三個相關資料表：DimProductCategory、DimProductSubcategory 和 DimProduct。

如果您運用想像力，可以想像正規化資料表是從事實資料表朝外形成雪花式設計。

在 Power BI Desktop 中，您可以選擇模擬雪花式維度設計（可能是因為源數據確實有），或合併源數據表以形成單一反正規化模型數據表。 一般來說，單一模型資料表優點超過多個模型資料表的優點。 最佳決策可能取決於資料量和模型的可用性需求。

當您選擇模擬雪花式維度設計時：

• Power BI 會載入更多資料表，從儲存空間和效能的觀點來看，這會降低效率。 這些資料表必須包含支援模型關聯性的資料行，因此可能導致更大的模型大小。
• 需要周遊較長的關聯性篩選傳播鏈結，這可能比套用至單一數據表的篩選效率低。
• [ 數據 ] 窗格會將更多模型數據表呈現給報表作者，這可能會導致較不直覺的體驗，特別是當雪花維度數據表只包含一或兩個數據行時。
• 您無法建立包含多個資料表之數據行的階層。

當您選擇整合成單一模型資料表時，您也可以定義階層來包含維度的最高和最低資料粒度。 可能的話，備援反正規化數據的儲存可能會導致模型記憶體大小增加，特別是針對大型維度數據表。

緩時變維度

緩時變維度 （或 SCD） 是適當管理一段時間維度成員變更的維度。 當商務實體值 以非計劃的方式變更緩慢 時，就會套用。 SCD 的良好範例是客戶維度，因為其聯繫人詳細數據行，例如電子郵件地址和電話號碼不常變更。 相反地，當維度屬性經常變更時，某些維度會被視為 快速 變更，例如股票的市場價格。 這些實例中的常見設計方法是將快速變更的屬性值儲存在事實資料表量值中。

星型結構描述設計理論是指兩個常見的 SCD 類型：類型 1 或類型 2。 維度數據表可以是類型 1 或 Type 2，或同時支援不同數據行的這兩種類型。

類型 1 SCD

類型 1 SCD 一律會反映最新的值，當偵測到來源資料中的變更時，便會覆寫維度資料表的資料。 此設計方法適用于儲存補充值的資料行，例如客戶的電子郵件地址或電話號碼。 當客戶電子郵件地址或電話號碼變更時，維度資料表會以新的值更新客戶資料列。 就好像客戶總是有此連絡資訊一樣。

Power BI 模型維度數據表的非累加式重新整理可達成類型 1 SCD 的結果。 它會重新整理資料表資料，以確保載入最新的值。

類型 2 SCD

類型 2 SCD 支援維度成員的版本設定。 如果來源系統未儲存版本，通常是數據倉儲載入程式，可偵測變更並適當地管理維度數據表中的變更。 在此情況下，維度資料表必須使用 Surrogate 索引鍵來提供維度成員「版本」的唯一參考。 它也包含定義版本日期範圍有效性的資料行 (例如，StartDate 和 EndDate)，以及可能由目前維度成員輕鬆篩選的旗標資料行 (例如，IsCurrent)。

例如，Adventure Works 會將每個銷售人員指派給銷售區域。 當銷售人員重新放置區域時，必須建立新版本的銷售人員，以確保歷史事實仍與前一個區域相關聯。 為支援銷售人員對銷售的精確歷史分析，維度資料表必須儲存銷售人員及其相關區域的版本。 資料表也應該包含開始和結束日期值，以定義時間有效性。 目前的版本可能會定義空的結束日期（或 12/31/9999），這表示數據列是目前版本。 數據表也必須有代理密鑰，因為業務密鑰（在此實例中為員工標識元）不會是唯一的。

請務必瞭解，當來源資料未儲存版本時，您必須使用中繼系統 (例如資料倉儲) 來偵測和儲存變更。 資料表載入程序必須保留現有的資料並偵測變更。 偵測到變更時，資料表載入程序必須使目前的版本過期。 它會藉由更新 EndDate 值，並使用從先前 StartDate 值開始的 EndDate 值插入新版本，以記錄這些變更。 此外，相關事實必須使用以時間為基礎的查閱來擷取與事實日期相關的維度索引鍵值。 Power BI 語意模型使用 Power Query，因此無法產生此結果。 不過，它可以從預先載入的 SCD 類型 2 維度資料表載入資料。

不論變更為何，Power BI 語意模型都應該支援查詢成員的歷史數據，以及成員版本的查詢，該版本代表成員的特定狀態。 在 Adventure Works 的內容中，此設計可讓您查詢銷售人員 (不論指派的銷售區域)，或特定銷售人員版本。

若要達到此需求，Power BI 語意模型維度數據表必須包含用來篩選銷售人員的數據行，以及篩選特定銷售人員版本的不同數據行。 版本資料行必須提供非模棱兩可的描述，例如 David Campbell (12/15/2008-06/26/2019) 或 David Campbell (06/27/2019-Current)。 也請務必教育報表作者和取用者關於 SCD 類型 2 的基本概念，以及如何藉由套用正確篩選來達成適當的報表設計。

最好是包含階層，可讓視覺效果向下切入至版本層級。

角色扮演維度

角色扮演維度是可利用不同方式篩選相關事實的維度。 例如，在 Adventure Works 中，日期維度數據表與轉銷商銷售事實有三個關聯性。 您可以使用相同的維度資料表，依訂單日期、出貨日期或交貨日期來篩選事實。

在資料倉儲中，接受的設計方法是定義單一日期維度資料表。 在查詢時，日期維度「角色」是由您用來聯結資料表的事實資料行所建立。 例如，當您依訂單日期分析銷售時，資料表聯結會與轉售商銷售訂單日期資料行相關聯。

在 Power BI 語意模型中，建立兩個數據表之間的多個關聯性，即可模擬此設計。 在 Adventure Works 範例中，日期和轉售商銷售資料表會有三個關聯性。

雖然此設計可行，但兩個 Power BI 語意模型數據表之間只能有一個 作用 中關聯性。 其餘所有關聯性都必須設定為非作用中。 具有單一作用中關聯性表示有從日期到轉銷商銷售的預設篩選傳播。 在此實例中，作用中關聯性會設定為報表所使用的最常見篩選，在 Adventure Works 是順序日期關聯性。

非作用中的關聯性只會用來定義使用 USERELATIONSHIP 函式的 DAX 運算式。 在我們的範例中，模型開發人員必須建立量值，依出貨日期和交貨日期來進行轉售商銷售分析。 這項工作可能很繁瑣，特別是當轉售商資料表定義許多量值時。 它也會建立雜亂的數據窗格，其量值過大。 還有其他限制：

• 當報表作者依賴摘要數據行而不是定義量值時，它們無法達到非作用中關聯性的摘要，而不需要撰寫報表層級量值。 只有在 Power BI Desktop 中撰寫報表時，才能定義報表層級量值。
• 由於日期與轉售商銷售之間只有一個作用中的關聯性路徑，因此無法同時依不同日期類型來篩選轉售商銷售。 例如，您無法產生依出貨銷售量繪製訂單日期銷售量的視覺效果。

為了克服這些限制，常見的Power BI模型化技術是為每個角色扮演實例建立維度數據表。 您可以使用 Power Query 建立每個維度數據表作為 參考查詢 ，或使用 DAX 建立計算數據表 。 此模型可以包含 Date 數據表、 Ship Date 數據表和 Delivery Date 數據表，每個數據表都有與其個別轉銷商銷售數據表數據行的單一和作用中關聯性。

這種設計方法不需要您針對不同日期角色定義多個量值，它可讓您同時依不同日期角色進行篩選。 不過，使用此設計方法支付的次要價格是，日期維度數據表將會重複，導致模型儲存大小增加。 因為維度數據表通常會相對於事實數據表儲存較少的數據列，所以很少擔心。

建議您針對每個角色建立模型維度數據表時，遵循良好的設計作法：

• 確定資料行名稱是自我描述的。 雖然所有日期數據表中都有一個數據行（數據行名稱在其數據表中是唯一 Year 的），但預設不會自我描述視覺效果標題。 請考慮重新命名每個維度角色數據表中的數據行，讓 Ship Date 數據表有名為 Ship Year的年份數據行等等。
• 相關時，請確定數據表描述會提供意見反應給報表作者（透過 數據 窗格工具提示），以瞭解篩選傳播的設定方式。 當模型包含泛型具名數據表時，這個明確性很重要，例如 Date，用來篩選許多事實數據表。 例如，如果此數據表具有與轉銷商銷售訂單日期數據行的作用中關聯性，請考慮提供類似的 Filters reseller sales by order date數據表描述。

如需詳細資訊，請參閱作用中與非使用中關聯性指引。

雜項維度

雜項維度適用於有許多維度 (特別是由幾個屬性或可能一個屬性所組成)，且這些屬性有幾個值的情況。 良好的候選專案包括訂單狀態數據行，或客戶人口統計數據行，例如性別或年齡群組。

垃圾維度的設計目標是將許多 小型 維度合併成單一維度，以減少模型儲存大小，並藉由顯示較少的模型數據表來減少 數據 窗格雜亂。

垃圾維度數據表通常是所有維度屬性成員的笛卡兒乘積，具有可唯一 識別每個數據列的 Surrogate 索引鍵 數據行。 您可以在資料倉儲中建置此維度，或使用 Power Query 建立執行完整外部查詢聯結的查詢，再新增 Surrogate 索引鍵 (索引資料行)。

您可以將此查詢載入模型作為維度數據表。 您也需要將此查詢與事實查詢合併，以便將索引數據行載入模型，以支援建立「一對多」模型關聯性。

變質維度

變質維度是指篩選所需的事實數據表屬性。 在 Adventure Works，轉售商銷售訂單號碼就是一個很好的例子。 在此實例中，建立只包含這個數據行的獨立數據表並不合理，因為它會增加模型記憶體大小，並導致 [數據 ] 窗格雜亂。

在 Power BI 語意模型中，您可以將銷售訂單號碼數據行新增至事實數據表，以允許依銷售訂單號碼進行篩選或分組。 這是先前引進的規則的例外，您不應該混合數據表類型（一般而言，模型數據表應該是維度或事實）。

不過，如果 Adventure Works 轉銷商銷售數據表具有訂單號碼 和 訂單明細編號數據行，而且篩選時需要它們，則建立變質維度數據表將是一個很好的設計。 如需詳細資訊，請參閱一對一關聯性指導方針 (變質維度)。

非事實資料表

非事實資料表不包含任何量值資料行。 它只包含維度索引鍵。

非事實資料表可以儲存維度索引鍵所定義的觀察。 例如，在特定日期和時間，特定客戶登入您的網站。 您可以定義量值來計算無事實事實數據表的數據列，以執行客戶登入的時機和數目的分析。

更引人注目地使用無事實數據表是儲存維度之間的關聯性，而這是我們建議用來定義多對多維度關聯性的 Power BI 語意模型設計方法。 在多對多維度關聯性設計中，非事實資料表稱為「橋接資料表」。

例如，假設銷售人員可以指派給一「或多個」銷售區域。 橋接資料表設計成由兩個資料行所組成的非事實資料表：銷售人員索引鍵和區域索引鍵。 這兩個資料行中都可以儲存重複的值。

此多對多設計方法已妥善記載，且可以在沒有橋接資料表的情況下達成。 不過，橋接資料表方法被視為關聯兩個維度時的最佳做法。 如需詳細資訊，請參閱多對多關聯性指導方針 (建立兩個維度類型資料表的關聯)。

相關內容

如需星型架構設計或Power BI語意模型設計的詳細資訊，請參閱下列文章：

• Dimensional modeling (維度模型) Wikipedia 文章
• Power BI Desktop 中的模型關聯性
• 一對一關聯性指導方針
• 多對多關聯性指引
• 雙向關聯性指導方針
• 作用中與非作用中關聯性指導方針
• Microsoft Fabric 倉儲中的維度模型化
• 有任何問題嗎？ 嘗試詢問網狀架構社群
• 有任何建議嗎？ 參與改善網狀架構的想法