ODBC の作成の目的

これまで、企業は 1 つの DBMS を使用しました。 すべてのデータベース アクセスは、そのシステムのフロントエンドを通じて、またはそのシステムでのみ動作するように作成されたアプリケーションを介して行われました。 しかし、コンピュータの利用が拡大し、より多くのコンピュータのハードウェアとソフトウェアが利用可能になるにつれて、企業は様々なDBMSを導入し始めました。 理由はたくさんありました:人々は、最も安いもの、最速だったもの、彼らがすでに知っていたもの、市場で最新だったもの、1つのアプリケーションに最適なものを購入しました。 その他の理由は、再編成と合併であり、以前は単一のDBMSを使っていた部門が複数のDBMSを持つようになったことが挙げられます。

この問題は、パーソナル コンピューターの出現によりさらに複雑化しました。 これらのコンピューターは、データのクエリ、分析、表示のための多数のツールと、安価で使いやすいデータベースをもたらしました。 それ以降、1 つの企業は、多くの場合、多数のデスクトップ、サーバー、ミニコンピューターにデータが散在し、さまざまな互換性のないデータベースに保存され、膨大な数の異なるツールによってアクセスされることが多くなり、すべてのデータにアクセスできるツールはほとんどなくなりました。

最後の課題は、コンピューター資源の最も効率的な使用を目指すクライアント/サーバー コンピューティングの出現でした。 安価なパーソナル コンピューター (クライアント) は、デスクトップに置かれ、データにグラフィカル フロントエンドと、スプレッドシート、グラフ 作成プログラム、レポート ビルダーなどの安価なツールの両方を提供します。 ミニコンピューターとメインフレーム コンピューター (サーバー) は DBMS をホストし、コンピューティング能力と中央のロケーションを利用して、迅速で調整されたデータ アクセスを提供できます。 では、フロントエンドのソフトウェアはどのようにバックエンドのデータベースに接続されるのでしょうか？

同様の問題は、独立系ソフトウェア・ベンダー (ISV) も直面していました。 ミニコンピュータやメインフレーム用のデータベースソフトウェアを作成しているベンダーは、通常、DBMSごとに1つのバージョンのアプリケーションを書くか、アクセスしたいDBMSごとにDBMS固有のコードを書かざるを得ませんでした。 パーソナル・コンピュータ用のソフトウェアを開発するベンダーは、作業するDBMSごとにデータ・アクセス・ルーチンを書かなければなりませんでした。 そのため、アプリケーションよりもデータ・アクセス・ルーチンの作成や保守に膨大なリソースが費やされ、アプリケーションはその品質ではなく、特定のDBMS 内のデータにアクセスできるかどうかで販売されることがよくありました。

両方の開発者が必要としていたのは、異なる DBMS 内のデータにアクセスする方法でした。 メインフレームとミニコンピュータのグループは、異なるDBMSからのデータを単一のアプリケーションでマージする方法を必要としていました。一方、パーソナルコンピュータのグループは、この機能と、どのDBMSにも依存しない単一のアプリケーションを書く方法を必要としていました。 要するに、どちらのグループもデータにアクセスするための相互運用可能な方法を必要としており、オープンなデータベース接続が必要だったのです。