これまで、企業は 1 つの DBMS を使用しました。 すべてのデータベース アクセスは、そのシステムのフロントエンドを通じて、またはそのシステムでのみ動作するように作成されたアプリケーションを介して行われました。 しかし、コンピュータの使用が増加し、コンピュータのハードウェアとソフトウェアが利用可能になるにつれて、企業は異なるDBMSを取得し始めました。 理由は多かった:人々は、最も安いもの、最速だったもの、彼らがすでに知っていたもの、市場で最新だったもの、1つのアプリケーションに最適なものを購入しました。 その他の理由は、再編成と合併であり、以前は 1 つの DBMS を持っていた部門に複数の DBMS がありました。
この問題は、パーソナル コンピューターの登場によりさらに複雑化しました。 これらのコンピューターには、データのクエリ、分析、表示のための多数のツールと、安価で使いやすいデータベースが多数用意されています。 それ以降、1 つの企業は、多くの場合、多数のデスクトップ、サーバー、ミニコンピューターにデータが散在し、さまざまな互換性のないデータベースに格納され、膨大な数の異なるツールによってアクセスされ、その中にはすべてのデータを取得できるものはほとんどありませんでした。
最後の課題は、コンピューター リソースの最も効率的な使用を目指すクライアント/サーバー コンピューティングの出現でした。 安価なパーソナル コンピューター (クライアント) は、デスクトップに配置され、データにグラフィカル フロントエンドと、スプレッドシート、グラフ 作成プログラム、レポート ビルダーなどの安価なツールの両方を提供します。 ミニコンピューターとメインフレーム コンピューター (サーバー) は DBMS をホストし、コンピューティング能力と中央の場所を使用して、迅速で調整されたデータ アクセスを提供できます。 その後、フロントエンド ソフトウェアをバックエンド データベースに接続する方法を説明します。
同様の問題は、独立系ソフトウェア ベンダー (ISV) に直面しました。 ミニコンピューターとメインフレーム用のデータベース ソフトウェアを作成するベンダーは、通常、DBMS ごとに 1 つのバージョンのアプリケーションを記述するか、アクセスする DBMS ごとに DBMS 固有のコードを記述することを強制されていました。 パーソナル コンピューター用のソフトウェアを作成するベンダーは、作業する DBMS ごとにデータ アクセス ルーチンを記述する必要がありました。 これは多くの場合、アプリケーションではなくデータ アクセス ルーチンの作成と保守に膨大な量のリソースが費やされ、アプリケーションは品質ではなく、特定の DBMS 内のデータにアクセスできるかどうかで販売されることがよくあります。
両方の開発者が必要としていたのは、異なる DBMS 内のデータにアクセスする方法でした。 メインフレームとミニコンピューター グループには、1 つのアプリケーションで異なる DBMS のデータをマージする方法が必要でしたが、パーソナル コンピューター グループには、この機能と、1 つの DBMS に依存しない単一のアプリケーションを記述する方法が必要でした。 要するに、両方のグループがデータにアクセスするための相互運用可能な方法を必要としました。開いているデータベース接続が必要です。