Cuando diseñamos la arquitectura de un sistema de Data Warehouse nos hemos de plantear los diferentes entornos por los que han de pasar los datos en su camino hacia su Data mart o cubo de destino. Dada la cantidad de transformaciones que se han de realizar, y que normalmente el DWH, además de cumplir su función de soporte a los requerimientos analíticos, realiza una función de integración de datos que van a conformar el Almacén Corporativo y que van a tener que ser consultados también de la manera tradicional por los sistemas operacionales, es muy recomendable crear diferentes áreas de datos en el camino entre los sistemas origen y las herramientas OLAP.
Cada una de estas áreas se distinguirá por las funciones que realiza, de qué manera se organizan los datos en la misma, y a qué tipo de necesidad puede dar servicio. El área que se encuentra 'al final del camino' es importante, pero no va a ser la única que almacene los datos que van a explotar las herramientas de reporting.
Tampoco hay una convención estandar sobre lo que abarca exactamente cada área, y la obligatoriedad de utilizar cada una de ellas. Cada proyecto es un mundo, e influyen muchos factores como la complejidad, el volumen de información del mismo, si realmente se quiere utilizar el Data Warehouse como almacén corporativo o Sistema Maestro de Datos, o si existen necesidades reales de soporte al reporting operacional.
Visto esto, comentaré a continuación las áreas de datos que se suelen utilizar, e iré perfilando una propuesta de arquitectura que cada uno ha de adaptar a sus necesidades o simplemente a su gusto en función de su experiencia.
Staging Area
Es un área temporal donde se recogen los datos que se necesitan de los sistemas origen. Se recogen los datos estrictamente necesarios para las cargas, y se aplica el mínimo de transformaciones a los mismos. No se aplican restricciones de integridad ni se utilizan claves, los datos se tratan como si las tablas fueran ficheros planos. De esta manera se minimiza la afectación a los sistemas origen, la carga es lo más rápida posible para minimizar la ventana horaria necesaria, y se reduce también al mínimo la posibilidad de error. Una vez que los datos están traspasados, el DWH se independiza de los sistemas origen hasta la siguiente carga. Lo único que se suele añadir es algún campo que almacene la fecha de la carga.
Obviamente estos datos no van a dar servicio a ninguna aplicación de reporting, son datos temporales que una vez hayan cumplido su función serán eliminados, de hecho en el esquema lógico de la arquitectura muchas veces no aparece, ya que su función es meramente operativa.
Hay quien considera que la Staging Area abarca más de lo que he comentado, o incluso que este area engloba todo el entorno donde se realizan los procesos de ETL, yo me decanto por su utilización sólo como área temporal.
ODS (Operational Data Store)
Como su nombre indica, este area es la que va a dar soporte a los sistemas operacionales. El modelo de datos del Almacén de Datos Operacional sigue una estructura relacional y normalizada, para que cualquier herramienta de reporting o sistema operacional pueda consultar sus datos. Está dentro del Data Warehouse porque se aprovecha el esfuerzo de integración que supone la creación del Almacén de Datos Corporativo para poder atender también a necesidades operacionales, pero no es obligatorio, y ni siquiera es algo específico del Business Intelligence, los ODS ya existían antes de que empezáramos a hablar de BI y de DWH.
No almacena datos históricos, muestra la imagen del momento actual, aunque eso no significa que no se puedan registrar los cambios.
Los datos del ODS se recogen de la Stage Area, y aquí sí que se realizan transformaciones, limpieza de datos y controles de integridad referencial para que los datos estén perfectamente integrados en el modelo relacional normalizado.
Hay que tener en cuenta que la actualización de los datos del ODS no va a ser instantánea, los cambios en los datos de los sistemas origen no se verán reflejados hasta que finalice la carga correspondiente. Es decir, que se irán actualizando los datos cada cierto tiempo, cosa que hay que explicar a los usuarios, porque los informes que se lancen contra el ODS casi nunca podrán estar tan 'al minuto' como los que existan en el sistema origen. Lo que sí se puede hacer es definir una mayor frecuencia de carga para el ODS que para el Almacén Corporativo. Si es necesario, se puede refrescar el ODS cada 15 minutos, y el resto cada día, por ejemplo.
Almacén de Datos Corporativo
El Almacén de Datos Corporativo sí que contiene datos históricos, y está orientado a la explotación analítica de la información que recoge. Las herramientas DSS o de reporting analítico atacarán principalmente a los Data marts, pero también se pueden realizar consultas directamente contra el Almacén de Datos Corporativo, sobretodo cuando sea necesario mostrar a la vez información que se encuentre en diferentes Datamarts.
En él se almacenan datos que pueden provenir tanto de la Staging Area como del ODS. Si ya hemos realizado procesos de transformación e integración en el ODS no los vamos a repetir para pasar los mismos datos al Almacén Corporativo. Lo que no se pueda recoger desde el ODS sí que habrá que ir a buscarlo a la Staging Area.
El esquema se parece al de un modelo relacional normalizado, pero en él ya se aplican técnicas de desnormalización. No debería contener un número excesivo de tablas ni de relaciones ya que, por ejemplo, muchas relaciones jerárquicas que en un modelo normalizado se implementarían con tablas separadas aquí ya deberían crearse en una misma tabla, que después representará una dimensión. Otra particularidad es que la mayoría de las tablas han de incorporar campos de fecha para controlar la fecha de carga, la fecha en que se produce un hecho, o el periodo de validez del registro.
Si el Data Warehouse no es demasiado grande, o el nivel de exigencia no es muy elevado en cuanto a los requerimientos 'operacionales', para simplificar la estructura se puede optar por prescindir del ODS, y si es necesario adecuar el Almacén de Datos Corporativo para servir a los dos tipos de reporting. En este caso, el área resultante sería el DWH Corporativo, pero a veces también se le llama ODS.
Data marts
Y por fin llegamos a la última área de datos, que es el lugar donde se crean los Data marts. Éstos se obtienen a partir de la información recopilada en el área del Almacén Corporativo. Cada Data Mart es como un subconjunto de este almacén, pero orientado a un tema de análisis, normalmente asociado a un departamento de la empresa.
Los Data marts se diseñan con estructura multidimensional, cada objeto de análisis es una tabla de hechos enlazada con diversas tablas de dimensiones. Si se diseñan siguiendo el Modelo en Estrella habrá prácticamente una tabla para cada dimensión, es la versión más desnormalizada. Si se sigue un modelo de Copo de Nieve las tablas de dimensiones estarán menos desnormalizadas y para cada dimensión se podrán utilizar varias tablas enlazadas jerárquicamente.
Este área puede residir en la misma base de datos que las demás si la herramienta de explotación es de tipo ROLAP, o también puede crearse ya fuera de la BD, en la estructura de datos propia que generan las aplicaciones de tipo MOLAP, más conocida como los cubos multidimensionales.
El paso del anterior área de datos a esta ha de ser bastante simple, cosa que además proporciona una cierta independencia sobre el software que se utiliza para el reporting analítico. Si por cualquier razón es necesario cambiar la herramienta de OLAP habría que hacer poco más que redefinir los metadatos y regenerar los cubos, y si el cambio es entre dos de tipo ROLAP ni siquiera esto último sería necesario. En cualquier caso, las áreas anteriores no tienen porqué modificarse.
