《計算機專業(yè)外文文獻翻譯-外文翻譯--基于Java的訪問遠程數(shù)據(jù)庫的高效的標準軟件體系結構 中文版》由會員分享，可在線閱讀，更多相關《計算機專業(yè)外文文獻翻譯-外文翻譯--基于Java的訪問遠程數(shù)據(jù)庫的高效的標準軟件體系結構 中文版（8頁珍藏版）》請在裝配圖網上搜索。

屆 畢業(yè)設計（論文） 英文參考文獻 英文文獻 1： of to 文獻 出處，年， 期 ) 4 998 作者 ： N. S. 英文文獻 2： of 文獻 出處，年， 期 ) 00 076, T&T 200 7748, 002; 002 作者 ： 學生院系 專業(yè)名稱 學生班級 學生姓名 學生學號 學生層次 英文文獻 1 譯文： 基于 訪問遠程 數(shù)據(jù)庫的 高效的 標準軟件體系結構 摘要： 新穎的客戶端服務器體系結構利用 術越來越有利于遠程數(shù)據(jù)庫存取，其結構是在客戶端采取 覽器作為圖形用戶界面，在服務器端采取傳統(tǒng)的 據(jù)庫管理系統(tǒng) ( 目 前，在標準瀏覽器和具體 間的活動是由 一定數(shù)量的 基于上一代 瀏覽器中的 擬機 的軟件結構支持。這些軟件結構 , 從開放性和靈活性問題看 似乎很好 , 但在 數(shù)據(jù)庫存取 方面卻存在不足 。 本文將通過對一定數(shù)量的實驗結果的分析 指出這些不足 。本文描述 了 四個不同 的 基于 術的 軟件結構支持 數(shù)據(jù)庫存取，報告了它們在不同的硬件平臺上工作的性能測試，并對測試結果進行了比較分析。 關鍵字： 執(zhí)行 評估 ； 可視化 數(shù)據(jù)庫存取 1. 介紹 對客戶服務器數(shù)據(jù)庫 訪問 的傳統(tǒng) 解決方法 是 根據(jù) 由 一種 直觀 語言 編寫 的 用戶界面的聯(lián)合的行動 (即客戶 ) 和 一個標準 擎 (即服務器 ) 。當前 , 這種方法 正受到一種 基于新興的 例的新穎的解決辦法 的挑戰(zhàn) 。 基于互聯(lián)網的 用戶界面，通常用 寫， 由瀏覽器從服務器下載 并運行在虛擬瀏覽器 上 。 這樣的解決辦法的要點是客戶軟件 作為一個獨特的副本 處 在服務器系統(tǒng)， 這就好于 客戶軟件 在 客戶 機 系統(tǒng)里。 由于集中所有這些操作在服務器站點 成為 可能 ，這就使客戶軟件的安裝、配置和維護費用 被降低 。 對 據(jù)庫的基于互聯(lián)網的 訪問 ，可以得到由很多基本組成成分組成的軟件體系結構的支持。 令人遺憾這 樣的軟件體系結構，從開放 性 和靈活性來看似乎 很 好， 但是給數(shù)據(jù)庫接口方面帶來了明顯的潛在 危機。 圖 1. 軟件結構 1: 通過 口訪問 數(shù)據(jù)庫 在這篇文章里 將描述四個不同 的 基于互聯(lián)網 訪問 據(jù)庫 的 軟件結構 ，并且 通過 報告 和 比較他們的 執(zhí)行情況來揭示各個體系結構的潛在危機的來源。 本文 結構 如下 ： 首先我們描述基于 數(shù)據(jù)庫存取 的 準軟件 體系結構 (第2 部分 )； 然后我們提出使用的試驗 平 臺和在我們的實驗過程中 遵循 的方法 (第 3 部分 )； 最后我們 給 出 了 結果 (第 4 部分 )， 并且討論 了 軟件體系結構 的 性能 (第 5 部分 )；總結 (第 6 部分 )結束 本文 。 2. 基于 數(shù)據(jù)庫 存取 的軟件體系結構 在這個部分我們提出四個 適合我們的調查 的 基于 問 數(shù)據(jù)庫 的 軟件結構 。 每 個體系結構都 遵循客戶機服務器 體系 并且由 3 個主要實體組成 ： 客戶、服務器和共用 組件 。 客戶和服務器在每 個體系結構 里是相同的； 共用 組件在各個體系結構之間則起著不同的作用。 客戶是一個 基于 術的 瀏覽器 , 服務器是 一個 接受遠程 網絡 連接 和查詢 的 據(jù)庫管理系統(tǒng) ( 網絡協(xié)議 采取 P 協(xié)議 。 各個軟件 體系 結構 的 共用 組件 在 結尾 部分描述。 基于 口 的 連接 模塊結構 基于 口的 連接 模塊結構如 圖 1 所示。陰影部分表示 軟件模塊 ， 程序員必須發(fā)展 它們使其余的組成部分連接起來。 客戶 端 (瀏覽器 )從服務器 端 上下載一個 用程序并且運轉它。 用程序通過 口模塊發(fā)送查詢和接收回應。 服務器 (過作為中間代理的一個軟件 元件 與客戶交換數(shù)據(jù)。這樣的 一個 中間 代理軟件接受 客戶 查詢 并且通過 息庫把它們提交到數(shù)據(jù)庫。 在 用程序和中間 代理軟件 之間的連接性 是 基于 議 。 在客戶端通信由標準 口 持 ; 在服務器端通信由標準 口接口支持。 在 用程序和中間 代理軟件 之間的操作 是 基于 支持 基本 數(shù)據(jù)庫存取操作的一個 普通 協(xié)議 （ 打開數(shù)據(jù)庫，提交 查詢 ， 接收回 應， 關閉 數(shù)據(jù)庫 ）。 基于專有的 數(shù)據(jù)庫管理系統(tǒng) 動程序的體系結構 基于專有的 動程序 的 結構如 圖 2 所示 。 允許 用程序 和應用 軟件在后臺訪問 數(shù)據(jù)庫的一個標準接口 。 和 前 面介紹 的 結構 一樣，客戶 機 (瀏覽器 )從服務器上下載一個 用程序并且運轉它 ， 用程序通過標準 用編程接口 (問 作為 標準 和 基于 術的 瀏覽器的最新 版本 的 一 部份 。 對不同 的不一樣 ， 施通信協(xié)議 時 必需 用 到 具體的 動程序。 具體 產商 或者第三 方 提供 ，并且 動態(tài)地連接標準 象。 通常 ， 動程序 跟客戶 端的 用程序一起從服務器下載。 圖 2 基于專有的 問 數(shù)據(jù)庫的軟件體系結構。 圖 3 基于 訪問 數(shù)據(jù)庫的軟件體系結構。 的體系結構 基于請求 機制 的軟件體系結構 如圖 3 所示。 如同前 面 的體系結構， 用程序通過標準 具體的 動 程序 與數(shù)據(jù)庫進行信息交流。與以前的體系結構 不同 ， 動 程序 不直接訪問數(shù)據(jù)庫，但是它訪問一個通過一份專有的協(xié)議運 行 在服務器上 的中間對象。 當 用程序 請求連接 時 ,動態(tài)地 生成 二個組分 : 為具體 采取 的 一個 理和 一個 數(shù)據(jù)庫代理。 圖 4 基于 數(shù)據(jù)庫 訪問 的軟件體系結構。 sv sv 1 作為被測試的軟件體系結構的組成部分使用 的 軟件產品 組成部分之間可用性 的結構 基于 結構如 圖 4 所 示。 在這 種 情況 下 用程序通過面向對象的 系。 服務器 端的 數(shù)據(jù)庫存取對象 進行交互。后臺操作由對象請求代理程序 (持 。 數(shù)據(jù)庫存取對象由系統(tǒng)集成商開發(fā) ， 它的 過一種正式的規(guī)范語言 不同的語言 編寫，它 支持在客戶 機 和服務器之間的可靠的操作 。 3. 測試和方法 在這個部分我們描述我們使用的試驗 平臺和 我們隨后執(zhí)行實驗的方法。我們在 服務器 ( , 200 32 M 作系統(tǒng) )安裝了 在 客戶機（ 166 C 機 ， 作系統(tǒng) ）安裝 不同 的 軟件 組件，選擇的 產品 如表 1所示。我們選擇了三個對數(shù)據(jù)庫的基本操作來進行測試，即 打開數(shù)據(jù)庫、查詢、數(shù)據(jù)庫關閉。我們?yōu)闇y試選擇的查詢是一個單獨的選擇，它從一個超過 4 列 39 000 行的表中而來，由 34 符串組成。 為了使偶然 性 減到最小 ，對每個潛在因素的測量都 重復實驗超過 6000 次并且選擇最小 的 結果 。 C 3 54 67 37 60 68 38 62 68 38 68 69 表 2 各個平臺利用 間 4. 實驗和結果 實驗能達到的標準和訪問數(shù)據(jù)庫的響應時間。 在初步的實驗里我們 測試 存在于 4 個 軟件體系結構的普通組成部分。在其余實驗里我們 測試 每軟件體系結構的響應時間 并且 確定 具體的 消耗時間 以及 這些時間消耗 的 原因 。 我們報告初步實驗的結果在 分和實驗 其 余的結果在 分。 這部分提出 初步測試 基于 客戶 端 軟件體系結構 的 響應時間 ， 即， (i)數(shù)據(jù)庫本地存取時間和 ( 件 通訊時間。 數(shù)據(jù)庫本地存取時間 測試 ， 我們開發(fā)一個 C 程序 來執(zhí)行對數(shù)據(jù)庫的基本操作，并測試它的運行時間。 測量數(shù)據(jù) 結果以 毫秒 為單位 ， 詳見 表 2(第一欄 )。 我們 還測試了 以 P 協(xié)議聯(lián)系 庫 和 取 數(shù)據(jù)庫的 響應時間。其響應時間小于 2以忽略不記。 為了測量 件 通訊時間，我們建立 了 基于插 件 連接 的 模 塊 (參閱第 分 )結構 。 結構中的代理模塊可在先前的實驗里， 通過 P 協(xié)議用 C 程序連接獲得。 測量 結構 的 響應 時間 的 數(shù)據(jù)在表格 2 的第 2 欄里 （每一列分別對應測試中用到不同的硬件平臺）。 結果 顯示 通過 件 遠程訪問數(shù)據(jù)庫 的響應時間不可以忽視，即打開數(shù)據(jù)庫和 執(zhí)行查詢的時間占到 10 C C C 3 54 67 143 101 5 192 104 8 218 106 10 70 77 0 93 80 0 160 83 1 39 66 72 42 71 75 44 78 78 表 3 不同的軟件體系結構和客戶平臺最小 查詢時間 這部分提出 對 標準 高效的體系結構 進行實驗評價 ，體系結構已在 第 2 部分中 描述。 對標準體系結構的評價是 基于 件之間的可用性。在這個部分 里 我們提出 對兩個標準體系結構的內部響應時間進行測試，其中一個是 基于 準 ，一個是 基于 準 。 動程序 的 結構 的效率 表 3 的 2是 基本 的 存取數(shù)據(jù)庫時間 數(shù)據(jù) ， 以 毫秒 為單位， 那些 結構的規(guī)則 在第 分 里 描述。 在 開放性 的操作里我們 確 定 時間消耗有 以下兩個來源： (i) 每當數(shù)據(jù)庫被打開時建立一個 件 連接， (通過插 件 讀 /寫 的對數(shù)據(jù)庫連接必要的每個項目 (登錄，密碼，數(shù)據(jù)庫名字等等 )。 第一 項來源是由 準數(shù)據(jù)庫關閉操作導致 P 連接 關閉 引起的 。 在 臺消耗的時間是 18 在 臺消耗的時間是 28 在 臺消耗的時間是 37 第 二 項來源是由 為了減少在 口上讀和寫的操作， 選擇單個字符串 信息 。這一時間消耗在不同的硬件平臺上變化很大（ 0 2 7 的 結構 的效率 表 3 的 5是 基本 的 存取數(shù)據(jù)庫時間 數(shù)據(jù) ， 以 毫秒 為單位， 那些 結構的規(guī)則 在第 分 里 描述。 在 開放性 的操作里我們 確定時間消耗有 以下兩個來源： (i)小應用程序分別向請求 代理 和 建立兩個網絡連接打開數(shù)據(jù)庫 ； (務器需要 很 長的時間來處理這兩個連接 。 第一個時間消耗是 36們 取決于硬件平臺 。第二個時間消耗大約是 75們是通過測試 對 求建立連接 到獲得查詢的時間間隔再減去網絡延遲得到這一結果 的。 截止時間 表示， 數(shù)據(jù)庫關閉 是 在網絡連接關閉之后。截止時間 僅僅包括 在那些代理終止之前 的 必要的握手行動。 結構 的效率 表 3 的 8是 基本 的 存取數(shù)據(jù)庫時間 數(shù)據(jù) ， 以 毫秒 為單位， 那些 結構的規(guī)則 在第 分 里 描述。 測試結果顯示， 基于 結構在 所有硬件工作臺 上直接 在 口上所有操作的響應時間可以忽略不記（ 參見表 2）。 在基于 的 結構 里獲得的關于通信協(xié)議和插 件 方法的幾 個 最優(yōu)化的結果 是很有價值的。 因此，我們實驗 表明 利用 件可使 件之間可用性 最優(yōu)化 。 5. 討論 實驗在前 面 部分提出 了 基于 術訪問數(shù)據(jù)庫的 標 準解決辦法 。假設在本地連接環(huán)境（局域網）下，網絡延遲不影響其他的延遲而可以忽略不記，那么這種解決方案是可行的。 在我們的實驗過程中獲得的 口 模 塊 的工作特性是： 連接和讀 /寫操作的反應時間快，接口相對根據(jù)使用的硬件平臺傳輸?shù)臄?shù)據(jù)類型的高可變性。 件 的可變性影響 了 所有其他 基于 件的方法的執(zhí)行。然而我們在進行 基于 決辦法的 實驗時，考慮到了所有可變性的影響。 一些實驗揭示 座接口把它的劣質的性能傳播到 件。尤其我們做 的 實驗， 件的執(zhí)行 增加 了 大約 30 到 100 的反應時間 并且 高度依賴 使用的硬件 平 臺。 反之，其他實驗 顯示 有受 件運行 的劣質性能 的 影響。 特別是我們 在客戶端的 口上測試到了接近最優(yōu)的結果，而且在不同硬件平臺上結果也不變。 最后，我們證明 準模件 是在 高性能 的 局域網環(huán)境 下 最適合 的 解決數(shù)據(jù)庫 存取的 辦法， 原因如下： —— 構足以可靠和輕易的支持用不同的語言運行在不同的環(huán)境里的客戶機和服務器之間的各種標準接口； —— 構 屬于標準 程序包， 足以最優(yōu)的解決 口 執(zhí)行時的問題。 6. 總結 文章提出 針對 四個 基于 口和關于 準 的 軟件結構 在執(zhí)行時的性能的測試方法。 這兩個標準 是最 頻繁 的被用來解決 由 戶 機輕易的訪問遠程 數(shù)據(jù)庫服務器 的方法。 我們的工作的主要貢獻是性能評價和軟件體系結構的比較測試 ，這對證明各個體系結構在訪問數(shù)據(jù)庫時的 瓶頸 問題很有意義。