分區(qū)視圖聯接來自一組成員的水平分區(qū)數據，使數據看起來象來自同一張表。sql server 2000 區(qū)分本地分區(qū)視圖和分布式分區(qū)視圖。在本地分區(qū)視圖中，所有相關表和視圖駐留在 SQL Server 的同一實例上。在分布式分區(qū)視圖中，相關表中至少有一張表駐留在其他某個（遠程）服務器上。建議您不要將分布式分區(qū)視圖用于數據倉庫應用程序。
矢量數據倉庫圍繞事實（標量）和矢量構建，從物理上通常表示為星形架構和雪花形架構，極少有同時包含事實和矢量的完全非正交化的平面表。由于矢量架構是最常見的關系型數據倉庫結構，本文集中討論這類架構的分區(qū)。下面的建議也適用于其他通用數據倉庫架構。
分區(qū)的優(yōu)點
數據修剪：
許多數據倉庫管理員會定期將陳舊的數據歸檔。例如，一個單擊流數據倉庫可能只將詳細數據聯機保留三至四個月。其他常見的規(guī)則可能是聯機保留 13 個月、37 個月或 10 年，當舊數據不在活動窗口中時就歸檔并從數據庫中刪除。這種滾動窗口結構是大數據倉庫通常采取的做法。
在沒有分區(qū)表的情況下，從數據庫中刪除舊數據的進程需要一個很大的 DELETE 語句，例如：
DELETE FROM fact_table
WHERE date_key < 19990101
執(zhí)行該語句開銷會非常大，可能比同一張表的加載進程需要更多的時間。相反，對于分區(qū)表，管理員重新定義 UNION ALL 視圖以排除最舊的表，然后將該表從數據庫中刪除（假設已確保備份該表），這個過程幾乎可以在瞬間完成。
后面我們會討論到，維護分區(qū)表的費用也很高。如果數據修剪是采用分區(qū)的唯一原因，設計者應考慮以數據分解的方式從未分區(qū)的表中刪除舊數據。在低優(yōu)先級進程上連續(xù)運行一個每次刪除 1000 行（用"set rowcount 1000"命令）的腳本，直至刪除所有希望刪除的數據。該技術可在大系統上有效運用，比創(chuàng)建必要的分區(qū)管理系統更為直接。根據加載量和系統使用狀況，該技術適合于某些系統，并應該考慮在系統上進行基準測試。
加載速度：
加載數據最快的方法是將數據加載至空表或沒有索引的表。通過加載至較小的分區(qū)表，漸變加載進程的效率將大大提高。
可維護性：
一旦已建成支持分區(qū)的數據倉庫分階段應用程序，整個系統將變得容易維護。維護活動（包括加載數據、備份和還原表）可以并行地執(zhí)行，這樣可以極大地改善性能。漸變填充下行數據流多維數據集的進程可以被加速和簡化。
查詢速度：
查詢速度不應該作為對數據倉庫關系型數據庫進行分區(qū)的理由。對于分區(qū)和未分區(qū)的事實表，查詢性能都差不多。在正確設計的分區(qū)數據庫中，關系引擎僅在查詢計劃中包括解析查詢所需的相關分區(qū)。例如，如果數據庫按月分區(qū)，查詢條件為 2000 年 1 月，則查詢計劃僅包括 2000 年 1 月的分區(qū)。結果查詢將對分區(qū)表正確執(zhí)行，與在分區(qū)鍵上帶有簇索引的已索引合并表上執(zhí)行的大體相同。
分區(qū)的缺點
復雜性:
分區(qū)的主要缺點是需要管理員創(chuàng)建應用程序來管理分區(qū)。在尚未設計、測試和試運行應用程序來管理分區(qū)之前，將在關系型數據庫中使用水平分區(qū)的數據倉庫投入正式運行是不恰當的。本文的目的之一就是討論與分區(qū)管理應用程序有關的問題和設計決策。
查詢設計約束:
要獲得最佳的查詢性能，所有的查詢都應將條件直接放在事實表中的篩選鍵上。將約束放在第二張表（例如以日期為矢量的表）的查詢將包括所有分區(qū)。
設計時要考慮的因素:
矢量數據倉庫圍繞事實（標量）和矢量構建，從物理上通常表示為星形架構和雪花形架構，極少有同時包含事實和矢量的完全非正交化的平面表。典型情況下，矢量數據倉庫的管理員僅對事實表進行分區(qū)；對矢量表進行分區(qū)幾乎沒有什么好處。在某些情況下，對包含多于一千萬個成員的大型矢量表進行分區(qū)會有些好處。也可以對非矢量關系型數據倉庫進行分區(qū)，本文中的一般觀點仍然適用。
只有充分考慮系統體系結構和設計目標，才能制訂有效的分區(qū)計劃。即使使用相同的架構設計，僅用于填充服務分析多維數據集的關系型數據倉庫可能采用一個不同于分析員直接查詢的數據倉庫的分區(qū)結構。帶有滾動窗口的系統必須按時間分區(qū)，其他系統則不一定。
如果數據倉庫包括分析服務多維數據集，Microsoft 建議關系型數據倉庫和分析服務數據庫中的分區(qū)應該為并行結構。維護應用程序被簡化了：應用程序在關系型數據庫中創(chuàng)建新表的同時創(chuàng)建一個新多維數據集分區(qū)。管理員僅需要掌握一種分區(qū)策略。不過，一個應用程序也可能有充分的理由對兩個數據庫以不同方式進行分區(qū)，唯一降低的將是數據庫維護應用程序的復雜性。
分區(qū)設計概述
SQL Server 數據庫中的分區(qū)表可以使用可更新或可查詢（不可更新）的分區(qū)視圖。在這兩種情況下，表分區(qū)都是由每個分區(qū)都包含正確數據的 CHECK 約束來創(chuàng)建的。一個可更新的分區(qū)視圖支持對視圖進行 INSERT (或 UPDATE 或 DELETE）操作，并將操作推入至正確的基礎表。這很有益處，但數據倉庫應用程序通常需要進行批量加載，而這是無法通過視圖執(zhí)行的。下表總結了可更新和可查詢分區(qū)視圖的要求、優(yōu)點和缺點。
Microsoft 建議的做法是定義主鍵，并將事實表設計為本地（單個服務器上）的分區(qū)聯合視圖。大多數情況下，該定義會產生可更新的分區(qū)視圖，但數據倉庫維護應用程序應設計為直接將大多數數據批量加載至成員表（而不是通過視圖進行）。
語法示例:
以下代碼示例用來說明定義成員表和聯合視圖以及將數據插入視圖的語法：
創(chuàng)建 1999 年事實表:
| 以下為引用的內容： CREATE TABLE [dbo].[sales_fact_19990101] ( [date_key] [int] NOT NULL CHECK ([date_key] BETWEEN 19990101 AND 19991231), [product_key] [int] NOT NULL , [customer_key] [int] NOT NULL , [promotion_key] [int] NOT NULL , [store_key] [int] NOT NULL , [store_sales] [money] NULL , [store_cost] [money] NULL , [unit_sales] [float] NULL ) ALTER TABLE [sales_fact_19990101] ADD PRIMARY KEY ( [date_key], [product_key], [customer_key], [promotion_key], [store_key]) |
| 以下為引用的內容： CREATE TABLE [dbo].[sales_fact_20000101] ( [date_key] [int] NOT NULL CHECK ([date_key] BETWEEN 20000101 AND 20001231), [product_key] [int] NOT NULL , [customer_key] [int] NOT NULL , [promotion_key] [int] NOT NULL , [store_key] [int] NOT NULL , [store_sales] [money] NULL , [store_cost] [money] NULL , [unit_sales] [float] NULL ) ALTER TABLE [sales_fact_20000101] ADD PRIMARY KEY ( [date_key], [product_key], [customer_key], [promotion_key], [store_key]) |
創(chuàng)建 UNION ALL 視圖:
| 以下為引用的內容：
CREATE VIEW [dbo].[sales_fact] 現在插入幾行數據，例如： INSERT INTO [sales_fact] |
要驗證分區(qū)是否正常工作，請使用查詢分析器來顯示查詢計劃，例如：
SELECT TOP 2 * FROM sales_fact WHERE date_key = 19990324
您應該看到查詢計劃中僅包括表 1999。將該查詢計劃與主鍵已刪除
關鍵詞標簽：分區(qū),使用,數據庫,數據
相關閱讀
熱門文章
SqlServer2005對現有數據進行分區(qū)具體步驟
sql server系統表損壞的解決方法
MS-SQL2005服務器登錄名、角色、數據庫用戶
Access、SQL Server、Oracle常見應用的區(qū)別
人氣排行 如何遠程備份（還原）SQL2000數據庫SQL2000數據庫遠程導入（導出）數據配置和注冊ODBC數據源-odbc數據源配置教程SQL2000和SQL2005數據庫服務端口查看或修改SQL Server 2005降級到2000的正確操作步驟修改Sql Server唯一約束教程淺談JSP JDBC來連接SQL Server 2005的方法SQL Server創(chuàng)建表語句介紹