本文概述了 sql server 2005 beta 2 中“商務智能”平臺的增強功能。本文并非實施指南，而是為讀者提供了關于“商務智能”平臺增強功能的信息。

　　一、簡介

　　microsoft sql server 2005 是一個完整的商務智能 (bi) 平臺，其中為用戶提供了可用于構建典型和創新的分析應用程序所需的各種特性、工具和功能。本文簡要介紹了您在構建分析應用程序時將要用到的一些工具，并著重介紹了一些新增功能，這些新增功能使復雜 bi 系統的構建和管理比以往更加輕松。

　　下表概述了商務智能系統的組件，以及與之相應的 microsoft sql server 2000 和 sql server 2005 組件。

　　sql server 2005 新增了兩個組件：sql server management studio 和 sql server business intelligence development studio。其他主要的 bi 組件——dts、analysis services olap、analysis services data mining 和 reporting services——在 sql server 2005 中得到了改進，與以前有很大的不同。sql server 2005 關系數據庫包含一些重要的新增功能。雖然 microsoft office 查詢和門戶工具并沒有包含在 sql server 中，但當前的發行版本力爭在 sql server 2005 之前實現這一功能。office 工具的 bi 功能將在 office 產品發行周期內將得到逐步實現。

　　sql server 2005 business intelligence 工具集提供了一種端到端的 bi 應用程序集成：

　　sql server 2005 business intelligence 組件的主要目標是支持在各種規模的企業中開發和使用商務智能，并使其能夠供所有員工使用，不僅包括管理層和分析師，還包括操作人員和外部委托人。就此目標而言，sql server 2005 具有完整、集成、易用的特點，它以 web 服務的形式發布數據，而且僅通過日常硬件便可提供極佳的性能，另外它還包含許多新增功能，您可以使用這些新增功能開發創新的分析應用程序。

　　二、sql server2005 beta 2 入門

　　在安裝 sql server 2005 時第一點要注意的就是它的集成安裝體驗。您不再需要為某些功能（如 analysis services）而分別運行安裝程序。如果某個功能（如 reporting services）不可安裝，則說明您的計算機不滿足該功能的安裝要求。您可以查看說明文件，以獲得有關功能必要條件的完整討論。在大多數配置得當的機器上，安裝過程中應接受所有默認設置，安裝所有的主要功能：

　　reporting services 要求在機器上安裝并妥善配置 iis。由于 reporting services 是 2005 business intelligence 功能組的一個重要組成部分，我們強烈建議您花費一定的時間，執行這些配置和安裝步驟。

　　熟悉 analysis services 的客戶可能會因缺少 analysis services 元數據倉庫而感到迷惑。在 sql server 2000 中，analysis services 倉庫被作為 microsoft access 數據庫發行。analysis services 2005 不包含元數據倉庫。相反，analysis services 數據庫元數據信息被存儲為 xml 文件格式，由 analysis services 進行管理。如果需要，還可以將這些 xml 文件放置在源代碼控制之下。

　　我們建議您使用 business intelligence development studio 進行開發，同時使用 sql server management studio 來操作和維護 bi 數據庫對象。雖然您能夠在 sql server management studio 中設置 dts 包以及 analysis services 多維數據集和數據挖掘模型，但 business intelligence development studio 卻為設計和調試 bi 應用程序提供了更好的體驗。

　　對于 beta 2 而言，建議您從掌握新的應用程序入手，因為與升級現有 dts 包或 analysis services 數據庫相比，這樣可以學到更多東西。如果您已有一個可用的包或數據庫，您會發現，“重新創建”現有的包或數據會十分有用。在您熟悉了這些新增工具、功能和概念之后，便可試著升級現有對象。

　　許多客戶都借助 sql server 工具，使用熟悉的來自一個或多個源系統的商務智能結構來開發新的系統，使用 dts 填充維度關系型數據倉庫，然后再用數據倉庫來填充 analysis services 數據庫。但是，sql server 2005 提供了許多選項，通過消除或淡化不同的組件使其背離了這種一般化設計。

　　三、關系型數據倉庫

　　sql server 2005 關系數據庫引擎包含一些對數據倉庫樣式應用程序設計和維護大有幫助的功能。這些功能包括：

　　要想將關系操作報告從事務處理數據庫中分離出來，經常采用的一項技術便是維護一臺報告服務器。報告服務器對事務處理數據庫映像的維護一般都有一定的時間延遲，通常截止到前一天。報告服務器多用于報告功能和數據倉庫提取。

　　microsoft sql server 2005 新增了兩項功能，使報告服務器的創建和維護過程變得更加簡單。sql server 報告服務器的延遲時間與以前相比大大縮短。同時，報告服務器被設計為充當事務處理系統的備選系統。

　　要創建報告服務器，先要創建一個數據庫鏡像，這是 sql server 2005 的新增功能，它為系統的高可用性提供了一個緊急備用系統。更多信息，請閱讀聯機叢書的“數據庫鏡像概念”主題。數據庫鏡像不能夠直接查詢，這時第二個新增功能就能派上用場了。

　　在鏡像上創建一個數據庫視圖。數據庫視圖是數據庫在某個時點的只讀副本。數據庫視圖并非數據庫的完整副本；極為節省空間。多個數據庫視圖還是可以同時共存，雖然維護數據庫視圖會對數據庫視圖所基于的事務處理數據庫產生一定的影響。更多信息，請閱讀聯機叢書的“了解數據庫視圖”主題。

　　通過在數據庫鏡像上創建數據庫視圖，您可輕松為系統的高可用性創建備用服務器，此服務器還可用作報告服務器，起著雙重作用。

　　分區表和分區索引將數據分割到多個水平單元中，以便于將行組映射到單獨的分區中。而對數據執行操作（如查詢）時，又可以將整個表或索引作為一個整體來執行。

　　分區可以：

　　
在關系型數據倉庫中，事實數據表比較適合應用表分區，而按日期范圍分區又是最常見的分區策略。

　　正如聯機從書的“創建分區表和索引”主題中所描述的，定義分區表可分為三個步驟：

　　多個表可以使用同一個分區方案。

　　本文討論了事實數據表的“范圍”分區，但其目的并非是針對表分區的完整討論或教程。有興趣的讀者請參閱 sql server 聯機叢書。

　　最常用的分區方案是按日期范圍（如年、季、月或甚至天）對事實數據表進行分區。在大多數情況下，對大型事實數據表進行日期分區可以提供良好的可管理性收益。為了改善查詢性能，應盡量使用相同的分區方案對時間維度表進行分區。

　　許多數據倉庫應用程序都力求在越來越小的加載窗口中加載越來越多的數據量。典型的流程是這樣的，先從幾個源系統中提取數據開始，接下來便是在這些系統間清理、轉換、合成和合理化數據。數據管理應用程序被限制為在加載窗口中完成整個提取、轉換和加載流程。通常，系統的業務用戶都強烈要求將數據倉庫查詢時的不可用時間降至最低。在設計時，數據管理應用程序的“寫入”步驟（即將新數據插入到現有數據倉庫的步驟）必須在短時間內完成，且要最小化對用戶造成的影響。

　　為了非常快速地加載數據，數據庫恢復模型必須為“批量記錄”恢復模式或“簡單”恢復模式，而數據表必須為空，或是包含數據但不包含索引。如果滿足這些條件，不作記錄的加載便成為可能。在 sql server 2000 中，分區表出現以前，這些條件通常只在初始歷史數據倉庫加載中才能滿足。一些具有大型數據倉庫的客戶已通過在分散的物理表上搭建 union all 視圖，構建了一個準分區結構；這些數據表都使用不記錄技術填充每個加載周期。這一方法并不盡如人意，而 sql server 2005 分區表則提供了更為優秀的功能。

　　在 sql server 2005 中，您不能直接在分區中執行不記錄加載。但是，卻可以將數據加載到將調用偽分區的單獨表中。在特定條件下，您可以用執行速度極快的元數據操作將偽分區切換到分區表中。此技術可滿足我們的兩個要求：

　　此外，偽分區還可作為單獨的表進行備份，從而改善系統的可管理性。

　　許多數據倉庫在數據倉庫中保留了一個詳細活動數據的滑動窗口。例如，事實數據表可能包含三年、五年或十年的數據。每到一個時間周期，便從數據表中刪除最舊的數據。持續刪除數據的主要原因在于要提高查詢性能并最小化存儲成本。

　　sql server 2005 分區使大型分區事實數據表中舊數據的刪除倍加輕松。如上所述，簡單地創建一個空白偽分區，然后將其切換到分區表中。分區表在其曾植入分區的地方有一個空白分區；偽分區在其曾為空白的地方包含數據。用戶可以根據需要對偽分區進行適當的備份、截斷或刪除。

　　或者，您還可以選擇重新定義分區函數，將所有空白分區合并到一個分區中。

　　sql server 2005 中有一些很重要的新類型，這些類型對數據倉庫大有裨益：

　　許多新分析功能都提供了 transact-sql 中的基本分析功能。這些功能在那些允許用戶查詢關系數據庫，而不是通過 analysis services 排他查詢數據的數據倉庫中非常有用。另外，在數據中轉過程中，這些復雜的計算常被用來開發有價值的數據屬性。

　　row_number。返回結果集的連續行號。

　　rank。返回行在結果集中的等級。在通常情況下，rank 值與有序數據集上的 row_number 值相同。但對于那些彼此之間有關聯的行來說，則是所有具有相同排序值的行都有相同的等級。而下一個等級則又與 row_number 值相同。換句話說，如果在第一個位置存在雙向關聯，那么行 1 和行 2 的 rank 就都為 1，而行 3 的 rank 則為 3。不存在 rank 為 2 的行。

　　dense_rank。返回行在結果集中的等級。dense_rank 函數與 rank 相似，只是去除了 rank 函數所留下的空隙。在上面的示例中，行 1 和行 2 的 rank 為 1，而行 3 的 rank 則為 2。

　　ntile。將有序集分成指定數量、大小近似相等的組。

　　在 sql server 2005 beta 2 中還不能使用這些函數。

　　pivot 操作符可以按查詢中的中斷值旋轉結果集，從而使您可以生成交叉數據報告。例如，如果表中在兩個不同的行中包含 "actuals" 和 "budgets" 數據，則使用 pivot 操作符將可以生成帶有 [actuals] 和 [budgets] 列的交叉數據報告。

　　與之相似，unpivot 操作符可以將一行拆分為若干行。在此示例中，帶有 [actuals] 和 [budgets] 列的行集可以被轉換為包含這些值的多個行。

　　在以前的 sql server 版本中，用戶能夠編寫復雜的 transact-sql select 語句來旋轉數據。pivot 和 unpivot 操作符則為數據旋轉提供了更為簡單的機制。

　　在許多方案中，“遞歸查詢”都是非常有用的。sql server 2005 中的新增功能令遞歸查詢成為可能，雖然此項功能還不是十分簡單易用。

　　遞歸查詢是針對自聯接表的查詢。自聯接表的兩個常見示例有保存員工及其經理信息的數據表，和保存材料清單的數據表。在 adventureworks 數據庫的 employee 表中對自聯接數據表進行了說明。

　　查詢自聯接表的直接關系通常十分簡單，如查詢直接向經理報告的員工數量。但是，如果要回答“經理的組織中有多少名員工？”這樣一個問題卻十分困難。

　　sql server 2005 中的關系數據庫功能解決了這一問題，這一功能被稱為“遞歸通用表表達式”。“附錄”中包含一個遞歸查詢的示例，該示例回答了以上定義的問題。聯機叢書的 "with <common_table_expression>" 主題中包含更多的相關信息。

　　四、提取、轉換和加載 (etl)

　　數據轉換服務 (dts) 對于 sql server 2005 而言，是一項全新的技術。dts 是 sql server 2000 中很受歡迎的一項功能，但 dts 2005 已被重新設計成企業 etl 平臺。dts 為構建企業級 etl 應用程序提供了大量必需的功能，以及非常高的擴展性能。dts 是完全可編程的、嵌入式的、可擴展的——所有這些特性都使它成為理想的 etl 平臺。

　　下表總結了 dts 2005 的這些功能。有關 etl 系統開發 dts 適用性更加完整的討論，請參閱 sql server 聯機叢書。

　　dts 2000 用戶已經開發出了一套執行復雜操作的技巧。這些技巧，尤其是編寫自修改包，在 dts 2005 中不再有用武之地。在 dts 2005 中要使用變量和配置基礎結構來編寫動態包、不要再試圖編寫自修改包。

　　配置良好的變量和配置基礎結構還可以減少創建復雜子包系統的需求。如果設計完善，單一包便可滿足多種需求；例如，單一包可以在多種不同配置中重復使用，以用來在維度數據倉庫中加載許多維度表。在 dts 2000 中，一個復雜的 dts 包網絡可能包括 50-100 個包；而在 dts 2005 中，一個復雜的網絡可能只包含 10 個包。

　　五、analysis services

　　sql server 2000 analysis services 由兩個主要的互補功能組成：聯機分析處理 (olap) 和數據挖掘。這兩個組件在 analysis services 2005 中仍然存在，并且是分析應用程序的基石。

　　analysis services 2005 olap 中的功能改進主要可以歸納為兩類改進：

　　構建分析數據庫的途徑主要有兩個：

　　不管采用哪種方法，基本的系統設計都假設使用當前熟悉的、來自一個或多個源的商務智能結構來填充維度關系型數據倉庫，然后再用數據倉庫來填充 analysis services 數據庫。但是，sql server 2005 提供了許多選項，通過消除或淡化不同的組件使其背離了這種常規設計。在下面“統一維度”模型中討論了一些其他的備選系統。

　　創建 analysis services 數據庫的第一種方法最為 sql server 2000 的用戶所熟悉。即從任意結構的源數據庫開始著手創建數據庫：

　　sql server 2005 中可從標準化數據庫尋源的能力是對 analysis services 2000 的一大突破，在 analysis services 2000 中，執行此操作需要一個維度結構，此結構或是星型的，或是雪花型的，或是拉伸型的。此功能使您可以輕松地開發具有極低延遲時間的商務智能應用程序。

　　通過直接在事務數據庫內構建 analysis services 數據庫，而不需要先構建正式的數據倉庫，可以用較低的成本，輕松有效地滿足許多用戶的要求。如果您需要僅對數據執行最低的數據轉換、清理和集成便投入使用，則可考慮使用一個 analysis services 數據庫來補充或替換現有的關系報告。您可以充分利用 analysis services 的功能和交互性，更好地管理事務系統中的負載。

　　雖然可以直接從事務系統構建和維護 analysis services 數據庫，但只有先構建關系型數據倉庫才能最好地滿足許多企業分析的要求。復雜的數據集成和數據更改管理問題可以通過典型的數據倉庫體系結構得到最好的解決，其中 analysis services 數據庫充當著查詢和分析引擎的角色。

　　構建分析應用程序的第一步就是在 business intelligence development studio 中創建一個新的 analysis services 項目。創建了空項目之后，應當創建一個“數據源”并將其與源數據庫建立連接，此源數據庫可以是任何受支持的關系數據庫管理系統中的數據庫。對于 beta 2 版本，建議您將 sql server 2000 或 sql server 2005 關系數據庫作為源。

　　“數據源”負責為源數據連接存儲信息。“數據源視圖”中包含著源數據庫表相關子集的信息。此信息不只局限于源數據庫中表的物理結構；您還可以添加諸如關系、表和列的友好名稱、計算列和命名查詢之類的信息。

　　“數據源視圖”可以在 bi 項目和 dts 項目之間共享。“數據源視圖”很有用處，尤其是在以下幾種情況中：

　　您為“數據源視圖”設置良好名稱和關系所作的投資將換來分析應用程序的輕松開發。

　　創建了“數據源視圖”之后，便可以右擊“解決方案資源管理器”窗格中的“多維數據集”圖標，選擇“新建多維數據集”，創建一個多維數據集。您可以啟用 intellicube 檢測和建議。如果您選擇使用 intellicube，則必須決定是否構建一個已為報告經過旋轉優化的多維數據集。intellicube 技術會對“數據源視圖”中的數據庫和數據基數關系進行檢查，并按事實數據表、維度表或用于解析多對多關系的維度-事實橋接表來智能呈現表特征。對于 beta 2 版本來說，選擇是為旋轉還是為報告優化多維數據集和維度存在一些微小的差別。唯一的差別就是 intellicube 是否會嘗試在維度屬性之間創建層次關系。由于層次易于創建，也易于毀壞，因此無須擔心會花費太多時間和精力。

　　建議您在此“多維數據集向導”的初始屏幕后立即點擊“完成”按鈕。這樣會一次定義好所需的 analysis services 數據庫、維度、層次、屬性和多維數據集。您可以對此設計進行編輯，但通常情況下，仔細一點兒走完向導，并在過程中作出一些明智的選擇會更加有效。

　　實施完“多維數據集向導”之后，您可能會發現您更喜歡用“維度向導”來逐一地創建復雜的維度，要啟動“維度向導”，只需在“解決方案資源管理器”窗格中右擊“維度”即可。仔細定義完大型維度（例如“產品”、“客戶”和“時間”）后，啟動“多維數據集向導”，并確保在適當的位置包括這些預定義的維度。

　　到此為止，前面執行的這些步驟已在您的開發機器上以 xml 文件輕松創建了維度和多維數據集定義和結構。business intelligence development studio 和“配置管理器”使您可以對目標服務器上的項目構建和部署過程進行管理。默認情況下，“部署”目標服務器就是您的本地服務器。您可以創建適合其他環境部署的備選配置。項目的主要屬性，如目標服務器的名稱和數據源連接字符串等，可能會因配置而不同。

　　要在開發循環過程中預覽和測試多維數據集和維度，請從 business intelligence development studio 的菜單中選擇“部署”，在指定的目標服務器上構建和部署項目。或者，單擊 f5，或選擇“調試”（位于 business intelligence development studio 主菜單中）。這樣會啟動幾個調試和瀏覽工具中的一個，具體啟動哪個，要取決于您所執行的操作以及您選擇“部署”的時間。根據此上下文，“部署”過程會啟動多維數據集瀏覽器、mdx 腳本調試器或 kpi 瀏覽器。

　　您可能想在定義完系統的維度、度量值和多維數據集后查看一下系統原型。請使用相對較少的數據針對開發數據庫進行處理，以驗證數據和結構的行為是否與預期的行為相一致。

　　作為原型的一部分，您可能想設計一些更為復雜的“analysis services 數據庫”、“關鍵績效指標”、“操作”和“計算”組件。如果您的數據庫是被對不同數據視圖感興趣的不同用戶團體使用的話，請深入查看“透視”和備選的安全計劃。如果您計劃部署可供國際上不同語言的用戶使用的數據庫，則可以使用“翻譯”功能引入本地化項目名稱。最終，原型會評估備選的物理配置，例如“分區”和不同的“主動緩存”選項。

　　在 analysis service 數據庫開發完成之后，便可以部署數據庫對象，以便于進行最終測試、臨時過渡并投入生產服務器。在構建階段的項目輸出可以用作 analysis services 部署實用工具的輸入。此實用工具可以幫助您部署和處理數據庫。

　　我們剛剛描述了從已知源創建自定義 analysis services 數據庫的基本步驟。這種通過“多維數據集向導”和“維度向導”創建的方法與創建 analysis services 2000 數據庫的標準方法十分類似。

　　創建 2005 分析應用程序的另外一種備選方法就是選擇“多維數據集向導”第二個屏幕上的“在不具備數據源的前提下設計商務智能模型”選項。這種通過向導創建的方法與 sql server 2000 accelerator for business intelligence 的設計體驗十分類似。這種設計體驗會從模板生成一個完全可自定義的應用程序，此處的模板：具有豐富的維度結構和分析功能，還有可能包括一個關系型數據倉庫和 dts 包。microsoft、集成商或獨立軟件供應商都可以提供這種模板。

　　不管采用哪種通過向導創建的方法，是從源數據庫創建，還是從模板創建，都可以設計相同的 analysis services 數據庫。第一種選項假設您將創建一個完全自定義的系統。對象名稱和結構都是可以完全自定義的，初始設計是受源數據庫中的名稱和結構所驅動的。模板選項也可以創建一個完全自定義的數據庫，但是初始設計是受專家主題區域模板所驅動的。

　　許多用戶都喜歡將這兩種方法結合使用。一個非常常見的方法就是用現有源創建 analysis services 數據庫中的大部分內容，而用模板法生成“時間”維度。

　　analysis services 2005 使關系數據庫與多維度 olap 數據庫之間的界線變得更加模糊。olap 數據庫分析應用程序一直以來都具有著巨大的優勢，這些優勢主要體現在以下幾個方面：

　　不過，在實現這些功能的同時也帶來了一定的負面效應。到目前為止，已經發現的問題就有 olap 數據庫（包括 analysis services 2000 在內）很難交付以下內容：

　　通過將傳統 olap 分析與關系報告二者的優點相結合，analysis services 2005 能夠提供一個可以同時覆蓋這兩方面需求的統一維度模型。在 sql server 2005 中定義的一套多維數據集和維度被稱為統一維度模型 (unified dimensional model)，或 udm。udm 的優勢和靈活性引發了設計領域的巨變。過去，bi 架構師會權衡備選基礎結構的收益和成本，并在關系數據庫和 olap 數據庫之間作出選擇。現在，架構師可以設計一個“統一維度模型”，然后從傳統極限中確定一點用于放置 analysis services 系統邏輯設計和物理配置。

　　analysis services 2005 圍繞維度的屬性，而非維度的層次構建多維數據集。在 analysis services 2000 中，維度設計由層次主宰，層次的示例有 {年、月、日} 或 {國家、地區、城市}。這些層次要求各層之間存在密切的數據關系。作為成員屬性和虛擬維度公開的“屬性”是“二等公民”。雖然有可能在物理維度中生成屬性，但性能因素卻使這一技術的廣泛使用大打折扣。熟悉關系結構的用戶對 olap 數據庫中對層次的過度側重深感困惑。

　　analysis services 2005 結構與關系型維度結構更為類似。一個維度可包含多個屬性，每個屬性都可用于切片和篩選查詢，同時每個查詢又可以合并到層次中，而不必考慮數據的相互關系。

　　有 olap 背景的用戶都知道強大的層次結構的價值，有一點您可以肯定，那就是“城市”清晰地匯總為“地區”和“國家”。這種自然層次結構依然存在，并應在適當的位置進行定義：查詢性能會因為這種層次結構而得到提高。