共用方式為

Microsoft Fabric Warehouse 中的維度模型化：事實資料表

  • 發行項

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

注意

本文是維度模型化系列文章的一部分。 此系列著重於 Microsoft Fabric Warehouse 中維度模型化的相關指導和設計最佳做法。

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

注意

在本文中，術語資料倉儲是指企業資料倉儲，可全面整合整個組織的重要資料。 相反，獨立術語倉儲是指 Fabric Warehouse，這是一種軟體即服務 (SaaS) 關聯式資料庫服務，可供您用來實作資料倉儲。 為了清楚起見，本文中將後者稱為 Fabric Warehouse。

提示

如果您不熟悉維度模型化，請先查閱這一系列的文章。 其目的不是提供關於維度模型化設計的完整討論。 如需詳細資訊，請直接參考廣泛採用的已發佈內容，例如 The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (2013 年第 3 版)，其作者為 Ralph Kimball 和其他人。

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

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

事實資料表也包含維度索引鍵，可決定事實的維度。 維度索引鍵值會決定事實的精細度，這是定義事實的原子層級。 例如，銷售事實資料表中的訂單日期維度索引鍵會設定日期層級的事實精細度，而銷售目標事實資料表中的目標日期維度索引鍵可以在季度層級設定精細度。

注意

雖然可以更高的精細度儲存事實，但將度量值分割成較低的精細度級別並不容易 (如有需要)。 純粹資料量連同分析需求，可能會提供有效的理由來儲存更高的精細度事實，但以犧牲詳細分析為代價。

若要輕鬆識別事實資料表，您通常會在其名稱前面加上 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 儲存模式來使用資料倉儲彙總事實資料表。

相關內容

在此系列中的下一篇文章中，了解加載維度模型資料表的指引和設計最佳做法。