中 華 大 學 碩 士 論 文
題目：整合物件導向設計與關聯式資料庫之輔助環境 A Bridging Environment for Object-Oriented System
Development with Relational Databases
系 所 別：資訊管理學系碩士班 學號姓名：M09010002 陳 建 樺 指導教授：王 素 華 博 士
中華民國 九十四 年 七 月
摘要
目前網際網路的應用技術上，物件導向式分析與開發方式是目前的潮流，而 其中運用最廣泛的物件導向開發語言即是 Java 語言。然而後端資料庫技術，由於 物件導向式資料庫尚未普及，絕大部分的企業還是使用關聯式資料庫來做為電子 商務後端的資料儲存平台。而關聯式資料庫的儲存方式與物件導向設計的概念卻 有著相當大的差異。如何使這些前端是物件導向設計的物件，得以在保持物件導 向的特性下，儲存到後端關聯式資料庫中，即是一個極待解決的問題。
本研究提出整合物件導向輔助開發環境，其中包含 XML 轉換模組、資料庫轉 換模組、Java 程式碼產生模組、資料庫代理物件產生模組。XML 轉換模組負責將 電腦輔助軟體工程工具所繪製之類別圖，轉換成延伸標記語言定義之類別圖。資 料庫轉換模組將 XML 定義之類別圖，轉換成為關聯式資料庫表格。Java 程式碼 產生模組將 XML 類別圖中定義之類別轉換成為 Java 程式碼。資料庫代理物件產 生模組則將產生一個物件化的存取介面供程式開發人員存取關聯式資料庫。
本論文將經由分析物件導向之類別圖，透過轉換模組轉換成為資料庫定義碼 與 XML 定義之類別圖，再利用 XML 定義產生輔助存取關聯式資料庫之資料庫存 取物件，提供程式開發人員一個物件化的資料庫存取介面。本論文使用範例來驗 證本架構之可行性。本研究建構一個整合性輔助開發環境，為物件導向分析與關 聯式資料庫提供一個自動化轉換機制與物件化存取介面，透過自動化的流程，減 短系統的開發時程，並且降低系統維護的成本。
關鍵字：物件導向設計、關聯式資料庫、XML
Abstract
Object-oriented design and development has become a new trend of Internet application technology. The most popular object-oriented programming language is the Java language. However, lots of enterprises still develop their e-commerce application by use relational database. The object-oriented approach is not as widely accepted in the database implementation as in the front-end development. Since relational database systems continue to dominate in the database implementation technology, there is a strong demand for object-oriented programming languages being able to manipulate data through relational databases.
This research aims at constructing a bridging framework that integrates the front-end object-oriented design and the back-end relational database implementation.
The framework will provide functions of mapping object models to relational schema by using XML, creating relational database tables, automatic generation of Java classes according to the object model, and automatic generation of database proxy objects for the classes defined in the Java programs.
This thesis describes the integrated framework and each component in details. The process of how to automatic generate the relational schema from the original class diagram and provide an object interface for accessing the relation database is also discussed. A prototype system is implemented for verifying the bridging environment with example applications. Using this bridging framework, the programmers can have more transparent access of objects from relational databases.
Keywords: Object-oriented design, relational database, XML
目錄
摘要... I Abstract ... II 目錄...III 圖目錄...V 表目錄... VII
第一章 緒論...1
1.1 研究動機 ...1
1.2 研究目的 ...2
1.3 研究步驟 ...3
1.4 章節導讀 ...4
第二章 文獻探討...6
2.1 結構化分析方式與物件導向式分析方式 ...6
2.1.1 結構化分析方式 ...6
2.1.2 物件導向化分析方式 ...8
2.1.3 物件導向分析方式與結構化分析方式之比較 ...9
2.2 物件導向式資料庫與關聯式資料庫 ...10
2.2.1 關聯式資料庫介紹 ... 11
2.2.2 物件導向式資料庫介紹 ... 11
2.2.3 物件導向式資料庫與關聯式資料庫的比較 ...12
2.3 資料庫連接方式之比較 ...13
2.3.1 原生式資料庫連接方式 ...14
2.3.2 ODBC 連線方式 ...14
2.3.3 JDBC 連線方式 ...15
2.4 物件導向式分析轉換關聯式資料庫之相關研究 ...17
2.4.1 統一塑模語言介紹 ...17
2.4.2 UML 類別圖轉換方式 ...19
2.4.3 多對多關係之正規化 ...23
第三章 物件轉換關聯式資料庫之研究架構...26
3.1 系統架構 ...26
3.2 XML 轉換模組 ...27
3.3 資料庫定義轉換模組 ...28
3.4 類別圖轉換實例 ...33
第四章 物件化資料庫連接架構...38
4.1 資料庫連接系統架構 ...38
4.2 Java 類別產生器 ...40
4.3 資料庫代理物件產生器 ...42
4.4 物件導向式模組設計 ...44
4.4.1 Java Class 類別 ...45
4.4.2 ClassAttribute 類別 ...47
4.4.3 RelationshipRecord 類別 ...47
4.4.4 DBSchema 類別...48
4.5 資料庫代理物件 ...49
第五章 系統實作與驗證...54
5.1 系統平台設定 ...54
5.1.1 Java 程式語言 ...54
5.1.2 MySQL ...54
5.1.3 文件物件模型 ...55
5.2 系統平台設定 ...55
5.3 個案分析 ...58
5.3.1 個案背景描述 ...58
5.3.2 企業資訊化目標 ...59
5.3.3 使用者需求描述 ...59
5.3.4 進銷存管理系統之類別圖 ...59
5.3.5 資料庫定義碼轉換之結果 ...61
5.3.6 Java 程式碼轉換之結果 ...63
5.3.7 比較資料庫連接方式 ...65
第六章 結論與未來展望...70
6.1 結論 ...70
6.2 未來展望 ...71
參考文獻...73
圖目錄
圖 1.1 研究流程圖 ...4
圖 2.1 分析模型的結構 [Roge01] ...7
圖 2.2 ODBC 組成架構圖 [ODBC05] ...15
圖 2.3 JDBC 組成架構圖 [JDBC05]...16
圖 2.4 繼承關係類別圖 ...20
圖 3.1 物件轉換關聯式資料庫定義 ...26
圖 3.2 XML 轉換模組 ...28
圖 3.3 資料庫轉換架構圖 ...29
圖 3.4 資料庫轉換流程圖 ...32
圖 3.5 類別圖實例 ...34
圖 3.6 月薪制類別之原始 XML 定義 ...34
圖 3.7 轉換後月薪制之 XML 定義 ...35
圖 3.8 月薪制資料庫定義碼 ...36
圖 3.9 月薪制類別包含資料庫定義(部分) ...36
圖 4.1 資料庫存取代理物件整合架構圖 ...39
圖 4.2 月薪制類別轉換之 Java 程式碼說明 ...41
圖 4.3 資料庫存取流程圖 ...43
圖 4.4 物件化資料庫連接系統之類別圖 ...44
圖 4.5 資料庫存取物件合作之類別 ...50
圖 4.6 getAllObject 之循序圖 ...52
圖 5.1 系統使用流程 ...56
圖 5.2 設定資料庫連接資訊 ...56
圖 5.3 設定資料型態對應 ...57
圖 5.4 類別圖輸入畫面 ...58
圖 5.5 服飾行之雛形系統類別圖 ...61
圖 5.6 Sales 之 Java 程式碼...64
圖 5.7 物件互動示意圖(商品銷售) ...65
圖 5.8 使用 JDBC 連接資料庫之 Sales 程式碼(部分) ...66
圖 5.9 使用 JDBC 與資料庫存取物件使用示意圖 ...67
圖 5.10 使用物件存取介面存取資料庫 ...67
圖 5.11 複合式結構化語句更新之程式碼行數比較 ...69
表目錄
表 2.1 結構化分析方式與物件導向分方式之差異 ...9
表 2.2 關聯式資料庫與物件導向式資料庫之比較 ...12
表 2.3 垂直式轉換資料表範例 ...21
表 2.4 水平式轉換資料表範例 ...22
表 2.5 過濾式轉換資料表範例 ...23
表 4.1 Java 型別與關聯式資料庫中對應之資料欄型別 ...41
表 4.2 類別之負責權責 ...45
表 4.3 Java Class 類別之屬性與方法 ...46
表 4.4 ClassAttribute 類別之屬性與方法 ...47
表 4.5 RelationshipRecord 類別之屬性與方法 ...48
表 4.6 DBSchema 類別之屬性與方法...49
表 4.7 DBInfo 類別之屬性與方法...50
表 4.8 ClassProxy 類別之屬性與方法...51
表 5.1 服飾行雛型系統之類別權責說明 ...60
表 5.2 類別圖轉換後資料表格名稱 ...61
表 5.3 Sales 關聯式資料表示意圖...62
表 5.4 Order 關聯式資料表示意圖...63
表 5.5 類別圖轉換 Java 檔案名稱 ...63
表 5.6 使用 JDBC 與資料庫存取物件程式碼行數比較 ...68
第一章 緒論
隨著資訊科技的蓬勃發展，電子商務在這幾年來迅速的成長，企業為了保有 其市場競爭力，企業的電子化以及發展電子商務早已是企業為了獲得市場競爭力 不可獲缺的重要因素之一。在目前網際網路應用技術當中，又以物件導向技術最 為常見。但是在物件導向式資料庫方面卻沒有跟著物件導向程式的發展，而取代 目前熱門的關聯式資料庫，企業仍使用關聯式資料庫來存放資料。本論文中，將 探討透過延伸標記語言(eXtensible Markup Language, XML)的技術，使前端的物件 導向設計之程式與後端的關聯式資料庫可以自動產生對應資料庫定義，透過本論 文提出的架構，自動的產生相對應的程式碼以及關聯式資料庫之定義碼，加速應 用程式系統的開發時程，降低企業應用系統建置之成本。本章說明研究動機、目 的、步驟並簡單說明之後各章節所闡述的內容。
1.1 研究動機
企業為了能夠在資訊技術上面以更新、更安全的方式來進行企業內部系統的 開發，往往在選擇系統開發的方式便會以物件導向式程式設計為優先選擇的目 標。而使用物件導向方式開發的優點，包含了元件的重複使用性高，元件的維護 成本降低等。Java 程式語言除了擁有上述物件導向的優點之外，還可以透過虛擬 機器的執行方式，達到跨平台的功能，減低重複開發的成本。近幾年來，Java 語 言已經越來越受到企業的喜愛，並且漸漸的取代了傳統結構化之程式語言。
但是在物件導向式資料庫(Object-oriented Database)卻沒有跟著物件導向程式 的發展，而取代目前熱門的關聯式資料庫(Relational Database)，企業仍使用關聯式 資料庫來存放資料。也因此在撰寫一個結構化程式的時候，程式開發人員可以很 輕易的把處理過的資料儲存至關連式資料庫當中，因為結構化的程式設計方式，
在資料與資料處理的邏輯方面是分開的。而關聯式資料庫本身的設計，就是專門 來存放資料，因此使得結構化的程式設計方式，把資料存入關聯式資料庫更加容 易。
但是當開發方式由結構化設計，改變成為物件導向式設計(Object-Oriented design)的開發方式時，處理方式便有極大的不同。在物件導向的觀點，每一個物 件都包含著屬性(attribute)以及相關方法(method)。物件是同時擁有資料的內容，以 及處理資料的邏輯概念兩個部分，這個特性跟只能儲存資料的關聯式資料庫大不 相同，但是目前物件導向式資料庫，在實際的企業應用上並不像關聯式資料庫一 樣普及。市面上所出現的商業化軟體也都較少使用物件導向式資料庫來進行資料 的存放。所以在處理物件導向程式的資料時，需要做額外的處理，來進行資料的 存放。
此外在較早進行資訊電子化的企業當中，有許多重要的資訊是儲存在早先建 立好的關聯式資料庫當中，而這些資料甚至會有許多不同的企業應用軟體來使 用，使得企業要捨棄原先既有的關聯式資料庫而改用物件導向式資料庫這件事，
增加了許多不確定的風險，這也是物件導向資料庫無法取代關聯式資料庫的因素 之ㄧ。
這樣的結果造成許多程式開發人員在資料庫的建立上，往往使用自我經驗來 建立，並且使得企業的資訊系統在經過多次的改版或修改之後，在系統維護上的 成本增加，甚至維護成本有可能會超過重新設計新的系統。這樣對企業來說，無 疑是浪費了許多不必要的成本，降低了企業的競爭力。
1.2 研究目的
目前系統開發程序當中，電腦輔助軟體工程(Computer Aided Software
Engineering tools, CASE tools)的應用是相當的重要，絕大多數的開發者人員，進行
大型應用軟體系統開發時，都會透過電腦輔助軟體工程來協助整個系統的開發。
而物件導向的設計方式領域中，使用的塑模語言為統一塑模語言(Unifier Modeling Language, UML)，這種語言可用規格化（Specifying）、視覺化（Visualing）、文件 化（Documenting）、及建構化（Constructing）的方式來塑模軟體系統。
透過電腦輔助軟體工程所產生的類別圖(class diagram)，程式開發人員會根據 類別圖所記載的內容，加上開發人員自己本身設計上的經驗，建立起所需要的資 料庫表格，但是這樣的建立方式往往沒有辦法提供一個有品質、可靠的資料庫表 格，以至於系統後期在維護上的負擔。且系統開發人員的經驗往往各不相同，也 使得在大型的專案上面，需要花更多的時間在開發人員的溝通與整合，使得系統 開發的時程受到耽誤。
本論文中，希望透過使用延伸標記語言達成自動整合物件導向設計與關聯式 資料庫之間的資料定義，讓開發人員可以專注在物件導向程式的設計與開發當 中，而關聯式資料庫的對映關係，由我們所提出的這個架構來負責處理。這樣的 處理方式，將可以盡量避免人為上的資料庫設計錯誤，並更可以加速整個企業應 用程式開發的時程。
1.3 研究步驟
本研究將收集相關文獻，針對關聯式資料庫與物件導向式資料庫差異之處，
進行比較。分析關聯式資料庫在設計上需要注意之要素，並結合物件導向式分析 之類別圖，探討兩者在進行結合時需要之訊息與方法，透過延伸標記語言的方式，
讓系統得以自動化產生關聯式資料庫之資料庫定義碼。
關於延伸標記語言的處理，則利用 Java 程式語言來進行處理，將物件導向分 析之類別圖中定義之物件類別，轉換成為 Java 語言之定義。透過自動化的產生程 式碼與資料庫定義，本研究將可更進一步提出自動化產生存取資料庫之物件化介
面供程式設計人員使用。本研究之研究流程如圖 1.1 所示。
收集相關文獻
界定研究範圍
探討關聯式資 料庫設計要素
探討物件導向 式分析方法
了解 Java 程 式語言特性 了解 XML
技術特性
系統驗證與實作 整合關聯式資料庫
對應物件導向分析
系統架構設計
圖 1.1 研究流程圖
1.4 章節導讀
本論文將針對所提出的物件導向式設計轉換關聯式資料庫之系統架構及流程 提出說明，內容包含物件導向設計到關聯式資料庫的轉換及提供一個物件導向式 的存取方式，以及未來的研究方向。
在下一章會針對物件導向式塑模方式與傳統的結構化塑模方式進行介紹與比 較、物件導向式資料庫以及關聯式資料庫進行比較；並且比較目前的資料庫連接
方式，像是 ODBC、與 JDBC 等等的技術，以及目前物件導向轉換到關聯式資料 庫的相關文獻作一探討。
第三章將會針對本論文所提出的轉換架構，作各個元件的說明與介紹。特別 是如何將類別圖進行轉換成 XML 定義，與自動化產生關聯式資料庫定義碼的方法 與演算法進行詳細的說明。
第四章將會針對本文所提出的物件導向式資料庫存取方式，作各個元件的說 明與介紹。如何自動化產生 Java 的程式碼，並且提出一個物件化資料庫存取介面，
供系統開發人員在存取資料庫時使用。
第五章將實作一個模擬系統，用來驗證本文所提出之架構可能性，本章主要 會說明系統實作時使用之設計考量、建置工具與技術。並且提出一個案例進行實 作說明與測試。第六章將對實作之系統，與傳統的分析與設計方式所產生的結果，
作一比較，並提出本論文的結論，及未來的研究展望。
第二章 文獻探討
在本章節中，將探討有關物件導向式設計與結構化設計。透過討論兩者之差 異，分析出物件導向分析所產生之相關分析文件在開發時的角色。分析物件導向 式資料庫與關聯式資料庫，並了解其存放的目標與差異。討論幾種目前常用的資 料庫連接方式，以分析目前資料庫連接上的差異與困難點。最後探討目前有關物 件導向對應到關聯式資料庫的相關文獻，並且整理出一個本論文所提出之架構可 用的方法。
2.1 結構化分析方式與物件導向式分析方式
在本節會介紹結構化分析方式之基本概念，與物件導向式分析方式之基本概 念。說明這兩種不同的分析方法相關文獻，並討論物件導向式分析與結構化分析 兩者之差異。
2.1.1 結構化分析方式
結構化分析(Structured analysis)是由 Douglas Ross 所創造的，而由 DeMarco [Dem79]所推廣。DeMarco 在其著作當中，介紹並命名了關鍵的圖形符號，使系統 分析師可以建立資訊流程模型，對這些符號的使用提出實用性的建議。在隨後的 幾年，有許多結構化分析方法的變化分別由 Page Jones[Page80]、Gane 和
Sarson[Gane82]，以及其他的許多人所提出。
分析模型必須要完成三個主要的目的：(1)描述客戶的需求是什麼，(2)建造一 個建立軟體規劃的基礎，(3)一旦軟體建立起來，便定義一組有效的需求。要完成 這些目標，在結構化分析中推導出如圖 2.1 的分析模型。
在這個模型的核心為資料字典(data dictionary)─一個包含軟體所有消費或產 生的資料物件的容器。在核心外有三個不同的圖表。實體-關係圖(entity-relationship diagram, ERD)，敘述資料物件之間的關係。ERD 是用於進行資料模型建立活動的 表示法。在 ERD 中每個資料物件的屬性可以使用資料物件特徵來描述。
Entity relationship diagram
Data flow diagram
State-transition diagram
Control specification
Data object description Process specification
Data dictionary
圖 2.1 分析模型的結構 [Roge01]
資料流程圖(data flow diagram, DFD)提供了兩個目的：(1)提供一個資料在系統 中移動時如何轉移的指示，及(2)敘述轉移資料流的功能(及子功能)。DFD 提供了 在資訊領域的分析過程中的額外資訊，並做為功能的模型建立之基礎。在 DFD 中 所表達的每個功能特徵則包含在過程規格說明(process specification, PSPEC)中。
狀態-轉移圖(state transition diagram, STD)描述的外部事件對系統行為造成如 何的影響。要完成這點，STD 表達了許多系統的行為模式(稱為狀態，state)及狀態
間轉移的方法。STD 是行為模型建立的基礎。對於軟體在控制方面的額外資訊則 包含在控制規格說明(control specification, CSPEC)中。
2.1.2 物件導向化分析方式
物件導向分析方式是繼結構化分析方式後，另一個廣為業界所使用之開發方 式，主要概念為，把真實世界視為由物件所構成，真實世界的運作是由各個物件 之間互動來產生，再將真實世界的問題對應到分析設計的模型上，最後再轉換成 相對應的程式碼。
以物件導向方法來發展軟體，最早在 1960 年代末期被提出的，但是，物件技 術到 20 年後才廣為使用。在 1990 年代前半期，物件導向軟體工程已成為許多軟 體產品建造者的選擇，物件科技正要取代傳統的軟體發展方法[Roge01]。
物件導向技術當中，主要有三個特性，分別為封裝性(encapsulation)、繼承性 (inheritance)以及多型(polymorphism)這三個觀念。封裝性就是將物件實例的屬性與 方法一起封裝到類別中，這是一種資訊隱藏(information hiding)的觀念。在傳統的 結構化分析當中，資料結構與函數是分離的，這當我們在維護程式時就會產生很 大的困擾；而在物件導向中便將這兩個東西緊密的包圍在一起，使得一物件內的 資料只有透過適當的介面(方法)才能修改。
繼承性起源於軟體再用(software reuse)的觀念。對於物件導向技術來說，經由 封裝而成的類別就是一個最佳的可重複使用軟體元件。而繼承性就是用來避免相 關資訊重複出現的一個觀念。當物件有繼承關係存在的時候，會繼承父類別相關 的方法與屬性，當此物件被要求執行某個方法時，若此物件本身有定義這個方法，
則可以直接執行此方法，否則會沿著繼承關係向上個層級去尋找，直到找到為止。
但是在不同的階層當中，同樣名稱的方法可能有不同的定義，執行方法時，會沿 著類別階層由下往上找，因此子類別的定義將優先於父類別。這樣的技術稱之為
覆蓋(overriding)。
多型或稱多載或同名異式，這項特色可以大大降低現有的物件導向系統的擴 充成本。多型可以允許許多不同的方法擁有相同的名稱，這有助於將物件隔開，
使得物件彼此依賴性降低[Tayl90]。
2.1.3 物件導向分析方式與結構化分析方式之比較
傳統的結構化分析方式曾被廣泛的使用，但是由於時代的進步與改變，結構 化分析方式漸漸暴露其缺點，對於追求效率與品質的時代，結構化技術無法符合 其需求，使其逐漸被物件導向技術所取代。表 2.1 是結構化技術與物件導向技術 的比較。
表 2.1 結構化分析方式與物件導向分方式之差異
議題 結構化分析 物件導向式分析
分析與設計 之轉換
分析與設計各個階段使用不 同模型，使分析與設計間存 在一道鴻溝。
分析：資料構面-實體關係圖 (ERD)為主要工具
處理構面-資料流程圖 (DFD)為主要工具
設計：使用資料庫模型、模 組結構圖
在分析、設計、程式設計與 資料庫均使用幾乎一致的類 別模型，使得分析與設計的 鴻溝不再存在，以及階段轉 移非常平順。分析與設計幾 乎是同一個工作。
資料與處理 之關係
資料與處理分開。 資料與處理均封裝於物件之
內。
設計考量 處理導向(Process-oriented)：
分析設計時，主要考量系統 所要完成的功能或處理。
以物件為導向
(Object-oriented)，以系統執行 時所需要處理的資料也就是 物件為中心來考量系統。
續表 2.1 結構化分析方式與物件導向分方式之差異
議題 結構化分析 物件導向式分析
分析與開發 之關係
由上而下 由下而上
學習門檻 易學難用 難學易用
軟體重複使 用性
資料是被動的，程式取得資 料，處理之後回存，軟體的 再用性取決於系統分析與設 計之良劣。
再用性高。
由表 2.1 的比較可以得知，傳統的結構化設計在軟體的重覆使用性，比起物 件導向設計要來得差，而物件導向設計在分析設計與程式開發上，又可以減少分 析與設計之間的差距，進而縮短了軟體開發的時程。這也是為什麼近幾年來，物 件導向設計漸漸取代了傳統的結構化設計的原因。
下一節將介紹物件導向式資料庫與關聯式資料庫，並討論一下目前物件導向 式資料庫未能夠普及的原因。
2.2 物件導向式資料庫與關聯式資料庫
資料庫系統基本上是一個電腦化的資料保存系統，也就是指整個系統的目的 在於維護資訊及依需要擷取資訊。以目前的應用來說，最多使用的資料庫系統是 關聯式資料庫。在本節中，將會針對關聯式資料庫，及物件導向式資料庫進行介 紹與比較。
2.2.1 關聯式資料庫介紹
C. J. Date[Date97]認為關聯式資料庫最少需要具備兩個特性，使用者所看到的 資料都是表格；使用者所用的運算子(用於資料擷取)是從舊表格產生新表格的運算 子。而張瓊誼[張瓊誼 94]認為關聯式資料庫系統的資料是以特定的欄位(Field)及固 定的欄位範圍(Domain)所組成，由於結構簡單、彈性大，故頗適合在商業領域上 之應用，因為一般商業上的應用，多是從檔案應用演進而來，通常只需要對大量 資料做一些簡單的運算，即能滿足其需求。但面對一些如 CAD/CAM、OIS、AI、
CASE 及多媒體等具有複雜性、大量性和資料密集性(Data-Intensive)等特性之應用 領域時，則有明顯之不足。
關聯式資料庫就是讓使用者將資料庫視為由關聯性(或表格)，所構成的集合。
關連性中所有值都是基元(atomic)或是純量。關聯式系統底下的正式理論基礎稱為 關聯式模型。關聯式模型所關心的是邏輯事務，並非實際事物。強調資料個三個 方面，資料結構，資料完整性與資料處理。
關聯式資料庫使用的查詢語言是結構化查詢語句( Structure Query Language，
SQL)[Codd70，90]。SQL 最初是由 IBM 研究中心在 1970 年代所開發的，SQL 首 度用在 IBM 關聯式資料庫中，隨即被很多商業化的產品所引用。因此，SQL 的語 言變成為了 ANSI/ISO 的標準。
SQL 是用來將關聯式運算(即以關聯式形式來定義及處理資料的運算)公式 化，透過 SQL 語法的使用，可以讓使用者快速的建立表格，修改、查詢資料等等。
2.2.2 物件導向式資料庫介紹
物件導向式資料庫就是遵循著物件導向的主要概念，以儲存完整物件特性為 主，其中包含了物件的屬性，以及處理物件內部資料的方法(method)。簡言之，物
件導向式資料庫必須是儲存物件的全部特性，而非單純的存放屬性資料，這點與 關聯式資料庫相當不同。
由於物件導向式開發的興起，近年來發現到其實整個真實世界的資料，都如 同物件導向語言中的定義，每個物體自成一個物件，並且可以繼承其它物件的性 質。而 Jasmine 物件導向式資料庫系統是由組合國際(Computer Association)公司所 開發出來的純物件導向式資料庫，它利用物件導向的特性，來儲存相關資料，也 利用物件導向式的特性，來進行對資料的處理。
根據 Date[Date97]對於物件導向式資料庫的定義，他認為物件導向式資料庫內 部存放的是一個個的物件，而每個物件都必須有獨一無二的物件辨別碼(OID)，且 每一個物件必須是經過包裝的，亦即其內部表示法對於使用者而言是不可視的，
使用者只知道該物件可以經由某些方法來處理。物件具有私用記憶體及公用介 面，私用記憶體為物件內之屬性(attribute)，而公用介面為方法的介面定義。在純 粹的物件導向系統中，使用者只能看到方法，這些方法則存在於物件的類別定義 物件(CDO)。
2.2.3 物件導向式資料庫與關聯式資料庫的比較
由前兩節的介紹可以得知，關聯式資料庫最主要的儲存目標是資料，再透過 表格欄位的關聯，去產生出需要的資料。而物件導向式的資料庫，則是存放一個 個的物件，等需要的時候再去尋找所需的物件，來進行相關的處理。本研究將簡 單的比較整理如表 2.2：
表 2.2 關聯式資料庫與物件導向式資料庫之比較
議題 關聯式資料庫 物件導向式資料庫
支援物件導向式 程式語言
無，程式設計師需要多花 25%的時間在編寫程式上
直接且幾乎全部支援
續表 2.2 關聯式資料庫與物件導向式資料庫之比較
議題 關聯式資料庫 物件導向式資料庫
使用是否容易 表格式的架構相當易讀，且 有很多的輔助工具可用
對有物件導向式經驗的程式 設計人員還算容易
是否容易開發 提供獨立於應用程式以外的 資料，當資料關聯簡單的時 候開發相當容易
很直覺的方式將物件的關係 與物件的本體放入資料庫之 中，可以存放很多不同的物 件與物件彼此之間的關係 儲存內容之延展
性
無 隨心所欲的存放，使用者可
以建立各個不同的資料物 件，也可以自由的幫該物件 撰寫方法
複雜的資料關係 很難以從資料庫中建立關係 模型
可以儲存很複雜的關係，也 可以讓使用者去建立各式各 樣的物件關係
目前廠商實際使 用的比例
多 很少
產品的成熟度 相當成熟 還不是很成熟
目前軟體業界的 環境
由許多相當大的公司所提供 許多大型的產品
目前廠商正想辦法追上大型 關聯式資料庫的腳步，但是 並沒有任何一家在目前具有 較大的市場佔有率
資料庫供應商的 穩定度
目前市場多半被許多大型的 公司分占，各家公司均有自 己固定的客戶
比較少相關資料實際討論這 個議題，不過大多研究預期 將有一些廠商退出這個市場
在對映物件導向式資料與關聯式資料的關係，一向是相當瑣碎且煩人的工 作。但是目前來說，純物件導向式資料庫應用仍舊不夠普及，再加上關聯式資料 庫在企業應用已經是相當成熟的技術，所以開發人員常常面臨到必須在後端使用 關聯式資料庫，來進行物件導向應用程式的開發與設計。
2.3 資料庫連接方式之比較
資料庫與應用程式之間的連接，透過幾種不同的方式來進行，目前比較常見 的資料庫連接方式分別是原生式資料庫連接方式，以及 ODBC(Open Database Connectivity)與 JDBC(Java Database Connectivity)的方式來進行資料庫的連接[呂凌 宇 04]，以下分節敘述。
2.3.1 原生式資料庫連接方式
早期的資料庫連接，不同的資料庫會有不同的連接方式，應用程式得配合資 料庫的不同，以撰寫專屬於某個廠牌的特殊連線程式，這方式就是所謂的原生式 資料庫連接方式。在早期資料庫種類不多的狀況之下，或是應用程式還不是很需 要跨多種不同的資料庫時，不同廠牌的資料庫各有不同的連線方式，對開發人員 還不是很大的問題。但隨著資料庫種類越來越多，為了能夠讓同時支援不同的資 料庫，程式開發人員得需要針對每一個不同類型的資料庫，撰寫相對應的應用程 式，或是修改程式碼以符合各個不同資料庫的需求，而造成程式移植與開發的困 難。
2.3.2 ODBC 連線方式
為了解決上述所提到的問題，誕生了 ODBC(Open Database Connectivity)的觀 念。ODBC 是一套應用程式介面(Application Program Interface，API)，利用這套 API 來撰寫應用程式時，便可以鬆脫應用程式與資料庫之間本來高度依賴的關係，
達到不用變更應用程式的程式碼，只要改用不同的 ODBC 就可以和不同的資料庫 做連線的效果。[ODBC05]
ODBC 的主要觀念是希望將資料庫連線的部份做成一個黑箱作業，讓程式開 發人員只需要熟悉 API 的使用，不必實際去了解 API 如何去跟資料庫溝通，而與 資料庫溝通的部份，就交由資料庫連線器的開發廠商去進行開發與處理，已達到 專業分工，進而將程式碼與資料庫分別獨立出來。
ODBC 一共由四個部份所組成，如圖 2.2。應用程式使用介面(Application)、
驅動程式管理員(Driver Manager)、驅動程式(Driver)和資料來源(Data Source)。透 過這四個不同層次的規範與標準，各家資料庫廠商就能依自己資料庫的特性，來
撰寫相對應的 ODBC，而達到將應用程式與資料庫獨立開來的架構。
應用程式使用介面 (Application )
驅動程式管理員 (Driver Manager)
驅動程式 (Driver)
資料來源 (Data Source)
圖 2.2 ODBC 組成架構圖 [ODBC05]
2.3.3 JDBC 連線方式
Java 在發展的過程當中，也將 ODBC 這套與資料庫連線的方式，應用在 Java 上，而發展出了 JDBC(Java Database Connectivity)。因此，Java 為程式語言所開發 出的應用程式如果想與資料庫連線，只要遵照 JDBC API 的規範與標準，並取得 欲連線資料庫的 JDBC，就可以在不更動程式碼的狀況下，而和不同的資料庫連 線。[JDBC05, Gutj02]
JDBC 的架構與 ODBC 的架構極為類似，都是分為四層，如圖 2.3。應用程式 使用介面(Application)、驅動程式管理員(Driver Manager)、驅動程式(Driver)、和資 料來源(Data Source)。
Java 應用程式使用介面
(Java Application Program Interface)
Application 層
Java 驅動程式管理員 (Java Driver Manage)
Driver Manager 層
網路協定 驅動程式 (JDBC-Net Driver)
JDBC- ODBC 橋接驅動程式 (JDBC-ODBC Bridge)
原生 API 驅動程式 (Native- API Driver)
原生協定 驅動程式 (Native Protocol Driver)
Driver 層
資料來源 (Data Source)
圖 2.3 JDBC 組成架構圖 [JDBC05]
Driver 層中的 JDBC 共有四種不同的形式，簡單介紹一下這四種形式的差異。
z 網路協定驅動程式，這一種形式的 JDBC 會經由中介網路伺服器去存取 資料庫，所以是否具有移植性，就要看這個中介網路伺服器所提供的功 能而定。
z JDBC-ODBC 橋接驅動程式，這種方式主要是為了能夠讓 JDBC 與原先 以存在系統內的 ODBC 相容，便在原來的 ODBC 之上，再加了一層 JDBC 的程式碼，以將 ODBC 包在 JDBC 之內。因為這種形式的設計必須依賴
特定的 ODBC，所以不具有移植性。
z 原生 API 驅動程式，這種型態的 JDBC 是由 Java 語言和非 Java 所開發出 來的存取程式合併而成，因為和原資料庫廠商的存取程式綁在一起，所 以不具有移植性。
z 原生協定驅動程式，這類型的 JDBC 完全由 Java 所撰寫出來的，它可以 直接與資料庫連線或是透過網路協定與資料庫連接，許多的資料庫廠商 所提供的都是這類型的 JDBC。
JDBC 是以物件導向的方式去設計出來的應用程式介面(Application
Programming Interface) [Bret01，Ivor00]，而且已經是目前 Java 連接資料庫當中，
最常被應用的技術。JDBC 主要的使用方式，就是利用 SQL 語句進行對資料庫中 資料的操作。但是過多的 SQL 語句除了造成程式在閱讀上的困難，以及增加在維 護上的成本，並且喪失物件之特性。
2.4 物件導向式分析轉換關聯式資料庫之相關研究
在本小節將針對物件導向式分析方式，跟如何轉換至關聯式資料資料庫作一 介紹，本節將會介紹物件導向式分析的塑模語言，以及在轉換至關聯式資料庫時，
一些需要注意的事項。以下先介紹有關物件導向式常用的塑模語言─UML (Unified Modeling Language)。
2.4.1 統一塑模語言介紹
統一塑模語言(Unified Modeling Language, UML)是 Rational 公司整合 Grady Booch [Booc91]的 Booch 方法、James Rumbaugh [Rumb96]的物件塑模技術(Object Modeling Technique, OMT)、Ivar Jacobson [Jaco94]的物件導向軟體工程
(Object-Oriented Software Engineering, OOSE)三種方法、和其它的物件導向方法 論，而提出物件導向系統的塑模語言。該塑模語言於 1997 年 11 月經物件管理組 織(Object Management Group, OMG)通過採用成為物件導向系統分析與設計的業 界標準。
UML 是一種規格化(Specifying)、視覺化(Visualizing)、文件化(Documenting)、
與建構化(Constructing)的軟體塑模語言，它是一個標準的塑模語言，而非標準的 程序(Process)語言。Jacobson [Jaco96]等人在 UML 0.9 和 0.91 版的文件說明了 UML 的宗旨：「UML 打算成為一套用來建立系統模型的普遍性語言，亦即 UML 可以表達許多不同種類與目的之模型，就像人們使用程式語言或自然語言一般」。
Booch 在接受 M., Frank[Maur96]專訪時也說道：「我們稱它為 UML，因為它是可 以標準化的部份，至於開發程序部份，通常必須隨企業或組織的應用領域而調整。
就如同建造房子的途徑是多樣化的，但設計房屋藍圖的方法則是唯一的」。上述特 性使得 UML 所能應用的專業領域變的更為寬廣，如一般企業的商用系統、工廠自 動化系統與軍事模擬系統等。
UML 是從使用者、分析師、系統整合者、測試者、技師與專案管理者的多種 觀點去思考，來架構一套從需求分析、系統分析設計到程式撰寫的完整塑模語言，
其所提供描述真實世界物件的符號(Notation)有彈性且精簡，並具備圖形化的表達 能力，讓使用者可以充分表達從業務流程分析、業務需求、物件模式化、到物件 設計的各種結果，因此企業與資訊軟體廠商紛紛開始投入並採用 UML 的產品及服 務，使 UML 成為目前最為盛行的塑模語言之一。
UML 定義了九種型態的圖形：使用個案圖(Use Case Diagram)、類別圖(Class Diagram)、物件圖(Object Diagram)、循序圖(Sequence Diagram)、合作圖
(Collaboration Diagram)、活動圖(Activity Diagram)、狀態圖(Statechart Diagram)、
元件圖(Component Diagram)和部署圖(Deployment Diagram)。所有圖形的基本原 則，就是將概念描繪成符號，並將概念之間的相互關係描繪為連接符號的路徑（直
線），這兩種型態的元素都可以擁有自己的名稱 [陳志昌 99]。
這些 UML 的圖型中，又以類別圖與資料庫的關係最為密切，根據 Elmasri 和 Navathe 看法：類別圖是 UML 與 OMT 物件塑模方法的重要部份，它在許多地方 和 ERD 很相似，只是詞彙用語不同，例如：ERD 的實體可對映成為 UML 的物件，
但是 ERD 無法對映出 UML 物件的操作(Operation)[Elma00]。
另外一位學者 Muller 表示：在許多地方類別圖是非常相似於 ERD，如果比較 UML 類別的定義與 ERD 實體型態(Entity Type)的定義，將會發現它們在本質上 是相同的，不同之處主要在操作及關係的塑模部份。這樣的結論不用驚訝，因為 UML 的物件導向圖示大都是由 ERD 所發展出來的。[Mull99]。
由以上幾位學者的研究，我們得知類別圖可應用在物件資料結構塑模及邏輯 資料庫綱要的塑模，換言之，UML 的類別圖可以做為物件導向分析設計時資料塑 模的工具，且 ERD 非常類似，也是本研究為何選擇類別圖進行資料對應與提供一 個完整的物件導向化資料存取介面。
2.4.2 UML 類別圖轉換方式
在這樣一個前提之下，首先要面對的就是在資料庫當中，如何去進行資料的 對映問題。Keller 把從概觀上的資料對映，到細部有關資料庫效能調校所需要注 意的工作，都整理成一個以樣式語言來描述的架構[Wolf98]。並且在這個架構當中 是把所有有關物件導向與關聯式資料庫的資料在對映時，所要注意的議題。
架構方面提出在對一個系統要設計對映的工作時，需要有哪些的部分去進 行：物件導向的資料維護方面提出一些在把物件的屬性及關聯，用何種方式存放 到關聯式的；關聯式資料庫方面提出如何讓資料庫系統可以提供較好的服務效 能；建立存取層方面討論在建立存取層時，要使用何種方式來將物件放入資料庫 當中，以及在物件導向的發展過程中，何時去建立一個轉換的機制較佳。
其中在架構方面提到的兩層式處理架構(Two Layer Persistence Subsystem) [Cold97]，就是把物件導向式的資料部分，以及關聯式資料庫運作的部分，分開來 進行處理。
這種分層式的做法，好處在於它可以很方便的進行管理，尤其是在多種不同 關聯式資料庫的環境下。當新增加一個不同於現有系統的資料庫，系統人員只需 要針對新的資料庫去進行設定，而不會去變更到舊有的系統，這樣可以有效的減 少在新增資料庫時對舊有系統的影響。
在繼承架構對映方面，目前最常見的繼承架構對映模式有 3 種，為水平式 (horizontal mapping)、垂直式(vertical mapping)跟過濾式(filtered mapping) [Arth93，
Dan92，Sun92]，以圖 2.4 為簡單的繼承關係類圖，用以說明三種對應方式。
圖 2.4 繼承關係類別圖
圖 2.4 是一個簡單的繼承架構，包含了三個簡單的類別，雇員類別表示是公 司的員工，記錄姓名、電話、地址等等的基本資料；按件計酬類別表示記錄公司 當中按件計酬的員工，記錄有關案件的價格與工作數量，以方便計算薪資；而月 薪制類別則是表示公司當中按月付薪水的一般員工，其中記錄月薪資料及其服務 的部門資料。其中雇員這個類別是按件計酬與月薪制之父類別，也就是說，按件
計酬與月薪制兩個類別繼承了雇員這個類別當中的屬性，及其相關的操作。
當以垂直式的方法進行繼承關係轉換時，會先將所有的類別加入一個物件辨 別碼(OID)的欄位，並且在所有子類別當中加入一個記錄父類別之物件辨別碼欄 位。再透過表單的加入(join)的方式，來取得所需要的資料。轉換結果如表 2.3 所 示。簡言之，當應用程式需要建立月薪制員工之資料時，須先在雇員的資料表中 建立一個雇員資料，再到月薪制的資料表中，將剛剛建立之雇員的物件辨別碼填 入，以完成繼承關係的記錄。當應用程式需要去查詢時，則需要透過關聯式資料 庫的加入，讓月薪制的物件資料可以完整的呈現。
表 2.3 垂直式轉換資料表範例 雇員 表格
物件辨別碼 AutoNumber
姓名 String
電話 String
住址 String
月薪制 表格
物件辨別碼 AutoNumber
雇員之物件辨別碼 Long
基本月薪 Int
服務部門 String
按件計酬 表格
物件辨別碼 AutoNumber
雇員之物件辨別碼 Long
每件報酬 Int
工作件數 Int
水平式的轉換方法將不會有產生父類別的表格，而是把父類別中的所有屬性 下移至子類別當中，如表 2.4 所表示。這個方式會使得繼承關係在表格當中較為 不容易顯現，但是卻可以減少關聯式資料庫多花在加入動作上的效率。當應用程 式需要尋找月薪制員工資料時，僅僅需要去月薪制員工的資料表中去尋找，而不
需要多做額外的加入動作，以增加應用程式執行的效率。
表 2.4 水平式轉換資料表範例 月薪制 表格
物件辨別碼 AutoNumber
姓名 String
電話 String
住址 String
基本月薪 Int
服務部門 String
按件計酬 表格
物件辨別碼 AutoNumber
姓名 String
電話 String
住址 String
每件報酬 Int
工作件數 Int
過濾式的轉換方法會將所有的物件類別，內部所擁有的所有屬性皆移至最上 層的父類別中，在產生資料表的過程中只會有一個資料表產生。並且需要額外多 加一個欄位用來分別該筆記錄是屬於哪一個型態的資料物件，如表 2.5 所表示。
當應用程式需要尋找月薪制的資料時，就必須透過記錄物件型態的指標，來找出 它所需的類別物件。這個方法把所有的資料儲存在同一個資料表格當中，也因此 程式開發人員可以很簡單的去尋找物件相關的資料，但是同時卻喪失了物件的繼 承關係，也造成資料庫的表格可能會有存在著過多不需要的欄位，形成儲存空間 上的浪費。
這三種方式都可以達到物件導向的繼承觀念在資料方面於關聯式資料庫上的 應用，但是仍存在一些問題，這些方法都或多或少犧牲了資料的維護性來達成物 件導向的要求，或是犧牲了物件導向的觀念來增加資料庫的維護性，有的方法還 會造成許多欄位的浪費，可能會使得在資料庫運行效率上產生影響。
表 2.5 過濾式轉換資料表範例
雇員 表格
物件辨別碼 AutoNumber
物件型態 Int
姓名 String
電話 String
地址 String
基本月薪 Int
服務部門 String
每件報酬 Int
工作件數 Int
2.4.3 多對多關係之正規化
除了上述的方法來進行物件繼承架構的轉換之外，也有一些其他的學者提出 對物件的多對多關係轉換到資料庫的看法。像是 Bennett [Benn99]等人提出將類別 轉換為資料表格(Table)的方法。
1. 將具有簡單資料結構的類別轉換為資料表格。
2. 將物件識別碼(Object Identifier, OID)轉換為主鍵(Primary Key)：為每一個 類別配置一個物件識別碼屬性以做為關聯式資料庫資料表格的主鍵。
3. 類別中的某一屬性若包含有另一個類別實例(Instance)時，可為這個內嵌 的類別建立一個新資料表格。內嵌類別的物件應該配置一個唯一的物件 識別碼，該物件識別碼在原類別轉換為資料表格時，將替代原來的內嵌 類別並做為該資料表格的外來鍵(Foreign Key)。
4. 包含有物件群組(Collection)的類別，為它配置一個物件識別碼，該類別 將以資料表格的形式來展現。產生一個包含兩個欄位的新資料表格，第
一個欄位保有包含有物件群組的類別之物件識別碼，第二個欄位包含有 物件群組內的類別之物件識別碼。
5. 一對多(One-to-Many)的關聯關係可以比照物件群組的方式來處理。
6. 多對多(Many-to-Many)的關聯關係將變成一個新資料表格。產生的新資 料表格包含兩個欄位，資料表格中每筆記錄(Row)將有一對物件識別碼，
它來自於每一個參與關聯關係的物件(類似兩個物件群組)。
7. 一對一(one-to-one)的關聯關係將被實作成外來鍵屬性。為了維繫類別間 的關係，每一個類別會獲得一個額外的屬性－物件的物件識別碼。
另外，Stoimenov [Stoi99]等人提出將物件導向模式轉換為關聯模式的演算 法。該演算法包括六個步驟。
1. 對每一個在物件導向綱要中的類別 C，建立一個關聯 R，包含所有類別 C 的屬性，關聯 R 的主要鍵相當於一般的類別 C 的物件識別碼(OID)。
2. 轉換每一個特殊化關係為多個子類別{S1, S2, …, Sn}及一個父類別 C，
父類別 C 的屬性為{k, a1, …, an}，k 是主鍵。在將父類別 C 轉換成關 聯綱要(Relational Schema)時，除了 C 原有的屬性外還需要增加一個型態 屬性 t，以標示每一個值組(Tuple)或物件歸屬何種子類別；在將子類別轉 換成關聯綱要時，在每一個子類別 Si 中包含一個 k(C 的主鍵)當做外來 鍵。
3. 對類別 C 中的嵌入類別 E(Embedded Class)，其主鍵必須是類別 C 的主 鍵。
4. 對類別 C1 及類別 C2 間的每一個一對一(1：1)的關聯，可將任何一方的 主鍵置於對方成為外來鍵。
5. 對類別 C1 及類別 C2 間的每一個一對多(1：N)的關聯，將 1 這方的主鍵
置於 N 這方成為外來鍵。
6. 對每一個多對多(M：N)的關聯產生一個新關聯 R，它的主要鍵是 C1 與 C2 的主鍵的結合。
根據以上多位學者提出的方法，本研究將試著提出一個可以自動化的將類別 圖完整對應到資料庫定義的架構，並且透過這個架構，產生資料庫存取物件，讓 關聯式資料庫不單單是儲存物件的屬性，更可以進一步的透過本研究提出的架 構，提供給程式開發人員一個完全物件的存取方式。下個章節將會針對本研究之 架構提出說明。
第三章 物件轉換關聯式資料庫之研究架構
在本章節將針對物件導向式電腦輔助軟體工程(CASE Tool)所產生的類別圖 如何進行轉換作一介紹，並且建立相關方便程式設計人員使用的索引資料，透過 自動化轉換與資料庫定義碼的產生，加速系統開發時程。以下小節將詳細敘述系 統之架構。
3.1 系統架構
本研究提出的方法，最主要是透過 XML 的描述機制，自動產生資料庫表格定 義，以減少人工作業所造成的錯誤。主要工作核心在於把物件導向式分析之系統 類別圖自動產生資料庫的表格對映與建立定義碼。
資料庫對映的主要功能在幫助系統分析人員可以快速的建立資料庫的表格以 及建立一個簡單的資料索引，如此可以避免不必要的人為錯誤，並且加速系統在 開發時的時程與品質。系統概念架構說明如圖 3.1。
Class Diagram
XML transfer module
Database transfer module
Data index Inheritance Record
Relation record
Database Schema
圖 3.1 物件轉換關聯式資料庫定義
當系統分析人員在完成系統設計之後，可以將系統分析所建立的類別圖(class
diagram)，輸入到系統中的 XML 轉換模組，XML 轉換模組將會把輸入的類別圖，
透過每個 CASE tool 所專屬的讀取模組進行讀取之後，轉換成為 XML 定義的檔 案。再將 XML 定義的檔案傳送給資料庫轉換模組轉換成為關聯式資料庫定義碼，
最後將資料庫定義的表格名稱與欄位，寫回 XML 格式的檔案當中，用以建立資料 索引。另外也會將繼承關係與物件間彼此的關係，另行記錄以方便之後自動產生 存取資料庫物件的工作。
透過本文所提出的轉換系統架構，可以把物件導向設計之類別圖轉換成關聯 式資料庫定義碼，以方便關聯式資料庫中表格的建立，並且減少人為的介入，避 免不必要的人為疏失。
3.2 XML 轉換模組
XML 轉換模組的主要工作，就是把各種不同電腦輔助軟體工程工具所產生的 系統分析圖，透過一個轉換的機制，變成我們這個平台當中可以閱讀的格式。以 Rational Rose 為例，我們可以針對 Rose 這個輔助工具，去撰寫一個屬於該輔助工 具的讀取模組，透過讓該工具所產生的檔案可以被本論文的系統所接受。Rational Rose 是由 Rational 公司(目前已由 IBM 收購)推出的視覺化塑模工具，也是目前最 完整、佔有率最高的 UML 視覺化塑模工具，它也支援企業流程分析、物件導向分 析設計及元件架構設計等功能。
爲了達成這樣的目的，本論文的架構提出的是兩層式的轉換模式，第一個是 讀取模組部分，第二個是 XML 轉換核心。讀取模組的工作，最主要是把輸入的分 析圖中不必要的訊息去除，例如像是有關排版的資訊，或是一些不需要的標頭去 除，只取出與系統分析圖表所記載的內容相關的資料，以加快處理的速度。
第二個 XML 轉換核心，如圖 3.2 所示，即是將取出的資訊，以 XML 的格式 記錄，像是利用 XML 標籤的優點，把物件的屬性(Attribute)，方法(Method)及繼
承關係等等的各種物件特性，利用 XML 的標籤，做忠實的記錄，同時可以把一些 資料庫會使用到的部份資料，如屬性的資料型態等等，也一併的記錄下來。
… …
Class Diagram
Class Diagram
XML transfer module Rational Rose
lead-in adapter
Visio lead-in adapter
XML format class diagram
圖 3.2 XML 轉換模組
透過這樣的兩層式的架構，可以使得市面上的 CASE tool 都可以透用本論文 的架構，而不是限定只有那些的系統分析工具才可以使用，也讓系統設計人員可 以利用他們熟悉的系統分析工具來進行系統分析，而不需要另外去學習特定的系 統分析工具。如此可以讓本架構更具有彈性，也可以縮短系統分析需要的時程。
這個模組主要的目的，是利用 XML 的特性，將各個不同的 CASE tool 所產生 的系統分析文件，透過一個統一的介面，讓本系統進行分析的動作。透過這樣的 機制，我們可以針對目前市面上所有不同的 CASE tool 進行 XML 的定義，讓我們 的分析系統可以不被某些特定的公司的軟體所把持，更進一步的讓系統的可用性 提高。
3.3 資料庫定義轉換模組
在物件導向設計的屬性與關聯式資料庫對映的過程中，有幾個步驟是我們必 須要額外去處理的，這是因為關聯式資料庫並沒有辦法完全存放物件導向式設計
的部分特色，像是對於物件辨別碼的處理等等，所以在進行資料庫的對映時，必 需針對物件導向的特性去進行處理。這就是資料庫轉換模組最主要的功能，透過 這樣的轉換機制，讓物件導向式的系統設計，可以更有效的轉換至關聯式資料庫 儲存平台上。圖 3.3 介紹資料庫轉換模組內之詳細的內容。
圖 3.3 資料庫轉換架構圖 z OID transfer module
由於物件導向式物件辨別碼在物件導向式中是相當重要的一個特性，它是獨 一無二的數值，用以辨別物件的唯一性。這個特性也是關聯式資料庫所沒有的，
因此必須要針對這個特性進行專屬的處理 Object-relational transfer module
OID transfer module
Inheritance process module
Many to many relationship process module
One to one relationship process module
One to many relationship process module
XML to Database Schema transfer
Inheritance record
Relation record
Data index generator Data index XML
format class diagram
圖 3.3 中的 XML format class diagram 為 XML 轉換模組(參見圖 3.2)所處理之 後的 XML 文件，在此轉換模組中是主要的輸入。物件辨別碼轉換模組會把物件辨 別碼在關聯式資料庫中所需要的記錄欄位產生，以便之後物件導向中去記錄物件 辨別碼。
z Inheritance process module
繼承關係轉換模組會將物件之間的繼承關係忠實的記錄下來，並且把需要新 增的欄位進行處理。例如一個物件具有繼承的關係時，在繼承處理模組中便會先 把繼承之間的類別關係先記錄起來，再將所有父類別的欄位，新增到子類別當中，
如此便可以將繼承的關係轉換，並且不會喪失了繼承關係的維護。
z Object-relational transfer module
物件關係轉換模組會針對物件之間的關係做轉換，在處理物件之間的關係 時，我們必須先去定義物件可能會有的關係，這個部分跟關聯式資料庫的實體關 係圖有點類似，我們可以定義出一對一、多對多、一對多等等的關係，各種不同 的關係會有不同的轉換時需要注意的事項。
一對一關係最為簡單，透過新增欄位與關聯式資料庫中的外來鍵的概念 就可以完成。
一對多的關係，在物件導向關係都是相同的處理方式，需要新增一個表 格去記錄集合之物件彼此的物件辨別碼，並且在一對多的一方加入一個 群組鍵值來達成。
多對多的關係會需要額外的表格記錄物件辨別碼。除此之外，系統仍會 多產生一個記錄類別之間關係的表格，把類別之間關係給記錄下來，以 供系統在產生資料庫連接時處理。
z XML to Database transfer
XML 轉換資料庫定義模組會把經過前幾個模組所處理完畢之 XML 檔案，轉 換成為結構化查詢語言(SQL)的關聯式資料庫定義，讓使用者可以直接透過結構化 查詢語言讓資料庫系統自動將表格建立。
z Data index generator
資料索引產生模組會把類別圖中定義之屬性，與目前資料庫表格欄位的關係 整理成為一份可讀的文件，一來可以幫助系統開發人員在加速開發時的速度，另 外一方面可以使得資料庫管理員在資料有誤時可以方便查詢，並且可供以後接手 管理系統的人員參考。
透過前小節所提出之 XML 轉換模組處理之後的類別圖文件，已經是本系統中 一個標準定義的 XML 文件。接著系統會針對此一文件去進行關聯式資料庫定義的 轉換，在上個章節中已經針對物件導向式資料庫與關聯式資料庫的不同作了比 較，以下會針對轉換的流程進行說明，如圖 3.4 所示。
圖 3.4 資料庫轉換流程圖
當轉換模式接收到 XML 定義之類別圖，系統會先針對物件辨別碼(OID)的部 份進行處理，由於在物件導向式的觀念中，每一個物件都擁有一個獨一無二的辨 別碼，但是在關聯式資料庫中並沒有這樣的概念。因此必須要先針對儲存物件時 必須的物件辨別碼進行處理，以供在關聯式資料庫中儲存之用。
新增物件識別碼(OID)
是否繼承?
將父類別屬性 寫入子類別中
有 無
產生系統表格額外記錄 其關係，並以成對的鍵值 為額外表格之主鍵 有
無
有一對多關 係?
有
無
寫入對應之 OID 並以 系統表格記錄之
有一對一關
係? 對應之欄位以 OID 寫
入，並且設定為外來鍵 無
有
XML 轉換成 資料庫定義
有多對多關 係?
接下來處理物件的繼承關係，當物件具有繼承的關係時，相關繼承的特性必 須要被記錄下來，並且預留相關的欄位資料，以供給關聯式資料庫日後在進行資 料儲存時使用，當繼承架構的處理完成之後，再繼續針對物件的關係進行相關的 處理。
物件的關係當中，跟關聯式資料庫的實體關係圖(ERD)有些相似的部份，不過 仍需要另外去進行處理。在流程當中會先去檢查物件是否存在著多對多的關係。
當物件存在多對多關係時，必須要多產生一個資料表格去記錄兩個物件之間的物 件辨別碼，也就是每一筆記錄都存在著一對的物件辨別碼。
一對多的關係也需要額外的資料表格在關聯式資料庫中儲存，利用新增一個 兩個欄位的資料表，記錄物件辨別碼，這個動作與多對多的關係儲存有著類似的 作用，都需要在額外記錄成對的物件辨別碼。這部份的工作，在本架構中會先在 XML 文件中，先將資料表格之欄位定義等等進行處理。
物件一對一關係在關聯式資料庫的記錄就比較簡單了，需要在物件當中新增 一個欄位記錄另外一個物件之物件辨別碼即可。在關聯式資料庫可以透過外來鍵 的方式來達到。最後再把已經處理好關聯維護之 XML 文件，透過文字轉換的方式 把 XML 的標籤與內容，轉換成關聯式資料庫之定義碼。
3.4 類別圖轉換實例
本節舉一個簡單的例子來說明如何進行轉換。有一個簡單的類別圖，分別有 3 個類別，分別為雇員、按件計酬、月薪制，其中按件計酬與月薪制分別繼承雇 員這個父類別，如圖 3.5。
圖 3.5 類別圖實例
以 Rational Rose 所繪製的類別圖為例，本架構在輸入到類別圖時，便會把類 別圖轉換成為 XML 的記錄方式。這部分的轉換並不會處理其他物件的繼承或關 係，僅是把圖像化的類別圖轉換成為 XML 的描述方式。經過轉換之後的月薪制類 別的定義如圖 3.6。
<xml version=”1.0”>
<class_digram>
<class>
<class_name>月薪制</class_name>
<inheritance>雇員</inheritance>
<attribute>
<attribute_name>基本月薪</attribute_name>
<attribute_type>Int</attribute_type>
</attribute>
<attribute>
<attribute_name>服務部門</attribute_name>
<attribute_type>String</attribute_type>
</attribute>
<method>
<method_name>調整月薪</method_name>
</method>
</class>
…
圖 3.6 月薪制類別之原始 XML 定義
接著把這份 XML 的文件透過架構中的資料庫轉換模組來進行關聯式資料庫 欄位的定義。首先會為物件加入物件識別碼的欄位，以供資料庫儲存物件識別碼 使用。
接著尋找此類別是否有與其他物件有繼承或關係，以月薪制為例，此物件繼 承於雇員，所以本架構會把雇員內的屬性加入其中，使得繼承之屬性等資料欄位 可以順利的記錄。另外，會在系統的資料庫中，記錄該繼承架構的關係。經轉換 處理過的月薪制 XML 文件大致如圖 3.7：
<xml version=”1.0”>
<class_digram>
<class>
<class_name>月薪制</class_name>
<attribute>
<attribute_name>OID</attribute_name>
<attribute_type>String</attribute_type>
</attribute>
<attribute>
<attribute_name>姓名</attribute_name>
<attribute_type>String</attribute_type>
</attribute>
<attribute>
<attribute_name>電話</attribute_name>
<attribute_type>String</attribute_type>
</attribute>
<attribute>
<attribute_name>基本月薪</attribute_name>
<attribute_type>Int</attribute_type>
</attribute>
<attribute>
<attribute_name>服務部門</attribute_name>
<attribute_type>String</attribute_type>
</attribute>
<method>
<method_name>調整月薪<method_name>
</method>
…
圖 3.7 轉換後月薪制之 XML 定義
把物件的物件辨別碼、繼承與關係轉換完畢之後，系統利用 XML 轉換資料庫 定義模組，將 XML 文件的定義，轉換成為 SQL 的定義碼(SQL Schema)，如圖 3.8 所示：
CREATE TABLE 月薪制 ( OID VARCHAR(255) NOT NULL, 姓名 VARCHAR (255),
電話 VARCHAR (255), 基本月薪 INTEGER (255), 部門 VARCHAR(255) ,
圖 3.8 月薪制資料庫定義碼
除了利用 XML 定義檔將關聯式資料庫的定義碼產生之外，將該物件在關聯式 資料庫中的表格定義也會寫入到該份 XML 的檔案當中。結果如圖 3.9 所示：
<xml version=”1.0”>
<class_digram>
<class>
<class_name>月薪制</class_name>
<attribute>
<attribute_name>OID</attribute_name>
<attribute_type>String</attribute_type>
<DB_define>
<table_name>月薪制</table_name>
<col>OID</col>
<type>VARCHAR</type>
<limit>255</limit>
</DB_define>
</attribute>
<attribute>
<attribute_name>姓名</attribute_name>
<attribute_type>String</attribute_type>
<DB_define>
<table_name>月薪制</table_name>
<col>姓名</col>
<type>VARCHAR</type>
<limit>255</limit>
</DB_define>
</attribute>
<attribute>
<attribute_name>電話</attribute_name>
<attribute_type>String</attribute_type>
<DB_define>
<table_name>月薪制</table_name>
<col>電話</col>
<type>VARCHAR</type>
<limit>255</limit>
</DB_define>
</attribute>
<attribute>
<attribute_name>基本月薪</attribute_name>
<attribute_type>Int</attribute_type>
<DB_define>
圖 3.9 月薪制類別包含資料庫定義(部分)
透過這樣的方式，本架構提供了一個可以自動產生資料庫定義的方法，也可 以透過資料庫自動產生去減少人為設計上的錯誤；並且可以自動產生資料庫與物 件彼此之間的資料索引，讓開發人員可以很快速知道物件的詳細資料是存放在哪 一個表格與欄位當中。
在下一章節中，本架構將更進一步的提出一個讓程式開發人員可以透過物件 導向式的存取模式，去存取資料庫。並且在開發人員不需要了解 SQL 語言的前提 之下，讓開發人員也可以去存取在資料庫中的物件屬性。
第四章 物件化資料庫連接架構
本論文討論如何使用去剖析類別圖，並且透過本論文所提出的機制，自動化 將關聯式資料庫定義檔產生，同時產生了一個資料庫定義與物件類別圖對應的 XML 描述文件。透過這份文件，本架構可以更進一步將關聯式資料庫連接，提供 一個全物件導向式的方式來進行。並且透過自動產生 Java 程式碼的方式，提供程 式設計人員一個存取資料庫的物件，讓程式設計人員透過該物件之介面存取資料 庫，而非使用資料庫查詢語句進行資料的存取。
4.1 資料庫連接系統架構
以本研究的架構進行系統的開發時，為了加速整個系統的開發與維護系統的 品質，可以針對資料庫操作要求的部分讓程式碼得以自動產生，用來處理對於資 料庫的操作要求，透過由系統自動產生程式碼，來減少結構化查詢語句的維護成 本。
由於前一個章節中，已經針對物件導向式分析文件轉換成為關聯式資料庫之 定義碼，並且也將相關物件與關聯式資料庫之間的關係以 XML 描述語言的方式記 錄下來，因此本論文將可以透過前章節所產生的描述文件，進行進一步的程式碼 與資料庫存取的自動產生。
有關資料庫的存取部分，自動為每一個類別建立一個該類別的資料庫代理物 件(DB Proxy Object)，用來負責處理所有該類別之物件與資料庫相關的存取動作。
而所有的資料庫代理物件的產生，都是由系統透過資料庫代理物件產生器來進行 自動的生成，如圖 4.1。
Java programmer
Data index
Relation record
Inheritance record
Database access module
Java class generator
Database proxy object generator
JAVA class
Object access API
Database proxy object
Relational Database
圖 4.1 資料庫存取代理物件整合架構圖
圖 4.1 中的資料索引(Data index)、關係記錄(Relation record)與繼承記錄 (Inheritance record)都是在第三章中所提出的自動化資料庫定義產生模組與資料索 引模組所產生的。在這個階段系統會把它們當作是資料庫存取模組的主要輸入。
資料庫存取產生模組由兩個主要的元件構成─Java 類別產生器(Java Class Generator)與資料庫代理物件產生器(Database Proxy Object)。Java 類別產生器主要 的功能是將原先在系統分析的類別圖中所定義的類別，預先轉換成為 Java 程式碼 的定義方式，把這個部份的工作轉換成為自動產生，以加快系統開發的腳步。
