時間：2022-03-24 11:45:51
開篇：寫作不僅是一種記錄，更是一種創造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇關系數據庫，希望這些內容能成為您創作過程中的良師益友，陪伴您不斷探索和進步。
全球多家研究機構統計數據顯示，大數據產業將迎來發展黃金期，IDC預計，大數據和分析市場將從2016年的1300億美元增長到2020年的2030億美元以上，中國報告大廳的大數據行業報告數據也說明，自2017年起，未來2-3年的市場規模增長率將保持在35%左右。大數據像空氣一樣，隨處可見，日積月累的海量數據不得不讓人們重新考慮大數據的存儲和管理。
2傳統關系數據庫面臨的挑戰
基于二維關系模型的數據庫在數據管理的發展歷程中是一個標志性的時期，數據結構化存儲，冗余較低、程序和數據具有一定的獨立性、易擴充等特點。隨著Internet技術的發展，涌現出半結構化、非結構化數據，對這些結構復雜的大數據的高效實時多維分析的需求越來越多。傳統的關系數據庫從70年展至今，雖然應用范圍較廣技術較成熟，但在處理海量數據方面還存在許多不足。（1）關系模型結構制約了快速訪問大數據的能力。在二維關系表中，依據屬性的值來檢索相應的元組，受這種方式的束縛，在檢索數據過程中，將耗費一定的時間，從而使訪問數據的時間較慢。在存儲對象設計上雖然可以使用分區的方法，提高數據訪問沖突，但在大量數據的前提下，分區技術改善的性能較微弱。（2）處理大數據的靈活性不足。在應用系統中，用戶的各種查詢需求經常發生變化，不受時間和操作對象的約束，用戶希望隨時隨地都能快速得到反饋結果。關系型數據庫需要專門的數據庫維護人員對用戶的查詢要求進行優化處理，不能及時的反饋給用戶查詢結果，這使得使用關系數據庫存儲數據的企業不具備對大數據的快速響應能力。（3）處理復雜結構數據能力較弱。關系型數據庫對現實數據的處理常見類型為字符、數值等，對于半結構化和非結構化數據的處理只限于二進制代碼文件的存儲，而現今用戶對復雜結構數據的要求上升為識別、檢索和多維分析，如何處理占總數據量85%的非結構化數據，是許多關系數據庫產品需要解決的問題。（4）存儲維護管理PB級數據導致成本不斷增加。數據量遞增使得企業在硬件存儲上投資不斷增加，雖然存儲設備的投入成本在逐步降低，但總成本卻在逐步提高。此外，大量復雜結構的數據維護工作也給數據庫管理員增加了很多負擔。
3大數據庫技術
隨著大數據技術的日趨完善，各大公司及開源社區都陸續了一系列新型數據庫來解決海量數據的組織、存儲及管理問題。目前，工業界主流的處理海量數據的數據庫有四種，分別是列式數據庫、內存數據庫、鍵值數據庫及流式數據庫。
3.1列式數據庫
采用列族存儲數據，將經常被使用的數據放到一個列族中，例如，經常會查詢學生的學號和姓名，而不是專業，這樣把學號和姓名放到一個列族中，專業放到另一個列族中，該數據庫通常用來存儲分布式大數據，HBase是列式數據庫的典型代表。
3.2內存數據庫
對數據庫中所有數據的操作都在內存中完成，一般數據庫也有一定的緩存機制，對大部分數據的操作都包含從外存到內存的讀取，這一過程在很大程度上降低了系統的性能。由于在內存中的讀/寫是以納秒為單位的，所以內存數據庫的性能極高，Spark是內存數據庫的典型代表。
3.3鍵值數據庫
該數據庫主要借助哈希表的結構，使用一個特定的鍵和一個指向特定數據的指針，利用鍵來完成對數據庫中數據的添加、刪除和查詢操作，這種結構具有很好的擴展性，使系統具有較高的性能，Memcached、Redis、MemcacheDB都是鍵值數據庫的典型代表。
3.4流式數據庫
基本理念是數據的價值會隨著時間的流逝而不斷減少，因此，需要使式數據庫來實現流式計算。流式計算處理模式是將源源不斷的數據視為數據流，它總是盡可能快速地分析最新的數據，并給出分析結果，也就是盡可能實現實時計算。典型流式數據庫：SparkStreaming、Storm。
4大數據SQL
大數據查詢分析是基于互聯網的相關服務的增加、使用和交互模式中的核心問題。由ApacheLucene的創始人DoungCutting使用GFS、Map-Reduce技術支持創建的ApacheHadoop，是一個能夠對大量數據進行分布式處理的軟件框架。Hadoop技術無處不在，其發展得益于Google發表的關于GFS和MapReduce的論文。在開源世界，ApacheHadoop的分布式文件系統HDFS和HadoopMapReduce完全是谷歌文件系統GFS和MapReduce的開源實現。Hadoop項目已經發展成為一個生態圈，觸及了大數據領域的各個方面。由Google的BigTable和Amazon的Dynamo使用的NoSQL數據庫，提倡使用非關系型的數據存儲，這一全新的思維的注入，打破了關系型數據庫管理系統在商用數據庫領域幾十年的統治性地位。
一般認為SaaS是由提供商為企業搭建信息化所需要的所有網絡基礎設施及軟件、硬件運作平臺，并負責所有前期的實施、后期的維護等一系列服務，企業無需購買軟硬件、建設機房、招聘IT人員，即可通過互聯網使用信息系統。就像打開自來水龍頭就能用水一樣，企業根據實際需要，從SaaS提供商租賃軟件服務。
目前世界上許多跨國信息技術行業的公司都在開發基于SaaS的產品和服務，為未來互聯網的發展提供技術平臺，而電子商務是近年來互聯網應用最受矚目的領域。因此SaaS模式的普及必將對電子商務的發展產生深刻的影響。
正如10Gen工程副總裁Geir Magnusson所指出那樣，在未來我們將很難找到關系數據庫的影子，這是因為關系數據庫不適用于分布式環境。SaaS的普及要求我們必須重新審視我們做事的方式。
時下的許多新型數據庫，包括Google的Bigtable，Amazon的SimpleDB，10Gen的Mongo，AppJet的AppJet數據庫以及甲骨文開源BerkelyDB。這些數據庫沒有一個是關系型的。而這些數據庫具有一些共同特征，就是都特別適用于服務云計算式的應用。它們中的大多數可以在分布式環境中運行，這意味著他們可以分布在多個地點的多臺服務器上。它們本質上都不是事務性的，并且都犧牲了一些高級查詢能力以換取更好的性能。在很多情況下，這些數據庫可以通過對象調用來檢索，而不用SQL。
盡管大型關系數據庫已經被應用在很多數據處理中心，但SaaS需要一種不同的設置來充分發揮其潛力。試想，在跨越地理空間距離之間執行復雜查詢以便減少響應時間、設計和維護支持不同位置的相關數據備份、在一個點癱瘓時能保證該數據同步、維護和運行這樣的體系并非易事。因此，數據庫組成部分在不同位置的分散對SaaS很必要，這也是SaaS產生的原因。更重要的是SaaS體系結構具有不同于目前使用的關系型結構的屬性，在SaaS體系結構里，關系不復存在，人們以群集形式看待數據。
目前用戶所使用的傳統數據庫開發軟件系統本質應該叫數據庫軟件系統，是一個數據庫系統，開發這樣的系統非常簡單，成本也非常低廉，只要根據需求先設計好數據表結構，然后，設計編寫大量SQL語句，雖然也使用JAVA/PHP/.NET等語言，但實際上這些語言只是將SQL送往數據庫執行的運輸工，沒有什么價值和地位。所以，這樣的系統運行在互聯網環境下，主要負載就集中在數據庫的SQL運行上，也就是說：整個軟件系統性能關鍵點就集中在數據庫上了，數據庫是性能的主要承擔者，盡管用戶使用的有可能是Websphere/weblogic等應用服務器，但是由于Java只是運輸工，所以起不到性能上分散負載的作用。
正是由于以上種種原因，有專家認為SaaS的普及對關系型數據庫的應用將產生巨大的影響，而絕大多數電子商務系統所使用的數據庫還是基于關系型的數據庫，未來隨著云計算的大量應用，勢必對電子商務數據庫的構建產生影響，進而影響整個電子商務技術的發展。
關鍵詞：對象關系數據庫；面向對象；AMOS II
中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)34-2016-02
A New Generation of Object-Relational Database: AMOSII
LIU Yan-hong1,2
(1.Nanjing Institute of Industry Technology Information Engineering, Nanjing 210046, China; 2.Nanjing University of Aeronautics and AstronauticsCollege of Information Science and Technology，Nanjing210016，China)
Abstract: Object-relational database can be combined with a single relational database system and a single object-oriented database system. It overcomes their limitations and is a new direction for research and discussion. AMOS II is the latest generation of object-relational database and has powerful object-oriented features. It provides the features and functions that a large number of next-generation database should have. The case of AMOS II fully reflects the advanced nature of the relational database.
Key words: object-relational database; object oriented; AMOS II
1 引言
隨著數據庫技術的發展,原有的數據庫系統很難適應新的應用領域中的復雜對象和這些對象的復雜行為的需求。新的應用需求推動了數據庫技術的研究, 其中最重要的研究方向之一就是使用一種與人們認識客觀事物的過程一致的方法, 這就是面向對象的方法。這種方法大大提高軟件開發的效率。對象關系數據庫是面向對象技術與數據庫技術相結合的產物。
2 對象－關系數據庫
對象關系數據庫兼有關系數據庫和面向對象的數據庫兩方面的特征。即它除了具有原來關系數據庫的種種特點外，還應該提供以下特點：
1) 允許用戶擴充基本數據類型。即允許用戶根據應用需求自己定義數據類型、函數和操作符，而且一經定義，這些新的數據類型、函數和操作符將存放在數據庫管理系統核心中，可供所有用戶公用。
2) 能夠在SQL中支持復雜對象。由多種基本類型或用戶定義的類型構成的對象。能夠支持子類對超類的各種特性的繼承，支持數據繼承和函數繼承，支持多重繼承，支持函數重載。能夠提供功能強大的通用規則系統，而且規則系統與其他的對象－關系能力是集成為一體的。
3 新一代對象關系數據庫的優勢
3.1 傳統的關系數據庫的缺陷
傳統的關系數據庫局限性為：
1) 面向機器的語法數據結構，數據模型單一，數據類型簡單、固定。
2) 不能依據某一類型的數據類型來擴展數據類型。
3) 結構與行為完全分離。
4) 存儲管理的對象有限，事物處理能力較差。
3.2 新一代對象關系數據庫的特征和功能
1) 數據庫應支持復雜的數據類型，并能存儲和處理復雜對象。還要具備支持用戶自定類型和可擴展能力。
2) 數據庫必須對其它系統開放。
3) 系統必須具有可移植性，可連接性，可擴展性和可互操作性。實現程序設計語言和數據庫語言的無縫的集成。
4 AMOS II應用案例分析
AMOS II是最新一代的對象關系數據庫，它充分體現了對象關系數據庫的強大功能。
4.1 學生課程成績查詢案例
有若干學生，學生信息包括學號，姓名，班級。有若干選修課程，課程信息包括課程號，課程名，成績。實現功能：1、通過查詢語句，可以查看所有的學生信息和課程信息。2、輸入學生信息如姓名，可以查看到他所選課程的相關內容。3、輸入課程名稱可以查看到選這門課的學生姓名。4、輸入學生姓名，可以統計出該生選的所有課程名稱和課程數。
4.2 案例設計與分析
1) AMOS II具有面向對象數據庫的特點。
在OODB中, 用類來描述對象的結構特征和行為特征。它有下面的定義形式：
class < 類名> [ (參數表) ]properties
{類的特征}
在本案例中課程和學生類設計如下：
create type kecheng properties(
sid charstring,//課程號//
sname charstring,//課程名//
scoreinteger //期末成績//
);
create type student properties(
tidcharstring,//學生號//
tname charstring,//學生姓名//
banjicharstring //班級//
);
創建kecheng的對象并且賦值用以下命令：
create kecheng(sid, sname,score) instances
:s1("01","Chinese",91),:s2("02","English",90),
…;
創建student的對象并且賦值用以下命令：
create student (tid, tname, banji) instances
:t1("08001","zhangsan","3ban"),
:t2("08002","lisi", "4ban"),
…;
函數設計舉例如下：
create function o_derect(student nonkey)-> as stored;
//輸入參數student類，返回該學生所選課程的元組//
create function sname(kecheng nonkey)->charstring as stored;
create function tname(student nonkey)->charstring as stored;
create function tid(student nonkey)->charstring as stored;
…;
以上定義的源代碼保存在文件lyh.amosql中。AMOSQL類似于SQL語言。例如用下面命令對學生信息進行查詢：
select tin (x), tname(x), from student (x);
在AMOS II中運行并得出結果，如圖1。
這些類、對象、屬性和函數的設計，充分體現了面向對象技術的特點。
2) AMOS II具有強大的可擴充功能。
AMOS II提供的Java函數的接口。在AMOS II中可以調用用戶自定義的Java函數。
本案例用Java語言定義函數tongji()并保存在名為lyh.java的文件中。該函數的功能是接受輸入參數為學生名，輸出該學生所選擇的課程名并統計出課程個數。
為了能在AMOS II調用該函數，需要在javademo.osql文件中添加下面的語句：
create function tongji(charstring)->charstring as foreign "JAVA:lyh/tongji";
運行后如圖2所示。
這充分體現了AMOS II允許用戶根據應用需求自己定義數據類型、函數，具有強大的可擴展功能。
5 總結和展望
綜上，對象―關系數據庫是面向對象技術與數據庫技術相結合的產物。AMOS II是最新的一代對象關系數據庫，具有強大的面向對象的功能。從學生課程成績查詢案例，可以看到AMOS II具有面向對象數據庫的特點，允許用戶根據應用需求自己定義數據類型、函數和操作符，具有強大的可擴展功能，體現了對象關系數據庫的先進性。本文用具體案例介紹了在AMOS II中如何定義類，對象和函數，和如何調用Java自定義函數，實現統計函數的功能。
對象―關系數據庫技術還處于研究發展階段,在很多方面它還面臨很多的挑戰，例如對象―關系數據庫還可以從面向對象數據庫那里吸收養分和研究成果，如路徑索引、對象聚集等。相信對象―關系數據庫有著美好的發展前景。
參考文獻：
[1] 趙志升,許素文,楊小姝.對象――關系數據庫管理系統及其特性與實現[J].電腦開發與應用,2002,15(8):47-48.
[2] 王治.對象―關系數據庫技術及其發展[J].九江師專學報:自然科學版,2003,22(5):86-88.
關鍵詞：XML；DOM；關系數據庫；轉換
中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2011)13-2988-03
The Data Transformation Methods for XML Documents to Relational Databases Based on DOM
ZHU Xing-tong
(School of Computer and Electronics Information, Guangdong University of Petrochemical Technology, Maoming 525000, China)
Abstract: With the popularity of Internet and the rapid development of Web technology, XML is quickly becoming the standards for data representation and exchange, the emergence of a large number of XML data in order to achieve fast query and efficient exchange of data, you need to transform from XML document to a relational database. This article describes the data transformation methods for XML documents to relational databases based on DOM.
Key words: XML; DOM; relational database; transform
1 XML技術
XML[1]是eXtensible Markup Language的縮寫，稱為可擴展標記語言。1998年2月W3C正式推出了XML（XML1.0）。XML的前身是SGML（Standard Generalized Markup Language，標準通用標記語言）。XML是一種簡單的數據存儲語言，使用一系列簡單的標記描述數據，它可以標記任何一種事物。XML的跨平臺型，它提供了一種不同的應用程序之間進行數據庫交換的公共標準，是一種公共的交互平臺。XML文件是由標記以及它所包含的內容構成的文本文件，這些標記可自由定義，其目的是使得XML文件能夠很好地體現數據的結構和含義。W3C推出XML的主要目的是使得Internet網絡上的數據相互交流更方便，讓文件的內容更加顯而易懂。
W3C XML1.0規范給出一種XML通用數據模型。XML文檔定義為具有一個名字和根元素。一個XML文檔有一棵樹組成。一棵XML文檔樹是一個節點的集合，其中每個節點至少有一個父節點，并可以有多個有序的孩子節點。一個XML文檔存在六種類型的節點：
1）聲名節點。包括XML聲明信息和DTD聲明信息。
2）元素節點。每個元素節點有一個名字、一個父節點、一個屬性節點集、一個有序的由元素節點、字符數據節點和注釋節點組成的孩子集。其中根元素節點沒有父元素，而且每個文檔只有一個根元素節點，它引用整個XML文檔資源。
3）字符數據節點。文檔中的字符數據字符串，包括CDAT段。
4）屬性節點。每個屬性節點有一個元素父節點、一個屬性名和一個屬性值。多值屬性例如IDREFS，分成多個節點。
5）注釋節點。由一個該文注釋組成。
6）處理指令節點。由一個目標和數據組成。
下面給出一個XML文檔例子。
XML實用教程
范立鋒
24
人民郵電出版社
智能計算
曾黃麟
28
重慶大學出版社
2 文檔對象模型（DOM）
XML解析器是XML和應用程序之間的一個軟件組織，為應用程序從XML文件中解析出所需要的數據，XML解析模型如圖1所示。
文檔對象模型（Document Object Model，DOM）提供了一種從其他的應用程序中調用或管理XML數據的方法。處理方法是將一個XML文檔看作一個對象，通過固定的方法和屬性對XML文檔的不同標記進行讀寫。DOM規范的核心就是樹模型，對于要解析的XML文檔，解析器會把XML文檔加載到內存中，在內存中為XML文件建立邏輯形式的樹，上面XML文檔例子對于的DOM樹圖2所示。DOM就是XML文檔的一個結構化的視圖，它將一個XML文檔看作是一棵節點樹，而其中的每一個節點代表一個可以與其進行交互的對象。樹的節點是一個個的對象，通過操作這棵樹和這些對象就可以完成對XML文檔的操作，為處理文檔的所有方面提供了一個完美的概念性框架。通過DOM解析器處理XML文件效率高，但是，十分消耗系統的資源，比較適合復雜但相對較小的文件。DOM解析器解析XML文件需要下列幾個步驟：
1）建立一個DOM解析工廠；
2）通過解析工廠創建DOM解析器；
3）解析指定的XML文件；
4）根據標記名稱獲得node標記列表；
5）遍歷每一個node節點；
6）獲得標記內容。
3 XML文檔到關系數據庫的數據轉換
XML文件和關系數據庫有很多相似之處，關系數據庫采用二維表方式存儲數據，XML文件通過標記之間的關系來描述數據。關系數據庫提供了對于大批量數據的有效存儲管理和快速信息檢索、查詢的功能。XML文件是基于標記的文本文件，兼容性好，便于組織、解析和交換數據。某個系統獲得一個XML文件后，可能需要將XML中的某些標記包含的文本內容轉化為數據庫中表的一條記錄，以便發揮關系數據庫在管理數據方面的優勢；另一方面，一個應用系統可能需要將關系數據庫表中的某些記錄轉化為一個XML文件，以便與其他系統交互數據，發揮XML文件在數據交換上的優勢。
要把XML文件中數據寫入關系數據庫中，首先需要利用解析器解析出XML文件中的數據，再利用某種技術獲得數據庫的連接，把數據寫進數據庫。Sun 公司制定了 JAXP(Java API for XML Processing) 規范，用于在 Java 程序中以一種標準的方式對 XML 文檔進行處理。將XML中的某些標記中的內容轉化為數據庫中表的一條記錄，主要步驟如下[5-6]：
1）使用DOM解析器獲取標記中的數據；
2）連接數據庫,將獲取的文本數據作為一條記錄添加到數據庫。
下面給出使用Java語言開發的基于DOM的XML文檔到SQL Server2000數據庫的數據轉換的實例，實現把上面XML文檔例子的數據寫入SQL Server2000數據庫中books表中，主要代碼如下。
public class XMLToDatabase{
public static void main(String args[]){
Connection con=null;
Statement sql=null;
ResultSet rs=null;
try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
}catch(Exception e){
System.out.println(""+e);
}try { con=DriverManager.getConnection("jdbc:odbc:books","","");
sql=con.createStatement();
DocumentBuilderFactory factory=
DocumentBuilderFactory.newInstance();
factory.setIgnoringElementContentWhitespace(true); //忽略縮進空白
DocumentBuilder domPaser=factory.newDocumentBuilder();
Document document=domPaser.parse(new File("books.xml")) ;
Element root=document.getDocumentElement();
NodeList list1=root.getElementsByTagName("title");
NodeList list2=root.getElementsByTagName("author");
NodeList list3=root.getElementsByTagName("price");
NodeList list4=root.getElementsByTagName("publisher");
int size=list1.getLength();
String [] title=new String[30];
String [] author=new String[20];
double [] price=new double[4];
String [] publisher=new String[30];
for(int k=0;k
Node titleNode=list1.item(k);
Node authorNode=list2.item(k);
Node priceNode=list3.item(k);
Node publisherNode=list4.item(k);
title[k]= titleNode.getTextContent().trim();
author[k]=authorNode.getTextContent().trim();
String str=priceNode.getTextContent().trim();
price[k]=Double.parseDouble(str);
publisher[k]=publisherNode.getTextContent().trim();
String insertData="INSERT INTO books VALUES('"
+ title[k]+"','"+ author[k]+"','"+ price[k]+"',"+publisher[k]+")";
sql.executeUpdate(insertData);
}con.close();
}catch(Exception e){ System.out.println(e); }
}}
運行上面的程序將前面的XML文檔例子中的數據轉換到SQL Server2000數據庫中，books表中的數據如圖3所示。
4 結束語
關系數據庫系統相當成熟，把XML文檔數據轉換到關系數據庫中，可以發揮關系數據庫在管理數據方面的優勢.本文介紹的利用Java語言實現基于DOM的XML文檔到SQL Server2000數據庫的數據轉換方法，經實例驗證是正確可行的。利用Java語言與DOM相結合來解析XML文檔，需要把XML文檔全部加載到內存中。如果XML文檔非常龐大，以及解析器耗盡內存，就會造成內存溢出異常。
參考文獻：
[1] W3C.Extensible Markup Language (XML) 1.0 (Fifth Edition)[EB/OL]./TR/2008/REC-xml-20081126/.
[2] 朱珊娜,李書琴,安福定.XML文檔到關系數據庫的轉換研究[J].計算機工程與設計,2008,29(21):5507-5509.
[3] 林耀進.基于實現XML文檔與關系數據庫轉換的方法[J].計算機與現代化,2007(6):43-45.
[4] 蔚曉娟,冉靜,李愛華,等.基于DOM的XML解析與應用[J].計算機技術與發展,2207,17(4):86-88.
[5] 范立鋒.XML實用教程[M].北京:人民郵電出版社,2009.
在計算機網絡設計活動中，關系數據庫技術是一種輔助手段，為計算機網絡設計活動提供數據支持。在計算機網絡設計活動中，關系數據庫的巨大容量和包含數據信息種類的多元性，為計算機網絡設計活動提供了充分的數據資源支持。在關系數據庫的運用活動中，使用者只需要在關系數據庫中進行數據的賦值就可以進行關系數據的存取和調用活動，讓網絡設計活動中遇到的數據和數值問題能夠得到及時、有效的解決。而在傳統的數據庫運行活動中，數據庫的錄入和調用需要借助人工操作來完成，這種數據庫運行模式不僅極大的浪費了人力資源，而且在數據運行的效率和質量上也有很大的缺陷，經常會導致數據的輸入、輸出環節出現錯誤，甚至會極大的拖延網絡設計活動的進程。當采用關系數據庫以后，數據庫以網絡設計活動為服務對象，對內部的數據信息內容進行了關聯化的處理，讓數據庫由過去的數據堆積體衍變成為一種數據的有機管理主體，內部的網絡設計數據與常用的數據關系連接起來，并采用基于可擴展語言設計了數據庫與使用者之間的信息交互界面，讓關系數據庫可以與使用者進行數據關系形式的交流，并根據使用者的數據要求對內部數據信息進行整理、關聯。實現了計算機網絡設計活動數據管理的智能化。
2關系數據庫技術在計算機網絡設計中的基本原理
在計算機網絡技術發展的過程中，數據庫技術存在著眾多的種類，其中根據數據庫模型的運行模式可以分為：網狀模型數據庫技術、層次模型數據庫技術以及關系數據模型數據庫技術。這些數據庫技術在不同的計算機網絡設計活動中有各自的優勢，其中關系數據模型數據庫技術，以其完美的數據連結技術和高度的數據模型適應性，成為計算機網絡設計活動中通用的一種數據庫技術。其在運行過程中展示出的完善的數據連結性，能夠在計算機網絡設計活動中，對任何相關的計算機網絡數據進行關聯，并能夠在一定數據基礎上對多種數據進行綜合性的關系鏈接。這種數據信息服務的全面性和數據鏈接服務形式的多樣性，能夠極大的滿足計算機網絡設計活動中多樣化的數據信息需求，所以在具體的計算機網絡設計活動中成為使用者首選的數據庫類型，被廣泛的應用于計算機網絡設計中。計算機網絡設計活動是一個復雜、系統的工程性活動，在其運行活動中要求下屬的各個模塊都要最大程度上的兼具數據信息服務的全面性和便捷性。在關系數據庫中這一系統要求被很好的體現了出來，關系數據庫擁有自己管理信息交互平臺，能夠基于C語言等網絡編程語言與使用者進行數據庫信息的交流，提高了數據庫使用的便捷性和全面性。在計算機數據庫軟件系統結構中包含著兩個數據庫訪問系統，一個是開放數據庫連接性（ODBC），一個是數據訪問對象（DAO），這兩個數據庫訪問系統相互獨立，能夠單獨向用戶提供數據信息服務。其中ODBC不僅能夠基于SQL語言與使用者進行數據信息交互，而且對C語言和SQL數據庫之間的訪問機制進行了定義，讓使用者可以通過C語言這樣一種計算機網絡設計活動中常見的語言形式與數據庫進行信息交互，保證了關系數據庫對計算機網絡設計活動數據信息交互，讓計算機網絡設計人員能夠通過其最常用的信息交互方式與關系數據庫進行交流，保證了關系數據庫與計算機網絡設計活動積極、有效的互動。DAO為計算機網絡設計提供了數據庫機制，這一機制是從關系數據庫的整體出發對關系數據庫內部組成部分和內容的一種規范。當一個關系數據庫體系結構由多個DAO構成時，DAO自身的數據庫管理機制就會發揮作用，從DAO自身的數據資源特點出發，對關系數據庫整體進行協同管理，保證整個關系數據庫的數據信息服務的高效進行。DAO的這種自我管理機制和其自身的數據訪問對象本質是相互分離的，在具體的管理活動中自我管理機制和數據訪問對象能夠進行各自獨立的管理，讓每一個DAO都可以在保證自身數據訪問對象性質的基礎上，同時實現自身和DAO群體的管理，這種各自獨立的數據訪問對象管理和運行管理，在保證DAO數據服務對象專業性的同時，也方便了自身的升級改造。而且在關系數據庫運行活動中，DAO可以鏈接相應的網絡數據庫，實現數據資源的網絡化共享和管理。
3關系數據庫在計算機網絡設計中的優勢
關系數據庫在計算機網絡設計中具有強大的數據存儲功能，以及簡便的數據轉換功能等強大的優勢，以下將對關系數據庫在計算機網絡設計中的優勢進行詳細的闡述。
3.1強大的數據存儲功能
強大的數據存儲功能，是關系數據庫在計算機網絡設計活動中運用的主要優勢。隨著計算機網絡設計應用范圍的不斷擴大，計算機網絡設計活動的內容含量越來越大，內容的組成形式也變得越來越復雜，面對計算機網絡設計活動這樣一種發展趨勢，相應的關系數據庫的數據儲存能力和數據管理能力變得極為重要。關系數據庫的應用，不僅能夠對計算機網絡設計活動中需求和產生的大量計算機網絡設計數據進行及時的存儲，而且能夠借助內部管理機制的幫助，對這些數據進行有效、準確的規劃和管理。關系數據庫的應用讓計算機網絡設計活動的數據管理環節，成為計算機網絡設計環節的一個效率增長點。在具體的操作活動中計算機網絡設計人員，可以利用數據庫強大的數據存儲功能將設備參數輸入到網絡拓撲結構中，進而借助網絡拓撲結構對關系數據庫進行高效、快捷的操作。如果不能有效的利用關系數據庫的輔助作用，有效管理復雜的數據信息，那么計算機網絡設計勢必會陷入困境中。
3.2簡便的數據轉換功能
關系數據庫在計算機網絡設計活動中的優勢，還體現在不同數據之間的轉換功能。在計算機網絡設計活動中，因為設計活動本身可能會涉及到社會經濟的各個領域，自身的設計形式也會因為網絡設計目標的不同而大相徑庭，在計算機網絡設計活動中，計算機網絡設計的數據從呈現形式和傳遞方式上都是有本質上的不同的，所以在對計算機網絡設計數據進行管理的時候，不同數據之間的轉換是一個關鍵性的問題，只有解決了計算機網絡設計活動中的數據轉換和數據轉換效率的問題，才能促進計算機網絡設計活動高效進行。關系數據庫在計算機網絡設計活動中的應用在一定程度上解決了這一關鍵性問題，因為關系數據庫本身存在的關聯性，就是要從兩組不同數據中尋找共同點，并基于這些共同點建立二者之間的普遍聯系，關系數據庫的這種工作機制，在不同形式的數據之間的轉換活動中也有積極的作用。數據的兩種不同呈現形式本質上也是兩種不同數據之間聯系的一種體現，二者之間本質內容和內在邏輯的聯系是普遍存在的。關系數據庫可以根據這一特點，結合自身的工作機制，對二者進行本質上的聯系，這樣一種在計算機網絡設計活動中復雜無比的問題，在關系數據庫的參與下立刻變得可實現、可操作。關系數據庫的存在只是解決了計算機網絡設計活動數據轉化能力的有無問題，只有強化計算機網絡設計活動中數據轉化能力的效率和便捷性，才能在網絡設計的實際工作中起到更加積極的效果。所以在關系數據庫的建立健全活動中，對其自身的數據轉換能力的強化，是關系數據庫發展完善的未來方向。這一改進必須要將關系數據庫的數據轉化能力與關系數據庫的信息交互系統結合起來，保證使用者對關系數據庫的數據轉換能力有更加直接的參與和應用，同時要結合計算機網絡設計活動發展的實際，對網絡設計活動中可能會涉及到的數據呈現形式進行系統、詳細的統計，并在關系數據庫中對這些數據的呈現形式進行廣泛的應用。具體而言，就是要在關系數據庫中，對計算機網絡設計活動中可能會涉及到的數據呈現形式進行定義，并設置相應的數據轉化機制，在對數據信息進行存儲時，盡量選擇應用范圍最廣的數據呈現形式進行存儲，以最大限度的保證計算機網絡設計活動的數據需求，同時也要定義好各種數據呈現形式的轉化機制，在使用者產生特殊的數據呈現形式需求時，能夠運用相應的數據轉換機制，進行數據呈現形式的轉換，以保證計算機網絡設計活動的高效進行。
4結束
[關鍵詞]關系數據庫SQL查詢對策
中圖分類號:TP3文獻標識碼:A文章編號:1671-7597(2009)1210080-01
在各類大型應用軟件的數據庫中,都存在大量的數據信息和記錄,經常要對它們進行各種數據操作。SQL(Structrued Query Language)作為結構化查詢語言,是大型計算機操作關系數據庫的標準查詢語言,同時也廣泛地應用到小型計算機的數據庫管理系統中。它是一種高度非過程化的語言,即只要用戶按其語法規則寫出符合操作要求的語句,而并不需要告訴系統應如何執行SQL語句,就可得到所要求的結果。隨著數據庫技術的廣泛應用,在數據庫程序的開發過程中,大量的工作是要進行數據查詢和檢索處理。本文從SQL查詢語句執行的過程入手,對其執行效率進行分析,并給出參考性建議和優化策略。
一、SQL語句執行過程解析
在平時書寫SQL查詢語句時,雖然每個人的寫法不盡相同,而且有時個別子句順序并不影響操作結果,但是在各種數據庫管理系統中,標準的SQL的解析順序為:
1.FROM子句,組裝來自不同數據源的數據;
2.WHERE子句,基于指定的條件對記錄進行篩選;
3.GROUP BY子句,將數據劃分為多個分組;
4.使用聚合函數進行計算;
5.使用HAVING子句篩選分組;
6.計算所有的表達式;
7.使用ORDER BY對結果集進行排序。
通過以上SQL語句的解析過程,我們可以對SQL查詢語句進行優化處理。SQL查詢語句的核心結構是SELECT…FROM…WHERE,了解了這個基本結構,我們可以從以下幾個方面對其進行優化處理。
二、效率分析及優化對策
(一)從From子句入手
From子句后面接單表或者多表,通常情況下接受來自不同數據源的多表。如果是單表,一般情況下對表進行快速全表掃描。如果是多表的情況,查詢設計優化器將采取自右向左的順序依次讀取數據表。如以下語句:“From table1,table2,table3”,優化器將優先讀取table3表,然后是table2表,最后是table1表。在進行From子句的多表連接時,就需要結合條件子句WHERE進行分析,需要遵循下面的規則:1. 當WHERE后面接的條件能夠一次性過濾某個表的大量記錄時,應優先處理該表。2. 如果WHERE后面接的條件不能過濾掉大量記錄時應該優先考慮處理記錄數最少或者索引關鍵值最少的表。
(二)從條件子句WHERE入手
WHERE子句后面通常接過濾條件,對表的記錄進行篩選,篩選出符合條件的記錄。如果SELECT查詢語句沒有WHERE子句,則無須對表記錄進行過濾。若后面接單個表,則通常順序掃描全表。若后接多表或者大量記錄表時,則可以考慮用索引來減少查詢的時間。所以在查詢前可對各個表建立比較的索引。對WHERE子句中出現的條件,可以依據以下原則首先來驅動查詢。
(1)建立索引字段的列比沒有建立索引的要快;(2)主索引要比普通索引快;(3)單索引要比符合索引快;(4)有條件約束要比沒有條件約束要快。
此外,WHERE子句通常采用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前,那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。根據以上原則,我們可以判斷出以下四個語句中哪個選項語句效率最高。
Select * Frommobilewhere (mobileno='13775637677') andbegINtime>
{^2009-1-308:20:11} andbegintime
B) SELECT*Frommobilewhere(mobileno='13775637677' )andbegINtime
{^2009-1-30 8:20:11} andbegintime>{^2009-1-30 8:20:11}
C) SELECT*Frommobilewherebegintime
{^2009-1-308:20:11}and(mobileno='13775637677' )
很顯然,綜合以上原則C選項效率最高。
(三)從GROUP BY和HAVING子句入手
在SELECT語句中,GROUP BY語句的作用是對記錄進行分組(劃分成較小的組),使用聚合函數返回每一個組的匯總信息,而HAVING子句限制返回的結果集。在一個SQL語句中可以有WHERE子句和HAVING子句。HAVING與WHERE子句類似,均用于設置限定條件。WHERE子句的作用是在對查詢結果進行分組前,將不符合WHERE條件的記錄過濾掉,而HAVING子句的作用是篩選滿足條件的組,即在分組之后過濾數據,但它不能單獨使用,只能配合GROUP By語句使用,該條件中經常包含聚組函數,使用HAVING條件顯示特定的組,也可以使用多個分組標準進行分組。雖然HAVING子句可以起到過濾的作用,但是要盡量避免使用HAVING子句,HAVING只會在檢索出所有記錄之后才對結果集進行過濾。這個處理需要排序,總計等操作。如果能通過WHERE子句限制記錄的數目,而且能盡早地把不滿足條件的記錄過濾掉,那就能減少這方面的開銷。
(四)從謂詞等方面入手
在SELECT語句中,由于實際需要,查詢語句會經常出現謂詞。常用的謂詞有EXIST,NOT EXSIT,IN,NOT IN等,巧用謂詞也會提高SQL語句的執行效率,可參考以下原則編寫SQL語句。
1.Where子句中盡量不要使用IS NULL或IS NOT NULL的語句,因為它們不會使用索引。
2.WHERE子句盡量不要將通配符(%)放在搜尋詞首出現,通配符(%)在搜尋詞首出現不會使用索引。
3.用EXISTS代替IN。在許多基于基礎表的查詢中,為了滿足一個條件,往往需要對另一個表進行聯接。在這種情況下,使用EXISTS(或NOT EXISTS)通常將提高查詢的效率。
4.用表連接代替EXISTS。通常來說,采用表連接的方式比EXISTS更有效率。
5.用EXISTS代替DISTINCT。當提交一個包含一對多表信息(比如班級表和學生表)的查詢時,避免在SELECT子句中使用DISTINCT。一般可以考慮用EXIST替換。
6.WHERE子句盡量少使用NOT或是,應該成OR來實行,使用OR時應該把結果集小的條件放在前面。
7.UNION改用UNION ALL,UNION要對合并的結果進行排序,UNION ALL不排序。
8.ORDER BY子句中盡量不要使用非索引列。
三、結語
通過對SQL查詢語句執行過程的分析,可以從以上幾個方面對其進行優化改進,從而提高了數據庫查詢和檢索的效率。當然,具體的查詢語句還要根據具體需要,并結合具體的數據庫系統而定。只有多總結多積累才能寫出高質量高效率的查詢語句,當然這只是提高數據檢索的一個方面,在其他方面的設計也要進行優化,如對表建立必要的索引,減少表之間的連接,或盡量在索引屬性列上建立連接等。總之,通過以上幾個方面的綜合優化,一定會使數據庫查詢與檢索效率有很大的提高。
參考文獻:
[1]王振輝、吳廣茂,SQL查詢語句優化研究[J].計算機應用,2005,25(12).
[2]徐鳳梅,關系數據庫中SQL查詢語言的優化策略[J].廣西輕工業,2009,126(5).
[3]鄧文艷,基于關系數據庫的查詢優化技術[J].太原科技,2007(12).
[4]楊克昌,Visual FoxPro程序設計教程[M].長沙:湖南科學技術出版社,2004.
[5]李瑩、代勤,關系代數運算與SQL查詢的對應關系[J].內蒙古農業大學學報(自然科學版),2003,24(3).
【摘 要 題】信息資源建設
.
【關 鍵 詞】非結構化WEB數據庫/多媒體/信息資源/組織利用/關系數據庫
【 正 文】
1 非結構化WEB數據庫簡介
非結構化WEB數據庫，是指其字段長度可變，并且每個字段的記錄又可以由可重復或不可重復的子字段構成的基于INTERNET、INTRANET的數據庫，用它不僅可以處理結構化數據（如數字、符號等信息）而且更適合處理非結構化數據（全文文本、圖象、聲音、影視、超媒體等信息）并在互聯網上。非結構化WEB數據庫主要是針對非結構化數據而產生的，與以往流行的關系數據庫相比，其最大區別在于它突破了關系數據庫結構定義不易改變和數據定長的限制，支持重復字段、子字段以及變長字段并實現了對變長數據和重復字段進行處理和數據項的變長存儲管理，在處理連續信息（包括全文信息）和非結構化信息（包括各種多媒體信息）中有著傳統關系型數據庫所無法比擬的優勢。
2 圖書館多媒體信息資源的特點及組織利用中的技術要求
2.1 圖書館多媒體信息的數據量非常大，象館藏影視資料和各種多媒體教育資料，其動態圖象信號，每秒可達數兆字節，一段幾分鐘的MP3音樂也有幾兆字節，即使經過壓縮、也十分巨大。如何對多媒體海量數據進行有效地組織、存儲并構成WEB數據庫提供給用戶網上使用，技術要求很高。
2.2 館藏多媒體信息的數據類型很多，包括各種圖文數據、聲音數據、影視數據、超媒體數據、多種格式的隨書光盤等等，其數據長度不固定，結構上的差異大，使得處理這些數據十分困難，要求數據庫既能夠處理可變長度字段又能夠處理可重復的子字段。
2.3 多媒體信息處理在時間上要求很高，多媒體信息中的聲音和動態圖像對時間特別敏感，在使用這些信息時，必須保證其時間上的要求，否則將會使這些信息失真甚至變得毫無意義。
2.4 開發利用館藏多媒體信息資源經常要多種信息集成描述，比如某種多媒體，既有圖像，又有聲音，還有文字說明，這樣就會改變傳統的數據庫操作形式和數據庫接口，尤其對圖文并茂的數據庫的建立和查詢，需要統一語義描述。
基于多媒體信息資源的上述特點，要想使館藏豐富的多媒體信息資源得到充分利用，滿足信息用戶不斷增長的信息需求，對多媒體信息處理提出了不同于普通信息處理技術的新要求：
（1） 多媒體數據庫元數據存儲技術要求
我們知道音頻、圖象、視頻等多媒體信息數據是非結構化的，它們不能用簡單的數字解析式表示，多媒體數據庫必須取得基于這些媒體對象內容及信息特征的解釋，才能完成存儲及應用，這些解釋就稱為元數據，通過對元數據的歸類、整理、實現標準化的存儲是多媒體信息資源組織利用的關鍵。多媒體數據庫元數據存儲技術要求包括：文本元數據的存取，語音元數據的存取，圖象元數據的存取，視頻元數據的存取等方面的技術要求。
（2） 多媒體數據庫結構字段設計與數據記錄處理方面的要求
a.允許可變長字段、可重復字段、子字段和MARC字段。
b.數據庫記錄的數目與記錄長度，字段數目與字段長度，字段可重復次數不應受到限制。
c.允許建立可以快速存取的倒排文件和多媒體、多語言記錄表。
d.數據庫可自動接受和產生MARC和ISO2709記錄格式的文件，并且滿足對MEDADATA數據模式的支持功能。
（3） 基于WEB的多媒體信息檢索與信息的技術要求
隨著用戶對于信息需求的大量增加，以及對于多媒體信息的實效性要求，基于WEB的數據庫信息存儲的檢索越來越傾向于多媒體全文信息檢索的查詢語言，并且對于檢索結果的需求也側重于多媒體全文信息的獲取。與此同時，WEB數據庫的信息形式開始更多地過渡到通過網絡瀏覽器以多媒體電子文檔的方式（B/S）傳輸給網上用戶。也要求利用多媒體WEB傳輸技術，向用戶提供主動的特定多媒體信息的推送服務。
3 非結構化WEB數據庫的特點及其在組織與利用多媒體信息資源中的作用
3.1 豐富的數據類型與靈活的數據結構，滿足多種類型館藏多媒體數據結構組織
根據非結構化多媒體數據信息的特殊性，非結構化WEB數據庫在進行存儲和管理多媒體信息時，整個數據庫的管理機制擯棄了傳統結構化關系數據庫對于信息采取定長和結構化定義和管理的局限，它從多媒體數據模型入手，采用子字段、多值字段以及變長字段的機制，允許創建許多不同類型的非結構化或任意格式的字段，從而突破了關系數據庫非常嚴格的表結構，解決了關系數據庫模型過于簡單，不便于表達復雜嵌套的問題。非結構化WEB數據庫在數據類型上不僅支持字符型、數值型數據，而且由于具有很強的外部文件支持功能，使其可以支持如超長文本、圖像、聲音、動畫等多種多媒體擴展數據類型。與傳統關系數據庫相同之處是非結構化WEB數據庫的數據結構也是建立在二維表的基礎之上的，但它與關系數據庫不同的是：（1）非結構化WEB數據庫二維表的屬性長度是不可變的，在列的維度上可以隨意擴展，這就能較好地滿足多媒體數據處理時，需要靈活的可變長字段的要求。（2）非結構化WEB數據庫由于支持重復字段、子字段，使其可以在數據庫記錄中實現二維嵌套，解決了非結構化多媒體數據結構復雜、可能存在重復字段和多個嵌套子字段的問題。（3）非結構化WEB數據庫一個字段可以存放關系數據庫的一張表，它可以在一張表中壓縮關系數據庫中一對多的關系，因此利用非結構化WEB數據庫能很好地實現多種多媒體數據庫的集中組織與管理。轉貼于
3.2 基于廣域網的圖書館海量多媒體數據庫存儲管理機制的實現
圖書館多媒體信息資源數據庫是海量數據庫，支持基于廣域網的海量多媒體信息存儲和管理是非結構化WEB數據庫管理系統的主要功能之一，不僅存儲數據量大，而且存取速度快，同時檢索功能強、檢索速度快，在檢索速度方面一般不受信息量大的影響。以IBASE非結構化數據庫為例，每個數據庫最大的記錄數可達到1000萬條，每條記錄的最大長度可達64000字節。每個數據庫最多可有800個字段。
關鍵詞：結構化數據源；關系數據庫；本體建模；組織業務；優化
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2014）25-5822-03
Ontology Modeling and Organization of Business Optimization Based on Structured Data Source
ZHU Qiang-sheng1， ZHU Xiao-juan2 ， LUO Yu-xin1
（1.College of Information Engineering， Nanjing University of Finance and Economics， Nanjing 210046， China；2.College of Electronic & Photoelectric Technology，Nanjing University of Science and Technology，Nanjing 210094， China）
Abstract：This paper studies the ontology modeling method based on structured data source， puts forward ontology modeling and optimization method from the relation database， to achieve the business purpose of simplified optimization and ontology modeling .
Key words：structured data source； relational database； ontology modeling； organization of business； optimization
1 概述
隨著經濟的飛速發展和企業不斷壯大，現代企業的中心已經從組織轉變到流程，對流程的分析優化已經成為主要問題。傳統的業務優化大都采用人工優化，需要對企業現有的業務流程、組織結構等信息進行分析，且需要時刻了解當前的業務流程，適時提出調整。國外的研究學者們提出企業業務流程重組（Business Process Reengineering，BPR）[1]，主要分為兩類，一類是在現有的業務基礎上進行改造；另一類是重新考慮業務，零起點設計業務。
本體，作為一種“共享概念模型的形式化規范說明”，能夠很好的描述業務特征與業務之間的關系，及業務特征與業務特征之間的關系，已經廣泛用于現代信息系統。目前，在許多領域中，本體的構建大多為手工構建。這種方式費時費力，同時還需要領域專家及時參與。該文從企業數據庫出發，通過數據庫逆向工程，構建企業組織業務的本體模型，通過分析模型其中的活動、目標、角色、信息資源等流程的基本要素，在確保活動都能實現的前提下，精簡流程，提高效率。
2 結構化數據源的本體建模方法
本體的質量決定了基于本體構建的應用的質量，所以選擇合適的數據源并從其出發構建高質量的本體模型是很重要的[2]，當前萬維網上大量的數據資源主要就是以關系數據庫的方式存儲[3]。在企業中，企業的人員、機構等信息基本是存入數據庫。數據源（數據庫、XML文檔、Web表格等）的結構化程度有所不同，但是均能夠構建高質量的本體模型。
通過已有的數據庫，我們可以獲取數據庫模式信息，根據設計好的映射規則，完成RDM到OWL本體的轉換[4]，示意圖如圖1。
圖1 RDM到OWL示意圖
2.1 關系數據庫數據模型的抽取
目前，網絡上大量的數據仍然主要以關系數據庫的方式存儲，其中，我們通過構建關系數據庫模式和本體間映射來解決數據庫與本體之間的數據互操作性。該文使用Power Designer[5]這個工具，并通過使用其具有的數據庫逆向功能，來抽取數據庫中的邏輯數據模型以及概念數據模型。
在軟件工程界，作為一個比較新興的領域，逆向工程已經得到廣泛的應用。在本文中，我們使用的Power Designer是Sybase公司的CASE工具集，使用它可以方便的對管理信息系統進行分析，它幾乎包括了數據模型設計的全過程。可以將目前所有流行的后端數據庫（包括Sybase、DB2、Oracle等）的結構信息通過逆向工程加入到Power Designer的物理數據模型和概念數據模型中，包括表、索引、觸發器、視圖等。
2.2 關系數據庫的本體構建規則
利用Power Designer的逆向工程特性，可以直接得到關系數據庫的邏輯數據模型和概念數據模型，從而可以得到基本的E-R圖。根據我們定義的規則[6]，將我們通過逆向工程得到的概念數據模型中的各種關系模式可以映射到本體，得到OWL本體概念或關系。
關系數據模型中的規范關系，我們定義的主要映射規則如下。
R1：如果數據庫中有表T1，那么，我們將T1映射到OWL本體模型中，且本體模型中得到的映射類具有相同的名字。T1中的描述轉換為同名類的中說明。
R2：如果數據庫中有兩個表T1，T2，且兩表之間具有“父子”關系（T2為T1孩子），那么，我們則將表T1、T2分別映射到OWL本體模型中，分別為作為父類和子類。
R3：如果數據庫中表T1存在字段A，且該字段不是外鍵，那么我們將該字段映射到OWL本體模型中，作為同名數據類型的屬性。其中，屬性的定義域和值域分別為數據庫中表T1對應的類、字段A的數據類型，同時，字段A的描述對應的映射為屬性的說明。
R4：如果數據庫表T1存在字段A，且字段A為非空、非外鍵，那么對應于該字段所的數據類型的屬性，其基數（cardinality）限制的值是“1”。
如果A的值可以為空，那么對應于該字段所的數據類型的屬性，其基數限制（MaxCardinality）的值是“1”。
R5：如果數據庫表T1存在字段A不可以為空，且A為外鍵，那么對于該字段所對應對象，其屬性的基數限制（MinCardinality）的值是“1”。
如果字段A的取值可以為空，那么對于該字段所對應的對象，其屬性的基數限制（MinCardinality）的值是“0”。
R6：如果關系數據庫中有表T1，該表的主鍵為Aa 與Ab，且字段Aa與Ab 均為外鍵，Aa 與Ab分別是表Ta與Tb的主鍵，且該表僅包含主鍵字段，那么把字段Aa與Bb映射為同名對象的屬性，同時存在逆向的（inverse-of）關系。
2.3 關系數據庫的本體構建方法
1） 搜集現有的企業關系數據庫，或根據企業的需求關系創建自己的關系數據庫。由于該數據庫已經包含了企業中的各種關系和行業的信息，對于缺乏領域專家或者專家參與不足這樣的問題，可以在一定程度上得到解決。
2） 使用Power Designer的逆向功能。從數據庫出發，我們將數據庫中的索引、表、視圖等各種關于數據庫結構的信息，通過使用Power Designer的逆向功能，生成物理數據模型（PDM）。通過分析物理數據模型，我們可以得出各個表的主鍵、外鍵關系，同時，刪除無用的狀態屬性、冗余表以及擴展屬性等，然后對實體表進行合并，獲得概念模型，最終獲得E-R模型。
3） 定義概念模型到OWL模型的轉換規則。根據已定義的轉換規則，我們可以將概念模型中的各個表及其數據類型、表-表的關系、屬性等模式轉換為OWL本體中相對應的模式。
4） 有效性的檢驗。當用OWL語言描述領域本體模型以后，我們需要評估和檢驗來判斷創建的本體模型的有效性。
方法的流程圖如圖2所示。
3 基于本體的組織業務優化方法
從企業的關系數據庫出發，由概念模型到本體模型轉化，建立領域本體，實現領域內知識概念或術語的一致性描述，得到的領域本體模型，該本體模型其反映了企業的組織關系及業務流程可視化的本體模型，可以直觀的反映組織業務流程，有利于刪除、簡化、重排、合并組織業務，但對于結構龐大、處理過程復雜的系統，很難全部人工來實現流程的優化。我們從本體出發，采用U/C矩陣研究組織業務的優化[7]。
3.1U/C矩陣
對于過程和數據之間的關系，我們可以用U/C矩陣來表達，其中，矩陣的行表示數據類，矩陣的列表示功能。在矩陣中，我們用大寫字母U（User）來表示數據的使用，字母C（Cerate）來表示數據的產生。U/C矩陣作為一種重要的工具，在管理信息系統（MIS）開發的系統分析階段得到了重要的應用。U/C矩陣的形式是一張表格，我們可以存在數據庫中，這樣我們可以通過對數據庫的操作，來對其進行操作，分析其正確性。同時，可以利用分析的結果，對U/C矩陣進行子系統的劃分。
3.2 利用U/C矩陣研究組織業務優化
1） 根據企業信息系統的業務流程，繪制業務流程圖，明確業務數據流向。同時，根據數據流向，確定關系數據庫E-R模型中各個實體之間的數據流向，明確時序。
2） 由E-R模型到本體模型的轉換。
3） 結合數據流程圖和數據流圖，建立U/C表，檢驗U/C矩陣的正確性。我們可以從三個方面來檢驗U/C矩陣的正確性：完備性、一致性、無冗余性。通過這三個方面的檢驗，我們可以整理U/C矩陣，對矩陣中行或列的進行移動，使字母“C”盡可能的靠近矩陣對角線，這樣我們得到一個新的矩陣排列。
4） 根據得到的新U/C矩陣，劃分子系統。
5） 生成通過U/C矩陣優化后的模型，生成新的本體。
3.3結論
1） 對根據企業流程所建立的U/C矩陣，可以對矩陣進行正確性檢驗和分析。通過檢驗和分析，其前段調查工作和分析工作中各種疏漏和冗余，可以及時的被我們發現，進而分析出新的改革方案。
2） 通過對U/C矩陣的求解過程，獲得子系統的劃分。這樣，可以降低業務流程的耦合性。
3） 子系統劃分完成后，由于各個子系統之間的數據產生和使用相對獨立，我們可以根據這個劃分結果，對目前組織機構的設置、業務流程的規劃進行評價。這樣，我們可以改進組織機構設置、完善精簡業務流程，進而提高企業的管理質量，降低企業成本。
4 結束語
本文分析了結構化數據源到本體模型的對應關系，這種形式化對應關系包括數據庫的結構模型與本體概念框架模型之間的轉換關系。給出了一個從概念數據模型到OWL本體模型的轉換規則，給出了一種基于結構化數據源的本體建模方法。最后，利用U/C矩陣的相關特性，研究了組織業務優化的方法。
本文僅對基于結構化數據源的本體建模問題進行了研究，同時對利用U/C矩陣來進行組織業務優化的問題進行了探索，設計完善的轉換規則和更好組織業務優化方法等工作需要進一步研究。
參考文獻：
[1] Hamer M， Champy J.Reengineering the Corporation： A Manifesto for Business Revolution[M].New York：Nicholas Brealey，1993：113-115.
[2] CHANG K C，HE Bin LI Cheng-kai，et al.Structured databases on the Web：observations and implications [J].ACM SIGMOD Record，2004，33（3）：61-70.
[3] 車成逸，馬宗民，焦曉龍.基于結構化信息源的本體構建方法綜述[J].計算機應用研究，2012（7）.
[4] 余霞，劉強，葉丹.基于規則的關系數據庫到本體的轉換方法[J].計算機應用研究，2008，25（3）：767-770，785.
[5] 顧平.數據庫設計工具Power Designer的研究與實踐[J].計算機應用與軟件，2004，11（12）.
關鍵詞：ORM；持久化；實體；事務；映射
前言
Hibernate框架最初是由一個名字為Gavin King的程序員，在2001年根據自己對ORM思想的理解，構建出來的一個Java持久化應用。在推出第一版后，很快得到了編程界的廣泛關注，并隨后被JBoss公司收購，從此Hibernate框架不斷推陳出新，在Java EE持久化領域獨占熬頭。
1 Hibernate框架應用
Hibernate作為一個持久化框架，其底層對JDBC的API進行了封裝，并在上層把自身的API暴露給應用程序業務層的一種全自動類型的持久化框架。其之所以能風靡編程界，與其自身的特性密切相關。
（1）Hibernate框架提供多個級別的緩存來加快數據的讀寫速度，如：一級的Session緩存、二級的插拔緩存。
（2）Hibernate框架的API及HQL語句具有開發性，能夠在不同的關系型數據庫中通用，可以實現一次編寫，隨處運行的思想。
（3）Hibernate框架的實體類中，只要求有對應的set、get方法，而無須引入其它類，因而它是一種非入侵的開發方式。
2 ORM原理與實現
ORM也叫對象關系映射（Object Relation Mapping），是面向對象語言操作持久層的一種有力工具。因面向對象語言與關系數據數據庫的交互存在一定的障礙，作為ORM的職責就是在它們中間建立一個交互的渠道，以方便程序與數據層的通信。
ORM的實現方式有很多種，Hibernate是其中的一種開源實現方式，具體實現過程如圖1所示。通過ORM插件的映射API及XML映射規則，面向對象語言域模型中的業務實體最終變成關系數據庫中的數據表，對象將成為表中記錄，屬性將映射成表中的字段。應用程序將通過Hibernate框架的HQL語句及實體對象與ORM插件模塊進行通信，而關系數據庫則通過SQL語句及數據關系與ORM插件模塊交互。
3 Hibernate框架組件
Hibernate框架的ORM運作機制以及跨數據庫平臺執行能力是通過五大核心組件支撐起來，如圖2所示。
Configuration接口：從配置文件hibernate.cfg.xml與實體映射文件*.hbm.xml文件中讀取相應的配置信息，負責程序運行環境初始化，并構建BeanFatory實例。
SessionFatory接口：代表關系數據庫中的邏輯數據源，為重量級組件，一個實例代表一個邏輯庫，不能隨意創建及銷毀。
Session接口：代表關系數據庫的連接，輕量級組件，從SessionFatory接口中可取得此實例，該實例中有對關系數據庫增、刪、改、查的操作API。
Query接口：框架中所有通過HQL語句去操作關系數據庫時，都必須通過此組件來實現，從Session接口中取得該實例。
Transaction接口：框架的事務管理接口，所有對關系數據庫的寫操作都必須在框架中開啟事務，否則不會提交到數據庫存儲層。
4 Hibernate對象管理
當應用程序通過Hibernate API與關系數據庫交互時，持久化框架內的實體對象存在著如圖3所示生命周期管理過程。
當業務實體對象被通過new的方式剛剛創建時，這時實體對象還未與任何持久化機制發生關聯，與普通的JavaBean對象完成一模一樣，此時實體對象的狀態稱之為臨時狀態，也叫瞬時狀態。
當實體對象進入Hibernate的Session緩存時，此時的對象已經跟持久化機制發生關聯，實體對象則處于持久化狀態。
當實體對象已經變成關系數據庫數據表中的某條記錄時，且已不存在Session中，此時則稱實體對象處于游離狀態或脫管狀態。
實體對象的狀態可以通過框架API的中方法，在三種狀態中進行相互的轉換。在臨時狀態下，通過save方法可以使對象變成持久化狀態，在持久化狀態下則可以通過delete方法，使對象重新返回到臨時狀態中。在持久化狀態下，則可以通過close、clear等方法使對象變成游離狀態，反過來，通過lock、update等方法則可以使對象的狀態從游離形式返回到持久化形式。在游離狀態下，還可以通過delete方法，直接使對象返回到臨時狀態。
5 結束語
Hibernate框架是一個持久層的優秀框架，同時也是一個主流的ORM工具，其可以讓開發人員以對象思維操作關系型數據庫，讓編碼過程變得更加簡潔、高效。但其也存在一定不足，如，稻菘馓匭怨δ鼙荒ㄉ保不支持批量操作等，以上是可以進一步完善的方面。
參考文獻
[1]張少應，程傳旭.基于Hibernate的對象關系映射研究[J].電子設計工程，2016，24（6）：128-130.
[2]宮生文，王寧.Hibernate作為J2EE數據持久層的分析和研究[J].計算機與信息技術，2006（4）：36-38.
[3]卞林，鄭中華，唐曉新.一種基于Hibernate的并行查詢方法[J].電子技術與軟件工程，2016（7）：181-183.
關鍵詞:XML; .Net; 領域對象; 設計模式; 數據傳輸對象
中圖分類號:TP311.132.4; TP311.132.3
文獻標志碼: A
Implementation of adaptive mechanism of domain object and XML data extension using .Net
WANG Xiang
(Graduate School,Chinese Academy of Sci.,Beijing 100049,China)
Abstract:To facilitate the complexity of the business logic and business data characteristics,the appropriate implementation pattern can be chosen for business logic according to the requirements by introducing adaptive mechanism. With the hierarchy characteristics of XML,business objects can invoke relational database as well as XML data using the expansion provided by XPath and XSLT. The tests demonstrate that with the adaptive mechanism client program can remain stable even when data model is changed. With special XML technologies,the adaptive mechanism can also apply to XML data.
Key words:XML; .Net; domain object; design pattern; data transfer object
0 引 言
在領域驅動設計中,實現業務邏輯層主要有3種模式[1]:Transaction Script,Domain Module和Table Module(見圖1).
圖 1 實現所需工作量與業務邏輯復雜度的關系
隨著業務邏輯復雜程度的增加,采用各模式實現的工作量變化趨勢有所不同;根據應用特點,3種模式各有優勢.
(1)Transaction Script:業務邏輯直接用SQL腳本與數據庫交互,實現簡單,但是限于SQL面向過程化的特點,完成復雜業務邏輯時工作量較大.
(2)Domain Module:將業務數據封裝為業務對象,適于業務邏輯復雜的應用,但需要O/R映射的支持.
(3)Table Module:將業務數據組織成數據表方式,雖然對象化特征不如Domain Module明顯,但適于展現層使用.
應用建設初期選擇的實現模式隨著業務需求和歷史數據量的變化需要進行調整,此時要增加1個適應性機制,保證在盡量不影響客戶程序的前提下,選擇合適的實現模式.隨著XML數據使用日趨廣泛,須借助XPath,XQuery和XSL為層次型數據增加專門的擴展機制,使得基于XML數據源的業務邏輯也可以采用上述3種模式實現.
1 概要設計
1.1 整體邏輯結構
總體適配機制見圖2.
圖 2 總體實現結構
為業務服務增加抽象接口IDomainService,客戶程序通過DomainServiceFactory獲得該抽象接口,這樣客戶程序不依賴于具體的業務服務實體類,僅依賴于抽象的服務接口,當下層實現模式調整時,不影響客戶程序;為了讓框架可以同時適應關系數據庫和XML數據,增加抽象接口IDataSource,代表不同的數據源對象;IDataMapper負責根據不同的數據源完成關系數據或XML數據與業務對象的映射;為了減少DomainServiceFactory對具體業務服務對象產生的依賴性,增加配置管理對象ConfigManager,由它獲取指定的業務服務實體類名稱,并通過反射機制動態生成目標實例.1.2 性能改進
由于業務實體經常會對應到具有Master-Detail關系的多個表,而且有些復雜業務實體本身包含1組或幾組其他業務實體,出于性能考慮,為了避免IDataMapper在映射過程中頻繁調用數據源逐個生成子業務實體,需要在IDataMapper與數據源之間增加1個DTO(Data Transfer Object)對象IDataTransferObject,通過將調用打包的辦法,減少頻繁的遠程調用(見圖3).圖 3 借助DTO和Domain Module對象間接訪問數據源
2 詳細設計
2.1 面向關系數據庫的業務服務設計
為了將業務實體納入適配機制管理,依據依賴倒置原則,對各模式實現的業務實體進行抽象(見圖4).
圖 4 關系數據庫方式下的適配機制
為每種模式實現的業務對象抽象獨立接口,并編寫對應的關系數據庫實現類;Domain Module需要調度數據映射和DTO進行關系數據與業務實體的映射;增加抽象基類DomainModuleBase,通過調用IDataMapper和IDataTransferObject完成數據提取和映射工作.關系數據庫下3種模式的執行特征見 表1.
2.2 面向XML數據的擴展設計
由于XML的層次特征[2],3種模式的實現技術與關系數據庫不同(見表2),XML數據方式下的適配機制見圖5.
圖 5 XML數據方式下的適配機制
2.3 配置機制設計
通過增加服務接口工廠類的方式隔離客戶程序與具體業務服務實體類間的依賴,工廠類通過配置管理ConfigManager獲得每個目標服務接口對應的實體類名稱,借助反射動態包裝目標服務接口.靜態結構和執行過程見圖6和7.
圖 6 配置管理機制
圖 7 客戶程序獲得業務服務接口的時序關系
3 實驗環境準備及實驗結果分析
3.1 測試業務對象
為了比較3種模式實現特點的不同,測試中設計2個具有Master-Detail特征的業務實體:Customer和Order,兩者之間也存在1:N的關系,對應的關系數據庫和XML數據實現見圖8~10.
圖 8 業務實體
圖 9 關系數據庫方式下業務實體實現
圖 10 XML數據方式下業務實體實現
目標服務是1個根據客戶名稱,返回其所有訂單明細項小計之和的接口.
3.2 測試內容準備
針對關系數據庫和XML數據方式的不同,業務邏輯如表3.表中,為了計算簡單,XML數據的Transaction Script模式增加1個采用XSTL生成 “客戶名稱―訂單項明細小計”的中間過程,見圖11.
圖 11 XML Transaction Script方式下生成中間結果的XSLT
3.3 測試數據和測試代碼
測試數據見表4.
測試代碼如下:
IDomainService service =
new DomainServiceFactory().Create();
Summary summary = service.GetSummary("joe");
Trace.WriteLine(summary.Name);
Trace.WriteLine(summary.Total);3.4 測試結果及分析
通過修改ConfigManager中實現業務服務的實體類名稱,結合數據庫調用監控獲得數據見表5.
測試結果分析如下:
(1)借助適配機制,在目標實現模式甚至數據模型修改時,客戶程序保持穩定,修改內容控制在配置文件部分,不影響客戶程序的業務邏輯;
(2)使用不同模式設計完成的業務對象,借助適配機制和XML數據擴展機制,在關系數據庫和XML數據方式下,可完成同樣的服務功能;
(3)通過DTO組件的調用打包作用,可以將包括2份訂單､4項訂單明細的信息一次性提取,將多次調用打包為1次調用,減少網絡往復.
4 結束語
依據引入適配機制可以從一定程度上減少客戶程序與業務邏輯的耦合程度,在部署､運行環境變化時,可通過調整配置選擇合適的業務邏輯實現模式,并且不需要客戶程序聯動修改;DTO對象的加入可以減少分布式調用中的往復次數,有利于提升應用性能.
實際工程中,由于業務邏輯實體往往需要被多個客戶程序調用,需要有效的并發機制配合[3],后續研究中將著重對并發能力進行調整.
參考文獻:
[1] FOWLER M,RICE D,FOEMMEL M,et al. Patterns of enterprise application architecture[M]. USA:Addison Wesley,2002.
[關鍵詞]多媒體數據庫；數據模型；面向對象；分布式數據庫
1多媒體數據模型
多媒體數據模型主要采用文件系統管理方式、擴充關系數據庫的方式和面向對象數據庫的方式。
1.1文件系統管理方式
多媒體資料是以文件的形式在計算機上存儲的，所以用各種操作系統的文件管理功能就可以實現存儲管理。Windows的文件管理器或資源管理器不僅能實現文件的存儲管理，而且還能實現有些圖文資料的修改，演播一些影像資料。為了方便用戶瀏覽多媒體資料，出現很多的圖形、圖象瀏覽工具軟件。有些在Windows95下的瀏覽軟件還和資源管理器結合起來，如ACDSee工具軟件不僅可瀏覽BMP、GIF、JPEG、PCX、Photo－CD、PNG、TGA、TIFF and WMF 格式的圖像，而且還具備資源管理器的查詢、刪除、復制等功能。如多功能影像處理及管理軟件ImagePals，是在Windows 上影像工具軟件，ImagePals提供了電子相簿（Album）、影像編輯（Image Editor）和屏幕捕捉（Screen Capture）等功能，此外還具有視窗及CD瀏覽器等。電子相薄（Album）是一個很具特色的應用程序，能對文件進行迅速、可視性的管理。文件系統方式存儲簡單，當多媒體資料較少時，瀏覽查詢還能接受，但演播的資料格式受到限制，最主要的是當多媒體資料的數量和種類相當多時，查詢和演播就不方便了。
1.2擴充關系數據庫的方式
數據庫的出現是為了解決文件管理數據的不足，同樣，為了解決管理多媒體數據，人們很容易地會想到使用數據庫。傳統的關系數據模型建立在嚴格的關系代數的基礎上的，解決了數據管理的許多問題，目前基于關系模型的數據庫管理系統仍然是主流技術。但是平坦化的數據類型不適于表達復雜的多媒體信息，文本、聲音、圖像這些非格式化的數據是關系模型無法處理的；簡單化的關系也會破壞媒體實體的復雜聯系，豐富的語義性超過了關系模型的表示能力。出于保護原有投資和市場的考慮，全球幾家大的數據庫公司都已將原有的關系數據庫產品加以擴充，使之在一定程度上能支持多媒體的應用。用關系數據庫存儲多媒體資料的方法一般是：
1.2.1用專用字段存放全部多媒體文件；
1.2.2多媒體資料分段存放在不同字段中，播放時再重新構建；
1.2.3文件系統與數據庫相結合，多媒體資料以文件系統存放，用關系數據庫存放媒體類型、應用程序名、媒體屬性、關鍵詞等。
1.3面向對象數據庫的方式
關系數據庫在事物管理方面獲得了巨大的成功，它主要是處理格式化的數據及文本信息。由于多媒體信息是非格式化的數據，多媒體數據具有對象復雜、存儲分散和時空同步等特點，所以盡管關系數據庫非常簡單有效，但用其管理多媒體資料仍不太盡如人意。而面向對象數據庫是指對象的集合、對象的行為、狀態和聯系是以面向數據模型來定義的。面向對象的概念是新一代數據庫應用所需的強有力的數據模型的良好基礎。面向對象的方法最適合于描述復雜對象，通過引入封裝、繼承、對象、類等概念，可以有效地描述各種對象及其內部結構和聯系。多媒體資料可以自然地用面向對象方法所描述，面向對象數據庫的復雜對象管理能力正好對處理非格式多媒體數據有益；根據對象的標識符的導航存取能力有利于對相關信息的快速存取；封裝和面向對象編程概念又為高效軟件的開發提供了支持。面向對象數據庫方法是將面向對象程序設計語言與數據庫技術有機地結合起來，是開發的多媒體數據庫系統的主要方向。
為高效管理多媒體數據，基于關系數據庫的應用系統逐漸演變到多媒體數據庫管理系統用面向對象的概念擴充關系數據庫。用面向對象的高級語言擴展基本關系類型，使其支持復雜對象，并對關系模型提供的操作加以擴充，利用關系數據庫的優勢管理多媒體資料。
2 數據的壓縮和解壓縮
由于多媒體信息，如聲音、圖像目前國際上的壓縮標準有：
JPEG(Joint Photographic Experts Group)，是由國際標準化組織(ISO)和國際電報電話咨詢委員會(CCITT)聯合制定的。適合于連續色調、多級灰度、彩色或單色靜止圖像的國際標準。轉貼于
MPEG(Moving Picture Experts Group)，是ISO／IEC委員會的第11172號標準草案，包括MPEG視頻、MPEG音頻和MPEG系統三部分。MPEG要考慮到音頻和視頻的同步，聯合壓縮后產生一個電視質量的視頻和音頻、壓縮形式的位速為1.5Mbps的單一流。
P×64，是CCITT的H．261號建議，P為可變參數，取值范圍是1～30。該標準的目標是可視電話和電視會議，它可以覆蓋整個ISDN(綜合業務數字網)信道。當P=1或2時，只支持每秒幀數較少的視頻電話，P＞6時可支持電視會議。
P×64標準和MPEG標準的數據壓縮技術有許多共同之處，但P×64標準是為適應各種通道容量的傳輸，而MPEG標準是用狹窄的頻帶實現高質量的圖像畫面和高保真的聲音傳送。
3 多媒體數據的存儲管理和存取方法
如何有效地按照多媒體數據的特性去存取多媒體數據呢？利用常規關系數據庫管理系統來管理多媒體數據已經不能適應了，基于內容的多媒體信息檢索研究應運而生。它支持其他多媒體信息技術，如超媒體技術、虛擬現實技術、多媒體通信網絡技術等。多媒體內容的處理分為三大部分：內容獲取、內容描述和內容操縱。也可將其看成是內容處理的三個步驟，即先對原始媒體進行處理，提取內容，然后用標準形式對它們進行描述，以支持各種內容的操縱。
內容獲取(Populating) 通過對各種內容的分析和處理而獲得媒體內容的過程。多媒體數據具有時空特性，內容的一個重要成分是空間和時間結構。內容的結構化(Structuring)就是分割(Segmenting)出圖像對象、視頻的時間結構、運動對象，以及這些對象之間的關系。特征抽取(Extraction)就是提取顯著的區分特征和人的視覺(Visual)、聽覺(Auditory)方面的感知特征來表示媒體和媒體對象的性質。
----內容描述(Description) 描述在以上過程中獲取的內容。目前，MPEG-7專家組正在制定多媒體內容描述標準。該標準主要采用描述子(Descriptor) 和描述模式(Scheme) 來分別描述媒體的特性及其關系。
----內容操縱(Manipulating) 針對內容的用戶操作和應用。有許多這方面的名詞和術語。查詢(Query)是面向用戶的術語，多用于數據庫操作。檢索 (Retrieval) 是在索引(Index)支持下的快速信息獲取方式。搜索(Search)常用于Internet的搜索引擎，含有搜尋的意思，又有在大規模信息庫中搜尋信息的含義。
摘要(Summarization， Excerpt)對多媒體中的時基媒體(如視頻和音頻)是一種特殊的操作。我們熟知文獻摘要的含義，在內容技術支持下，也可以對視頻和音頻媒體進行摘要，獲得一目了然的全局視圖和概要。同樣，用戶可以通過瀏覽(Browsing) 操作，線性或非線性地存取結構化的內容。另外，基于內容的技術不僅僅用在多媒體信息的檢索和搜索方面，檢索僅僅是信息存取的一個方面。過濾(Filtering)就是與檢索相反的一種信息存取方式。用過濾技術可以實現個人化的信息服務。
4 分布式數據庫技術
分布式數據庫系統是在集中式數據庫系統的基礎上發展起來的，是數據庫技術與計算機網絡技術的產物。分布式數據庫系統是具有管理分布數據庫功能的計算機系統。一個分布式數據庫是由分布于計算機網絡上的多個邏輯相關的數據庫組成的集合，網絡中的每個結(一般在系統中的每一臺計算機稱為結點node)具有獨立處理的能力(稱為本地自治)，可執行局部應用，同時，每個結點通過網絡通訊系統也能執行全局應用。所謂局部應用即僅對本結點的數據庫執行某些應用。所謂全局應用(或分布應用)是指對兩個以上結點的數據庫執行某些應用。支持全局應用的系統才能稱為分布式數據庫系統。對用戶來說，一個分布式數據庫系統邏輯上看如同集中式數據庫系統一樣，用戶可在任何一個場地執行全局應用。分布式數據庫具有如下特點：
4.1本地自治(Local Autonomy)；
4.2不依靠一個中心站點；
4.3能連續操作；它也是數據庫技術的一個發展方向。
關鍵詞：Struts；Hibernate；MVC；ORM
1 引言
基于網絡的教學答疑系統可以使學生與教師之間的溝通更加及時、深入，從而增加學生學習興趣并提高學習質量。本系統基于Struts與Hibernate的J2EE框架，Struts實現MVC架構，Hibernate完成J2EE中的對象持久層。
2 基于MVC的Struts實現機制
MVC是Model-View-Controller的簡稱，即模型－視圖－控制器。MVC是一種設計模式，它把應用程序分成三個核心模塊：模型、視圖和控制器。Struts是一個基于Sun J2EE平臺的MVC框架，主要是采用Servlet和JSP技術來實現的。Struts實質上就是在JSP Model2的基礎上實現的一個MVC框架。在Struts框架中，模型由實現業務邏輯的JavaBean或EJB組件構成，控制器由ActionServlet和Action來實現，視圖由一組JSP文件構成。圖1顯示了Struts實現的MVC框架[1]。
Struts工作流程：首先由客戶端瀏覽器向Web服務器發出HTTP請求，JSP容器中控制器ActionServlet根據配置文件struts-config.xml決定將請求交給相應的Action來處理。Action實現業務邏輯的處理，實現模型中業務數據的更新及程序的流程控制。當Action處理結束后，控制器根據Action返回結果調用相應的JSP文件，并將執行結果返回給客戶端瀏覽器。
3 數據持久化與Hibernate實現機制
在J2EE應用中編程操作采用的是面向對象模型，而后臺數據庫通常是關系模型，為解決關系型數據庫與對象型編程語言之間的不一致提出了數據持久化。數據持久化完成了O/R Mapping（Object/Relation Mapping，ORM，對象關系映射），從而實現了對象與關系數據庫之間的映射。Hibernate是一個開源的ORM框架，它提供了強大的對象和關系數據庫映射與查詢功能，并大幅度減少開發過程中使用SQL與JDBC處理數據的時間。Hibernate實現機制如圖2所示[2]。
Hibernate是Java應用系統和關系數據庫之間的ORM中間件，它完成Java對象和關系數據之間的映射。Hibernate內部封裝了通過JDBC訪問數據庫的操作，向上層應用系統提供了面向對象的數據訪問API[3]。Hibernate的配置文件hibernate.properties包含了數據庫連接的有關信息，XML Mapping文件包含了對象和關系數據庫之間的映射。
4 教學答疑系統的設計與實現
教學答疑系統實現了教師與學生之間基于網絡的信息交流與溝通。系統的用戶主要有三種：學生、教師和系統管理員，學生和教師要先注冊才能使用本系統。系統主要由5個模塊構成：
（1）注冊模塊：學生和教師可以以不同的角色進行注冊。
（2）登錄模塊：學生和教師以注冊的角色進行登錄。
（3）問題提交模塊：學生登錄后可以提出問題，并可以選擇相應的任課教師回答。
（4）問題回答模塊：教師登錄后對沒有回答的問題進行回答。
（5）管理模塊：管理員登錄后可以對問題和答案進行管理。
教學答疑系統使用Struts框架進行設計與實現，顯示層使用JSP頁面實現，控制層由ActionServlet和Action實現，模型層的業務數據由Hibernate框架實現數據的持久化。
4.1 Struts框架的實現
在基于Struts框架的系統中控制器ActionServlet根據Struts的配置文件struts-config.xml來實現客戶端數據的輸入、處理及輸出的映射。運行用戶注冊頁面register.jsp，用戶將表單中的注冊信息提交給控制器后，控制器根據上面配置文件創建一個JavaBean文件RegisterForm.java，即MVC中的業務模型。對業務模型的處理則由RegisterAction.java來完成，當注冊成功后調用login.jsp頁面進行登錄，失敗則調用register.jsp重新注冊。
在RegisterAction.java文件中，方法public ActionForward execute(ActionMapping mapping,ActionForm form,HttpServletRequest request,HttpServletResponse response)接收用戶表單中的信息，并根據信息創建業務模型對象RegisterForm，從而實現對業務數據的訪問，還可以根據業務數據的信息決定程序執行的流程。
4.2 Hibernate框架的實現
Hibernate的配置文件hibernate.cfg.xml中設置了數據庫的連接信息：數據庫的驅動程序、用戶名和密碼。UserInf.hbm.xml是對象/關系映射文件，實現了UserInf.java對象文件與數據庫表userinf的映射。
對數據庫的操作如查詢、修改、刪除和增加等操作則封裝在UserInfManager.java文件中：
該方法在實現時首先創建Session對象，Session s=Sessionfactory.getSession(); 然后執行各種數據庫操作，執行完畢后將Session對象關閉。
5 結語
基于Struts與Hibernate教學答疑系統實現了教師與學生之間信息交流的即時性，提高了學生的學習質量與學習興趣；同時基于Struts與Hibernate框架的設計與實現提高了系統的開發效率，增強了系統的可維護性，并提供系統更好的性能。
參考文獻
[1]孫衛琴.精通Struts：基于MVC的Java Web設計與開發[M].北京：電子工業出版社，2005：13-14.
[2]石志國.JSP網絡開發詳解[M].北京：電子工業出版社，2007：291-294.
[3]孫衛琴.精通Hibernate：Java對象持久化技術詳解[M].北京：電子工業出版社，2005.
