Share via

統一維度模型

  • 發行項

想要直接從資料來源 (例如 Enterprise Resource Planning (ERP) 資料庫) 擷取資訊的使用者，會面臨到許多重大的挑戰：

  • 這類資料來源的內容通常很難了解，設計時考慮到的是系統和開發人員，而非使用者。
  • 使用者需要的資訊，一般是散佈在多個異質資料來源中。即使只是處理不同的關聯式資料庫，使用者也必須了解每個資料庫的詳細資料 (例如，使用之 SQL 的方言)。尤有甚者，那些資料來源的類型可能大不相同，不只包含關聯式資料庫，也包含檔案和 Web 服務。
  • 雖然許多資料來源的目的都是保存大量的交易層級詳細資料，但是支援商務決策的查詢通常會牽涉到摘要、彙總的資訊。隨著資料量的增加，擷取這類摘要值以供互動式使用者進行分析所需的時間往往變得太長。
  • 資料來源中通常並未封裝商務規則。使用者必須自行解譯資料。

統一維度模型 (UDM) 的角色，旨在提供使用者和資料來源之間的橋樑。UDM 是透過一或多個實體資料來源建構而成。使用各種用戶端工具 (例如 Microsoft Excel)，使用者即可對 UDM 發出查詢。

用戶端會透過單一 UDM 存取所有資料來源

即使 UDM 只是建構為資料來源上的簡易層時，對使用者而言，還是具有下列優點：更簡單且更容易了解的資料模型、與異質後端資料來源隔離，以及提高摘要類型查詢的效能。在某些狀況下，會自動建構像簡單的 UDM。對 UDM 建構的投資愈大，就可從模型可提供的豐富中繼資料中產生更多的優點。

UDM 提供下列優點：

  • 大大豐富了使用者模型。
  • 即使資料量很大，也能提供支援互動式分析的高效能查詢。
  • 在模型中擷取商務規則，以支援更豐富的分析。
  • 支援「封閉迴圈」，讓使用者可在這種迴圈中操作自己所看到的資料。

基本一般使用者模型

假設一個範例，使用者想要比較不同時間週期的銷售和配額。

銷售資料儲存在主要的 Sales and Inventory 資料庫中，該資料庫中也包含其他許多資料表。即使在識別出相關資料表之後，使用者可能會發現單一實體的資料 (例如 Product) 散佈在許多資料表中。因為是透過應用程式邏輯來強制執行參考完整性，所以在那些資料表之間並未定義任何關聯性。Sales Quotas 儲存在其他應用程式的資料庫中。沒有一個資料庫會擷取任何商務規則，例如在比較配額與實際銷售時，應使用出貨之訂單的日期，而非訂單的其他許多日期 (訂購日期、到期日期、排程日期等等)。

直接存取資料來源

首先，假設使用者會直接存取資料來源。下圖顯示利用範例工具建構查詢的範例。

DSV 可允許不同資料來源之間的聯結

至此，使用者會有相當大的進展。這個進展包含：

  • 檢查過大量的加密具名資料表，來尋找所要的資料表。
  • 識別出應使用哪些資料行，將資料表聯結在一起。
  • 從具有較多系統導向詳細資料的許多資料表中，選出那些包含所需之詳細資料的資料行。例如，在儲存產品類別目錄詳細資料之資料表的 11 個資料行中，實際與使用者有關的只有 2 個姓名資料行。

現在使用者要定義「外部」與「內部」聯結的使用位置，以及如何將詳細資料群組，以支援必要的彙總。

然而，使用者面臨到更困難的工作。例如，使用者可用什麼方式來聯結另一個資料來源中的資料？即使其中一個資料庫支援分散式查詢，但是大部分使用者還是無法建構必要的查詢，而在此工作中，各種工具也無法對使用者提供足夠的支援。此程式碼範例顯示一種查詢外部資料的方法。

SELECT Quotas.QuotaAmount, Quotas.EmployeeId, …
FROM OPENROWSET('SQLOLEDB','seattle1';
'Sales';'MyPass',
   'SELECT * FROM Forecasts.dbo.SalesQuota’ ) As Quotas

使用其他資料來源 (例如 Web 服務) 時，使用者遇到的另一個大障礙是決定如何進行正確的遠端呼叫，以及如何處理傳回的 XML，以將它與其他資料合併。

最後，針對某項查詢執行此工作後，也必須針對下一項查詢和所有後續查詢，重新執行其大部分的工作。

使用 UDM 以存取資料來源

下圖是一個對照範例，顯示使用者存取建構在這些資料來源之上的簡單 UDM 時，建立查詢的情形。

透過多重資料來源存取 UDM 的用戶端

可在 Microsoft SQL Server 2005 所提供的開發工具中，取得這個範例所顯示的設計介面。然而，您可以使用任何支援 UDM 的介面，包括用戶端工具 (例如 Office Excel 或 Office Web 元件 (OWC)) 或其他任一種報表和分析工具。

左邊的樹狀檢視會顯示 UDM 的內容。請注意，這個範例中的下列幾點：

  • 只會向使用者顯示使用者導向的相關項目。並不會顯示系統資料行 (例如資料列 GUID 或上次修改日期)。
  • 使用的名稱是易記名稱，而非基礎資料庫中所採用之開發人員導向命名慣例的名稱。

UDM 也會將每個商務實體 (例如 Product 或 Employee) 的所有屬性群組成另一個「維度」。因此，在這個範例中，用戶端可以參考 Product Color、Subcategory 和 Category，而不必明確地執行各種相關資料表之間的聯結。

然後，代表交易值或度量單位的資料行會呈現為「量值」。例如，使用者一般會想要彙總資料行 (例如，銷售量或銷售額)。這種將資料呈現為「量值」和「維度」的方法稱為維度模型。

圖表的右邊會顯示目前查詢中所含的元素。在此情況下，若要要求 "Sales Amount and Quota by Product Category"，則使用者只要將 3 個相關項目從樹狀檢視拖曳至設計介面的右邊，即可定義查詢。使用者不需指定實際存取兩個不同資料來源所需的詳細資料，也不需要執行許多相關資料表之間的正確聯結。

此模型定義了簡單的預設格式 (例如，使用貨幣符號)。也可以定義更豐富的格式，包含條件式格式 (例如，如果值低於特定臨界值，則以紅色顯示該值)。

相同的模型也支援各種查詢。例如，只要從員工維度拖曳一個屬性進來，即可依員工來細分結果。

擴充基本模型

上述範例示範了即使是簡單 UDM 也可大幅簡化基本資料瀏覽。然而，提供使用者的資料存取權時，仍有其他挑戰需要考量。例如：

  • 支援不同使用者執行之許多不同類型查詢的 UDM，本身的大小可能會變得很大。如何確保只需要進行特定工作的使用者，不會淹沒在不相關的資訊中？
  • 如何支援全球的使用者，以自己的母語查看報表的需求？
  • 如何簡化所有常見時間問題的詢問？例如，使用者可能會想要顯示與去年同時期比較的銷售。

此章節會探討上述部分問題，以顯示 UDM 如何擴充基本模型來支援更進階的資料瀏覽。

階層

雖然將實體的所有屬性都合併到某個維度中，可大幅簡化使用者的模型，但是屬性之間還是有一些其他關聯性無法以簡單清單予以表現。在上述情況下，Category、SubCategory 和 SKU 會定義一個用來組織產品的階層。因為使用者常常會想要根據這類階層來執行分析，所以 UDM 可讓您定義這類階層。例如，依據 Category 檢視總值後，使用者可能會向下鑽研至 SubCategory，然後再向下鑽研至最低的 SKU 層級。每個階層都是一連串可在查詢中使用的屬性，用以簡化這類向下鑽研/向上鑽研狀況。

下圖是使用者在介面中所看到之階層的範例。此模型包含許多不同的階層，可用來組織產品。此處所顯示的查詢回答了下列問題：「顯示依產品類別目錄分組的銷售和配額，然後細分子類別目錄」。將 "Products By Category" 階層拖曳至方格中，即可定義此查詢。若要檢視詳細資料，則使用者只要按兩下 "Bike" 類別目錄，即可展開子類別目錄。

在 UDM 中導覽階層

UDM 會處理如何在階層層級之間移動的詳細資料。因為 Quotas 並不會出現在 SubCategory 層級，而只會出現在 Category 層級，所以 UDM 也會處理這類詳細資料。

父子式階層是一種特殊的階層，涵蓋與本身有複雜關聯性的許多實體。在下圖中，員工維度有一個 "Employees By Organization Structure" 階層。使用這個階層可輕易地導覽父子式關聯性，以及分析每個組織層級的積存值。例如，銷售副總裁 Charles Marshall 的銷售額包含其所有下屬職員的總銷售額，加上與其直接相關的任何銷售額。

在 UDM 中導覽父子式階層

分類

使用者通常會將分類套用至他們的資料中。例如，使用者可能會說「這些屬性都是員工個人詳細資料」或「這個屬性是電子郵件地址」。UDM 提供兩種機制，特別用來根據這類分類以提供其他值：

  • 可以在具有語意意義的類別目錄中加入維度、屬性和其他物件，讓用戶端工具更有智慧地使用物件。例如，可以將屬性標示為 URL。然後，包含這個屬性的報表即可根據 URL 的值來啟用導覽。另一個屬性則可能標示為電子郵件地址。在此情況下，報表用戶端可能會在某個使用者動作時自動開啟新的電子郵件。
  • 量值、階層和其他物件都可分組成對使用者有意義的資料夾。這個分組可讓報表工具以較易管理的方式顯示大量屬性。例如，可能會有一組標示為 'Customer Demographics' 的屬性。

時間

時間資訊通常是使用 DateTime 或 Date 資料類型，記錄在基礎資料來源中。雖然熟悉 SQL 或 XPath 的使用者可擷取依年度加總資料所需的日期資訊，但他們會發現很難根據其他形式的時間來撰寫問題的查詢 (例如「依每週的星期幾顯示銷售」或「從 7 月 1 日開始，依會計年度細分」)。

然而，UDM 具有內建的時間知識，其包含下列日曆：

  • 自然
  • 會計
  • 報表 ('445' 等)
  • 製造 (13 期)
  • ISO8601

因此，此模型所包含的時間維度可提供一組用來定義每天之詳細資料的豐富屬性集。下圖顯示的是使用者選擇查看 2001 會計年度的銷售量和銷售額時所顯示的結果。而使用者只要將相關項目從樹狀結構中拖曳至篩選區域即可做到。UDM 知道如何將該使用者項目翻譯成日期的範圍，也了解查詢中必須包含在那些日期出貨之訂單的商務規則，而非包含在那些日期到期或已訂購的訂單。UDM 會隱含地產生正確的聯結。

依時間維度量值

此外，UDM 還提供回答一般時間相關問題 (包含不同週期的比較，例如「比較本月與去年同月」) 的特定支援。

翻譯

在上述範例中，模型內容和資料都是以單一語言顯示。但是，國際使用者經常會需要檢視其當地語言的中繼資料。

為了解決這個問題，UDM 允許以任何語言提供中繼資料的翻譯。使用特定地區設定連接的用戶端應用程式，會收到以適當語言顯示的所有中繼資料。

此模型也提供資料的翻譯。屬性可以對應到資料來源中的不同元素，並提供那些元素之不同語言的翻譯。例如，如果使用者利用用於之前範例的相同工具來進行連接，但是使用具有法文地區設定的用戶端電腦，則 UDM 和查詢結果都會以法文顯示 (如下圖所示)。

在 UDM 中顯示中繼資料的翻譯

檢視方塊

雖然此處使用的範例模型大小不大，但是實際使用之模型的範圍可能會大很多，可能包含數十個量值和維度，而每個維度都包含數十或數百個屬性。從事特定工作的使用者通常不需要看到整個模型。為了避免使用者無法忍受整個模型大小，則需要可定義用來顯示模型之子集的檢視。

UDM 提供這類檢視 (稱為檢視方塊)。UDM 可以有許多檢視方塊，每個檢視方塊都只代表模型中與特定使用者群組相關的特定子集 (量值、維度、屬性等等)。然後，每個檢視方塊都可以與使用者安全性角色產生關聯，而這些角色定義的是應看到該檢視方塊的使用者。

例如，可定義名為 Seattle Inventory 的檢視方塊，其中只包含 Inventory 量值群組中的量值、隱藏 "Warehouse By Location" 階層，並將預設 City 設定為 "Seattle"。

屬性語意

UDM 提供屬性的其他語意。這些語意的目標是要讓資訊更容易使用。下列是一些可套用至屬性之語意的範例：

  • 名稱與索引鍵：查看關聯式資料庫時，可能不是很容易發現 EmployeeID 是無意義、唯一且由系統產生的索引鍵。而讓 Employee 屬性同時擁有索引鍵 (唯一的 EmployeeID) 和名稱 (例如，FirstName 和 LastName 的串連)，UDM 即可解決此問題。查詢 (例如「顯示員工」) 使用唯一識別碼來正確區別姓名相同的員工，但是會向使用者顯示有意義的名稱。
  • 順序：通常必須以非簡單字母或數字順序的某種固定順序，來顯示屬性的值。UDM 可讓您定義用來管理這項需求的預設順序。例如：
    • 每週的星期幾會顯示為「星期日」、「星期一」、「星期二」等等。
    • 屬性是以「高」、「中」和「低」順序來顯示。
  • 分隔方法：若為數值屬性，則顯示屬性的每個相異值時，它有時不是很有用。例如，查看產品之所有不同價格的銷售 ($9.97、$10.05、$10.10 等等) 就不如依價格範圍查看銷售 (<$10、$10 - $15 等等) 來得有用。UDM 可讓您使用各種準則，將屬性分隔為這樣的範圍。

關鍵效能指標 (KPI)

企業通常會定義關鍵效能指標 (KPI)，這是用來測量企業健全狀況的重要標準。UDM 允許建立這類 KPI，因此該企業可用較易了解的方式來分組和呈現資料。KPI 也可以使用圖形來顯示狀態和趨勢 (例如號誌燈，用以指出「好」、「平均」或「差」)。

針對每個效能標準，UDM 中的每個 KPI 最多會定義四個運算式：

  • 實際值
  • 目標值
  • 狀態：介於 -1 與 1 之間的正規化值，代表實際與目標的比例 ( -1 是「非常差」、1 是「非常好」)。
  • 趨勢：介於 -1 與 1 之間的正規化值，代表經過一段時間的趨勢 (-1 是「變得更差」、1 是「變得更好」)。

使用 KPI 可讓用戶端工具以使用者較容易立即了解的方式，來呈現相關的量值。下圖顯示用戶端工具會如何顯示組織到顯示資料夾中之三個 KPI 的範例。

在 UDM 中顯示 KPI

效能

使用者的互動式瀏覽需要快速的回應時間。這項需求對於經常進行這類瀏覽的極大資料集，是一項挑戰。

為了改進效能，UDM 提供快取服務。快取可儲存從基礎資料來源讀取的詳細資料，以及根據該資料所預先計算的彙總值。但是，使用這類快取值可能意味著資料過時。商務需求會決定資訊需要多久更新一次。在某些情況下，重要的是顯示最新資料，而在其他情況下，則顯示兩小時或兩天前的資料可能就夠了。

為了反映這些決定資料之傳播的原則，UDM 允許明確地管理快取 (例如，可定義排程，在每天早上 2 點重新整理快取)，或使用「主動式快取」透明地管理。使用者可以指定資料的最新程度，以及 UDM 會提供自動快取建立和管理，以啟用最快的可能查詢回應。

分析

前面各節討論的是，UDM 可以如何支援資料的互動式瀏覽。不過，只從基礎資料來源提供資訊 (即使以更容易了解與使用的形式)，很顯然地並不符合將商務邏輯併入使用者模型的目標。因此，UDM 提供可定義資料之簡單和複雜計算的能力。

基本分析

查詢一般會傳回彙總的資料。例如，一般查詢會依類別目錄來顯示銷售，而非顯示所有銷售和每個銷售順序。然而，基礎關聯式資料中並沒有任何項目可用來定義應該如何彙總特定量值。例如，銷售量可明顯地予以加總，而單價則應平均。UDM 會加入這個語意。

可以使用各種配置來定義彙總的方法：

  • 可以使用簡單的彙總函數 (例如 Sum、Count、Distinct Count、Max 或 Min)。
  • 彙總可以定義成局部加總。這表示簡單函數 (例如 Sum) 是用於 Time 以外的所有維度，而 Time 使用的是 Last Period。例如，雖然 Inventory Level 可以從 Product 加總到 Product Category，但是該月的存貨層級並非是每天之存貨層級的加總，而是該月最後一天的存貨層級。
  • 彙總能夠以帳戶類型為基礎，例如 Income 與 Expense。
  • 可以自訂彙總，以滿足任何特殊需求。

UDM 也可以包含導出成員。這些成員並未直接與來源資料相關聯，而是從該資料衍生。例如，可以定義導出成員 Variance，以計算 Sales 與 Quota 之間的差異。

同樣地，UDM 可以定義使用者所要的實體集：例如前 10 大客戶 (依銷售量排列) 或最重要的產品。然後就可以很方便地使用這些實體集，來限制對特定實體集之查詢的範圍。

進階分析

有時使用者需要的計算遠比先前所提供的 'Variance' 範例複雜。下列是一些複雜計算的範例：

  • 顯示每個時間週期的三個月移動平均。
  • 比較這個期間和去年相同期間的逐年成長。
  • 如果是以基準貨幣報告銷售，請使用銷售時的每日平均匯率，將銷售轉換回原始貨幣。
  • 以高於本年度 10%，來計算下一年度每一類別目錄的預算銷售，然後根據過去三年的相關平均銷售，將預算分攤到每一項產品。

UDM 提供眾多定義這類計算的模型，且類似多維度試算表，可根據其他資料格的值，來導出資料格的值。然而，即使這種比喻也無法適當地描述 UDM 中之計算的豐富。資料格的值可能不只根據其他資料格的值來計算，同時也根據該資料格過去的值來計算。因此，可以支援同時存在的方程式；例如，收益是衍生自收入減掉費用，而紅利 (包含在費用中) 則是衍生自收益。

除了提供專為撰寫這類計算而設計的強大多維度運算式 (MDX) 語言以外，UDM 也會與 Microsoft .NET 整合。這項整合會以任何可驗證的 .NET 語言 (例如 C#.NET 或 Visual Basic .NET) 寫入預存程序和函數。然後，可透過 MDX 呼叫預存程序或函數，以用於計算。

用戶端會與這類計算的詳細資料隔離。對用戶端應用程式而言，只表示模型現在已有更有用的量值。在以下範例中，使用者會根據 Sales，針對在美國銷售之獲利最高的產品檢視各種導出量值。

在 UDM 中顯示計算的量值

與資料採礦整合

以豐富、易懂的形式來顯示資料的能力十分重要，但是使用者也需要具有推斷該資料之新資訊的能力。

UDM 與資料採礦技術緊密整合，以允許對資料執行採礦，然後再使用發現的模式進行預測。

讓資料可作用

對使用者而言，查看資料通常都會產生其他疑問，或讓使用者想要採取某個動作。例如：

  • 「構成該數字的詳細銷售為何？」
  • 「配額太低了 - 必須提高。」
  • 「看起來很奇怪 - 我要在這個數字加上註解」。
  • 「我們網站上的促銷詳細資料內容為何？」

只利用易懂的方式向使用者呈現資料是不夠的。還要讓使用者更容易依照所看到資料採取適當的動作。

UDM 可以藉由兩種方式支援此功能：

  • 允許將變更寫回資料中
  • 讓動作與資料產生關聯

回寫

UDM 並非唯讀的。資料也可以透過 UDM 更新。以量值為例，更新可以和原始值分開儲存，作為與那些值的差異。

此外，也可以更新摘要數字。例如，以預算狀況為例。雖然預算金額可能會在詳細層級中出現 (依小組和帳戶)，但是最早可能只會出現在摘要層級 (依部門和帳戶類型)。

動作

UDM 支援資料之間的連結，以及根據資料採取動作等等動作。主要的動作種類有：

  • URL：移至指定的 URL。這類型的動作支援將使用者導向某個 URL 以取得進一步的資訊，以及將使用者導向某個允許執行新工作的網路架構應用程式。例如：
    • 若是產品，請移至描述該產品的公司網站。
    • 若是產品/倉儲組合，則請移至網路架構存貨管理應用程式，並傳遞產品/倉儲作為參數，以允許增加安全庫存量。
  • 報表：執行指定的報表。例如，針對指定的產品，動作可能是執行提供產品描述與目前訂購狀態的參數化產品報表。
  • 鑽研：鑽研至最低的可用詳細資料層級。例如，依產品與客戶檢查總銷售量的使用者，可以進行鑽研以檢視對總和有影響的所有銷售交易。

動作可以和特定的資料區域關聯。例如，導覽網頁的動作可能適用於每一種產品，但是查看詳細庫存傳送交易的動作，則只適用於依據產品和倉儲分類的每個數量值。

雖然動作定義為 UDM 的一部分，但是用戶端應用程式需要負責擷取適用的動作詳細資料，並將該動作提供給使用者，然後依需要起始該動作。

安全性

對 UDM 的存取是可以控制的。主要的安全性功能如下：

  • UDM 提供以角色為基礎的安全性。可以定義角色，並授與角色權限，然後再將使用者併入為每個角色的成員。使用者的實際權限，是授與每個使用者所屬角色之權限的聯集。角色的權限也可以包含「強式拒絕」，而這類拒絕會移除權限，而不管使用者所屬的其他角色。
  • 管理權限 (例如，變更 UDM) 可以單獨授與，與資料存取權限分開。而且，可定義用來讀取物件之中繼資料的個別權限，以及用來進行資料之讀取/寫入的個別權限。
  • 從資料粒度層級往下到個別資料格，都可保護資料的安全。例如，您可將使用者檢視 'Widget' 產品之銷售的能力限制成客戶 'ACME'。安全性也可以是條件式的；例如，只有在部門員工超過五人時，角色才能夠看到該部門的薪資總和。
  • 權限可以定義是否應使用視覺化總計，若是使用，總計只會反映使用者擁有權限的較低層級成員。資料格存取權也可以視情況決定，這表示只有在可檢視其他所有資料格時，才能夠檢視衍生自其他資料格的資料格。例如，如果收益是衍生自收入和成本，則使用者只能檢視他們有權檢視收入和成本之產品的收益。

請參閱

其他資源

Analysis Services 概念

說明及資訊

取得 SQL Server 2005 協助