Менеджер доступа к данным в классической macOS: обзор API DAM

Введение

API классической Mac OS
Data Access Manager (DAM) — это API доступа к базам данных для классической Mac OS, представленный в 1991 году как расширение System 7. По своей концепции DAM был аналогичен ODBC, но получил ограниченное распространение и был прекращен к концу 1990-х годов. Лишь небольшое количество продуктов когда-либо использовали его, хотя он применялся при создании некоторых весьма впечатляющих демо-программ в начале 1990-х. В более поздних версиях классической Mac OS и macOS для этих целей используется ODBC.

Понятия

DAM и ODBC во многом схожи. Основная цель обеих систем заключалась в отправке "запросных строк" поставщику данных, который в ответ (возможно) предоставлял "результирующий набор", состоящий из строк данных. Обе системы должны были преобразовывать данные в соответствующие форматы системы, например, целые числа и строки. Кроме того, обе предоставляли подсистему связи, скрывавшую детали отправки запросов и данных между клиентом и сервером. Как и большинство программного обеспечения Apple, DAM стремился максимально упростить процесс запроса для пользователей – как пользователей приложений, так и программистов, разрабатывающих эти приложения. Особенно заметной особенностью была концепция "документов запросов". Документы запросов могли содержать любое количество предварительно определенных запросов (или других серверных команд) вместе с дополнительным кодом для их изменения перед отправкой на сервер. Например, типичный документ запроса мог содержать запросную строку для входа на сервер базы данных, а в случае успеха – запросить текущую дату с локальной клиентской машины с помощью вызова Mac OS, а затем использовать эту дату в запросе, возвращающем данные об остатках на складе на указанную дату. Документы запросов также могли включать компьютерный код и ресурсы, необходимые для поддержки этого процесса, например, диалоговое окно с запросом имени пользователя и пароля. Приложения могли использовать документы запросов, не зная внутренней структуры запроса. Они просто открывали документ, состоящий из ряда ресурсов, и последовательно выполняли каждый ресурс запроса. DAM обеспечивал выполнение любого необходимого кода в документе без ведома приложения, а результаты в конечном итоге передавались обратно в приложение для отображения. Вся операция была непрозрачной, что позволяло приложениям легко добавить поддержку DAM. DAM также включал два более прямых API: интерфейс высокого уровня и интерфейс низкого уровня. Интерфейс высокого уровня был довольно похож на использование документов запросов, хотя предполагалось, что приложение будет формировать запросы в коде, а не в ресурсах. Интерфейс высокого уровня в целом аналогичен общедоступному интерфейсу ODBC. Интерфейс низкого уровня позволял программисту вмешиваться в любой момент процесса запроса, например, извлекать данные построчно. Одно из ключевых различий между 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 and ODBC are similar in many ways. The primary purpose of both systems was to send "query strings" to a data provider, who would respond (potentially) with a "result set" consisting of rows of data. Both systems were expected to convert data to and from the system's respective formats, integers and strings for instance. Additionally, both provided a communications subsystem that hid the details of sending queries and data between the client and server. Like most Apple software, DAM attempted to make the query process as simple as possible for the users, both application users and programmers writing those applications. One particularly notable feature was the concept of "query documents". Query documents contained any number of pre defined queries (or other server commands), along with optional code to modify them before being sent to the server. For instance, a typical query document might contain a query string that would log into the database server, and if that was successful, look up the current date from the local client machine using a Mac OS call, and then use that date in a query that returns inventory in a warehouse for a given date. Query documents could also include computer code and resources needed to support this process, for instance, a dialog box asking for the username and password. Applications could use query documents without having any idea of the internals of the query. They simply opened the document, which consisted of a series of resources, and ran each query resource inside in turn. The DAM would ensure that any needed code in the document would be run without the application even being aware of it, and eventually, results would be passed back to the application for display. The entire operation was opaque, allowing applications to add DAM support with ease. DAM also included two more direct API's, the High Level interface, and the Low Level interface. High Level was fairly similar to using query documents, although it was expected that the application would construct the queries in code rather than resources. The High Level interface is broadly similar to ODBC's public interface. Low Level allowed the programmer to intercede at any point in the query process, retrieving data line by line for instance. One major difference between DAM and ODBC came about largely by accident. Prior to the development of DAM, Apple had purchased a database middleware product they sold as the Data Access Language, or DAL. DAL was essentially a standardized SQL with translators for various databases that ran on the server side. Standards for SQL were extremely basic at the time, and relatively poorly supported, DAL addressed this by having a single language and converting to and from the other systems. Client software, including DAM, could send queries in DAL's standard language which would then be translated and executed regardless of the back end database. In contrast, ODBC was developed from the start to be a SQL based system, based on the standardized Call Level Interface from X/Open (now part of the Open Group). Under OBDC, every data source was made to look like a SQL server. For serverless sources, such as text files, a local SQL parser would interpret the commands and read the file. Under ODBC, all data source drivers are expected to understand SQL and translate it to the local dialect if needed, as well as convert data into standard formats when it is returned. This difference made DAM much less useful than ODBC in practice. Since it was expected that DAL would be providing query standardization, DAM had no layer similar to ODBC's for translating different dialects. In order for DAM to be truly useful, the user also had to buy and install a DAL server for their particular database. DAL was generally known to be slow and expensive, seriously degrading DAM's overall value. Further, DAM did not standardize the language for accessing non SQL data sources; an adaptor for a text file might use a non SQL language, or a completely function call based system instead. Nor were any simple interfaces for text files or similar data sources included with basic DAM installs.

Применение

Одним из основных клиентов DAM была HyperCard, система управления данными и быстрой разработки приложений от Apple. Сочетание отличной системы форм HyperCard с данными из DAM привело к созданию невиданных ранее GUI-приложений, управляемых данными. Наиболее распространенной демонстрацией системы был стек HyperCard, выполняющий запросы к базе данных Baskin Robbins, что ранее было невозможно, поскольку каждый региональный филиал использовал собственные серверы баз данных, которые DAL теперь объединила в единую систему. Повторные заказы на пополнение запасов можно было оформлять, перетаскивая изображения шариков мороженого на графическое отображение текущих складских запасов. Система произвела такое впечатление, что другие производители баз данных начали спешно разрабатывать аналогичные решения; Oracle Corporation немедленно приобрела PLUS у Spinnaker Software, выпустив её сначала как Oracle Card, а затем как Oracle Media Objects. Другие компании пошли по схожему пути, и вскоре интерфейс базы данных, управляемый событиями, стал стандартной функцией большинства систем. Ряд других приложений также использовали эту систему, и, возможно, иронично, наиболее регулярно это делали различные продукты Microsoft Office. В остальном поддержка DAM была довольно редкой, и продукт не получил широкого распространения. Вероятно, это было связано с незавершенностью системы DAM в целом: необходимостью использования промежуточного ПО DAL в большинстве случаев и отсутствием недорогих средств построения запросов к документам (существовали лишь дорогие аналоги), что значительно удорожало использование DAM. Разработка DAM была прекращена в середине 1990-х годов, и система полностью исчезла до выхода Mac OS X. В течение некоторого времени была доступна "классическая" версия ODBC для Mac OS, хотя поддержка была ограничена. Начиная с выпуска OS X 10.2 Jaguar, Apple начала распространять версию кроссплатформенных драйверов ODBC iODBC. Начиная с OS X 10.4 Tiger, Apple представила новую, значительно более продвинутую систему, известную как Core Data. Core Data позволяет разработчикам сериализовать данные в SQLite для обработки, что концептуально аналогично использованию ODBC с не-SQL источниками данных.

One of the major clients for DAM was HyperCard, Apple's data manager/rapid application development system. Combining HyperCard's excellent forms system with data from DAM resulted in something that no one had ever seen before data driven GUI apps. The most common demo of the system showed a HyperCard stack querying a series of Baskin Robbins databases, formerly impossible because each regional area used their own database servers which DAL now combined into one. Reorders for more stock could be made by dragging a series of ice cream scoops on a graphical display of the current warehoused inventory. The system was so impressive that it made other database vendors scramble to provide similar systems; Oracle Corporation immediately purchased PLUS from Spinnaker Software, releasing it first as Oracle Card, and then Oracle Media Objects. Other companies followed similar routes, and soon the event driven database front end was a standard feature of most systems. A number of other applications also used the system, perhaps ironically Microsoft's various Office products doing so with the most regularity. Other than that DAM support was fairly rare, and the product did not see widespread use. Perhaps much of this was due to the incomplete nature of the DAM system as a whole; the need for DAL middleware in most cases, and the lack of low cost query document builders (there were some expensive ones) made the overhead of using DAM quite high. Work on DAM ended in the mid 1990s, and disappeared entirely sometime before the release of Mac OS X. A "classic" Mac OS version of ODBC was available for some time, although support was limited. Starting with the release of OS X 10.2 Jaguar, Apple started distributing a version of the iODBC cross platform ODBC drivers. Starting with OS X 10.4 Tiger Apple has introduced a new and much "higher level" system known as Core Data. Core Data allows developers to serialize data into SQLite for processing, similar in concept to ODBC when used with a non SQL data source.