オープンデータベース接続

1970年代にメインフレームベースのリレーショナルデータベースが導入されたことで、データアクセス方法が多様化した。これらのシステムは一般的に、ユーザーが英語のようなコマンドを入力して出力を受け取ることができるシンプルなコマンドプロセッサと連携して動作した。最もよく知られている例は、IBMのSQLとIngresプロジェクトのQUELである。これらのシステムは、他のアプリケーションがデータに直接アクセスできる場合とできない場合があり、アクセスできる場合でも、さまざまな手法が用いられた。SQLの導入は言語の標準化という問題を解決することを目的としていたが、実装には依然として大きな違いが残っていた。

SQL言語には基本的なプログラミング機能しかなかったため、ユーザーはFortranやC言語など、別の言語で書かれたプログラム内でSQLを使用したいと考えることが多かった。これが、 SQLコードを別の言語に埋め込むことができる「埋め込みSQL」という概念につながった。例えば、のようなSQL文をC言語のソースコード内にテキストとして挿入すると、コンパイル時にカスタム形式に変換され、ライブラリ内の関数を直接呼び出して、その関数がSQLシステムに文を渡す。文から返された結果は、同様のライブラリコードを使用して、やのようなC言語のデータ形式に解釈される。SELECT * FROM citychar*char[]

組み込みSQLのアプローチにはいくつかの問題がありました。SQLのさまざまな種類と同様に、それらを使用する組み込みSQLも、プラットフォーム間だけでなく、同じプラットフォーム上の言語間でも大きく異なっていました。IBM Db2への呼び出しを可能にするシステムは、独自のSQL/DSを呼び出すシステムとは全く異なるものになります。組み込みSQLの概念におけるもう1つの重要な問題は、SQLコードはプログラムのソースコードでしか変更できないため、クエリのわずかな変更でさえ、プログラマーが修正するためにかなりの労力を要したことです。SQL市場ではこれを静的SQLと呼び、ほぼすべてのSQLシステムに付属するコマンドラインインターフェイスや、呼び出されるまでSQLをプレーンテキストのままにしておくプログラミングインターフェイスのように、いつでも変更できる動的SQLと対比しました。動的SQLシステムは、1980年代にSQLベンダーの主要な焦点となりました。

旧式のメインフレームデータベース、およびそれを基にした新しいマイクロコンピュータベースのシステムでは、一般的にユーザーとデータベースエンジンの間にSQLのようなコマンドプロセッサは存在しませんでした。代わりに、データはプログラムによって直接アクセスされていました。大規模なメインフレームシステムの場合はプログラミングライブラリ、dBASEや類似のアプリケーションの場合はコマンドラインインターフェースまたは対話型フォームシステムです。dBASEのデータは、一般的にマシン上で実行されている他のプログラムから直接アクセスすることはできませんでした。これらのプログラムには、ライブラリなどを介してこのデータにアクセスする方法が提供される場合もありましたが、他のデータベースエンジン、あるいは同じエンジン内の異なるデータベース間でも動作しませんでした。事実上、これらのシステムはすべて静的であり、大きな問題を引き起こしていました。

1980年代半ばまでに、マイクロコンピュータの急速な進歩、特にグラフィカルユーザーインターフェースやLotus 1-2-3のようなデータ豊富なアプリケーションプログラムの導入により、クライアント/サーバコンピューティングにおいてパーソナルコンピュータをクライアント側のプラットフォームとして利用することへの関心が高まった。このモデルでは、大型のメインフレームやミニコンピュータは、主にローカルエリアネットワーク経由でマイクロコンピュータにデータを提供し、マイクロコンピュータがそのデータを解釈、表示、操作するために使用される。このモデルが機能するためには、データアクセス標準が必要だった。メインフレームの分野では、店舗内のすべてのコンピュータが1つのベンダー製である可能性が高く、クライアントはコンピュータ端末で、それらと直接通信していたが、マイクロコンピュータの分野ではそのような標準化はなく、どのクライアントでもどのネットワークシステムを使用してどのサーバにもアクセスできた。

1980年代後半には、この目的のために抽象化レイヤーを提供する取り組みがいくつか行われていた。これらの中にはメインフレーム関連のものもあり、それらのマシン上で動作するプログラムがさまざまなSQLを相互に変換し、他のメインフレームやマイクロコンピュータのプログラムから呼び出せる単一の共通インターフェースを提供することを目的としていた。こうしたソリューションには、IBMの分散リレーショナルデータベースアーキテクチャ（DRDA）やApple Computerのデータアクセス言語などがあった。しかし、より一般的だったのは、必要なネットワーク機能やファイル変換サポートを含む完全なプロトコルスタックを備え、マイクロコンピュータ上で完全に動作するシステムだった。

このようなシステムの初期の例の 1 つは、 Lotus DevelopmentのDataLensで、当初は Blueprint と呼ばれていました。1-2-3 用に開発された Blueprint は、SQL/DS、DB2、FOCUS、および同様のさまざまなメインフレーム システム、dBaseなどのマイクロ コンピュータ システム、そして最終的にMicrosoft SQL Serverに発展する初期の Microsoft/Ashton-Tate の取り組みなど、さまざまなデータ ソースをサポートしていました。^{[ 1 ]}後の ODBC とは異なり、Blueprint は純粋にコード ベースのシステムであり、SQL のようなコマンド 言語に似たものは何もありませんでした。代わりに、プログラマはデータ構造を使用してクエリ情報を格納し、これらの構造を多数リンクしてクエリを構築しました。Lotus はこれらの複合構造をクエリ ツリーと呼んでいました。^{[ 2 ]}

ほぼ同時期に、Sybase (Tom Haggin)、Tandem Computers ( Jim Grayと Rao Yendluri)、Microsoft (Kyle Geiger) のメンバーを含む業界チームが、標準化された動的 SQL の概念に取り組んでいました。システムの大部分は Sybase の DB-Library システムをベースにしており、Sybase 固有のセクションが削除され、他のプラットフォームをサポートするためにいくつかの追加が行われました。^{[ 3 ]} DB-Library は、特定の言語に密接にリンクされたライブラリ システムから、オペレーティングシステムによって提供され、そのプラットフォーム上の言語がその標準に準拠する必要があるライブラリ システムへの業界全体の移行によって促進されました。これは、単一のライブラリを特定のプラットフォーム上の (潜在的に) 任意のプログラミング言語で使用できることを意味します。

Microsoft Data Access APIの最初のドラフトは、Lotus が Blueprint を発表したのとほぼ同時期の 1989 年 4 月に公開されました。^{[ 4 ]} Blueprint は MSDA がまだ紙のプロジェクトだった頃に稼働していたため、大きくリードしていましたが、SQL が事実上のデータベース標準になることが明らかになったため、Lotus は最終的に MSDA の取り組みに参加しました。^{[ 2 ]}業界からの多大な意見を取り入れた後、1989 年の夏に標準はSQL Connectivity ( SQLC ) となりました。^{[ 5 ]}

1988 年、主にUnixおよびデータベース コミュニティのベンダー数社が SQL 言語の単一の基本標準を作成するためにSQL Access Group (SAG) を結成しました。最初の会議では、SQL 言語自体のみに取り組むべきか、それともコール レベル インターフェイス( CLI) と呼ばれる動的な SQL 言語埋め込みシステムも含むより広範な標準化を試みるべきかについて、かなりの議論がありました。^{[ 6 ]}当時 MS Data Access として知られていたものの初期ドラフトを持って会議に出席していた Microsoft の Kyle Geiger は、Digital Equipment Corporation (DEC) の Jeff Balboni と Larry Barnes を SQLC 会議にも招待しました。SQLC は、DEC が主導していた CLI の要求に対する潜在的な解決策でした。

新しい SQLC の「4人組」、MS、Tandem、DEC、Sybase は、1990 年 6 月に開催された次の SAG 会議に SQLC の更新版を持ち込んだ。^{[ 7 ]} SAG は、標準化の取り組みを競合する設計に開放することで対応したが、多くの提案の中で、真剣な競争相手となるシステムを持っていたのはOracle Corpだけだった。最終的に、SQLC が投票で勝ち、ドラフト標準となったが、API の大部分が削除された後だった。この間に標準文書は 120 ページから 50 ページまで削減された。また、この時期に Call Level Interface という名前が正式に採用された。^{[ 7 ]} 1995 年に SQL/CLI は国際 SQL 標準 ISO/IEC 9075-3 の一部となった。^{[ 8 ]} SAG 自体は1996 年にX/Openグループに引き継がれ、時を経てThe Open GroupのCommon Application Environmentの一部となった。

MS はオリジナルの SQLC 標準での開発を続け、CLI バージョンから削除された多くの高度な機能を維持しました。これには、スクロール可能なカーソルやメタデータ情報クエリなどの機能が含まれていました。API のコマンドはグループに分けられ、コア グループは CLI と同一で、レベル 1 拡張機能はドライバに簡単に実装できるコマンド、レベル 2 コマンドにはカーソルなどのより高度な機能が含まれていました。1991 年 12 月に標準案が発表され、1992 年にかけて業界からの意見が収集され、システムに反映され、その結果、ODBCという名称に再び変更されました。^{[ 9 ]}

この時期、マイクロソフトはJetデータベースシステムの開発を進めていました。Jetは主に3つのサブシステムで構成されていました。ISAMベースのデータベースエンジン（これも紛らわしいことにJetという名前でした）、アプリケーションがそのデータにアクセスできるようにするCベースのインターフェース、そして同じCインターフェースからParadoxやxBaseなどの他のISAMベースのデータベースに入出力をリダイレクトできるようにするドライバダイナミックリンクライブラリ（DLL）です。Jetは、Blueprint（当時はDataLensと改名されていました）と同様の方法で、1つの呼び出しセットを使用して一般的なマイクロコンピュータデータベースにアクセスできるようにしました。ただし、JetはSQLを使用しませんでした。DataLensと同様に、インターフェースはC言語で記述され、データ構造と関数呼び出しで構成されていました。

SAG の標準化の取り組みは、Microsoft が Jet システムを新しい CLI 標準に適合させる機会を提供しました。これにより、Windows は CLI 開発の主要プラットフォームになるだけでなく、ユーザーは SQL を使用して Jet や他のデータベースにもアクセスできるようになります。不足していたのは、これらの呼び出しをテキスト形式から Jet で使用される C インターフェースに変換できる SQL パーサーでした。この問題を解決するために、MS はPageAhead Softwareと提携し、既存のクエリ プロセッサである SIMBA を使用しました。SIMBA は Jet の C ライブラリの上位のパーサーとして使用され、Jet を SQL データベースに変えました。また、Jet はこれらの C ベースの呼び出しを他のデータベースに転送できるため、SIMBA は他のシステムにクエリを実行することもできました。Microsoft は Excel 用のドライバを含め、スプレッドシート ドキュメントを SQL でアクセス可能なデータベース テーブルに変換しました。^{[ 10 ]}

ODBC 1.0 は 1992 年 9 月にリリースされました。^{[ 11 ]}当時、SQL データベース (ISAM と比較して) の直接的なサポートはほとんどなく、初期のドライバはパフォーマンスが低いことで知られていました。これは、呼び出しが Jet ベースのスタックを通過する経路のため、ある程度避けられないものでした。SQL データベースへの ODBC 呼び出しは、まずSimba Technologiesの SQL 方言から Jet の内部 C ベースの形式に変換され、次にドライバに渡されて、データベースの SQL 呼び出しに再度変換されました。Digital EquipmentとOracle はどちらもSimba Technologiesに自社のデータベース用のドライバの開発を委託しました。^{[ 12 ]}

1993 年頃、OpenLink Software はPROGRESS DBMS用の、独自に開発された最初のサードパーティ ODBC ドライバの 1 つを出荷し^{[ 13 ]}、その後すぐに、UDBC (ODBC および SAG/CLI のクロスプラットフォーム API 相当) SDK と、PROGRESS 、Sybase、Oracle、およびその他の DBMS 用の関連ドライバを、Unix 系 OS ( AIX、HP-UX、Solaris、Linuxなど)、VMS、Windows NT、OS/2、およびその他の OSで使用できるように出荷しました^{[ 14 ] 。}

一方、CLI 標準化の取り組みは長引き、決定版が完成したのは 1995 年 3 月になってからだった。その頃には、マイクロソフトはすでにVisigenic Software に非 Windows プラットフォームでの ODBC 開発のためのソース コード ライセンスを付与していた。Visigenic は ODBC を従来の Mac OS やさまざまな Unix プラットフォームに移植し、ODBCはすぐに事実上の標準となった。^{[ 15 ]}今日では「真の」CLI は稀である。2 つのシステムは依然として類似しており、多くのアプリケーションはほとんど変更せずに ODBC から CLI に移植できる。^{[ 16 ]}

時が経つにつれ、データベースベンダーがドライバインターフェースを引き継ぎ、自社製品への直接リンクを提供するようになった。Jetや同様のラッパーとの中間変換を省略することで、多くの場合、パフォーマンスが向上した。しかし、その頃にはマイクロソフトはOLE DB ^{[ 17 ]}コンセプト（最近復活^{[ 18 ]} ）に重点を移しており、アドレス帳からテキストファイルまで、より幅広いデータソースへの直接アクセスが可能になっていた。その後、 ActiveX Data Objects（ADO）やADO.netなど、ODBCからさらに離れた新しいシステムがいくつか登場したが、これらはライフサイクルを通じて多かれ少なかれODBCと連携していた。

Microsoft が ODBC の直接的な開発から注意をそらすと、Unix 分野では ODBC がますます普及していきました。これは、市場における 2 つの変化によって促進されました。1 つは、GNOMEのようなグラフィカル ユーザー インターフェイス(GUI)の導入により、これらのソースにテキスト以外の形式でアクセスする必要性が生じたことです。もう 1 つは、当初は Unix 上でPostgreSQLやMySQLのようなオープン ソフトウェアデータベース システムが登場したことです。その後、Apple がMac OS X 10.2 (Jaguar) ^{[ 19 ]}で標準の Unix 側iODBCパッケージ(OpenLink Software が 2001 年以来 Mac OS X 10.0 や Mac OS 9 向けに独自に提供していたもの^{[ 20 ]} ) を使用するために ODBC を採用したことで、クロス プラットフォーム データ アクセスの標準としての ODBC の地位がさらに確固たるものになりました。

サン・マイクロシステムズは、 ODBCシステムを基盤として独自のオープン標準であるJava Database Connectivity （JDBC）を開発しました。JDBCは、多くの場合、 C言語ではなくJava言語用のODBCバージョンと考えることができます。JDBC-to-ODBCブリッジを使用すると、Javaベースのプログラムが、ネイティブJDBCドライバを持たないプラットフォーム上でODBCドライバを介してデータソースにアクセスできるようになります（ただし、現在ではそのようなプラットフォームは比較的まれです）。逆に、ODBC-to-JDBCブリッジを使用すると、Cベースのプログラムが、適切なODBCドライバを持たないプラットフォームまたはデータベース上でJDBCドライバを介してデータソースにアクセスできるようになります。

ODBC は今日でも広く使用されており、ほとんどのプラットフォームとほとんどのデータベース用のドライバが利用可能です。SQLite のように組み込みを目的としたデータベース エンジン用の ODBC ドライバは、既存のツールをテストやデバッグ用のフロントエンドとして機能させる方法として、よく見られます。^{[ 21 ]}

近年、ODBCはSalesforce、Google BigQuery、SnowflakeといったクラウドベースのデータソースやSaaSプラットフォームへの接続にも採用されています。Windows、macOS、Linuxに対応したクロスプラットフォームドライバが利用可能になったことで、Power BI、Tableau、RStudioなどの最新の分析ツールやビジネスインテリジェンスツールとの統合が可能になりました。これにより、ODBCの活用範囲は従来のリレーショナルデータベースにとどまらず、クラウドデータウェアハウスやデータサイエンスのワークフローへと広がっています。

ODBCはデバイスドライバモデルに基づいており、ドライバは標準的なコマンドと関数を、基盤となるシステムが必要とする特定の呼び出しに変換するために必要なロジックをカプセル化します。たとえば、プリンタドライバは、印刷システムを使用するアプリケーションに、標準的な印刷コマンドのセット（API）を提供します。これらのAPIへの呼び出しは、ドライバによって、 PostScriptやPCLなどの実際のハードウェアで使用される形式に変換されます。

ODBCの場合、ドライバは多くの機能をカプセル化しており、それらはいくつかの大まかなカテゴリに分類できます。1つの機能群は、ドライバが通信するDBMSの検索、接続、および切断を主な業務としています。2つ目の機能群は、ODBCシステムからDBMSにSQLコマンドを送信し、内部でサポートされていないコマンドを変換または解釈するために使用されます。たとえば、カーソルをサポートしていないDBMSは、ドライバでこの機能をエミュレートできます。最後に、主に内部で使用される別のコマンド群は、DBMSの内部フォーマットから、C言語フォーマットに基づいた標準化されたODBCフォーマットにデータを変換するために使用されます。

ODBC ドライバを使用すると、ODBC 準拠のアプリケーションがデータ ソース (通常は DBMS) を使用できるようになります。CSVファイルなどのデータ ソース用に、ドライバ自体に小さな DBMS を実装することで、DBMS 以外のドライバも存在します。Oracle、PostgreSQL、MySQL、Microsoft SQL Server (Compact または CE エディションには対応していません)、Mimer SQL、Sybase ASE、SAP HANA [ 28 ][ 29 ]、IBM Db2 など、ほとんどの DBMS 用のODBCドライバが存在します。テクノロジーによって機能が異なるため^{、ほとんどのODBCドライバは}ODBC標準で定義されているすべての機能を実装しているわけではありません。一部のドライバは、標準で定義されていない追加機能を提供しています。

デバイスドライバは通常、別のマネージャ層によって列挙、設定、管理され、この層は追加機能を提供する場合があります。例えば、印刷システムには、ドライバの上にスプーリング機能を提供する機能が含まれていることが多く、サポートされているあらゆるプリンタの印刷スプーリングが可能になります。

ODBCでは、ドライバマネージャ（DM）がこれらの機能を提供します。^{[ 30 ]} DMはインストールされているドライバを列挙し、多くの場合GUIベースの形式でリストとして表示できます。

しかし、ODBCシステムの動作においてより重要なのは、データマネージャ（DM ）におけるデータソース名（DSN）の概念です。DSNは、DBMS自体ではなく、特定のデータソースに接続するために必要な追加情報を収集します。例えば、同じMySQLドライバを使用して任意のMySQLサーバーに接続できますが、ローカルのプライベートサーバーに接続するための接続情報は、インターネット上でホストされているパブリックサーバーに接続するために必要な情報とは異なります。DSNはこの情報を標準化された形式で保存し、DMは接続要求時にこの情報をドライバに提供します。DMには、人間が読みやすい名前でDSNのリストを表示し、実行時にそれらを選択して異なるリソースに接続する機能も備わっています。

DMには、部分的に完成したDSNを保存する機能も含まれており、実行時に不足している情報をユーザーに尋ねるコードとロジックが組み込まれています。たとえば、パスワードを必須とせずにDSNを作成できます。ODBCアプリケーションがこのDSNを使用してDBMSに接続しようとすると、システムは一時停止し、続行する前にユーザーにパスワードの入力を求めます。これにより、アプリケーション開発者はこのようなコードを作成する必要がなくなり、また、どのような質問をすべきかを把握する必要もなくなります。これらすべては、ドライバとDSNに含まれています。

ODBC-JDBCブリッジは、JDBCドライバのサービスを利用してデータベースに接続するODBCドライバで構成されます。このドライバは、ODBC関数呼び出しをJDBCメソッド呼び出しに変換します。プログラマは通常、特定のデータベース用のODBCドライバがないものの、JDBCドライバが利用できる場合に、このようなブリッジを使用します。例：OpenLink ODBC-JDBC Bridge、SequeLink ODBC-JDBC Bridge。

JDBC-ODBCブリッジは、ODBCドライバを使用してターゲットデータベースに接続するJDBCドライバで構成されます。このドライバは、JDBCメソッド呼び出しをODBC関数呼び出しに変換します。プログラマは通常、特定のデータベースにJDBCドライバがないものの、ODBCドライバを介してアクセスできる場合に、このようなブリッジを使用します。Sun MicrosystemsはJVMにこのようなブリッジを組み込んでいましたが、JDBCドライバがほとんど存在しない間の暫定的な措置とみなしていました（組み込みのJDBC-ODBCブリッジはJava 8でJVMから削除されました^{[ 31 ]}）。Sunは、このブリッジを本番環境での使用を想定しておらず、一般的には使用を推奨していませんでした。2008年現在独立系のデータアクセスベンダーは、両方のメカニズムの最新標準をサポートし、JVMに組み込まれているものよりもはるかに優れたパフォーマンスを発揮するJDBC-ODBCブリッジを提供しています。例：OpenLink JDBC-ODBC Bridge、SequeLink JDBC-ODBC Bridge、ZappySys JDBC-ODBC Bridge。

OLE DB-ODBC ブリッジは、ODBC ドライバのサービスを利用してターゲット データベースに接続するOLE DBプロバイダで構成されます。このプロバイダは、OLE DBメソッド呼び出しを ODBC 関数呼び出しに変換します。プログラマは通常、特定のデータベースに OLE DB プロバイダがないものの、ODBC ドライバ経由でアクセスできる場合に、このようなブリッジを使用します。Microsoft は、他のデータベース ドライバとともに、 MDACシステム コンポーネント バンドルの一部として MSDASQL.DLL を同梱しており、COM 対応言語 ( Visual Basicなど) での開発を簡素化しています。サードパーティも同様のブリッジを開発しており、特に OpenLink Software は、Microsoft が 64 ビット OS 向けにこのブリッジを非推奨にした際に、そのギャップを埋める 64 ビット OLE DB プロバイダ (ODBC データ ソース用) を提供しています。^{[ 32 ]} (Microsoft は後に譲歩し、 Windows Server 2008およびWindows Vista SP1 以降の 64 ビット Windows には64 ビット版の MSDASQL が同梱されるようになりました。) 例: OpenLink OLEDB-ODBC Bridge (2017 年 3 月 27 日にWayback Machineにアーカイブ)、SequeLink OLEDB-ODBC Bridge。

ADO.NET-ODBC ブリッジは、ODBC ドライバのサービスを利用してターゲット データベースに接続するADO.NET プロバイダで構成されます。このプロバイダは、ADO.NETメソッド呼び出しを ODBC 関数呼び出しに変換します。プログラマは通常、特定のデータベースに ADO.NET プロバイダがないものの、ODBC ドライバ経由でアクセスできる場合に、このようなブリッジを使用します。Microsoft は、C#での開発を簡素化するために、他のデータベース ドライバとともに、MDACシステム コンポーネント バンドルの一部としてこのブリッジを提供しています。サードパーティも同様のブリッジを開発しています。例: OpenLink ADO.NET-ODBC Bridge、SequeLink ADO.NET-ODBC Bridge。