Source: https://www.dataprix.com/blogs/respinosamilla/fases-implantaci-n-sistema-dw-metodologia-para-construcci-n-dw-0
Timestamp: 2019-07-17 10:19:13+00:00

Document:
Fases en la implantación de un sistema DW. Metodologia para la construcción de un DW. | Dataprix TI
Antes de comenzar nuestro proyecto de BI, vamos a determinar que tipo de metodología vamos a utilizar. Existen diferentes metodos, todos relacionados con el ambito del despliegue de sistemas de información, con alguna concreción referente a los sistemas de BI y DW.
5.1. Metodogia Hefesto.
Como una gran aportación podemos mencionar la Metodología Hefesto, creada por Bernabeu Ricardo Dario (disponible con licencia GNU FDL):
Pagina de la metodologia en el blog Open Business Intelligence.
Consulta Online del libro aquí.
Descarga del Libro aquí.
El libro es un resumen muy completo de todo lo relacionado con el Business Intelligence y los DW, y puede ser un punto de partida de gran calidad para iniciarnos en la materia. En la segunda parte del libro se desarrolla la metodología Hefesto, creada y revisada por esta persona, que ademas ha compartido con todo el mundo con licencia GNU su completo trabajo.
La metodología esta orientada a la construcción de DW para Analisis Dimensional (OLAP) y comprende las siguientes fases, que podemos ver en el gráfico de la derecha.
5.1.1. Análisis de requerimientos.
Identificar preguntas para las que queremos tener respuesta y los objetivos que se quieren conseguir con el nuevo sistema.
Analizar las preguntas para determinar las perspectivas de análisis y los indicadores de negocio.
Diseñar el modelo conceptual, que incluira las perspectivas e indicadores identificados. A través del modelo se podrán alcanzar claramente cuales son los alcances del proyecto, y será un punto de partida con alto nivel de definición para su exposición a los usuarios y responsables.
5.1.2. Analisis de los sistemas transaccionales.
Determinación de indicadores: identificar el origen de los indicadores en los sistemas transaccionales y determinar la forma de su calculo.
Correspondencias: establecer correspondencias entre los elementos definidos en el modelo conceptual y las fuentes de datos existentes en elos OLTP (sistemas transaccionales).
Definición del nivel de granuralidad: nivel de detalle de los datos a obtener para cada dimensión de análisis.
Modelo conceptual ampliado con los campos identificados para cada perspectiva.
5.1.3. Modelo lógico del ETL.
Tipo de modelo lógico del DW: selección del tipo de esquema que utilizaremos (estrella, copo de nieve, etc).
Tabla de dimensiones:Construccion de las tablas de dimensiones para cada una de las perspectivas de analisis considerada.
Tablas de Hechos: definición de las tablas de hechos que contendras la información a partir de los cuales construiremos los indicadores de análisis.
Uniones: relaciones entre las tablas de dimensiones y las tablas de hechos.
5.1.4. Procesos ETL: analisis, definición y desarrollo de todos aquellos procesos necesarios para la extracción, transformación y carga de datos desde los sistemas origen para “llenar” el DW.
5.1.5. Perfomance y mantenimiento del DW: ajustes en el diseño del DW y mantenimiento en el tiempo.
5.2. En otro nivel tenemos la metodología desarrollada por SAS, llamada The SAS Rapid Data Warehouse Methodology
( Podeis descargar el documento en el link ).
Tal y como aparecía en un artículo en ComputerWorld: “Un Data Warehouse no se puede comprar, se tiene que construir“. Como hemos mencionado con anterioridad, la construcción e implantación de un Data Warehouse es un proceso evolutivo.
Planteamos aquí la metodología propuesta por SAS Institute: la “Rapid Warehousing Methodology”. Dicha metodología es iterativa, y está basada en el desarrollo incremental del proyecto de Data Warehouse dividido en cinco fases:
5.2.1-Definición de los objetivos
En efecto, como punto de arranque de todo, es preciso “vender la idea” a los usuarios finales de un Data Warehouse. Esto es así, por ser una idea bastante novedosa y sobre la que pueden surgir recelos de su efectividad. Estos recelos se pueden eliminar comenzando por un pequeño módulo, del cual se valoren los beneficios posteriores, para iniciar progresivamente el desarrollo de nuevos módulos, cada uno con un coste unitario cada vez más reducido, pero sin embargo con unos beneficios distribuidos cada vez mayores por poder cada vez incluir más información.
El simple hecho de realizar un informe de necesidades previas en el que se enumeren la situación de los datos entre los diversos sistemas operacionales, puede ser un hecho decisivo para emprender un proyecto de este tipo. Muchas veces la información existente se encuentra tan poco normalizada, existen tantas discrepancias entre estos sistemas, que el abordar un Data Warehouse en el que se limpien estos datos y se normalicen pueden aportar un valor intangible: “la calidad y fiabilidad de la información“.
La venta de esta idea no sólo se ha de realizar frente a la Dirección sino que es preciso realizarla a todos los niveles: a la Dirección, Gerencia e incluso al área de Desarrollo.
Tras esta venta de la idea, comienzan dos fases similares al análisis de requisitos del sistema (ARS según abreviaturas de la metodología METRICA): la definición de objetivos y requerimientos de información, en el que se analicen las necesidades del comprador.
En esta fase se definirá el equipo de proyecto que debe estar compuesto por representantes del departamento informático y de los departamentos usuarios del Data Warehouse además de la figura de jefe de proyecto.
Se definirá el alcance del sistema y cuales son las funciones que el Data Warehouse realizará como suministrador de información de negocio estratégica para la empresa. Se definirán así mismo, los parámetros que permitan evaluar el éxito del proyecto.
5.2.2.-Definición de los requerimientos de información
Durante esta fase se mantendrán sucesivas entrevistas con los representantes del departamento usuario final y los representantes del departamento de informática. Se realizará el estudio de los sistemas de información existentes, que ayudaran a comprender las carencias actuales y futuras que deben ser resueltas en el diseño del Data Warehouse
Asimismo, en esta fase el equipo de proyecto debe ser capaz de validar el proceso de entrevistas y reforzar la orientación de negocio del proyecto. Al finalizar esta fase se obtendrá el documento de definición de requerimientos en el que se reflejarán no solo las necesidades de información de los usuarios, sino cual será la estrategia y arquitectura de implantación del Data Warehouse.
5.2.3.-Diseño y modelización
5.2.4.-Implementación
5.2.5.-Revisión
5.2.6.-Diseño de la estructura de cursos de formación
(Definiciones extraidas del Consejor Superior de Informatica, del documento Manual para la adquisición de un sistema de Data Warehouse, en http://www.csi.map.es/csi/silice/Elogicos.html ).
Ambas metodologías tienen muchos aspectos en común y utilizaremos una combinación de las técnicas descritas en ambas para la realización de nuestro proyecto PILOTO.
5.3.Otras metodologias.
En el libro Mastering data warehouse design ( Imhoff, Claudia; Galemmo, Nicholas; Geiger, Jonathan G.) ISBN:978-0-471-32421-8, podemos encontrar una metodologia para proyectos de este tipo, desde metodos para la definición del Modelo de Negocio (con consideraciones a tener el cuenta segun el sector de la empresa que estemos analizando)., recogida de requerimientos, técnicas de reuniones, así como información técnica de como modelizar y diseñar el DW.
E imprescindible para diseñar correctamente nuestro DW y para formarnos en este ambito:
The Data Warehouse Lifecycle Toolkit ( Kimball, Ralph; Ross, Margy; Thornthwaite, Warren; Mundy, Joy; Becker, Bob) ISBN: 978-0-470-149777-5
The data warehouse toolkit : the complete guide to dimensional modeling. 2ed (Kimball, Ralph; Ross, Margy) ISBN: 978-0-471-20024-7
Estos dos libros son fundamentales para entender todo lo necesario en el ambito del DW. Ademas, en la segunda edición, aparecen ejemplos de diseño en las diferentes areas de una empresa (Ventas, Contabilidad, Recursos Humanos, Finanzas) y de diferentes sectores.
Como un resumen de las metodologías descritas en estos libros, es interesante la siguiente presentación de Manuel Torres, de la Universidad de Almeria:
Como aportación interesante para nuestra tarea de construir el DW, la serie de articulos publicado en Business Intelligence Facil ( Como construir un Datawarehouse ), que nos hablan de como definir y construir los diferentes elementos que forman un DW, y sobre todo, que errones no cometer.
Introducción: Cómo no construir un datawarehouse
Artículo 1: Datawarehouse
Artículo 2: Dimensiones
Artículo 3: Jerarquías
Artículo 4: Dimensiones lentamente cambiantes
Artículo 5: Claves subrogadas
Artículo 6: Tablas de hecho
Artículo 7: DWH organizado por temas
Artículo 8: Tablas agregadas
Artículo 9: Máximo nivel de detalle
Artículo 10: Rendimiento
Artículo 11: Unificar los hechos
Artículo 12: Unificar las dimensiones
Igualmente, os dejo los links igualmente a un serie de artículos publicados por Josep Curso en su blog, os pueden ser muy utiles en los diferentes aspectos que teneis que tener en cuenta a la hora de construir un DW:
Definiciones de Kimball & Inmon.
Contexto para un data warehouse.
Data Warehousing, Data Warehouse y Data Mart.
¿Qué es una Staging Area?
Estrella y copo de nieve.
Slowly Changing dimensions (e información ampliada en la entrada del Blog de Bernabeu Dario en Dataprix, incluyendo ejemplos reales).
Medidas (I).
Medidas (II).
Tabla de hecho.
Para terminar, son de gran calidad los materiales del curso “Creando el próximo DataWarehouse: Integración y Calidad de Datos”, de la Facultad de Informatica de la UPC (dentro del programa Aules Empresa 2009). Os dejo una de las presentaciones:
Book traversal links for Fases en la implantación de un sistema DW. Metodologia para la construcción de un DW.
‹ Ambitos de aplicación de la Inteligencia de Negocio y del DW.
Nuestro primer proyecto. Definición y consideraciones iniciales. ›

References: Artículo 1

Artículo 2

Artículo 3

Artículo 4

Artículo 5

Artículo 6

Artículo 7

Artículo 8

Artículo 9

Artículo 10

Artículo 11

Artículo 12