次の方法で共有


OLE DB プロバイダー (ADO)

OLE DB では、さまざまな情報ソースに格納されているデータへの統一されたアクセスをアプリケーションに提供する一連の COM インターフェイスが定義されています。 この方法により、データ ソースは、データ ソースに適した DBMS 機能の量をサポートするインターフェイスを介してデータを共有できます。 設計上、OLE DB の高パフォーマンス アーキテクチャは、柔軟なコンポーネント ベースのサービス モデルの使用に基づいています。 OLE DB では、アプリケーションとデータの間に所定の数の中間レイヤーを設定するのではなく、特定のタスクを実行するために必要な数のコンポーネントのみが必要です。

たとえば、ユーザーがクエリを実行するとします。 次のシナリオについて考えてみましょう。

  • データは、現在 ODBC ドライバーは存在するが、ネイティブ OLE DB プロバイダーがないリレーショナル データベースに存在します。アプリケーションは ADO を使用して OLE DB Provider for ODBC と通信し、適切な ODBC ドライバーを読み込みます。 ドライバーは SQL ステートメントを DBMS に渡し、データを取得します。

  • データは、ネイティブ OLE DB プロバイダーが存在する Microsoft SQL Server に存在します。アプリケーションは ADO を使用して OLE DB Provider for Microsoft SQL Server と直接通信します。 仲介者は必要ありません。

  • データは、OLE DB プロバイダーがあるが、SQL クエリを処理するエンジンを公開していない Microsoft Exchange Server に存在します。アプリケーションは ADO を使用して OLE DB Provider for Microsoft Exchange と通信し、OLE DB クエリ プロセッサ コンポーネントを呼び出してクエリを処理します。

  • データは、ドキュメントの形式で Microsoft NTFS ファイル システムに存在します。データには、Microsoft Indexing Service 経由でネイティブ OLE DB プロバイダーを使用してアクセスします。このプロバイダーは、ファイル システム内のドキュメントのコンテンツとプロパティのインデックスを作成して、効率的なコンテンツ検索を可能にします。

上記のすべての例では、アプリケーションはデータに対してクエリを実行できます。 ユーザーのニーズは、最小限のコンポーネント数で満たされます。 いずれの場合も、追加のコンポーネントは必要な場合にのみ使用され、必要なコンポーネントのみが呼び出されます。 この再利用可能なコンポーネントと共有可能なコンポーネントの需要読み込みは、OLE DB を使用する場合の高パフォーマンスに大きく貢献します。

プロバイダーは、データを提供するプロバイダーとサービスを提供するプロバイダーの 2 つのカテゴリに分類されます。 データ プロバイダーは独自のデータを所有し、表形式でアプリケーションに公開します。 サービス プロバイダーは、データを生成して使用し、ADO アプリケーションの機能を強化することで、サービスをカプセル化します。 サービス プロバイダーは、サービス コンポーネントとしてさらに定義することもできます。サービス コンポーネントは、他のサービス プロバイダーまたはコンポーネントと組み合わせて動作する必要があります。

ADO は、さまざまな OLE DB プロバイダーに対して一貫性のあるより高いレベルのインターフェイスを提供します。

このセクションには、次のトピックが含まれています。