Loading article…
データアクセスマネージャ（DAM）は、 1991年にSystem 7の拡張機能として導入された、クラシックMac OS用のデータベースアクセスAPIでした。ODBCと概念は似ていましたが、DAMはほとんど利用されず、1990年代後半に廃止されました。1990年代初頭には非常に印象的なデモウェアで使用されたものの、実際にDAMを使用した製品はごくわずかでした。クラシックMac OSやmacOSのより新しいバージョンでは、この役割にODBCが使用されています。
DAMとODBCは多くの点で類似しています。両システムの主な目的は、データプロバイダに「クエリ文字列」を送信し、データプロバイダは（場合によっては）データ行からなる「結果セット」で応答することです。両システムは、例えば整数と文字列など、それぞれのシステム形式間でデータを変換することが求められていました。さらに、両システムとも、クライアントとサーバー間でクエリとデータを送信する詳細を隠蔽する通信サブシステムを提供していました。
Appleのソフトウェアの多くと同様に、DAMはアプリケーションユーザーとアプリケーション開発者の両方にとって、クエリ処理をできるだけシンプルにすることを目指していました。特に注目すべき機能の一つが「クエリドキュメント」という概念です。クエリドキュメントには、あらかじめ定義されたクエリ（またはその他のサーバーコマンド）がいくつでも含まれており、サーバーに送信する前にクエリを修正するためのオプションのコードも含まれていました。例えば、一般的なクエリドキュメントには、データベースサーバーにログインするクエリ文字列が含まれている場合があります。ログインが成功した場合、Mac OSの呼び出しを使用してローカルクライアントマシンから現在の日付を取得し、その日付を使用して特定の日付の倉庫の在庫を返すクエリを実行します。クエリドキュメントには、この処理をサポートするために必要なコンピュータコードやリソース（例えば、ユーザー名とパスワードの入力を求めるダイアログボックスなど）も含まれる場合があります。
アプリケーションは、クエリの内部構造を一切意識することなくクエリドキュメントを使用できました。ドキュメントは一連のリソースで構成されており、アプリケーションはドキュメントを開いて、その中の各クエリリソースを順番に実行するだけでした。DAMは、アプリケーションが意識することなくドキュメント内の必要なコードが実行されるようにし、最終的に結果がアプリケーションに渡されて表示されます。この一連の操作は完全に不透明であったため、アプリケーションは容易にDAMのサポートを追加することができました。
DAMには、ハイレベルインターフェースとローレベルインターフェースという2つの直接的なAPIも含まれていました。ハイレベルはクエリドキュメントの使用とかなり似ていましたが、アプリケーションがリソースではなくコードでクエリを構築することが想定されていました。ハイレベルインターフェースは、ODBCのパブリックインターフェースと概ね似ています。ローレベルでは、プログラマーがクエリ処理の任意の時点で介入し、たとえばデータを1行ずつ取得することができました。
DAMとODBCの大きな違いの一つは、ほとんど偶然から生まれたものです。DAMの開発に先立ち、Appleはデータベースミドルウェア製品を購入し、データアクセス言語（DAL）として販売していました。DALは基本的に、サーバー側で動作する様々なデータベースに対応するトランスレータを備えた標準化されたSQLでした。当時のSQLの標準規格は非常に基本的なもので、サポートも比較的不十分でしたが、DALは単一の言語を採用し、他のシステムとの間で変換を行うことでこの問題を解決しました。DAMを含むクライアントソフトウェアは、DALの標準言語でクエリを送信でき、バックエンドのデータベースの種類に関係なく、クエリは変換されて実行されました。
対照的に、ODBCは当初からSQLベースのシステムとして開発され、X/Open（現在はOpen Groupの一部）の標準化されたコールレベルインターフェースに基づいていました。ODBCでは、すべてのデータソースがSQLサーバーのように動作するように設計されていました。テキストファイルなどのサーバーレスソースの場合、ローカルのSQLパーサーがコマンドを解釈してファイルを読み取ります。ODBCでは、すべてのデータソースドライバがSQLを理解し、必要に応じてローカル方言に変換するとともに、返されるデータを標準形式に変換することが求められます。
この違いにより、DAMは実際にはODBCよりも使い勝手がはるかに劣るものとなった。DALはクエリの標準化を提供するものと想定されていたため、DAMにはODBCのような異なる方言を変換するレイヤーがなかった。DAMを真に活用するには、ユーザーは特定のデータベース用にDALサーバーを購入してインストールする必要もあった。DALは一般的に低速で高価であることが知られており、DAMの全体的な価値を著しく低下させていた。さらに、DAMは非SQLデータソースにアクセスするための言語を標準化していなかった。テキストファイル用のアダプタは非SQL言語を使用したり、完全に関数呼び出しベースのシステムを使用したりする可能性があった。また、テキストファイルや同様のデータソース用のシンプルなインターフェースは、基本的なDAMのインストールには含まれていなかった。
DAMの主要クライアントの一つは、Appleのデータマネージャー兼高速アプリケーション開発システムであるHyperCardでした。HyperCardの優れたフォームシステムとDAMのデータを組み合わせることで、それまで誰も見たことのないデータ駆動型GUIアプリが誕生しました。このシステムの最も一般的なデモでは、HyperCardスタックがBaskin-Robbinsの複数のデータベースにクエリを実行する様子が示されました。以前は、各地域が独自のデータベースサーバーを使用していたため、このようなクエリは不可能でしたが、DALによって1つのサーバーに統合されました。在庫補充の注文は、倉庫にある現在の在庫状況を示すグラフィカル表示上で、アイスクリームのスクープをドラッグするだけで行うことができました。
そのシステムは非常に優れていたため、他のデータベースベンダーはこぞって同様のシステムを提供しようと躍起になった。オラクル社はすぐにスピネーカー・ソフトウェア社からPLUSを買収し、まずOracle Cardとして、次にOracle Media Objectsとしてリリースした。他の企業も同様の道を辿り、やがてイベント駆動型データベースのフロントエンドはほとんどのシステムの標準機能となった。
他の多くのアプリケーションもこのシステムを利用していましたが、皮肉なことに、最も頻繁に利用していたのはマイクロソフトの各種Office製品でした。それ以外では、DAMのサポートはかなり稀で、この製品は広く普及しませんでした。おそらく、これはDAMシステム全体が不完全だったことに大きく起因しているのでしょう。ほとんどの場合、DALミドルウェアが必要であり、低コストのクエリドキュメントビルダーが不足していた（高価なものはいくつかありましたが）ため、DAMを使用する際のオーバーヘッドが非常に高くなっていました。
DAM の開発は 1990 年代半ばに終了し、Mac OS Xのリリース前に完全に姿を消しました。「クラシック」な Mac OS 版の ODBC はしばらくの間利用可能でしたが、サポートは限定的でした。OS X 10.2 Jaguarのリリース以降、Apple はiODBCクロスプラットフォーム ODBC ドライバのバージョンを配布し始めました。OS X 10.4 Tiger以降、Apple はCore Dataと呼ばれる、より「高レベル」の新しいシステムを導入しました。Core Data を使用すると、開発者はデータをSQLiteにシリアル化して処理できます。これは、非 SQL データ ソースで使用する場合の ODBC の概念と似ています。