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

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

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

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

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

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

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

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

下圖是一個對照範例，顯示使用者存取建構在這些資料來源之上的簡單 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 個相關項目從樹狀檢視拖曳至設計介面的右邊，即可定義查詢。使用者不需指定實際存取兩個不同資料來源所需的詳細資料，也不需要執行許多相關資料表之間的正確聯結。

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

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

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

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

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

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

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

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

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

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

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

因此，此模型所包含的時間維度可提供一組用來定義每天之詳細資料的豐富屬性集。下圖顯示的是使用者選擇查看 2001 會計年度的銷售量和銷售額時所顯示的結果。而使用者只要將相關項目從樹狀結構中拖曳至篩選區域即可做到。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)，這是用來測量企業健全狀況的重要標準。UDM 允許建立這類 KPI，因此該企業可用較易了解的方式來分組和呈現資料。KPI 也可以使用圖形來顯示狀態和趨勢 (例如號誌燈，用以指出「好」、「平均」或「差」)。

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

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

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

查詢一般會傳回彙總的資料。例如，一般查詢會依類別目錄來顯示銷售，而非顯示所有銷售和每個銷售順序。然而，基礎關聯式資料中並沒有任何項目可用來定義應該如何彙總特定量值。例如，銷售量可明顯地予以加總，而單價則應平均。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 支援資料之間的連結，以及根據資料採取動作等等動作。主要的動作種類有：

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

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

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