Open Database Connectivity (オープン データベース コネクティビティ)

By admin on

ODBCEdit以前

1970年代にメインフレームベースのリレーショナル データベースが導入されたことで、データ アクセス方法が急増しました。 一般的に、これらのシステムは、ユーザーが英語のようなコマンドを入力し、出力を受け取ることができる単純なコマンド プロセッサとともに動作します。 IBMのSQLやIngresプロジェクトのQUELなどがよく知られています。 これらのシステムでは、他のアプリケーションがデータに直接アクセスできる場合とできない場合があり、アクセスできる場合は様々な方法論が用いられています。

SQL言語には初歩的なプログラミング機能しかなかったため、ユーザーはFortranやCなどの他の言語で書かれたプログラムの中でSQLを使いたいと思うことがよくありました。 例えば、SELECT * FROM cityのようなSQL文をC言語のソースコードにテキストとして挿入すると、コンパイル時にカスタムフォーマットに変換され、SQLシステムに文を渡すライブラリ内の関数を直接呼び出すことができました。 ステートメントから返された結果は、同様のライブラリ コードを使用して char * のような C データ形式に解釈されます。 様々な種類の SQL のように、それらを使用した埋め込み SQL は、プラットフォームごとに大きく異なり、また、一つのプラットフォーム上の言語間でさえも異なります。 組み込みSQLのコンセプトのもう一つの重要な問題点は、SQLコードはプログラムのソースコードの中でしか変更できないため、クエリの小さな変更でもプログラマが修正するのに多大な労力を必要とすることでした。 SQL市場ではこれを静的SQLと呼んでいましたが、ほとんど全てのSQLシステムに同梱されているコマンドラインインターフェースや、SQLを呼び出すまでプレーンテキストのままにしておくプログラミングインターフェースのように、いつでも変更可能な動的SQLとは異なります。

古いメインフレームのデータベースや、それをベースにした新しいマイクロコンピュータベースのシステムでは、一般的にユーザーとデータベースエンジンの間にSQLのようなコマンドプロセッサがありませんでした。 代わりに、データはプログラムによって直接アクセスされていました。大規模なメインフレームシステムの場合はプログラミングライブラリ、dBASEや同様のアプリケーションの場合はコマンドラインインターフェースや対話型フォームシステムです。 dBASEからのデータは、通常、マシン上で動作する他のプログラムから直接アクセスすることはできませんでした。 それらのプログラムにはデータにアクセスする方法が与えられているかもしれませんが、多くの場合、ライブラリを介して、他のデータベースエンジンや、同じエンジン内の異なるデータベースでさえも動作しません。

初期の取り組み

1980年代半ばになると、マイクロコンピューターが急速に進歩し、特にグラフィカル ユーザー インターフェイスや Lotus 1-2-3 のようなデータ量の多いアプリケーション プログラムが導入されたことで、クライアント サーバー コンピューティングのクライアント側プラットフォームとしてパーソナル コンピューターを使用することへの関心が高まりました。 このモデルでは、大型のメインフレームやミニコンピュータは、主にローカルエリアネットワークを介して、データを解釈、表示、操作するマイクロコンピュータにデータを提供するために使用されます。

1980年代後半には、この目的のために抽象化レイヤーを提供するいくつかの取り組みが行われていました。 これらの中には、メインフレーム関連のものもあり、メインフレーム上で動作するプログラムがさまざまなSQLを翻訳し、他のメインフレームやマイクロコンピュータのプログラムから呼び出すことができる単一の共通インターフェースを提供できるように設計されていました。 これらのソリューションには、IBMのDistributed Relational Database Architecture（DRDA）やApple ComputerのData Access Languageなどがあります。

このようなシステムの初期の例の 1 つは、Lotus Development 社の DataLens で、当初は Blueprint として知られていました。 1-2-3 用に開発された Blueprint は、SQL/DS、DB2、FOCUS、およびさまざまな類似のメインフレーム システム、dBase などのマイクロコンピュータ システム、および初期の Microsoft/Ashton-Tate の取り組み (後に Microsoft SQL Server に発展) など、さまざまなデータ ソースをサポートしていました。 後のODBCとは異なり、Blueprintは純粋にコードベースのシステムで、SQLのようなコマンド言語に近いものはありませんでした。 代わりに、プログラマーはデータ構造を使用してクエリ情報を保存し、これらの構造を多数リンクしてクエリを構築しました。

同時期に、Sybase (Tom Haggin)、Tandem Computers (Jim Gray & Rao Yendluri)、Microsoft (Kyle G)のメンバーを含む業界チームが、標準化されたダイナミック SQL のコンセプトに取り組んでいました。 システムの多くはSybaseのDB-Libraryシステムをベースに、Sybase特有の部分を削除し、他のプラットフォームをサポートするためにいくつか追加しました。 DB-Libraryは、特定の言語と密接に結びついたライブラリシステムから、オペレーティングシステムによって提供され、そのプラットフォーム上の言語がその標準に準拠することを要求するライブラリシステムへと、業界全体が移行したことに助けられた。

Microsoft Data Access API の最初のドラフトは、ロータスがブループリントを発表したのとほぼ同時期の 1989 年 4 月に公開されました。 MSDA がまだペーパー プロジェクトだった頃に実行されていたブループリントの大きなリードにもかかわらず、SQL が事実上のデータベース標準になることが明らかになったため、ロータスは最終的に MSDA の取り組みに参加しました。

SAG と CLIEdit

1988 年に、主に Unix とデータベースのコミュニティから数社のベンダーが SQL Access Group (SAG) を結成し、SQL 言語のための単一の基本規格を作成しようとしました。 最初の会議では、この取り組みがSQL言語そのものだけを対象とすべきか、それとも、動的なSQL言語埋め込みシステムも含めた、より広範な標準化を試みるべきかについて、かなりの議論が交わされました。 当時まだMS Data Accessとして知られていた初期のドラフトを持って会議に参加していたMicrosoft社のKyle Geiger氏は、Digital Equipment Corporation（DEC）社のJeff Balboni氏とLarry Barnes氏をSQLCの会議にも招待しました。

MS、Tandem、DEC、Sybase の新しい SQLC の「4 人組」は、1990 年 6 月の次の SAG 会議に SQLC の更新版を持ち込みました。 SAGはこれを受けて、標準作業を競合するデザインに開放しましたが、多くの提案の中で、Oracle Corp.だけが本格的な競合となるシステムを持っていました。 最終的には、SQLCが票を獲得して規格案となりましたが、それはAPIの大部分が削除された後のことで、規格書はこの時期に120ページから50ページにまで削減されました。 コールレベルインターフェースという名前が正式に採用されたのもこの時期でした。 1995年、SQL/CLIは、国際的なSQL標準であるISO/IEC 9075-3の一部となりました。

MSはオリジナルのSQLC規格で作業を続け、CLIバージョンから削除された高度な機能の多くを保持しました。 これには、スクロール可能なカーソルやメタデータ情報のクエリなどの機能が含まれます。 APIのコマンドはグループに分けられ、コアグループはCLIと同じで、レベル1拡張はドライバーに実装しやすいコマンド、レベル2コマンドはカーソルのようなより高度な機能を含んでいました。

JET と ODBCEdit

この時期、Microsoft は Jet データベース システムの開発を進めていました。 すなわち、ISAM ベースのデータベース エンジン (紛らわしいことに Jet という名前も付いていました)、アプリケーションがデータにアクセスできるようにする C ベースのインターフェイス、および同じ C インターフェイスで Paradox や xBase などの他の ISAM ベースのデータベースに入力と出力をリダイレクトできるようにするドライバー ダイナミック リンク ライブラリ (DLL) です。 Jet は、当時 DataLens と改名された Blueprint に似た方法で、1 つのコールセットを使用して一般的なマイクロコンピュータデータベースにアクセスすることができます。

SAG の標準化活動は、Microsoft にとって、Jet システムを新しい CLI 標準に適合させる機会となりました。 これにより、Windows が CLI 開発の最高のプラットフォームになるだけでなく、ユーザーが SQL を使用して Jet と他のデータベースの両方にアクセスできるようになります。 欠けていたのは、これらの呼び出しをテキスト形式から Jet で使用される C インターフェイスに変換できる SQL パーサーでした。 この問題を解決するために、MSはPageAhead Software社と提携し、同社の既存のクエリプロセッサであるSIMBAを使用することにしました。 SIMBAは、JetのCライブラリの上のパーサーとして使用され、JetをSQLデータベースに変えました。 また、JetはCベースの呼び出しを他のデータベースに転送することができるため、SIMBAは他のシステムに問い合わせをすることもできました。

リリースと継続的な開発

ODBC 1.0 は 1992 年 9 月にリリースされました。 当時、SQL データベースに対する直接的なサポートはほとんどなく (ISAM に対して)、初期のドライバーはパフォーマンスが低いことが指摘されていました。 これは、SQLデータベースへのODBCコールが、Simba Technologies社のSQL dialectからジェットの内部Cベースのフォーマットに変換された後、ドライバーに渡され、データベースのSQLコールに変換されるという、ジェットベースのスタックを経由する経路のために避けられなかったものです。

一方で、CLI標準の取り組みは長引き、最終版が完成したのは1995年3月のことでした。

一方、CLI規格の策定は長引き、最終版が完成したのは1995年3月のことでした。 Visigenic社はODBCをさまざまなUnixプラットフォームに移植し、ODBCはすぐに事実上の標準となった。 “本物 “のCLIは今日では珍しい。

やがて、データベース ベンダーがドライバー インターフェイスを引き継ぎ、自社製品への直接リンクを提供するようになりました。 Jet や類似のラッパーとの間の中間的な変換をスキップすることで、しばしば高いパフォーマンスが得られました。 しかし、その頃、マイクロソフトはOLE DBのコンセプトに焦点を当てていました（最近、復活しました）。OLE DBは、住所録からテキストファイルまで、より多様なデータソースに直接アクセスできます。 その後、ActiveX Data Objects (ADO) や ADO.net など、ODBC からさらに目をそらした新しいシステムがいくつか登場しましたが、これらのシステムは生涯にわたって ODBC と多かれ少なかれ相互に作用しました。

Microsoft が ODBC への直接の取り組みから目をそらしている間に、Unix 分野はますます ODBC を受け入れていました。 それは、GNOME のようなグラフィカル ユーザー インターフェイス (GUI) が導入され、これらのソースにテキスト以外の形式でアクセスする必要性が生じたことと、PostgreSQL や MySQL のようなオープン ソフトウェア データベース システムが、当初は Unix の下で登場したことです。

Sun Microsystemsは、ODBCシステムを自社のオープンスタンダードであるJava Database Connectivity (JDBC)の基礎として使用しました。 JDBCからODBCへのブリッジは、Javaベースのプログラムが、ネイティブなJDBCドライバを持たないプラットフォーム上のODBCドライバを介してデータソースにアクセスすることを可能にしますが、これは現在では比較的まれです。

ODBC の現状

ODBC は現在も広く使用されており、ほとんどのプラットフォームとデータベースに対応したドライバーが用意されています。 既存のツールがテストやデバッグのためにこれらのエンジンへのフロントエンドとして機能する方法として、SQLite のような組み込みを目的としたデータベース エンジン用の ODBC ドライバーを見つけることは珍しいことではありません。 多くの Web 開発プラットフォームには、ターゲット データベースへの直接リンクが含まれており、MySQL は非常に一般的です。 このようなシナリオでは、クライアントサイドに直接アクセスすることも、複数のクライアントソフトウェアシステムをサポートすることもなく、すべてはプログラマーが提供するHTMLアプリケーションを介して行われます。 ODBCが提供する仮想化は、もはや強力な要件ではなく、ODBCの開発もかつてほど活発ではなくなっている。 しかし、ODBCがクライアント・サーバー・プログラミングの強力な要件でなくなると、今度は、データ分析やデータサイエンスのシナリオにおけるデータ統合のデータアクセスとデータ仮想化のためにODBCがより重要になります。

Version historyEdit

Version history:

  • 1.0：1992年9月リリース
  • 2.0：1994年頃
  • 2.5
  • 3.0：1995年頃、Intersolv社のJohn Goodson氏とIBM社のFrank Pellow氏とPaul Cotton氏がODBC 3.0に重要な意見を提供した
  • 3.5：1997年頃
  • 3.8：2009年頃、Windows 7に対応
  • 4.0: 2016年6月に開発が発表され、2017年9月にSQL Server 2017での最初の実装がリリースされ、2018年後半にデスクトップドライバーが追加された 最終仕様がGithubに公開された

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です