中央大學資訊管理學系碩士班

Advanced Database

Data Warehousing

指導教授：陳彥良博士

學生：陳家仁88423007

黃琮盛88423010

林耀堂88423025

鄒順安88423031

目錄

1. 前言3

2. Overview 4

3. 資料倉儲的架構12

4. Dimensional Modeling 15

5. 資料倉儲資料庫之設計33

6. 以 SQL Server 建立「星

狀架構」資料倉儲46

7. 結論58

第一章前言

資料庫（Database）用來管理大量的資料是行之已久的成熟技術，電腦網路普及之後，資料庫的應用更為廣泛，但資料累積多了，在使用上有很多地方不是傳統的資料庫技術能解決的，例如歷史資料的分析、大量資料的彙總查詢。許多的連鎖大型超市，在資料庫中存有顧客採購的時間、產品類別、購買數量與金額，為了規劃上架商品的類別與數量，希望能了解過去顧客採購的習性，此時可能過去的資料已經存入歸檔（Archive），或是資料庫未提供所需要的分析功能。資料超市（Data mart）與資料倉儲（Data warehouse）的技術就是在這樣的情勢下產生的。

 資料倉儲中含有的資料具有多方位性（Multi-dimensional），或可稱為多維度性的資料，例如談到某產品的價格，就不再是單一的數值了，因為也要考慮時間的因素，去年的價格和今年的價格應該不同，水果在冬天的價格可能就和夏天的價格不同，所以設計資料倉儲時用的資料模型，有時也叫做多維度的資料模型（MDM, Multi-dimensional Data Model）。資料超市可以看成資料的分類，因為倉儲中的資料量顯然要比傳統的資料庫大很多，資料超市可以將龐大的資料做有效的分類。

隨著資料倉儲與資料超市技術的興起，很多相關的技術也跟著發展起來，例如線上分析處理（OLAP, On-Line Analytical Processing ）、資料採擷（Data mining）等，讓資料的處理與呈現更為精緻化，以便未來在所謂的主管資訊（Executive Information）、決策支援（Decision Support）、企業資源規劃（ERP, Enterprise Resources Planning）等領域有多元化的應用。

本質上，資料倉儲系統要能提供歷史數據給決策程式，這類的應用程式包括報表、線上分析處理(OLAP)、執行資訊系統(EIS)和資料擷取工具等，但是大多數公司，在他們的生產系統裡都已經擁有資訊儲存倉庫的設計，而且當中許多也都是集中式的資料庫。那麼，這些算不算是資料倉儲系統呢？答案是「不盡然」。

第二章Overview

• 什麼是資料倉儲？

定義一：

資料倉儲不是一個單一性產品或服務，而是一個包含了各種技術、各種工具且具有彈性的環境。

定義二：

將組織中作業性資料、歷史性資料和一些外部的資料，合併放入一個分散式設計的關連式資料庫中，並管理之，使其成為一個以主題為導向的資料庫，以提供決策者存取資料並分析資料，進而幫助決策的建立。

雖然資料倉儲聽起來只有單一實體，但是它可包含多層、多重應用元件所組成的架構。每個元件均能被一或多個硬體或軟體元件控制。因此不會有所謂的一套資料倉儲套裝軟體出現。

• 資料倉儲的興起的源由

在1970年代，商業系統幾乎全部架構在IBM Mainframe Computers之上，雖然1980年之後陸續推出了mini-computer的平台，但大致上所有的商業行為仍舊在Mainframe Computers上進行，而因商業行為而產生的大量資料就儲存在如DB2、IMS這些資料庫系統中；一般說來，若是企業中的高階主管想要取得有關公司營運方面的資料時，IT/IS的工作人員就必須從龐大的資料儲存設備中﹝如：tape libraries﹞，找到相關的資料並製作成報表供主管查閱；但很不幸地，資訊人員寫程式的速度永遠趕不上主管們的需求。縱使有足夠的資料讓我們做分析，但卻缺乏了專業的人才及完善的工具來輔助分析工作的進行，所以在這個時候並不適合資料倉儲的發展。

一直到最近十年才有了明顯的轉變，自從個人電腦普及之後，商業分析人才與程式設計師之間的距離已經不再如此遙遠，而市面上也漸漸有廠商開發出分析系統供企業使用，其中以DSS及EIS最為著名；DSS可以幫助中低階的管理人員做決策，EIS則能提供高階管理人多元化的企業觀點，幫助企業做出最適當的決定；至此，資料倉儲才正式有了發揮的空間。

以下整理了幾個關鍵的因素：

• 決策的需要：一個良好正確的決策，往往需要大量的歷史性資料，與參閱各式資料，才能評估出來。但大多數的企業，其資料來源大多分散在不同平台上、或以不同的資料形態來儲存資料、或是不儲存歷史性資料，也因此，使得資料的整理變得更形困難。故需要一個整合性、一致性、具有多元化資料的系統是必要的。

• 硬體效能增加，價格卻不升反跌：根據Gordon Moore所提出的定律，中央處理器的速度每十八個月就增加一倍；儲存設備的進步則更為驚人，例如十年前40MB 硬碟的價格在今日足以購買一顆20GB的硬碟，容量暴增五百倍，價格卻一模一樣，無形中就降低了儲存設備的投資，資料的儲存成本也就相對降低了。

• 桌上型個人電腦的普及：目前的個人電腦皆提供了和善的圖形介面，使用者的進入障礙遠較大系統為低，而資料倉儲的資料擷取與分析大多是在個人電腦上進行，也是由於個人電腦應用程式支援完善的緣故。

• Server級作業系統價格下降：以Windows NT及UNIX為例，它們都具有多人多工的能力，對於大規模的分析工作皆能勝任有餘，但價格卻極為便宜，甚至有免費的伺服器作業系統，如Linux、FreeBSD的問世，同時在提供極佳的工作效能之外，也具備容易安裝與使用的特性。

• 網際網路應用程式的普及：藉由Internet與Intranet的技術，資料倉儲的資料將可以跨越國際，而不再僅限於企業內部的存取，這對現今的全球化經濟型態有相當正面的幫助。

• 標準商業應用程式的出現：另一個重要的因素是標準商業應用程式的採用無形間增加了資料倉儲的使用，目前這方面的主導廠商有SAP、Baan、PeopleSoft及Oracle。

• 經濟環境的改變：在企業不再以大眾化市場，而以分眾化市場導向、顧客導向為主的經營模式來經營企業，故分析顧客的消費行為益形重要，故需要資料倉儲來提供分析統計顧客行為的方式。

• 全球化經營的改變：由於現代企業漸漸的以全球化為企業經營模式，使得資料分散在各地，並以不同的資料形態來儲存，使得分析資料更形困難，故企業決策者往往在評估企業所需的經營策略上，面臨挑戰。

• 資料倉儲和線上交易系統（OLTP）的不同？

資料倉儲不同於生產資料庫，或線上交易處理(OLTP)系統，這些系統主要的設計目的，以OLTP為例，最重要的任務在資料輸入和更新，而資料倉儲通常則是為了檢索資料和產生報表等目的，而且它通常被設計成唯讀式的系統；OLTP系統所處理的資料類型通常為企業中以日為單位所處理的資料，但是資料倉儲所含的則是用來分析企業運作狀況的資料，其中可能包含了月的彙總資料或年的彙總資料；OLTP系統所得到的資料，多具高揮發性和即時的特色，因為輸入的可能為不完整甚至是無法判讀的資料，而資料倉儲中的歷史資料則為已更正過的非揮發性資料。

最後因為這兩種系統的差異甚大，所以OLTP和資料倉儲系統使用的是完全不同的資料模型。在OLTP系統中，多餘資料幾乎是不存在的，由於複雜的資料更新作業無時不在進行，所以OLTP系統的資料庫多半已經高度正規化，而且通常使用關連式資料庫模型。資料倉儲系統為了簡化並提高使用者存取資料的效能，大大降低了資料表使用的數目，並且在其中充斥著多餘的資料，因此資料倉儲系統多半不使用關連式資料庫模型，而改採多維資料庫的設計。

資料倉儲提供了一個彈性且具有效率的存取企業資料的方式，並能將資料以一個具有可讀性、可利用、且是對決策者是有用的資料表達方式。其將各式資料來源由各式的作業性資料系統中，萃取整合放入一個整合的資料結構中。

事實上，資料倉儲自操作的系統資料擷取資料並載入至暫存區內清理(使資料倉庫標準一致)、合併、標上時間或註明日期等，然後用資料存取工具將之載入資料庫中。

由於資料經過許多的轉換並且最後被放在不同於原先的資料結構內，所有的改變係記錄、對照在目錄或資料字典內，這類的目錄是由 Metadata(定義或描述資料倉儲內資料的資料)工具來管理。傳統上有二類的metadata。讀者需要知道的有，例如定義表和欄位名字的，被稱為前端metadata。其它如某個特別的資料元件如何對應到它的最初的資料庫，稱為後端metadata。

設計和管理工具也是非常重要的資料倉儲元件。即使它包含不因電源關掉而「揮發」的資料，但資料倉儲絕對不是靜態性的資料，不能新增完成後便不再管它。資料倉儲是需要高度維護的系統，以隨著企業的成長而擴展。即使資料倉儲系統本身的設計有些改變，或者餵給它資料的生產系統設計也有可能改變。這些改變都必須送到metadata資料內。不像OLTP系統，僅專注於目前的瞬間時點，資料倉儲必須提供任何時刻，全面綜覽資料的能力。這意謂每當有任何生產系統的資料結構改變，必須抓取兩者的變化和它發生在資料倉儲內的時間，否則和歷史數據違背可能產生無法預期的後果。

• 資料倉儲的環境？

在早期，資料倉儲通常是使用在大型的主機上，但隨著科技進步、軟硬體技術的大幅提升、且成本降低，使得資料倉儲技術應用在分散式的環境中變得可行。

一個開放性的資料倉儲環境是由什麼組成的？

• 一個可並行處理的關連式資料庫管理系統（RDBMS）

• 能實行將作業性資料放入資料倉儲中的資料模型

• 具有自動化資料對應(data mapping)、資料萃取(data extraction)、資料轉換(data transformation)、和資料維護(data maintenance)的資料倉儲管理軟體

• 資料存取工具

• 線上分析處理(OLAP)能力

• 具並行處理能力

• 整合的系統

• 建構資料倉儲需考量的因素？

時間和金錢：

在1996年 IDC發佈的一項研究報告(「資料倉儲對財務影響的研究」)指出，建構資料倉儲系統的平均成本是220萬美元，平均到第2.3個年度打平。90％研究個案裡面的公司，會達到比40％更好的投資利潤(權益報酬率)，而且50％達到三個年度，平均超過 160％的權益報酬率，累計起來超過 400％，比資料商業中心更高。很清楚地，建構資料倉儲系統能提高獲利，但它不是一蹴可及的。在收到任何預期的回饋之前，應該先行評估這項投資的額度。

空間：

資料倉儲需要許多磁碟空間。當估計需要儲存磁碟空間時，不要只著眼於目前的生產系統規模，記得是要建構包含龐大歷史資料的系統。大多數的組織至少會保留資料一個年度以上，如果還想作些趨勢分析什麼的，就會需要好幾個年度的資料，還有報表和分析通常需要一個以上的索引。請不要把磁碟空間估得太緊。資料倉儲的磁碟空間需求以TeraBytes(TB)為單位是很平常的事，還有一些更大的系統甚至用到PetaByte(1PB=1024TB)計算的磁碟空間。

整合：

整合多種來源的資料可能會導致OLTP系統產生不相容或其它問題。既然大多數的資料擷取工具已經內建分析和轉換資料的能力，所以穩定對資料擷取應用程式是非常重要的。你可根據成本來評估另外設計外部資料過濾轉換工具，或直接修改OLTP系統。

安全：

資料倉儲的安全考量和 OLTP系統是不一樣的。要讓資料倉儲系統能值回票價，就必須有夠多的使用者能從中獲得好處，因此會比傳統OLTP授權數更多的使用者存取資料。根據專家的說法「渴望知道」的企業文化必定勝過「需要知道」，「需要知道」的態度會限制對資料倉儲的存取並將大大降低其效能。如果組織不能作此文化上的改變，建置資料倉儲系統可能是一個全然浪費的投資。

使用者親和力：

資料倉儲必須要有使用者親和力。既然資料倉儲不是生產系統，所以使用者不必非使用它不可。如果使用者不了解或發現它難用得要死，就算是最快速、可靠的系統也將乏人問津。

專案計劃：

資料倉儲有時需要好幾個年度來建置。在著手建置資料倉儲專案前，請先定義好什麼是系統的企業目標、潛在的好處與成本，需要什麼樣的資源配合，還有需要多少組織上的支持。沒有好的計劃編列和使用者的支持，很難成功地建置資料倉儲系統。

二、資料倉儲的屬性與概念

通常我們不會將資料倉儲的儲存容量做限制，因為資料倉儲的容量將隨著儲存年度的增加而逐漸擴增，我們不可能預估企業十年之後的資訊容量應該會多大。接下來來談談資料倉儲的一些屬性及一般性概念。

1. “Warehousing” data outside the operational systems

基於輔助決策上的需要，資料倉儲的資料必須包括多方的來源甚至外部的資料，只有將不同資料整合之後，透過它們彼此的對照與比較，將可讓決策者得到單一資料來源所無法提供的資訊。

但因為商業分析的過程已經越來越複雜，所以資料倉儲的產生也會需要較佳的系統來支援，但即使現在的機器已經有極佳的效能，我們仍建議資料倉儲的分析工作應該與作業性系統﹝Operational Systems﹞分開。其主要的原因如下：

1. 日常作業與分析作業在本質上的差異：在一般的操作系統內，我們可以制定一個系統的負荷度，例如今天我們有一部檔案伺服器，在考量機器的效能與頻寬之後，將會訂定系統能夠同時接收使用者需求的數量，可能從數十人到數百人不等；但若是在做資料倉儲的分析時，卻可能會衍生出許多額外的分析需求，例如當某一位使用者在分析客戶的存款資料時，可能會想要順便去分析客戶的全國分布率對於存款是否有影響，這時候如果我們將資料倉儲架構在現行的操作系統上，將非常有可能造成操作系統額外的負荷，甚至影響到現在正在進行中的交易活動。

2. 一但資料存入資料倉儲，將鮮少會做更動：一般說來，放入資料倉儲的資料將不會再做更動，例如某一個月份的存貨數量通常是屬於非揮發性的資料，一但紀錄到資料倉儲就不會再更改了。不過，我們並不建議正在操作中的交易每一筆都加入資料倉儲中，這種做法將導致系統的負荷過重，正確的做法應該取一段時間來做資料的擷取，例如每半小時將交易的資料作統計後再存入資料倉儲。另外，有一點非常重要的是，資料倉儲中的資料不可能是動態變動﹝dynamic﹞的，因為這將導致資料作分析時的困難。

3. 資料倉儲儲存長期的資料：通常我們會等到處理中的資料已經成為非互動性﹝inactive﹞之後才存入資料倉儲中，例如一筆order的命令在填寫完交易資料並送出之後，就成為一筆非互動性的資料；事實上，只要資料一被存入資料倉儲後，維護的成本將非常小，一般而言，成本會耗費在資料的傳輸及資料維護上。

2. Logical transformation of operational data

當資料從操作系統進入到資料倉儲前，會進行一連串邏輯上的轉換，而轉換的工作將需要極為龐大的分析動作，基本上，轉換的工作將依循data warehouse model的架構來進行，所以一個差勁的架構將導致整個系統的災難。在接下來的部分，將針對資料倉儲的模型來做探討，究竟什麼樣的模型架構才是正確的：

1. 可擴充的資料模型：跟關聯式資料模型不同的是，資料倉儲模型並不建議採用正規化的資料，也許在操作系統上有相當多的資料是彼此參照的，然而一進入資料倉儲中，資料倉儲會將所有互相參照的資料做統合；例如訂單系統可能維護的資料對象有價格及產品屬性，製造系統則包含產品的設計規格和方程式等資料；可是兩個系統的資料到最後仍會被資料倉儲整合成一個單一的產品資訊。另外，值得注意的是，有些在操作過程中很重要的屬性，並不一定會被資料倉儲認為是重要的。

而為了因應商業資料可能從不同的應用程式得來，所以資料倉儲模型應該具有彈性；不過，早期可能因為環境的因素，不可能一下子就能擁有全部的應用程式來做資料的擷取，一個好的資料倉儲模型應該是逐漸擴增的，可能一開始我們並不知道究竟有哪些資料是必須的，這時候不妨將所有的資料全部放入資料倉儲中，以利往後的分析；等到經驗足夠之後，自然會知道有哪些資料是分析時需要的。

2. 資料倉儲模型應該符合商業結構：資料倉儲模型會根據現行的商業結構來存放資料，而非僅是針對某一個特殊的應用；例如銀行的存款系統可能只知道客戶的存款額度、利息等資料，另一個系統則可能知道客戶的借貸紀錄、放款利息，可是一旦資料進入資料倉儲時，資料倉儲會將所有牽涉到客戶的資料放在一塊，這種做法將會有利於我們往後的分析工作。

3. 操作狀態資訊的轉換：一個資料倉儲通常不會將所有的操作狀態全部紀錄下來，以一個每天必須應付數萬筆交易的企業而言，光資料的存取動作就有可能讓操作系統癱瘓，所以一般的資料倉儲終止會記錄最後的交易成果或某個時間片段的資料。

4. 資料必須反正規化：在關聯式的資料庫中，我們通常在設計table時會先進行資料的正規化工作，將一個table分成數個獨立的table，然後再經由key值來做參照；但在資料倉儲中，正規化只會帶來麻煩，因為資料倉儲會將所有相關的資料整合在一起，這時候若是我們的資料有太多的參照存在，資料倉儲勢必要耗費相當大的精神才能夠將它們整合在一起，所以反正規化將會有效地減少資料倉儲在join table上的時間浪費，而這也就是為什麼要在資料倉儲上提倡資料反正規化的主要原因了。

3. Physical transformation of operational data

從操作系統將資料實際轉換到資料倉儲之前，會把資料先做統合以及淨化的工作，而淨化的方式有以下幾種：

1. Operational terms transformed into uniform business terms：不同的操作系統對於相同資料可能會有不同的命名方式，例如同樣是客戶資料，在甲系統可能用cust來代表客戶的識別資料欄位，乙系統則採用cust_id或是cust_no，這時候應該要有一個標準的命名方式，否則容易造成資料整合上的困難。

2. Single physical definition of an attribute：除了命名是一個問題之外，資料型態與長度也應該有放諸四海皆準的規格。

3. Consistent use of entity attribute values：屬性資料也應該要有統一的格式，例如有的系統再表示性別時會用”Male”或”Female”，有的則乾脆用簡寫”M”、”F”來表示性別，甚至有的會用數字來代表性別；不管之前的操作系統在屬性的命名上有多分歧，如果要能夠順利地整合資料，統一規格的確是不二法門。

4. Issues associated with default and missing values：企業中可能會有部分的資料是存放在極為老舊的系統裡，跟現行的資料比較起來，或許會有遺失或空白的情形發生，例如某項產品在以前並沒有尺寸的資料存在，到了現代尺寸的資料突然變得極為重要，而必須納入資料庫中，這時候我們必須採取某些措施，來將遺失的資料作補遺的工作，通常我們在遇到遺失的狀況時，會有以下幾種處理方法：<1>以預設值代替；<2>參照現存的資料；<3>直接空白不做處理。留空白的原因在於，若胡亂填入一筆資料可能反而讓資料倉儲無法正確地做分析。

4. Business view summarization of data

有一些資料倉儲中的query與report工作是常常會用到的，如果每次做分析時都必須將query重新做一遍，將會浪費相當多的執行時間，所以資料倉儲中有一個重要的觀念，那就是summary views；我們可以將常用到的query儲存起來，一旦需要用到時就可以馬上拿來用，如此將可以減少處理程序的數目。

第三章資料倉儲的架構

資料倉儲的架構包含了下列幾層：

• 作業資料或外部資料層（Operational Data Base / External Data Base Layer）

• 資訊存取層（Information Access Layer）

• 資料存取層（Data Access Layer）

• 資料目錄層（Data Directory (Metadata) Layer）

• 程序管理層（Process Management Layer）

• 應用訊息層（Application Messaging Layer）

• 資料倉儲層（Data Warehouse Layer）

• 資料步驟層（Data Staging Layer）

圖3-1 – 資料倉儲架構

3.1) 作業資料/外部資料層（Operational Data Base / External Data Base Layer）

作業系統為企業處理了大量的資料，並支援了企業所需關鍵作業需求，也因此作業系統每日所產生的資料，將是大量的交易資料，但一般企業中使用的作業系統，通常是已經使用了十至十五年之久，故一般的資訊管理系統是很難與之溝通，故此層所設計的目標，就是讓資訊管理系統可以藉由系統提供的界面，來獲取分析所需的資料來源。

然而，資料倉儲的目標，是將經由各個不同來源作業系統的資料加以萃取、整合成為有用的資訊，其來源可能是來自其他或外部的資料。一般來說，一個巨大有規模的組織，常常除了自己企業本身以外，還需要一些關於外部的相關資訊，其可能包含了人口統計、經濟、社會、同業競爭和顧客購買行為的資訊。此層我們亦可稱為資訊高速道路(information superhighway)，一個提供每日我們存取更多資料資源的界面。

3.2) 資訊存取層（Information Access Layer）

資料倉儲架構中的資訊存取層，是一個終端使用者（亦稱資料倉儲使用者）可以直接接觸的一層，它提供了一些終端使用者常用的分析工具，例如：Excel、Lotus 1-2-3、Focus、Access、SAS。

此層亦包含了相關的硬體與軟體，其提供了展示、列印報表、試算表、圖形化分析和圖形化呈現的功能。

3.3) 資料存取層（Data Access Layer）

資料倉儲架構中的資料存取層，提供了資訊存取層和作業性資料溝通的界面。目前，最常用的資料溝通語言便是–結構查詢語言（SQL），利用標準的查詢語言，可讓資訊存取層上的應用系統，和作業/ 外部資料層溝通，以存取相關資料。

資料存取層不只可以將相同硬體中的各個DBMSs或檔案系統作為管理，亦可以結合網路技術來處理異質的資料來源，此層的應用提供了使用者一個一體的資料存取環境(universal data access)，其可以讓使用者只需在本地，即可使用全企業中相關聯的資料，以完成工作。

2.5)資料目錄層（Data Directory (Metadata) Layer）

為了提供一個一體的資料存取環境，必須要有一個用以記錄資料倉儲的方式，這就是metadata。Metadata是描述資料的資料，其記錄了所有資料倉儲的種種，如資料存取的方式、資料萃取所採用的方法、各階段的資料定義、資料轉換的方式、轉換的格式，這都是資料倉儲中的metadata。

2.6) 程序管理層（Process Management Layer）

程序管理層包含了多樣的工作，其用以完成建立和維護資料倉儲和資料字典資訊，此層作用就像排程處理器，負責安排資料倉儲中的各種任務。

2.7) 應用訊息層（Application Messaging Layer）

提供各階層用意相互溝通的環境，全部的訊息傳送都透過這一層，在特定的時間內傳送到特定的點。即此層的功用就像是一個中介系統（middleware），負責做各階層的資訊溝通。

2.8) 實體層（Data Warehouse (Physical) Layer）

資料倉儲主要用做資訊使用的實際資料發生的地方。在某些情況下, 人們認為資料倉儲完全是資料邏輯設計或者virtual view。在許多情況下, 資料倉儲可以不實際上牽涉到儲存資料。

在實際的資料倉儲，許多作業性和外部的資料都拷貝在容易存取和較富彈性的table中，越來越多的資料倉儲都架構在client/server的平台上，但普遍都會儲存在main frames。

2.9) Data Staging Layer

最後一個資料倉儲架構的元件，是data staging layer。此層亦可稱為複製管理(copy management)或抄寫管理(replication management)，但事實上，它包含了所有的資料倉儲的必要程序，其中包含了選擇、編輯、摘要、合併、載入資料倉儲、和由作業性系統或外部來源存取資料。

第四章Dimensional Modeling

資料倉儲經常使用Dimensional modeling的方法來進行邏輯設計，也是唯一能將資料倉儲中的資料送給end-user的可行技術。

第一節THE CASE FOR DIMENSIONAL MODELING

• What is Entity-Relationship Modeling?

ERD（Entity-Relationship Modeling）是一種打算消除資料重複的邏輯設計技術，由於在資料庫存入資料時，相關記錄可能分散於不同的relation中，所以相要維持它的一致性也變得較為困難。例如某個消費者的名字和地址出現了很多次，當消費者地址的instances彼此獨立不相關時，又經常有地址的異動時，不一致的情形便可能日益嚴重。而為了避免資料的重複，我們將它分別存放於不同的tables中，但因為它必須透過複雜且沒有效率的連結方法，才能將所要的資料擷取出來，我們便需要資料庫有很強的連結功能，這也是關聯式資料庫所專注的重點。

1980年代中期，是關聯式資料庫開始崛起盛行，在1980年代Chris Date的書中，對於是否資料已經正規化了或是是否有任何table可以再被分割切細，並沒有深入探討，它是著重在解釋那些如何進行tables的關連合併的基本觀念。所有ERD和正規化的相關主題是在產業轉移注意力到交易過程的時候才發展的。ERD是用來闡明各個資料元素間的彼此關係，最好的ERD是除去所有的資料重複性。由於它可以讓交易變得簡單明確，對交易過程來說是有相當大的益處的，我們可以將消費者的地址放在一個專屬的table，透過唯一的識別碼記錄它或在上面建立索引來加快搜尋，所以ERD可說是關聯式資料庫的交易過程是否成功的基礎。

然而當我們熱衷於提昇交易效率時，我們會忽略關聯式資料庫原來的重要目的，而開發了一個無法進行查詢的交易導向資料庫。如同圖4-1的圖示所展現的企業製造產品的ERD（圖中共22個entities），即便是下訂單這麼簡單的例子，要在建立了相當多的tables的資料庫中，進行tables之間進行合併，其關係就猶如蜘蛛網一般，易讓人混淆迷惑。一般的企業在ERD中會有數百個entities，而大型企業的ERP系統如SAP，與之相關的entities將多達數千種，而這些entities在implement時，通常會變成關連表，這種情況將是一個惡夢。

終端使用者不能了解或記住ERD，也無法操控ERD，沒有一種針對ERD可資利用的GUI可以提供終端使用者使用。軟體無法對ERD進行有用的查詢，欲對查詢進行最佳化經常會有錯誤的選擇，其成本很大，也對效率造成重大影響。使用ERD技術與資料倉儲的目的相違背，換句話說，ERD不符資料的直接retrieval和快速retrieval的目的。

圖4-1：

自關聯式資料庫發展之初，資訊系統商便注意到這些問題。許多商家在嘗試將資料傳送給終端使用者時，已經發現要在這麼龐大複雜的架構下運作是行不通的。許多商家則走回”簡單的設計”的方式進行嘗試，我們很驚訝的發現這些”簡單的”設計方法都很類似，每一個都能被想成是”dimensional”的方式。很自然地，資訊系統設計者回到原始關連模型的根部，因為他們知道除非資料庫被包裝成很簡易的方式來操作，否則將無法被終端使用者接受。而這個natural dimensional的方法並不是由哪一個人發明的，當設計者在開發資料庫時，若是以可理解性和效能為最高目標時，便一定得使用這個設計方法。

• What is Dimensional modeling?

Dimensional modeling是一種邏輯設計技術，它企圖尋求以一個直覺表現的並允許高速存取的標準的框架來展示資料。它是天生的dimensional，而且它是依附在以某些重要限制使用relational model的方法之上。每一個dimensional model是由一個含有multipart key的table所組成，我們稱之為fact table，其他較小的tables的集合則稱之為dimension tables，每一個dimension table有一個單獨部份的主鍵，它與fact table內的multipart key的其中一個成份恰好相對映，如圖4-2。

圖4-2：

這種類似星狀結構的特性經常被稱為star join。有趣的是，dimensional modeling的方法，可能是在ERD之前就有，1960年代末期，General Mills and Dartmouth University發展以”facts”和”dimensions”組成的用語，我們相信在1970年代，Nielsen Marketing Research將這些技術應用於雜貨店和藥房的稽核資料，在稍後的1970年末和1980年初這段期間，則進一步用於掃描資料上，而這些來自Nielsen，使用這些想法的作者們，是在1984年的時候，第一次變得廣為人知。Fact table因為有一個由兩個或更多個外來鍵所構成的multipart主鍵，所以經常是一個多對多的關係，最有用的fact tables也會包含一個或多個數值的facts，這些facts是為了”定義每個record的keys的組合”而出現的。在圖4-2中，這類facts是Dollars Sold、Units Sold、以及Dollars Cost，在fact table中最有用的便是那些數值的或加總的facts。可加性是相當決定性的因素，因為資料倉儲的應用幾乎從不會retrieve 單一的fact table記錄，而是一次就取回數百、數千、甚至數百萬筆這類資料，而這麼多的records要變成有用，就是要能將他們加總起來。就Dimension tables與fact table的差別來說，它們經常包含描述性的原文資訊。dimension的屬性，是在資料倉儲查詢中，大部分有興趣的限制之來源，事實上，也經常是在SQL answer set中那些row headers的source，在圖4-2中，我們強迫檸檬香味的產品在Product table內，經由Flavor屬性識別，而收音機的促銷在Promotion table中，則經由AdType屬性來識別。很明顯地，在圖4-2的資料庫的全部power，是dimension tables的品質和深度能夠兼顧。Dimension tables是進入資料倉儲之內的登錄要點（entry points）。圖4-2中的資料庫設計的迷人之處，是它對特別的行業之end users有很高的可辨識度。我們已經注意到數百個instances，是終端使用者會立刻同意說這就是”他們的business”。

• The Relationship between Dimensional Modeling and Entity-Relationship Modeling

明顯地，圖4-1和圖4-2看起來相當的不同，許多設計者的反應是認為star join中的資訊應該比較少，或star join僅是用在高階摘要之用，而這兩種觀點都是錯誤的。了解dimensional modeling和entity-relationship之間關係的關鍵是，一個單獨的entity-relationship diagram，打破後進入multiple fact table diagrams之內。試想一個將企業所有可能的商業過程展現出來的大型ERD，它的主ERD可能有Sales Calls、Order Entry、Shipment Invoices、Customer Payments、和Product Returns等，它們都在同一個diagram中。ERD本身的弱點，是在及時的一致觀點下，單一資料集合是無法以一個diagram多個processes共存的。

因此，要將ERD轉換為dimensional modeling diagrams的集合的第一步是，分離ERD到它的不連續商業程序之內，並分別針對每一個進行model。第二個步驟是選擇那些在ERD中包含數值和additive非鍵值facts的多對多的關係，並將它們變成fact tables。第三個步驟是將剩下來的所有tables反正規化，變成flat tables，並透過它們所含的single-part keys來直接與fact tables連接。這些tables就變成了dimension tables。如果一個dimension table連接到一個以上的fact table，我們會將這個dimension table在兩個schemas中都展現出來，而且在這兩個dimensional models間，我們稱這個dimension table為”conformed”。

一個大型企業的資料倉儲，其dimensional model可能包含了10到25個之間，外觀相當類似的star-join schemas。典型的star join，每個都會有5到15個dimension tables，如果設計得當，許多dimension tables將可以從一個fact table到某個fact table被分享利用。微觀（drill down）的applications可以輕易地自一個單獨的star join內加入更多的dimension attributes到SQL的答案集，drill across的applications經由conformed dimensions，可以輕易地將不同的fact tables連接起來。

儘管企業內dimensional model的所有star-join schemas相當複雜，查詢的程序將因為在最低的層次而非常容易預測，我們建議每一個fact table應該單獨進行查詢。

• The Strengths of Dimensional Modeling

用在資料倉儲時，使用ERD有一些好處是達不到的，但使用dimensional model是可以達到的。

首先，dimensional model是可以預測的；標準的架構，包含report writers、query tools、和interfaces，我們都能強力的假設dimensional model能讓使用者介面更易讓人了解；讓程序更有效率。例如幾乎所有使用者所設定的限制的條件均可由dimension table提供，終端使用者可以利用bit vector indexes高效率的瀏覽dimension內的attributes。Metadata可以可以作為指引使用者介面行為的樞紐，可預測的架構在程序上有了很大的益處，比之用optimizer計算查詢成本的方式，dimension tables的資料庫引擎能夠透過偵測一次fact table和對應它的dimension table keys的笛卡爾乘積來滿足使用者的constraints。我們很驚訝地發現，使用這個方法可以單獨透過fact table的索引，可以估計出任何join到fact table的n-way joins。由於DBA們並不了解n-way join的問題其實相當於一個單一的排序合併，所以我們過去都認為n-way joins是很困難的。dimensional model的可預測架構使資料庫系統和終端使用者查詢工具兩者在presentation和performance均相當有幫助。

第二點，即使使用者行為有不可預期的改變，star join schema的可預測架構仍然能夠應付。每一個dimension都是相當的，每一個dimensions都能相稱對等地看成是fact table內的entry points。邏輯設計幾乎可以不考慮預期的query patterns而單獨完成，使用者介面是如此；查詢策略和SQL的產生也是如此。

第三點，dimensional model可平順地擴展來適應新的非預期資料元素以及新設計決定。首先，所有已經存在的tables可以藉由簡單的加入新資料到table中，或用SQL ALTER TABLE命令來進行改變。資料不用重新載入；這各擴展能力的特性也意味著要適應轉變，並不需要以查詢工具或報表工具來重新運算；最後，這個特性也意味著所有以前的applications都能繼續運用，而不會產生不同的結果。在圖4-2中，我們已經標示出1到4的編號，那是我們可以進行平順的改變之處，對應的事情如下：

1.加入新的非預期facts，只要它們與現存的fact table的基礎性質是一致的。

2.完全增加一個新的dimensions，只要這個dimension的單獨值是為了現存的fact記錄而被定義的。

3.加入一個新的非預期的dimensional attributes。

4.將現存的dimension records即時從一個certain point打散到一個粒度（granularity）的較低level。

第四點，在商業世界中有數種標準方法可掌控共通的modeling情況，每一個情況都有一組易於明瞭的方案，可在report writers、query tools和其他使用者介面被明確地程式化。這些情況包含：緩慢改變dimensions，一個如產品或消費者的”constant” dimension，事實上進展是緩慢而且不同步的，dimensional modeling提供特定的技術來掌控這些緩慢改變的dimensions，不過這種dimensions是視商業環境而定的。

異質的產品，如銀行需要在一組單一公用的屬性和facts集合內，一起追蹤一些不同的商業線，但在同一時間，它也需要在高度異質且使用不相容的facts方式下，描述和測量個別的商業線。Pay-in-advance資料庫，儘管商業的交易佔歲入的大部份，但是公司仍需要注意個人的交易如同歲入報告一般。事件掌控的資料庫，fact table通常會變成”factless”。

最後一點，用來維護和使用彙總資料管理的公用程序和軟體程序是會逐漸膨脹的。彙總的資料之所以與基本資料重複存在於資料倉儲，是為了改善查詢效率的。每一個中型和大型資料倉儲的implementation中都必須要有一個管理與維護這些彙總資料的方法或程序。從另一個角度來說，如果沒有事先儲存彙總資料，我們可能需花費大筆金錢用硬體來提昇效率。

所有可用的合計套裝軟體和公用程序均依賴於特定的單一fact和dimension tables的結構，它們絕對依賴於dimensional model，如果不伴隨dimensional的方法，便無法從這些工具中獲益。

第二節PUTTING DIMENSIONAL MODELS TOGETHER：THE DATA WAREHOUSE BUS ARCHITECTURE

資料倉儲最常被討論的主題是如何計畫出一個資料倉儲構造，我們究竟應該畢其功於一役，還事先針對我們需要的部份採漸進式分別完成?我們必須打破兩個迷思：

第一個是認為沒有人相信一個完全統一的方法，也沒有人defend完整的方法。某些業者使用了一些逐步的建構方法建立了整個企業的資料倉儲，這種方式的特殊變化我們稱之為Data Warehouse Bus Architecture。

第二點是認為：data mart是一個資料倉儲高度彙整後的子集合。這種觀點造成許多問題和誤解，在第一章我們定義了data mart是所有資料倉儲的自然完整子集合，每一個有用的data mart應該是由可以被組合和儲存的最細部資料所構成的。

• The Planning Crisis

計畫開發資料倉儲將面臨兩個嚴酷的挑戰，第一個是去了解企業所擁有的資產，它的所在和內容均非常複雜，而且負責新資料倉儲的經理通常被認為在一整夜的時間後，就能變成資料庫所含內容的專家，對每個table的每個欄位都必須了解，資料倉儲的經理必須能取出任何所需資料元素，可能的情況下還需要清洗或更正資料；另一個是資料倉儲的經理被認為在一個晚上就能了解什麼是管理所需要用到的資訊，而資料倉儲又被預期成確實可以回答企業急需知道的問題。當然，data warehouse manager是可以不時地和高階主管討論目前組織的優先順序，只要他能夠非常快速地完成資料倉儲。

為減輕這種令人畏懼的壓力，可先建構data mart來因應。發展data mart時經常忽略了建立將來可以結合所有data mart的架構，市面上販售data mart的產品通常會侷限它的範圍，而且市面上流行的是快速建立的方案，但這對於資料倉儲的管理是十分不利的，因為將它們整合在一起是十分困難的。

孤立的data mart無法使用，可說是資料倉儲整合運作時的毒藥，將失去分析它的機會，因為它無法和其他資料一起比較，它將阻塞企業資料倉儲的發展。所以，如果畢其功於一役的方式建構一個資料倉儲是令人畏懼的，而分別建立時，若產生孤立的data mart，將妨害整體目標，我們應該如何做呢？

• Data Marts with a Bus Architecture

為解決這種困境，在一開始規劃資料倉儲時，我們必須先有一個整體資料建構階段（overall data architecture phase）的規劃，接著再依循這個建構階段逐步將個別的data mart實行，每一個實行均需要依附在這個建構藍圖之上。資料建構階段提供了個別data mart發展的指引，讓它們得以依循，而data mart發展小組也可以不受時間限制地個別獨立地進行工作。當它們完成時，就可以如同拼圖一般將之組合，而確保了資料倉儲的一致性。

任何成功的資料倉儲實行者，一定會執行下面兩個步驟：（一）開發一個環境架構，用來定義範圍和為完成資料倉儲所應進行的implementation。（二）監控那些為了完成資料倉儲的每一個部份的構造。現在我們思考第二個步驟，在建構資料倉儲中最大的工作是設計從legacy system擷取資料到資料暫存區並轉換到最終資料庫中，以提供查詢之用。由於對來源資料的處理是相當大的工作，我們可以一起進行或分開進行，不過data mart最好用一次implement來完成它。

• Conformed Dimensions and Standard Fact Definitions

架構階段是在任何data mart的實行前進行，目的是定義一個facts標準和合適的dimensions，這些標準的結果集合就叫Data Warehouse Bus Architecture，我們假定所有的data mart已經都有適當的dimensional設計，相關的key均完整對應，變成了一個star join的架構。

一個conformed dimension是表示對於所有可能join此一dimension的fact table而言，它都有相同的意義。一般而言，conformed dimension在每一個data mart均相同，例如消費者、產品、位置、交易（促銷）、日期（時間）等。中心資料倉儲設計小組的主要責任是確立、公佈、維護和實施conformed dimensions。確立conformed dimension是相當重要的步驟，例如一個conformed customer dimension是customer經過淨化，包含消費者的key、最佳維護屬性等，用來描述消費者的主要table。它是經過合併而且是去蕪存菁的資料。conformed dimension對資料倉儲而言是非常重要的。如果資料倉儲不是精確的依附在conformed dimensions上，將很難達成資料的完整性。

如果不使用conformed dimensions，將來資料可能無法一起運作，甚至運作以後產生錯誤結果。conformed dimensions使以下的事情變成可能：

• 在同一個資料庫環境下，單一的dimension table就能提供多個fact tables使用。

• 不管何時使用dimension，使用者界面和資料內容可以一致。

• 屬性可以有一致的解釋。

• Designing the Conformed Dimensions

設計conformed dimensions的工作通常都需要花費數週的時間，一般來說，大部分的conformed dimensions都自然被定義好了，例如customer dimension自然是每個消費者個人，product dimension自然是來源系統可被追蹤的最低層次的產品，time dimension則通常是每個獨立的日期。conformed dimensions總是有一個代替的資料倉儲鍵值，它不是來自legacy系統，有許多理由讓資料倉儲鍵值與產品互相獨立，產品系統的管理目的和資料倉儲是不同的。

• Establishing the Conformed Fact Definitions

至目前為止我們討論了用conformed dimensions將所有的data marts整合在一起，這部份大約佔了整個資料架構工作的80%，剩下的20%則是用來發展conformed fact的定義工作。

幸運的是，它的定義工作會在conformed dimensions完成定義的同時完成。當我們經由data mart使用相同的術語，以及當我們建構一個drill across data mart的single reports時，我們會需要conformed fact的定義。

必須被conformed的facts如歲入、收益、標準價格、和標準成本等，只要得自這些facts而且名稱是相同的，就必須均是相同的值。這些conformed fact定義需要被定義在相同的dimension context以及每個data mart中與它相同的units之內。歲入與收益必須在相同的時期和地區進行報表產製。

有時不同fact tables中的fact會有不同的衡量單位，例如典型製造的價值鏈可能是用製造業者的貨櫃來衡量，但它又必須在零售時用貨物單元來衡量，即使所有的dimensional均考慮了且正確的計算了，仍然很難在drill-across report中同時使用這兩種不相容的衡量單位。一般的解決方案是由使用者轉換埋藏於產品dimension table的因素，並期望使用者發現轉換因素而正確地使用它。這是令人無法接受的overhead，正確的解決方案是將貨櫃fact和產品單元fact都放入manufacturer’s table中或manufacturer’s table的view中。

如果很難甚至不可能明確地conform一個fact，要確定針對不同的解釋，給予不同的名稱。當產製財務數值報表時，一個類似的衡量單位衝突將會發生，歲入是相當重要的衡量，但是它也能有些微不同的解釋，例如我們必須區分月末收入與Billing Cycle Revenue，最嚴重的誤解就是將兩者都叫做歲入。

• The Importance of Data Mart Granularity

Conformed dimensions通常都是最小的單元，因為他們的每一筆資料相當於是單一顧客、產品、天的描述。換句話說，在每個data mart的base level fact tables必須是相當於所有組成dimensions的最低層次。

Granular fact table data有很大的power和彈性。Data mart的基本資料若是保持在最小的單元，將幾乎不受改變的影響。“Gracefully extended”是dimensional modeling approach的重要特性，它表示在加入新的來源facts、來源dimension的attribute、或整個dimensions等轉變發生時，所有舊有的queries和applications仍可使用，而且沒有任何fact table被drop掉或reload，也沒有key需要改變。

• Multiple-Source Data Marts

一個成功的單一來源data mart之實行，將可提供使用者有價值的資料，使user感到滿足。當數個單一來源的data mart已經實行完成後，接下來就是將它結合在一起，典型的多來源data mart是關於企業收益的data mart，它將個別的收入和成本整合而得到企業收益性的全貌。它可經由將產品維度roll up的方式，而產生不同產品的收益性；也可以經由將促銷維度roll up而知道不同促銷的收益性。在第一次嚐試時不要立刻就去建構完整的收益性data mart，否則你將淹死在撰寫粹取程式中。

之後，當你有時間去正確地了解成本細節的來源，你可以建構一個Activity-Based Profitability multiple source data mart來取代你的single-source data mart。如果你不得不將收益性帶入你的第一個data mart，你最好以簡單的經驗法則估算成本，而不要進行了解所有底部成本細節來源的工作。

• When You Don’t Need Conformed Dimensions

如果有數條不同的產品線，而其消費者和產品不需要合併查詢，也沒有將它們一起管理的需求，又很少有要緊密結合這些商業來建立資料倉儲的情況，例如，如果有一組凝聚的商業，它的子公司跨越了食品業、硬體業、和服務業，它們的資料可能就不適合共享，這時它們的資料倉儲最好是分別建立。

• The Data Warehouse Bus

Conformed dimensions和conformed facts是資料倉儲的”bus”，bus這個字是來自發電廠的老術語，而現在它則普遍用於計算機產業。bus是一個公用的結構，所有的事物均與之相連且從它那兒獲得power，bus在計算機中是標準的的介面，它允許許多不同種類的設備透過它與計算機相連接，而每個設備也能並存且有效的在計算機中使用。

從這個section我們可以明顯知道conformed dimensions和conformed facts是扮演資料倉儲中的bus角色。幾乎可以確定地，新的data mart將自bus得到power，因為bus提供了標準dimensions和平行facts的陣列，它可以增進新的data mart的表現。

第三節BASIC DIMENSIONAL MODELING TECHNIQUES

本節討論dimensional modeling的通用狀況，而非特殊的例子。

• Fact Tables and Dimension Tables

dimensional modeling 的基本想法是每種商業資料都可以一種cube的資料型態表示，每一個cube的cell包含measured value，cube的每一個邊（edge）是自然的資料的維度。當然可以有三維以上的cube，稱為hypercube。

真實商業世界的dimensional model常包含4~15個維度，少於這個數量會讓人懷疑是否太少；若超過20個則不易解釋，宜與予合併。維度數目的決定最好是配合現實商業環境，而非設計著的喜好。

• Facts

Fact通常是我們事先不知道的某件事，是商業界中一個觀察的資料，通常是數字。所以設計者要先預設很多數值的資料欄位，尤其是浮點數。

• Fact table

存在著我們所需要的真實資料，其內容是我們所要分析的數值，例如銀行的交易記錄及產品的銷售，其他包含資料的計算結果如每個地點每個月的銷售量，Fact表格中的資料內容是無法修改的，只能新增資料到表格中而已。

因為在這個表格中包含資料倉儲中最主要的資料，在資料被呼叫到表格前就應該把它的資料結構設計正確。在設計這個表格時如果您認為原來的資料表格無法保證在決策支援的查詢下有正確結果的話，那您必須將原來表格重新結構化。Fact表格應有如下特性：

• 大量的資料列，可能達到十億以上。

• 主要都是數值資料，只有少數的文字資料。

• 許多和Dimension表格連接的外來鍵（Foreign Key）。

• 靜態資料

• Attributes

和fact相比attributes通常為文字欄位較多，通常描述有形物體的特徵，最多的是有關於產品的描述，例如產品保裝上所顯示的資料，如味道、顏色、組成成分。這些資料都是預先會知道的。

• Dimensions

dimensions是一些高度相關的 text-like attributes的集合，系統到底要有哪些的dimensions在某種程度上是由分析師決定的，我們也可以考慮把若干個dimensions合併成一個dimension。例如我們有1000個product以及100個store，我們可以產生合併的dimension為 product-store。如果合併後的product-store dimension共有100000筆資料，則合併後的dimensions和原始的dimensions所產生的資訊是相同的，我們即不予合併，因為效率較差，而且使用者介面上也無優點。如果合併後的product-store dimension只有2000筆資料，則不但資料較精簡，且也隱含了一些有趣的訊息，這樣的合併就非常有用，設計者可以使用count distinct operations來檢驗兩者是否相關。

• Dimensionstable

此表格的資料是用來參考Fact表格資料的，例如產品、客戶名稱、住址及供應商….等，透過某些事件的需求將一些煩雜敘述分割成幾個小部份，例如某個時點的銷售量等，盡量藉由這些表格的設計減少對Fact表格的讀取將查詢最佳化。

Dimension表格沒有包含像Fact表格中那麼多的資料列，且其中的資料是可以修改的，其有以下的特性：

• 其資料少於Fact表格，可能只有上百或上千個資料而已。

• 大都為文字資料。

• 欄位會較多，其是用來管理Dimension的階層（hierarchies）。

• 只有一個主鍵（Primary Key或Dimension Key）。

• 資料可以修改。

Star架構的設計可以藉由減少磁碟存取次數來幫助我們增加查詢效率，查詢分析資料列較少的Dimension表格來得到關連到Fact表格中的Dimension鍵，如此可以減少所需要讀取的列數。

• Inside dimension tablesdrilling up and down

drilling down的意義是提供更詳細的資料，例如從現存的查詢中增加新的欄位，drilling down是資料倉儲的drilling中最早使用的方法。

在dimensional model 中，dimension table 中的attribute扮演重要的角色，這些attribute是文字的或類似文字，而且是application限制的的來源及最終報表的欄位名稱。我們可以從 dimension table 拉出一個attribute成為一個欄位名稱，或將不同dimension table中的不同attribute組合成不同欄位。

這些動作可以用SQL中的select加group by或再加上order by排序即可完成。在特定的dimension中，以product dimension為例，財務部門及行銷部門對於產品階層分類會有不同看法，因此要能讓使用者自己選擇階層及其他與階層無關的attribute。

Rollup是減少資料欄位。一般而言增加或減少row header都需從新執行一次join query。在high level及low level 執行bringing back效率是不同的。

• 瀏覽器的重要

browsing的意義是檢驗dimension table中的attribute之間是否有關聯。一個好的browser能讓使用者探勘不熟悉的dimension table並能顯示出之間的關係。

在dimension table所設定的一些限制條件應能影響browse request的結果。browse過程中所設定的一些限制條件應能被儲存下來，以供將來再查詢或製作報表使用。

• Permissible Snowflaking

在資料倉儲的環境中不建議使用雪花狀，因為會讓使用者難以表示及難以理解 、分析，而且會使browse時更慢。雪花狀的效率是很極端的，在某些狀況很差，在有些狀況又很好。有些DB設計者使用雪花狀是為了節省空間。另一個不用雪花狀的原因是因為會妨礙bitmap indexes。

• The Importance of a High-Quality Verbose Attribute

一個資料倉儲品質的衡量通常以 dimension attribute的品質為依據。一個理想的dimension table應包含許多描述個別dimension的文字欄位。這些文字欄位包含個別的詳細的字或簡短的片語，而非代碼或縮寫。

資料庫設計者常說服使用者使用或接受代碼。資料倉儲小組一個主要的責任是確保代碼轉成全文字的品質。全文字的attribute有助於理解browse的結果及最終的報表。

資料倉儲小組在製作dimension table attributes應達成以下目標：

• verbose (全文)

• descriptive (描述性的)

• complete (沒有遺失任何值)

• quality assured (沒有錯誤、不可能的值)

• indexed (可能用B-tree或bitmap )

• documented (每一個attribute都有說明或解釋)

• 推薦的時間維度

時間維度在資料倉儲中扮演重要地位，因為資料倉儲的fact table是時間序列的觀察值。在fact table中通常有一種以上的時間維度。利用圖4-3的方式可以轉換各國的日曆，也可包含各國的假日、月份名、日期名稱等。

• 個人姓名與地址資料的建議格式

現今很多人名及住址的儲存方式都太簡單及缺乏結構化，而這些資料對於消費者分析是非常有助益的。一個好的姓名及地址可以分解成許多部分，設計的原則是將姓名及地址盡可能的細分詳細，如此即容易有一統一的且符合國際準則的郵寄地址，也容易以地址來對地理位置進行區分方便分析。

圖4-3：

• 商業客戶地址的建議格式

商業客戶資料和一般的個人不同，通常會有複雜的名稱及多個住址。例如會有地區分公司、總公司、母公司等。範例為下：

1.organization name

2.post name

3.post name abbreviation

4.role

5.street name

6.street type

... ...

... ...

... ...等等。

• Degenerate Dimensions

很多維度的設計依循著一些控制文件如訂單、發票、出貨單等，通常這些文件包含著一連串的資料項目，以訂單為例就有時間、客戶、貨品名稱、數量、送貨地址等資料，而這些即是fact table的紀錄。在此例中，我們最適合的儲存顆粒度是以訂單中的每一訂購項目（line item）為基本儲存單位，也就是fact table記錄訂單中的不同訂購項目，而dimension table自然也必須根據不同的訂購項目來設計，如此藉由描述每一項目我們可以很快得到所需的維度（dimension）。

在此例中，我們會把原先order中的其他屬性搬移到其他直接參照line item table的dimension，最後可能會造成order所有的屬性都被搬走了，而在line-item fact table中，我們雖然還有order number屬性，但order number將無任何attribute，稱為degenerate dimension。

• Junk Dimensions

從複雜的資料來源萃取資料後會留下許多難以理解的旗標(flag)及text attribute，設計者有很多解決方案，但需避免：

• 把flag及text attribute留在fact table紀錄中：因為會造成fact table紀錄的定義驚人的增加。

• 使每一個flag及attribute都存入各自不同的dimension中：原因同上。

• 將flag及attribute刪除：假使flag and attribute 和某些交易有關係，則會產生錯誤。

解決方法是仔細研究flag and attribute ，並將flag and attribute 整理並集合存於一個或以上的junk dimensions中。

• Foreign Keys、Primary Keys and Surrogate Keys

在資料倉儲中的所有keys都必須是無意義的代用鍵（surrogate key），而不使用原始產品、資料的key。我們假設所有的代用鍵是簡單的整數，而且是由資料倉儲的管理者所給予的。他本身並無任何意義。一般是使用4-byte integer來作為surrogate key。

• Surrogate Sate Keys

用SQL-based 的時間stamp作為join fact table and time dimension table的key有兩個明顯的錯誤：

1.浪費4-byte的空間，因為SQL-based 的時間stamp通常為8-byte

2.無法直接join time table和在fact table的date key

• Avoid Smart Keys

資料儲倉的設計者要避免有包含特殊意義的smart keys，換言之，要避免由不同的attribute組成dimension的primary key。因為會造成join時很大的負擔，所以應該再分解不同的欄位。

• 設計個別fact table 的四個步驟

dimensional schema 的詳細邏輯設計可分為四個步驟：

1.the data mart：選擇資料超市

2.the fact table grain：選擇fact table的顆粒度

3.thedimensions：選擇維度

4.the facts：選擇fact

Step1.選擇資料超市：單一資料來源及多重資料來源的資料超市

選擇資料超市最簡單的狀況就像選擇資料來源一樣，典型的資料超市包含有銷售訂單、裝運資料、零售資料、付款、客戶資料等。為降低發展風險建議由單一資料來源開始，如此也可以減少從現有系統粹取資料的工作量。

Step 2.選擇fact table的顆粒度：fact tables的形式

必須清楚的定義 fact table顆粒度，絕不可省略此步驟，必須能回答；what is a fact record, exactly ?"。顆粒度的選擇是越小越好，優點是可以應付各種不預期的查詢，而且可以加總成較大的顆粒度。facttable的資料來源及顆粒度的選擇有以下可能的來源：

• 銷售紀錄可以是factrecord

• 保險公司的保單可以是factrecord

• ATM的交易資料可以是factrecord

• 每一家店每天銷售總計可以是factrecord

• 每月的會計帳資料快照可以是factrecord

• 每一筆訂單上的資料可以是factrecord

• ﹍﹍

• ﹍﹍

• ﹍﹍等等。

以上種種的資料來源可以分為三種最有用的facttable grain：

• 個別交易資料

• 高階的快照資料

• 控制文件上的資料項目

Step 3. 選擇dimensions

一旦fact table的grain確定後，維度的選擇就變的十分簡單、直接，grain本身常會決定基本或者最小集合的維度，其他額外的維度如：運送方式、訂購狀態、送貨日期可由設計者自行判斷。

Step 4.選擇fact

fact是fact table中的具體、特定grain。fact table的grain決定了哪些fact要要加入fact table中，也清楚定義每個fact合法的範圍。

第五章資料倉儲資料庫之設計

第一節決策支援資料庫

決策支援系統（DSS）被設計為允許用來快速而容易的分析所萃取到的資訊，通常被分析的資料以日、週或年為單位。某些DSS的範例包含了分析銷售收入、行銷資訊、保險索賠和客戶資料等的應用。這些系統提供用來管理企業之商務分析和計劃所需的資訊。

DSS擁有以下的特色：

• 可瞭解性：資料的結構必須是很容易被使用者所理解的。

• 大多數的靜態：當資料根據預先定義的行程被載入，資料庫絕大多數的改變都發生在被控制的規則之下。

• 不可預測性和複雜的SQL查詢。

• 高階的商務測量通常需要多個SQL敘述。

• 必須支援多個、大的而反覆的結果集合。

• 可復原性：規律性的備份，以確實防止靜態資料的流失。

第二節Star Schema的資料庫設計

決策支援資料庫的目標，通常是透過使用一種稱為Star Schema的資料庫設計來達成。Star Schema設計是一種簡單的結構，擁有相對較少的table和完整定義的join path。這種資料庫設計相對於使用正規化結構的交易處理資料庫，提供較為快速的回應時間和較為簡單易懂的Schema，這些在資料倉儲的結構中是不常見的。

1.使用Star Schema的好處：

在data modeling和實體資料庫設計之前，最好先決定使用Star Schema 或者傳統的關聯式資料庫設計。在這兩者之中，你都可以透過解正規化和資料分割來使其效能最佳化。不過，使用Star Schema還是可以提供了一些傳統關聯式資料庫結構所不能提供的好處。Star Schema 常被資料倉儲資料庫所採用，其原因如下：

• 建造一個可提供較快回應時間的資料庫設計。

• 為了產生較佳的執行計劃，在一個更簡單的資料庫設計中，允許最佳化作業。

• 在資料庫設計中，考慮終端使用者通常如何使用資料。

• 簡單化發展者和終端使用者對metadata的瞭解及探索。

• 增加前端存取工具的選擇，如同某些產品需要以Star Schema設計。

2.瞭解Star Schema設計

一個Star Schema包含兩種table：Fact tables和Dimension tables。Fact tables又稱之為major tables,包括所需的定量或定性的商業資料。Dimension tables有時又稱為minortables，較小，且擁有描寫反映商業的重要性的資料。SQL查詢利用使用者預先定義介於fact table和dimension table之間的join paths，以限制其傳回所選擇的資訊。

舉例來說，在一個銷售資料庫中，一個fact table包含了在每個統計市場、每一段時間，每個產品對於每個客戶的銷售收入。Dimension table在這個資料庫中則定義了在fact table中被使用到的顧客、產品、統計市場和時段資料。

一個經過仔細考慮的schema所提供的dimension table允許使用者任意的瀏覽資料庫中的資訊。使用者可以使用限制查詢，使其只回傳滿足限制條件的資訊。

第三節Star Schema的種類

1.Simple Star Schemas：

每一個table必須擁有主鍵，主鍵可為單一欄位或由數個欄位所組成，每一列（值組）的主鍵都必須是唯一的。在Simple Star Schema中，fact table的主鍵是由一或數個外來鍵所組成，而每個外來鍵皆是由另一個table的主鍵定義出來的欄位。當一個資料庫被建立起來，被用來建立table的SQL敘述將指定哪些欄位是主鍵和外來鍵。

圖5-1描述了fact table和dimension table之間的關係。此一圖形包含了一個fact table和三個dimension table，其中fact table擁有一個由三個外來鍵（KEY1、KEY2、KEY3）所組成的主鍵，此三個外來鍵皆為其中一個dimension table的主鍵。

圖5-1：

圖5-2描述了一個使用Simple Star Schema來設計的銷售資料庫。在fact table中，主鍵是由三個外來鍵（Product_Id、Period_Id、Market_Id）所組成，其中每個外來鍵皆是參照三個dimension table之一中的主鍵。

圖5-2：

要注意fact table中外來鍵和它們所參照到的dimension table中的主鍵之間的關係是多對一的。舉例來說，Product Table中定義的是產品，因此每一個值組所表示的是一個不同的產品，也擁有唯一的產品識別碼。產品識別碼在Sales Table中可以出現很多次，表示特定的產品在每一個時段和每一個市場的銷售。

2.Multiple Fact Tables：

有更多複雜的資料庫實作可能需要使用到多個fact table。在某些案例中，由於包含術個無關的事實或使用不同的時間週期，因此存在多個fact table。舉例來說，內部的出貨資料需要以週為單位，但所提供的資料卻是以每四週為單位，所以必須為了這些不同的事實分割表單。另一個案例中，多個fact table存在是為了改善效率。舉例說明，多個fact table通常被用在掌握總合資料的不同階層，尤其當總合的數目非常的龐大時，使用不同的分別來存放銷售的日資料、週資料以及年資料。為不同階層的總合資料建立不同的表單對資料倉儲來說是相當普遍的設計技術，使得單一的需求可對映至一個合理大小的表單。

圖5-3描述了以額外的fact table記錄先前的年銷售資料的銷售資料庫。

圖5-3：

Fact table的另一個功能是定義某些商業構面之間的多對多的關係。舉例說明，在銷售資料庫中，每種產品屬於一或多個群組，而每個群組包含多種產品。一個多對多的關係透過建立一個fact table來定義產品和群組的組合。圖5-4描述一個新的fact table被建立以表示不同構面間為對的關係。

第四節範例（沙拉醬銷售）

此範例說明了schema的設計如何影響資料庫的可用性和有效性。此資料庫追蹤了沙拉醬產品在超級市場的銷售，以週為區間，為期四年，是一個典型的客戶-產品行銷資料庫。

圖5-4：

圖5-5：

沙拉的種類共有14,000種，資料為120個位於美國的統計區（市場）和為期四年中的208週彙總而來。

此沙拉醬銷售資料庫包含一個fact table（Sales）和三個dimension table（Product、Period和Market），如圖5-5所示。在Sales fact table中的每一個值組都包含了三個外來鍵，分別來自Product、Period和Market三個dimension table，並足以識別Sales table中唯一的值組，因此這是一個simple star schema。Salestable還包含了七個額外的欄位，其值為關於市場分析的測量內容。

每一個dimension table描述一個商務構面，並且包含了一個主鍵和數個描述此構面的屬性欄位。透過瀏覽dimension table，瞭解可用的資料。為了下達有效的查詢命令，使用者必須熟悉資料庫的內容。找出特定維度值的範圍可以使用一個方便的方法，就是對此dimension table下查詢。舉例來說，想知道銷售資料的市場資訊，可以下達：

SELECT market_desc FROM market

將會顯示出所有的120個市場資料。類似的查詢也可以使用在product和period兩個table上。

WHERE子句的語法可以縮小瀏覽的範圍至特定感興趣的像目上，舉例來說，如果使用者只對Kraft生產的沙拉醬有興趣，則可利用WHERE子句來過濾特定的製造商，限制product table中只有Kraft的產品資訊才會顯示出來。在dimension table中瀏覽比在fact table中下達SELECT DISTINCT敘述來得快速，尤其是在facttable擁有大量的資料時。

• 使用表單中的屬性

在dimension table中的非主鍵欄位，被稱之為屬性。為了瞭解屬性如何被使用，讓我們考慮沙拉醬資料庫中的product table，有1400筆資料在其中，並以主鍵加以識別，識別元允許使用者取回唯一的值組。Dimension table中其他的屬性則允許其子集存在差異化。

舉例來說，屬性brand使得14000種沙拉醬產品的brand存在差異，因此使用者可以只選擇特定brand的產品，使用者可以透過Class、Flavor、Size和Manufacturer屬性在Product table中選取特定工廠生產的特定等級、特定大小包裝及特定口味的沙拉醬以分析沙拉醬的銷售。

• 創造屬性的階級制度

資料雖然看起來不一樣，但卻相當近似，遠眺允許終端使用者將資料分析至細部的階級當中，這是提供答案所必要的。從較高的階層透過不同的維度向細部的視界觀看資料，稱為drilling down，反之，從細部的階層向較高階層觀看資料，則稱為rolling up。資料庫的設計將決定可以drill down和roll up的能力。

終端使用者通常希望在相同的資料上看到不同的觀點(perspective)，舉例來說，你可能觀看跨城市的特定產品銷售量，然後想要依區域將資料分解。觀看區域的資訊可能會顯示不一致的銷售，所以需要更多的資訊，因此drill down到銷售的區域補充區域的資料，再去觀察哪些地方的銷售被疏忽了。Drilling down允許我們取得更接近更細部階級的資料。

一個設計良好的star schema，在dimension table中將包含這些階層。多階層也可以表示在一個單一的表單中，舉例來說，在一個關於地理區域資訊的表單中，分割地理階層，一個實體地理和一個組織銷售地理，可以表示在相同的表單中。這些屬性可以當作限制的基礎。圖5-6顯示在一個維度中的多屬性階層，用來對資料drill-down和roll-up。

圖5-6：

一個好的star schema設計，可以幫助使用者依照他們直覺的瞭解去下查詢，並且減低資料庫管理者的負擔。

第五節AGGREGATION

Aggregation是一個沿著事先定義屬性的累積資料過程，舉例說明，你可以透過細部階層的項目累積銷售，創造一個區域或部門的銷售摘要，在資料庫設計的背景中，你必須決定在資料轉換過程中建立總計和將預先計劃好的資料放入資料倉儲中。建立預先儲存的總合的主要驅動力量為：

• 改善終端使用者的查詢效率

• 減低CPU cycle使用的總次數

如果在一年之中只被使用者使用一次，則花兩個小時去建立預先儲存的特定總合是不合理的，反之，若相同的集合體一天被使用三百次，則這個程序將對你的作業系統有不利的影響。在這個案例中，預先儲存的集合體將受到保障，你應該在資料轉換過程中建立它，並將其載入資料庫中。圖5-7顯示了預先儲存的集合體表單，其跨越了地理及產品兩個維度。

圖5-7：

將屬性的各種組合都預先儲存其集合體是沒有必要的，為了要瞭解在資料倉儲中哪些是要預先儲存的，我們除了必須考慮使用者存取的頻率，也要考慮到值組總數的潛在變化。舉例來說，在圖5-8的表單中，可能有一個fact table擁有10,000,000個值組，如果你集合了細部階層的區域項目，你可能會得到9,000,000筆資料，如果你集合了市場的細部階層資料，你將只得到1,000,000筆資料。在這個案例中，不要儲存區域項目的資料，但要保留下市場項目的資料。只在被選擇階層的概略資料被稱為稀疏集合體(sparse aggregation)。透過選擇適當的集合體階層，資料倉儲將可達到查詢效率及磁碟儲存的最佳化。

圖5-8：

最後要說明的概念是當載入一個資料倉儲時，還是需要使用到某些傳統的資料庫技術，如實體表單分割等。這對於擁有數百GB資料的資料倉儲來說，顯得相當的重要，圖5-9顯示了一個分割集合體策略的範例，在此只有最大的集合體被分割。

• Star schema的限制

在資料倉儲資料庫的設計中，我們必須瞭解到star schema並非萬能的，雖然有許多的決策支援環境非常適合用star schema來設計，但也有某些案例star schema並非最佳的資料庫設計技術。Star schema的方法最初是在零售及客戶包裝產品業的決策支援資料庫中發展，在這些環境中，star schema幾乎可以良好的運作，這是因為在這些產業中，dimension table（如：product、period和market）比起sales fact table小得多。

圖5-9：

當一個dimension table的屬性及值組相當多時，千萬不要嘗試用star schema來設計，我們看過資料庫中描述客戶的資訊被解正規化到細部的交易記錄，並堅持以star schema來設計，根據儲存成本、可用性及效能的角度來看，這是一個相當大的錯誤。有一個典型的範例，一個擁有相當多的客戶的大企業，有效的使用了star join查詢技術，大量的客戶屬性解正規化至每個細部的記錄，將造成fact table大小的激增。

你應該感覺不到資料倉儲資料庫的設計適用某些預定的公式，其成功的關鍵因素，在於資料庫的設計基於成功的決策支援環境之商業考量，而非信賴技術的萬靈丹。不要害怕改變star schema以使其更適合你的商業需要。舉例來說，圖5-10的預約資料庫使用一個multi-star schema的設計，其中Frequent_Stayers、Actuals和Bookings table提供了主要的市實以供分析。

第六章資料倉儲資料庫的設計範例

一系列特殊的範例顯示如何將此章所提到的許多不同的概念應用在真實的環境裡。

圖5-10：

1. 預約資料庫：

圖5-10描述了一個multi-star schema，其主鍵和外來鍵並沒有合併到相同的欄位集合，這樣的設計也包含了一個fact table的族群（Booking table、Actuals table和Promotion Schedule table）。這個資料庫追蹤了預約和旅館租用的資訊，也維護了顧客、促銷和連鎖店中的所有旅館。

圖5-11：

2. 投資資料庫：

圖5-11為一個投資基金銷售的資料庫範例，以日和月為基礎，其中也包含了客戶組織、投資基金和不同交易程式的資訊。

這個範例描述了使用一個簡單的schema來掌握aggregation，日資料存放在一個表單中，並且集合資料到另一個表單中，以代替合併兩個集合階層到一個表單中。

第六章以 SQL Server 建立「星狀架構」資料倉儲

在此我們先假設一個車商TOYOTA的OLTP 資料庫

其部份關連圖如下

各表格的部份資料為：

Models

Model Price Import

Tercel 450000.0000 國產車

Premio 600000.0000 國產車

Corolla 700000.0000 進口車

Camry 1000000.0000 進口車

Solemio 750000.0000 國產車

Zace 500000.0000 國產車

Avalon 1500000.0000 進口車

Lexus 2000000.0000 進口車

Retailers

Retailer Region

Taipei North

Chungli North

Toayuan North

Tainan South

Kaoshiung South

Taidong South

Sales

OrderNo Retailer Model SalesDate Qty

1 Taipei Tercel 1999-12-25 1

2 Kaoshiung Solemio 1998-11-28 2

3 Tainan Lexus 1998-11-15 1

4 Chungli Premio 1998-05-19 2

5 Taidong Tercel 1999-02-28 2

6 Taoyuan Zace 1998-04-19 1

7 Tainan Solemio 1999-02-23 1

8 Chungli Solemio 1999-01-17 1

9 Taoyuan Avalon 1998-04-02 1

10 Taidong Premio 1999-05-15 1

: : : : :

: : : : :

49871 Tainan Avalon 1998-07-23 1

49872 Taipei Solemio 1999-12-08 1

49873 Taipei Premio 1999-12-26 2

49874 Taoyuan Avalon 1999-08-02 2

49875 Taipei Avalon 1999-03-18 2

49876 Kaoshiung Premio 1998-07-27 2

49877 Taipei Zace 1999-03-06 2

針對Decision Support 之需求，我們可能需要查詢一些銷售狀況的資料，如：

一、一九九九年五月份、北區的進口車銷售量為何？

二、一九九八年、中壢營業所的營業額為何？

三、一九九九年各月份、各營業所、各車款的銷售量為何？

類似這樣的問題，OLTP 資料庫通常要經過非常繁複的彙總運算才能得到解答，而資料倉儲主要的目的就是要解決這一類的需求。

以下我們將分為兩個部份來說明以SQL Server 來建立資料倉儲：

（一）建立資料倉儲的Dimensional Model

包括建立Star Schema、Fact table、Dimension table

（二）資料彙總與載入

1. 建立資料倉儲的Dimensional Model

(1) 決定維度

車款（Model）

(2) 維度階層

地區（Region）

車款（Model）

(3) Star Schema

首先決定Fact Table：

由於Fact table 通常取最基本的單位，所以我們將Fact 定為每一筆交易。

sYear

sMonth

Retailer

Model

Quantity

TotalPrice

Fact Table

接下來再定義Dimension tables

Dimension 有車款（Model）、營業所（Retailer）、時間（Time）

Sales_Fact

Retailer

Region

sYear

sMonth

Retailer

Model

Quantity

TotalPrice

sYear

sMonth

Model_Dimension

Model

Import

Star Schema

（二）資料彙總與載入

(1) 建立各Dimension Table，並載入Dimension Table 的資料（註1）

• Retail_Dimension

CREATE TABLE Retail_Dimension

( Retailer varchar(12) PRIMARY KEY,

Region varchar(12)

)

INSERT Retail_Dimension

SELECT Retailer, Region FROM Retailers

• Model_Dimension

CREATE TABLE Model_Dimension

( Model varchar(12) PRIMARY KEY,

Import varchar(8)

)

INSERT Model_Dimension

SELECT Model, Import FROM Models

• Time_Dimension （註2）

CREATE TABLE Time_Dimension

( sYear int,

sMonth int,

CONSTRAINT pk_Y_M PRIMARY KEY ( sYear, sMonth )

)

INSERT Time_Dimension

SELECT DISTINCT

YEAR( SalesDate ), MONTH( SalesDate )

FROM Sales

(2) 建立Fact Table，並載入資料

• Sales_Fact

CREATE TABLE Sales_Fact

( sYear int,

sMonth int,

Retailer varchar(12),

Model varchar(12),

Quantity int,

TotalPrice money,

CONSTRAINT pk_sY_sM_R_D

PRIMARY KEY ( sYear, sMonth, Retailer, Model )

)

INSERT Sales_Fact

SELECT Retailer, s.model, YEAR( SalesDate ),MONTH( SalesDate ), SUM( Qty ), SUM( Qty * m.price ) FROM Sales s JOIN Models m

ON s.model = m.model

GROUP BY Retailer, s.model, YEAR(SalesDate), MONTH(SalesDate)

註1：本範例使用Microsoft Transact-SQL。

註2：在本範例中，如果Time_Dimension 中沒有其它階層，

因為在Fact Table 已表達此事實，其實可以不需要Time_Dimension。

經由資料倉儲支援決策分析：

一、一九九九年五月份、北區的進口車銷售量為何？

SELECT SUM(Quantity) AS '北區, 1999 五月, 進口車'

FROM Sales_Fact s JOIN Retail_Dimension r

ON s.Retailer = r.Retailer

JOIN Model_Dimension m

ON s.Model = m.Model

WHERE r.Region = 'North'

AND s.sMonth = 5 AND s.sYear = 1999

AND m.Import = '進口車'

二、一九九八年、中壢營業所的營業額為何？

SELECT SUM(TotalPrice) AS '1998, 中壢營業所, 營業額'

FROM Sales_Fact

WHERE sYear = 1998

AND Retailer = 'ChungLi'

三、一九九九年各月份、各營業所、各車款的銷售量為何？

SELECT sMonth AS '月份', Retailer AS '營業所', Model AS '車款',

SUM(Quantity) AS '銷售量'

FROM Sales_Fact

WHERE sYear = '1999'

GROUP BY sMonth, Retailer, Model

維護資料倉儲的資料：

資料倉儲內的資料除了建立時的淨化、彙總、載入之外，還有一部份很重要的工作，就是倉儲的維護管理。以TOYOTA 範例資料庫而言，前述的步驟主要是介紹倉儲的建立與資料載入，以下的部份就針對資料倉儲的維護作一簡介。

可能的需求與問題：

一、隨著時間變化，倉儲內的資料需要更新，例如現在是西元2000 年五月，倉儲內的資料應該要能夠要涵蓋至2000 年四月。

二、若是每次將資料寫入倉儲時都讓系統重新彙總資料（把載入Sales_Fact 表格的敘述重新執行），雖然能夠確保倉儲內的資料是最新狀況，但是這種作法非常沒有效率。

三、這樣的工作應該要讓系統幫我們完成。

步驟：

一、由於我們的倉儲資料是以月份為基本單位來統計銷售量及營業額，所以我們可以訂定每個月的第一天要將上個月的銷售資料寫入倉儲中，不需要重新彙總倉儲內的資料。SQL 敘述如下–

INSERT Sales_Fact

SELECT YEAR( SalesDate ), MONTH( SalesDate ),

Retailer, s.model, SUM( Qty ), SUM( Qty * m.price )

FROM Sales s JOIN Models m

ON s.model = m.model

WHERE

MONTH(SalesDate) = MONTH(DATEADD(mm,-1,GETDATE()))

AND YEAR(SalesDate) = YEAR(DATEADD(mm,-1,GETDATE()))

GROUP BY YEAR(SalesDate), MONTH(SalesDate), Retailer, s.model

二、利用SQL Server 提供的Data Transformation Services 建立DTS Packages。如下圖：

三、新增Connection ；

設定Connection Properties –

(1) Connection Name；(2) Data Source；(3) Server；(4) Database

四、新增Execute SQL Task ；

設定Execute SQL Properties –

(1) Description；(2) Connection；(3) SQL statement

五、儲存DTS Package

六、Schedule Package

七、設定Recurring Job Schedule

八、大功告成。

第七章結論

當越來越多的公司了解每日所產生的資料也是重要資產時，他們便會越來越依賴資料倉儲系統。但是除非資料倉儲能提供經理人的問題或資料解答，否則它不能自動地為公司生出更多的利益。好的技術和好的經營一樣重要。資料倉儲系統會變成有價值的戰略工具或昂貴又大而無當的玩具，不僅取決於技術能力，在組織上如何使用它也一樣重要。

所有大組織都有資料倉儲，如果不好好的加以管理，成長會很快，所以資料倉儲需要小心管理。資料倉儲是好投資，可以使用目前的技術讓使用者能更快速更便宜，找到最重要資訊。事實上，經驗表明資料倉儲在任何組織裡成為最迅速使用的系統之一。