基本介紹
OLE 全稱 Object Link and embed,即對象連線與嵌入。
作為微軟的
組件對象模型(COM)的一種設計,OLE DB是一組讀寫數據的方法(在過去可能被稱為渠道)。OLE DB中的對象主要包括數據源對象、階段對象、命令對象和行組對象。使用OLE DB的應用程式會用到如下的請求序列: 初始化OLE 連線到數據源、發出命令、處理結果、釋放數據源對象並停止初始化OLE Object Linking and Embedding,對象連線與嵌入,簡稱OLE技術。OLE不僅是
桌面應用程式集成,而且還定義和實現了一種允許應用程式作為軟體“對象”(數據集合和運算元據的函式)彼此進行“連線”的機制,這種連線機制和協定稱為部件對象模型。
OLE 是一種
面向對象的技術,利用這種技術可開發可重複使用的
軟體組件(COM)。
DB(英文全稱data base,資料庫)是依照某種數據模型組織起來並存放二級
存儲器中的數據集合。
組成
OLE DB 最主要是由三個部分組合而成:
Data Providers 數據提供者
凡是透過OLE DB 將數據提供出來的,就是數據提供者。例如SQL Server 資料庫中的數據表,或是附檔案名稱為mdb 的Access 資料庫檔案等,都是Data Provider。
Data Consumers 數據使用者
凡是使用OLE DB 提供數據的程式或組件,都是OLE DB 的數據使用者。換句話說,凡是使用ADO 的應用程式或網頁都是OLE DB 的數據使用者。
Service Components 服務組件
數據服務組件可以執行數據提供者以及數據使用者之間數據傳遞的工作,數據使用者要向數據提供者要求數據時,是透過OLE DB 服務組件的查詢處理器執行查詢的工作,而查詢到的結果則由指針引擎來管理。
新概念
OLE DB 將傳統的
資料庫系統劃分為多個邏輯組件,這些組件之間相對獨立又相互通信。這種
組件模型中的各個部分被冠以不同的名稱:
數據提供者
(Data Provider)。提供數據存儲的
軟體組件,小到普通的文本檔案、大到主機上的複雜資料庫,或者電子郵件存儲,都是數據提供者的例子。有的文檔把這些軟體組件的開發商也稱為數據提供者。
數據服務提供者
(Data Service Provider)。位於數據提供者之上、從過去的
資料庫管理系統中分離出來、獨立運行的功能組件,例如查詢處理器和
游標引擎(Cursor Engine),這些組件使得數據提供者提供的數據以表狀數據(Tabular Data)的形式向外表示(不管真實的物理數據是如何組織和存儲的),並實現數據的查詢和修改功能。SQL Server 7.0 的查詢處理程式就是這種組件的典型例子。
業務組件(Business Component)。利用數據服務提供者、專門完成某種特定業務信息處理、可以重用的功能組件。
分散式資料庫套用系統中的中間層(Middle-Tier)就是這種組件的典型例子。
數據消費者(Data Consumer)。任何需要訪問數據的系統程式或應用程式,除了典型的資料庫應用程式之外,還包括需要訪問各種數據源的開發工具或語言。
結構設計問題
開始編寫 OLE DB 應用程式之前應考慮以下問題:
使用何種編程實現來編寫 OLE DB 應用程式?
Microsoft 提供多種庫來解決該問題:OLE DB 模板庫、OLE DB 屬性以及 OLE DB SDK 中的原始 OLE DB 接口。另外,Microsoft 還提供幫助您編寫程式的嚮導。有關這些實現的更詳細的信息,請參見 OLE DB 模板、屬性和其他實現。
是否需要編寫自己的提供程式?
大多數開發人員無需這樣。Microsoft 提供多種提供程式。無論用戶何時創建一個
數據連線,例如,當使用 ATL OLE DB 使用者嚮導向項目中添加使用者時,“數據連結屬性”對話框都將列出系統中所有被註冊的可用提供程式。如果其中一個提供程式適合於用戶自己的數據存儲和數據訪問應用程式,最簡單的辦法就是使用該提供程式。但是,如果用戶的
數據存儲不適合所提供的類別,則必須創建自己的提供程式。有關創建提供程式的信息,請參見 OLE DB 提供程式模板及其子主題。
需要為自己的使用者提供何種級別的支持?
一些使用者可能非常簡單,另一些可能非常複雜。OLE DB 對象的功能由屬性指定。使用 ATL OLE DB 使用者嚮導創建使用者或者使用資料庫提供程式嚮導創建提供程式時,嚮導將為用戶設定合適的對象屬性來提供一組標準功能。但是,如果嚮導生成的使用者類或提供程式類並不具有您需要的所有支持功能,那么您需要查閱這些類在 OLE DB 模板庫中的接口。這些接口包裝原始 OLE DB 接口,提供附加實現以使其使用起來更加簡單。
例如,如果您希望更新行集合中的數據,但在使用嚮導創建使用者時卻忘記指定該功能,則可以在創建使用者之後通過對命令對象設定 DBPROP_IRowsetChange 和 DBPROP_UPDATABILITY 屬性來指定該功能。這樣,當行集合創建之後,它將具有 IRowsetChange 接口。
您是否有使用其他數據訪問技術(ADO、ODBC 或 DAO)的舊版代碼?
由於可能有各樣各樣的技術組合(例如 ADO 組件和 OLE DB 組件一起使用、將 ODBC 代碼遷移至 OLE DB 等等),所以
Visual C++ 文檔不能涵蓋所有的情形。
區別關係
OLE DB 與ODBC 的關係
由於OLE DB 和ODBC 標準都是為了提供統一的訪問數據接口,所以曾經有人疑惑:OLE DB 是不是替代ODBC 的新標準?答案是否定的。實際上,ODBC 標準的對象是基於SQL 的數據源(SQL-Based Data Source),而OLE DB 的對象則是範圍更為廣泛的任何數據存儲。從這個意義上說,符合ODBC 標準的數據源是符合OLE DB 標準的數據存儲的子集。符合ODBC 標準的數據源要符合OLE DB 標準,還必須提供相應的OLE DB 服務程式(Service Provider),就像SQL Server 要符合ODBC 標準,必須提供SQL Server ODBC 驅動程式一樣。現在,微軟自己已經為所有的ODBC
數據源提供了一個統一的OLE DB 服務程式,叫做ODBC OLE DB Provider。
ODBC OLE DB Provider 發布之後,有人又擔心:ODBC Provider 是不是在ODBC 之上的新的層次(Layer)?如果是,那么使用OLE DB 訪問ODBC 數據源是否將影響性能?答案也是否定的。實際上,ODBC Provider 的作用,是替換ODBC Driver Manager,作為應用程式與ODBC 驅動程式之間的橋樑,理論上不會增加任何開銷。