Gestor de acceso a datos

El Administrador de Acceso a Datos (DAM) era una API de acceso a bases de datos para el Mac OS clásico , introducida en 1991 como una extensión de System 7. De concepto similar a ODBC , DAM tuvo poca acogida y finalmente se dejó de usar a finales de la década de 1990. Solo un puñado de productos lo utilizaron, aunque se empleó en algunas demostraciones muy impresionantes a principios de los 90. Las versiones más modernas del Mac OS clásico y macOS utilizan ODBC para esta función.

DAM y ODBC son similares en muchos aspectos. El objetivo principal de ambos sistemas era enviar "cadenas de consulta" a un proveedor de datos, quien respondería (potencialmente) con un "conjunto de resultados" compuesto por filas de datos. Se esperaba que ambos sistemas convirtieran los datos a sus respectivos formatos, como enteros y cadenas de texto. Además, ambos proporcionaban un subsistema de comunicaciones que ocultaba los detalles del envío de consultas y datos entre el cliente y el servidor.

Como la mayoría del software de Apple, DAM intentó simplificar al máximo el proceso de consulta para los usuarios, tanto usuarios de la aplicación como programadores. Una característica particularmente destacable fue el concepto de "documentos de consulta". Estos documentos contenían consultas predefinidas (u otros comandos del servidor), junto con código opcional para modificarlas antes de enviarlas al servidor. Por ejemplo, un documento de consulta típico podría contener una cadena de consulta que iniciara sesión en el servidor de la base de datos y, si la conexión era exitosa, buscara la fecha actual en el equipo cliente local mediante una llamada a macOS, para luego usar esa fecha en una consulta que devolviera el inventario de un almacén para una fecha determinada. Los documentos de consulta también podían incluir código informático y recursos necesarios para este proceso, como un cuadro de diálogo que solicitara el nombre de usuario y la contraseña.

Las aplicaciones podían usar documentos de consulta sin tener conocimiento de su funcionamiento interno. Simplemente abrían el documento, que constaba de una serie de recursos , y ejecutaban cada recurso de consulta sucesivamente. El DAM se encargaba de que cualquier código necesario en el documento se ejecutara sin que la aplicación lo supiera, y finalmente, los resultados se devolvían a la aplicación para su visualización. Toda la operación era opaca, lo que permitía a las aplicaciones añadir compatibilidad con DAM con facilidad.

DAM también incluía dos API más directas: la interfaz de alto nivel y la interfaz de bajo nivel. La interfaz de alto nivel era bastante similar al uso de documentos de consulta, aunque se esperaba que la aplicación construyera las consultas mediante código en lugar de recursos. Esta interfaz es muy similar a la interfaz pública de ODBC. La interfaz de bajo nivel permitía al programador intervenir en cualquier punto del proceso de consulta, recuperando datos línea por línea, por ejemplo.

Una diferencia importante entre DAM y ODBC surgió en gran medida por casualidad. Antes del desarrollo de DAM, Apple había adquirido un producto de middleware de bases de datos que comercializaba como Data Access Language (DAL). DAL era esencialmente un SQL estandarizado con traductores para diversas bases de datos que se ejecutaban en el servidor. En aquel entonces, los estándares de SQL eran extremadamente básicos y contaban con un soporte relativamente deficiente. DAL solucionó este problema al utilizar un único lenguaje y realizar conversiones entre los diferentes sistemas. El software cliente, incluido DAM, podía enviar consultas en el lenguaje estándar de DAL, que luego se traducían y ejecutaban independientemente de la base de datos.

En cambio, ODBC se desarrolló desde el principio como un sistema basado en SQL, utilizando la interfaz estandarizada Call-Level Interface de X/Open (ahora parte de Open Group ). Con ODBC, cada fuente de datos se configuraba para funcionar como un servidor SQL. Para fuentes sin servidor, como archivos de texto, un analizador SQL local interpretaba los comandos y leía el archivo. Con ODBC, se espera que todos los controladores de fuentes de datos comprendan SQL y lo traduzcan al dialecto local si es necesario, además de convertir los datos a formatos estándar al recibirlos.

Esta diferencia hizo que DAM fuera mucho menos útil que ODBC en la práctica. Dado que se esperaba que DAL proporcionara estandarización de consultas, DAM no contaba con una capa similar a la de ODBC para traducir diferentes dialectos. Para que DAM fuera realmente útil, el usuario también debía comprar e instalar un servidor DAL para su base de datos específica. DAL era generalmente conocido por ser lento y costoso, lo que reducía considerablemente el valor general de DAM. Además, DAM no estandarizaba el lenguaje para acceder a fuentes de datos no SQL; un adaptador para un archivo de texto podía usar un lenguaje no SQL o un sistema basado completamente en llamadas a funciones. Tampoco se incluían interfaces sencillas para archivos de texto o fuentes de datos similares en las instalaciones básicas de DAM.

Uno de los principales clientes de DAM fue HyperCard , el sistema de gestión de datos y desarrollo rápido de aplicaciones de Apple . La combinación del excelente sistema de formularios de HyperCard con los datos de DAM dio como resultado algo nunca antes visto  : aplicaciones GUI basadas en datos. La demostración más común del sistema mostraba una pila de HyperCard consultando una serie de bases de datos de Baskin-Robbins , algo que antes era imposible porque cada área regional usaba sus propios servidores de bases de datos, que DAL ahora combinaba en uno solo. Se podían realizar pedidos de más existencias arrastrando una serie de bolas de helado en una representación gráfica del inventario almacenado.

El sistema resultó tan impresionante que provocó que otros proveedores de bases de datos se apresuraran a ofrecer sistemas similares; Oracle Corporation adquirió inmediatamente PLUS de Spinnaker Software , lanzándolo primero como Oracle Card y luego como Oracle Media Objects . Otras compañías siguieron rutas similares, y pronto la interfaz de base de datos basada en eventos se convirtió en una característica estándar de la mayoría de los sistemas.

Varias otras aplicaciones también utilizaban el sistema, siendo, irónicamente, los diversos productos de Office de Microsoft los que lo hacían con mayor frecuencia. Aparte de eso, el soporte para DAM era bastante escaso y el producto no tuvo una gran acogida. Esto se debió, probablemente, en gran medida a la naturaleza incompleta del sistema DAM en su conjunto ; la necesidad de middleware DAL en la mayoría de los casos y la falta de generadores de documentos de consulta de bajo coste (aunque existían algunos costosos) elevaban considerablemente la complejidad del uso de DAM.

El trabajo en DAM finalizó a mediados de la década de 1990 y desapareció por completo poco antes del lanzamiento de Mac OS X. Durante un tiempo, estuvo disponible una versión "clásica" de ODBC para Mac OS, aunque con soporte limitado. A partir del lanzamiento de OS X 10.2 Jaguar , Apple comenzó a distribuir una versión de los controladores ODBC multiplataforma iODBC . Con OS X 10.4 Tiger, Apple introdujo un nuevo sistema de nivel superior conocido como Core Data . Core Data permite a los desarrolladores serializar datos en SQLite para su procesamiento, de forma similar a ODBC cuando se utiliza con una fuente de datos que no sea SQL.

• Gestor de acceso a datos
• Desarrollo con Core Data