RVZ

Como comentaba en el post anterior, en este artículo voy a hablar sobre la solución que estamos adoptando y porque hemos descartado algunas de las alternativas.

El modelo de datos

Lo primero que consideramos fue como modelar la realidad que tenemos. Pensamos, inicialmente, en un modelo como el que se muestra a continuación:

Inicialmente nos centramos en modelar los cálculos. Los cálculos deberían tener una magnitud a medir, las unidades en las que se mide esta magnitud, y el valor calculado. Así mismo, podría tener uno o varios valores de entrada o condiciones iniciales. Y además debería de tener un origen para identificar de donde proviene ese calculo.

Lo siguiente en ser modelado fueron los valores de entrada o condiciones iniciales, ya que queríamos que el sistema fuera bastante dinámico pensamos en condiciones iniciales como una magnitud, con la unidad correspondiente y su valor. Esto nos permitiría meter valores de entrada bastante complejos, pero tendríamos que crear unidades ficticias para aquellos valores de entrada que no tengan unidades de medida, como por ejemplo la configuración electrónica.

Teniendo ya los cálculos y los valores de entrada, lo siguiente a modelar fueron las unidades. Cada unidad podía tener un símbolo y un valor que contendrá una descripción más detallada de la unidad.

Finalmente modelamos las magnitudes que contendrán un valor con una descripción de la magnitud, y las fuentes con  una descripción del origen como valor.

Implementación

Para implementar el modelo descrito decidimos usar CouchDB, como ya hemos comentado anteriormente, ya que nos permite trasladar fácilmente el modelo dinámico que hemos explicado.

Pensamos en usar vistas para generar las posibles búsquedas sobre los diferentes parámetros, pero nos dimos cuenta de que la forma de filtrar y realizar búsquedas se nos quedaba muy corta para nuestras necesidades. Así que finalmente optamos por usar CouchDB-Lucene para generar indices de los documentos y poder realizar búsquedas más complejas.

Luego pensamos en donde colocar la aplicación. Primero pensamos que sería una idea genial aprovechar las ventajas de CouchDB e intentar que la aplicación migrase como mismo lo hacen los datos. Pero esta solución no nos era válida, ya que queríamos ofrecer una interfaz REST y al almacenar la aplicación como un documento en CouchDB siempre tendríamos que hacer un GET. La alternativa era tener un servidor web que se encargase de recibir la petición REST y generase las llamadas a CouchDB. Con esto obtendríamos varias ventajas de una sola vez, tendríamos la interfaz REST, podríamos definir un API mucho más cercano a nuestro problema en vez de atacar a CouchDB directamente, y además tendríamos autenticación web. Además podríamos programar la aplicación en el lenguaje que quisiéramos y no nos veríamos atados a JavaScript. Así que finalmente optamos por esta opción, programando la aplicación en Ruby con Sinatra (aún en desarrollo), pero no hemos abandonado del todo la idea de que la aplicación migre.

Arquitectura Calculus

En los próximos post hablaré de todo el desarrollo en concreto, como generamos los indices con CouchDB-Lucene, como usamos Sinatra y demás. Prometo que serán mucho más técnicos.