資料庫系統開放式界面－ODBC

應用系統程式透過標準資料來 ODBC 界面與資料庫連接，因此開發過程中不需指定特定的資料庫系統，所以資料庫系統的開放性從此被建立

文/胡大雄

學電腦的人總免要做的一件事 - 寫程式。不管是在學校裡上電腦課寫作業，或者是因工作上的需要、藉著電腦來管理、統計分析，或其他相關的事情。最近幾年，我們最普遍聽得到或看得到的就是為各種不同需要而寫成的應用系統（Application）。

早在十多年前，寫程式大多採用 DBASE 或 COBOL 語言（工程上都用 PASCAL 和 FORTRAN），而且必須在大型電腦上執行。之後，由於硬體技術的提升以及電腦使用的普及，這些程式可以在不同電腦上，不同的人在開發著。但這些系統在不同的機器上用著不同的作業系統（Operating System），不同的編譯器（Complier），使它們之間有著十分不同的容貌（也許這些系統可能做相同的事情），也不能互相交互交換使用。

因此，為了克服不同區域間的差異性，開放系統的觀念出現了，也同時打破彼此間的界限。UNIX 系統就是開放式系統的一個代表者。開放系統的誕生，改變了應用系統的撰寫方式。應用系統開發者從此只需依循既有的標準來思考它想要賦予應用系統的存在方式，全心全意投入系統開發。將來系統完成後，自然可以很容易的移植在不同的機器上。

對於 MIS ( Management Information System，管理資訊系統 ) 開發者而言，不僅逐漸走向開放式資訊系統，同時也開始依賴資料庫管理系統（Database Management System）。而當面對資料庫系統時也同樣有著在開放式系統來臨前的束縛感，因為它必須在一開始就選對一個非常適合的資料庫系統，否則應用程式寫完, 想要更換資料庫系統就很困難了。可是所謂現在最適用的，卻未必是未來最好的。因此資料庫系統的開放架構，同樣面臨極大的考驗。

開放式資料庫連接界面 ODBC（Open DataBase Connectivity）為資料庫的開放架構建立了一個發展方向。ODBC建立在主從架構上，並提供一組 API（Application Programming Interface），使應用程式可以透過這一組 API 把 SQL （Structured Query Language）指令送到資料庫系統中存取資料。由於 ODBC 是一個為資料庫系統定義的標準界面，因此應用程式可以同時與多個資料庫系統連接。

在圖一中， OBDC 的架構包含了 4 個部份：

  1. 應用程式（Application）

    應用程式對外提供使用者交談界面，同時對外提供使用者交談界面，同時對內執行資料之準備工作和呼叫 ODBC 程式函數，傳送 SQL 指令以及接收資料庫系統所傳回來的結果在顯示給使用者看。簡單來說，應用程式藉 ODBC 界面執行下列主要工作：

    1. Request a connection（i.e.session） with a data source.
    2. Send SQL requests to the data source.
    3. Define storage areas and data formats for the result of SQL requests.
    4. Request results.
    5. Process errors.
    6. Request a commit or rollback of operations for transcation control.
    7. Terminate a connection a data source.

     

  2. 驅動管理員（Driver Manager ）

    驅動管理員本身在MS Windows中一個動態連接程式庫檔（ODBC.DLL）。應用程式透過驅動管理員去載入並連結資料來源的驅動程式（driver）並連接資料來源。驅動管理員主要工作如下：

    1. Uses ODBC INI file to map a data source name to a specific driver DLL.
    2. Processes server ODBC initalization calls.
    3. Provides entry points to ODBC functions for each driver.
    4. Provides parameter validation and sequence validation for ODBC calls.

    3.  

  3. 驅動程式（Driver）

    驅動程式也是一個動態連接程式庫檔，當應用程式呼叫 ODBC 函式，SQLConnect 或 SQLDriverConnect時，驅動管理員就會載入相對的驅動程式與應用程式呼應。驅動程式主要是執行 ODBC 之相對函式，並與對應之資料來源（Data Source）做溝通。驅動程式之工作如下：

    1. Establishes a connect to a data source.
    2. Submits requests to a data sources.
    3. Trnslates data to or from other formats,if requested by the application.
    4. Return results to the application.
    5. Formats errors into standard error codes and returns them to the application.
    6. Declares and manipulates cursors if necessary （invisible to the application）.
    7. Initiates transactions if the data source requires explicit transaction initiation（invisible to the app）.

     

  4. 資料來源（Data Source）

    資料來源唯一資料庫系統（DMBS）或是資料庫操作系統的一個組合。舉例來說，應用庫系統可以同時與下列兩個或其中一個資料來源連接。

    1. A DBMaker DBMS running on a Microsoft Windows NT accessed by NTaccessed by TCP/IP.
    2. A Tandem NonStop SQL DBMS running on the Guardian 90 accessed via a gateway.

應用系統程式透過標準資料來ODBC界面與源連接，因此開發過程中不需指定特定的資料庫系統，所以資料庫系統的開放性從此被建立。筆者認為在電腦系統進入開放時代之時，我們應可體會到標準的建立與系統的發展是同樣的重要。而資訊系統架構在資料庫的必要性也隨著資訊化社會的蓬勃發展而更形重要, 因此在ODBC標準日益成熟的同時，我們也同時可以感受到資料庫系統在開放架構下，更須扮演強而有力的角色。

圖一、ODBC架構圖

在上面的文章中，我們對於 ODBC 作一概觀式的介紹。同時我們也了解其中四個重要的組成份子（應用程式 Application､驅動管理員 Driver Manager､驅動程式 Driver､及資料來源 Data Source）所個別扮演的角色與任務。在此，我想有很多的讀者早已經開始利用 ODBC 來連接其應用程式和資料庫系統，藉以對資料庫系統進行資料存取之工作。筆者曾經與很多應用系統開發者在言談中提及 ODBC，許多人告訴我，用ODBC 來開發系統似乎執行效率並不好，甚至感覺相當差 ─ 為什麼會如此？我想大家很有興趣來探索一下究竟。

首先，我們先來回顧一下ODBC的系統架構，在整個架構中很清楚地說明了，當一個資料庫資料存取指令從應用系統開始發生後送到資料來源，中間必須經由驅動管理員及驅動程式。而當資料來源將相對資料取出後，又得反方向地透過驅動程式､驅動管理員才能送回給應用系統 (圖二)。所以，很顯然地我們可以認定在這個過程中，已經發生了一些必然及必要的轉換或處理交換的工作時間。也因此，我們初步可以肯定：應用系統若直接與資料來源連接，在效率上，一定比中間透過 ODBC來得好。

透過上述筆者的推論，我們可以大致瞭解影響效率的問題所在。但從市面上大多數的新一代應用系統開發工具（指提供第四代語言之開發工具，如 Boland Delphi､Power Builder､Visual Basic等）卻得知 ─ 提供 ODBC 的界面功能是一個相當重要的關鍵：因為應用系統的開發過程與其所連接的資料來源有著相當密切而不可分的關係；如果透過 ODBC 界面及標準 SQL（Structured Query Language）資料庫語言來從事應用系統的開發，那麼開發應用系統就從此可以不再受到資料來源的強力牽制。正如筆者曾提過的「應用程式獨立性 （Application Independence）」觀念一樣。

那麼，是不是當面對此「魚與熊掌」狀況時，我們就必須得在這兩者間來進行取捨呢﹖其實， 如果只憑前述之推論即斷定未來我們必須「二選一」的話，未免太過於武斷了。我想資訊技術在這方面可以有很多的突破與改進。

筆者先行在此提出二個方向來與各位讀者共同探討：

  1. 上述推論中並未探討驅動程式本身的執行效率（即其程式撰寫之演算法），及與資料來源之界面或資料轉換能力。關於此點，我們可以發現市面上有相當多的廠商為不同的資料來源撰寫驅動程式，其效率亦不相同。
  2. 若資料來源的程式界面直接改寫成 ODBC 界面（即 Native ODBC），則 ODBC 系統架構中，驅動程式與資料來源就合成一體，中間不再需要轉換或處理。既能滿足效率問題，又可達到開放性的目的。

也許 ODBC 界面的應用，對應用系統開發者而言，已經產生另一種衝擊，也同時是提供資料來源的廠商的一種新的考驗。筆者認為資訊科技在軟體系統上，標準化的工作是相當重要的。

圖二

在了解 ODBC 的架構及其執行過程之後, 接下來我們來看看到底 ODBC 的程式界面是那些，我們如何用它來完成一個程式，以及這樣的一個程式的結構長相如何。首先我們先來看看的程式界面是那些。

依據 ODBC 的規格，其界面共可分為以下九類界面函數：

  1. 連接資料來源（Connecting to a Data Source）
    1. SQLAllocEnv.
    2. SQLAllocConnect.
    3. SQLConnect.
    4. SQLPriverConnect.
    5. SQLBrowseConnect.
  2. 取得驅動程式及資料來源的相關訊息
    1. SQLDataSource.
    2. SQLGetInfo.
    3. SQLGetFunctions.
    4. SQLGetTypeInfo.
  3. 設定及取得驅動程式的選項
    1. SQLSetConnectOption.
    2. SQLGetConnectOption.
    3. SQLSetStmtOption.
    4. SQLGetStmtOption.
  4. 準備SOL指令之需求
    1. SQLAllocStmt.
    2. SQLPrepare.
    3. SQLSetParam.
    4. SQLParamOptions.
    5. SQLGetCursorName.
    6. SQLSetCursorName.
    7. SQLSetScrollOptions.
  5. 傳送及執行需求
    1. SQLExecute.
    2. SQLExecDirect.
    3. SQLNativeSql.
    4. SQLDescribeParanl.
    5. SQLNumParams.
    6. SQLParamData.
    7. SQLPutData.
  6. 取得執行結果及有關結果的訊息
    1. SQLRowCount.
    2. SQLNumResultCols.
    3. SQLDescribeCol.
    4. SQLColAttributes.
    5. SQLBindCol.
    6. SQLFetch.
    7. SQLExtendedFetch.
    8. SQLGetData.
    9. SQLSetDos.
    10. SQLMoreResults.
    11. SQLError.
  7. 取得有關資料來源系統回錄（System tables or Catalog）的訊息
    1. SQLColumnPrivileges.
    2. SQLColumns.
    3. SQLForeignkeys.
    4. SQLPrimaryKeys.
    5. SQLProcedureColumns.
    6. SQLProcedures.
    7. SQLSpecialColumns.
    8. SQLStatistics.
    9. SQLTablePrivileges.
    10. SQLTables.
  8. 結束 SQL 指令需求
    1. SQLFreeStmt.
    2. SQLCancel.
    3. SQLTransact.
  9. 結束與資料來源的連接
    1. SQLDisconnect.
    2. SQLFreeConnect.
    3. SQLFreeEnv.

以上所列之 ODBC 界面函數，我們發現全都以 SQL 為開頭。除以上述分類外，各個函數在其必要性或複雜度上， 更被規定在不同的幾個層級中 ODBC 函數的層級為核心層（Core level），第一層（Level 1），和第二層（Level 2）。

我們再來看一個很基本的應用程式步驟是如何呢？

下圖告訴我們這個答案。

圖三．ODBC程式流程

若以Ｃ語言來完成上述的基本流程如下：（程式一，二）

程式一

程式二

程式中, 我們很容易發現,在呼叫 ODBC 函數之前, 程式必須準備

  1. 輸入資緩衝記憶體（Input Buffer），
  2. 輸出資料緩衝記憶體（Output Buffer），
  3. 環境變動（Environment Handle），
  4. 連接資料來源變數（Connection Handle）和
  5. 指令變數（Statement Handle）。

看來，呼叫 ODBC 的函數是有規則可循的。雖然如此，對於一個不熟悉寫程式的人來看，它還是需要一些時間來學習的。

其實，目前市面上有所謂的應用程式開發工具或稱為第四代語言工具（4GL）。這些工具大部份都將 ODBC 視為其內定支援的對象。它們把 ODBC 包裝在所謂的資料控制物件（Data control）及資料存取控制物件（Data Access Control Object）中。所以程式開發者，只需利用這些物件就可完成使用 ODBC 的目的了。當然，使用者也不須要知道 ODBC 的函數是如何呼叫的了。

最後，與讀者們共同回顧 ODBC 的架構及其執行過程。ODBC 造就了"應用程式獨立性（Application Independency）"的特性，使應用程式不需在乎資料來源是何種資料庫系統或者純粹是個資料或文字檔案，只要相對驅動程式能完成啣接的功能，則應用程式即可達到高度的獨立性。

Copyright 2002 SYSCOM Computer Engineering Co. All rights reserved.