Ciclo de vida de Ralph Kimball

Metodología de Ralph Kimball

La metodología de Kimball, llamada Modelo Dimensional (Dimensional Modeling), se basa en lo que se denomina Ciclo de Vida Dimensional del Negocio (Business Dimensional Lifecycle). Esta metodología es considerada una de las técnicas favoritas a la hora de construir un Data Warehouse.

Un almacén de datos (Data Warehouse) es una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza. Es una estructura de datos donde la información contenida esta diseñada para favorecer el análisis y la divulgación eficiente de datos.

En el Modelo Dimensional se constituyen modelos de tablas y relaciones con el propósito de optimizar la toma de decisiones, con base en las consultas hechas en una base de datos relacional que están ligadas con la medición o un conjunto de mediciones de los resultados de los procesos de negocio.

El Modelo Dimensional es una técnica de diseño lógico que tiene como objetivo presentar los datos dentro de un marco de trabajo estándar e intuitivo, para permitir su acceso con un alto rendimiento.

¿Por qué es necesario construir un Data Warehouse?

Los sistemas de ingreso de transacciones se ven afectados por las consultas a sus bases de datos. Generalmente poseen informes predefinidos, y cualquier modificación a los mismos debe ser solicitado al departamento de sistemas, que será en definitiva quien evaluará si tiene los recursos humanos disponibles como para realizarlos. El Data Warehouse está separado de los sistemas transaccionales, por lo tanto las consultas no afectan la velocidad de registro de las operaciones. Se actualiza periódicamente, capturando datos de los distintos sistemas transaccionales. Una vez implementado, es importante elegir las herramientas de consulta al Data Warehouse, que permitan un alto grado de autonomía a los usuarios.

La pregunta más común con respecto a los Data Warehouses es:

Ya tengo la información en la base de datos, entonces ¿para qué necesito un repositorio adicional?

La respuesta a esto es que la base de datos, o cualquier otro sistema de archivos que está orientado a los sistemas de producción están diseñadas para tener un respuesta rápida a transacciones relativamente pequeñas: Emitir una factura, registrar un cheque, etc. No están orientadas hacia el proceso masivo de información para reportes.

En cambio el Data Warehouse se construye pensado en que tenga una gran capacidad para obtener reportes que involucren el procesamiento de enormes cantidades de información y en el menor tiempo posible.

Fases del ciclo de vida Kimball

• 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.