Database 版 (精华区)
作 家: baby (心月) on board 'database'
题 目: JDBC
来 源: 哈尔滨紫丁香站
日 期: Tue Jun 24 10:14:09 1997
出 处: lupy.bbs@melon.gznet.edu.cn
发信人: kaler (海子), 信区: Database
标 题: [转]jdbc (转载)
发信站: 华南木棉站 (Wed Sep 18 14:14:11 1996)
1. 介绍
许多开发者和用户都在寻找Java程序中访问数据库的便捷方
法。由于Java是一个健壮，安全，易于使用的，易于理解且可
以从网络中自动download ，所以它成为开发数据库应用的一种
良好的语言基础。它提供了C,C ,Smalltalk, BASIC, COBOL,
and 4GLs的许多优点。许多公司已经开始在Java与DBMS的连接
方面做工作。
许多Java应用开发者都希望能够编写独立于特定DBMS的程
序，而我们也相信一个独立于DBMS的接口将使得与各种各样
DBMS连接变得最为便捷，开发更加迅速。所以我们认为定义
一个通用的SQL数据库存取框架，在各种各样的提供数据库连
接模块上提供统一的界面是十分有意义的。这使程序员可以面
对单一的数据库界面，使数据库无关的Java工具和产品成为可
能，使得数据库连接的开发者可以提供各种各样的连接方案。
我们看到我们定义一个通用低层的，支持基本SQL功能的Java
DataBase 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.
l JDBC允许查询表达式直接传递到底层的数据驱动，这样一
个程序可以获得尽量多的SQL功能，但是可能被DBMS拒
绝。事实上，一个程序的查询甚至可以不是SQL的，或者
是SQL的一个特殊演化，例如：为专门数据库设计的文本
或者图形查询。
l 为了通过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语句并且处理结果。
错误! 嵌入对象无效。
最重要的接口是：
l java.sql.DriverManager 处理驱动的调入并且对产生新的
数据库连接提供支持。
l java.sql.Connection 代表对特定数据库的连接。
l java.sql.Statement 代表一个特定的容器，来对一个特定的
数据库执行SQL语句。
l 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的两种主要使用场合里面，我们必须考虑安全性
问题：
l 在Java applications的场合里面Java代码是本地的，所以也是
"trusted"
l 没有验证的Java applet代码不可以存取本地的以及其他网络
的数据。
5.1. JDBC 和未验证的applet
JDBC首先必须符合JAVA的一般安全规则。另外：
l JDBC 必须认为没有验证的applets是不可靠的。
l JDBC 不可以让不可靠的applets存取本地数据库。
l 一个已经向JDBC DriverManager注册的是JDBC Driver只能
存取它所来的数据源。
l 一个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");
I. }
---------------------------------------------------------------
P.S 本文取自CZF，在此表示感谢。
版权归CZF所有。
--
※ 来源:·哈尔滨紫丁香站 bbs1.hit.edu.cn·[FROM: lupy.bbs@melon.gznet]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间：211.392毫秒