La
Metodología Kimball, es una metodología empleada para
la construcción de un almacén de datos (data warehouse, DW) que no
es mas que, 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.
La
metodología se basa en lo que Kimball denomina Ciclo de Vida
Dimensional del Negocio (Business Dimensional Lifecycle). Este ciclo
de vida del proyecto de DW, está basado en cuatro principios
básicos:
Centrarse
en el negocio
Construir
una infraestructura de información adecuada
Realizar
entregas en incrementos significativos (este principio consiste en
crear el almacén de datos (DW) en incrementos entregables en plazos
de 6 a 12 meses, en este punto, la metodología se parece a las
metodologías ágiles de construcción de software)
Ofrecer
la solución completa (En este se punto proporcionan todos los
elementos necesarios para entregar valor a los usuarios de negocios,
para esto ya se debe tener un almacén de datos bien diseñado, se
deberán entregar herramientas de consulta ad hoc, aplicaciones para
informes y análisis avanzado, capacitación, soporte, sitio web y
documentación).
La
construcción de una solución de DW/BI (Datawarehouse/Business
Intelligence) es sumamente compleja, y Kimball nos propone una
metodología que nos ayuda a simplificar esa complejidad. Las tareas
de esta metodología (ciclo de vida) se describen a continuación:
4.1. Planificación del
Proyecto
En este proceso se determina el
propósito del proyecto de DW/BI,
sus objetivos específicos y el
alcance del mismo, los principales riesgos
y una aproximación inicial a
las necesidades de información.
Esta tarea incluye las
siguientes acciones típicas de un plan de proyecto:
Definir
el alcance (entender los requerimientos del negocio).
Identificar
las tareas
Programar
las tareas
Planificar
el uso de los recursos.
Asignar
la carga de trabajo a los recursos
Elaboración
de un documento final que representa un plan del proyecto.
Además en esta parte definimos
cómo realizar la administración o gestión de esta subfase que es
todo un proyecto en si mismo, con las siguientes actividades:
4.2 Definición de
Requerimientos del Negocio
La definición de
requerimientos, es un proceso de entrevistar al personal de negocio y
técnico, aunque siempre conviene, tener un poco de preparación
previa. En esta tarea, se debe aprender sobre el negocio, los
competidores, la industria y los clientes del mismo. Se debe dar una
revision a todos los informes posibles de la organización; rastrear
los documentos de estrategia interna; entrevistar a los empleados,
analizar lo que se dice en la prensa acerca de la organización, la
competencia y la industria y se deben conocer los términos y la
terminología del negocio.
Se sugiere entrevistar al
personal que se encuentra en los cuatro grupos que se mencionan a
continuación:
El personal de sistemas, si
existe (estas son las personas que realmente saben qué tipos de
problemas informáticos y de datos existen en la organización)
El personal que se entrevista
por razones políticas.
Entre las tareas antes
descritas, existe una flecha bidireccional, esto indica que los
requerimientos del negocio son el soporte inicial de las tareas
subsiguientes, también tiene influencia en el plan de proyecto.
Si avanzamos por el camino
central del diagraman, encontramos las tareas asociadas al área de
Datos, en esta, diseñaremos e implementaremos el
modelo dimensional, y desarrollaremos el subsistema de Extracción,
Transformación y Carga (Extract, Transformation, and Load - ETL)
para cargar el DW. Las tareas pertenecientes al área, se describen a
continuación:
4.3 Modelado Dimensional
Es un proceso dinámico y
altamente iterativo. Comienza con un modelo dimensional de alto nivel
obtenido a partir de los procesos priorizados y descritos en la tarea
anterior, y El proceso iterativo consiste en cuatro pasos:
a). Elegir el
proceso de negocio: que consiste en, elegir el área a
modelizar. Esta es una decisión de la dirección, y depende
fundamentalmente del análisis de requerimientos y de los temas
analíticos anotados en la etapa anterior.
b). Establecer el
nivel de granularidad: La granularidad significa especificar
el nivel de detalle. La elección de la granularidad depende de los
requerimientos del negocio y lo que es posible a partir de los datos
actuales. La sugerencia general es comenzar a diseñar el DW al mayor
nivel de detalle posible, ya que se podrían realizar agrupamientos
posteriores, al nivel deseado.
c). Elegir las
dimensiones: Las dimensiones surgen naturalmente de
las discusiones del equipo, y facilitadas por la elección del nivel
de granularidad y de la matriz de procesos/dimensiones (que se
realiza en la tarea 4.2) Las tablas de dimensiones tienen un conjunto
de atributos (generalmente textuales) que brindan una perspectiva o
forma de análisis sobre una medida en una tabla hechos. Una forma de
identificar las tablas de dimensiones es que sus atributos son
posibles candidatos para ser encabezado en los informes, tablas
pivot, cubos, o cualquier forma de visualización, unidimensional o
multidimensional.
d). Identificar
medidas y las tablas de hechos: Este paso, consiste en
identificar las medidas que surgen de los procesos de negocios. Una
medida es un atributo (campo) de una tabla que se desea analizar,
sumando o agrupando sus datos y usando los criterios de corte
conocidos como dimensiones. Las medidas habitualmente se vinculan con
el nivel de granularidad del punto 2, y se encuentran en tablas que
denominamos tablas de hechos (fact en inglés). Cada tabla de hechos
tiene como atributos una o más medidas de un proceso organizacional,
de acuerdo a los requerimientos. Un registro contiene una medida
expresada en números, como ser cantidad, tiempo, dinero, etc., sobre
la cual se desea realizar una operación de agregación (promedio,
conteo, suma, etc.) en función de una o más dimensiones. La
granularidad, en este punto, es el nivel de detalle que posee cada
registro de una tabla de hechos.
4.4. Diseño Físico
En esta tarea, se contestan las
siguientes preguntas:
¿Cómo puede determinar cuán
grande será el sistema de DW/BI?
¿Cuáles son los factores de
uso que llevarán a una configuración más grande y más compleja?
¿Cómo se debe configurar el
sistema?
¿Cuánta memoria y servidores
se necesitan? ¿Qué tipo de almacenamiento y procesadores?
¿Cómo instalar el software en
los servidores de desarrollo, prueba y producción?
¿Qué necesitan instalar los
diferentes miembros del equipo de DW/BI en sus estaciones de trabajo?
¿Cómo convertir el modelo de
datos lógico en un modelo de datos físicos en la base de datos
relacional?
¿Cómo conseguir un plan de
indexación inicial?
¿Debe usarse la partición en
las tablas relacionales?
4.5. Diseño e
Implementación del subsistema de Extracción, Transformación y
Carga (ETL)
El subsistema de Extracción,
Transformación y Carga (ETL) es la base sobre la cual se alimenta el
Data warehouse. Si se diseña adecuadamente, puede extraer los datos
de los sistemas de origen de datos, aplicar diferentes reglas para
aumentar la calidad y consistencia de los mismos, consolidar la
información proveniente de distintos sistemas, y finalmente cargar
(grabar) la información en el DW en un formato acorde para la
utilización por parte de las herramientas de análisis.
4.6. 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. Existen 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 y las estrategias de feedback.
4.7 Mantenimiento y
Crecimiento del Data Warehouse
Para administrar el entorno del
Data Warehouse existente es importante enfocarse en los usuarios de
negocio, los cuales son el motivo de su existencia, además de
gestionar adecuadamente las operaciones del Data Warehouse, medir y
proyectar su éxito y comunicarse constantemente con los usuarios
para establecer un flujo de retroalimentación, En esto consiste el
Mantenimiento. Finalmente, es importante sentar las bases para el
crecimiento y evolución del Data Warehouse en donde el aspecto clave
es manejar el crecimiento y evolución de forma iterativa utilizando
el Ciclo de Vida propuesto, y establecer las oportunidades de
crecimiento y evolución en orden por nivel prioridad.
Si avanzamos por el camino
inferior del diagraman, encontramos las tareas asociadas al área
Aplicaciones de Inteligencia de Negocios, en esta ruta
se encuentran tareas en las que diseñamos y desarrollamos las
aplicaciones de negocios para los usuarios finales. Las tareas
pertenecientes al área, se describen a continuación:
4.8 Especificación de
aplicaciones de BI
En está tarea se proporciona,
a una gran comunidad de usuarios una forma más estructurada y por lo
tanto, más fácil, de acceder al almacén de datos. Se proporciona
este acceso estructurado a través de lo que llamamos, aplicaciones
de inteligencia de negocios (Business Intelligence Aplications). Las aplicaciones de BI son la
cara visible de la inteligencia de negocios: los informes y
aplicaciones de análisis proporcionan información útil a los
usuarios. Las aplicaciones de BI incluyen un amplio espectro de tipos
de informes y herramientas de análisis, que van desde informes
simples de formato fijo, a sofisticadas aplicaciones analíticas que
usan complejos algoritmos e información del dominio. Kimball divide
a estas aplicaciones en dos categorías basadas en el nivel de
sofisticación, y les llama:
a). Informes
estándar: son informes relativamente simples, de formato
predefinido, y parámetros de consulta fijos, proporcionan a los
usuarios un conjunto básico de información acerca de lo que está
sucediendo en un área determinada de la empresa y se utilizan día a
día.
b). Aplicaciones
analíticas: Son más complejas que los informes estándar.
Estas aplicaciones pueden incluir algoritmos y modelos de minería de
datos, que ayudan a identificar oportunidades o cuestiones
subyacentes en los datos, y el usuario puede pedir cambios en los
sistemas transaccionales basándose en los conocimientos obtenidos
del uso de la aplicación de BI. Algunas aplicaciones analíticas
comunes incluyen:
Análisis de la eficacia de la
promociones
Análisis de rutas de acceso
en un sitio Web
Análisis de afinidad de
programas
Planificación del espacio en
espacios comerciales
Detección de fraudes
Administración y manejo de
categorías de productos
Por ultimo, en el camino
superior, encontramos las tareas asociadas al área Tecnología
en esta ruta, se encuentran las tareas relacionadas con software
específico, por ejemplo, Microsoft SQL Analysis Services, etc. Las
tareas pertenecientes al área, se describen a continuación:
4.9 Diseño de la
Arquitectura Técnica
El área de arquitectura
técnica cubre los procesos y herramientas que se aplican a los
datos. En el área técnica existen dos conjuntos que tienen
distintos requerimientos, brindan sus propios servicios y componentes
de almacenaje de datos, por lo que se consideran cada uno aparte: El
back room (habitación trasera) y el front room (habitación
frontal). El back room es el responsable de la obtención y
preparación de los datos, por lo que también se conoce como
adquisición de datos y el front room es responsable de entregar los
datos a la comunidad de usuario y también se le conoce como acceso
de datos.
