Você está na página 1de 11

ESPECIALIDAD EN TECNOLOGIA DE BASE DE DATOS CURSO: Depsito de Datos Avanzados

Asignacin #1:

Metodologa de Kimball

Profesor: Jose Mayorga

Estudiantes: - Eduardo Mndez Salazar - Jonathan Gmez Chaves - Esteban Oviedo Blanco

Enero, 2012

Introduccin
El concepto fue concebido desde los aos 80s por miembros del Kimball Group y otros colegas. La metodologa fue publicada en The Data Warehouse Lifecycle Toolkit en 1998 refirindose al Business Dimensional Lifecycle y reforzando tres conceptos: 1. Enfoque en agregar valor de negocio a travs de la empresa 2. Estructurar dimensionalmente la data entregada al negocio, va informes y consultas 3. Desarrollar la solucin iterativamente en ciclos de vida incrementales y administrables, en lugar de pretender un entregable Big Bang. Al final del ao 2000, cuando se publica la segunda edicin del Lifecycle Toolkit los anteriores principios se haban convertido en mejores prcticas acogidas por muchos, por lo que la metodologa cambia su nombre a simplemente Kimball Lifecycle. La metodologa ha sido utilizada exitosamente por miles de equipos de proyectos en todas las industrias, reas de aplicacin, funciones de negocio y plataformas de tecnologa.

Desarrollo
El Ciclo de Vida de Kimball
Las implementaciones exitosas de DW/BI dependen de un apropiado amalgamiento de numerosas tareas y componentes; no es suficiente tener un Data Model perfecto o la mejor tecnologa. El siguiente diagrama muestra la secuencia de tareas requeridas para un diseo efectivo, desarrollo e implementacin.

Planeacin y Administracin del Proyecto En el proceso de Planeacin se pone en marcha el proyecto de DW/BI, se determina el propsito del proyecto, la justificacin, sus objetivos especficos, el alcance, el personal, los principales riesgos y una aproximacin inicial a las necesidades de informacin. A lo largo del ciclo de vida se mantienen tareas de administracin. Definicin de Requerimientos del Negocio Un factor determinante en el xito de un proceso de DWH es la interpretacin correcta de los diferentes niveles de requerimientos expresados por los distintos grupos de usuarios. La tcnica utilizada para revelar los requerimientos de los analistas del negocio difiere de los enfoques tradicionales guiados por los datos. Los diseadores de los DWH deben entender los factores claves que guan el negocio para determinar efectivamente los requerimientos y traducirlos en consideraciones de diseo apropiadas. Los requerimientos se deben priorizar basados en el valor agregado y viabilidad. A partir de las entrevistas, se pueden identificar temas analticos y procesos de negocio. Los temas analticos agrupan requerimientos comunes en un tema comn. Track de Tecnologa Ambientes de DW/BI demandan la integracin de numerosas tecnologas, almacenes de datos y metadata asociada. El Track de Tecnologa comienza con el Diseo de la Arquitectura del Sistema para establecer una lista de capacidades requeridas, seguido de la Seleccin e Instalacin de Productos que satisfagan sas necesidades. Track de Datos El Track de Datos comienza con el Diseo de un Modelo Dimensional para guiar los requerimientos del negocio, considerando la realidad de la data. La creacin de un modelo dimensional es un proceso dinmico y altamente iterativo, donde la data se divide en hechos de medicin o dimensiones descriptivas. Modelo Dimensional Los modelos dimensionales pueden ser instanciados en Bases de Datos relacionales, referenciados como esquemas de estrellas, o Bases de Datos multidimensionales, conocidos como cubos OLAP. Independientemente de la plataforma, siempre buscan la facilidad de uso por parte del usuario y un rpido rendimiento en las consultas. El Bus Matriz del Data Warehouse empresarial es un entregable clave de la metodologa que representa los procesos del core business de la empresa y las dimensiones compatibles asociadas. Consiste en un plan de integracin top-down con las entregas gestionadas bottom-up, centrndose en nico proceso del negocio a la vez. Es tremendamente importante ya que sirve como gua tcnica, gua de administracin y un foro para comunicarse con ejecutivos.

El proceso de Diseo comienza con un Modelo Dimensional de alto nivel obtenido a partir de los procesos priorizados de la matriz descrita. La creacin de un Modelo Dimensional es un proceso dinmico y altamente iterativo.

(1) Modelo Dimensional de Alto Nivel El proceso iterativo consiste en cuatro pasos: 1. 2. 3. 4. Elegir el proceso de negocio. Establecer el nivel de granularidad. Elegir las dimensiones. Identificar medidas y las tablas de hechos.

Para concluir con el proceso dimensional inicial se realiza un grfico denominado modelo dimensional de alto nivel (o grfico de burbujas, Bubble chart, en el lxico de Kimball).

(2) Desarrollo Detallado del Modelo Conceptual La identificacin de atributos de dimensiones y tablas de hechos consiste en completar cada tabla con una lista de atributos bien formada.

La implementacin del modelo dimensional detallado consiste simplemente en completar la informacin incompleta de los pasos anteriores. Si el modelo ya esta estable, lo que se hace habitualmente es probarlo contra los requerimientos del negocio. Haciendo la pregunta prctica de Cmo podemos obtener esta informacin en particular del modelo? Para las pruebas podemos usar diseos de reportes estructurados, de usuarios actuales, diseos de cubos prospectivos, etc. (3) Revisin y Validacin del Modelo Implica revisar el modelo con diferentes audiencias, cada una con diferentes conocimientos tcnicos y del negocio. En el rea de sistemas deberan revisarlo los programadores y analistas de los sistemas, y el DBA si existe. Tambin debera revisarse con usuarios y personas del negocio que tengan mucho conocimiento de los procesos y que quizs no hayan participado del diseo del modelo. Finalmente

podemos hacer un documento que enuncie una serie de preguntas del negocio y las conteste por medio del modelo. (4) Iteracin final de Diseo El producto final son una serie de documentos, a saber: a. b. c. d. e. f. g. Modelo de datos inicial de alto nivel Lista de atributos Diagrama de tablas de hechos Definicin de campos de medida Diagrama de tablas de dimensiones Descripcin de los atributos de las dimensiones Matriz DW (o DW Bus Matrix) completa

El modelo dimensional se convierte en un Diseo Fsico y luego se aborda el diseo de los ETLs y los desafos de su Desarrollo. El ciclo de vida describe 34 subsistemas en el flujo de procesos, agrupados en cuatro operaciones mayores: a) Extraer data de la fuente, b) realizar limpieza y transformaciones, c) entregar la data a la capa de presentacin y d) administrar los procesos ETLs y el ambiente. Diseo Fsico En esta parte, intentamos contestar las siguientes preguntas: Cmo puede determinar cun grande ser el sistema de DW/BI? Cules son los factores de uso que llevarn a una configuracin ms grande y ms compleja? Cmo se debe configurar el sistema? Cunta memoria y servidores se necesitan? Qu tipo de almacenamiento y procesadores? Cmo instalar el software en los servidores de desarrollo, prueba y produccin? Qu necesitan instalar los diferentes miembros del equipo de DW/BI en sus estaciones de trabajo? Cmo convertir el modelo de datos lgico en un modelo de datos fsicos en la base de datos relacional? Cmo conseguir un plan de indexacin inicial? Debe usarse la particin en las tablas relacionales?

Diseo e Implementacin del ETL El sistema de Extraccin, Transformacin y Carga (ETL) es la base sobre la cual se alimenta el Datawarehouse. Si el sistema ETL se disea 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 informacin proveniente de distintos sistemas, y finalmente cargar (grabar) la informacin en el DW en un formato acorde para la utilizacin por parte de las herramientas de anlisis.

Track de Business Intelligence Mientras algunos miembros del equipo de Proyecto se encuentran inmersos dentro de la tecnologa y la data, otros se enfocan en identificar y construir una amplia gama de aplicaciones de Inteligencia de Negocios, como informes, consultas, dashboards, scorecards, modelos analticos, y aplicaciones de Data Mining, junto con las interfaces de navegacin asociadas. Especificacin y desarrollo de aplicaciones de BI Las aplicaciones de BI son la cara visible de la inteligencia de negocios: los informes y aplicaciones de anlisis proporcionan informacin til a los usuarios. Las aplicaciones de BI incluyen un amplio espectro de tipos de informes y herramientas de anlisis, que van desde informes simples de formato fijo a sofisticadas aplicaciones analticas que usan complejos algoritmos e informacin del dominio. Kimball divide a estas aplicaciones en dos categoras basadas en el nivel de sofisticacin, y les llama informes estndar y aplicaciones analticas. Implementacin, Mantenimiento y Crecimiento Los tres tracks del Ciclo de Vida convergen en la implantacin, juntando la tecnologa, la data y las aplicaciones de BI. La iteracin desarrollada entra a una fase de mantenimiento, mientras el crecimiento es direccionado por una flecha hacia atrs a la planeacin del proyecto para la siguiente iteracin del sistema de DW/BI. Es importante recordar que un sistema DW/BI es un programa a largo plazo y no solamente un proyecto.

Desde la banca
En la primera versin del Data Warehouse Lifecycle Toolkit se eligi el nombre Business Dimensional Lifecycle porque reforzaba los principios bsicos acerca de los Data Warehouses exitosos: Primero y ms importante, enfocarse en el negocio Los datos analticos deben entregarse en modelos dimensionales para facilidad de uso y rendimiento de consultas Mientras el programa de Data Warehouse constantemente evoluciona, cada iteracin debe ser considerada un ciclo de vida del proyecto compuesto por actividades previsibles con un comienzo y final finitos

Aunque se etiquet la metodologa como Bottom-Up, los autores recomiendan el desarrollo de un Bus Matriz para capturar la relacin entre el core business y las dimensiones descriptivas, antes de que empiece el desarrollo.

El anti-arquitecto
Siempre se nos ha dicho qu hacer; ahora vamos a balancear la lista con lo que no hay que hacer, de acuerdo al orden de gravedad. Error 1: Confiar en los pasados consultores y dems personal de TI para decir los requisitos del Data Warehouse. No entrevistar a los usuarios de negocio. Realidad: Nada sustituye al usuario del negocio. Desarrolle la habilidad de escuchar.

Error 2: Vivir con el supuesto de que los administradores de los principales sistemas fuentes OLTP estn muy ocupados y son muy importantes para pasar tiempo con el equipo y no puede alterar sus procedimientos operacionales para pasar datos desde o hacia el DWH. Realidad: Si su organizacin realmente entiende y valora el DWH, entonces los administradores deberan ser afiliados eficaces brindando la data que se necesita y limpiando alguna otra. Error 3: Despus de que el DWH se ha desplegado, organizar una reunin para discutir una comunicacin continua con usuarios de negocio. Realidad: Boletines, capacitacin y apoyo continuo deben ser parte de la primera presentacin del DWH. Error 4: Asegurarse de que todo el personal de soporte del DWH tiene lindas oficinas, cerca de los usuarios de negocio. Dar servicio de soporte 365/24. Realidad: El personal de soporte debe estar fsicamente localizada en el departamento de los usuarios de negocio y mientras estn trabajando, deben gastar todas sus horas de vigilia en el contenido de negocio en los departamentos que ellos sirven. Error 5: Declarar el xito del usuario al final de la primera capacitacin. Realidad: Retrase la capacitacin hasta que el primer rea de negocio est lista para salir en vivo con data real. Error 6: Suponga que los usuarios de ventas, operaciones y finanzas tendern espontneamente a los buenos datos y desarrollarn sus propias aplicaciones asesinas. Realidad: Los usuarios de negocio no son los desarrolladores de aplicaciones. Error 7: Asegurarse de escribir un plan que describa todos los activos de datos que la empresa posee y los usos de la informacin antes de que se implemente el DWH. Realidad: Muy pocas organizaciones pueden desarrollar un plan completo y perfecto para un DWH. Error 8: No molestar a los altos ejecutivos de la organizacin con el DWH hasta que est instalado y corriendo y pueda apuntar a un xito significativo. Realidad: Los altos ejecutivos deben apoyar el esfuerzo de DWH desde el principio. Si no lo hacen, o no puede, entonces su organizacin puede no ser capaz de utilizar un DWH eficaz. Error 9: Fomentar en los usuarios de negocio que den informacin continua a lo largo del ciclo de vida del desarrollo acerca de nuevas fuentes de datos y nuevos indicadores de rendimiento. Realidad: Necesita pensar como desarrollador de software y gestionar tres etapas: a) recopilacin de requisitos, b) etapa de implementacin y c) etapa de lanzamiento.

Error 10: Acordar entregar un Modelo Dimensional como primer entregable. Realidad: Enfocar el primer entregable en una sola fuente de datos y hacer los temas ms ambiciosos despus. Error 11: Definir su rol profesional como la autoridad en el uso adecuado del DWH. Realidad: Su rol profesional es escuchar a los usuarios de negocio, que siempre tienen la razn. Error 12: Recoger todos los datos en un solo DWH centralizado antes de entrevistar a los usuarios de negocio o liberar cualquier Data Mart. Idealmente implementar el DWH en una sola mquina monoltica donde se pueda controlar y proteger todo. Realidad: Los sistemas de planificacin central a menudo no funcionan. En su lugar, construir sistemas distribuidos y agregar gradualmente el diseo lgico y fsico a medida que aprende de los usuarios de su negocio.

Pensando crticamente al aplicar las mejores prcticas


Tener un enfoque empresarial El mtodo de Kimball est pensado para ofrecer soluciones de DW/BI a gran escala. Se ensea un punto de vista empresarial, a partir de la recoleccin de requerimientos. El siguiente paso es crear un Bus Matriz para entender y crear una apropiada arquitectura que soporte los requerimientos del negocio. Adoptar Business Intelligence Business Intelligence es un concepto que ha emergido y evolucionado en los ltimos aos y actualmente se utiliza para describir todos los sistemas y procesos que una empresa usa para obtener, procesar, dar acceso y analizar informacin. El trmino Data Warehouse se usa para indicar la plataforma de todas las formas de BI. Diseando esquemas dimensionales El mtodo de Kimball parte del principio de que todos los usuarios acceden a la data va esquemas dimensionales. El modelaje dimensional es una disciplina enfocada en optimizar la plataforma de BI para la facilidad de uso y rendimiento de las consultas. Usar dimensiones compatibles para la integracin Integracin y consistencia de datos son objetivos claves en cualquier esfuerzo de BI. La integracin requiere de consenso para establecer y administrar nombres y medidas comunes en toda la empresa. Master Data Management y Customer Data Integration son muy consistentes con el enfoque de Kimball. Cuidadosamente planear la Arquitectura del ETL El mtodo Kimball describe un conjunto de subsistemas ETL que componen un slido conjunto de mejores prcticas de ETL.

Ocho guas para DWH empresariales de bajo riesgo


Actualmente, el clima econmico presiona para que los proyectos de DW/BI por un lado tengan una visin ms centrada de sus herramientas de BI en la satisfaccin del cliente y la rentabilidad, pero tambin quieren controlar costos y reducir riesgos. A continuacin se describen 8 directrices para abordar esta tarea: 1. Trabajar en lo correcto: Priorizacin de proyectos basado en factibilidad, impacto y realidad de los datos.

2. Dar control a los Usuarios de Negocio: Facilitar los datos correctos para que los usuarios tomen sus decisiones. 3. Proceder de forma incremental: liberaciones frecuentes y correcciones sobre la marcha 4. Iniciar con Gobernanza ligera y enfocada: identificacin, valoracin, catalogacin, asignacin de responsabilidades, asegurar, proteger, cumplir, controlar, mejorar, estableciendo prcticas coherentes, la integracin entre reas de conocimiento, la planificacin para el crecimiento, la planificacin de la cosecha de valor y el cuidado general. 5. Construir una plataforma simple y Universal: No importa cmo se vaya a visualizar la informacin en el futuro, la plataforma de datos del DWH debe ser transparente para todas las herramientas de BI. 6. Integrar utilizando dimensiones compatibles: Las dimensiones compatibles permiten a cualquier herramienta de BI hacer drill a travs de diferentes reas de procesos del negocio, ensamblando un reporte final integrado. 7. Gestionar la calidad, pocas pantallas a la vez: Colocar pantallas desde la fuente hasta el objetivo para medir la calidad de los datos. 8. Usar llaves suplentes: Reduce el riesgo en el desarrollo.

Relacionado con Metodologas giles


Desarrollo gil de Software se refiere a un grupo de metodologas, incluyendo XP, SCRUM, Adaptive Software Development y otros que comparten el enfoque de desarrollo iterativo y minimizando riesgo entregando nuevas funcionalidades en corto tiempo, en ocasiones en semanas. El trmino gil fue adoptado en 2001 con el Agile Manifesto, desarrollado por la Agile Alliance. gil es un enfoque al desarrollo de software iterativo e incremental (evolutivo) de manera altamente

colaborativa con las ceremonias suficientes. Hay principios que se alinean con tcnicas estndar del mtodo de Kimball: Enfocado en el principal objetivo de aportar valor de negocio Colaboracin valiosa entre el equipo de proyecto y los stakeholders nfasis en la importancia de la comunicacin cara a cara, retroalimentacin y priorizacin con los involucrados del negocio. Adaptacin rpida al inevitable surgimiento de requerimientos Desarrollo de software reutilizable en una iterativa, incremental manera con tareas traslapadas.

Hay un tiempo y un lugar para utilizar tcnicas giles cuando se crea un sistema DW/BI. Pareciera ser la capa de aplicacin del BI. Disear y desarrollar los informes analticos y anlisis involucra cambios de requerimientos rpidos e impredecibles, que pueden necesitarse en semanas. El desarrollo de ETLs puede tardar meses. Como todo en la vida, la moderacin y el balance entre los extremos es lo ms prudente.

Ser Agile Enterprise Data Warehousing un oxmoron?


El equipo de proyecto se encuentra atrapado entre dos presiones. Primero se necesitan resultados inmediatos e impactantes acerca de los clientes, productos y servicios (integracin YA!).Segundo, evitar el desperdicio. La recomendacin para estas ocasiones es la aplicacin de Master Data Management (MDM) al DWH para que las herramientas de BI subscriptoras puedan hacer informes y dashboards con los contenidos compatibles de las dimensiones. El desarrollo gil espera entregar un demo funcional del sistema a los usuarios de negocio, al final de cada sprint dos a cuatro semanas.

Conclusin
La metodologa de Kimball proporciona una base emprica y metodolgica adecuada para las implementaciones de almacenes de datos pequeos y medianos, dada su gran versatilidad y su enfoque ascendente, que permite construir los almacenes en forma escalonada. Adems presenta una serie de herramientas, tales como planillas, grficos y documentos, que proporcionan una gran ayuda para iniciarse en el mbito de la construccin de un Data Warehouse.

Você também pode gostar