成功實施 LuckyTemplates 的技巧

我們將繼續我們關於 LuckyTemplates 項目規劃和實施的系列。這一次，我們將討論數據集設計、分析和模式。查看我們的項目規劃系列的第一部分，其中涉及部署模式，第二部分討論發現和攝取。

LuckyTemplates 項目實施的數據集設計
LuckyTemplates 項目實施的數據總線矩陣
LuckyTemplates 實施的數據分析
LuckyTemplates 實施的數據集規劃
- 選擇數據集模式
- 選擇數據集模式時要問的一些問題
結論

LuckyTemplates 項目實施的數據集設計

讓我們談談數據集設計過程並討論數據倉庫總線矩陣，這是一個已經存在了一段時間的工具。

設計 LuckyTemplates 數據集類似於設計數據倉庫。因此，數據集和數據倉庫都有類似的概念，例如事實表和維度表、星型模式、緩慢變化的維度、事實表粒度以及用於建立表之間關係的本地通知鍵。

數據集設計的 4 個步驟

數據集設計過程有四個步驟：選擇業務流程，聲明事實表的粒度，確定維度，然後定義事實。

成功實施 LuckyTemplates 的技巧

選擇業務流程。

對於第一步，每個業務流程都由一個事實表表示，該事實表具有與維度具有多對一關係的星型模式。

在發現或需求收集過程中，很難孤立地關注單個業務流程，因為用戶經常同時分析多個業務流程。

LuckyTemplates 實施中要避免的反模式

您希望在 LuckyTemplates 項目中避免的常見反模式（這是對通常無效且可能適得其反的重複出現問題的響應）是為特定項目或團隊而非業務流程開發數據集。

例如，專門為營銷團隊開發一個數據集，為銷售組織開發另一個數據集。這種做法自然會導致資源浪費，因為相同的銷售數據在兩個數據集中被查詢和刷新了兩次。這些也會消耗 LuckyTemplates 服務中的存儲資源。

這些是您想要通過良好的數據集設計過程的一些原因。孤立的方法會導致可管理性和版本控制問題，因為數據集可能包含變化和轉換。

儘管用戶或團隊的分析需求是 LuckyTemplates 項目的優先事項，但規劃最終可跨團隊共享的可持續解決方案也很重要。

聲明糧食。

事實表的粒度最終涵蓋了可用於分析查詢的詳細程度，以及可訪問的數據量。

所以更高的粒度意味著更多的細節，而更低的粒度意味著更少的細節。這方面的一個例子是當您想要獲取銷售訂單行級別時，或者如果您希望項目僅包含每個銷售訂單的匯總級別而不是深入到作為該銷售的一部分訂購的特定產品。

有時，這種粒度會根據您的時間範圍而有所不同。我遇到過許多客戶，他們想要當前季度的非常細粒度的事實表，但對於前幾個季度，他們只需要知道該季度的總銷售額是多少。

在此步驟中，您想要確定不同業務流程的每一行代表什麼。例如，我們數據倉庫中銷售事實表的每一行代表客戶的銷售訂單行。

相反，銷售和利潤計劃的行將在日曆月、產品子類別和銷售區域中聚合。所以在這種情況下，您有兩個不同的事實表和兩個不同的粒度。如果要比較兩者，就會涉及到一些數據建模工作。

確定維度。

尺寸只是前面設計步驟中選擇的紋理的自然副產品。

因此，事實表中的單個示例行應該清楚地指示與給定流程關聯的業務實體的維度，例如購買單個項目的客戶、特定日期和特定時間的產品。代表較低粒度的事實表具有較少的維度。

例如，表示採購訂單抬頭級別的事實表可以標識供應商，但不能標識從供應商處購買的單個產品。所以在這種情況下，您不需要包含產品類別或產品子類別維度。

定義事實。

事實表示事實表中包含的數字列。因此，雖然第 3 步中的維度列用於關係，但事實列用於包含聚合邏輯的度量，例如數量列的總和或價格列的平均值。

LuckyTemplates 項目實施的數據總線矩陣

數據倉庫總線矩陣是 Ralph Kimball 數據倉庫架構的主要部分，它為數據倉庫設計提供了增量和集成的方法。

您在此處看到的架構來自數據倉庫工具包，Ralph Kimball 的第 3 版。它允許多個業務團隊或功能通常需要訪問相同業務流程和維度的可擴展數據模型。

保留數據倉庫總線矩陣很有用。當你填寫它時，你就會知道是否有其他數據集包含類似的互聯網事實表和維度表。這促進了項目的可重用性並改善了項目溝通。

成功實施 LuckyTemplates 的技巧

因此，每一行都反映了一個重要且重複發生的業務流程，例如總分類賬的每月結賬。每列代表一個業務實體，可能與一個或多個業務流程相關，而帶陰影的行代表項目中包含的業務流程。

LuckyTemplates 實施的數據分析

一旦確定了粒度並完成了四步數據集設計過程，就應該立即對事實表和維度表的源數據進行技術分析。

技術元數據，包括數據庫圖表和數據分析結果，對於項目規劃階段至關重要。

此信息用於確保 LuckyTemplates 數據集反映預期的業務定義，並建立在可靠且可信的來源之上。

所以三種是收集分析信息的三種不同方式，這應該是人們完成設計過程後要做的第一步。

成功實施 LuckyTemplates 的技巧

SQL Server 集成服務

有幾種方法可以解決這個問題。一種方法是在SQL Server Integration Services (SSIS) 包中使用數據分析任務。

數據分析任務需要一個 ADO.NET 連接，並且可以將其輸出寫入 XML 文件或 SSIS 變量。

成功實施 LuckyTemplates 的技巧

在此示例中，ADO.NET 源數據是 AdventureWorks 數據倉庫、數據庫和 SQL 服務器，目標是 XML 文件。

因此，一旦執行任務，就可以通過 SQL 服務器數據配置文件查看器讀取 XML 文件。您可以根據空計數和空計數百分比查看結果。

達克斯工作室

另一種數據分析方法是通過 DAX Studio。您必須通過轉到 DAX Studio 將數據實際攝取到 LuckyTemplates 數據集中，轉到高級選項卡，然後運行 VertiPaq Analyzer。

成功實施 LuckyTemplates 的技巧

它將向您顯示有關列基數的同類信息，以便您了解哪些列在數據模型中佔用的空間最多。它包括有關數據的所有各種統計信息。

LuckyTemplates 桌面

數據分析也可用於 LuckyTemplates 桌面中的 power query。如果您轉到“查看”選項卡，則可以打開諸如列質量、列分佈和列配置文件之類的功能。至少在前一千行左右，您可以看到錯誤、空值、平均值和標準差等信息。

LuckyTemplates 實施的數據集規劃

根據四步數據集設計過程中確定的要求對源數據進行概要分析和評估後，BI 團隊可以進一步分析數據集的實施選項。

在幾乎所有的 LuckyTemplates 項目中，即使是那些在企業數據、倉庫、架構和 ETL 工具和流程方面進行了大量投資的項目，都需要某種程度的額外邏輯、集成或轉換來提高源數據的質量和價值。

數據集規劃階段確定如何解決已識別的數據轉換問題以支持數據集。此外，項目團隊必須確定是開發導入模式數據集、直接查詢數據集還是複合數據集。

為了闡明數據集規劃流程，此圖標識了數據倉庫和 LuckyTemplates 數據集的不同層，可以在其中實施轉換和業務邏輯。

在某些項目中，只需進行最少的轉換，就可以輕鬆將其包含在 LuckyTemplates 數據集中。例如，如果維度表只需要幾個額外的列，並且有關於如何計算這些列的直接指導，IT 組織可能會選擇在 M 冪查詢中實施這些轉換，而不是修改數據倉庫。

如果允許 BI 需求與企業數據倉庫之間的巨大差距持續存在，那麼 LuckyTemplates 數據集的構建和維護就會變得更加複雜。

如果復雜程度更高，數據集設計者應定期分析和傳達數據集的含義。

但是，如果所需的轉換邏輯複雜或涉及多個聯合操作、行篩選器和數據類型更改，則 IT 組織可能會選擇在數據倉庫中實施必要的更改以支持新數據集和未來的 BI 項目。

例如，可能需要暫存表和 SQL 存儲過程來支持、修改和更新過程，或者可能需要創建索引來提高 DirectQuery 數據集的查詢性能。

選擇數據集模式

數據集規劃的後續但密切相關的步驟是在默認導入模式、DirectQuery/實時模式或複合模式之間進行選擇。

成功實施 LuckyTemplates 的技巧

在某些項目中，這是一個簡單的決定，在已知要求的情況下，只有一個選項是可行或現實的，而其他項目則需要對每個設計的優缺點進行重要分析。

因此，如果認為數據源速度慢或無法處理大量分析查詢，那麼導入模式數據集很可能是首選。

同樣，如果數據源的近實時可見性至關重要，那麼 DirectQuery 或實時模式是實現該目標的唯一選擇。DirectQuery 和實時模式彼此非常相似。這兩種方法都不在數據集本身中存儲數據，並且都直接查詢源系統以根據用戶操作檢索數據。我們現在擁有用於 LuckyTemplates 數據集的 DirectQuery 和用於分析服務的 DirectQuery。

選擇數據集模式時要問的一些問題

以下是在決定使用哪種模式時要問的一些問題。我們的數據集有單一來源嗎？如果沒有單一來源，那麼您過去無法使用 DirectQuery/Live 來源。

儘管我們現在有了複合模式數據集，但一開始就問這個問題仍然是個好問題，因為如果沒有單一來源，那麼它要么是導入的，要么是複合的。

成功實施 LuckyTemplates 的技巧