首先，假設一般使用者直接存取資料來源的情況。下圖顯示使用簡單工具建構查詢的範例。

至此，使用者有相當大的進展。使用者：

• 已檢查過大量的加密具名資料表，來尋找所要的資料表。
  
  
• 已識別出應使用哪些資料行，來將資料表聯結在一起。
  
  
• 已選取包含所要詳細資料的資料行，通常必須從大量系統導向的詳細資料中取出這些資料行。例如，在保存產品類別目錄之詳細資料的 11 個資料行中，與人相關的實際只有 2 個姓名資料行。
  
  

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

不過，還有更糟的情況。如何讓其他資料來源的資料聯結進來？即使其中有一個資料庫支援分散式查詢，大部份使用者是無能力建構必要的查詢的，而各種工具通常也不支援使用者執行此功能。

	複製程式碼
select Quotas.QuotaAmount, Quotas.EmployeeId, ?FROM OPENROWSET(’SQLOLEDB’,’seattle1’; ’Sales’;’MyPass’, ’select * FROM Forecasts.dbo.SalesQuota?) As Quotas

接著考慮其他資料來源 (例如 Web 服務)，使用者遇到的另一大障礙，是決定如何進行必要的遠端呼叫，以及處理傳回的 XML，將它與其他資料聯結。

最後一點，即使建構好一個查詢 (「依類別目錄顯示銷售與配額總計」)，還必須在下一個查詢重做大部份的工作 (「...接著依員工細分」)，後面的每個查詢也一樣。

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

在此範例中顯示的 UI，是 Microsoft SQL Server 所提供之開發工具中的 UI。其他用戶端工具 (例如 Office Excel 或 Office Web 元件 (OWC))，或者支援 UDM 的其他眾多報表和分析工具的 UI 也差不多是這樣。

左邊的樹狀檢視會顯示 UDM 的內容。首先，請注意：

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

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

至於顯示使用者通常在彙總中需要之交易值，或度量的資料行 (例如「Sales Amount」或「Quota」)，則顯示為「量值」。這種利用「量值」與「維度」來表現資料的方法，稱為維度模型，已經在業界證實是讓一般使用者容易瞭解的一種成功模型。

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

模型當然定義了預設使用的簡單格式 (例如，使用貨幣符號)。也可以定義更豐富的格式，包括條件式格式 (例如，如果低於某個臨界值，就以紅色顯示值)。

同一個模型支援各種查詢。例如，只要從員工維度拖曳一個屬性進來，就可以依員工細分數字。

雖然將實體的所有屬性合併到一個維度中，可以為使用者大幅簡化模型，不過屬性之間有一些其他關聯性，利用簡單清單是無法表現的。在上述的案例中，Category、SubCategory 和 SKU 會定義一個階層，可以在這個階層中組織產品。因為使用者通常希望根據這類階層執行分析，例如，先依 Category 查看總計，然後向下鑽研至 SubCategory 和最低的 SKU 層級，而 UDM 就允許定義這樣的階層。每個階層只是一連串的屬性，可以在查詢中使用這些屬性，以簡化這些向下鑽研/向上鑽研狀況。

以下是階層可能在一般使用者 UI 中顯示的範例。範例中的模型包含許多不同的階層，產品會依這些階層組織。定義查詢 (「先依產品類別目錄顯示銷售和配額，然後細分至子類別目錄」) 時，只要拖曳「Products By Category」階層，然後按兩下以展開「Bike」類別目錄，就能看到更詳細的資料。

UDM 會處理如何在階層之層級中進行導覽的細節，在此案例中，還會處理 SubCategory 層級無法使用 Quotas，只能在每一 Category 使用的細節。

父子式階層是一種特殊的階層，涵蓋與本身有複雜關聯性的許多實體。圖裡的 Employee 維度有一個「Employees By Organization Structure」階層。使用此階層可以輕鬆地導覽父子式關聯性，以及分析積存值。銷售副總裁 Charles Marshall 的配額，包含其所有下屬職員的配額總和，加上與其直接相關聯的任何配額。

使用者自然地將分類套用至資料 - 例如「這些屬性全都是關於員工的個人詳細資料、該屬性是電子郵件地址」。UDM 提供兩種專用機制，能夠讓一般使用者工具根據這些分類，以及顯示之資料的意義，提供其他的值：

• 可以在具有語意意義的類別目錄中加入維度、屬性和其他物件，更有智慧地在用戶端工具內使用。例如，某個屬性可能標示為 URL，而報表可以根據 URL 的值啟用導覽。另一個屬性可能標示為電子郵件地址，能夠讓報表用戶端在某些使用者動作下，自動開啟新的電子郵件。
  
  
• 可以將量值、階層和其他物件群組至對使用者有意義的資料夾中，讓報表工具能夠以方便管理的方式，顯示大量的屬性。例如，可能有一組「Customer\Demographics」屬性。
  
  

時間資訊通常只使用 DataTime 或 Date 資料類型，記錄在基礎資料來源中。雖然熟悉 SQL (如果是 Web 服務，則是 XPath) 的使用者可以擷取需要查看的部份，例如依年度加總的資料，不過很難根據其他形式的時間 (例如，「依每週的星期幾顯示銷售」或「從 7 月 1 日開始，依會計年度細分」) 來詢問問題。

但是，UDM 有內建的時間知識，包括各種不同的日曆：

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

因此，模型可以包含一個時間維度，其中提供定義每一天之詳細資料的內容豐富的屬性集。在下圖中，使用者只要將相關項目從樹狀檢視拖曳至篩選區域，就能選取查看 2001 會計年度的銷售量和配額。UDM 知道如何將項目翻譯成日期的範圍，也知道查詢中必須包含這些日期出貨之訂單的商務規則，而非包含到期或訂購的訂單。因此 UDM 隱含地產生正確的聯結。

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

在前面的範例中，模型內容和資料都以英文顯示。如果只有這個選項，很顯然對擁有國際性使用者的組織是個問題。

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

此外，模型也可以提供資料的翻譯。一個屬性可以對應至資料來源中的不同元素，提供不同語言的翻譯。例如，前面範例中使用的工具若是從法文用戶端連接，將會以法文顯示 UDM 和查詢結果，如下所示。

此處使用的範例模型大小不大，不過實際使用之模型定義的範圍可能會大很多，可能包含數十個量值和維度，而每個維度又包含數十或數百個屬性。但是，從事特定工作的使用者通常不需要看到整個模型。因此應該是要定義縮小版的模型檢視，以避免使用者淹沒在過大的模型大小中。

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

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

UDM 為每個屬性提供了其他的語意，旨在讓資訊能夠更容易地使用。範例如下：

• 名稱 vs. 索引鍵：查看關聯式資料庫，可能不是很容易發現，EmployeeID 是系統產生的無意義唯一索引鍵。但是，UDM 允許 Employee 屬性同時擁有索引鍵 (唯一的 EmployeeID) 與名稱 (在此情況下，是 FirstName 和 LastName 的串連)。現在，像「顯示員工」這樣的查詢，將會正確地區別姓名相同的員工，但是會向使用者顯示有意義的名稱。
  
  
• 順序：有時候，必須以和簡單字母或數字順序不同的固定順序，來顯示屬性的值。例如：
  
  
  • 週中的天顯示為「星期日」、「星期一」、「星期二」等等。
    
    
  • 屬性以「高」、「中」、「低」等順序顯示。
    
    
  UDM 允許定義代表這種情形的預設順序。
  
  
• 分隔：針對數值屬性，顯示屬性的每個相異值往往沒什麼用。例如，要求「Sales by Product Price」時，查看不同價格的小數後兩位 ($9.97、$10.05、$10.10、…)，就不如依價格範圍查看銷售量 (<$10、$10 - $15、…) 來得有用。UDM 允許使用各種準則，將屬性分隔為這樣的範圍。
  
  

企業通常會定義關鍵效能指標 (KPI)，這是用來測量企業健全狀況的重要標準。UDM 允許定義這些 KPI，以便更容易瞭解資料的群組與呈現。

UDM 中的每個 KPI，針對某些效能標準 (例如 Sales 層級)，最多定義四個運算式：

• 實際值。
  
  
• 目標值。
  
  
• 狀態。介於 -1 和 1 之間的正規化值，提供實際 vs. 目標的狀態 ( -1 是「極差」、1 是「極好」)。
  
  
• 趨勢。介於 -1 與 1 之間的正規化值，提供經過一段時間的趨勢 (-1 是「變得更差」、1 是「變得更好」)。
  
  

此外，KPI 可以定義建議的圖形，例如號誌燈，在顯示狀態和趨勢時表示「好、平均、差」。

使用 KPI 允許用戶端工具以使用者更容易瞭解的方式，呈現相關的量值。下圖顯示用戶端工具會如何顯示組織到顯示資料夾中之三個 KPI 的範例。

簡單來說，查詢通常會傳回彙總資料 (「依類別目錄顯示銷售」，而非「顯示每一個銷售訂單產品線」)。各種量值應如何彙總呢？例如，基礎關聯式資料中，並無任何內容表示「Sales Amount」可以明顯地加總，而「Unit Price」則應平均。UDM 會加入這個語意。可以使用各種配置來定義彙總的方法：

可以使用 Sum、Count、Distinct Count、Max 或 Min 的簡單彙總函數。

可以針對時間以外的所有維度，使用 ’Sum’ 等簡單函數將彙總定義為局部加總，時間則使用 ’Last period’。例如，Inventory Level 可以從 Product 加總到 Product Category，而 Month 的存貨層級並非每一天的存貨層級加總，而是每月最後一天的存貨層級加總。

彙總能夠以帳戶類型為基礎，例如 Income 與 Expense。

可以自訂彙總，以滿足任何特殊需求。

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

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

即使考慮到這裡顯示的是簡單範例，不過很明顯地，使用者所需的計算遠超過 ’Variance’ 小範例的範圍。例如：

「顯示每個時間週期的 3 個月移動平均」

「與去年同期比較，出現年度成長的年度？」

「以基準貨幣報告銷售量。使用銷售時的每日平均匯率，將這些值轉換回原始貨幣」。

「以高於本年度 10%，來計算下一年度每一類別目錄的預算銷售，然後根據過去 3 年的相關平均銷售量，分攤到每一項產品」。

UDM 提供定義這些計算的內容眾多的模型，提供類似於多維度試算表的工具，可以根據其他資料格的值，來計算某個資料格的值，例如，「2003」年「Bike」類別目錄的 AverageSales。但是，即使這種比喻也無法適當地描述 UDM 裡的計算。部份原因在於，資料格的值可能不只依據其他資料格的值來計算，同時也根據過去的值來計算。因此，可以支援同時存在的等式；例如，收益是收入減掉費用而得出的，但是，紅利 (包含在費用中) 則從收益衍生。

除了提供專為撰寫這類計算而設計的強大語言 MDX (多維度運算式) 以外，UDM 也能夠與 .Net 整合。此一整合允許以任何可驗證的 .NET 語言 (例如 C#.NET 或 Visual Basic.NET) 編寫預存程序與函數，然後從 MDX 叫用，在計算中使用。

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

利用多樣易讀的格式顯示資料很有用，但是要如何從該資料推斷新資訊呢？

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

UDM 並非唯讀的。資料也可以透過 UDM 更新。以量值為例，更新實際上可以和原始值分開保存，當成這些值的差異。

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

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

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

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

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