A. 14.數據倉庫常見的存儲優化方法有哪些
存儲優化管理的方式包括數據壓縮、數據重分布、存儲治理項優化、生命周期管理等方法。
數據壓縮
在分布式文件系統中，會將數據存儲3份，這意味著存儲1TB的邏輯數據，實際上會佔用3TB的物理空間。使用盤古RAIDfile格式的文件，將存儲比從1：3提高至1:1.5。這樣做的缺點是數據塊損壞時的修復時間比原來更長，讀的性能也有損失。數據重分布
由於每個表的數據分布不同，插入順序不同，導致壓縮效果有很大的差異，通過修改表的數據重分布(distributeby,sortby欄位)進行數據重分布，能夠對表進行優化處理。存儲治理項優化：
存儲治理項優化是指在元數據的基礎上，診斷、加工成多個存儲治理優化項。目前已有的存儲治理優化項有未管理表、空表、最近62天未訪問表、數據無更新無任務表等。生命周期管理策略
根本目的：用最少的存儲成本滿足最大的業務需求，使數據價值最大化。
a）周期性刪除策略：針對無效的歷史數據進行定期清理。
b）徹底刪除策略：無用表數據或者ETL過程產生的臨時數據，以及不需要保留的數據，可以進行及時刪除，包括刪除元數據。
c）永久保留策略：重要且不可恢復的底層數據和應用數據需要永久保留。
d）極限存儲策略：超高壓縮重復鏡像數據。
e）冷數據管理策略：永久保留策略的擴展。永久保留的數據需要遷移到冷數據中心進行永久保存。一般將重要且不可恢復的、佔用存儲空間大於100TB，且訪問頻次較低的數據進行冷備，例如3年以上的日誌數據。
B. 淺談數據挖掘與數據倉庫
淺談數據挖掘與數據倉庫
1數據挖掘
1.1數據挖掘與傳統數據分析的區別
數據挖掘與傳統的數據分析，如查詢、報表、聯機應用分析的本質區別是數據挖掘是在沒有明確假設的前提下去挖掘信息、發現知識。數據挖掘所得到的信息應具有先前未知、有效和實用三個特徵。即數據挖掘是要發現那些不能靠直覺發現的信息或知識，甚至是違背直覺的信息或知識，挖掘出的信息越出乎意料就可能越有價值。而傳統的數據分析趨勢為從大型資料庫抓取所需數據並使用專屬計算機分析軟體。因此數據挖掘與傳統分析方法有很大的不同。
1.2數據挖掘的應用價值
（1）分類：首先從數據中選出已經分好類的訓練集，在該訓練集上運用數據挖掘分類的技術，建立分類模型，對於沒有分類的數據進行分類。（2）估計：與分類類似，不同之處在於，分類描述的是離散型變數的輸出，而估值處理連續值的輸出；分類是確定數目的，估計是不確定的。（3）聚類：是對記錄分組。聚類和分類的區別是聚集不依賴於預先定義好的類，不需要訓練集。中國移動採用先進的數據挖掘工具馬克威分析系統，對用戶wap上網的行為進行聚類分析，通過客戶分群，進行精確營銷。（4）關聯規則和序列模式的發現：關聯是某種事物發生時其他事物會發生的這樣一種聯系。例如：每天購買啤酒的人也有可能購買香煙，比重有多大，可以通過關聯的支持度和可信度來描述。與關聯不同，序列是一種縱向的聯系。例如：今天銀行調整利率，明天股市的變化。（5）預測：通過分類或估值得出模型，該模型用於對未知變數的預言。（6）偏差的檢測：對分析對象的少數的、極端的特例的描述，揭示內在的原因。除此之外，在客戶分析，運籌和企業資源的優化，異常檢測，企業分析模型的管理的方面都有廣泛使用價值。
2數據倉庫
2.1數據倉庫的特徵
（1）面向主題（Subject Oriented）的數據集合。數據倉庫圍繞一些主題如顧客、供應商、產品和銷售來組織。數據倉庫關注決策者的數據建模與分析，而不是組織機構的日常操作和事務處理。（2）集成（Integrated）的數據集合。數據倉庫中的數據是在對原有分散的資料庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。（3）時變（Time Variant）的數據集合。數據存儲從歷史的角度提供信息。數據倉庫中的數據通常包含歷史信息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。（4）非易失（Nonvolatile）的數據集合。數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，修改和刪除操作很少，通常只需要定期的載入、刷新。數據倉庫里的數據通常只需要兩種操作：初始化載入和數據訪問，因此其數據相對穩定，極少或根本不更新。[page] 2.2數據倉庫的類型
數據倉庫的類型根據數據倉庫所管理的數據類型和它們所解決的企業問題范圍，一般可將數據倉庫分為下列3種類型：企業數據倉庫（EDW）、操作型資料庫（ODS）和數據集市（Data Marts）。①企業數據倉庫為通用數據倉庫，它既含有大量詳細的數據，也含有大量累贅的或聚集的數據，這些數據具有不易改變性和面向歷史性。此種數據倉庫被用來進行涵蓋多種企業領域上的戰略或戰術上的決策。②操作型資料庫既可以被用來針對工作數據做決策支持，又可用做將數據載入到數據倉庫時的過渡區域。與EDW相比，ODS是面向主題和面向綜合的，易變的，僅含有目前的、詳細的數據，不含有累計的、歷史性的數據。③數據集市是為了特定的應用目的或應用范圍，而從數據倉庫中獨立出來的一部分數據，也可稱為部門數據或主題數據。幾組數據集市可以組成一個EDW。
2.3數據倉庫與傳統資料庫的比較
二者的聯系既有聯系又有區別。數據倉庫的出現，並不是要取代資料庫。目前，大部分數據倉庫還是用關系資料庫管理系統來管理的。可以說，資料庫、數據倉庫相輔相成、各有千秋。二者的區別可以從以下幾個方面進行比較：
（1）出發點不同：資料庫是面向事務的設計；數據倉庫是面向主題設計的。（2）存儲的數據不同：資料庫一般存儲在線交易數據；數據倉庫存儲的一般是歷史數據。（3）設計規則不同：資料庫設計是盡量避免冗餘，一般採用符合範式的規則來設計；數據倉庫在設計是有意引入冗餘，採用反範式的方式來設計。（4）提供的功能不同：資料庫是為捕獲數據而設計，數據倉庫是為分析數據而設計。（5）基本元素不同：資料庫的基本元素是事實表，數據倉庫的基本元素是維度表。（6）容量不同：資料庫在基本容量上要比數據倉庫小的多。（7）服務對象不同：資料庫是為了高效的事務處理而設計的，服務對象為企業業務處理方面的工作人員；數據倉庫是為了分析數據進行決策而設計的，服務對象為企業高層決策人員。
3數據倉庫與數據挖掘的關系
當然為了數據挖掘你也不必非得建立一個數據倉庫，數據倉庫不是必需的。建立一個巨大的數據倉庫，把各個不同源的數據統一在一起，解決所有的數據沖突問題，然後把所有的數據導到一個數據倉庫內，是一項巨大的工程，可能要用幾年的時間花上百萬的錢才能完成。只是為了數據挖掘，你可以把一個或幾個事務資料庫導到一個只讀的資料庫中，就把它當作數據集市，然後在他上面進行數據挖掘。
C. 數據倉庫中如果出現大表和小表的關聯，可以通過什麼方式提高計算效率
一般數據倉庫都是多節點，甚至分布式架構。無論哪個資料庫，大表關聯小表走的應該是小表廣播的方式，具體優化得看你用的那個資料庫具體sql是啥。
D. 資料庫優化(ER模型設計）
據訪問需要的完整解datamole4.adoquery2.sql.add('SELECT借書證號,密碼FROM[user]WHERE(借書證號=:tt)');
datamole4.adoquery2.parameters[0].value:=username;
datamole4.adoquery2.open;
在為TQuery或TADOquery部件設置SQL屬性時調用Close方法總是很安全的，如果TQuery或TADOquery部件已經被關閉了，調用Close方法時不會產生任何影響。在應用程序中為SQL屬性設置新的SQL命令語句時，必須要調用Clear方法以清除SQL屬性中現存的SQL命令語句，如果不調用Clear方法，便調用Add方法向SQL屬性中設置SQL命令語句，那麼新設置的SQL命令語句會追加在現存SQL命令語句後面，在程序運行時常常會出現出乎意料的查詢結果甚至程序無法運行下去。
在這里要特別注意的，一般情況下TQuery或TADOquery部件的SQL屬性只能包含一條完整的SQL語句，它不允許被設置成多條SQL語句。當然有些資料庫伺服器也支持在TQuery或TADOquery部件的SQL屬性中設置多條SQL語句，只要資料庫伺服器允許這樣，我們在編程時可以為SQL屬性設置多條SQL語句。
在為TQuery或TADOquery部件設置完SQL屬性的屬性值之後，也即編寫好適當的SQL程序之後，可以有多種方式來執行SQL程序。
在設計過程中，設置完TQuery或TADOquery部件的SQL屬性之後將其Active屬性的值置為True，這樣便可以執行SQL屬性中的SQL程序，如果應用中有與TQuery或TADOquery部件相連的數據瀏覽部件(如TDDGridTDBEdit等)那麼在這些數據瀏覽部件中會顯示SQL程序的執行結果。
在應用程序運行過程中，通過程序調用TQuery或TADOquery組件的Open方法或ExecSQL方法可以執行其SQL屬性中的SQL程序。Open方法和ExecSQL方法是不一樣的。Open方法只能用來執行SQL語言的查詢語句(Select命令)，並返回一個查詢結果集，而ExecSQL方法還可以用來執行其它常用的SQL語句(如INSERT,UPDATE,DELETE等命令)，例如：
Query1.Open(這樣會返回一個查詢結果集)
如果調用Open方法，而沒有查詢結果時，會出錯。此時應該調用ExecSQL方法來代替Open方法。如：
Query1.ExecSQL(沒有返回結果)
當然在設計應用程序時，程序設計人員是無法確定TQuery或TADOquery組件中的SQL語句是否會返回一個查詢結果的。對於這種情況應當用Try…Except模塊來設計程序。在Try部分調用Open方法，而在Except部分調用ExceSQL方法，這樣才能保證程序的正確運行。
例如：
Try
Query1.Open
Except
Query1.ExecSQL
End
通過Tquery或TADOquery組件可以獲得兩種類型的數據：
u「活動」的數據
這種數據就跟通過TTable部件獲得的數據一樣，用戶可以通過數據瀏覽部件來編輯修改這些數據，並且當調用Post方法或當焦點離開當前的數據瀏覽部件時，用戶對數據的修改自動地被寫回到資料庫中。
u非活動的數據(只讀數據)
用戶通過數據瀏覽部件是不能修改其中的數據。在預設情況下，通過TQuery部件獲得的查詢結果數據是只讀數據，要想獲得「活動」的數據，在應用程序中必須要設置Tquery或TADOquery組件的RequestLive屬性值為True，然而並不是在任何情況下(通過設置RequestLive的屬值True)都可以獲得「活動」的數據的，要想獲得「活動」的數據，除了將TQuery部件的RequestLive屬性設置為True外，相應的SQL命令還要滿足以下條件。
本地SQL語句查詢情況下，要得到可更新的數據集，SQL語句的限制為：
n查詢只能涉及到一個單獨的表
nSQL語句中不能包含ORDERBY命令
nSQL語句中不能含聚集運算符SUM或AVG
n在Select後的欄位列表中不能有計算欄位
n在Select語句WHERE部分只能包含欄位值與常量的比較運算，這些比較運算符是：Like,>,<,>=,<=。各比較運算之間可以有並和交運算：AND和OR
當通過SQL語句查詢資料庫伺服器中的資料庫表：
n查詢只能涉及到一個單獨的表
nSQL語句中不能包含ORDERBY命令
nSQL語句中不能含聚集運算符SUM或AVG運算
另外，如果是查詢Sybase資料庫中的表，那麼被查詢的表中只能有一個索引。
如果在應用程序中要求TQuery或TADOquery組件返回一個「活動」的查詢結果數據集，但是SQL命令語句不滿足上述約束條件時，對於本地資料庫的SQL查詢，BDE只能返回只讀的數據集。對於資料庫伺服器中的SQL查詢，只能返回錯誤的代碼。當Tquery或TADOquery組件返回一個「活動」的查詢結果數據集時，它的CanModIfy屬性的值會被設置成True。
§3.4MSSQLServer簡述
SQLServer是一個後台資料庫管理系統,它功能強大操作簡便,日益為廣大資料庫用戶所喜愛。越來越多的開發工具提供了與SQLServer的介面。SQLServer是一個關系資料庫管理系統，它最初是由Microsoft、Sybase和Ashton-Tate三家公司共同開發的。於1988年推出了第一個OS/2版本，在WindowsNT推出後，Microsoft與Sybase在SQLServer的開發上就分道揚鑣了，Microsoft將SQLServer移植到WindowsNT系統上，專注於開發推廣SQLServer的WindowsNT版本。
SQLServer2000是Microsoft公司推出的SQLServer資料庫管理系統的最新版本，該版本繼承了SQLServer7.0版本的優點，同時又比它增加了許多更先進的功能、具有使用方便、可伸縮性好與相關軟體集成程度高等優點。可跨越從運行MicrosoftWindows98的膝上型電腦到運行MicrosoftWindows2000的大型多處理器的伺服器等多種平台使用。MSSQLServer不但可以應用於大中型資料庫管理中，建立分布式關系資料庫，並且也可以開發桌面資料庫。事實上，SQLServer資料庫處理的基本結構，採取關系型資料庫模式，盡管如此，相信大家都可以輕易的發現，在SQLServer的資料庫處理方式，則是使用面向對象的操作方式與精神，也就是說，SQLServer的所有功能，都可以基於系統已經建立好的一些對象來達成，是相當OO（面向對象）的一個系統結構。
SQLServer企業管理器是SQLServer的主要管理工具，它提供了一個遵從MMC標準的用戶界面，使用戶得以：
·定義SQLServer實例組。
·將個別伺服器注冊到組中。
·為每個已注冊的伺服器配置所有SQLServer選項。
·在每個已注冊的伺服器中創建並管理所有SQLServer資料庫、對象、登錄、用戶和許可權。
·在每個已注冊的伺服器上定義並執行所有SQLServer管理任務。
·通過喚醒調用SQL查詢分析器，交互地設計並測試SQL語句、批處理和腳本。
·喚醒調用為SQLServer定義的各種向導。
·
第三章圖書管理系統設計分析
§4.1應用需求分析
圖書管理系統需要滿足來自三方面的需求，這三個方面分別是圖書借閱者、圖書館工作人員和圖書館管理人員。圖書借閱者的需求是查詢圖書館所存的圖書、個人借閱情況及個人信息的修改；圖書館工作人員對圖書借閱者的借閱及還書要求進行操作，同時形成借書或還書報表給借閱者查看確認；圖書館管理人員的功能最為復雜，包括對工作人員、圖書借閱者、圖書進行管理和維護，及系統狀態的查看、維護並生成催還圖書報表。
圖書借閱者可直接查看圖書館圖書情況，如果圖書借閱者根據本人借書證號和密碼登錄系統，還可以進行本人借書情況的查詢和維護部分個人信息。一般情況下，圖書借閱者只應該查詢和維護本人的借書情況和個人信息，若查詢和維護其他借閱者的借書情況和個人信息，就要知道其他圖書借閱者的借書證號和密碼。這些是很難得到的，特別是密碼，所以不但滿足了圖書借閱者的要求，還保護了圖書借閱者的個人隱私。
圖書館工作人員有修改圖書借閱者借書和還書記錄的許可權，所以需對工作人員登陸本模塊進行更多的考慮。在此模塊中，圖書館工作人員可以為圖書借閱者加入借書記錄或是還書記錄，並列印生成相應的報表給用戶查看和確認。
圖書館管理人員功能的信息量大，數據安全性和保密性要求最高。本功能實現對圖書信息、借閱者信息、總體借閱情況信息的管理和統計、工作人員和管理人員信息查看及維護。圖書館管理員可以瀏覽、查詢、添加、刪除、修改、統計圖書的基本信息；瀏覽、查詢、統計、添加、刪除和修改圖書借閱者的基本信息，瀏覽、查詢、統計圖書館的借閱信息，但不能添加、刪除和修改借閱信息，這部分功能應該由圖書館工作人員執行，但是，刪除某條圖書借閱者基本信息記錄時，應實現對該圖書借閱者借閱記錄的級聯刪除。並且還應具有生成催還圖書報表，並列印輸出的功能。
在本系統中由於沒有列印機設備供試驗，所以預先把報表列印改成報表預覽。
設計不同用戶的操作許可權和登陸方法
對所有用戶開放的圖書查詢
借閱者維護借閱者個人部分信息
借閱者查看個人借閱情況信息
維護借閱者個人密碼
根據借閱情況對資料庫進行操作並生成報表
根據還書情況對資料庫進行操作並生成報表
查詢及統計各種信息
維護圖書信息
維護工作人員和管理員信息
維護借閱者信息
處理信息的完整性
對借閱過期的圖書生成報表
圖4-2圖書管理系統資料庫應用需求的總結
根據以上所做的需求分析，並略掉一些細節（如不考慮用戶的登錄；對記錄的維護），得出以下的三層數據流圖。
§4.2系統功能模塊劃分
系統功能框圖如圖4-10所示。
§4.3系統資料庫設計
4.3.1概念設計
在概念設計階段中，設計人員從用戶的角度看待數據及處理要求和約束，產生一個反映用戶觀點的概念模式。然後再把概念模式轉換成邏輯模式。將概念設計從設計過程中獨立開來，使各階段的任務相對單一化，設計復雜程度大大降低，不受特定DBMS的限制。
利用ER方法進行資料庫的概念設計，可分成三步進行：首先設計局部ER模式，然後把各局部ER模式綜合成一個全局模式，最後對全局ER模式進行優化，得到最終的模式，即概念模式。
（1）設計局部ER模式
實體和屬性的定義：
圖書（圖書編號，圖書名稱，作者，出版社，出版日期，備注，價格，數量，）
借閱者（借書證號，姓名，性別，身份證，聯系電話，密碼）
身份（身份編號，身份描述，最大借閱數）
圖書類別（圖書類別編號，類別描述）
ER模型的「聯系」用於刻畫實體之間的關聯。一種完整的方式是對局部結構中任意兩個實體類型，依據需求分析的結果，考察局部結構中任意兩個實體類型之間是否存在聯系。若有聯系，進一步確定是1:N，M:N，還是1:1等。還要考察一個實體類型內部是否存在聯系，兩個實體類型之間是否存在聯系，多個實體類型之間是否存在聯系，等等。聯系定義如圖4-5所示。解釋如下：
u一個借閱者（用戶）只能具有一種身份，而一種身份可被多個借閱者所具有；
u一本圖書只能屬於一種圖書類別（類別），而一種圖書類別可以包含多本圖書；
u一個用戶可以借閱多本不同的書，而一本書也可以被多個不同的用戶所借閱。
（2）設計全局ER模式
所有局部ER模式都設計好了後，接下來就是把它們綜合成單一的全局概念結構。全局概念結構不僅要支持所有局部ER模式，而且必須合理地表示一個完整、一致的資料庫概念結構。
1)確定公共實體類型
為了給多個局部ER模式的合並提供開始合並的基礎，首先要確定各局部結構中的公共實體類型。在這一步中我們僅根據實體類型名和鍵來認定公共實體類型。一般把同名實體類型作為公共實體類型的一類候選，把具有相同鍵的實體類型作為公共實體類型的另一類候眩
2)局部ER模式的合並
合並的原則是：首先進行兩兩合並；先和合並那些現實世界中有聯系的局部結構；合並從公共實體類型開始，最後再加入獨立的局部結構。
3)消除沖突
沖突分為三類：屬性沖突、結構沖突、命名沖突。
設計全局ER模式的目的不在於把若干局部ER模式形式上合並為一個ER模式，而在於消除沖突，使之成為能夠被所有用戶共同理解和接受的同一的概念模型。
3)全局ER模式的優化
在得到全局ER模式後，為了提高資料庫系統的效率，還應進一步依據處理需求對ER模式進行優化。一個好的全局ER模式，除能准確、全面地反映用戶功能需求外，還應滿足下列條件：實體類型的個數要盡可能的少；實體類型所含屬性個數盡可能少；實體類型間聯系無冗餘。
綜上所述，「圖書管理系統」的全局ER模式如圖4-13所示。
4.3.2關系資料庫的邏輯設計
由於概念設計的結果是ER圖，DBMS一般採用關系型（本人所使用的MSSQLServer就是關系型的DBMS），因此資料庫的邏輯設計過程就是把ER圖轉化為關系模式的過程。由於關系模型所具有的優點，邏輯設計可以充分運用關系資料庫規范化理論，使設計過程形式化地進行。設計結果是一組關系模式的定義。
（1）導出初始關系模式
book（圖書編號＃，圖書名稱，圖書類別＃，作者，出版社，出版日期，備注，價格，數量）class（圖書類別#，類別名）user（借書證號＃，姓名，性別，身份編號＃，身份證，聯系電話，密碼）ID（身份編號#，身份描述，最大借閱數）Owner（借書證號#,圖書編號#，借書日期）
圖4-14關系模式集
（2）產生子模式
子模式是用戶所用到的那部分數據的描述。除了指出用戶用到的數據外，還應指出數據與概念模式中相應數據的聯系，即指出概念模式與子模式之間的對應性。
借書子模式（借書證號#，姓名，圖書編號＃，圖書名稱，借書日期）
圖4-15部分子模式
（3）根據設計中出現的問題本人在寫系統時還加入了兩個關系模式：
1、ownertemp：用於工作人員在處理借書、還書工作時臨時存儲借書、還書信息，以便列印報表時使用。
2、keyer：用於存儲工作人員和圖書館管理員的用戶名和密碼及許可權，以便工作人員或圖書館管理員進入相應的功能模塊時進行驗證用戶的身份。
4.3.3資料庫的實現
我選用MicrosoftSQLServer2000(企業版)資料庫來進行資料庫的邏輯設計。首先創建七個基本資料庫表如表4-1－4-7所示，然後根據全局ER圖，建立各個表之間的聯系，如圖4-8所示。
表4-1借閱者基本信息表的結構(User)
表4-2圖書信息表的結構（Book）
表4-3圖書類別信息表的結構（Class）
表4-4借閱者身份信息表的結構（ID）
表4-5借閱情況信息表的結構（Owner）
表4-6借閱情況臨時存儲信息表的結構（Ownertemp）
註：在owner表和ownertemp表中加入了索引欄位，用來唯一標識一條借書記錄，並且設置為標識，標識種子為1。
表4-7工作人員和管理員信息表的結構（Keyer）
圖4-8資料庫表間聯系圖
第五章圖書管理系統應用程序設計
§5.1系統窗體模塊組成
§5.2數據模塊窗體的設置
在編寫資料庫應用程序時，經常要遇到這樣的情況，即好多組件、窗體同時訪問相同的數據源，如果為每一個組件或者窗體都設置一個數據源將是十分耗時的工件，而且要保證這些數據源的確是相同的也需花一番功夫。那麼，能不能將這些數據源集中管理，最好是做成一個統一的模塊，需要時就將該模塊引入而不必直接操作數據源本身呢？數據模塊（DataMole）是解決這個問題最好的答案。簡單說來，數據模塊是用來集中管理數據源的一個窗體，該窗體可被需要的地方隨時引入。
但本人在開發這個系統時，開始使用了一下數據模塊，但在使用過程中卻碰到了一些問題。並且考慮這個系統使用到的TADOQuery控制項比較多，如果使用數據控制項可能會帶來管理上的麻煩，如弄混各個數據控制項的作用。還考慮到使用動態生成ADOQuery可能會更節省資源。所以在本人的系統中，開始做的第一個模塊「借閱者個人模塊」中還稍微使用了一下數據模塊。但在後面做的兩個模塊中大多都是用動態生成ADOQuery來實現的。並且由於SQL語句是動態加入的所以datamole中的控制項也不會多。
§5.3啟動畫面的實現
啟動畫面是為了給用戶一個良好的印像，加深軟體的親和力，沒有實際的功能，在Form1窗體中加入了Image和Time組件。啟動畫面的窗體略，主要的源代碼如下：
§5.4用戶登錄窗體的的實現
本窗體是為三種不同的用戶（一般用戶，工作人員，管理員）提供選擇以進入不同的模塊，滿足不同用戶的需求。源代碼比較簡單，略。
§5.5用戶密碼認證窗體的的實現
本窗體是為了讓工作人員或圖書館管理員按照用戶名和密碼進行登錄，並且跟據用戶名檢查Keyer表中的「許可權」欄位，以分辯進入圖書館管理人員模塊還是進入工作人員模塊。窗體界面、源代碼如下
§5.6借閱者服務模塊的實現
借閱者服務窗體的功能主要是圖書的查詢，個人借閱情況查看及個人部分信息的修改。界面圖如下：
5.6.1圖書查詢功能的實現
在本系統中，任何人都有許可權使用查詢功能，不做任何限制。界面如下，
由於實現的查詢功能有多種，如按圖書編號、圖書名稱等欄位進行完全體配查找和部分體配的模糊查找，還有按多個條件進行邏輯與或是邏輯或的多條件查找。其中實現的方法者差不多，所以只給出多條件查找的代碼，如下：
5.6.2借閱者登錄功能的實現
這個功能的實現與工作人員和管理人員登錄功能實現的方法大致一樣，並且還要簡單。是從User表中查到到借閱證號與密碼，看與用戶輸入的是否一致。如果一致，那麼用戶就可查看自已的借閱情況並維護自己的部分信息。源代碼與借閱者登錄界面都略。
5.6.3借閱者借閱情況功能的實現
當借閱者正確登錄到系統後，此功能將被激活，使用戶能查看到自身的借閱情況。在此系統中，信息的顯示一般用ListView來實現，只在較少的情況下用到了DBgrid，因為我覺得ListView更好實現，並能使信息數據對用戶的完全分離。
在這里跟據借閱者的不同要求實現借閱情況的查詢，有檢查所有的借閱情部、某本書的借閱情況、和根據已借閱天數的來查詢。其中根椐借閱天數來查詢更有代表性，有方式一和方式二。以下給出此功能的源代碼
按借閱天數查詢方式一
按借閱天數查詢方式二
5.6.4借閱者個人資料維護功能的實現
此功能實現當前借閱者部份資料的修改，但借書證號和身份類別這樣的信息不允許修改，這是圖書館管理員模塊的功能。在此界面中點擊修改按鈕將出現「修改」窗體（Form8），點擊修改密碼按鈕將出現groupbox8，在這里進行密碼修改。關鍵源代碼如下。
這里給出個人部分信息修改的源代碼：
這里給出密碼修改的源代碼：
5.7工作人員－圖書借閱/歸還模塊的實現
5.7.1工作人員進行圖書借閱功能實現
在這個功能中，工作人員輸入借閱者的借閱證號和所要借閱的圖書的圖書編號，然後點擊借閱按鈕就可進行圖書借閱。考慮到實際中可能會出現只知圖書名而不知圖書編號的情況，在此界面下方加入了一個轉換功能，可以把圖書名稱轉換成圖書編號，再進行圖書借閱。
在借閱完成後會生借閱報表以便借閱者檢查和確認，借閱報表的列印效果如下圖，實現比較簡單，略去實現過程。
5.7.2工作人員進行圖書歸還功能實現
在此功能中，工作人員根據借閱者的借書證號和歸還的圖書編號進行圖書的歸還工作。並且根據現實中可能會出現的只知圖書名不知圖書編號的歸還情況，所以加入了按書籍名稱進行歸還的功能。這個功能是圖書借閱功能中把圖書名稱轉換成圖書編號的一種改進方法，這樣就不用如借閱功能中一樣要先轉換再借閱了。歸還完成後，同樣會列印出歸還報表以便用戶檢查和確認。
5.8圖書館管理員模塊的實現
5.8.1圖書館管理員圖書管理功能的實現
在這個功能中可以在（＊圖書編號）中輸入圖書編號，點查找按鈕後就會在各個相應的組件中顯示出信息，或按圖書名稱模糊查找到所要的記錄，在各個相應的組件中顯示第一條記錄的信息，也可在下端的ListView組件中點擊某一條記錄，在各個相應的組件中也會顯示所選記錄的信息。在入庫功能中只要不是相同的圖書編號並且帶＊號提示的欄位不為空就可插入新的圖書記錄。刪除則刪除那些Book表中的圖書記錄，如果借出還可依用戶要求連帶刪除owner表中的記錄。因為圖書修改與圖書入庫的功能與工作人員記錄修改和工作人員記錄添加的實現過程一樣，所以下面僅給出刪除功能的源代碼，如下
5.8.2圖書館管理員工作人員和管理員管理功能的實現
在此功能中可以加入工作人員或是管理員，或是修改他們的密碼、許可權。
在此功能中如果選中ListView中的記錄，則在右邊相應的組件中顯示出信息，並且管理員還可對這些記錄進行修改或加入新的記錄。並且也可以點刪除按鈕刪除選中的一條或多條記錄。刪除功能與圖書記錄的刪除一般，所以下面只給出添加與修改的實現過程。
5.8.3圖書館管理員修改圖書類別及統記功能的實現
在此窗體中能對圖書的類別進行刪除，添加和修改，這模塊的功能的實現過程與圖書記錄的刪除，添加和修改一樣的，但是這個窗體還能跟據圖書類別進行統計，還可根據Book表和owner表統計出圖書總數目，庫存圖書數目，借出圖書數目及借閱過期的圖書數目。在這里給出統計圖書總數目，庫存圖書數目，借出圖書數目及借閱過期的圖書數目的實現過程中的幾個函數和過程
5.8.4圖書館管理員借閱者管理功能的實現
查詢借閱者可根據借閱者的借書證號或姓名或身份編號查找到借閱者的信息，也可以實行模糊查找，這個功能的實現與前面圖書查找的實現過程一般，就不再詳細說明。
5.8.5圖書館維護借閱者管理功能的實現
此功能能對借閱者信息進行查看添加、刪除、修改。在這里給出刷新按鈕的實現過程
5.8.6圖書館身份維護功能的實現
這一部分是對借閱者身份進行管理，能對身份進行添加、刪除、修改。並且同樣的在listview中選中某條或多條記錄時會在相應的右邊的組件中顯示出信息。此功能實現過程與前面所敘有雷同，略。
5.8.7圖書館借閱者統計功能的實現
此功能按借閱者身份進行統計，得出具有某種身份的借閱者總數，此種身份的並借閱圖書的借閱者數和所借閱的圖書數，在下面給出實現過程。
5.8.8圖書館統計借閱過期記錄功能的實現
列印出的借閱過期催還報表如下圖所示：
此報表能顯示按借書證號升序排列的借閱信息超過限定時限的信息，其中主要的SQL語句如下：
5.9系統信息顯示的實現
顯過本系統的信息，並且右邊的字向上滾動顯示，主要實現如下：
另外,虛機團上產品團購,超級便宜
E. 數據倉庫的特點
1、數據倉庫是面向主題的；操作型資料庫的數據組織面向事務處理任務，而數據倉庫中的數據是按照一定的主題域進行組織。主題是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統相關。
2、數據倉庫是集成的，數據倉庫的數據有來自於分散的操作型數據，將所需數據從原來的數據中抽取出來，進行加工與集成，統一與綜合之後才能進入數據倉庫；
數據倉庫中的數據是在對原有分散的資料庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。
數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以後，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的載入、刷新。
數據倉庫中的數據通常包含歷史信息，系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到當前的各個階段的信息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。
3、數據倉庫是不可更新的，數據倉庫主要是為決策分析提供數據，所涉及的操作主要是數據的查詢；
4、數據倉庫是隨時間而變化的，傳統的關系資料庫系統比較適合處理格式化的數據，能夠較好的滿足商業商務處理的需求。穩定的數據以只讀格式保存，且不隨時間改變。
5、匯總的。操作性數據映射成決策可用的格式。
6、大容量。時間序列數據集合通常都非常大。
7、非規范化的。Dw數據可以是而且經常是冗餘的。
8、元數據。將描述數據的數據保存起來。
9、數據源。數據來自內部的和外部的非集成操作系統。
數據倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它並不是所謂的「大型資料庫」。數據倉庫的方案建設的目的，是為前端查詢和分析作為基礎，由於有較大的冗餘，所以需要的存儲也較大。為了更好地為前端應用服務，數據倉庫往往有如下幾點特點：
1.效率足夠高。數據倉庫的分析數據一般分為日、周、月、季、年等，可以看出，日為周期的數據要求的效率最高，要求24小時甚至12小時內，客戶能看到昨天的數據分析。由於有的企業每日的數據量很大，設計不好的數據倉庫經常會出問題，延遲1-3日才能給出數據，顯然不行的。
2.數據質量。數據倉庫所提供的各種信息，肯定要准確的數據，但由於數據倉庫流程通常分為多個步驟，包括數據清洗，裝載，查詢，展現等等，復雜的架構會更多層次，那麼由於數據源有臟數據或者代碼不嚴謹，都可以導致數據失真，客戶看到錯誤的信息就可能導致分析出錯誤的決策，造成損失，而不是效益。
3.擴展性。之所以有的大型數據倉庫系統架構設計復雜，是因為考慮到了未來3-5年的擴展性，這樣的話，未來不用太快花錢去重建數據倉庫系統，就能很穩定運行。主要體現在數據建模的合理性，數據倉庫方案中多出一些中間層，使海量數據流有足夠的緩沖，不至於數據量大很多，就運行不起來了。
從上面的介紹中可以看出，數據倉庫技術可以將企業多年積累的數據喚醒，不僅為企業管理好這些海量數據，而且挖掘數據潛在的價值，從而成為通信企業運營維護系統的亮點之一。正因為如此，
廣義的說，基於數據倉庫的決策支持系統由三個部件組成：數據倉庫技術，聯機分析處理技術和數據挖掘技術，其中數據倉庫技術是系統的核心，在這個系列後面的文章里，將圍繞數據倉庫技術，介紹現代數據倉庫的主要技術和數據處理的主要步驟，討論在通信運營維護系統中如何使用這些技術為運營維護帶來幫助。
4.面向主題
操作型資料庫的數據組織面向事務處理任務，各個業務系統之間各自分離，而數據倉庫中的數據是按照一定的主題域進行組織的。主題是與傳統資料庫的面向應用相對應的，是一個抽象概念，是在較高層次上將企業信息系統中的數據綜合、歸類並進行分析利用的抽象。每一個主題對應一個宏觀的分析領域。數據倉庫排除對於決策無用的數據，提供特定主題的簡明視圖。
