Índice:

1. Para los impacientes.
2. Origen de la idea.
3. Instalación.
4. Como generar los diagramas.
5. Funcionalidades futuras.
6. Como colaborar.

Para los inpacientes:

Para los inpacientes, aqui tenéis un par de screenshots:

...O también lo podáis ver "en acción" en:

http://bulmages.bulma.net/erm/

Origen de la idea:

Hace poco he sido "llamado a filas" al proyecto Bulmagés porque se estaba pensando en arrancar el módulo de facturación y TPV (actualmente Bulmagés sólo es contabilidad) y como que, como por muchos es sabido, yo estaba interesado y, de hecho ya estaba haciendo cosas por mi cuenta, me invitaron a colaborar en el proyecto.

La idea era empezar con un TPV porque hay una persona a quien le interesa y está dispuesta a currar por tenerlo listo en poco tiempo. Va bien marcarse objetivos y este es uno fácilmente asumible.

Pero todos coincidimos en que hacer un TPV sin antes tener definida la Base de Datos de toda la gestión supondría que al ponernos a trabajar en ésta, seguramente nos veriamos obligados a hacer cambios serios en la implementación del TPV, cosa que es duplicar trabajo.

Por esta razón nos basamos en la documentación de la "media gestión" que yo tengo funcionando en la empresa en la que trabajo para hacer el diseño de la base de datos de la futura BulmaFACT. Y el primer problema con que nos encontramos fué que aquel diagrama no se correspondia al 100% con la base de datos actual porque ésta ha sufrido modificaciones que no siempre he dispuesto de tiempos de actualizar al modelo Entidad-Relación y hacerlo cuadrar con el relacional y el SQL de la Base de datos.

Por lo tanto, tuve que partir del modelo ER que tenía y repescar las mejoras de notas sueltas y de consultas directas sobre la BD en producción. Y, lógicamente, es previsible que el resultado sea objeto de modificaciones futuras puesto que se pretende que todo aquel que esté interesado pueda participar en el desarrollo del proyecto.

Además ésto añade una complicación extra: Si muchas personas tienen que participar en el diseño del modelo de datos, es difícil que todos entiendan a la perfección la finalidad de entidades o campos concretos colocados por otras personas. Si esto ya es un problema cuando el diseño de la base de datos la hace una sola persona y hemos de ir tomando nota de nuestros propios pensamientos para luego ser capaces de entenderlos en el futuro, imaginaros cuando tienen que ser entendidos por muchas personas.

Resumiendo, necessitábamos un modelo ER:

1. Fácilmente modificable.
2. Rápido de consultar.
3. Fácilmente comprensible:
• Tanto por el autor...
• ...como por terceras personas que lo tengan que consultar.
4. Y si no es mucho pedir que modificando una sola fase del diseño, el resto se puedan generar automáticamente.

Creo que los tres primeros puntos los hemos conseguido. Y el cuarto está en el TO-DO (el proyecto es joven todavía ;-)) pero creo que no será demasiado difícil de conseguir.

Para entender la idea, si pensamos en la naturaleza de un diagrama *ER, veremos que consta de dos partes:

• Una lista de entidades con la correspondiente enumeración de los campos que la componen y con indicación de cual es el campo o campos que forman la cllave primaria.
• Un esquema gráfico dónde se representan estas entidades y las relaciones que hay entre ellas (que, como sabemos, a veces podan contener algún campo de datos).

La lista de entidades es fácil y se puede hacer con cualquiera editor de texto plano (vi comes for help! :-)). Pero cuanto más grande es el cociente entre el número de relaciones y el de entidades, más difícil es conseguir una representación gráfica clara y legible (incluso con lápiz y papel) de las relaciones existentes entre las entidades. Por eso es tan difícil encontrar una herramienta CAD adecuada.

Como que esto suponía un gran contratiempo decidí, en lugar de dibujar el diagrama, redactar también una lista de las relaciones indicando las entidades que relacionan, con qué cardinalidad y, de haberlos, los campos de datos pertinentes. Y que cada cual se dibuje, si quiere, su propio diagrama de todo o de la parte que el interese, pero que el formato "oficial" del modelo ER seria el texto plano.

Con esto se solucionaba el punto 1 puesto que, por ejemplo, para añadir una relación al diagrama nada más rápido que escribirla. Y así surgió la idea que solucionaría el punto 2, porque Crear una aplicación capaz de leer e indexar toda esta información era relativamente trivial y, si bien plasmarla toda de golpe y que quedase legible es, como hemos dicho, poco menos que imposible, representar una entidad y, al lado, todas las entidades con que se relaciona y dibujar las relaciones, también era un problema relativamente sencillo.

El problema hubiera sido hacerlo a mano (repetición de trabajo) o consultarlo (ir hacia delante y hacia atrás por un montón de páginas para seguir el trazado del esquema). Pero la idea, era hacer esta misma representación en formato web de manera que, hiperenlazando las entidades, esta navegación se convertiría en instantánea.

Ahora sólo nos quedaba el punto 3: Hacer que el diagrama fuera fácilmente comprensible. En primer lugar por el propio autor, tarea que, como todos sabemos, corresponde a un documento aparte del modelo ER denominado Diccionario de Datos y que se debe hacer al mismo tiempo que se diseña el modelo ER porque si no después no nos acordamos de porqué eran la mitad de cosas. Pero que a la práctica todo el mundo lo hacía después por lo engorroso que resulta pasar constantemente del ratón al teclado y viceversa (ahora podemos, por ejemplo, tener dos pestañas del konsole con vim para editar simultáneamente MER y DD sin tener que utilizar el ratón para nada. Además, tampoco hace falta consultarlo "aparte", sino que las descripciones de los campos nos salen al lado de éstos para la entidad que estamos consultando y en un cuadro emergente al pasar el ratón por encima (anchor con 'title') para los campos de las entidades hijas y las relaciones.

...y en segundo lugar, para terceras personas, caso en el cual sólo queda desear que el autor haya tomado buenas notas de lo que ha hecho y de porqué lo ha hecho si no queremos tener que preguntarle (o si él no quiere que le pregunten :-P).

Pero aun así, para quien no las ha escrito, puede ser complicado encontrar una nota en el momento en que la necesita. Por esta razón, la aplicación también interpreta ciertos marcadores que podamos utilizar dentro el fichero de notas para:

• Delimitar secciones (con jerarquía).
• Marcar las notas como "TO-DO notes" (cosas a hacer) que salen en rojo, o "Recordatorios o cosas hechas".
• "Enganchar&qout; la nota a una o varias entidades o relaciones determinadas.

Finalmente, si existe un fichero denominado CHANGELOG.txt, en la vista general del diagrama sale reproducido debajo de manera que si tenemos diferentes versiones podamos ir anotando los cambios que vamos realizando en comparación con la versión anterior.