1. 介紹
許多開發者和用戶都在尋找Java程序中訪問數據庫的便捷方法。由於Java是一個健壯，安全，易於使用的，易於理解且可以從網絡中自動download ，所以它成為開發數據庫應用的一種良好的語言基礎。它提供了C,C++,Smalltalk, BASIC, COBOL, and 4GLs的許多優點。許多公司已經開始在Java與DBMS的連接方面做工作。
許多Java應用開發者都希望能夠編寫獨立於特定DBMS的程序，而我們也相信一個獨立於DBMS的接口將使得與各種各樣DBMS連接變得最為便捷，開發更加迅速。所以我們認為定義一個通用的SQL數據庫存取框架，在各種各樣的提供數據庫連接模塊上提供統一的界面是十分有意義的。這使程序員可以面對單一的數據庫界面，使數據庫無關的Java工具和產品成為可能，使得數據庫連接的開發者可以提供各種各樣的連接方案。我們看到我們定義一個通用低層的，支持基本SQL功能的JavaDataBase Connectivity (JDBC)API的緊迫任務。
幸運的是我們不必從頭設計一個SQL API。我們可以把我們的工作建立在 X/Open SQL CLI (調用層接口)之上(它也是Microsoft's ODBC 的基礎)。
我們主要任務是定義一個自然的Java接口來與X/Open CLI中定義的基本的抽象層和概念連接。
JDBC API得到數據庫開發廠商，連接開發廠商，ISV,以及應用開發者的支持是十分重要的。我們相信把我們的工作建立在ODBC抽象層的基礎上將JDBC更加容易得到大家的接受。而且從技術上來說，ODBC是我們設計工作的一個良好基礎。
因為ODBC是一個C語言接口，所以ODBC在Java中直接使用不適當。從Java中來調用C代碼在安全性，健壯性，實現的方便，可移植性等等方面有許多不便。它使得Java在這些方面的許多優點得不到發揮。
我們已經在短期裡面實現了一個建立在ODBC上的API。長遠來看，我們可以通過其他方式提供實現。
1. 1. 注意
我們非常感謝在數據庫，數據庫連接和數據庫工具領域的許多早期的工作者。他們為JDBC的早期草案提供了很好的意見和建議。他們的工作對本規范起了不可估量的作用。
2. 目標與哲學
這個部分描述了指引這個API開發的目標以及哲學。
2. 1. SQL 級 API
我們的主要目標是為Java定義一個“調用級”(call-level)的SQL接口。著意味著我們主要的注意力集中在執行原原本本的SQL語句並且取回結果。我們預計高層的API也將被定義，這些可能將建立在基層的接口上。
這些高層接口包括象直接地、透明地把表裡面的數據影射到Java類裡面，用語法樹表示更加通用的查詢，以及Java內嵌的SQL語法。
我們希望大量的應用開發工具將使用我們的API。然而我們也希望程序員能夠使用我們的API，尤其是目前這樣在Java裡沒有任何其他手段(應該是說數據庫訪問手段)的情況下。
2. 2. 遵循SQL
數據庫系統支持各式各樣的SQL語法和語義，它們相互之間在比較高級的功能例如外部連接，內嵌過程等方面並不一致，盡管我們能夠盼望著隨時間的推移這些部分的SQL可以獲得標准化。同時我們采取這樣的態度與立場：
In fact, an application query need not even be SQL, or it may be a specialized derivative of SQL, e.g. for document or image querIEs, designed for specific DBMSs.
In order to pass JDBC compliance tests and to be called "JDBC COMPLIANT " we require that a driver support at least ANSI SQL-2 Entry Level. This gives applications that want wide portability a guaranteed least common denominator. We belIEve ANSI SQL-2 Entry Level is reasonably powerful and is reasonably widely supported today.
* JDBC允許查詢表達式直接傳遞到底層的數據驅動，這樣一個程序可以獲得盡量多的SQL功能，但是可能被DBMS拒絕。事實上，一個程序的查詢甚至可以不是SQL的，或者是SQL的一個特殊演化，例如：為專門數據庫設計的文本或者圖形查詢。
* 為了通過JDBC兼容的測試，並且能夠被稱為JDBC兼容，我們要求一個驅動至少支持ANSI SQL-2的標准。這使得那些需要廣泛移植性的程序獲得一個最小的分母(這句話的原文是：This gives applications that want wide portability a guaranteed least common denominator.)。我們相信ANSI SQL-2是足夠強大的，並且是得到足夠支持的。
2. 3. JDBC必須可以建立在現有的數據庫接口上
我們必須能夠保證 JDBC SQL API 能夠建立在普通的SQL API上，尤其是ODBC。這些要求已經對這個規范的一些部分產生了影響，尤其是對傳出參數(OUT parameter)和大數據塊的處理。
2. 4. 必須保證這個接口與Java系統的其他部分保持一致
目前對JAVA的積極回應已經十分熱烈。很大程度上是由於這個語言標准以及標准運行時庫被認為是一致，簡單和強大的。我們將盡我們所能，提供這個Java數據庫接口，這個接口將建立在Java內核現有的這種風格，並且將進一步加強它。
2. 5. 保持簡單
We would prefer to keep this base API as simple as possible, at least initially. In general we would prefer to provide a single mechanism for performing a particular task, and avoid provid-ing duplicate mechanisms. We will extend the API later if any important functionality is miss-ing.
我們將力爭使得基本的API盡量簡單，至少開始的時候是這樣的。一般來說，我們希望對實現每個特定的任務只提供一種方案，而避免提供多種方案。如果一些重要的功能遺漏了，那麼我們在晚些時候將擴充這個API。
2. 6. 盡量保持強的、靜態的類型
我們希望這個JDBC API保持盡量強的類型檢查，使得盡可能多的類型信息可以靜態地表達。著使得盡可能多的錯誤可以在編譯的時候被發現。
由於SQL本身是動態類型的，所以我們可能會在程序運行的時候遇到類型不能匹配的問題。例如：當一個程序員在希望SELECT返回一個整數，但是實際返回的是一個字符串“foo”. 但是我們依然希望程序員把他們所希望的類型在編譯的時候就能夠表達清楚，這樣我們可以做盡可能多的靜態檢查。我們也希望在必要的時候能夠支持動態類型接口（見第四章）
2. 7. 使普通任務簡化
我們希望普通的任務能夠是簡單的，而不一般的工作是可行的。
一個普通任務是指一個程序員執行一個簡單的沒有參數的SQL語句（例如:SELECT,INSERT,UPDATE,DELETE），然後(例如SELECT)處理返回的具有簡單類型的元組。一個具有傳入參數（IN parameter）的SQL語句也是普通的。
不那麼普通但是也是十分重要的情形是當程序員使用有INOUT,OUT參數的SQL語句。我們也需要支持讀寫幾兆字節對象的SQL語句，更特別一些的情形包括一個語句返回了多個結果集合。
我們希望元數據(Meatdata)的使用很少的，只是那些熟練的程序員以及開發工具才需要處理的問題。元數據存取函數以及動態類型數據存取函數在這個文檔末尾，一般的程序員可以不必關心這些章節。
2. 8. 不同的功能讓不同的方法（函數）來實現（“方法”的原文是：method，這樣翻譯是跟VB的）
一種界面設計風格是使用很少的過程，提供許多作為參數傳遞的控制標志，這樣它們可以用來影響很大一個范圍內的各種行為。來表達不同的功能。這趨向與使用很多的方法，但是每個方法都比較同意理解。
一般來說，Java內核類使用不同的方法（method）。這個步驟的主要優點是開始學習基本界面的程序員可以不必被那些與復雜功能相關的參數所困擾。我們力圖在JDBC接口上也采用相同的策略。一般來說采用不同的方法而不是采用不同的標志和多用途的方法。
3. 接口概貌
接口分為兩個層次，一個是面向程序開發人員的JDBC API。另外一個是底層的JDBC Driver API。
3. 1. JDBC API
JDBC API 被描述成為彝族抽象的Java接口，似的應用程序遠可以對某個數據庫打開連接，執行SQL語句並且處理結果。最重要的接口是：
* Java.sql.DriverManager 處理驅動的調入並且對產生新的數據庫連接提供支持。
* Java.sql.Connection 代表對特定數據庫的連接。
* Java.sql.Statement 代表一個特定的容器，來對一個特定的數據庫執行SQL語句。
* Java.sql.ResultSet 控制對一個特定語句的行數據的存取。
其中Java.sql.Statement又有兩個子類型：
1. Java.sql.PreparedStatement 用於執行預編譯的SQL語句。
2. Java.sql.CallableStatement 用於執行對一個數據庫內嵌過程的調用。
下面的章節對JDBC是如何運行的提供了更多描述，整個定義見第13章。另外第15章描述了系統如果獲取數據庫的元數據信息。
3. 2. JDBC Driver API
java.sql.Driver在第9章有完整的定義了.大部分JDBC驅動只需要完成這些JDBC API所定義的抽象類就可以了。特別地，所有的driver必須提供對java.sql.Connection, java.sql. State-ment, java.sql.Prepared－Statement, and java.sql.ResultSet的實現。如果目標DBMS提供有OUT參數的內嵌過程，那麼還必須提供java.sql.CallableStatement 接口。 每個database driver必須提供一個類：java.sql.Driver以使得系統可以由 Java.sql.DriverManager來管理。
一個顯然的driver是在ODBC之上提供對JDBC的實現，從而提供與ODBC接口的JDBC-ODBC 橋，就象前面的圖所顯示的.由於JDBC放在ODBC之後，所以實現起來簡單而且高效。
另外一個有用的驅動直接接觸數據庫無關的網絡協議。發布一個協議允許多個服務器實現的方法，例如在ODBC或者特定的DBMS上（盡管已經有了一些使用固定協議的產品，但是我們不打算對它們實現標准化。），是可取的。
4. JDBC使用場合
Before looking at specifics of the JDBC API, an understanding of typical use scenarios is help-ful. There are two common scenariOS that must be treated differently for our purposes: applets and applications.
在看JDBC API之前了解一下典型的使用場合是有幫助的。通常有兩種情形必須分別對待：applet和application.
4. 1. Applet
目前Java使用的最多的從網絡中下載的applet，它們作為web文件的一個部分。當中有數據庫存取applet和能夠使用JDBC來接觸數據庫的applet。例如，一個用戶可能下載一個顯示股票歷史價格圖的applet。這個applet通過internet來從關系數據庫中獲得股票歷史價格。
最一般的情況裡面，對applet的使用是通過不可靠的邊界的。例如從另外一個公司或者Internet上獲得這些applet。於是稱這個情況為"Internet"場合。然而applet也可能通過局域網下載。在這個情況裡面，客戶機的安全都還是一個問題。
典型的applet在幾個方面與傳統的數據庫應用程序有所不同：
1). 不可靠的applet被嚴格地限制在他們被允許執行的的操作上。特別地，不允許他們存取本地的文件，切不允許他們對任意的數據庫建立網絡連接。
2). 就標識和連接網上數據庫來說，Internet環境裡面的applet面臨新的問題。
3). 當數據庫可能與你相隔萬裡的時候，效率的考慮也有所不同了。與局域網相比，Internet上數據庫applet可能會碰到十分不同的反應時間。
4. 2. Application
Java也可以用來建立普通的應用，從而想一般的應用一樣在客戶機上使用。我們相信隨著開發工具越來越多，人們開始認識到提高程序生產效率的必要性，以及Java的其他優點，Java的這種用法將越來越流行。在這種方式裡面，Java的代碼是可以信賴的，且被允許讀寫文件打開網絡連接等等，就想其他的應用程序代碼一樣。
也許這些Java應用使用的最多的是在一個公司內部或者在Intranet上，所以不妨成為Intranet場合。例如一個公司希望利用Java及其GUI構件工具來建立他的基於合作數據模式的合作軟件。這些應用程序將存取局域網或者廣域網的數據。Java應用可以作到這些。
Java應用程序場合和Intranet場合與applet場合有諸多不同。例如標定一個數據庫最自然的方式是用一個數據庫的名字，就象"Customers" 和"Personnel"這樣。然後用戶希望系統能夠定位具體的機器，DBMS，JDBC driver，和Java應用程序。
4. 3. 其他場合
還有其他一些有趣的場合：
1). 已驗證的applet（Trusted applets）是指那些已經被Java虛擬機器認定是可以信賴的applet。他們之所以被認為是可信的是因為他們已經對上了特定的密匙，或者用戶認為從特定來源來的applet是可信的。在安全的方面上他們與應用（appliction）相同，但是其他方面（例如定位一個數據庫）與則與applet相似。
2). 與直接從Java GUI出發用客戶/服務器模式來度曲DBMS服務器不同，三層存取方式可能被使用。在這個場合裡面，Java應用程序對中間層的服務發出調用，中間層的服務在網上，它又再去調用數據庫。這些調用可能通過RPC (remote procedure call)或者ORB (object request broker )。在這兩種場合裡面，中間層最好使用一個對象變化。我們希望三層結構會變得越來越普遍，因為對於MIS管理者來說，這可以使得他們有機會在公共數據庫上顯式地定義合法操作等。同時三層結構可以提供許多效率上的好處。
目前中間層一般用C或者C++這樣的語言來完成。通過優化編譯器把把Java 字節代碼翻譯成為高效的機器代碼，中間層也可以用Java來實現。Java有許多優良特性（健壯性，安全性，多線程）可以達到中間層需要達到的目的。
5. 安全性考慮
作為網絡上的語言Java必須十分注安全性的考慮。基於上面的討論，JDBC的兩種主要使用場合裡面，我們必須考慮安全性問題：
* 在Java applications的場合裡面Java代碼是本地的，所以也是"trusted"
* 沒有驗證的Java applet代碼不可以存取本地的以及其他網絡的數據。
5. 1. JDBC 和未驗證的applet
JDBC首先必須符合Java的一般安全規則。另外：
* JDBC 必須認為沒有驗證的applets是不可靠的。
* JDBC 不可以讓不可靠的applets存取本地數據庫。
* 一個已經向JDBC DriverManager注冊的是JDBC Driver只能存取它所來的數據源。
* 一個applet也只能向它所Download來的服務器來存取數據。
如果JDBC驅動層如果完全確信對一個數據庫服務器打開連接不會引起認證或者權限問題（可能由網上隨機主機上運行的程序引起），那麼它就允許applet打開這樣的連接。數據庫服務器不通過IP地址來限制存取是相當少的，主要是為了舉例。（當心，這一段話我可能翻譯反了！！！大家看看原文。）這些限制是相當煩瑣的。不過他們與對一般applet的限制是一致的我們沒有必要放開這些限制。
5. 2. JDBC 和Java應用程序
對於一個普通的Java應用程序（例如全部用Java代碼而不是不可靠的applet ）JDBC將從本地的類路徑裡面獲得驅動，並且允許應用程序自由存取文件，遠程服務器等等。
但是和applet一樣，如果由於某些原因一個沒有驗證的sun.sql.Driver類從遠程的來源裡面獲得，那麼這個驅動只能和相同地方來的代碼配合。
5. 3. Driver的安全責任
JDBC driver可能在各種情況下使用，所以驅動的編制者遵循一定的簡單的安全規則，從而避免applet做非法的數據庫連接。
如果所有的驅動都象applet一樣從網上下載，那麼這些原則將是不必要的，因為普通的安全規則已經對它做了限制。但是驅動的編寫者必須記住一旦他們的驅動獲得成功，用戶將在本地磁盤安裝這些驅動，那麼驅動將成為Java環境中一個被信任的部分，所以必須確信它不會被來訪的applet所濫用。所以我們鼓勵所有的驅動編寫者必須遵循一定安全原則。
所有這些原則都是在連接打開的時候使用。這正式驅動和虛擬機器檢查當前調用者是否真的可以與指定的數據庫連接的時刻。一旦連接建立就不必做更多的檢查了。
5. 3. 1. 分享TCP/IP連接的時候必須謹慎 如果一個JDBC驅動試圖打開一個 TCP 連接，那麼這個打開會被Java 安全管理機制自動檢查。這個機構會檢查當前調用棧裡面有沒有applet，如果有那麼就限定它可以訪問的機器集合。所以一般地JDBC驅動可以把TCP建立檢查留給Java虛擬機。
但是如果一個JDBC驅動試圖在多個數據庫連接之間共享一個TCP連接，那麼驅動就必須自己負責檢查每個調用者是否真的被允許與目標數據庫聯系。例如如果我們為applet A打開了一個通往機器foobah 的TCP連接，這並不意味著applet B被自動允許來共享這個連接。applet B可能沒有任何訪問機器foobah的權力。所以在允許某個程序重用一個現成的TCP連接之前，JDBC 驅動必須通過安全機構來檢查當前的的調用者是否可以訪問這個連接。通過下面的代碼可是實現這個功能。
SecurityManager security = System.getSecurityManager();
if (security != null)
{
security.checkConnect(hostName, portNumber);
}
如果連接是不允許的，那麼Security.checkConnect方法將產生一個Java.lang.SecurityException。 5. 3. 2. 檢查所有的本地文件訪問
如果一個JDBC取得需要訪問本地機器上的數據，那麼他必須確信調用者是被允許打開這個文件的。例如：
SecurityManager security = System.getSecurityManager();
if (security != null)
{
security.checkRead(fileName);
}
如果對特定文件的訪問是不允許的，那麼Security.checkRead方法將產生一個Java.lang.SecurityException。
5. 3. 3. 作好最壞的准備
一些驅動可能使用本地的方法來橋接底層數據庫程序。則這些情況裡面判斷那些本地文件將被底層函數所訪問是困難的。
在這些環境裡面用戶必須作好最壞的打算，並且否決所有下載applet所發出的數據庫存取，除非驅動可能完全確信將要做存取是沒有問題的。
例如一個JDBC-ODBC橋接器必須檢查ODBC數據源的的名稱，確保applet只可以訪問它的"生源地"。如果對有的名字中不能判斷出數據源的主機名，那麼只能否決這個訪問。
為了決定一個當前的調用者是可以信賴的應用還是一個applet，JDBC驅動必須能夠檢查這個調用者是否可以寫一個隨機的文件：
SecurityManager security = System.getSecurityManager();
if (security != null)
{
security.checkWrite("foobaz");
}
