En alguno de los cursos de Tecnología de Objetos que imparto muestro una transparencia con el título “Diseño de Bases de Datos” para seguidamente, tras una estudiada pausa, superponer otra con una señal de prohibición, a la vez que afirmo categórico: “No hay diseño sustantivo de bases de datos” [1]. Y punto: nada que añadir. Naturalmente el buscado efectismo intenta comunicar que si en Tecnología de Objetos el abismo (gap) semántico entre Análisis y Diseño se difumina, tal solapación debiera ampliarse a las etapas de codificación y almacenamiento. O sea, las entidades que se encuentran en la fase de análisis de requerimientos se corresponderán biunívocamente con clases/objetos en las de análisis y diseño, para después mantener su integridad modular y conceptual tanto en la implementación como en el esquema de persistencia. Para abreviar: el objecto finalmente almacenado en la Base de Datos se corresponderá estructuralmente con aquél encontrado en el dominio del problema, significando así que queda sin sentido el trabajo de descomposición en estructuras de datos asumibles por gestores concretos que luego habrán de ser nuevamente compuestas para su uso efectivo. La cuestión es ¿desmontaría usted cada noche su coche en piezas para reconstruirlo en la mañana siguiente, cuando desee usarlo? Evidentemente no [2], al menos directamente. El enfoque más elegante sería dejar que un guardacoches responsable se ocupara del auto, sin necesaria sujección a un garaje dado, y nos lo entregara cada mañana en perfecto estado de funcionamiento. Y es aquí donde aparecen las bases de datos orientadas-a-objetos en sus distintas graduaciones.

DEGRADADO DE BASES DE DATOS

Como las verduras en las pequeñas tiendas de barrio, la Orientación-a-Objetos en Bases de Datos posee distintos grados de pureza. Helos aquí:

• Bases de Objetos Puras (ODBMSs: Object DataBase Manager Systems): Los productos que se enmarcan en esta categoría usualmente ofrecen la misma funcionalidad que puede encontrarse en gestores relacionales maduros (integridad, concurrencia, distribución, persistencia, recuperación de errores, etc.), con la particularidad de basarse en un estricto modelo de objetos, significados por OIDs (Object Identifiers). La naturaleza avanzada de los mismos procura además, por lo general, servicios de migración de objetos, soporte de trabajo en grupo, transacciones distribuidas, etc.
• Gestores de Almacenamiento Persistente (PSMs: Persistent Storage Managers): En entornos de ingeniería y CAD, donde lo que importa es la focalización del equipo en el trabajo “real”, los PSMs proporcionan servicios de persistencia que aislan al usuario especializado de las tareas de segmentación, almacenamiento y composición de entidades, usalmente con identidad propia temporal. Diríamos que se trata de OODBMSs especializadas que, en esa razón, carecen (o disponen pobremente) de algunos de los servicios genéricos de éstas, como control avanzado de integridad de datos, evolución dinámica de esquemas, etc.
• Envoltorios de Objetos (OWs: Object Wrappers): Se trata de capas software que se constituyen, como el envoltorio de un caramelo, en interfaz entre el usuario y el pegajoso interior relacional. Las estructuras segmentadas en tablas pueden ofrecer, así, un interfaz orientado-a-objetos susceptible de interactuar con otros similares interfaces. Esta opción aparécese de forma natural cuando se intentan compatibilizar las técnicas de orientación-a-objetos en análisis/diseño y GUIs con bases de datos relacionales pre-existentes, o aun con la imposibilidad práctica de operar con gestores reales de objetos. El peligro es, naturalmente, que pueda llegar a confundirse “wrapper” con “front-end” o, aun peor, con un mero “interfaz-de-dibujitos”. En realidad los envoltorios que aquí se detallan son usualmente no visuales, constituyéndose así en mediadores (O/R bridges) entre las vistas y la información tabulada que manejan. Así, por ejemplo, el evento/mensaje “clicked” aplicado/enviado al botón de una determinada vista resultará en el envío del mensaje “ejecutaQuery” a un objeto envoltorio de tipo, verbigracia, “ClienteWrapper”, que a su vez se ocupará, mediante la implementación interna (como función miembro en C++) de una funcionalidad contenedora de una frase SQL, de acceder y unir (JOIN) varias tablas para devolver, de forma conceptualmente unificada, una respuesta coherentemente encapsulada [3]. El “wrapper” se transforma así en un intermediario que encierra cuestiones de implementación específicas de el/los gestor/es relacional/es a que accede, separando así, de una forma adecuada para los sufridos mantenedores de aplicaciones, la oscura parte tabular de los volátiles dibujos de ventanas. Hay que decir, empero, que subsisten -naturalmente- los problemas de eficacia relacionados con la gestión de información compleja: un vale de entrada y el abandono de andrajos facilitan la asistencia a la ópera, pero en absoluto ayudan a la inmersión musical en las obras.
• Bases de Datos Relacionales Extendidas (RDBMS/Os) o con-orientacion-a-objetos (“a-algunos-objetos”, que diría más de un malicioso usuario): De las chisteras de las grandes compañías de RDBMSs aparece, de tanto en tanto, alguna porción de lo que nos presentan como conejo y que, sin embargo, es mayormente gato. Ahora una patita (procedimientos almacenados), luego esos bigotes (disparadores/triggers), más tarde ... ¿qué? La presión del mercado consigue que lo que debiera presentarse como “RDBMSs mejoradas” -y ciertamente es así- aparezca en mercantilista calidad de “Bases de Datos Relacionales Orientadas-a-Objetos”. Naturalmente este tipo de producto se debe al casi siempre loable afan de supervivencia base de la evolución darwiniana, y aunque algunos puedan decir que la evolución del diámetro de la cabeza para albergar más ideas no es sino simple mixomatosis, la verdad es que las cuestiones de compatibilidad se imponen: sea cual sea el tamaño de la cabeza lo cierto es que seguirá gobernando el mismo cuerpo, lo cual es bueno y malo. Bueno porque se aprovecha sin merma toda la estructura de información pre-existente; malo porque nueve ginecólogos no reducen a un mes el período de preñez de una gestante: encapsulación, herencia y polimorfismo son conceptos en buena medida ajenos a estos gestores.

Qué producto usar depende en gran medida del lenguaje, de las herramientas, del tipo de aplicación. Y aunque lo usual es empezar por el ámbito más relacional e ir escalando características de objetos según se encuentran problemas o imposibilidades, yo recomendaría comenzar con las bases de objetos puras e ir bajando a esquemas con mayor componente relacional conforme no se cumplan las características de eficacia, rapidez, etc. Deseadas. Pero vayamos a la parte humana de los objetos.

LOS DESEOS DEL PROGRAMADOR

Seguro que los programadores, como clase, albergan toda suerte de deseos nocivos, pero entre ellos uno destaca por su interés morboso: el de liberarse de las repetitivas codificaciones de acceso y recuperación de datos en bases de datos. Si, de acuerdo con el esquema involutivo en espiral (de fuente o de piscina) de las fases de análisis y diseño, la mayor parte del tiempo se pasa intentando generar un interfaz limpio de clases para su implementación, ¿por qué no dedicar el tiempo restante a la codificación algorítmica inteligente, en vez de tratar con aspectos que podrían ser en gran medida mecanizados o, cuando menos, obviados por sistemas de gestión de más alto nivel? La respuesta a la pregunta retórica es obvia. El lector se cuestionará, empero, el calificativo “morboso”: lo cierto es que la solución de las cuitas aquí planteadas pasa por una degradación de la profesión misma de programador, cuya funcionalidad básica ha sido, tradicionalmente, trasladar a código los resultados exactos de la fase de diseño. Si, con el nuevo esquema del ciclo de vida del software, la codificación queda grandemente sustituida por la lectura y el reuso de clases insertas en bibliotecas y entornos-marcos, y además prácticamente se elimina la codificación final de almacenamiento, ¿qué queda para el programador? ¿No resulta más rentable y efectivo, más aún teniendo en cuenta el gran acervo actual de herramientas software, que el mismo diseñador traslade al código los resultados del diseño? Edward Berard afirma que la figura del programador habrá de ser sustituida por la del “Analista del Dominio del Problema Orientado-a-Objetos” (OODA: Object-Oriented Domain Analyst). Tal presunción es un tanto efectista, pero el razonamiento subyacente es prudentemente razonable. De cualquier forma el hecho es simple: el programador tiende a desear un gestor de almacenamiento transparente (por invisible), o cuando menos translúcido. El presupuesto inicial es sencillo: el manejo de instancias de objetos en memoria ha de ser igual o muy parecido al manejo de los mismos objetos en un espacio de almacenamiento físico. Así, si consideramos que la memoria es el almacenamiento primario (AP) y, verbibracia, el disco el secundario (AS), el esquema ideal de cosas pasaría por considerar que los objetos (instancias) pueden, merced a mecanismos muy simples, pasear entre AS y AP considerando éstos como zonas de un hábitat global para nuestras instancias.

PERSISTENCIA, TRANSITORIEDAD Y MATRICES

La persistencia es, en esencia, la cualidad de un objeto o grupo de objetos de sobrevivir al proceso o CPU que los creó. Esto es, los objetos podrán, tras ser usados, ser accedidos todavía por otros objetos, pues anidarán en la zona persistente del espacio de almacenamiento unificado. Los objetos transitorios (transient objects) son, en contraposición a los persistentes, aquéllos cuyo acceso no puede garantizarse tras terminar el proceso que los creó y/o usó. Y fíjese bien el lector: no es que no puedan ser accedidos ocasionalmente, sino que no puede garantizarse en general tal acceso. Tenemos, pues, dos características que, junto con las zonas de almacenamiento (AP y AP), generan una matriz que puede complicar la vida al programador dependiendo del enfoque que haya adoptado el producto de base de datos. La cuestión depende, básicamente de la dependencia entre la cualidad de persistencia y la clase de la instancia que se pretende persistente.

ORTOGONALIDAD DE PERSISTENCIA Y TIPO

La ortogonalidad se refiere, según el Manifiesto de Sistemas de Bases de Datos Orientadas-a-Objetos, Tokyo, 1.989, a la independencia entre el tipo de un objeto y su capacitación para asumir características persistentes. Al decir “ortogonal” se pretende indicar una relación similar a la de dos ejes perpendiculares en un plano, representativos de distintas dimensiones y, por ende, independientes. La dicotomía queda reflejada en los siguientes distintos enfoques:

• La persistencia es una cualidad o capacitación de todas las instancias de una clase o clases dadas : en esta variante un objeto de una determinada clase (de cualquier clase, en un modelo más amplio pero que aquí no consideraremos debido a la serie de debilidades prácticas que conlleva) automáticamente se convierte en persistente al crearse. Digamos que existirían clases (en un modelo restringido, mucho más flexible) cuya persistencia no merecerá la pena y otras cuyas instancias contengan información no volatil. En la práctica, un enfoque muy extendido para insuflar la cualidad de persistencia a una clase es hacerla derivar de otra que encierre los mecanismos de persistencia (generalmente denominada “Persist” o algo parecido). El problema que suele plantear este enfoque es el “apuntamiento” de objetos desde el AP al AS y viceversa, que se troca muchas veces casi inmanejable en objetos compuestos. Imaginemos, por ejemplo, que nuestra clase “Cliente” genera instancias persistentes. Pero la clase contiene muchos atributos, pertenecientes, a su vez, a otras tantas clases, algunas de las cuales serán transitorias y otras no. Si, de acuerdo con el esquema flexible planteado, una instancia de Cliente contiene un atributo, verbigracia, “apodo” de una clase “Apodo” de tipo no persistente, la vida se va a complicar para el programador: no pueden incluirse para este atributo mecanismos de inicialización equivalentes a los usados en Bases de Datos Relacionales, pues lo usual es que no podamos controlar si un objeto persistente apuntado (la instancia de Cliente) está en cada momento en una zona transitoria o en una zona persistente, de tal manera que habría que añadir código de comprobación e inicialización en cada función que intentara acceder al atributo volatil. Pero el problema se agrava cuando tal atributo es accesible mediante una consulta a la OODB. Naturalmente una opción muy practicada es evitar la mezcla, siquiera en composición, de clases -y aun de objetos- persistentes y transitorios.
• Cualquier instancia de cualquier clase puede ser persistente o transitoria : de esta forma no se pretenden incluir mecanismos específicos en la clase, directamente o por herencia, sino que más bien el sistema gestor se encarga de traspasar o no la cualidad de persistencia merced a comportamientos influenciables por el usuario. Una práctica muy extendida, adoptada por GemStone y O 2 entre otros sistemas, es que el sistema conste de unos objetos persistentes predefinidos, de manera que una instancia cualquiera se convertiría también en persistente si es “apuntada” por alguno de aquéllos objetos. Este esquema, más complejo que el no-ortogonal, elimina, sin embargo, buena parte de la complejidad de la matriz “Espacio de Almacenamiento x Persistencia”: si una instancia transitoria de la clase, verbigracia, “Persona” con identificador “miTio” se troca en persistente por su inclusión, por ejemplo, en el objeto persistente de tipo agregado con identificador “miFamilia”, las instancias concretas significadas por variables en nuestro objeto “miTio” se trocarán también en persistentes. La persistencia se perderá cuando la instancia deje de ser apuntada por objetos persistentes (cuando, por ejemplo, “miTio” sea expulsado de “miFamilia” por crápula). Naturalmente este enfoque es el preferido por los programadores, porque convierte en invisible la gestión de almacenamiento. Desgraciadamente, también, sus implementaciones actuales muchas veces no se ajustan a lo requerido.

CRÍTICA DE LA RAZÓN PRÁCTICA

Bien, bien. Las cuestiones prácticas son: ¿realmente funcionan las Bases de Objetos? ¿Facilitan las tareas de codificación y, por ende, favorecen la ejecución de proyectos? ¿La velocidad y eficacia son aceptables? ¿Puedo contar, al menos, con las mismas características disponibles en el sector relacional? ¿Puedo ... ? Sí, sí, sí, sí y ... err ... no. La tecnología anda en buena medida renqueando tras los productos comerciales, así que los esquemas de persistencia, recuperación de errores, versionamiento, concurrencia, integridad referencial [4], etc. dependen del producto en cada caso elegido. Mi experiencia señala que los conceptos que aquí se han apuntado, siquiera someramente, son asimilados con cierta eficacia cuando pueden ejemplificarse aplicándolos a un producto concreto. La comprehensión aumenta cuando los mismos ejemplos se refieren a porciones conceptuales de una aplicación homogénea. Así que lo mejor será emplazarme para un nuevo artículo relativo a una Base de Objetos comercial. ¿Y cuál más adecuada a estos propósitos que GemStone? Bueno: la intención es lo primordial.

INTERNET: ¿CÓMO NO?

Los interesados en las cuestiones aquí esbozadas pueden acercarse por el grupo de noticias de usenet “comp.databases.object”, excelente punto de partida para novicios, donde encontrarán interesantes discusiones e información práctica de uso de productos. Las típicas preguntas, por otro lado, sobre productos comerciales relacionados con las Bases de Objetos obtendrán su respuesta en la FAQ informal del grupo que, con el calificativo de mini-faq, mantiene y actualiza regularmente Tim Harvey. Yo mismo mantengo, de acuerdo con Tim, una copia de esta mini-faq en http://www.well.com/user/ritchie/mini-faq.html.

BIBLIOGRAFÍA COMENTADA

“Si yo tuviera que vender mi gato (al menos a un informático) no diría que es amable y autosuficiente y que se alimenta de ratones: más bien argüiría que está orientado-a-objetos” (Roger King). Oh, oh, hay que protegerse de la tontería. La literatura sobre Bases de Datos y Orientación-a-Objetos y, en general, sobre sistemas persistentes está poblada de informes técnicos, de implementaciones comerciales y de aventurados esquemas de investigación. En la bibliografía que sigue me centraré en los títulos que no requieren un bagaje técnico excesivo, favoreciendo las visiones simplistas que, al final, generan una cierta cultura de Bases de Objetos.

• Object-Oriented Concepts, Databases, and Applications , editado por Won Kim & Frederick H. Lochovsky, 1989, Addison-Wesley, 0-201-14410-7. Este temprano texto contiene artículos muy citados (como el de Roger King, “Mi Gato está orientado-a-objetos”, que proporciona una leve visión sobre modelos semánticos), aunque los dedicados a las bases de objetos han quedado un tanto “historizados”, manteniendo empero un unos aspectos intencionales de lectura aconsejable.
  
• Object-Orientation: Concepts, Languages, Databases, User Interfaces , Setrag Khoshafian & Razmik Abnous, 1990, John Wiley & Sons, 0-471-51801-8. Este libro es un tanto viejo y bastante elemental, aunque confieso que le dispenso cierta simpatía (que por definición podría calificarse de afinidad con lo inútil). Las ideas presentadas aquí son claras -por simples- y leves -por meramente intuitivas-: así, por ejemplo, la parte dedicada a Interfaces de Usuario Orientados-a-Objetos rebosa candor desde nuestra perspectiva actual. El libro se constituye, pues, en una introducción amable a esta área tecnológica.
  
• Object Data Management: Object-Oriented and Extended Relational Database systems , R.G.G. Catell, 1991, Addison-Wesley, 0-201-53092-9. Este es uno de los textos más apreciados por gestores en relación al soporte de decisiones sobre las Bases de Objetos. Cattell, un “activista” del sector, plantea un texto con afan de completitud que revisa todos los tópicos de la Tecnología, incluyendo un repaso de sistemas tradicionales, una panorámica de los nuevos conceptos de gestión de información, algunas ideas sobre implementación, un detalle de objetivos y la revisión sumaria de bastantes productos, para acabar con unas agradables referencias bibliográficas brevemente comentadas.
  
• Object-Oriented Databases , Setrag Khoshafian, 1993, John Wiley & Sons, 0-471-57056-7. Yo diría que este es un “texto para gestores (managers)” en el que, tras la consabida y evitable introducción genérica a la Tecnología de Objetos, se muestran algunos aspectos básicos y prácticos de las OODBMSs: modelado, diseño, persistencia, versionamiento, transacciones, concurrencia y ... arquitectura cliente-servidor. Se puede leer de un tirón, lo que es bueno y malo, naturalmente.
  
• Sistemas de Bases de Datos Orientadas a Objetos: Conceptos y Arquitecturas , Elisa Bertino & Lorenzo Martino, 1993 (traducción 1995), Addison-Wesley Iberoamericana, 0-201-65356-7. Hay que decir que el Dr. Miguel Katrib ha realizado una traducción magnífica de este texto, que se transforma así en el único en castellano que aborda de forma seria algunos aspectos genéricos teóricos y prácticos sobre las Bases de Objetos: indexación, consultas, evolución dinámica de objetos y esquemas, modelos de datos y mecanismos de autorización se sopesan entre ejemplos aplicados, fundamentalmente, a GemStone, O 2 e Iris. Siendo, empero, un texto académicamente absolutamente recomendable, adolece de cierta vaguedad anímica si se considera como lectura de convencimiento para gestores de proyectos y programadores en general. En resumen: si su bibilioteca ha de constar de más de un libro, compre también éste.
  
• The Object Database Standard: ODMG-93 , editado por R.G.G. Catell, 1994, Morgan Kaufmann Publishers, 1-55860-302-6. Con la intención de normalización “de facto” subyaciendo en cada párrafo, este libro, instructivo y afortunadamente breve, es de lectura obligada no tanto por la realidad que refleja sino por la pretensión formalizadora que insufla.
  
• Object-Oriented Databases: Technology, Appllications and Products , Bindu R. Rao, 1994, McGraw-Hill, 0-07-051279-5. En este libro asistimos a una demostración de conocimientos prácticos un tanto deslavazada, aunque útil para determinados lectores: Rao nos lleva a galope por capítulos triviales y relatos recopilatorios entre los que cruzan exposiciones de algunas Bases de Objetos comerciales: ObjectStore, Versant, Objectivity/DB; y en menor medida GemStone, IRIS, UniSQL y otras. El texto aparece adecuado para gestores que deseen asimilar de forma rápida las técnicas y esquemas más usados en los productos comerciales, aunque adolece de coherencia. Yo suelo, no obstante, recomendar la lectura directa de los manuales de las distintas OODBMSs, pues éstos suelen incluir unas buenas introducciones genéricas y usualmente están pedagógicamente estructurados para su pronta asimilación.
  
• Object Databases: The Essentials , Mary E. S. Loomis, 1995, Addison-Wesley, 0-201-56341-X. Debo reconocer mi debilidad por la Dra. Loomis: el libro, al igual que sus columnas periódicas en el JOOP, está escrito en un lenguaje sorprendentemente claro que hace gala de un pragmatismo agradable y natural. La exposición está bien estructurada, es amena, encaja a la vez con un público técnico y de gestión, y resulta, al fin, en un buen sabor post-lectura. La asunción, por otra parte, de distintos puntos de vista (del administrador, del programador, etc.) confiere al texto una perspectiva única que se convierte en perfecta guía respecto de las distintas opciones teóricas: si la persistencia ha de ser ortogonal al tipo, si el enfoque pesimista de concurrencia es apropiado, etc. El texto es totalmente autónomo, aunque es opinión general que complementa el más antiguo de Cattell. En verdad que si sólo ha de comprar un libro sobre Bases de Objetos, elija éste.
  
• Modern Database Systems: The Object Model, Interoperability, and Beyond , editado por Won Kim, 1995, Addison-Wesley, 0-201-59098-0. Siguiendo un esquema similar al texto del 89, aparecen aquí muchos artículos de distintos autores que se estructuran en dos capítulos tecnológicos: Bases de Datos de Próxima Generación e Interoperabilidad con Bases de Datos Preexistentes. La adecuada disposición de las contribuciones, mayormente originales para el texto, permite una lectura secuencial y muestra una precisa visión del estado actual de la Tecnología.

[1] El lector aprensivo puede ojear mi columna “Prestigio Informático” en RPP, noviembre 95, donde se hace mofa y befa de negaciones de la misma calaña. Aunque, vaya, nadie dijo que yo fuera especialmente prudente.

[2] Cuando formulo esta pregunta ante equipos de análisis y diseño estructurados la respuesta invariablemente es: “¡Por supuesto! ¡Es lo que hacemos a diario!”

[3] El equivalente gastronómico es claro: el cocinero eficaz es, a efectos del comensal, un “wrapper” entre los simples alimentos y las pesadas composiciones culinarias. Evidentemente, cuando las viandas poseen calidad, sabor y textura per se, el cocinero se troca en mero transportista: vamos, la antítesis de la nouvelle cousine.

[4] Incidentalmente cabe notar que, como en otros ámbitos, la mejor manera de solucionar los problemas de integridad referencial es precisamente ignorarlos. GemStone, por ejemplo, impide la eliminación efectiva de cualquier objeto apuntado por otro, posponiendola hasta que el objeto quede totalmente desreferenciado y entre en marcha el recolector de basura.