Genera tus Entidad/Relación circulares con SchemaBall-PHP

Gráfico generado con SchemaBall-PHP

Inspirándome en el SchemaBall de Martin Krzywinski este fin de semana he escrito SchemaBall en PHP. Se trata de un generador de gráficos que representan las tablas de una base de datos y sus relaciones, al estilo de un diagrama entidad/relación. Aún está bastante verde, y la mayor carencia que tiene es que no distingue relaciones de cardinalidad N:N, es decir, aquellas donde la relación está expresada en una tabla intermedia y dos claves foráneas. Además, sólo es compatible con MySQL, aunque mi intención es darle compatibilidad con más gestores de bases de datos, e integrarlo en MagiSQL, del que tendrás noticias en breve ;-)

Por lo demás, añadiré al gráfico alguna representación de los campos, para poder visualizar la complejidad de las tablas de algún modo. Además, me gustaría añadirle interactividad, pero para ello habría que cambiar completamente la plataforma gráfica, pasando de imágenes PNG generadas con GD al Canvas de HTML o incluso Flash.

En fin, sólo es un adelanto para una librería que espero que crezca y se convierta en una herramienta útil para los diseñadores/administradores de bases de datos. ¿Opiniones? ¿Sugerencias? ¿Críticas? ¿Insultos racistas? Los comentarios están abiertos y en cuanto el SVN me funcione (hoy los astros se han alineado favorablemente xD) subiré el código.

PD: la librería para generar este tipo de gráficas estará disponible de forma independiente, para que se pueda utilizar para información diferente al esquema de una base de datos.

Bases de datos orientadas a objetos, la plataforma óptima para la Web Semántica

Una de los últimas tendencias en el desarrollo de software orientado a objetos es el abandono de las bases de datos relacionales como sistemas de almacenamiento, en favor de bases de datos orientadas a objetos (por ejemplo, ZODB es la base de datos orientada a objetos de Zope, el potente framework de desarrollo para Python), o bien sistemas que, aun utilizando un DBMS relacional aportan una capa de abstracción al programador para crear objetos persistentes (Object-Relational Mapping, ORM), por ejemplo Hibernate o Doctrine.

Con la aparición en escena de estos sistemas de almacenamiento, surgió la polémica entre seguir usando los seguros, estables y rápidos RDBMS o sencillamente almacenar los objetos que maneja internamente el programa, prescindiendo de DAOs y demás inventos.

Hoy en día la papeleta se soluciona con motores de persistencia (capas de abstracción para guardar objetos que se apoyan sobre BBDD relacionales), como el ya citado Hibernate; aunque existen Sistemas de Gestión de Bases de Datos orientadas a objetos, como ZODB (Zope Object Database), que ofrece resultados muy buenos en cuanto a rendimiento y seguridad. Destaca también OpenLink Virtuoso, un puente entre SQL y RDF/XML. En Wikipedia se resume muy bien el concepto de persistencia de objetos.

Bases de datos orientadas a objetos, diseño y semántica

Todo este rollo viene a cuento de la Web Semántica, y su evidente estructura orientada a objetos (iba a poner un enlace a la especificación del RDF-Schema pero no quiero quedar como un pedante con semejante tostón). Pero no sólo es una cuestión de estructura. Las bases de datos orientadas a objetos, y sobre todo las bases de datos semánticas, ofrecen una flexibilidad muy apropiada para proyectos web (no sólo “3.0”). Y el mejor ejemplo que he encontrado es Plone, el gestor de contenidos para portales web basado en Zope, permite crear archetypes de información que Zope/ZODB manejan de forma semi-automática, permitiendo extender el portal rápidamente.

El caso es que la elección entre DBMS relacional y orientado a objetos depende de la orientación del problema a solucionar: si pretendes hacer un portal web grande (para una universidad o algo así), un sistema para gestión colaborativa del conocimiento o un proyecto que simplemente tenga que ser muy flexible y escalable, es muy probable que la mejor opción sea una base de datos orientada a objetos. También son útiles las BBDD orientadas a objetos (y además embebidas, como son la mayoría) para programas sencillos que no procesen grandes volúmenes de datos. En este último caso también son adecuadas las bases de datos basadas en pares atributo-valor, que resultan extremadamente sencillas, y cuyo máximo exponente es la oferta SimpleDB de Amazon Web Services. Aunque si no quieres “volar en la nube” también está BerkeleyDB (de hecho, es una de las tecnologías que usa SimpleDB). De todos modos, de bases de datos “”minimalistas”” hablaremos otro día.

En medio de esta jungla, para muchos desconocida por su novedad y poca penetración en el mercado (los consultores se sienten seguros con Oracle), surgen las Bases de Datos semánticas. Están manejadas por bibliotecas como Jena o RdfLib y consultadas por un “safari” de lenguajes como RDQL, SeRQL o SPARQL (este último iniciativa del W3C), un poco inmaduros para ser usados de manera extensiva. Hoy en día se usan para software de gestión del conocimiento, tesauros, biblioteconomía… casi todas ellas bases de datos privadas.

En la otra cara de la moneda tenemos la propuesta de Tim Berners-Lee, su visión de la Web Semántica en la que “sirvientes” software nos hacen el trabajo, compran entradas para el cine o buscan exactamente qué jugadores de la selección uruguaya de fútbol jugaron en el último mundial con un dorsal mayor a 10. Pero abrir las bases de datos y semantizar todo la información de la red (que es una utopía) no es el único camino para aplicar las tecnologías semánticas en Internet.

Pensemos en RDF. Es el lenguaje base de las tecnologías semánticas. Con sus “triplets” (sujeto, predicado y objeto) se construyen las estructuras de conocimiento y las ontologías. RDF se puede expresar en XML. XML es una buena manera de almacenar objetos. XML se puede procesar con diferentes extensiones: XSL-T, Xpath, Xlink, Xforms… y construir páginas web enteras sin usar prácticamente ni HTML ni programación en el lado del cliente. Pero aún hay más, la arquitectura REST es la óptima para la publicación de objetos. ¿Eins, y eso qué es? Pues la publicación de objetos es sencillamente eso: publicar los objetos persistentes en el servidor web. Por ejemplo, el Zpublisher de Zope (sé que soy repetitivo, pero cada vez confirmo más que Zope es la plataforma perfecta para aplicaciones semánticas): el usuario envía una petición (en principio una URI por HTTP, pero Zope permite publicar objetos incluso a través de FTP, WebDAV y XML-RPC), Zpublisher busca el objeto entre su Base de Datos y lo devuelve.

¡Anda, la arquitectura es como en un servidor de Bases de Datos! ¡Y como en los servicios web (los servicios web trabajan con XML, y hemos dicho que XML es un buen lenguaje para expresar objetos)!. De hecho, Zpublisher publica objetos a través de XML-RPC, algo que al lector atento no hace falta repetir ;-P. Es decir, que si hago una aplicación web en Zope con mis objetos persistentes, ZPublisher automáticamente creará servicios web para que otros sitios puedan interactuar con mi programa. Y si a esa Base de Datos orientada a objetos (expresable en XML) le agrego metadatos semánticos (algo fácil de hacer en XML, gracias a los namespaces y a los RDF-Schema), es posible disponer de servicios web semánticos. Fíjate hasta que punto Zope es el más indicado para estos menesteres su nombre significa Z Object Publishing Environment.

En fin, un buen comienzo, implementable sin grandes dificultades, para posibilitar un nodo inteligente en la web semántica, que produzca contenido y metadatos y pueda colaborar con otros servicios. Y si es Zope, encima de todo ese framework y esa base de datos orientada a objetos podemos poner Plone, el gestor de contenidos con la curva de aprendizaje más jodida que conozco, y convertir nuestra semantizada instancia de Zope en un portal web, con todo lo que ello implica.

¿Qué hay detrás de Amazon SimpleDB?

Estos días he estado informándome sobre los Amazon Web Services, más concretamente el relativamente reciente SimpleDB, un poco por escepticismo hacia la moda del Cloud Computing, o mejor dicho, a la moda de hablar sobre el Cloud Computing (qué queréis que os diga, tampoco me parece tan novedoso el invento). El servicio es un gestor de BBDD no relacional y no orientado a objetos, situado en nosedonde, gestionado de nosequé manera (cloud computing, vamos). Este gestor de BBDD es tan sencillo de entender como que tenemos dominios y, dentro de los dominios, registros con pares propiedad-valor. Estos pares no están definidos, por lo que podemos decir que es una base de datos sin esquema, sin estructura previamente definida. Genial, parece útil para ciertos programas.

El caso es que desde hace algún tiempo estoy recopilando información sobre Oracle BerkeleyDB (Oracle compró SleepyCat, desarrolladora original), un gestor de bases de datos embebido, no relacional, no orientado a objetos, y encima Open Source. Genial, parece útil para ciertos programas. Coño, dejá vu. Y encima voy a la web de BerkeleyDB y me encuentro este case study de Julio de 2008 en el que Tim Kohn, jefe de servicios explica que BerkeleyDB es usado como caché para la gran base de datos de Amazon (como tienda, no como proveedor de servicios web), delante de un Oracle DB normal (el artículo indica el talento que tienen en Amazon).

Interesante. Buscando un poco más me encuentro con que el desarrollo de Amazon para integrar BerkeleyDB, Oracle y los demás sistemas ha evolucionado y le han llamado Dynamo. Aunque su autor empieza diciendo que:

Dynamo is not directly exposed externally as a web service; however, Dynamo and similar Amazon technologies are used to power parts of our Amazon Web Services, such as S3.

…aunque teniendo en cuenta que fue publicado hace un año, la verdad es que es bastante probable que SimpleDB sea una interfaz, o directamente instancias, de Dynamo, esa combinación de BerkeleyDB y MySQL:

[...] BDB can handle objects typically in the order of tens of kilobytes whereas MySQL can handle objects of larger sizes. Applications choose Dynamo’s local persistence engine based on their object size distribution. The majority of Dynamo’s production instances use BDB Transactional Data Store.

Conclusiones:

  • Leyendo ambos artículos uno se da cuenta de lo buenos que son los informáticos de Amazon. Normal, dado que son una de las empresas más potentes de Internet y manejan una de las Base de Datos comerciales más grandes del mundo.
  • Open Source matters, como dicen los de Joomla. Y las empresas lo saben, cada vez mejor. Y sobre todo por las malas lenguas que desprecian a MySQL como RDBMS incompleto en comparación con PostgreSQL. Soy fanático de MySQL y es cierto que es un DBMS muy sencillo, está algo verde y en algunas cosas resulta “de juguete” (sobre todo en comparación con el gigante Oracle), pero la escalabilidad y rendimiento que ofrecen lo hacen líder para Internet y entornos como los de AmazonWS.
  • En el caso de BerkeleyDB ha habido una apuesta fuerte por parte de Oracle, aunque Amazon ya la usaba antes de ser adquirida por el grande de Redwood City. Un DBMS original, sencillo, que desafía a los tradicionales RDBMS que nos enseñan en la universidad como la única solución posible. Además, existe BerkeleyDB XML, una interesante Base de Datos estructurada que emplea XQuery. Puede dar mucho que hablar en el futuro, sobre todo de cara a las BBDD semánticas.
  • El cloud computing en BBDD, como las demás tendencias 2.0 (odio esa etiqueta, la odio, la odio!!) no aporta ninguna innovación tecnológica (en este caso Dynamo ha sido un implementación para hacer posible una aplicación, pero BDB y MySQL ya existían), pero es una gran oportunidad para ahorrar costes en mantenimiento y tiempo en desarrollo.

¿Qué opinión os merece SimpleDB? ¿Y los servicios de cloud computing en general? ¿Os gustan, no os gustan, ponen en peligro vuestros empleos…?