Recientemente en un artículo publicado por Bill Inmon toca el tema del tiempo que debería tomar el modelo de datos de un datawarehouse, este artículo rompe algunos paradigmas comunes en las etapas de un proyecto de datawarehouse, para esto necesitamos entender los siguientes puntos.
1. Definir el alcance de los requerimientos de los modelos de negocio
Como primera etapa en el diseño de datos es necesario definir el alcance de los requerimientos, es tan simple como si no conocemos el alcance del modelo de negocio, estaremos modificando y adaptando el modelo de datos indefinidamente, que en un caso real, esto implica altos costos de retrabajo en todas las etapas del proyecto impactando obviamente en costo y tiempo.
2. Diseña solo los datos granulares
La siguiente etapa es diseñar el modelo de los datos granulares, esto indica que nuestro datawarehouse contará con la información al nivel más granular, que durante el desarrollo de reportes o modelos multidimensionales podremos usar, si en otro caso, diseñáramos los datos de acuerdo al uso relacional o multidimensional es casi seguro que tendríamos que tener información similar con diferente dimensionalidad, lo cual nos traería mayor tiempo de proceso y mayor esfuerzo para el mantenimiento de los modelos.
Cabe aclarar que herramientas de Business Intelligence que emulan escenarios multidimensionales requieren la información especialmente tratada para emular agregaciones, y/o facilitar cálculos para el usuario final, en estos casos se recomienda un proceso de preparación de la información partiendo de los datos granulares.
3. Desarrolla en iteraciones
Como en las mejores prácticas de desarrollo de aplicaciones, se recomienda diseñar el modelo de datos en iteraciones, es decir, cada requerimiento o grupo de requerimientos a la vez, esto es adaptable partiendo del diseño granular de la información, donde iremos diseñando los detalles del modelo de acuerdo como vayamos avanzando.
4. Evita la mentalidad de cascada
Así como en los proyectos de desarrollo de aplicaciones, es común pensar en que el flujo de un proyecto es en cascada, esto quiere decir que hasta no terminar una actividad se puede comenzar la siguiente, lamentablemente en el diseño de un Datawarehouse esto no es posible, ya que es una situación normal que los requerimientos de datos sean diseñados y desarrollados al mismo tiempo y que por lo tanto se adapten los modelos de datos al avance de cada requerimiento.
5. Diseña entidades genéricas
Cuando se diseña un modelo de datos es común enfocarse a los requerimientos de los reportes más que en entidades genéricas, es decir, en lugar de interpretar entidades como “clientes” y sus atributos relacionados, se diseña como un requerimiento de reporte de ventas donde se muestra algunos atributos de “clientes”, esto al final del día nos traerá graves consecuencias al no permitir la adaptabilidad de nuestro diseño cuando requiramos información adicional de los “clientes”.
Se recomienda identificar entidades genéricas que nos permitan la mayor adaptabilidad a todo tipo de requerimientos de información, por lo cual en nuestro análisis de requerimientos tenemos que identificar las entidades y eventos, y no mezclarlos en el diseño por las necesidades de un reporte, sino buscar hacer las entidades genéricas e independientes que nos permitan cubrir cualquier requerimiento de información sin necesidad de adecuar el diseño o tener información redundante.
Conclusión
El tiempo que nos debe tomar el diseño de un modelo de datos de un Datawarehouse es algo que no podemos asegurar desde el inicio de un proyecto, ya que el modelo se va adaptando conforme se avance en las etapas de cada requerimiento de negocio, por lo cual es conveniente romper los paradigmas de la planeación de un proyecto de datawarehouse, preparándonos de la manera adecuada para que nuestro modelo de datos sea fácilmente adaptable y funcional a todos los requerimientos.
Puedes leer el artículo de Bill Inmon en http://www.b-eye-network.com/newsletters/inmon/6666
