郭紅資料庫

❶ 求《資料庫原理與應用》SQL Server版 毛一梅，郭紅著的課後習題答案，發至[email protected]

地方史蒂夫

❷ 基於J2EE的圖書管理系統畢業設計

摘要：對基於XML的多源異構數據融合、遙感數據存儲、數據持久化以及用戶訪問控制技術進行了分析和設計；討論了元數據管理系統的實現技術、設計思想和系統構架，注重系統的可移植性、可維護性和可擴展性；實現了基於J2EE技術的元數據管理系統。�
關鍵詞：Java 2平台企業版；元數據管理；擴展標記語言�

隨著信息技術的發展，產生了海量的信息。如何有效地管理和組織這些海量信息已經成為一個突出的問題。元數據機制是解決這一問題的有效手段。一些部門已經針對數據在行業內部的應用特點來開發自己的管理系統[1]。目前，在元數據管理系統的建設中存在的主要問題是：基於不同操作系統和資料庫的管理平台不可移植、安全性差、難以維護和擴展、缺乏統一的建設模式與內容服務提供方式[2，3]。�
以J2EE平台為基礎的各項技術的成熟為這些問題提供了良好的解決方案。J2EE是一種利用Java2平台來簡化諸多與多級解決方案的開發、部署和管理相關的復雜問題的體系結構。J2EE的核心技術是Java2平台的標准版，具有Java語言的特性，是一個開放的、跨平台的結構，提供了健全的意外事件處理機制，具有良好的可移植性和擴展性。�
基於J2EE的元數據管理系統具有高效、穩定、可復用、易維護的特點；獨立於平台，可以部署於Microsoft Windows、Linux、UNIX等操作系統之上；可對Oracle、SQL Server 2000、MySQL等多種資料庫進行操作。但是J2EE涉及的技術種類繁多，在實際應用中要根據需要准確使用，而且基於J2EE的系統需要具有良好的系統設計結構，才能最大限度地發揮優勢。盡管基於J2EE平台的系統具有諸多優點，但目前J2EE還沒有被廣泛應用在元數據管理中。本文提出的基於J2EE架構的元數據管理系統建設方法和應用實例，是將J2EE引入元數據管理的一個初步嘗試。�

1關鍵技術研究�

1．1基於XML的多源異構數據融合�
各個部門採用了不同的元數據存儲方式。由於缺乏統一的標准，很難對這些元數據進行有效的管理和發布。必須實現多源異構數據的融合。�
採用簡單文本文件作為中間介質的信息交換方法不能描述數據的結構，不適合用來進行復雜的元數據交換。 XML技術實現信息交換與共享已經成為一種發展趨勢。孫君明等人[4]對基於XML的數據交換技術進行了研究。XML是採用線性語法描述樹狀結構的標志語言。作為一種數據交換的中間件，XML具有跨平台、結構化和自描述性強的特點。�
用XML實現多源異構數據融合的過程如圖1所示。�
在圖1中，首先各地的數據提供者通過瀏覽器將數據傳送給伺服器，由伺服器端的XML引擎將這些數據轉換成標準的XML文檔；再由一些服務組件根據需要對XML文檔進行處理，如建立索引等。這樣，多源異構數據就被轉換成了具有統一標準的XML文檔；通過對這樣具有固定結構的XML中間件的解析，實現從XML文檔到資料庫的轉換，完成了多源異構數據的統一存儲[4，5]。進行信息發布時，根據客戶端的查詢條件在資料庫中提取相應的結果集，形成XML文檔，將該文檔發送至客戶端；由客戶端的格式化工具解析該XML文檔，顯示在客戶端。�

1．2遙感數據的分塊存儲�
遙感數據（如DEM、TM、ASTER等）具有數據量龐大的特點，應用資料庫中的大數據類型存儲，如Oracle 9i中的Blob、SQL Server 2000中的Image。但是如果將它們直接存入資料庫中會造成系統效率低下;可採用一種分塊存儲的策略，將原始數據分割成大小一致的若干塊，一塊一塊地進行存儲。分塊大小要根據磁碟的讀寫性能和網路的傳輸性能確定，過大或過小都會導致系統運行效率低下[6]。每塊數據以一條記錄的方式進行存儲，包含數據的編號、經緯度、步長、時間等信息，並且建立索引。�

1．3數據持久化�
為了能使系統部署在任意資料庫系統上，加入了一個持久化層，作為連接Java應用和關系資料庫的通道。為資料庫中的每張表建立一個Java對象，定義好對象與表之間的對應關系，只需對Java對象進行操作，不用關心SQL語句和系統最終使用的資料庫。持久層作為一個中間件，封裝對資料庫的操作，提供介面，隱藏數據訪問的細節[7]。�
1．4用戶訪問控制�
元數據的使用人員級別復雜，用戶管理困難。使用RBAC(Role－Based Access Control，基於角色的訪問控制)模型，可以提高管理的效率和安全性。RBAC在傳統的用戶——許可權模型中引入了角色的概念。角色是一組用戶的集合，也是一個授權的集合，它將一組用戶與許可權聯系起來。一個角色可以與多個用戶對應，一個用戶可以擁有多個角色，每個角色可以執行多種許可權，每個許可權可以被多個角色共享。對一個用戶授予相應的角色，使用戶可以進行相應的操作[8]。引入角色可以使系統的安全機制具有很大的靈活性，減少了許可權管理的負擔和代價，同時也增強了系統的可維護性。�

2元數據管理系統的設計�

使用本系統的各部門實際情況不同，系統可能被部署到不同的平台上，而且需要對該系統進行一定的擴展和改進。所以在系統設計上，需要充分考慮到系統的可移植性和可擴展性。�

2．1系統設計�
本系統基於J2EE平台，是一個瀏覽器/伺服器（B/S）結構的系統，具有J2EE平台可以跨系統使用的特性，採用MVC（Model－View－Controller）應用框架。MVC設計框架的內部原理比較復雜，將MVC運用到應用程序中會帶來大量的額外工作，增加應用的復雜性。但是MVC可以輕松地實現程序代碼與HTML的分離，而且MVC的三個模塊相互獨立，可以構造良好的松耦合構件，提高應用系統的可維護性、可擴展性、可移植性和可復用性。從長遠的應用考慮，應使用MVC設計框架[9]。�

本系統在傳統的B/S三層結構上作了一定的改進。�
（1）表現層。在該層使用Struts框架。Struts是一個MVC模式的表現層應用框架。瀏覽器向Web伺服器提出請求後，Web伺服器會把請求交給控制器處理。ActionServlet控制器根據請求的不同，將它們轉發給不同的Action實例。Action實例在這里充當了用戶請求與業務處理邏輯之間的適配器，它只負責控制整個程序的流程，不關心具體業務的實現，實現了請求與業務邏輯的分開。本系統使用一個高效的Action類——DispatchAction類。只要繼承該類，就可以在一個Action中集成多個業務方法，有利於系統的維護。在視圖顯示方面，其大量使用了Struts標簽，用來控制顯示的邏輯和內容。由於不同平台採取的編碼方式不同，在進行系統移植時很容易出現中文亂碼問題。在這里使用一個可插拔式的過濾器，實現對請求和響應的預處理及後處理，很好地解決了字元編碼問題，使系統可以在不同的平台上進行移植。

（2）業務層。它處理用戶請求和應用邏輯。在處理之前，將所有涉及到表現層的數據結構替換成更加通用的數據結構類型；使用通用的、與表現層無關的數據結構在這兩層之間傳遞參數。表現層方法提交的參數類型主要是HttpServletRequest和HttpServletResponse；使用這樣的參數會增加系統的耦合性，不利於代碼的重用，所以要將它們處理成通用的數據類型，如數組。這一過程在Action適配器進行轉發之前完成，提供給業務層的參數是通用的數據類型[10]。業務層方法之間的通信也通過通用的參數類型進行，使得每個業務方法均獨立存在於系統之中，在很大程度上減少了系統的耦合，提高了可復用性。�

（3）數據層。為了實現資料庫訪問細節與業務層的分離，引入持久化層。�
為了使系統具有較好的可維護性、可移植性和可復用性，採用以上的設計思想，以搭建一個邏輯清楚、功能明確、模塊化程度高的元數據管理系統。�

2．2工作流程�
用戶通過瀏覽器（IE/Netscape）向伺服器提交請求，請求經過過濾器處理後再提交給控制器ActionServlet；控制器根據請求的類別將它們轉發給不同的DispatchAction類。該類中的方法對參數進行處理後調用不同的業務邏輯對請求進行分析處理，處理後得到的信息通過視圖顯示在用戶瀏覽器上。�

3基於J2EE的元數據管理系統的實現�

根據本文提出的設計思想，實現了一個元數據管理系統——基於J2EE的小城鎮元數據管理平台。本實例以J2EE平台為基礎，Tomcat 5.0為伺服器，可以使用Oracle 9i、SQL Server 2000、MySQL資料庫，使用了ORM（Object－Relation Mapping）模式的持久化層中間件Hibernate，以Eclipse 3.0為開發平台。在系統實現過程中，使用了以J2EE平台為基礎的各項技術，遵循Java2標准平台的編碼標准，注重系統的可擴展性和可維護性。系統的XML引擎採用了DOM（Document Object Model）和SAX（Simple API for XML）。DOM負責XML文檔的生成和修改；SAX對XML進行解析。
小城鎮元數據管理平台的功能主要分為管理與檢索兩部分，可以實現對矢量數據、柵格數據、文檔數據、原始試驗數據、報表數據和模型數據的管理與檢索；用戶管理可以對用戶進行許可權設置；系統管理功能可以提供系統運行的日誌和幫助文件。�

4結束語�

基於J2EE的元數據管理平台，具有良好的跨平台特性；解決了多源異構數據的融合、遙感數據的存儲、數據持久化和用戶控制訪問問題；在設計和實現過程中遵循J2EE的設計模式，具有良好的擴展性和維護性；功能模塊具有低耦合的特點，極大地提高了代碼的可復用性；可對元數據進行有效管理，實現信息的共享發布，廣泛地應用在各個領域。在如何提高系統的安全性方面還有待於對其進行進一步的研究。�

參考文獻：�
〔1〕吳洪橋，何建邦，池天河，等.基於Internet的元數據管理模式研究[J].計算機科學,2003,30(4)：89－91. [2]李廣乾 .小城鎮信息化建設的基本思路[J].信息化建設,2005(Z1)：24－26.�
[3]趙春江，楊信廷. 加強信息技術研究和開發促進小城鎮健康發展[J].小城鎮建設,2005(1)：22－23.�
[4]孫君明，郭紅. 基於XML的異構信息交換技術研究[J].計算機應用研究，2003,20(1)：70－72.�
[5]李德冠，陳夢東. 一種基於XML的數據交換系統的設計和實現[J].微機發展,2005,15(12)：12－14.�
[6]朱雷，潘懋，李麗勤，等. GIS中海量柵格數據的處理技術研究[J].計算機應用研究，2006,23(1)：66－68.�
[7]孫衛琴. 精通Hibernate：Java對象持久化技術詳解[M]. 北京：電子工業出版社,2005.�
[8]范會聯，李獻禮. 基於Struts框架的Web信息系統中RBAC的實現[J].計算機時代，2005(12)：33－34.�
[9]孫衛琴. 基於MVC的Java Web設計與開發[M]. 北京：電子工業出版社,2004.

❸ 轉SQLSERVER 會不會自動加鎖

[SQL]提升查詢效率與避免LOCK發生nolock: 可能把沒有提交事務的數據也顯示出來，可能會產生臟讀readpast： 會把被鎖住的行不顯示出來
所有Select加 With (NoLock)解決阻塞死鎖
在查詢語句中使用 NOLOCK 和 READPAST

處理一個資料庫死鎖的異常時候，其中一個建議就是使用 NOLOCK 或者 READPAST 。有關 NOLOCK 和 READPAST的一些技術知識點：

對於非銀行等嚴格要求事務的行業，搜索記錄中出現或者不出現某條記錄，都是在可容忍范圍內，所以碰到死鎖，應該首先考慮，我們業務邏輯是否能容忍出現或者不出現某些記錄，而不是尋求對雙方都加鎖條件下如何解鎖的問題。

NOLOCK 和 READPAST 都是處理查詢、插入、刪除等操作時候，如何應對鎖住的數據記錄。但是這時候一定要注意NOLOCK 和 READPAST的局限性，確認你的業務邏輯可以容忍這些記錄的出現或者不出現：

簡單來說：

NOLOCK 可能把沒有提交事務的數據也顯示出來．

READPAST 會把被鎖住的行不顯示出來

不使用 NOLOCK 和 READPAST ，在 Select 操作時候則有可能報錯誤：事務(進程 ID **)與另一個進程被死鎖在 鎖 資源上，並且已被選作死鎖犧牲品。

下面就來演示這個情況。

為了演示兩個事務死鎖的情況，我們下面的測試都需要在SQL Server Management Studio中打開兩個查詢窗口。保證事務不被干擾。

演示一 沒有提交的事務，NOLOCK 和 READPAST處理的策略：

查詢窗口一請執行如下腳本：

CREATE TABLE t1 (c1 int IDENTITY(1,1), c2 int)
go

BEGIN TRANSACTION
insert t1(c2) values(1)

在查詢窗口一執行後，查詢窗口二執行如下腳本：

select count(*) from t1 WITH(NOLOCK)
select count(*) from t1 WITH(READPAST)

結果與分析：

查詢窗口二依次顯示統計結果為： 1、0

查詢窗口一的命令沒有提交事務，所以 READPAST 不會計算沒有提交事務的這一條記錄，這一條被鎖住了，READPAST 看不到；而NOLOCK則可以看到被鎖住的這一條記錄。

如果這時候我們在查詢窗口二中執行：

select count(*) from t1 就會看到這個執行很久不能執行完畢，因為這個查詢遇到了一個死鎖。

清除掉這個測試環境，需要在查詢窗口一中再執行如下語句：

ROLLBACK TRANSACTION
drop table t1

演示二：對被鎖住的記錄，NOLOCK 和 READPAST處理的策略

這個演示同樣需要兩個查詢窗口。

請在查詢窗口一中執行如下語句：

CREATE TABLE t2 (UserID int , NickName nvarchar(50))
go
insert t2(UserID,NickName) values(1,'郭紅俊')
insert t2(UserID,NickName) values(2,'蟈蟈俊')
go

BEGIN TRANSACTION
update t2 set NickName = '蟈蟈俊.net' where UserID = 2

請在查詢窗口二中執行如下腳本：

select * from t2 WITH(NOLOCK) where UserID = 2
select * from t2 WITH(READPAST) where UserID = 2

結果與分析：

查詢窗口二中， NOLOCK 對應的查詢結果中我們看到了修改後的記錄，READPAST對應的查詢結果中我們沒有看到任何一條記錄。 這種情況下就可能發生臟讀