基於中介軟體的查詢最佳化模型 (轉)[@more@]

基於的查詢模型:namespace prefix = o ns = "urn:schemas--com::office" />

傳統的客戶/是一種雙層的結構，通常是一臺個人做客戶機使用（執行客戶端），另外一臺伺服器用於存放後臺的，應用程式可客戶端直接相連，中間沒有其他的邏輯。在MIS系統的開發過程中，查詢資料是必不可少的一個重要部分，而如何幫助在資料庫中進行而有效的查詢資料是軟體開發人員十分關心的事情。我從我做過的2個MIS系統中關於資料查詢方面，大致總結出以下幾種方法：

1． 固定結構方式：即程式設計師根據客戶的業務要求定製客戶端查詢程式，這種定製的程式沒有通用性。或者業務邏輯也存在於後臺資料庫中，以(trigger)的方式實現。這種方式有一個很大的缺點，就是一旦客戶的業務邏輯有所改變的話，將引起應用程式的修改以及後臺觸發器的修改，將所有程式模組都重新修改、編譯、連線的工作量是相當大的。另外由於這種結構將使用者介面和業務邏輯以及資料來源繫結在一起，會消耗客戶機的大量資源，對客戶機來說是一個很大的負擔。

2． 靈活結構方式：既除了使用固定查詢命令以外，再做一些讓人員可以修改查詢命令的介面。也就是讓系統管理人員可以編寫

語句的方式，這種方式雖然可以提高查詢質量，但對與非專業的操作人員來講，是很困難的。

3．基於中介軟體的資料查詢最佳化模型：本文就以中介軟體和分散式系統為理論基礎，以曾經開發過的成都市康泰電器MIS系統為例介紹這種資料查詢模型，相信它給使用者提供了更方便和更快速的服務。

1． 什麼是中介軟體：

為解決分佈異構問題，人們提出了中介軟體(middleware)的概念。中介軟體是位於平臺(和)和應用之間的通用服務，如圖3所示，這些服務具有標準的程式介面和。針對不同的作業系統和硬體平臺，它們可以有符合介面和協議規範的多種實現。也許很難給中介軟體一個嚴格的定義，想了解的讀者可以去。

2． 開發人員在做查詢模組的時候應該注意的問題：

一般來說，客戶只關心他們所需要的資料和怎樣查詢出這些資料，而對與這條查詢語句是和生成的，就不會關心了。舉一個例子，一個庫房管理系統，包括入庫情況，出庫情況和結存情況等等。客戶只關心如何得到一個產品的出庫數量，入庫數量和當前的結存數量。而對於這個庫房管理系統是如何生成，和查詢語句的SQL程式碼和資料表，一律不感興趣。以康泰電器MIS系統為例，它採用的是client/server結構，根據我對MIS系統的瞭解，只要應用系統的客戶端數目在200個使用者以內而且是在同一個內，那麼client/server結構在MIS系統就足夠了。但是，眾所周知client/server結構存在很多問題。既前面固定結構方式中所談到的一些問題，導致它影響了資料庫的執行。

加上近年來INTE/INTRANET應用的興起，對於企業的運作方式有了重大的影響，康泰電器的企業主管要求開發產品查詢的資訊給所有在INTERNET/INTRANET上的潛在使用者，所以MIS系統必須能夠讓客戶使用來查詢所有的產品資訊，事實上系統結構已經進入了分散式的結構了。因為它多了一臺伺服器。以前的系統要提供INTERNET/INTRANET的存取形式時，舊的MIS系統必然以新的技術編寫一次。這必然加大了開發人員的工作，也提高了成本。所以我想，只是由於多了BS的查詢方式，為什麼不利用現在流行的中介軟體的思想開發一個新的查詢模型呢？

3．查詢系統的模型：

我透過分析一些查詢的語句，瞭解到了他們的一些共同性，並且共同性比較

突出，因為他們不是離散出現的。比如所有關於庫房查詢的語句構成了庫房管理查詢系統，所有財務收支的查詢語句構成了收支查詢系統，我將查詢的語句進行分類處理，structN_class={Table1,Table2…..Tablen};Datawarehouse={ struct 1_class, struct 2_class……structN_class}.而我就是要在structN_class上使用的D技術建立我們的查詢系統。

它的主要技術特徵是把查詢語句和系統的介面完全分開，不是原來的client/server結構了，我把client分為2個部分，client和Com-Server.。不管使用者是在client端，還是在採用瀏覽器介面。把使用者輸入的查詢條件和類別先提交到SelectCom-Server. SelectCom-Server.根據使用者輸入的查詢條件和類別自動生成查詢語句。然後把它們提交給資料庫，最後資料庫執行查詢語句，再將查詢的資料交給SelectCom-Server. SelectCom-Server.在把資料返回給client端，這樣就完成了查詢工作。

我認為它的好處有以下幾點：

由於SelectCom-Server.和client是分離的，那麼一個使用者使用過的查詢條件可以被其它使用者使用共享。這樣使和資料庫的開銷大大降低了。還可以根據已經使用過的查詢條件來縮小查詢的範圍。在由於我已經把深一級的加在了SelectCom-Server.上，它就可以拒絕一些核心資料的查詢，提高了資料的性

也減輕了程式碼的從用性，因為這種分散式的系統，考慮安全性按照常規不僅要完善client/server結構，而且要完善BS結構。再者，它還有利與系統管理人員的維護，他要排錯就只需要對SelectCom-Server.上的查詢語句進行分析。

4實現：

限與篇幅的問題，我不會把DCOM實現的程式碼寫出來，因為這種分散式系統介面牽涉到的東西太多了，只是談一下查詢語句的構成原理和它的最佳化，這才是最主要的。

但是這其中牽涉的東西也很多，比如：合理使用，避免或簡化排序，消除對大型錶行資料的順序存取，避免相關子查詢，用排序來取代非順序存取等等。

先說構成的原理，查詢subsentence的生成依據是各個欄位屬於哪個關係表而產生的，當同一個欄位屬於2個關係表共同擁有的時候，那麼它就是連線的欄位。

例如有3個關係表：

table1(Rnumber,Name,Guige),table2(Cnumber,Xinghao,Guige),table3(re,Guige)

那麼可以生成一個查詢subsentence的成員N=table1.Guige= table2.Guige.

而對於如何實現一個使用者使用過的查詢條件可以被其它使用者使用共享如下所敘述：關鍵是建立臨時，（我把其最佳化方式也加在其中）。以曾經開發過的成都市康泰電器MIS系統為例，把表的一個子集進行排序並建立臨時表，有時能加速查詢。它有助於避免多重排序操作，而且在其他方面還能簡化最佳化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個臨時檔案中，並按客戶的名字進行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然後以下面的方式在臨時表中查詢：
SELECT ＊ FROM cust_with_balance
WHERE postcode>“98000”
臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了I/O，所以查詢工作量可以得到大幅減少。為了加速查詢語句的生成和搜尋我們使用的臨時快取表。進行搜尋時，首先搜尋臨時快取表，再搜尋語句生成表。
但是要注意的是臨時表建立後不會反映主表的修改。在主表中資料頻繁修改的情況下，注意不要丟失資料。但是我到現在還沒有完全的解決這個問題，有興趣的讀者可以想想。

5．查詢語句的結構：

一個查詢語句可以分解成一個或許多的查詢subsentence，一個查詢subsentence還可以分解成多個更小的查詢subsentence。實際上他們是一個樹型結構，所以每一個新的查詢語句就是新的父節點。我們的臨時快取表就是已這種結構進行儲存的。

6．結束語

此模型在實際的運用中執行良好，而且對於使用者來說簡單實用，基本滿足了使用者的分散式系統的要求。儘管使用者對查詢的要求不一致，但是利用基於中介軟體的查詢最佳化模型具有友好的人機互動介面，查詢條件能夠自動靈活的生成，增加了實用性。對於開發人員來說減少了工作量，在提高了資料的安全性的同時也減輕了程式碼的二次開發等等。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10752043/viewspace-993131/，如需轉載，請註明出處，否則將追究法律責任。

基於中介軟體的查詢最佳化模型 (轉)

相關文章