7.2 数据库访问技术访问数据库中的数据对象时,一般可采用两种访问方式:一是登录用户直接借助DBMS 的数据操纵工具,通过图形或SQL命令接口联机访问;另外一种为程序代码通过应用程序编程接口(Application Programming Interface,API)进行数据库连接验证以及数据操作。
两种数据库访问方式,可以抽象为图7.5的层次结构,从中可见中间的接口组件是数据库访问的桥梁与核心,本节主要就该部分的通用接口技术(即API访问方式)部分进行介绍。
图7.5 数据库访问结构示意根据底层数据操作模式的差异,数据库接口可简单分为:本地(Local)数据库接口和客户机/服务器(Client/Server)数据库接口。
1.本地数据库接口通过DBMS将用户数据请求转换成为简单的磁盘访问命令,并交由操作系统的文件管理系统执行;然后DBMS从文件管理系统得到数据响应并加以处理。
由于DBMS数据文件组织结构的差异,本地型DBMS只能够读取特定的数据源。
2.客户机/服务器数据库接口数据处理工作分散到工作站和服务器上处理。
工作站通过特定的数据库通信API,把数据访问请求传给相应的服务器的后端数据驱动程序。
由于不同客户机/服务器数据库管理系统通信机制的差异,异构数据库之间也难以实现透明通信互访。
因此,仅依靠特定DBMS提供的数据库访问接口难以支撑透明的、通用的异构数据库访问。
后台数据库管理系统的变更或升级,需要程序员对特定API的重新学习,以及对应用程序代码的改写;而市场上DBMS产品众多,必将进一步加大系统开发人员的学习和维护压力,应用程序与数据源间的独立性难以真正实现。
为此,建立更为通用的数据访问技术规范,为程序用户提供一套完整、统一的数据库访问接口,得到了数据库业界广泛认同与支持,并由此产生了众多成熟的数据库访问接口应用技术规范。
到目前为止,主流的数据库访问技术包括ODBC、MFC ADO、RDO、OLE DB、ADO、以及JDBC等通用技术标准。
这些通用数据库访问技术的出现与发展大大降低了数据库系统开发与维护门槛,改善了数据库系统的移植性、扩展性,极大推动了数据库技术的发展与普及。
下面就主流数据库访问技术发展与演化进行介绍。
7.2.1 ODBC开放数据库互联(Open DataBase Connectivity,ODBC)数据库访问标准是微软公司于1991年11月首次提出的,是微软开放服务结构(Windows Open Services Architecture,WOSA)下与数据库相关的组成部分。
它建立了一组数据库访问规范,并提供了一组标准API。
目前ODBC可以在众多操作系统平台上使用,包括Windows、OS/2、SunOS、Solaris、Mac OS、SCO UNIX等。
在ODBC技术规范中,应用程序并不是直接对数据库进行操作,而是通过ODBC的驱动程序间接完成数据库访问。
面向异构的数据库系统,应用程序依靠ODBC提供的统一的API进行编码,数据源变化主要涉及特定的驱动程序加载变换,从而把应用程序从特定的数据库物理操作中独立出来,解决了在异构数据库管理系统之间移植难题。
ODBC的数据访问架构如图7.6所示。
图7.6 ODBC的数据访问架构由图7.6可知,ODBC系统包括应用程序、驱动管理器、各种驱动程序与数据源等对象,不同对象在ODBC的数据库访问过程中充当不同的角色。
1.应用程序应用程序为数据库用户提供了数据交互界面,可以是Microsoft Word、Excel和Access 等内嵌了ODBC支持的应用程序,也可以是由Java、C#、Visual C++或其他程序设计语言开发的用户程序。
数据访问时,应用程序与ODBC驱动程序管理器(如ODBC32.dll)进行静态或动态链接,主要工作包括:①向数据源申请连接;②发出SQL数据访问请求;③定义数据结果结构与空间;④获取数据访问结果;⑤判断处理状态,提交处理或者回滚;⑥释放数据源连接。
2.驱动管理器驱动管理器是ODBC的一个重要组成部分,如在Windows的32位操作系统中,它包含在ODBC32.DLL动态链接库文件中。
负责处理应用程序和ODBC驱动程序之间的连接,以及在网络中有关ODBC网络库和驱动程序之间的连接的问题。
驱动管理器主要工作如下:①使用ODBC初始化文件,把数据源名称映射到特定的数据库驱动程序上;②处理ODBC服务器的初始化操作;③为驱动程序提供ODBC调用入口;④为ODBC调用进行参数和操作验证。
3.驱动程序驱动程序(Driver)是用以支持ODBC函数调用的模块。
应用程序必须通过调用驱动程序所支持的函数来对数据库进行操作。
因为驱动程序通常是一个动态链接库,所以当应用程序需要连接到不同的数据库时,就要采用动态链接的方式去连接一个或者几个驱动程序。
驱动程序主要是执行ODBC 的相关接口函数,并与对应的数据源(Data Source)直接交互。
驱动程序之工作如下:①建立与数据源的连接;②提交数据请求;③为应用程序转换数据格式;④为应用程序返回结果;⑤返回处理结果状态代码;⑥根据需要,定义游标,提交事务。
4.数据源数据源是指数据以及访问这些数据所需的各种描述信息的组合,其中数据源名是应用程序访问特定数据库的连接标识,通过它应用程序无须获取数据源其他细节信息。
同时应用系统可以同时与多个数据源进行连接。
虽然ODBC提供了一种通用的数据库访问接口标准,但是直接使用ODBC API是比较困难的。
于是出现了对ODBC API的不同版本的封装类库,这些类库对ODBC API进行了更高级别的抽象,为用户提供了更为简单的数据库处理对象,如Visual Basic、Visual C++和Delphi 等高级程序设计语言提供的类库。
MFC ODBC是微软基础类中封装的ODBC API类库,它为MFC库用户提供了高效、易用的数据库访问工具。
7.2.2 MFC DAO数据访问对象(Data Access Object,DAO)提供了通过程序代码创建和操纵数据库的体系框架,是一组面向对象的API。
它为数据库的管理与操作提供了完整的属性和方法,包括创建数据库,定义表和索引,建立表间的关系,定位和查询数据库等。
DAO 最适用于单系统应用程序或小范围分布应用。
DAO有时也称为Jet数据库引擎,是组成数据引擎内核的一组动态链接库(DLL)。
它提供了一组分层数据操作对象,支持两种数据库操作环境:①使用Microsoft的JET数据库引擎,为存取本地ISAM(Index Sequential Access Method)数据库提供了最佳手段,例如FoxPro、Paradox、Microsoft Access、Excel等;②采用ODBC的存取方法存取客户机/服务器数据库,如Oracle、Sybase和SQL Server等。
DAO应用程序访问数据库的原理如图7.7所示。
图7.7 DAO应用程序访问数据的原理与ODBC类似,MFC也提供了一组DAO类,封装了底层的DAO API,从而简化了应用程序的调用开发。
MFC的DAO类和ODBC类有很多相似之处,主要包括两点:(1)都支持对各种ODBC数据源的访问,都可以编写独立于DBMS的应用程序。
(2)提供了功能相似的类库。
例如DAO的CDaoDatabase类对应于ODBC的CDatabase 类,DAO的CDaoRecordset类对应于ODBC的CRecordset类等。
这些类所提供的程序方法也很相似。
尽管二者非常相似,但访问数据库的机制完全不同。
DAO和Jet数据库引擎一起工作,如果该数据库是一个本地的Access数据库或其他ISAM类型的数据库,那么Jet引擎加载相应的数据库驱动程序。
如果Jet正在使用远程数据库,那么该引擎加载ODBC驱动程序管理器。
这使得DAO在访问Access、FoxPro、dBase、Paradox和Excel等数据库时具有最快速、最有效的性能。
而利用ODBC调用来访问远程数据库,由于DAO与ODBC之间的调用,需要Jet引擎的中间解释参与,导致了较慢的连接速度以及额外的处理开销。
7.2.3 RDO远程数据对象(Remote Data Objects,RDO)是DAO的继承者,它提供一组类对象,通过这些类对象可协助客户/服务器程序开发。
与DAO是Jet引擎之上的对象层不同,RDO提供了一个抽象定向对象层直接与ODBC API相连接,而不需Jet引擎的中间支持,它把DAO 的易编程性和ODBC API的高性能有效地结合在一起。
RDO能够访问ODBC API提供的全部功能,为ODBC提供了更易使用的COM封装,其分类层次如图7.8所示:图7.8 RDO层次对象使用RDO访问ODBC数据源的主要步骤包括:(1)创建指定用户名和密码值的rdoEnvironment对象;(2)在引用远程数据库之前,必须先建立到数据源的rdoConnection连接对象;(3)提交数据访问请求;(4)处理RDO结果集。
虽然RDO在很好地访问Jet 或ISAM 数据库方面受到限制,而且它只能通过现存的ODBC 驱动程序来访问关系数据库。
但是,RDO 已被证明是许多SQL Server、Oracle 以及其他大型关系数据库开发者经常选用的最佳接口之一。
RDO 提供了用来访问存储过程和复杂结果集的更多和更复杂的对象、属性以及方法。
目前RDO已被后面发展起来的ADO 取代,但在某些情况下比ADO的性能更加突出。
7.2.4 OLE DB对象链接嵌入数据库(Object Linking and Embedding Database,OLE DB)是Microsoft开发的一种高性能的、基于组件对象模型的数据库技术,它是微软的一致数据访问技术框架(Uniform Data Access,UDA)的一部分。
ODBC虽然采用分层结构,为关系数据库提供了一致的数据库访问接口,但对于不同应用、不同格式的数据源,如操作系统中的文件、顺序索引文件、桌面数据库、电子邮件、目录服务、多媒体数据、空间数据等,却显得无能为力,而UDA则很好地解决这个难题。
UDA系统框架如图7.9所示。
图7.9 UDA技术架构及其OLE DB关系从中可看出,UDA包括两层软件接口:OLE DB和ADO,它们分别对应于不同的应用开发层次。
OLE DB是UDA的核心,在系统建立了数据访问的一组标准COM接口。
它是一组符合COM标准、基于对象的C++ API函数。
使用OLE DB API,可以编写能够访问符合OLE DB 标准的任何数据源的应用程序,也可以编写针对某种特定数据存储的查询处理程序和游标引擎,因此,OLE DB标准实际上是规定了数据消费者和数据提供者之间的一种应用层协议。