【導讀】本科畢業(yè)設計外文文獻翻譯

　　

【正文】 的 DB2,Oracle 8,Informix UDS） 10 櫻井擴展了它們的系統(tǒng)，使之具有存儲諸如圖像，文本等新數(shù)據(jù)類型的能力，以及回答更復雜查詢的能力。大量的廠商已經(jīng)為創(chuàng)建數(shù)據(jù)倉庫，繼承多個數(shù)據(jù)庫的數(shù)據(jù)以及實現(xiàn)專業(yè)化分析而開發(fā)了專用系統(tǒng)。 一個 有趣的現(xiàn)象是隨著一些企業(yè)資源規(guī)劃（ ERP）和管理自愿規(guī)劃（ MRP）軟件包的出現(xiàn)，他們在 DBMS 之上增加了一層面向應用的特征。廣泛使用的軟件包有Baan,Oracle,PeopleSoft,SAP 和 Siebel 等系統(tǒng)，它們先確定大多數(shù)組織機構所遇到的共同任務（例如，庫存管理，人力資源規(guī)劃，財務分析等），并提供一個通用的應用層以完成這些任務。數(shù)據(jù)存儲在關系型 DBMS 中，可以為不同公司分別定制應用層。與從頭開始創(chuàng)建應用層的開銷相比，這樣可以降低公司的總體開銷。 也許，在 DBMS 的發(fā)展中，最重要的事是 DBMS 已經(jīng)進 入了因特網(wǎng)時代。第一代Web 站點是把數(shù)據(jù)存儲在操作系統(tǒng)的文件中，而現(xiàn)在，使用 DBMS 存儲數(shù)據(jù)并通過 Web瀏覽器瀏覽數(shù)據(jù)已變得越來越普遍。通過 Web 可存取的表單界面來產(chǎn)生查詢請求，并使用諸如 HTML 的標記語言將查詢結果格式化，從而便于在瀏覽器中顯示。所有數(shù)據(jù)庫提供商都在增加它們的 DBMS 功能，使之更適于在因特網(wǎng)上部署。 隨著越來越多在線數(shù)據(jù)的產(chǎn)生，并且通過計算機網(wǎng)絡越來越容易獲得，數(shù)據(jù)庫也變得更加重要了。今天，眾多領域的發(fā)展需求，例如，多媒體數(shù)據(jù)庫，互動視頻，流數(shù)據(jù)，數(shù)字圖書館等精彩視頻節(jié)目，人類基因圖和 NASA 的地球觀測系統(tǒng)等科學項目，以及公司對鞏固它們的決策支持處理和有用信息挖掘的渴望，正推動著數(shù)據(jù)庫領域的發(fā)展。在商業(yè)上，數(shù)據(jù)庫管理系統(tǒng)代表著最大和最具活力的市場之一。所以，有關數(shù)據(jù)庫系統(tǒng)的研究回報豐厚！ （二）物理數(shù)據(jù)庫設計簡介 與數(shù)據(jù)庫設計的其他方面一樣，我們要根據(jù)數(shù)據(jù)的性質和用途來進行物理數(shù)據(jù)庫設計。特別是，我們必須了解數(shù)據(jù)庫所必須支持的典型的工作負載，工作負載是查詢和更新的混合體。用戶有一些特定的要求，如，某些查詢或更新的執(zhí)行速度應該有多快，或者每秒鐘必須處理多少個事務等。在物理數(shù)據(jù)庫設計過程中，工作 負載的描述和用戶的需求是作出許多決策的基礎。 為了獲得一個好的物理數(shù)據(jù)庫設計，我們還要調整系統(tǒng)的性能以滿足用戶的需求。設計者需要明白 DBMS 工作的細節(jié)，特別是 DBMS 所支持的索引和查詢處理技術。 11 如果數(shù)據(jù)庫允許多個用戶并發(fā)訪問，或者是分布式數(shù)據(jù)庫，那么這是設計任務就變得更復雜了，還需要考慮 DBMS 的其他特點。 （三）數(shù)據(jù)庫負載 一個好的數(shù)據(jù)庫設計的關鍵是對所希望的負載有準確的描述。一個工作負載的描述包括以下幾個部分： ，一個查詢的頻率指該查詢在所有的查詢和更新中所占的比例 。 。 。 對于在工作負載中的每個查詢，我們必須確定： 需要訪問哪些關系。 需要保留那些屬性（在 SELECT 子句中）。 在那些屬性上有選擇或連接條件（在 WHERE 子句中），以及這些條件具有多大的選擇性。 類似地，對工作負載中每個更新，我們必須確定： 在哪些屬性上有選擇或連接條件（在 WHERE 語句中），以及有多大的選擇性。 更新的類型（ INSERT,DELETE,UPDATE）以及所要更新的關系。 對于 UPDATE 命令，要更新哪些字段。 典型的 查詢和更新都帶有參數(shù)，例如，借款或存款操作都涉及某個特定的帳號。這些參數(shù)的值決定了選擇和連接條件的選擇性。 更新中包括一個查詢部分，用來找到目標元組。這個部分可以得益于一個好的物理設計和索引。另一方面，更新操作一般還要做一些額外的工作，以維護所修改的屬性上的索引。這樣，盡管查詢總可以從索引受益，但是索引也可能使一個給定的更新加快或變慢。在生成索引時，設計者應該在頭腦中進行一下權衡。 （四）數(shù)據(jù)庫調整的必要性 準確地講，在系統(tǒng)設計的初始階段，我們很難得到工作負載的詳細信息。所以在 12 系統(tǒng)設計完以后，對數(shù)據(jù)庫的調整就變得很重要，我們必須按照實際的使用模式來對初始的設計進行求精，以便獲得好的性能。 對于如何區(qū)別數(shù)據(jù)庫設計和數(shù)據(jù)庫調整，人們有不同的看法。一種看法認為，一旦初始模式、索引和聚簇決策已經(jīng)確定，那么設計過程也就結束了。接下去對概念模式或索引的任何改變，都被認為是對數(shù)據(jù)庫進行調整的活動。另一種看法是，對于概念模式的進一步求精（和受這些改進影響的物理設計決策）也應該是物理設計過程的一部分。 如何區(qū)分設計和調整并不是很 重要的 （五）數(shù)據(jù)庫調整簡介 當數(shù)據(jù)庫初始設計完成后，數(shù)據(jù)庫的實際使用提供了一些有用的詳細信息，它們可以用來對初始設計進行進一步求精。先前對工作負載的很多假設都可以用觀察到的模式來代替；一般來講，一些初始的關于工作負載的說明將得到驗證，其中有一些可能是錯誤的。關于數(shù)據(jù)大小的初始猜測可以用實際的數(shù)據(jù)庫的統(tǒng)計數(shù)字來代替（盡管這個信息會隨著系統(tǒng)的不斷進化而變化）。對于查詢的仔細監(jiān)測可龕發(fā)現(xiàn)一些預測不到的問題，例如，優(yōu)化器可能不使用某些索引，盡管這些索引可以產(chǎn)生好的計劃。 為了獲得可 能的最好的性能，對數(shù)據(jù)庫進行連續(xù)的調整是很重要的。 （六）調整概念模式 在數(shù)據(jù)庫設計期間，我們也許會意識到，在給定工作負載和任何一組可行的物理設計選擇的情況下，當前選擇的關系模式并不能滿足性能目標。如果是這樣，我們也許必須重新設計概念模式（而且還要重新檢查那些受到影響的物理設計決策）。 在系統(tǒng)已經(jīng)運行了一段時間后，我們也許會認識到在初始設計期間或之后重新設計的必要性。一旦數(shù)據(jù)庫設計完成并且已經(jīng)被裝載數(shù)據(jù)了，如果要改變概念模式，就需要做出很大的努力去映射受到影響的關系的內容。然而，有時需要根據(jù)使用系統(tǒng)的經(jīng)驗來 對概念模式進行修正?，F(xiàn)在，我們從性能的角度來考慮概念模式（重新）設計中的一些問題。 在對概念模式進行調整時我們必須考慮以下幾點： 13 我們也許應當采用 3NF 設計來代替 BCNF 設計。 如果將一個關系分解為 3NF 或 BCNF 有兩種方式，那么應該根據(jù)工作負載來進行選擇。 有時我們需要對一個應景是 BCNF 的關系進一步分解。 在某些情況下可能進行反規(guī)范化。也就是，可能將一組由一個大關系分解而得到的關系用它們的原大關系代替，盡管這樣會引起一些冗余的問題。而且，我們可能在特定的關系上加上一些字段來加速一些重要的查詢，即使這樣會 導致對一些信息的冗余存儲（從而使得模式既不是 3NF 也不是 BCNF）。 關于規(guī)范化的討論集中在分解技術上，實際上就是對關系的垂直劃分。另一個技術是對關系進行水平劃分，這將導致兩個具有相同模式的關系。這里需要注意的是，這里討論的不是一個關系元組的物理劃分；而是想創(chuàng)建兩個不同的關系（可能具有不同的約束和索引）。 另外，在重新設計概念模式時，特別是如果調整一個現(xiàn)存數(shù)據(jù)庫的模式時，我們需要考慮是否定義視圖來向用戶隱藏這些改變，因為對于用戶來說原始的模式可能更自然一些。 （ 七 ） 調整查詢和視圖 如果一個查詢比預計的要慢得 多，那么我們就必須仔細檢查并找出問題。通過對查詢進行重寫，并且進行一些索引的調整，常常能夠解決問題。如果在視圖上的一些查詢運行得很慢，也可以進行類似的調整。 當調整一個查詢時，第一件事就是確定系統(tǒng)是否使用了你所希望的執(zhí)行計劃。由于一些原因，有時系統(tǒng)可能沒有找到最好的執(zhí)行計劃。下面是很多優(yōu)化器都不能有效處理的一些情況： 含有空值的選擇條件； 選擇條件含有算數(shù)或字符串表達式，或者使用 OR 進行條件連接。例如，如果在WHERE 語句中有一個條件 =2*，那么優(yōu)化器可能會正確利用現(xiàn)有的在 上的 索引，但是不能正確利用在 上的索引。當將條件變?yōu)?時，將會出現(xiàn)相反的情況。 不能識別出一個復雜的執(zhí)行計劃，例如不能發(fā)現(xiàn)在 GROUP BY 語句中含有的 14 聚集操作的查詢中的只讀索引掃描計劃。 如果優(yōu)化器不太聰明，不能發(fā)現(xiàn)最好的執(zhí)行計劃（使用 DBMS 支持的一些訪問方法和執(zhí)行策略），一些系統(tǒng)允許用戶通過提供給優(yōu)化器一些提示來指導計劃的選擇。例如，用戶可能強迫系統(tǒng)使用特定的索引或連接的方法和順序。如果一個用戶希望以這種方式來指導優(yōu)化，那么他應該對優(yōu)化和給定的 DBMS 的能力有一個全面的理 解。 （八）其他專題 移動數(shù)據(jù)庫 便攜計算機和無線通信的應用創(chuàng)建了一批移動數(shù)據(jù)庫用戶。一方面，這些用戶只是簡單地通過網(wǎng)絡來訪問數(shù)據(jù)庫，類似于分布式 DBMS。另一方面，不論是網(wǎng)絡，還是數(shù)據(jù)和用戶，都有一些新的特性，這就影響了 DBMS 中的許多構件，包括查詢引擎，事務管理程序和虎伏管理程序。 通過無線連接的用戶帶寬是以太網(wǎng)的 1/10 左右，是 ATM 網(wǎng)的 1/100 左右。因此通信開銷比 I/O 和 CPU 開銷更高。 用戶的位置通常是變動的，而且移動計算機的電池壽命是有限的。因此，除內容傳輸開銷以及因位置的頻繁變動而產(chǎn)生的開銷 外，真正的通信開銷體現(xiàn)在連接時間和電池的使用上。通常將數(shù)據(jù)生成多個副本，以使從不同位置的訪問開銷最小化。 當一個用戶移動的時候，一個事務可能需要從多個數(shù)據(jù)庫服務器中訪問數(shù)據(jù)，此時丟失連接的可能性比傳統(tǒng)的網(wǎng)絡要大。因此，集中式的事務管理也是不實際的，尤其是有些數(shù)據(jù)存儲在移動計算機上更是這樣。事實上，我們可能不得不放棄具有 ACID特性的事務，而是為用戶程序開發(fā)其他的一致性方法。 主存數(shù)據(jù)庫 由于主存的價格已經(jīng)很便宜了，許多應有可以購買足夠的主存來保存整個數(shù)據(jù)庫。而且，現(xiàn)代的 CPU 使用 64 位的尋址，有了很大的尋址 空間。一些商用的數(shù)據(jù)庫已有幾個 GB 的主存。這促使重新考慮一些基本的 DBMS 設計決策，因為對于駐留內存的數(shù)據(jù)庫，磁盤訪問不再是主要的處理時間。 主存也不能幸免于系統(tǒng)崩潰，所以仍然需要實現(xiàn)日志和恢復機制，以保證事務的原子性和持久性。在提交事務的時候，日志記錄必須寫到固定的存儲中。這個處理可能會變成一個瓶頸。為了使該問題最小化，不是每完成一個事務就進行提交，而是收 15 集已完成的事務，然后批量提交它們，這稱為組提交?；謴退惴ㄍ瑯右残枰獌?yōu)化，因為很少這種情況：某頁因需要為其他頁省出空間而不得不被移出。 應認真優(yōu)化主存中的 操作實現(xiàn)，因為磁盤存取不再是限制性能的要素。 在優(yōu)化查詢時必須考慮新的標準，即執(zhí)行一個計劃時所需要的空間數(shù)量。最小化空間開銷是很重要的，因為如果空間開銷超出物理內存，會使交換頁保存到磁盤（通過操作系統(tǒng)的虛擬存儲機制），這將大大降低執(zhí)行效率。 基于頁的數(shù)據(jù)結構不再重要了（因為頁不再是數(shù)據(jù)檢索的單位），同時，聚簇也不重要了（因為訪問主存的任何區(qū)域的開銷是一致的）。