Consideraciones de diseño del data warehouse

La primera idea que a uno se le ocurre, cuando se piensa en construir un data warehouse, es la de abordar el proyecto en la misma forma en que hemos desarrollado siempre los sistemas operacionales: definición de requerimientos, análisis, diseño, construcción, pruebas e implantación. Esto es lo que tradicionalmente se llama el Ciclo de Vida del Desarrollo de Sistemas (o SDLC, en sus siglas en inglés).

Sin embargo, es un error pensar que esta forma de diseñar sistemas sigue siendo la adecuada para diseñar y construir el DW. Para empezar, el usuario del DW (el analista de negocio, utilizando herramientas de soporte a la toma de decisiones o DSS) funciona en modo descubrimiento. Raramente conoce de antemano aquello que necesita, por lo que utiliza un método de prueba y error para descubrir aquella información, contenida en los datos, que le es relevante. De la misma manera, los requerimientos del DW no se conocen con precisión hasta que se construye el DW y queda disponible para las tareas de análisis. Los requerimientos de los analistas de la información se descubren de forma similar a como ellos trabajan: mediante un proceso iterativo de prueba y error. En conclusión, dado que únicamente algunos de los requerimientos de proceso de la información pueden conocerse antes de empezar, hay una forma de desarrollo del DW que es completamente diferente del ciclo de vida tradicional del desarrollo de software.

"Perfection is spelled P-A-R-A-L-Y-S-I-S"

Winston Churchill)

El entorno del DW se construye de una manera completamente diferente a la forma en que se construyeron los sistemas operacionales de los que se nutre. El DW se construye mediante pequeños impulsos de desarrollo. Y el primer impulso no se consigue recogiendo y estudiando una enorme cantidad de requerimientos antes de comenzar. El desarrollador del DW debe tener siempre en cuenta la necesidad de moverse rápidamente hacia adelante, pasando por todas las fases del diseño y del desarrollo, aunque sea consciente de que los requerimientos de los datos y de los procesos no están completos en el momento de comenzar.

Por otra parte, tampoco hay que caer en la idea de que se puede comenzar con un prototipo del DW sin hacer un análisis de requerimientos.

Una forma de encontrar un punto intermedio entre estas dos actitudes erróneas es efectuar la recogida y análisis de requerimientos informacionales durante un tiempo determinado previamente (digamos que entre una semana y varios meses). De esta forma, los requerimientos más importantes y obvios se recogen durante ese tiempo y se puede comenzar a diseñar el modelo de datos del DW.

El modelo de datos

Es el punto de comienzo para el desarrollo del DW. Es como un mapa que nos debe guiar durante el proceso de desarrollo y sin el cual es difícil construirlo.

El modelo de datos del DW se construye a partir del modelo de datos corporativo. Sin embargo, dado que las técnicas clásicas de modelado de datos no hacen distinciones entre el entorno operacional y el de soporte a decisiones, hay ciertas transformaciones que deben realizarse para crear el modelo de datos del DW a partir del modelo de datos corporativo. Es evidente que, para poder utilizar el modelo de datos corporativo, éste debe estar construído y listo para utilizar. En particular, el modelo de datos corporativo ha de identificar y estructurar, por lo menos, las siguientes áreas:

- las áreas principales de la empresa

- las relaciones entre las áreas

- un diagrama entidad-relación (ERD)

- para cada área principal:

Claves

- atributos

- subtipos

- conectores de un área a la siguiente

- agrupaciones de atributos

El modelo de datos corporativo puede incluir también información acerca de los procesos (descomposición funcional, diagramas de flujo de datos, pseudocódigo, etc.). Esta información siempre es interesante, pero es aplicable al entorno operacional y no al DW. El modelo de datos corporativo suele estar descrito a alto nivel y a medio nivel. Este último contiene claves, atributos, subtipos, conectores, etc. No todos los modelos de datos ni todas las áreas tienen el mismo nivel de detalle, aunque esta carencia no es un inconveniente serio porque el DW se irá diseñando en fases sucesivas.

Las transformaciones

Suponiendo que tenemos un modelo de datos corporativo del cual partir (y si no existe o no se puede utilizar, convendría investigar la oportunidad de utilizar como punto de partida un modelo de datos genérico, adquirido en el mercado), el proceso de transformación hacia el modelo de datos del DW puede comenzar. Las transformaciones más inmediatas que nos permitirán diseñar el modelo de datos del DW, son:

- eliminar los datos puramente operacionales,

- añadir un elemento de tiempo a la estructura de las claves,

- añadir datos derivados,

- transfomar las relaciones de datos en artefactos de datos,

- acomodar los diferentes niveles de detalle de la información,

- fusión de datos de diferentes tablas,

- creación de ocurrencias de datos,

- agrupación de datos, en función de su estabilidad.

La decisión de eliminar los datos puramente operacionales raramente es evidente. La decisión se centra siempre alrededor de la pregunta "¿qué probabilidad hay de que este dato se utilice para la toma de decisiones?". Desafortunadamente, con una fértil imaginación se podría llegar a la conclusión de que TODO sirve para la toma de decisiones. Habría que preguntarse, de una manera más sensata, "¿qué probabilidad RAZONABLE hay de que este dato pueda utilizarse para la toma de decisiones?".

La segunda transformación que debe sufrir el modelo de datos corporativo es añadir un elemento de tiempo a la clave del DW, si es que aún no lo tiene. El tiempo es un elemento extremadamente importante dentro del DW.

La siguiente transformación a aplicar al modelo de datos corporativo para construir nuestro modelo de datos del DW es la de añadir datos derivados de otros, cuando sea apropiado.

Resulta apropiado añadir datos derivados cuando éstos:

- se acceden con frecuencia y

- se calculan una sóla vez.

Añadir datos derivados al DW, aparte de reducir la cantidad de proceso requerida para acceder a los datos, consigue otro efecto beneficioso: una vez que los datos están correctamente calculados, nadie puede utilizar un algoritmo diferente y erróneo para calcular los datos, con lo que la credibilidad de éstos aumenta.

Por otra parte, de nuevo hay que recurrir al sentido común y preguntarse hasta qué punto son convenientes cada uno de los datos derivados, para evitar que el DW pueda crecer incontroladamente.

Creando artefactos de relaciones

Un artefacto de una relación es simplemente la parte de la relación que es obvia y tangible en el momento en que la "instantánea" de los datos entra a formar parte del DW. Dicho de otra manera, cuando tomamos una instantánea de los datos de los sistemas operacionales para incorporarlos al DW, la parte de la relación entre los datos de dos tablas es útil y obvia.

Un artefacto puede incluir claves extranjeras (foreing keys) y otros datos relevantes. O la instantánea puede incluir sólo datos relevantes y no claves extranjeras.

Fusión de tablas

La siguiente transformación a considerar es la fusión de tablas corporativas en una tabla del DW.

Las condiciones bajo las cuales una fusión de tablas tiene sentido son:

- las tablas comparten una clave común,

- los datos de las diferentes tablas se utilizan juntos con frecuencia, y

- el comportamiento de las inserciones en las tablas es similar.

Si cualquiera de las condiciones anteriores no se cumple, NO tiene sentido fusionar las tablas