Ciclo de Vida Dimensional del Negocio (BDL)
El ciclo de vida de los DATA WAREHOUSES definido por Ralph Kimball como Business Dimensional Lifecycle (BDL) ilustra las etapas por las que pasan y la secuencialidad de tareas de alto nivel, requeridas para el efectivo diseño, desarrollo e implementación de los mismos.
Fig. 7 Ciclo de Vida Dimensional del Negocio (BDL - Business Dimensional Lifecycle)
Planificación del Proyecto.
Busca identificar la definición y el alcance del proyecto de Data Warehouse, las justificaciones del negocio y evaluaciones de factibilidad. Se focaliza sobre recursos, perfiles, tareas, duraciones y secuencialidad.
Es independiente al negocio y sus requerimientos. Esta etapa identifica el escenario del proyecto para saber donde surge la necesidad del Data Warehouse. “Antes de comenzar un proyecto de Data Warehouse o Data Mart, hay que estar seguro si existe la demanda y donde la existe. Si no se tiene un solo usuario sponsor y no hay usuarios entusiasmados posponga el proyecto”.
Algunos factores asociados con esta etapa son:
· Identificación de los tres Sponsors (usuarios).
· Convincentes motivaciones del negocio.
· Cooperación entre áreas y negocios de sistemas.
· Cultura analítica de la organización y,
· Análisis de factibilidad.
Definición de los requerimientos del negocio.
La técnica utilizada para nivelar los requerimientos de los analistas de negocio difiere de los enfoques tradicionalistas guiados por los datos (Inm92) (Gol99). Los diseñadores de los data warehouse deben entender los factores claves que guían al negocio para determinar efectivamente los requerimientos y traducirlos en consideraciones de diseño apropiadas, pues son la base para las tres etapas paralelas subsiguientes focalizadas en la tecnología, los datos y las aplicaciones, por lo cual es altamente critica y el diseño es el centro de atención del BDL (Business Dimensional Lifecyle).
Modelado dimensional.
Básicamente se comienza con una matriz donde se determina la dimensionalidad de cada indicador y luego se especifican los diferentes grados de detalle (atributos), dentro de cada concepto del negocio (dimensión), así como la granularidad de cada indicador (variable o métrica) y las jerarquías que dan forma al modelo dimensional del negocio (BDM) o mapa dimensional.
Diseño físico.
El diseño físico se focaliza sobre la selección de estructuras necesarias para soportar el diseño lógico. Los elementos principales de este proceso son la definición de convenciones estándares de nombres y seteos específicos del ambiente de la base de datos. La indexación y las estrategias de particionamiento son también determinadas etapas.
Uno de los problemas del modelado dimensional y a su implementación relacional es el llamado n-way join, el hecho de tener que hacer join de cada lookup contra la BT de una por vez. En algunos RDBMS esto se resuelve mediante el seteo de STAR JOIN en el motor mejorando el rendimiento en unas 60 veces por sobre la utilización del join secuencial en un equipo de iguales características. Esta técnica demanda la realización de un producto cartesiano, algunos motores no la proveen, pero en un modelo dimensional es más eficiente que hacer el join entre lookup´s u BT una a una.
Diseño y desarrollo de presentación de datos.
Las principales sub-etapas de esta zona del ciclo de vida son: la extracción, la transformación y la carga (ETL process). Se definen como procesos de extracción a aquellos requeridos para obtener los datos que permitirán efectuar la carga del modelo físico acordado. Los procesos de transformación sirven para convertir o recodificar los datos fuente para cargar el modelo físico. Los procesos de carga de datos sirven para poblar el Data Warehouse. Ralph Kimball propone en esta etapa un PLAN de diez pasos.
Diseño de la Arquitectura Técnica
Los ambientes de data warehousing requieren la integración de numerosas tecnologías. Se debe tener en cuenta tres factores: los requerimientos del negocio, los actuales ambientes técnicos y las directrices técnicas estratégicas futuras planificadas para de esta forma poder establecer el diseño de la arquitectura técnica del ambiente de data warehousing.
Hay que tener un plan antes de comenzar, no es simplemente reoordenar y explotar la información. Al igual que en una contrucción, los planos sirven para comunicar los deseos entre los clientes y el arquitecto, como así también para medir esfuerzos y materiales necesarios para la obra (comunicación, planificación, flexibilidad y mantenimiento, documentación, productividad y reuso).
Selección de Productos e Instalación
Utilizando el diseño de arquitectura técnica como marco, es necesario evaluar y seleccionar componentes específicos de la arquitectura como ser la plataforma de hardware, el motor de base de datos, la herramienta de ETL o el desarrollo pertinente, herramientas de acceso, etc.
Una vez evaluados y seleccionados los componentes determinados se procede con la instalación y prueba de los mismos en un ambiente integrado de data warehousing.
Especificación de Aplicaciones para Usuarios Finales
Los diferentes roles o perfiles de usuarios determinan la interfase o ventana al warehouse. Herramientas de diseño de reportes y consultas avanzadas para analistas, tableros de control para gerentes, acceso mediante inter/intra net para usuarios internos/externos remotos, envío de información por dispositivos no estándares para usuarios internos/externos, etc.
Se clasifican a los usuarios según su perfil de consulta, desde usuarios con un perfil más estratégico y menos predecibles (power users) hasta usuarios netamente operacionales que consumen una serie de reportes estándares (final users) pasando por los usuarios gerenciales con uso de interfases push-button (EIS users).
Desarrollo de Aplicaciones para Usuarios Finales
Siguiendo a la especificación de las aplicaciones para usuarios finales, el desarrollo de las aplicaciones de los usuarios finales involucra configuraciones del metadata y construcción de reportes específicos.
Implementación
La implementación representa la convergencia de la tecnología, los datos y las aplicaciones de usuarios finales accesible desde el escritorio del usuario del negocio. Hay varios factores extras que aseguran el correcto funcionamiento de todas estas piezas, entre ellos se encuentran la capacitación, el soporte técnico, la comunicación, las estrategias de feedback. Todas estas tareas deben ser tenidas en cuenta antes de que cualquier usuario pueda tener acceso al data warehouse.
Mantenimiento y crecimiento
Data Warehousing es un proceso (de etapas bien definidas, con comienzo y fin, pero de naturaleza espiral) pues acompaña a la evolución de la organización durante toda su historia. Se necesita continuar con los relevamientos de forma constante para poder seguir la evolución de las metas por conseguir. Según afirma Kimball [Kim98], “si se ha utilizado el BDL el data warehouse está preparado para evolucionar y crecer”.
Al contrario de los sistemas tradicionales, los cambios en el desarrollo deben ser vistos como signos de éxito y no de falla. Es importante establecer las prioridades para poder manejar los nuevos requerimientos de los usuarios y de esa forma poder evolucionar y crecer.
Gerenciamiento del Proyecto
El gerenciamiento del proyecto asegura que las actividades del BDL se lleven en forma y sincronizadas. Como lo indica el diagrama, el generenciamiento acompaña todo el ciclo de vida. Entre sus actividades principales se encuentra el monitoreo del estado del proyecto y la comunicación entre los requerimientos del negocio y las restricciones de información para poder manejar correctamente las expectativas en ambos sentidos.
Puntos problemáticos de un DW
Los principales puntos de atención que pueden llegar a complicar un proyecto de data warehousing se discriman en según las siguientes tres áreas:
· Rutinas de Carga. Incluye programas de extracción y limpieza de datos. Surgen problemas en este punto dada la falta de integración y estructura consistente (alineada) entre los sistemas fuentes.
· Mantenimiento. Dados los diferentes períodos de almacenamiento para OLTP y OLAP y el hecho de que los DW son sistemas secundarios de información, otro problema surge para sincronizar los datos entre los sistemas operacionales fuentes y los warehouses.
· Tuning. Dado los patrones de uso y los métodos de acceso típicos de los sistemas OLAP, diseñadores y administradores deben realizar cambios significativos a los implementados en el tuning de sistemas OLTPs.
