瞭解星型架構和Power BI的重要性

  • 發行項

本文以 Power BI Desktop 數據模型工具為目標。 它描述星型架構設計，以及其與開發針對效能和可用性優化的Power BI資料模型相關。

本文並非旨在提供星型架構設計的完整討論。 如需詳細資訊，請參閱 Ralph Kimball 等已發佈的內容，例如 數據倉儲工具組：維度模型 化的最終指南（第 3 版，2013 年）。

星型架構概觀

星型架構 是關係型數據倉儲廣泛採用的成熟模型化方法。 它需要模型化工具將其模型數據表分類為 維度 或 事實。

維度數據表 會描述商務實體，也就是 您建立模型的專案 。 這些實體可以是產品、人員、地點和概念 (包括時間本身)。 您在星型架構中找到的最一致數據表是日期維度數據表。 維度數據表包含索引鍵數據行（或數據行）作為唯一標識碼，以及描述性數據行。

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

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

影像顯示星型架構的圖例。

正規化與反正規化

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

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

影像顯示包含產品金鑰數據列的數據數據表。

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

影像顯示包含產品金鑰和其他產品相關數據行的數據表，包括類別、色彩和大小。

當您從導出檔案或數據擷取源數據時，它可能代表非正規化數據集。 在此情況下，使用 Power Query 將源數據轉換成多個正規化數據表，並將其塑造成多個標準化數據表。

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

與 Power BI 模型相關的星型架構

星型架構設計和本文中導入的許多相關概念，與開發針對效能和可用性優化的Power BI模型高度相關。

假設每個Power BI報表視覺效果都會產生傳送至Power BI模型的查詢（Power BI 服務呼叫語意模型，先前稱為數據集）。 這些查詢可用來篩選、分組和摘要模型數據。 然後，設計良好的模型是一個提供用於篩選和分組的數據表，以及用於摘要的數據表。 此設計非常適合星型架構原則：

  • 維度數據表支持 篩選 和 分組
  • 事實數據表支援 摘要

沒有模型工具設定為將數據表類型設定為維度或事實的數據表屬性。 其實是由模型關聯性所決定。 模型關聯性會建立兩個數據表之間的篩選傳播路徑，而它是 決定數據表類型之關聯性的基數 屬性。 常見的關聯性基數是 一對多 或其反向 多對一。 「一」端一律是維度類型數據表，而「多」端一律是事實類型數據表。 如需關聯性的詳細資訊，請參閱 Power BI Desktop 中的模型關聯性。

影像顯示星型架構的概念圖例。

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

最後，請務必瞭解最佳模型設計是部分科學和部分藝術。 有時候，當這樣做很合理時，您可以中斷良好的指引。

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

量值

在星型架構設計中， 量值 是儲存要摘要之值的事實數據表數據行。

在 Power BI 模型中， 量值 有不同的定義，但類似。 這是以數據分析表達式 （DAX） 撰寫 的公式， 可達成摘要。 量值表達式通常會利用 SUM、MIN、MAX、AVERAGE 等 DAX 聚合函數，在查詢時間產生純量值結果（值永遠不會儲存在模型中）。 量值表達式的範圍可以從簡單的數據行匯總到更複雜的公式，以覆寫篩選內容和/或關聯性傳播。 如需詳細資訊，請參閱 Power BI Desktop 中的 DAX 基本概念一文。

請務必瞭解 Power BI 模型支援第二個方法來達成摘要。 任何數據行，通常是數值數據行，都可以由報表視覺效果或Q&A摘要。 這些數據行稱為 隱含量值。 它們提供您作為模型開發人員的便利，因為在許多情況下，您不需要建立量值。 例如，Adventure Works 轉銷商銷售 金額 數據行可以以多種方式摘要（總和、計數、平均值、中位數、最小值、最大值等），而不需要為每個可能的匯總類型建立量值。

影像顯示 [欄位] 窗格中找到的圖示。

不過，您有三個令人信服的理由可以建立量值，即使是簡單的數據行層級摘要：

  • 當您知道報表作者會使用 多維度表達式 （MDX） 查詢模型時，模型必須包含 明確的量值。 明確量值是使用 DAX 來定義。 使用 MDX 查詢 Power BI 數據集時，這個設計方法非常相關，因為 MDX 無法達到數據行值的摘要。 值得注意的是，MDX 會在執行 [在 Excel 中進行分析] 時使用，因為數據透視表會發出 MDX 查詢。
  • 當您知道報表作者會使用 MDX 查詢設計工具建立 Power BI 編頁報表時，模型必須包含明確的量值。 只有 MDX 查詢設計工具支援 伺服器匯總。 因此，如果報表作者需要有Power BI評估的量值（而不是編頁報表引擎），則必須使用 MDX 查詢設計工具。
  • 當您需要確保報表作者只能以特定方式摘要數據行時。 例如，轉銷商銷售 單價 數據行（代表每單位費率）可以摘要，但只能使用特定的匯總函數。 它不應該加總，但應該使用其他聚合函數來摘要，例如min、max、average等。在此實例中，模型工具可以隱藏 單價 數據行，併為所有適當的聚合函數建立量值。

此設計方法適用於在 Power BI 服務和Q&A中撰寫的報表。 不過，Power BI Desktop 即時連線可讓報表作者在 [ 欄位 ] 窗格中顯示隱藏欄位，這可能會導致規避此設計方法。

Surrogate 索引鍵

Surrogate 索引鍵是您新增至數據表以支援星型架構模型化的唯一標識符。 根據定義，它不會定義或儲存在源數據中。 通常，代理索引鍵會新增至關係型數據倉儲維度數據表，以提供每個維度數據表數據列的唯一標識符。

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

影像顯示 Power Query 編輯器 中的 [建立索引數據行] 命令。

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

雪花尺寸

雪花式維度是單一商務實體的一組標準化數據表。 例如，Adventure Works 會依照類別和子類別分類產品。 產品會指派給子類別，而子類別則會接著指派給類別。 在 Adventure Works 關係型數據倉儲中，產品維度會正規化並儲存在三個相關數據表中：DimProductCategory、DimProductSubcategory 和 DimProduct。

如果您使用想像，可以圖片從事實數據表向外放置的標準化數據表，形成雪花設計。

影像顯示由三個相關數據表組成的雪花圖範例。

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

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

  • Power BI 會載入更多數據表，從記憶體和效能的觀點來看較不有效率。 這些數據表必須包含數據行以支援模型關聯性，而且可能會導致較大的模型大小。
  • 需要周遊較長的關聯性篩選傳播鏈結，這可能會比套用至單一數據表的篩選效率低。
  • [ 欄位 ] 窗格向報表作者呈現更多模型數據表，這可能會導致較不直覺的體驗，特別是當雪花維度數據表只包含一或兩個數據行時。
  • 無法建立跨越數據表的階層。

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

影像顯示維度數據表內具有 Category、Subcategory 和 Product 等數據行的階層範例。

緩時變維度

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

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

類型 1 SCD

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

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

類型 2 SCD

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

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

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

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

若要達到此需求，Power BI 模型維度類型數據表必須包含用來篩選銷售人員的數據行，以及篩選特定銷售人員版本的不同數據行。 版本數據行必須提供非模棱兩可的描述，例如“Michael Blythe （2008/12/15-06/26/2019）” 或 “Michael Blythe （current）”。 此外，請務必教育報表作者和取用者瞭解 SCD 類型 2 的基本概念，以及如何套用正確的篩選來達成適當的報表設計。

也適合納入階層，讓視覺效果向下切入至版本層級。

影像顯示 [字段] 窗格，其中包含 Salesperson 和 Salesperson 版本的數據行。

影像顯示產生的階層，包括 Salesperson 和 Salesperson 版本的層級。

角色扮演維度

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

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

在 Power BI 模型中，建立兩個數據表之間的多個關聯性，即可模擬此設計。 在 Adventure Works 範例中，日期和轉銷商銷售數據表會有三個關聯性。 雖然此設計可行，但請務必瞭解兩個 Power BI 模型數據表之間只能有一個作用中的關聯性。 所有剩餘的關聯性都必須設定為非使用中。 具有單一作用中關聯性表示有從日期到轉銷商銷售的預設篩選傳播。 在此實例中，作用中關聯性會設定為報表所使用的最常見篩選條件，在 Adventure Works 是順序日期關聯性。

影像顯示單一角色扮演維度和關聯性的範例。Date 數據表與事實數據表有三個關聯性。

使用非作用中關聯性的唯一方法是定義使用 USERELATIONSHIP 函式的 DAX 表達式。 在我們的範例中，模型開發人員必須建立量值，才能依出貨日期和交貨日期來分析轉銷商銷售。 這項工作可能很繁瑣，尤其是在轉銷商數據表定義許多量值時。 它也會建立 [ 欄位 ] 窗格雜亂無章，且量值過高。 還有其他限制：

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

為了克服這些限制，常見的Power BI模型化技術是為每個角色扮演實例建立維度類型數據表。 您通常會使用 DAX，將其他維度數據表建立為 匯出數據表。 使用導出數據表，模型可以包含 Date 數據表、 Ship Date 數據表和 交貨日期 數據表，每個數據表都有與其個別轉銷商銷售數據表數據行的單一和作用中關聯性。

影像顯示角色扮演維度和關聯性的範例。事實數據表有三個不同的日期維度數據表。

此設計方法不需要您為不同的日期角色定義多個量值，而且它允許依不同的日期角色同時篩選。 不過，使用這個設計方法，要支付的次要價格是，日期維度數據表將會重複，導致模型記憶體大小增加。 由於維度類型數據表通常會儲存相對於事實類型數據表的數據列較少，因此很少值得關注。

當您為每個角色建立模型維度類型數據表時，請觀察下列良好的設計作法：

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

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

垃圾郵件維度

當有許多維度，特別是由少數屬性所組成時，以及當這些屬性只有少數值時，垃圾維度就很有用。 良好的候選專案包括訂單狀態數據行，或客戶人口統計數據行（性別、年齡群組等）。

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

垃圾維度數據表通常是所有維度屬性成員的笛卡兒乘積，具有 Surrogate 索引鍵數據行。 Surrogate 索引鍵會提供數據表中每個數據列的唯一參考。 您可以在數據倉儲中建置維度，或使用 Power Query 建立執行 完整外部查詢聯結的查詢，然後新增 Surrogate 索引鍵（索引數據行）。

影像顯示垃圾維度數據表的範例。訂單狀態有三種狀態，而傳遞狀態有兩種狀態。垃圾維度數據表會儲存這兩個狀態的所有六個組合。

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

變質維度

變質維度是指篩選所需的事實數據表屬性。 在 Adventure Works 中，轉銷商銷售訂單號碼是很好的範例。 在此情況下，建立只包含這一個數據行的獨立數據表並不具有良好的模型設計意義，因為它會增加模型儲存大小，並導致 [字段 ] 窗格雜亂。

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

影像顯示 [欄位] 窗格和銷售事實數據表，其中包括 [訂單號碼] 字段。

不過，如果 Adventure Works 轉銷商銷售數據表具有訂單號碼 和 訂單明細編號數據行數據行，而且需要篩選，則變質維度數據表會是一個很好的設計。 如需詳細資訊，請參閱一對一關係指引（變質維度）。

無事實事實數據表

無事實數據表不包含任何量值數據行。 它只包含維度索引鍵。

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

更吸引人的事實數據表用法是儲存維度之間的關聯性，而Power BI模型設計方法我們建議定義多對多維度關聯性。 在多對多維度關聯性設計中，無事實事實數據表稱為橋接數據表。

例如，假設銷售人員可以指派給一 或多個 銷售區域。 橋接數據表會設計成由兩個數據行組成的無事實數據表：銷售人員索引鍵和區域索引鍵。 重複的值可以儲存在這兩個數據行中。

影像顯示無事實數據表橋接 Salesperson 和 Region 維度。無事實數據表包含兩個數據行，也就是維度索引鍵。

此多對多設計方法已妥善記載，而且不需要橋接數據表即可達成。 不過，在關聯兩個維度時，橋接數據表方法會被視為最佳做法。 如需詳細資訊，請參閱多對多關聯性指引（關聯兩個維度類型數據表）。

相關內容

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