Cualquier propuesta de diseño o implementación de un Datamart o de un Datawarehouse termina chocando con el concepto de calidad del dato. De nada vale hacer una implementación modélica de los modelos de datos del Datamart o el desarrollo de unos procedimientos ETL que permitan extraer la información de diferentes sistemas o fuentes de información y coloquen los datos en el repositorio listos para ser explotados haciendo uso de las herramientas correspondientes, si al final el problema está en la base, en la información de partida, ya que si el objetivo final de todo Datamart es la explotación de la información con un determinado propósito, el resultado final estará contaminado si los datos de partida están contaminados.

Hace unos días en una reunión volvió a salir este tema, ¿se debe parar el desarrollo de Datamarts sin que los datos de partida estén del todo bien? Mi respuesta a esto es que si el desarrollo de Datamarts es un objetivo de la organización (como es en este caso), no debe parar la iniciativa el recurrente problema de la calidad del dato, ya que entre otras cosas, los Datamarts y las distintas alternativas existentes para explotar la información, tienen la ventaja de que permiten descubrir datos incompletos, inexistentes y erróneos, y además, el problema de la calidad del dato, es un tema que no se soluciona de manera sencilla y que generalmente se afronta como un proceso de mejora continua (en la mayoría de los casos bastante lento).

La calidad del dato está relacionada con la visión que tenga el usuario sobre la información que está grabando en el sistema, es decir, si considera que el sistema de información como un instrumento a corto plazo, en el que introduce unos datos y le proporciona unos servicios (y la calidad del dato no resulta fundamental para obtener el servicio), los datos por regla general no serán buenos, ya que el usuario no tiene conciencia de la utilidad que tiene que los datos estén más o menos completos o más o menos bien.

También existen otros factores, como la usabilidad del sistema de información (cuanto menos usable sea un sistema de información, peores serán los datos), la flexibilidad del sistema (este caso es un poco paradójico, ya que la flexibilidad de un sistema está intimamente ligada a su usabilidad), pero resulta que en un sistema muy flexible (sin apenas controles) se deja prácticamente la responsabilidad de lo que se graba en el usuario y por tanto en la visión que él tenga de la necesidad de grabar datos con calidad.

Otro factor muy importante es la visión corporativa que tenga la organización de la información, es decir, si en la organización no existe conciencia de que una información consistente, coherente y de calidad sobre una determinada temática, requiere de un repositorio de información de procedencia (aunque sea alimentado por distintas fuentes (distintos usuarios)) y que esos repositorios se alimentan a través de sistemas de información, será mucho más difícil que los datos que se graben tengan calidad, ya que la gestión se centra en cumplir con las tareas del día a día y no existen unas instrucciones generales o normativa interna, que por un lado obligue a utilizar los sistemas de información corporativos y por otro que haga que los datos que se introduzcan en ellos sean los más completos y exactos posibles.

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.