共用方式為

Microsoft 網狀架構倉儲中的維度模型化：事實數據表

  • 發行項

適用於： Microsoft Fabric 中的 SQL 分析端點和倉儲

注意

本文構成文章維度模型系列的一部分。 本系列著重於Microsoft網狀架構倉儲中維度模型化的相關指引和設計最佳做法。

本文提供在維度模型中設計 事實 數據表的指引和最佳做法。 它提供 Microsoft Fabric 中倉儲的實際指引，這是支援許多 T-SQL 功能的體驗，例如在數據表中建立及管理數據。 因此，您可以完全控制建立維度模型數據表，並使用數據載入它們。

注意

在本文中，數據倉儲一詞 是指企業數據倉儲 ，可全面整合整個組織的重要數據。 相反地，獨立字詞 倉儲 是指網狀架構倉儲，這是一種軟體即服務 （SaaS） 關係資料庫供應專案，可供您用來實作數據倉儲。 為了清楚起見，本文中將後者稱為 網狀架構倉儲。

提示

如果您不熟悉維度模型化，請考慮這一系列文章您的第一個步驟。 它的目的不是提供關於維度模型設計的完整討論。 如需詳細資訊，請參閱 Ralph Kimball 等廣泛採用的已發佈內容，例如 數據倉儲工具組：維度模型 化的最終指南（2013 年第 3 版，2013 年）。

在維度模型中，事實數據表會儲存與觀察或事件相關聯的度量。 它可以儲存銷售訂單、庫存餘額、匯率、溫度讀數等等。

事實數據表包含量值，通常是數值數據行，例如銷售訂單數量。 分析查詢會匯總維度篩選和群組內容中的量值（使用總和、計數、平均值和其他函式）。

事實數據表也包含維度索引鍵，可決定事實的維度。 維度索引鍵值會 決定事實的粒度 ，這是定義事實的不可部分完成層級。 例如，銷售事實數據表中的訂單日期維度索引鍵會設定日期層級的事實粒度，而銷售目標事實數據表中的目標日期維度索引鍵可以在季度層級設定數據粒度。

注意

雖然可以將事實儲存在更高的粒度，但不容易將量值分割成較低的數據粒度層級（如有需要）。 單一數據量，連同分析需求，可能會提供有效的理由來儲存更高的數據粒度事實，但代價是詳細的分析。

若要輕鬆地識別事實資料表，您通常會在名稱前面加上 f_ 或 Fact_。

事實數據表結構

若要描述事實數據表的結構，請考慮下列名為 f_Sales的銷售事實數據表範例。 此範例會套用良好的設計作法。 下列各節將說明每個數據行群組。

CREATE TABLE f_Sales
(
    --Dimension keys
    OrderDate_Date_FK INT NOT NULL,
    ShipDate_Date_FK INT NOT NULL,
    Product_FK INT NOT NULL,
    Salesperson_FK INT NOT NULL,
    <…>
    
    --Attributes
    SalesOrderNo INT NOT NULL,
    SalesOrderLineNo SMALLINT NOT NULL,
    
    --Measures
    Quantity INT NOT NULL,
    <…>
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

主要金鑰

如同範例中的情況，範例事實數據表沒有 主鍵。 這是因為它通常不提供有用的用途，而且會不必要地增加數據表記憶體大小。 主鍵通常是由維度索引鍵和屬性集合所隱含。

維度索引鍵

範例事實數據表具有各種 維度索引鍵，可決定事實數據表的維度。 維度索引鍵是相關維度中代理索引鍵（或更高層級屬性）的參考。

注意

這是一個不尋常的事實數據表，不包含至少一個日期維度索引鍵。

事實數據表可以多次參考維度。 在此情況下，稱為 角色扮演維度。 在此範例中，事實數據表具有 OrderDate_Date_FK 和 ShipDate_Date_FK 維度索引鍵。 每個維度索引鍵都代表不同的 角色，但只有一個實體日期維度。

最好將每個維度索引鍵設定為 NOT NULL。 在事實數據表載入期間，您可以使用 特殊維度成員 來表示遺漏、未知、N/A 或錯誤狀態（如有必要）。

屬性

範例事實數據表有兩個 屬性。 屬性會提供其他資訊，並設定事實數據的粒度，但它們既不是維度索引鍵或維度屬性，也不是量值。 在此範例中，屬性數據行會儲存銷售訂單資訊。 其他範例可能包括追蹤號碼或票證號碼。 為了分析目的，屬性可能會形成 變質維度。

量值

範例事實數據表也有 量值，例如數據 Quantity 行。 量值數據行通常是數值且通常加總（這表示可以使用其他匯總來加總和和。 如需詳細資訊，請參閱 本文稍後的量值類型 。

稽核屬性

範例事實數據表也有各種 稽核屬性。 稽核屬性是選擇性的。 它們可讓您追蹤建立或修改事實記錄的時機和方式，而且可以包含擷取、轉換和載入 （ETL） 程式期間引發的診斷或疑難解答資訊。 例如，您會想要追蹤誰（或哪些程式）更新了數據列，以及何時更新。 稽核屬性也可以協助診斷具有挑戰性的問題，例如 ETL 進程意外停止時。

事實數據表大小

事實數據表的大小會有所不同。 其大小會對應至維度、粒度、量值數目，以及歷程記錄數量。 與維度數據表相比，事實數據表比較窄（數據行較少），但在數據列（超過數十億個）方面則更大 或甚至巨大 。

事實設計概念

本節說明各種事實設計概念。

事實數據表類型

事實資料表有三種類型：

  • 交易事實數據表
  • 定期快照集事實數據表
  • 累積快照集事實數據表

交易事實數據表

交易事實數據表會儲存商務事件或交易。 每個數據列都會根據維度索引鍵和量值，以及選擇性地儲存其他屬性的事實。 插入時，所有數據都是完全已知的，而且永遠不會變更（除了更正錯誤除外）。

一般而言，交易事實數據表會將事實儲存在最低可能的數據粒度層級，並且包含所有維度上加總的量值。 儲存每個銷售訂單明細的銷售事實數據表是交易事實數據表的良好範例。

定期快照集事實數據表

定期 快照集事實 數據表會以預先定義的時間或特定間隔儲存度量。 它提供一段時間的關鍵計量或效能指標摘要，因此適合用於一段時間的趨勢分析和監視變更。 量值一律 為半加法 （稍後所述）。

清查事實數據表是定期快照集數據表的良好範例。 它每天都會載入每一個產品的日終庫存餘額。

記錄大量交易時，可以使用定期快照集數據表，而不是交易事實數據表，而且不支援任何有用的分析需求。 例如，一天可能會有數百萬個股票變動（這可能儲存在交易事實數據表中），但您的分析只涉及日末股票水平的趨勢。

累積快照集事實數據表

累積的快照集事實數據表會儲存在定義完善的期間或工作流程中累積的量值。 它通常會記錄不同階段或里程碑的商務程序狀態，這可能需要數天、周甚至數月才能完成。

事實數據列會在進程中的第一個事件之後不久載入，然後在每次發生里程碑事件時，都會以可預測的順序更新數據列。 更新會繼續進行，直到程式完成為止。

累積快照集事實數據表有多個日期維度索引鍵，每個索引鍵都代表里程碑事件。 某些維度索引鍵可能會記錄 N/A 狀態 ，直到程式到達特定里程碑為止。 量值通常會記錄持續時間。 里程碑之間的持續時間可以提供對商務工作流程或元件程式的寶貴見解。

量值類型

量值通常是數值，而且通常加總。 不過，某些量值不一定可以新增。 這些量值會分類為半加法或非加法。

加法量值

可跨任何維度加總加量值。 例如，訂單數量和銷售收入是加法量值（提供單一貨幣的收入）。

局部加總量值

半加總量值只能在特定維度上加總。

以下是一些半加法量值的範例。

  • 定期快照集事實數據表中的任何量值都無法與其他時段加總。 例如，您不應該加總每晚取樣的庫存專案存留期，但您可以為每個晚上加總貨架上所有庫存專案的存留期。
  • 庫存事實數據表中的庫存餘額量值無法與其他產品加總。
  • 具有貨幣維度索引鍵的銷售事實數據表中的銷售收入無法跨貨幣加總。

非加法量值

無法跨任何維度加總非累加量值。 其中一個範例是溫度讀數，其本質並無意義地新增至其他讀數。

其他範例包括費率，例如單位價格和比率。 不過，最好是儲存用來計算比率的值，以便視需要計算比率。 例如，銷售事實的折扣百分比可以儲存為折扣金額量值（以除以銷售收入量值）。 或者，貨架上庫存專案的存留期不應隨著時間加總，但您可能會觀察到庫存專案平均存留期的趨勢。

雖然某些量值無法加總，但它們仍是有效的量值。 您可以使用計數、相異計數、最小值、最大值、平均值和其他項目來匯總它們。 此外，非加總量值在計算中使用時可能會變成加法。 例如，單價乘以訂單數量會產生銷售收入，這是加總的。

無事實事實數據表

當事實數據表不包含任何量值數據行時，它就會呼叫 無事實事實數據表。 無事實數據表通常會記錄事件或發生次數，例如學生上課。 從分析的觀點來看，您可以藉由計算事實數據列來達成度量。

匯總事實數據表

匯總事實數據表代表基底事實數據表的匯總，以降低維度和/或更高的數據粒度。 其用途是加速常見查詢維度的查詢效能。

注意

Power BI 語意模型可以產生使用者定義的匯總來達到相同的結果，或使用 DirectQuery 儲存模式來使用數據倉儲匯總事實數據表。

相關內容

在本系列中的下一篇文章中，瞭解載入維度模型數據表的指引和設計最佳做法。