Jummp’s Blog

Sigamos con la teoría.

La base del desarrollo de Datawarehouse o Datamarts independientemente de que se opte por una implementación basada en cubos, por una implementación basada en un modelo de datos optimizado para el análisis de la información o por ambas, se basa en un procedimiento denominado ETL (Extract, Transform and Load) que tiene como objetivo, en líneas generales, coger los datos desde las distintas fuentes origen, que pueden ser bases de datos de los sistemas operacionales, ficheros ofimáticos, etc…, transformarlos a unidades coherentes con el modelo o modelos con los que se va a trabajar y cargarlos en dichos modelos.

Como es lógico, la existencia de un proceso ETL y las bases teorícas presentadas en la anterior entrada implica que la información con la que se trabaja en los sistemas de soporte a la decisión no es información en línea, existiendo por tanto un tiempo de desfase entre la información “fresca” de los sistemas operacionales fuentes y la información con la que se trabaja en los almacenes de datos. Dependerá del tipo de información que se maneje (también influirá el volumen) la ventana de tiempo que se deja entre actualización y actualización del Datamart o del Datawarehouse. Si la ventana del tiempo es adecuada, no tendrá importancia que la información con la que se trabaja no esté en línea.

También es conveniente destacar que en función de la solución de Business Intelligence que se aplique, en ocasiones se actualizará la información del almacén de datos con datos nuevos procedentes del operacional (realizándose los ajustes necesarios si fuera preciso, por actualizaciones que afectan a registros ya cargados) y en otras será más rentable un borrado y carga completo.

Un poco de teoría.

No se recomienda la implementación de almacenes de datos corporativos (Datawarehouse) o almacenes sobre una problemática concreta del negocio de la organización (Datamarts) en el mismo sistema y/o espacio de los sistemas operaciones (OLTP: On-Line Transaction Processing), ya que requiere modelos de datos orientados a la consulta de la información (modelos en estrella o copo de nieve) y no se quiere interferir el funcionamiento de los sistemas transaccionales con la capacidad de proceso que requiere un proceso de ETL realizado sobre las tablas del operacional cada vez que se requiera una consulta o con la necesidad de proceso que se requiere para consultar la información si se está trabajando incluso con sistemas orientados a cubos.

Es decir, la teoría tradicional recomienda entornos distintos para los sistemas operacionales y para los sistemas orientados al soporte a la decisión, de manera que unos no influyan sobre los otros.

En los sistemas de soporte a la decisión, sobre todo aquellos orientados a los cuadros de mando y al análisis OLAP, la solución de modelado de datos se recomienda que esté orientada a modelos en estrella o copos de nieve, basados en la existencia de una o más tablas de hechos que muestran cada una de ellas un indicador a medir y las dimensiones, que no es otra cosa que los diferentes puntos de vista por los que se puede consultar un indicador, por ejemplo, punto de vista temporal, punto de vista geográfico, etc… Para sistemas orientados al reporting o al análisis puro y duro de la información es más recomendable otras soluciones, ya que en estos casos no resulta tan interesante la información agregada, siendo más importante tener la información en detalle.

Mi recomendación es que si se necesita una solución mixta, basada por un lado por cuadros de mando y análisis OLAP y por otro por reporting o análisis de la información, se implementen dos soluciones, una orientada a los modelos en estrella o modelos copo de nieve y otra basada en la desnormalización del modelo de datos operacional quedándonos solo con la información que se precisa o se prevé precisar para la confección de los listados o para la realización del análisis de la información.

Independientemente de que la solución óptima para el tipo de información que se requiere y el perfil del usuario sean cuadros de mando, reporting, análisis dinámico de la información o una combinación de ellas, el desarrollo de un sistema de estas características debe ser iterativo y es necesario hacer el esfuerzo que haya que hacer para que el resultado cumpla al máximo las espectativas del usuario, por lo que si las iteraciones deben seguir una vez que la solución esté en producción es necesario hacerlo. Hay que evitar que el producto no quede del todo fino por no haber recorrido esa milla extra que puede convertir en sobresaliente un producto que sin ella se quede en un aprobado raspado.

Un buen sistema de soporte a la decisión (se entiende un buen sistema aquel que verifique las expectativas del usuario) que se base en 1 o más sistemas operacionales de base, garantizará el uso cada vez más extendido y con mayor calidad de dichos sistemas operacionales, ya que quienes saquen provecho del sistema de soporte a la decisión se preocuparán porque los sistemas de base estén lo mejor alimentados de información posible.

La colaboración del usuario para el desarrollo de un sistema de estas características resulta esencial. Sin una colaboración activa del usuario será complicado encontrar una solución que le satisfaga completamente, ya que quien conoce qué necesidades en materia de información o conocimiento requiere es el usuario final. En el proceso de análisis y en la presentación de prototipos iterativos, es conveniente siempre hacerle ver al usuario sobre qué aspectos puede obtener información y conocimiento y sobre cuáles no, ya que el usuario o usuarios que definen el sistema de soporte a la decisión no tienen por qué saber con detalle las características de la información que se graban en los operaciones y la calidad de la misma. Por tanto, hay que saber indicar los límites que existen para evitar falsas expectativas.

El desarrollo de sistemas de soporte a la decisión supone el fin último de la informatización de procesos de una organización que no es otro que extraer información y/o conocimiento a partir de la información que se genera en los procesos de gestión u operacionales.

El desarrollo de este tipo de sistemas no es complejo, pero para conseguir soluciones válidas es conveniente seguir una serie de recomendaciones:

1) Es necesario identificar cuáles son las necesidades de información que existen. Es decir, no es lo mismo que se necesite información de detallada (solución de reporting o de análisis de datos), cuadros de mando o la verificación o extracción de hipótesis de negocio (minería de datos).

La solución óptima a aplicar para cada caso es diferente por lo que antes que empezar hay que tener muy claro qué necesidades existen y qué quiere el usuario.

2) Otra característica que hay que identificar es el tipo de usuario que necesita la información y su cualificación técnica para utilizar soluciones más complejas o avanzadas.

Es decir, no es lo mismo que el usuario sea la alta dirección, un analista de información o un administrativo de la organización.

3) Es necesario hacer un estudio previo de la calidad del dato de los sistemas de información implicados. Aunque el análisis de datos permite sin duda detectar la calidad de los mismos, es mejor hacer un estudio a priori sobre los mismos, porque lo mismo interesa retrasar la implantación de sistemas de soporte a la decisión hasta que los datos ganen en calidad y dirigir los esfuerzos a esa tarea.

4) Si la organización no tiene implantada ninguna solución de Business Intelligence, es conveniente hacer una estimación a corto y medio plazo de lo especificado en 1) y en 2) y del volumen de información que se va a tratar en el desarrollo del sistema de soporte a la decisión. De ello va a depender mucho la solución de Business Intelligence a utilizar. Mi recomendación es que se opte por soluciones de bajo coste que permitan obtener resultados a muy corto plazo, nada de buscar soluciones monstruosas desde el primer momento, siempre hay tiempo de evolucionar hacia soluciones más complejas.