【文章內(nèi)容簡介】 于使用率較低而溢出內(nèi)存[9]。2. 性能緩存的執(zhí)行計劃曾使存儲過程較之查詢更有性能優(yōu)勢。但對于 SQL Server 的幾個最新版本，執(zhí)行計劃已針對所有 TSQL 批處理進行了緩存，而不管它們是否在存儲過程中。因此，基于此功能的性能已不再是存儲過程的賣點。任何使用靜態(tài)語法，且提交頻率足以阻止執(zhí)行計劃溢出內(nèi)存的 TSQL 批處理將會獲得同樣的性能好處。“靜態(tài)”部分是關鍵；任何更改，即使像添加注釋這樣無關緊要的更改，也將導致無法與緩存的計劃相匹配，從而將無法重復使用計劃。但是，當存儲過程可以用于降低網(wǎng)絡流量時，它們?nèi)匀荒軌蛱峁┬阅芎锰?。您只需在網(wǎng)絡中發(fā)送 EXECUTE stored_proc_name 語句，而非整個 TSQL 例程，這可以在復雜操作中廣泛使用。設計良好的存儲過程可以將交易記錄端與服務器之間的許多往返過程簡化為單個調用。此外，使用存儲過程使您能夠增強對執(zhí)行計劃的重復使用，由此可以通過使用遠程過程調用 (RPC) 處理服務器上的存儲過程而提高性能。使用 StoredProcedure 時，存儲過程通過 RPC 執(zhí)行。RPC 封裝參數(shù)和調用服務器端過程的方式使引擎能夠輕松地找到匹配的執(zhí)行計劃，并只需插入更新的參數(shù)值。考慮使用存儲過程提高性能時，最后要考慮是否要充分利用 TSQL 的優(yōu)點。請考慮要如何處理數(shù)據(jù)。 (1) 是否要使用基于集合的操作，或執(zhí)行 TSQL 中完全支持的其他操作？那么存儲過程就是一個選擇，而內(nèi)聯(lián)查詢也可以使用。(2) 是否嘗試執(zhí)行基于行的操作，或復雜的字符串處理？那么可能要重新考慮在TSQL 中進行這種處理，這不包括使用存儲過程，至少要到 Yukon 發(fā)布并且公共語言運行庫 (CLR) 集成可用后，才能使用存儲過程。3. 可維護性和抽象要考慮的另一個潛在優(yōu)勢是可維護性。理想情況下，數(shù)據(jù)庫架構從不更改，業(yè)務規(guī)則不被修改，但在現(xiàn)實環(huán)境中，情況則完全不同。既然情況如此，那么如果可以修改存儲過程以包括新 X、Y 和 Z 表（為支持新的銷售活動而添加了這些表）中的數(shù)據(jù)，而不是在應用程序代碼中的某個位置更改此信息，則維護對您來說可能比較容易。在存儲過程中更改此信息使得更新對應用程序而言具有透明性。您仍然返回相同的銷售信息，即使存儲過程的內(nèi)部實現(xiàn)已經(jīng)更改。更新存儲過程通常比更改、測試以及重新部署程序集需要較少的時間和精力。 另外，通過抽象化實現(xiàn)并將此代碼保存在存儲過程中，任何需要訪問數(shù)據(jù)的應用程序均可以獲取一致的數(shù)據(jù)。您無需在多個位置維護相同的代碼，用戶便可獲取一致的信息。在存儲過程中存儲 TSQL 的另一個可維護性優(yōu)點是更好的版本控制。您可以對創(chuàng)建和修改存儲過程的腳本進行版本控制，就像可以對任何其他源代碼模塊進行版本控制一樣。通過使用 Microsoft Visual SourceSafe174。 或某個其他源代碼控制工具，您可以輕松地恢復到或引用舊版本的存儲過程。 在使用存儲過程提高可維護性時應值得注意的一點是，它們無法阻止您對架構和規(guī)則進行所有可能的更改。如果更改范圍大到需要對輸入存儲過程的參數(shù)進行更改，或者要更改由其返回的數(shù)據(jù)，則您仍需要更新程序集中的代碼以添加參數(shù)、更新GetValue()調用，等等。要注意的另一個問題是，由于存儲過程將應用程序綁定到SQL Server，因此使用存儲過程封裝業(yè)務邏輯將限制應用程序的可移植性。如果應用程序的可移植性在您的環(huán)境中非常重要，則將業(yè)務邏輯封裝在不特定于RDBMS的中間層中可能是一個更佳的選擇。 4. 安全性考慮使用存儲過程的最終原因是它們可用于增強安全性。 就管理用戶對信息的訪問而言，通過向用戶授予對存儲過程（而不是基礎表）的訪問權限，它們可以提供對特定數(shù)據(jù)的訪問。存儲過程可以看成是SQL Server視圖，除非存儲過程接受用戶的輸入以動態(tài)更改顯示的數(shù)據(jù)。存儲過程還可以解決代碼安全問題。它們可以防止某些類型的SQL插入攻擊。主要是一些使用運算符（如AND或OR）將命令附加到有效輸入?yún)?shù)值的攻擊。在應用程序受到攻擊時，存儲過程還可以隱藏業(yè)務規(guī)則的實現(xiàn)。這對于將此類信息視為知識產(chǎn)權的公司非常重要。另外，使用存儲過程使您可以使用JAVA中提供的SqlParameter類指定存儲過程參數(shù)的數(shù)據(jù)類型。這為驗證用戶提供的值類型（作為深層次防御性策略的一部分）提供了一個簡單方法。在縮小可接受用戶輸入的范圍方面，參數(shù)在內(nèi)聯(lián)查詢中與在存儲過程中一樣有用。使用存儲過程僅僅能夠增強數(shù)據(jù)庫安全性，而不能完全使數(shù)據(jù)庫免受攻擊。如果數(shù)據(jù)庫的安全性或編碼做法不完善仍然會受到攻擊。對SQL Server角色創(chuàng)建和分配如果不加注意將導致人們訪問到不應看到的數(shù)據(jù)。同時，如果認為使用存儲過程便可防止所有SQL插入代碼攻擊（例如，將數(shù)據(jù)操作語言 (DML) 附加到輸入?yún)?shù)），后果將是一樣的。另外，無論TSQL位于代碼還是位于存儲過程中，使用參數(shù)進行數(shù)據(jù)類型驗證都不是萬無一失的。所有用戶提供的數(shù)據(jù)（尤其是文本數(shù)據(jù)）在傳遞到數(shù)據(jù)庫之前都應受到附加的驗證。5. 使用存儲過程的優(yōu)缺點使用存儲過程封裝應用邏輯的優(yōu)點如下：(1) DBA+Developer分工明確，之間代碼模塊化。減少數(shù)據(jù)庫操作員和程序員的錯誤。(2) 數(shù)據(jù)庫安全性；可以設置連接字符串中賬號只可訪問存儲過程，不可操作表。這樣數(shù)據(jù)完整性也有保證。(3) 存儲過程是編譯過的，執(zhí)行快。(4) 事務的級別，存儲過程級別的事務，JAVA級別的事務比較。一致性。(5) 減少網(wǎng)絡通信量。一個需要數(shù)行 TransactSQL 代碼的操作由一條執(zhí)行過程代碼的單獨語句就可實現(xiàn)，而不需要在網(wǎng)絡中發(fā)送數(shù)行代碼。使用存儲過程封裝應用邏輯的缺點如下：(1) 編程語言SQL功能較差（不包括 SQL 2005）(2) 與編程環(huán)境集成不夠（不包括 SQL 2005）(3) 移植性差（不同數(shù)據(jù)庫）(4) 數(shù)據(jù)庫服務器壓力大 數(shù)據(jù)庫的表的設計根據(jù)項目要求進行數(shù)據(jù)庫中表格的建立。根據(jù)對用戶的需求分析，在項目中，需要記錄銀行的基本信息、交易記錄的基本信息、銀行的操作信息。數(shù)據(jù)庫的設計范式是數(shù)據(jù)庫設計所需要滿足的規(guī)范，滿足這些規(guī)范的數(shù)據(jù)庫是簡潔的、結構明晰的，同時，不會發(fā)生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給數(shù)據(jù)庫的編程人員制造麻煩，而且面目可憎，可能存儲了大量不需要的冗余信息。范式的介紹：第一范式（1NF）：數(shù)據(jù)庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數(shù)、字符型、邏輯型、日期型等。第二范式（2NF）：數(shù)據(jù)庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數(shù)依賴（部分函數(shù)依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的情況），也即所有非關鍵字段都完全依賴于任意一組候選關鍵字。第三范式（3NF）：在第二范式的基礎上，數(shù)據(jù)表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數(shù)依賴則符合第三范式。所謂傳遞函數(shù)依賴，指的是如果存在“A → B → C”的決定關系，則C傳遞函數(shù)依賴于A。因此，滿足第三范式的數(shù)據(jù)庫表應該不存在如下依賴關系：　　關鍵字段 → 非關鍵字段x → 非關鍵字段y鮑依斯科得范式（BCNF）：在第三范式的基礎上，數(shù)據(jù)庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數(shù)依賴則符合第三范式?？梢韵谌妒絼h除異常、插入異常和更新異常[13]。系統(tǒng)中還需要有用戶的登錄信息表用于記錄用戶的登錄信息。登錄信息表中應該有登錄的用戶名和密碼，其中登錄名為主鍵。 設計局部ER模式1實體和屬性的定義：1）管理員用戶類別（用戶名，密碼，權限，注冊時間等）管理員用戶用戶名密碼權限注冊時間……圖42管理員用戶實體與屬性的定義2）賬戶信息類別（姓名，身份證，性別，聯(lián)系電話，地址，注冊時間等）賬戶信息姓名性別地址注冊時間時間……圖43賬戶信息實體與屬性的定義3）交易記錄信息類別（姓名，性別，身份證，電話，地址） 轉入賬戶轉出賬戶類型身份證……交易信息圖44 交易記錄信息實體與屬性的定義2 實體關系定義：ER模型的“聯(lián)系”用于刻畫實體之間的關聯(lián)。一種完整的方式是對局部結構中任意兩個實體類型，依據(jù)需求分析的結果，考察局部結構中任意兩個實體類型之間是否存在聯(lián)系。若有聯(lián)系，進一步確定是1:1:N、M:N的關系。還要考察一個實體類型內(nèi)部是否存在聯(lián)系，兩個實體類型之間是否存在聯(lián)系，多個實體類型之間是否存在聯(lián)系，等等針對本系統(tǒng)分析如下：實體間的關系：① 一個管理員可以管理多個自助銀行賬戶，而一個自助銀行賬戶只能被一個管理員管理。管理員ATM賬戶1N管理圖45 自助銀行賬戶與管理員信息管理1:N(一對多的關系)管理員出入賬信息1N管理② 一個管理員可以管理多個出入賬信息，而一個出入賬信息只可以被一個管理員管理圖46管理員與出入賬信息1:N（一對多的關系） 設計全局ER模式所有局部ER模式都設計好了后，接下來就是把它們綜合成單一的全局概念結構。全局概念結構不僅要支持所有局部ER模式，而且必須合理地表示一個完整、一致的數(shù)據(jù)庫概念結構。1) 確定公共實體類型 為了給多個局部ER模式的合并提供開始合并的基礎，首先要確定各局部結構中的公共實體類型。在這一步中我們僅根據(jù)實體類型名和鍵來認定公共實體類型。一般把同名實體類型作為公共實體類型的一類候選，把具有相同鍵的實體類型作為公共實體類型的另一類候選。2) 局部ER模式的合并 合并的原則是：首先進行兩兩合并；先合并那些現(xiàn)實世界中有聯(lián)系的局部結構；合并從公共實體類型開始，最后再加入獨立的局部結構。3) 消除沖突 沖突分為三類：屬性沖突、結構沖突、命名沖突。 設計全局ER模式的目的不在于把若干局部ER模式形式上合并為一個ER模式，而在于消除沖突，使之成為能夠被所有用戶共同理解和接受的同一的概念模型。4) 全局ER模式的優(yōu)化 在得到全局ER模式后，為了提高數(shù)據(jù)庫系統(tǒng)的效率，還應進一步依據(jù)處理需求對ER模式進行優(yōu)化。一個好的全局ER模式，除能準確、全面地反映用戶功能需求外，還應滿足下列條件：實體類型的個數(shù)要盡可能的少；實體類型所含屬性個數(shù)盡可能少；實體類型間聯(lián)系無冗余。數(shù)據(jù)字典是在新系統(tǒng)數(shù)據(jù)流程圖基礎上，進一步定義和描述所有數(shù)據(jù)項的工具，是關于數(shù)據(jù)的數(shù)據(jù)。它包括對一切動態(tài)數(shù)據(jù)和表態(tài)數(shù)據(jù)的數(shù)據(jù)結構和相互關系等的說明，是數(shù)據(jù)分析和數(shù)據(jù)管理的重要工具。數(shù)據(jù)字典實際上是新系統(tǒng)的所有數(shù)據(jù)流、數(shù)據(jù)存儲、數(shù)據(jù)結構、數(shù)據(jù)元素和處理功能等卡片的集合。這些卡片內(nèi)容是根據(jù)數(shù)據(jù)流程圖，通過數(shù)據(jù)調查和分析得到的。數(shù)據(jù)字典可以匯總成清單形式，經(jīng)過數(shù)據(jù)分析及規(guī)范化轉換成組織模式，進行數(shù)據(jù)庫的邏輯設計；或者，直接用來進行文件設計。數(shù)據(jù)字典的卡片內(nèi)容不可能在系統(tǒng)分析階段都填寫完善，還須在系統(tǒng)設計和實施階段進行補充和修改。