データベース抽象化レイヤー

データベース抽象化レイヤー（DBAL [ ^1]またはDAL）は、コンピュータアプリケーションとSQL Server、IBM Db2、MySQL、PostgreSQL、Oracle、SQLiteなどのデータベース間の通信を統合するアプリケーションプログラミングインターフェースです。従来、すべてのデータベースベンダーは、自社製品に合わせた独自のインターフェースを提供しています。アプリケーションでサポートされるデータベースインターフェースのコードを実装するのは、アプリケーションプログラマの責任です。データベース抽象化レイヤーは、開発者に一貫した API を提供し、データベースの詳細をこのインターフェースの背後に可能な限り隠すことで、作業量を削減します。さまざまなプログラミング言語で、さまざまなインターフェースを持つ抽象化レイヤーが多数存在します。アプリケーションにこのようなレイヤーが組み込まれている場合、データベースに依存しないと呼ばれます。^[2]

最下位レベルはデータベースに接続し、ユーザーが必要とする実際の操作を実行します。このレベルでは、概念的な命令はデータベースが理解できる複数の命令に変換されています。命令を正しい順序で実行することで、DAL は概念的な命令を実行できます。

物理層の実装では、データベース固有の API を使用することも、基盤となる言語の標準データベース アクセス テクノロジとデータベースのバージョン SQL を使用することもできます。

このレベルでは、データ型と操作の実装は最もデータベース固有です。

概念レベルでは、外部の概念と指示を、物理的な指示に委譲できる中間データ構造に統合します。このレイヤーは、外部レベルと物理レベルにまたがるため、最も複雑です。さらに、サポートされているすべてのデータベースとその癖、API、問題にもまたがる必要があります。

このレベルでは、データベース間の違いを認識し、あらゆるケースで操作の実行パスを構築できます。ただし、概念レイヤーは、個々の操作の実際の実装については物理レイヤーに従います。

外部レベルはユーザーと開発者に公開され、データベース操作を実行するための一貫したパターンを提供します。 ^[3]このレベルでは、データベース操作はSQLまたはデータベースアクセスとしてのみ緩く表現されます。

このレベルでは、物理的なデータの種類や操作が異なっていても、すべてのデータベースは明らかな違いなく平等に扱われる必要があります。

ライブラリは、アプリケーション開発者に単一の低レベル プログラミング インターフェイスを提供することで、データベースへのアクセスを統合します。ライブラリの利点は、ほとんどの場合、特定のクエリ言語(サブセット) に縛られず、目的を達成するために薄いレイヤーを実装するだけでよいため、速度と柔軟性が高くなります。すべてのSQL方言は互いに類似しているため、アプリケーション開発者はすべての言語機能を使用でき、通常はユーザー ID や資格情報など、データベース固有のケース用に構成可能な要素を提供することもできます。薄いレイヤーにより、同じクエリとステートメントをさまざまなデータベース製品で実行でき、オーバーヘッドは無視できます。

データベース抽象化レイヤーは、API レベルの抽象化レイヤーに似たオブジェクト指向プログラミング言語でよく使用されます。C++ や Java などのオブジェクト指向言語では、データベースはオブジェクトを通じて表現され、そのメソッドとメンバー (または他のプログラミング言語の同等のもの) はデータベースのさまざまな機能を表します。また、API レベルのインターフェースと長所と短所を共有しています。

言語レベルのデータベース抽象化レイヤーの例としては、プラットフォームに依存しないデータベース抽象化レイヤーの実装であるODBCがあります。ユーザーは特定のドライバー ソフトウェアをインストールし、それを介して ODBC は 1 つまたは複数のデータベースと通信できます。次に、ユーザーはプログラムを ODBC と通信させ、その結果をユーザー プログラムとデータベースの間で中継することができます。この抽象化レベルの欠点は、ステートメントをターゲット データベースが理解できる構造に変換するためのオーバーヘッドが増加することです。

^{あるいは、OpenDBX [4]}やlibzdb ^[5]などの軽量抽象化レイヤーと呼ばれる薄いラッパーもあります。 最後に、大規模なプロジェクトでは、たとえばGNOME用のlibgda ^[6]のように独自のライブラリを開発することもあります。

• 開発期間: ソフトウェア開発者は、アプリケーションがサポートするデータベースのすべての API ではなく、データベース抽象化レイヤーの API のみを知っていればよいことになります。サポートするデータベースの数が多いほど、時間の節約が大きくなります。
• より広い潜在的なインストールベース: データベース抽象化レイヤーを使用すると、新しいインストールで特定のデータベースを使用する必要がなくなります。つまり、データベースを切り替えたくない、または切り替えることができない新しいユーザーは、既存のインフラストラクチャに展開できます。
• 将来性: 新しいデータベース テクノロジが登場しても、ソフトウェア開発者は新しいインターフェイスに適応する必要がなくなります。
• 開発者テスト: 開発者レベルの単体テストでは、運用データベースをデスクトップ レベルのデータ実装に置き換えることができます。
• 追加されたデータベース機能: データベースと DAL によっては、DAL がデータベースに機能を追加できる場合があります。DAL は、データベース プログラミング機能またはその他の方法を使用して、標準だがサポートされていない機能やまったく新しい機能を作成する場合があります。たとえば、DBvolution DAL は、標準偏差関数をサポートしていないいくつかのデータベースに対して、標準偏差関数を実装します。

• 速度: 抽象化レイヤーは、実行する必要がある追加コードの量に応じて、全体的な速度を多少低下させます。データベース レイヤーがネイティブ データベース インターフェイスから抽象化され、すべてのデータベース バックエンドに存在しない機能をエミュレートしようとするほど、全体的なパフォーマンスは低下します。これは、ODBC のようにクエリ言語を統一しようとするデータベース抽象化レイヤーに特に当てはまります。
• 依存性: データベース抽象化レイヤーは、ソフトウェア システムにさらに別の機能的な依存性を提供します。つまり、他のものと同様、特定のデータベース抽象化レイヤーは、最終的には廃止されたり、時代遅れになったり、サポートされなくなったりする可能性があります。
• マスクされた操作: データベース抽象化レイヤーは、利用可能なデータベース操作の数を、サポートされているデータベース バックエンドでサポートされている操作のサブセットに制限する場合があります。特に、データベース抽象化レイヤーは、データベース バックエンド固有の最適化やデバッグ機能を完全にサポートしていない場合があります。これらの問題は、データベースのサイズ、スケール、複雑さによって大幅に増大します。

• オブジェクトリレーショナルマッピング