INDICE DE LA PROPUESTA METODOLOGIA 8.2 Política para obtener obtener Calidad en los Datos del DWH ....................................................................................... 2
FASE 1: EXPLORACION DE LOS DATOS........ DATOS............................... .............................................. ...........................................3 ....................3 FASE 2: DISEÑO DE LAS SOLUCIONES....... S OLUCIONES.............................. ................................................................ .............................................4 ....4 FASE 3: EJECUCIÓN DE RUTINAS DE LIMPIEZA.................................................. LIMPIEZA..........................................................4 ........4 ETAP ETAPA A 3.1: En DS-Flow................................. DS-Flow........................................................ .............................................. ...................................... .......................4 ........4 ETAP ETAPA A 3.2: En In-Flow ........................................... .................................................................. .............................................. ................................... ..............5 ..5 ETAP ETAPA A 3.3: En Up-Flow .................................................................. ......................................................................................... ................................... ............55 FASE 4: ASEGURAR LA CALIDAD EN LA DAT DATA.............................................. A.......................................................... ..............6 ..6 Entregable en la Política de Calidad............................................ Calidad.................................................................... ............................................ ....................66 Roles y Responsabilidades del Equipo para Obtener Calidad en el DWH..............................7 DWH..............................7 8.3 Relación entre los Estados de los datos con las políticas para asegurar la calidad en los datos del DWH.......7 8.4 Integración entre el Ciclo de Vida propuesto para desarrollar desarrollar un DWH con la Política para asegurar la Calidad en la Data del DWH......................................................................................................................................9 DWH......................................................................................................................................9
CAPITULO 9:
PROCESO DE ELABORACION DEL CICLO DE VIDA DEL DWH...........11
FASE FASE 0: ESTUDIO DE VIABILIDAD DEL DWH........................................................... DWH....................................................................................................15 .........................................15
MILESTONE 0: Aprobación del Estudio de Viabilidad...................... iabilidad............................................. ..................................16 ...........16 Entregables..................... Entregables............................................ .............................................. .............................................. ........................................ ............................. .................16 .....16 Roles y Responsabilidades Responsabilidades del Equipo en la Fase del Estudio de Viabilida Viabilidadd del DWH...... DWH... ....16 .16 FASE FASE 1: VISIONADO......................................................................................................................................... ......16
ETAP ETAPA A 1.1: Organización Organización del Proyecto............................ Proyecto................................................... .............................................. ..............................17 .......17 ETAP ETAPA A 1.2: Evaluación Evaluación de la Solución......................... Solución................................................ ........................................... ................................ .............21 .21 ETAP ETAPA A 1.3: Definición Definición de la Solución....................... Solución.............................................. .................................................... ....................................21 .......21 MILESTONE 1: Visión y Alcance Aprobados.................................... Aprobados......................................................................22 ..................................22 Entregables..................... Entregables............................................ .............................................. .............................................. ........................................ ............................. .................22 .....22 Roles y Responsabilidades del Equipo en la Fase de Visionado....... Visionado.......................................... ....................................22 .22 FASE 2: PLANIFICACIÓN.............................................................................................................. PLANIFICACIÓN.......................................................................................................................................23 .........................23
ETAPA 2.1: Identificación y Análisis de clientes y usuarios.................................................23 ETAP ETAPA A 2.2: Análisis de Requerimientos Requerimientos .............................................. ..................................................................... ................................24 .........24 ETAP ETAPA A 2.3: Modelamiento Modelamiento Dimensional..................... Dimensional............................................ ........................................ ............................. .................30 .....30 ETAP ETAPA A 2.4: Validación del Modelado........................... Modelado.................................................. ....................................................... .................................34 .34 ETAP ETAPA A 2.5: Diseño del DWH.................................. DWH......................................................... .............................................. ................................... ...............35 ...35 ETAP ETAPA A 2.6: Validación del Diseño............................. Diseño.................................................... ...........................................................62 ....................................62 MILESTONE 2: Plan de Proyecto Aprobado.................. Aprobado......................................... ......................................................63 ...............................63 Entregables..................... Entregables............................................ .............................................. .............................................. ........................................ ............................. .................63 .....63 Roles y Responsabilidades del Equipo en la Fase de Planificación..................................... Planificación......................................63 .63 FASE FASE 3: DESARROLLO................................................................................................ DESARROLLO............................................................................................................................... ........................................ ............64 ...64
ETAP ETAPA A 3.1: Consideraciones Consideraciones de la Solución........................ Solución............................................... .................................................64 ..........................64 ETAPA 3.2: Construcción del Documento del Desarrollo.....................................................65 ETAP ETAPA A 3.3: Validación del Desarrollo............................ Desarrollo................................................... ..................................... .......................... .................65 .....65 MILESTONE 3: Alcance completo........................ completo............................................... .............................................. ........................................65 .................65 Entregables..................... Entregables............................................ .............................................. .............................................. ........................................ ............................. .................65 .....65 Roles y Responsabilidades Responsabilidades del Equipo en la Fase de Desarrollo............................... Desarrollo..........................................66 ...........66 FASE FASE 4: ESTABILIZACION ESTABILIZACION .....................................................................................................................................66
ETAP ETAPA A 4.1: Verificaciones erificaciones ............................................ ................................................................... ..................................... .......................... .................67 .....67 MILESTONE 4: Versión aprobada............................ aprobada................................................... .............................................. .....................................67 ..............67 Entregables..................... Entregables............................................ .............................................. .............................................. ........................................ ............................. .................67 .....67 Roles y Responsabilidades Responsabilidades del Equipo en la Fase de Estabilización..................... Estabilización.....................................67 ................67
FASE FASE 5: UTILIZACION ....................................................................................................................................... ...........................................................................................................................................68 ....68
ETAP ETAPA A 5.1: Actividades para el uso del DWH................................... DWH.......................................................... ...................................68 ............68 MILESTONE 5: Implantación Implantación aprobada............................ aprobada................................................... ...................................................69 ............................69 Entregables..................... Entregables............................................ .............................................. .............................................. ........................................ ............................. .................69 .....69 Roles y Responsabilidades Responsabilidades del Equipo en la Fase de Utilización.............................. Utilización.........................................69 ...........69 FASE FASE 6: EVALUACIÓN........................ EVALUACIÓN............................................................................................................................................69 ....................................................................................................................69
ETAP ETAPA A 6.1: Impactos del DWH..................................... DWH............................................................ .................................................... ................................70 ...70 ETAPA 6.2: Valor del DWH para la Toma de Decisiones.....................................................72 ETAP ETAPA A 6.3. Balance Costo/Valor.............. Costo/Valor...................................... ............................................... ..................................... .......................... ...............73 ...73 Entregables..................... Entregables............................................ .............................................. .............................................. ........................................ ............................. .................73 .....73 Roles y Responsabilidades Responsabilidades del Equipo en la Fase de Evaluación...................................... Evaluación.........................................74 ...74 9.1 CONSIDERACIONES IMPORTANTES......................................... IMPORTANTES................................................................................................ ....................................................... .............74 ........ .....74
8.2 Política para obtener Calidad en los Datos del DWH Una buena práctica para minimizar errores en los datos de un DWH es primeramente limpiar la data de las fuentes de origen y luego continuar paulatinamente estas prácticas prácticas cuando los usuarios ya se encuentran usándolos, de modo que la calidad se mantiene, este tema es una tarea constante a ejecutar. Existen software, herramientas y entes que nos ayudan a obtener el objetivo deseado de la calidad, pero estos incluyen un gasto extra generalmente no calculado para efectuar proyectos de DWH, y por ser un factor que debe de efectuarse constantemente, entonces entonces surge un gran costo de mantenimiento, mantenimiento, que finalmente lleva al fracaso del proyecto del DWH. Una opción alter alternat nativa iva es la realiz realizaci ación ón de pol polít ítica icass inclu incluida idass dentro dentro de la metodo metodolog logía ía efectu efectuand andoo determinados procedimientos, ahora bien es necesario evaluar si en las fuentes de datos de la organización organización son suficientes con estas rutinas de calidad; si el equipo del DWH determina que se requiere de un apoyo tecnológico para asegurar la calidad en los datos, es necesario informarlo antes de iniciar el proyecto para ver la factibilidad del caso, ser claro y explicito en este factor crítico. En esta política se acota su alcance a organizaciones cuya información a usar no se presentan en gran cantidad siendo innecesario el uso de alguna herramienta de software. La calidad en los datos de un DWH se considera descentralizada porque no se focaliza en la creación del mismo, sino en todo el ambiente del DWH; es por ello que esta política formará parte del DWH propiamente dicho (hablando físicamente), y también será parte del proceso ETL y de las fuentes de orígenes de datos. La política propuesta para la calidad de datos en este trabajo de tesis se basa exclusivamente para aquellas organizaciones que con la misma sean suficientes para obtener un DWH con data confiable; confiable; se basa fundamentalmente fundamentalmente en la limpieza de la data, consistencia, corrección de errores típicos, etc. Funcionalmente efectivas para el análisis de poca información. El costo que pueda generar estas actividades no agrega valor a la elaboración del DWH pero lleva a los datos a un estado de utilidad y confianza al momento de tomar decisiones generándose entonces el valor agregado deseado para el DWH, al contar con información confiable, exacta y completa.
La política de calidad en los datos diferencia a dos estados de los datos en un DWH [BI16], añadiendo a ello un tercero que lo llamamos DS-Flow (Data Source-Flow) como se observa en la ilustración.
ILUSTRACION 1: Estados de los datos en un un DWH DWH [BI16] [BI16] [FP] [FP] −
DS-flow:
Se refiere a los datos que se encuentran en las fuentes de datos origen (datos generalmente ubicados en los sistemas operacionales). −
In-flow:
El In-flow describe el flujo de los datos desde su captura hasta su ingreso al almacén. Se hace referencia a la data que usamos en el Proceso ETL. −
Up-flow:
El Up-flow abarca las etapas donde los datos se resumen a formas relevantes a los usuarios; es decir, se ubica en el mismo DWH o en aquellas aplicaciones aplicaciones que el proceso de Inteligencia de Negocios realice o utilice. Esta distinción en los estados de los datos en un DWH nos permite distinguir tres estados diferentes de los datos en un ambiente del DWH y de ese modo entender mejor las políticas de calidad de los datos que se extienden en dicho ambiente. La metodología propuesta para desarrollar un Almacén Almacén de Datos se focalizó en el Estado Up-Flow de los datos, como se observa en la Ilustración.
FASE 1: EXPLORACION DE LOS DATOS Se comienza con la exploración de los valores de los datos mediante la investigación de cada valor en los campos, descubriendo información dentro de campos sin formato, reconociendo información perdida, alcanzándose el conocimiento necesario acerca del nivel de calidad en que se encuentran los datos de las fuentes de origen y por tanto se determina si la data es lo suficientemente confiable para implementarse en el DWH. Al término de esta fase se puede definir las rutinas de limpieza necesarias para convertirlos en información correcta, completa y consistente para el DWH, y también determinar si con las rutinas se satisface con datos de calidad al DWH o con algún tipo de herramienta especializada.
Esta fase nos permite tener una visión sobre la condición real de los datos, ayudándonos a conocer y comprender mejor la información que se encuentra en las fuentes de datos y su nivel de calidad. Se compone de las siguientes actividades: − − −
Se estudia los datos que tengan un significado relativo al negocio o área de estudio. Se descubre metadata oculta (o se analiza metadata existente si hubiese) y prácticas de negocio no documentadas. Se extrae datos específicos que se encuentra mezclados en campos de diferente dominio.
FASE 2: DISEÑO DE LAS SOLUCIONES En esta fase ya se está en condiciones de definir que rutinas de limpieza se deben incluir; se define también el conjunto de rutinas de limpieza que se deben de incluir para dar solución a los problemas encontrados en la fase anterior. Las rutinas pueden ser diseñadas como soluciones automáticas, semi-automáticas o directamente manuales según sea la necesidad de tales soluciones en los datos. Se deben diseñar rutinas tendiendo en cuenta 3 componentes básicos: [BI09] − − −
Verificación de la data: La validación de la data consiste de un número de checks, incluyendo: Chequeo de dominio, chequeo de claves foráneas, etc. Mejorar la data: Es el proceso de la limpieza de los datos válidos para hacerlos más importantes, por ejemplo, la información del nombre y la dirección. Manejar errores: Es un proceso que determina que se hará con los datos que no son perfectos. La data puede no ser aceptada, guardada para ser reparada en un área de trabajo, o pasar con sus imperfecciones para el DWH. La metadata para datos imperfectos debe incluir sentencias sobre la calidad de los datos: Tipos de errores y frecuencia de errores.
Esta no es una lista exhaustiva, sólo nos resalta algunos conceptos básicos a considerar.
FASE 3: EJECUCIÓN DE RUTINAS DE LIMPIEZA Esta fase se lleva a cabo en el caso de desarrollar las propias rutinas de limpieza de datos, consiste en la realización de estas rutinas (desarrollo de algoritmos) y su ejecución (aplicarlos en el proceso del DWH) y también se llevan a acabo el Diseño de las Soluciones planteadas en la fase anterior, se extienden estas actividades a todo el ciclo de vida del DWH. Esta es una fase flexible, se adecua a las necesidades de la data para obtener la calidad deseada; entre algunas (por ejemplo) de las actividades más destacables de esta fase según el estado en que los datos se encuentren se tiene: ETAPA 3.1: En DS-Flow
Esta etapa nos permite limpiar la data de los errores que se encuentran presentes en las fuentes de origen que alimentará al DWH, porque es mejor evitar que datos sin calidad ingresen al DWH, se extiende hasta mantener la calidad en los datos que ya se ingresaron al DWH. Esta etapa se lleva a cabo en todo el proceso del DWH.
I.
Supervivencia y formateo de datos
Sirven para asegurar que la data más importante sea considerada y se encuentre de forma adecuada. Esta tarea se encarga de varias sub-tareas como: Llenado de datos: Ingresa los valores que faltan en registros remplazándolos con valores de registros relacionados correspondientes a la misma entidad. Resolución de conflictos de datos: Resolver problemas de registros múltiples que se refieren a la misma entidad con atributos conflictivos. Ejemplo: Registros de clientes que coinciden en el nombre y dirección pero tienen diferente número de RUC. Supervivencia de datos: Determinar los datos apropiados a cargar en caso de múltiples posibilidades. La información se puede encontrar en más de un lugar y debe determinarse cuál seleccionar para el DWH.
− −
−
ETAPA 3.2: En In-Flow II. Verificación de la uniformidad
Asegura que los valores de los datos que se cargarán, se encuentren dentro de límites preestablecidos. Las reglas de negocio determinan qué valores son factibles en cada campo de datos, esta verificación permite que los datos que ingresarán al DWH cumplan con determinadas reglas y se impide que los datos inválidos ingresen. III.
Transformación de datos
Estas convierten los datos a una forma adecuada para el DWH. Se estandarizan los datos a un lenguaje común usado para el DWH y también se usan las reglas de negocios para transformar los datos adecuadamente. IV. Verificación de versión
Se encarga de detectar cambios en la codificación de los datos fuente se obtiene comparando con la información de la metadata. ETAPA 3.3: En Up-Flow V.
Verificación de la completitud
Determina la completitud y correctitud de las agregaciones en los datos, estas son útiles pero pueden ocultar datos importantes. Por ejemplo cuando se saca un promedio a partir de campos con valores nulos, el promedio puede estar bien calculado pero no refleja la realidad correctamente. VI. Verificación de la conformidad
Valida si los datos se encuentran en la forma adecuada en el DWH; permitiéndonos descubrir casos excepcionales, donde se debe investigar si la causa de los mismos
proviene de datos erróneos o que los resultados reflejan un cambio en la realidad. Por ejemplo, si el promedio de ventas en una área organizacional se mantiene constante durante todos los meses del año y en determinado mes aumenta al doble, los resultados pueden deberse a datos ingresados en forma errónea por los operadores de los sistemas operacionales o que las ventas en realidad subieron en dicho mes. VII. Verificación de la metadata
Esta fase consiste en la revisión de la metadata del DWH, en caso de que exista alguna BD o DWH en funcionamiento o del DWH que se elaboró en la organización.
FASE 4: ASEGURAR LA CALIDAD EN LA DATA Esta fase nos indica que el mejoramiento en la calidad de los datos del DWH es un proceso que va más allá de la construcción del mismo DWH. A diferencia de la limpieza de datos que apunta a corregir errores, el proceso de mejoramiento de la calidad busca prevenirlos atacando los problemas desde su origen (Fuente de Datos) y continuando estas mejoras en todo el tiempo de vida del DWH; se debe mejorar sus procesos de negocio y concientizar a los usuarios y gerencia de su importancia para que se logre los beneficios deseados. Una forma indirecta para asegurar la calidad en el DWH es mejorar los procesos de negocios que producen los datos o reestructurarlos antes de que automaticen de tal manera que se elimine pasos innecesarios que incluyen costo innecesarios y añaden errores para el DWH. Los puntos más importantes y resaltantes a considerar dentro de una organización para asegurar la calidad de la data de las fuentes de origen, son: 1. 2. 3. 4. 5. 6. 7.
Definir los datos consistentemente entre todos los futuros usuarios del DWH. Ubicar los programas de captura de datos lo más cerca posible del evento de negocio que origina esos datos. Ingresar reglas de validación automática que se disparen al momento que se ingresan los datos y validen si los mismos son correctos. Permitir actualizar los datos siempre. Permitir cargar el valor "desconocido" en cada uno de los campos cuando no se conoce el valor real. Estimular a la organización para que tenga la data lo más actualizados y correcto posible. Hacer que tanto los encargados de ingresar los datos como los encargados de los procesos de negocios se sientan responsables de la calidad de los datos.
Si se minimiza los errores de los datos desde el origen, estos nos aseguran que la data que ingresa al DWH es confiable para la toma de decisiones en la organización
Entregable en la Política de Calidad −
−
Documento Master de la Política de Calidad de Datos (incluye integradamente aspectos de la Exploración de los Datos, explicación del Diseño de las Soluciones, Ejecución de Rutinas de Limpieza, reglas aplicadas para Asegurar la Calidad en los Datos). Presentación en Power Point de la Política de Calidad del DWH.
Roles y Responsabilidades del Equipo para Obtener Calidad en el DWH 1 2 3 4
5 6
Administración del Producto: Exploración de los Datos. Administración del Programa: Diseña las Soluciones. Desarrollo: Ejecución de Rutinas de Limpieza. Experiencia del Usuario: Apoyo en la Fase de Exploración de Datos con la participación activa de los usuarios, Trabajo en Power Point de la Presentación de las Políticas de Calidad. Pruebas: Verificación de algoritmos o rutinas de limpieza. Administración de Versiones: Evaluación de los aspectos para desarrollar en las versiones posteriores del tema relacionado a la calidad.
8.3 Relación entre los Estados de los datos con las políticas para asegurar la calidad en los datos del DWH Estados de los Datos
Políticas de Calidad
DS-Flow (Fuentes de Datos)
In-Flow (ETL)
Up-Flow (DWH)
1º Exploración de los Datos
2º Diseño de las Soluciones
3º Ejecución de rutinas de limpieza −
Supervivencia y formateo de datos, etc.
− − −
Verificación de la uniformidad. Transformación de datos. Verificación de versión, etc.
− − −
Verificación de la completitud. Verificación de la conformidad. Verificación de la metadata, etc.
−
4º Asegurar la calidad en la data
TABLA 1: Ubicación de las políticas de Calidad en el Ambiente del DWH [FP] Esta tabla nos permite entender la relación de los tres estados de los datos de un DWH con las fases de la Política de Calidad que se propone en este trabajo de tesis; a diferencia de la propuesta metodológica que se enfoca en el Estado Up-Flow, la política de calidad se enfoca en todo el ambiente del DWH (proceso ETL, DWH) y también en la Fuentes de Datos que nos permitirán alimentar al DWH.
O T C Eentre el Ciclo 8.4 Integración Y Calidad en la O Data del DWH R P L E D N O I C A R T S I N I M D A
de Vida propuesto para desarrollar un DWH con la Política para asegurar la
1º Exploración de Datos
FASE DE VISIONADO
2º Diseño de Soluciones
FASE DE
FASE DE DESARROLLO
3º Ejecución de Rutinas de Limpieza CAPITULO 1:ILUSTRACION
FASE DE
2: Integración de la Calidad de Datos con la propuesta metodológica [FP]
4º Asegurar la calidad en la data (ETL, DWH y en las Fuentes de Datos).
FASE DE UTILIZACION
P R U E B A S
Esta ilustración nos indica que la Política para Asegurar la Calidad en un DWH es una tarea paralela a la elaboración del DWH. El equipo del DWH a la vez que realiza la elaboración del proyecto del mismo, debe realizar tareas paralelas de calidad de datos, para que de esta forma se obtengan datos con mayor credibilidad.
CAPITULO 9:
PROCESO DE ELABORACION DEL CICLO DE VIDA DEL DWH
La propuesta se basa en la integración del Modelo de Procesos y del Modelo de Equipo de MSF; se usan los Milestone al culminar cada Fase, los Milestone son puntos en el proyecto en los cuales los entregables importantes se tienen que completar y revisar. El Modelo de Procesos de MSF nos permite adaptarnos a los requerimientos cambiantes del proyecto debido a las iteraciones a través del ciclo de desarrollo y las versiones incrementales de la solución. Previamente es importante que se tenga en cuenta algunas pautas y/o significados de algunos conceptos en la propuesta. Un Cliente es la persona u organización que se encarga del proyecto, proporciona fondos y quienes esperan conseguir un valor al negocio desde la solución. Los usuarios son gente quienes interactúan con la solución en sus trabajos. [BI19] Clientes y Usuarios:
Nuestra propuesta es una Aproximación basada en Fases y Milestone , identificando Milestone Principales, los Milestone Principales son aquellos que nos sirven para la transición de una fase a otra, mientras que los Provisionales nos sirven como indicadores progresivos que aparecen durante una fase. Aproximación Iterativa, en el lanzamiento de las versiones, MSF recomienda que las soluciones se desarrollen por desarrollo, pruebas e implementación estas son el núcleo de la funcionabilidad, posteriormente un conjunto de características son adicionadas, esto se conoce como el lanzamiento de una versión, proyectos y/o soluciones pequeñas a veces requieren de una sola versión, MSF recomienda que una solución se halle en múltiples versiones, de tal forma que a medida que salen más versiones, la funcionalidad se incrementa como se muestra en la siguiente Ilustración. El Tiempo de Lanzamiento de las versiones varía de acuerdo al tipo y tamaño del proyecto.
ILUSTRACION 3: Funcionalidad vs. Tiempo en el Lanzamiento de Versiones [BI19] Crear un plan multi-versiones, entregar primero el centro funcional, ciclos a través de iteraciones rápidamente, establecer el control del cambio, parar de crear nuevas versiones cuando no agreguen valor; son aquellos aspectos que se debe de considerar al momento del Lanzamiento de Versiones. La Versión 1 de la propuesta desarrolla el aspecto funcional , para lo cual se integra el Modelo de Procesos y de Equipo de MSF adecuándolo a la construcción de un DWH; en la Versión 2, se centra en el tema de la Calidad de la Datos; las versiones posteriores se dejan para aspectos de Administración de Riesgos (a profundidad), Administración del Proyecto, Administración de la Preparación y otros aspectos que se presenta en MSF, no siendo estos menos importantes que los primeros. Para finalizar, la propuesta es también una Aproximación Integrada del Desarrollo e Implementación de Soluciones, una solución no proporciona valor al negocio mientras no se encuentre en funcionamiento. Las Fases en el proceso de elaboración del DWH no son iguales en duración, la cantidad de tiempo en cada fase puede variar dramáticamente y las actividades frecuentemente atraviesan las fases. El Modelo de Equipo de MSF por ser un modelo no jerárquico en donde la Comunicación es el núcleo que integra a todos los “Roles Cluster” (Grupo de Roles) nos permite estructurar a la gente y sus actividades para encomendar proyectos exitosos. El Modelo de Equipo se organiza en equipos pequeños y multidisciplinarios , en los cuales frecuentemente los miembros comparten responsabilidades teniendo una visión común del proyecto, estos equipos tienen la habilidad de responder más rápido que los equipos grandes. Los equipos trabajan juntos , una de las metas del equipo es disminuir los obstáculos para tener una efectiva comunicación, además de hacer cumplir el sentido de la identidad y unidad del equipo. Los equipos deben tener una total participación en el Diseño , es importante ello porque cada rol tiene una única perspectiva del diseño y sus relaciones con objetivos individuales. Desde una perspectiva general el Modelo de Equipo de MSF se basa en la creencia que 6 son las metas claves de calidad (Role Cluster ó Grupo de Roles) que se deben de llevar a cabo en orden para que un proyecto se considere exitoso. Estas metas guían al equipo y definen el Modelo de Equipo. La clave es tener clara la determinación de los individuos del equipo que son asignados para un específico Role Cluster y sus funciones asociadas, responsabilidades y contribuciones hacia la meta principal. En la siguiente tabla se describe los Role Cluster y la meta principal de cada unos de ellos. Role Cluster
1. Administración del Producto
Meta Principal
Satisfacer a los clientes.
2. Administración del Programa
Entregar soluciones con las restricciones del proyecto.
3. Desarrollo
Construir las especificaciones.
4. Pruebas
Aprobar las versiones solo después de que los temas de calidad del producto sean identificados y diseccionados.
5. Experiencia del Usuario
Mejorar la eficacia de los usuarios.
6. Administración de Versiones
Conseguir una tranquila implementación y operaciones en curso.
TABLA 2: Metas de los Role Cluster del Modelo de Equipo [FP] Finalmente, es relevante indicar que el Modelo de Procesos y el de Equipo, complementan todos los principios fundamentales que nos presenta MSF y los cuales son los cimientos para nuestra propuesta, como se muestra en la siguiente Ilustración. Donde: 1. Fomentar la comunicación abierta (Foster Open Communications) 2. Trabajar hacia una visión compartida (Work toward a Shared Vision) 3. Facultar a los miembros del equipo. (Empower team members) 4. Establecer responsabilidades claras y responsabilidades compartidas (Establish clear
accountability and Shared responsability) 5. Centrarse en lo que se entrega de valor al negocio (Focus on Delivering Business Value) 6. Mantenerse ágiles, esperando el cambio (Stay agile, expect change) 7. Invertir en calidad (Invest in Quality) 8. Aprende de todas las experiencias (Learn from all experiencies) Modelo de Procesos
Modelo de Equipo
3
1 7
2 5 6 8
4
ILUSTRACION 4: Relación de los Principios fundamentales con los Modelos de Proceso y de Equipo de MSF [FP] Los 6 Role Cluster del Modelo de Equipo de MSF son participantes activos de cada fase de la propuesta metodológica. La siguiente ilustración resume las fases de la propuesta metodológica de este trabajo de tesis.
LUSTRACION 5: Fases del Ciclo de Vida del Almacén de Datos [FP] Estas fases se describen a continuación detalladamente con sus respetivas tareas. Cada Roles Cluster será un participante interactivamente activo en cada fase del ciclo de vida del DWH.
FASE 0: ESTUDIO DE VIABILIDAD DEL DWH Esta fase nos permite realizar un previo estudio de algunos criterios en la organización y así determinar si el proyecto es posible realizar en la organización. Los costos de construir un DWH son similares para cualquier proyecto informático, se clasifican en tres categorías: [BI05] −
−
−
RRHH: Los usuarios que participen de la construcción deben contar con un enfoque fuerte sobre el conocimiento del área de la organización involucrada y sus procesos respectivos; los usuarios y el equipo deben de trabajar juntos, compartiendo conocimiento y destrezas para enfrentar los desafíos de la construcción del DWH). Tiempo: Se debe establecer el tiempo no tan solo para la construcción y entrega de resultados del DWH, sino también para el planeamiento del proyecto y la definición de la arquitectura, ambos establecen un marco de referencia y un conjunto de estándares que son críticos para la eficacia del DWH.). Tecnología: Muchas tecnologías nuevas son introducidas por el DWH, el costo de la nueva tecnología puede ser tan solo la inversión inicial del proyecto).
Los costos de operación se presentan una vez que se haya construido y entregado el DWH, este se debe mantener y actualizar para que tenga valor empresarial. Son justamente estas actividades fuentes de continuos costos operacionales para el DWH. Se distinguen tres tipos de costos de operación: [BI05] −
Evolutivos: Ajustes continuos del DWH a través del tiempo, como cambios de expectativas y cambios como resultado del aprendizaje de los RRHH del proyecto mediante su experiencia usando el DWH.
−
Crecimiento: Incrementos en el tiempo en volúmenes de datos, del número de usuarios del DWH, lo cual conllevará a un incremento de los recursos necesarios como la demanda de monitoreo, la administración y la sintonización del DWH.
−
Cambios: El DWH requiere soportar cambios que ocurren tanto en el origen de datos que éste usa, como en las necesidades de la información que éste soporta. Cuando se lleva a cabo el proceso del DWH, el impacto de los cambios es compuesto, existiendo dos orígenes primarios de cambios:
Cambios en el ambiente organizacional: Un cambio en el ambiente organizacional pueden cambiar las necesidades de la información de los usuarios, el contenido del DWH se puede ver afectados y el sistema de BI pueden requerir cambios. Cambios en la tecnología: Un cambio en la tecnología puede afectar la manera que los datos operacionales son almacenados, lo cual implicaría un ajuste en los procesos ETL para adaptar las variaciones presentadas.
Los costos por evolución y crecimiento, son normales en un sistema operacional, el costo por cambios es una tema que se debe de tener especial cuidado.
MILESTONE 0: Aprobación del Estudio de Viabilidad Este milestone consiste en la entrega y aprobación del estudio de viabilidad del área gerencial, siendo este milestone el punto de inicio para que se emprenda el proceso de DWH en la organización.
Entregables −
Documento del Estudio de Viabilidad
Roles y Responsabilidades del Equipo en la Fase del Estudio de Viabilidad del DWH Todo el Equipo del DWH se encargará de efectuar este estudio en la organización.
FASE 1: VISIONADO La Fase de Visionado del DWH, es una de las fases donde se obtienen los requerimientos fundamentales para asegurar el éxito del proyecto, se realizan las siguientes etapas y/o tareas resumidas en la siguiente ilustración: FASE DE VISIONADO
Organización del Proyecto
Evaluación de la Solución
Definición de la Solución
MILESTONE 1:
Visión y Alcance Aprobados
ILUSTRACION 6: Fase de Visionado del Ciclo de Vida del DWH [FP]
ETAPA 1.1: Organización del Proyecto I. ¿La organización esta preparada para un proyecto de BI (con un DWH inicial?
Cuando ya es factible realizar el proyecto del DWH, surge esta pregunta inicial y básica para que se de inicio al proyecto del DWH (y así se inicie el proyecto de BI); una decisión que se puede efectuar en esta fase sería de posponer el proyecto y el equipo puede recomendar un número de pasos para llevar a acabo la preparación. La preparación de la organización consta de varios ítems, según sea el tamaño de la organización y el nivel de preparación que tengan en el momento, se recomienda de todas maneras realizar estos ítems, por ejemplo: Exponer los casos exitosos del uso de BI y la importancia del DWH dentro del proceso de BI, exponer beneficios claros para la empresa, concientizar al área u organización de que todos formamos parte del proyecto y la importancia vital de su participación activa en todo el proceso, el valor agregado en la toma de sus decisiones. El equipo debe plantear otros ítems según su experiencia y la organización lo requiera. Si la organización se encuentra preparada para emprender el proyecto del DWH, el equipo decidirá si es necesario que se realice los ítems mencionados, pero se recomienda realizarlos para asegurar el conocimiento de la organización acerca del DWH. II. Visión del Proyecto
Se debe tener una clara visión de lo que se desea conseguir respecto a los clientes. La Visión del Proyecto se refiere a aquellas soluciones que se pueden dar (perspectiva de lo que se pueda realizar). III. Identificación del Alcance del Proyecto del DWH
El Alcance se refiere a las partes de la Visión que se puede cumplir incluyendo las limitaciones del proyecto. Una buena definición del Alcance del Proyecto permite: - Dividir la visión en partes alcanzables. - Definir las características que se debe ejecutar en cada versión. - Permitir la flexibilidad para el cambio. El alcance tiene 2 aspectos: Alcance de la Solución, describe las características de la solución, son aspectos notables de la aplicación o parte del hardware; el Alcance del Proyecto de BI, se refiere al Alcance del proyecto final en términos de la BI. Al definir el Alcance se impide cambios constantes en el ciclo de vida del DWH, tales como el surgimiento de nuevos requerimientos. Es importante prevenir que los objetivos que se cambien y/o que surjan nuevos requerimientos implicarían muchas veces cambiar el Alcance, Visión y con ello la variación del Tiempo de Entrega de la Solución. IV. Identificación de las Restricciones
del Proyecto
En este ítem se debe investigar sobre aquellos aspectos que son los limitantes, ya sean del proyecto o de la solución, aspectos a tratar como, Tiempo de Entrega de la Solución, insuficiente presupuesto que se invertirá, etc., estos aspectos se deben desarrollar interactivamente con todas las actividades de esta primera fase para identificar las restricciones. V. Formación del Equipo de trabajo y asignación de responsabilidades
Formar el núcleo del Equipo y asignar sus responsabilidades a los encargados de los Grupos de Roles. La cantidad de personas que formarán el equipo puede variar, cada Role Cluster asigna un número de personas teniendo en cuenta la cantidad y/o experiencia de cada uno en los aspectos del Modelo de Equipo; varias personas pueden compartir Roles Cluster; es decir, el hecho que existan 6 Role Cluster en el Modelo de Equipo no significa que se necesite un mínimo de 6 personas, el punto clave es que se debe de cumplir 6 metas en el equipo. Los miembros de los equipos pequeños deben compartir roles y para que se consiga eficientemente esto, se debe tener en cuenta lo siguiente: Que los miembros del Grupo de Rol de Desarrollo nunca deben compartir roles, estos se encargan de la construcción del proyecto y no se deben distraer con otras tareas principales. Se debe evitar combinar roles que tienen conflictos intrínsecos de interés. En la siguiente Ilustración se explica claramente que roles pueden ser compartidos o no.
CAPITULO 2:ILUSTRACION
Donde:
7: Combinación de Roles para proyectos pequeños [BI20]
N, U : No recomendados. P : Posibles. VI. Identificar las estrategias a seguir durante el ciclo de vida para la participación e
identificación permanente de los usuarios
El equipo debe de plantear una serie de estrategias que se ejecutarán para mantener viva la relación entre los clientes, usuarios y la gestión. Estrategias como las que se menciona a continuación son las que se deben extraer en este ítem: Reportar activamente y exponer casos exitosos de uso de proyectos de DWH y BI respectivamente. La retroalimentación del usuario también ayuda a comprender cómo evoluciona la implementación del DWH a través del tiempo para reunir requerimientos de usuarios nuevamente identificados. - Antes de iniciar una fase se deberá exponer los objetivos y beneficios a obtener con la misma. - Exponer y enfatizar que la participación empresarial o del área en estudio es vital para cumplir el objetivo del Proyecto y conseguir el éxito del mismo. - Destacar que la Comunicación es el medio que nos lleva al éxito, etc. -
VII. Factores de Planificación del DWH
Se indican algunos puntos clave a considerarse en la planificación del DWH: -
-
-
-
Establecer una asociación de usuarios, gestión y grupos Un efectivo involucramiento entre los usuarios y la gestión nos asegura que el DWH contenga información que satisfaga los requerimientos de la empresa. Seleccionar una aplicación piloto con una alta probabilidad de éxito Se refiere a desarrollar una aplicación piloto (prototipo inicial) con características especiales tales como: Alcance limitado, reembolso medible para los usuarios y la gestión; y con beneficios claros para la empresa. Construir prototipos rápida y frecuentemente Un prototipo nos da la flexibilidad de reunir en mayor cantidad las necesidades de los usuarios, se recomienda hacer el prototipo a lo largo del Proceso de Implementación (y aún más). Desarrollar una Implementación Incremental La implementación incremental reduce riesgos y asegura que el tamaño del proyecto permanezca manejable en cada fase.
VIII. Estrategias para el Desarrollo de un DWH
Previamente al desarrollo del DWH, es crítico desarrollar una estrategia equilibrada que sea apropiada para los propios requerimientos y usuarios del DWH. Existe un número de estrategias mediante las cuales las organizaciones pueden desarrollar sus DWH.
-
-
Primera estrategia: Establecer un ambiente "DWH virtual" Este se puede crear por: Instalación de un conjunto de facilidades para acceso a datos, directorio de datos y gestión de proceso. Entrenamiento de usuarios finales. Control de cómo se usan realmente las instalaciones del DWH. Segunda estrategia: Construir una copia de la data operacional desde un sistema operacional único. Con esto se posibilita al DWH de una serie de herramientas de acceso a la información. Esta estrategia tiene la ventaja de ser simple y rápida. Desafortunadamente, si los datos existentes son de mala calidad y/o el acceso a los datos no se ha evaluado previamente, entonces se puede crear una serie de problemas.
-
Tercera estrategia: La estrategia DWH óptima. Consiste en seleccionar el número de usuarios basados en el valor de la empresa y hacer un análisis de sus preguntas y necesidades de acceso a datos. De acuerdo a estas necesidades, se construyen los prototipos del DWH y se prueban para que los usuarios finales puedan experimentar y modificar sus requerimientos.
IX. Estrategias para el Diseño del DWH
El hecho que los usuarios finales tengan mayor dificultad en definir sus requisitos no lo hace menos importante que en los sistemas operacionales. En la práctica, los diseñadores de DWH tienen que valerse de muchos trucos, por decirlo de alguna manera, para ayudar a sus usuarios a visualizar sus requerimientos. Por ello, son esenciales los Prototipos, como una forma de estrategia para la obtención de requisitos (diseño). Estas estrategias para el Diseño del DWH se evalúan por el Equipo del DWH y/o se definen las que sean necesarias de acuerdo a la organización y el nivel de la solución que se desee obtener. X. Estrategias para la Administración de un DWH
Se debe considerar lo siguiente: -
La Administración tiene que pensar sobre cómo se desea un desempeño eficaz en el DWH y cómo conseguirán llegar a los usuarios finales. (si y solo si un DWH si y es una inversión óptima si los usuarios finales realmente pueden conseguir información vital más rápida y más barata de lo que obtienen con la tecnología actual).
-
La Administración debe reconocer que el mantenimiento del DWH es tan crítico como el mantenimiento de cualquier otra aplicación.
-
La Administración debe comprender también que si se embarcan sobre un programa de DWH se crearán nuevas demandas sobre sus sistemas operacionales, que son:
Demandas para mejorar la calidad en la data Demandas para una data consistente Demandas para diferentes tipos de datos, etc.
XI. Planificación de la Administración de Datos
Este ítem nos indica sobre que estrategias se debe organizar para obtener una data de calidad, como punto inicial es analizar las fuentes de origen y concluir el estado de los datos en cuanto a la calidad de los mismos. En el Proceso ETL de igual forma se lleva a cabo, técnicas de limpieza de datos. Finalmente el proyecto del DWH, puede querer realizar muchos aspectos de limpieza de datos, pero la empresa será el responsable final de indicarnos hasta donde llegar y que realizar. Por ello en este punto es relevante enfatizar la importancia de la Calidad en la Data a la organización, descrito con mayor detalle en las políticas de calidad de datos que se propone en este trabajo de tesis.
ETAPA 1.2: Evaluación de la Solución Identificación y análisis de Riesgos potenciales antes/durante/después de la elaboración del proyecto del DWH XII.
Esta actividad se lleva a cabo en todo el ciclo de vida del proyecto. Este trabajo es un trabajo que sólo concluye con el término del proyecto, es primordial constantemente evaluar aspectos de riesgo para así poder prevenirlos a tiempo o en tal caso saber que medidas ejecutar en el momento que se den. Es importante seguir la Disciplina de la Administración de Riesgos de MSF, siendo estudiada y aplicada para siguientes versiones de la metodología propuesta. XIII. Identificación y análisis de los requerimientos del negocio
Esta tarea se refina rigurosamente en la Fase de Planificación, pero es necesario comenzar con la obtención de requisitos para así evitar la ausencia de algunos al término de la Etapa de la Obtención de Requisitos.
ETAPA 1.3: Definición de la Solución XIV. Evaluación de los procesos en el área de estudio
Se indica los procesos encontrados en el área o en la organización de estudio, además del flujo de datos de los mismos y de las personas involucradas. XV. Identificar a los indicadores que ayudan a la toma de decisiones
En el momento de identificar los procesos involucrados fácilmente se pueden extraer aquellos indicadores que ayudan a la toma de decisiones. XVI. Análisis y elaboración del Flujo de Datos para la toma de decisiones
Se realiza todo el seguimiento de la data que se encuentra involucrada en el proceso de la toma de decisiones y se identifica también a las personas involucradas en el proceso de toma de decisiones. XVII. Verificación de la soluciones
En este ítem se responde preguntas como: ¿Qué se desea analizar?, ¿Porque y para qué se quiere analizar ello?
MILESTONE 1: Visión y Alcance Aprobados Este milestone culmina con la Fase de Visionado, en este punto tanto el equipo como los clientes se tiene que poner de acuerdo en toda la dirección del proyecto, como que características de la solución se incluirán o no.
Entregables -
Trabajo en Power Point, presentación de la Fase de Visionado del DWH. Trabajo realizado en Power Point de la organización y el DWH. Documento de Visión/Alcance/Restricciones. Documento de Evaluación de la Solución. Documento de Estructura del Proyecto.
Roles y Responsabilidades del Equipo en la Fase de Visionado 1
Administración del Producto: Se centra en la obtención de las metas; identifica las necesidades de los clientes, requerimientos; Documento Visión/Alcance/Restricciones.
2
Administración del Programa: Diseña las metas, concepto de solución, Documento de la Estructura el proyecto, Documento de Evaluación de la Solución.
3
Desarrollo: Análisis de las opciones de desarrollo y tecnología.
4
Experiencia del Usuario: Trabajos de Power Point, necesidades e implicaciones de la participación de los usuarios.
5
Pruebas: Estrategias de Pruebas.
6
Administración de Versiones: Implicaciones de la implementación, evaluación de los aspectos para desarrollar en las versiones del proyecto.
FASE 2: PLANIFICACIÓN En esta fase, la Planificación se completa y el equipo prepara las especificaciones de los requerimientos, los trabajos a través de proceso de diseño y prepara planes de trabajo, estimación de costos, etc. La siguiente ilustración muestra las Etapas de la Fase de Planificación.
ILUSTRACION 8: Fase de Planificación del Ciclo de Vida del DWH [FP]
ETAPA 2.1: Identificación y Análisis de clientes y usuarios Se resume los usuarios involucrados en los procesos de negocios en cuestión y para que se logre este objetivo previamente es necesario estudiar el Flujo del Negocio y extraer quien (es) son los responsables, paralelamente se necesita entender al sistema
operacional que se usa actualmente si lo hubiese, con esto se entiende también la filosofía de trabajo de la organización.
ETAPA 2.2: Análisis de Requerimientos Para que se obtenga los requerimientos, es necesario tener claro quien o quienes son los clientes y usuarios de los procesos a estudiar. Una confirmación y revisión de la Etapa anterior da al equipo confianza para seguir avanzando a paso firme. En esta etapa se direcciona a un nivel alto las necesidades del ambiente completo del DWH; consiguiendo, analizando y documentando los requerimientos, estos nos sirven posteriormente para el Modelamiento del DWH. Al culminar esta etapa se tendrá el documento resultante con la definición de requerimientos, el cual se debe revisar por la totalidad de las partes involucradas. El proceso de obtener los requerimientos de la organización es una tarea que cambia constantemente, en un tiempo dado los requerimientos son verdaderos y luego no lo son, pero entonces ¿como se va a identificar satisfactoriamente los requerimientos?, la metodología de IBM expone que si se direcciona los requerimientos hacia las siguientes interrogantes, probablemente se tiene la suficiente información para comenzar el modelamiento del DWH. -
Cómo (la gente, los grupos, la organización) se interesa en el usuario. Qué (funciones) el usuario intenta analizar. Por qué el usuario necesita los datos. Cuando (para que periodo en el tiempo) los datos necesitan ser recordados. Donde (geográficamente, organizacionalmente) los procesos importantes ocurren. Como nosotros indicamos la ejecución o estado de las funciones que son analizadas.
I. Técnicas de Recolección de datos
Existen muchos métodos para hallar los requerimientos de la organización. En general, estos métodos se pueden ubicar en una de las 2 categorías mencionadas de la metodología propuesta por IBM.
ILUSTRACION 9: Técnicas de Recolección de los Requerimientos (traducción) [BI09] -
Recolectando requisitos de las Fuentes de Origen (Source - driven requirements gathering)
Esta categoría reúne los requerimientos mediante el Análisis de la Información basado en el uso de las fuentes de origen de la data; es decir, los requerimientos se hallan en el Análisis del Modelo ER de los sistemas operacionales de la organización. Con ellos se investiga los documentos existentes (facturas, informes, reportes, etc.), permitiendo al equipo conocer lo que se posee actualmente en la organización y comprender las carencias actuales y futuras que deben ser resueltas en el diseño del DWH, estos sistemas pueden ser usados para reunir y confirmar los elementos que forman parte del sistema (tablas de sistema), objetos que produce el sistema (informes, formularios, nuevos archivos de datos), objetos que se usan (hardware y software), procesos que hay en la empresa (gestión de cobro, ventas, recepciones), restricciones, criterios de validación y rangos de valores de entrada, etc. Una gran ventaja mencionada por IBM es que es importante porque se conoce el origen y almacenamiento de los datos; además conlleva a que se comprenda la lista de las mejores dimensiones para el interés de la organización (si se desea realizar un DWH de la organización minimiza la proliferación de dimensiones duplicadas a través del desarrollo separado de los Data Marts) e identificar las áreas donde se debe enfocar los esfuerzos para el desarrollo del DWH. En contraparte, se minimiza el involucramiento de los usuarios, si en caso se usara únicamente y exclusivamente esta categoría. Otra desventaja que se añade es que esta tarea por si sola puede consumir gran cantidad de tiempo en BD de gran volumen, se recomienda usar esta categoría complementariamente.
-
Recolectando requisitos de los usuarios (User - driven requirements gathering)
Esta categoría se basa en la definición de los requerimientos por la investigación de las funciones que desempeñan los usuarios. Este método se usa generalmente mediante una serie de encuentros, entrevistas o cuestionarios con la gente identificada par el proceso. Esta categoría es el punto principal de lo que se pretende obtener y se necesita en cuanto a información. Se debe tener cuidado con las expectativas de los clientes y/o usuarios, están deben ser administradas muy cuidadosamente por el equipo, se debe hacer entender claramente lo que es posible y lo que no, como en Etapas anteriores refiere nuestra propuesta. Una de las más conocidas dentro de esta categoría son las Entrevistas, se obtienen mediante sucesivas conversaciones dirigidas para conseguir algunos propósitos con los representantes del departamento del usuario final y los clientes y usuarios; asimismo el equipo debe ser capaz de validar el proceso de entrevistas y reforzar la orientación del proyecto. En una entrevista debe haber un cierto clima de cordialidad para que se produzca un mejor involucramiento y comunicación con el entrevistado, además se debe preparar al entrevistado (concretar la fecha, hora y pasarle un guión al entrevistado indicándole la mayor cantidad de alcances de la entrevista para que el estructure su información). En la entrevista propiamente dicha se toman notas, se graba en video o audio, o video conferencia con el debido permiso; en la entrevista se procura conseguir respuestas objetivas. Finalmente al término se hace un breve resumen de la entrevista y se agradece la atención prestada. Un modelo del Informe de la Entrevista se presenta en la siguiente tabla.
Informe de Entrevista
Fecha: 00 / 00 / 2007 Entrevistado : ______________________________________________ Cargo : ______________________________________________ Entrevistador : _____________________________________________ Tema : _____________________________________________ Objetivos de la entrevista: ¿Qué se quiere conseguir con la entrevista? ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________
Puntos principales de la entrevista:
Opiniones del entrevistador:
___________________________ ___________________________ ___________________________ ___________________________ ___________________________ ___________________________ ___________________________ ___________________________ ___________________________ ___________________________ ___________________________ ___________________________
________________________ ________________________ ________________________ ________________________ ________________________ ________________________ ________________________ ________________________ ________________________ ________________________ ________________________ ________________________
¿Se lograron los objetivos? : (Si) - (No) Observaciones adicionales: __________________________________________________________ __________________________________________________________ __________________________________________________________ Compromisos para la próxima entrevista: (si la hubiese) __________________________________________________________ __________________________________________________________ __________________________________________________________
ILUSTRACION 10: Modelo de Informe de Entrevista [FP] Otra que se menciona en este tipo de categoría es el Cuestionario, es un documento que nos permite complementar la entrevista. Sus tipos de preguntas son: Respuestas abiertas, Si/NO y valoraciones puntuales (1, 2, 3). Las Reuniones en la organización nos sirven de gran utilidad si se tiene:
Objetivos definidos. Tiempo de duración adecuada. Si la reunión se puede realizar en la empresa de los interesados. Antes de comenzar todos los participantes tienen que saber las reglas de la reunión (saber turnos de palabra etc.) Cada sesión tiene un objetivo (se da un informe con anticipación).
El uso de estas aproximaciones es opcional, se recomienda usar la unión de ellas en la medida que el proyecto y el equipo lo requieran.
II. Realización de Obtención de Requerimientos y presentación de informes
Antes de lleva acabo la obtención de los requerimientos mediante las técnicas especificadas en la Tarea I se indica a toda persona de la cual se extraerán los requerimientos, de que tipo y la manera como se tratarán los temas y sobre todo la importancia y seriedad en que deben tomarlos. Finalmente, esta se presentan los informes respectivos. III. Preparación de los Planes
El equipo prepara un plan general que es uno de los Entregables en la Fase de Planificación y se relaciona con los roles y participaciones a lo largo del proyecto. Se tiene por ejemplo los siguientes planes: Plan de Desarrollo (Expansión y Mantenimiento). Plan de Pruebas. Plan de Operaciones. Plan de Seguridad. Plan de Capacitación. Plan de Implementación. Plan de Adquisiciones. Plan de Obtención de Requisitos. Plan de Administración de Riesgos. Proyecto principal del programa. (incluye todos los detalles de los programas), etc. Como grupo del DWH, el equipo revisa e identifica las dependencias entre estos planes. Todos los planes son sincronizados y presentados juntos como un Plan de Proyecto Master. Un beneficio que se observa al hacer un plan de la unión de otros pequeños es que ellos facilitan la planificación en curso por varios roles del equipo y ofrecen responsabilidades claras porque se especifican roles y responsabilidades para planes específicos. -
IV. Especificación
de los Requerimientos
Después de determinar que técnica de recolección de los datos, se inicia la construcción del Documento de las Especificaciones y se extiende en toda la Fase de Planificación, siendo este el resultado del proceso de diseño, las especificaciones son descripciones detalladas de las necesidades de información y los requerimientos del DWH a desarrollar desde el punto de vista funcional, y cuanto de cada característica se debe visualizar y ser operativa, se describe también la arquitectura y diseño de todas las características. Estas especificaciones son la base para construir el Plan principal del Proyecto y del Programa, sólo se pueden cambiar con la aprobación de los clientes y/o usuarios. Las especificaciones nos sirven para múltiples propósitos, tales como: -
Son instrucciones para que los desarrolladores sepan en que construir. Bases para la Estimación del Trabajo. Estar de acuerdo con los clientes y/o usuarios exactamente que se construirá. Puntos de sincronización de todo el equipo, etc.
Finalmente este Documento debe ser lo más claro posible, presentado y aprobado por la Gerencia para que se pueda continuar con las siguientes fases. Una aproximación de este documento sería como en la siguiente ilustración, pero este documento se debe acomodar básicamente teniendo en cuenta la forma más eficiente como la gerencia de la organización lo entienda o lo requiera: Especificación de Requerimientos
Proyecto: Número del Versión: Anexos: (que se revisan o que se adjuntan) Resumen:
La Especificación de Requerimientos se define de forma precisa como se va a construir el software. Estas decisiones se basan en la información de los documentos del Plan de Proyecto Master y de los Requerimientos de los usuarios, ambos deben satisfacer el Diseño. Se verifica y validada por la Gerencia de la organización. Requerimientos Funcionales:
1. Nombre de la Característica: Prioridad: (Alta, Media, Baja) Proceso: Descripción: (explicar y detallar el requerimiento) (por ejemplo)** De Usabilidad (fácil acceso, interfaz amigable). De Confiabilidad. De Precaución. De Seguridad (acceso al sistema, derechos de usuarios, etc.) Detalle: Contraseñas de que longitud, caracteres permitidos, omitidos, etc. De Desempeño y Escalabilidad. De Mantenimiento y Actualización. De Ciclo de Vida del Proyecto. De Hardware. De Software. De Importación y Exportación de datos. (BD, almacenamiento.)
Requerimientos No Funcionales:
-
** En cada tipo de requerimientos se debe Detallar de que forma se solicita. Estado final del documento:
Se verifica y valida por la Gerencia de la organización.
ILUSTRACION 11: Modelo del Documento de la Especificación de Requerimientos [FP]
Se recomienda enfocar los requerimientos desde cuatro puntos de vista (esto depende del DWH a construir): -
Requerimientos del Negocio. Requerimientos del Cliente/Usuario. Requerimientos Operacionales. Requerimientos del sistema de BI.
V. Evaluación de la Tecnología
El equipo se encarga de evaluar los productos o tecnologías que se usarán para construir e implementar la(s) solución(es). Esta elección involucra evaluaciones comparativas entre las tecnologías rivales o proveedores que dan solución al DWH que se construirá.
ETAPA 2.3: Modelamiento Dimensional La técnica de modelamiento elegido para el DWH es el Modelamiento Dimensional. Este tipo de modelamiento se debe de comprender por los clientes y/o usuarios. Se debe de distinguir entre completar la Etapa de modelamiento y completar el modelo. Al fin de esta etapa, se tiene un completo cuadro de los requerimientos. Sin embargo, sólo parte de la metadata tendrá que ser documentada. Un modelo no puede ser considerado verdaderamente completo hasta que el resto de la metadata sea identificado y documentado durante la Fase de Planificación. No existe exactamente una técnica a seguir para modelar datos, un diseñador se adecúa diferentes factores, la guía que Ralph Kimball nos presenta se usará como base para efectuar el Modelamiento Dimensional. ( Ver Capítulo de Modelamiento Dimensional para mayor explicación) VI. Proceso para realizar el Modelamiento Dimensional (Kimball)
Una buena práctica antes de comenzar a modelar los datos es identificar los indicadores y dimensiones sin nuestros requerimientos, partiendo de esas premisas, iniciar con los requerimientos. Paso 1: Seleccionar los Procesos de Negocio para el modelo
Se realiza el resumen de los Procesos de Negocios encontrados en la Fase de Visionado ( Etapa 1.3: Definición de la Solución). Se enfatiza nuevamente que no se refiere a un departamento organizacional del negocio al hablar de Proceso de Negocio. Paso 2: Declarar el Grano de cada Proceso de
Negocio Nos permite especificar el nivel de detalle de una fila individual de la Tabla de Hechos. Es necesario que se lleve a cabo este paso. Este grano decidirá las dimensiones del DWH. Paso 3: Decidir las dimensiones que aplicar para cada fila de la Tabla de Hechos
¿Cómo la gente de negocio describe los datos que resultan de los procesos de negocio?, se quiere decorar la Tabla de Hechos con un robusto conjunto de dimensiones
representando todas las posibles descripciones que toma un simple valor en el contexto de cada indicador. Paso 4: Identificar los hechos numéricos que poblarán cada fila de la Tabla de Hechos
¿Qué se está midiendo?, los usuarios de los negocios son los entusiastamente interesados en analizar estos performance de las medidas de los procesos de negocio. Un aporte de la Metodología de IBM, a los requisitos los agrupa como un conjunto de interrogantes, y para analizar estas interrogantes, se definen Dimensiones e Indicadores requeridos para encontrar los requerimientos. Esta tabla se recomienda completar durante el modelamiento para mejor entendimiento del mismo. REQUERIMIENTOS (PREGUNTAS RELACIONADAS )
REQ1
DIMENSIONES DIM1 DIM2 DIM3 INDICADORES IND1 IND2 IND3
X X X X
REQ2
X X X
REQ3
REQ4
X
X
X
X
TABLA 3: Ejemplo del Resumen de Dimensiones, Indicadores y Requisitos [BI09] Donde: Q1, Q2, Q3, Q4 : Requisitos en forma de preguntas relacionadas. DIM1, DIM2, DIM3 : Dimensiones encontradas. IND1, IND2, IND3 : Indicadores de la organización. Con este cuadro se permite revisar dimensiones y asegurarnos que las dimensiones, e indicadores obtenidos cubren satisfactoriamente los requerimientos. Este contexto la data gira en torno al Tiempo, por ello se debe añadir la Dimensión Tiempo y su nivel de granulidad se obtiene del intervalo de tiempo que se requiera la información analítica que la organización. A la propuesta de Kimball se le añade algunos pasos complementarios para realizar un modelo consistente de datos del DWH. Paso 5: Análisis de la Granulidad y Aditividad
Como regla general, la data se debe guardar en el más alto nivel de granularidad (mayor detalle) porque no se puede cambiar los datos hacia un nivel más alto que el que se decidida guardar. Sin embargo, se puede realizar un Roll-Up (sumarizar) de la data para crear una nueva tabla con un nivel más bajo de granularidad.
Junto la granulidad se debe decidir la Aditividad (capacidad de los indicadores para ser sumarizados), especialmente cuando se considere posibles sumarizaciones que ocurrirán en la Tabla de Hechos, habitualmente se aconseja que los indicadores sean Completamente Aditivos para mayor facilidad en su uso. Una vez que se tienen calculados la granularidad y aditividad que existen en los Hechos, se debe de considerar la posibilidad de combinar hechos. Estos pueden ser requeridos cambiando la granularidad de un hecho particular; usualmente, juntar hechos ampliará el rango de análisis que puede ser ejecutado en el Hecho, esto es porque al unir hechos a menudo implica añadir dimensiones para un hecho. Una primera aproximación para evaluar las posibilidades de tal unión es determinar para cada indicador cuales dimensiones adicionales se puede incrementar a su granularidad. Los hechos se deben revisar para tener oportunidades de añadir dimensiones, incrementando así el valor potencial del análisis. VII. Integración con los modelos existentes de un DWH actual
Una vez que se concluya la Tarea VI, se busca proceder algunos procesos referidos a la granularidad, aditividad con datos existentes del almacén (en caso que existiera alguno), y hasta de Hechos y Dimensiones con el objeto de complementar el modelo, sin que se llegue al exceso de restringir su capacidad para cambiar los hechos, dimensiones e indicadores ya existentes. VIII. Dar inicio a la Metadata
El modelo del DWH se usa continuamente; sus clientes y/o usuarios constantemente hacen referencia al modelo para determinar los datos que se usa para el análisis. El índice de cambios de la estructura en los datos en un DWH es mucho mayor que las estructuras de datos operacionales. Por lo tanto, los usuarios técnicos del DWH usarán su modelo regularmente como básico. Es aquí donde la metadata llega a ser relevante. Usualmente en este punto no se va a definir todo acerca de la metadata; sin embargo, esto no significa que se deba esperar hasta donde se pueda. Adecuadamente se entiende el modelo y este confirmará que requerimientos se conocen, un usuario debe tener acceso a la metadata que describe el DWH en términos de negocios que estos son fácilmente entendidos. Por lo tanto, la metadata no técnica debe ser documentada en este punto. Durante las Etapas y Fases posteriores la metadata técnica se añadirá. En un nivel del DWH, se debe de facilitar una lista sobre que esta disponible en el DWH. Esta lista debe contener modelos, dimensiones, hechos e indicadores disponibles como estos serán usados como puntos de entradas iniciales cuando un usuario empieza el análisis de los datos. Para cada modelo, proporcionar un nombre, definición y objetivo. Simplemente el nombre da al usuario un enfoque para la búsqueda. Usualmente, esto es similar como el hecho. La definición identifica que está modelado y el objetivo describe que modelo se usa. La metadata para cada modelo debe también contener una lista de dimensiones,
hechos e indicadores asociados con el DWH, como también el nombre de la persona de contacto para que los usuarios puedan agregar información adicional cuando ellos tengan algunas dudas acerca del modelo. Un nombre, definición y sobrenombres deben ser proporcionados para todas las dimensiones, atributos, hechos e indicadores. Los sobrenombres son necesarios porque estos a menudo llegar a dificultar la concordancia en los nombres comunes para cada objeto ampliamente usado. Para las dimensiones y hechos se debe de proporcionar a una persona de contacto. La metadata acerca de una dimensión debe también incluir jerarquía, cambio de reglas, frecuencia de la carga y los atributos, hechos e indicadores asociados con la dimensión. La jerarquía define las relaciones entre atributos de una dimensión que identifica los diferentes niveles que existen con ellos. El cambio de reglas identifica como cambian los atributos en una dimensión. En algunas instancias, estas reglas pueden ser diferentes para los atributos individuales. La frecuencia de la carga permite al usuario entender si la data estará disponible cuando se le necesite. Los atributos de una dimensión son usados para identificar que hechos los usuarios quieren para analizar. Los atributos son usados eficientemente, la metadata acerca de ellos debe de incluir tipos de datos, dominios y reglas de derivación. En este punto, una indicación general de los tipos de datos (caracter, date, numeric, etc.) es suficiente. La definición exacta del tipo de dato puede ser realizado durante el diseño. El dominio de un atributo define el conjunto de valores válidos que estos pueden almacenar. Para atributos que contienen valores derivados, las reglas para determinar el valor debe ser documentado. Metadata acerca de un hecho debe incluir la frecuencia de la carga, los indicadores y dimensiones asociados con los hechos, y tiempo de cada hecho. Aunque esto es posible para derivar el tiempo para cada hecho a través de sus relaciones la dimensión tiempo. Metadata acerca de un indicador debe incluir su tipo de dato, dominio, reglas de derivación, los hechos y dimensiones asociadas con los indicadores. Se facilita una representación gráfica de la metadata y los caminos de acceso que podrían recorrer los usuarios cuando analizarían su data. En la Ilustración 12 se presenta un ejemplo de una metadata de un DWH.
ILUSTRACION 12: Ejemplo de la Metadata para un DWH [BI09]
ETAPA 2.4: Validación del Modelado Antes de continuar con las siguientes etapas de planificación e invertir mucho tiempo y esfuerzo en un modelado incorrecto. Para esta revisión se debe básicamente: -
-
Confirmar que el modelo que se ha realizado hasta el momento puede conocer los requerimientos del usuario, y además la revisión confirma que el cliente y/o usuario entienda el modelo. Recordar que una vez que el DWH es implementado, el usuario confiará en el modelo en una base regular para acceder a la data en el DWH. No importa cuan bueno el modelo conozca los requerimientos del usuario, el DWH fallará si el usuario no puede entender el modelo y consecuentemente, no puede acceder a la data. La validación se realiza en un alto nivel. El modelo se revisa con el cliente y/o usuario para confirmar si entiende o no el modelo. Conjuntamente con ellos se evalúa el modelo para resolver como se respondería algunas de las interrogantes identificadas en los requerimientos. Existe la posibilidad que no se conozca todos los requerimientos en el modelo o necesiten ser mejor entendidos o tengan que ser cambiados o redefinidos; esto no
implica que se detenga y se regrese al inicio; en tal caso la data en cuestión se envían a la Etapa de Análisis de Requerimientos y la data validada del modelo pasa a una Fase Anexa, de Pruebas, para que luego se pueda continuar el ciclo de vida del DWH. Esta iteración y la creación continua de modelos parcialmente completos son elementos claves que proporcionan la facilidad para desarrollar rápidamente DWHs.
ETAPA 2.5: Diseño del DWH En esta etapa se identificarán las fuentes de los datos (sistema operacional, fuentes externas, etc.) y las transformaciones necesarias para que a partir de dichas fuentes, obtener el Esquema Lógico del DWH. La mayor parte estas definiciones de los datos del DWH estarán almacenadas en la Metadata. Los requerimientos de información identificados en la fase anterior se usan como entrada para esta etapa. IX. Selección de las Técnicas de Diseño
Para que se de inicio al proceso de diseño se determina que Técnica de Diseño se usará, se distingue en [BI23] dos técnicas de diseño para el DWH: -
-
Técnica Top-Down: Se construye el modelo el modelo general para toda la empresa y a partir de ahí se construye el DWH de la organización y luego los Data Marts. Técnica Bottom-Up: Se enfoca en el desarrollo de Data Marts pequeños, especializados en determinadas áreas o procesos que en su conjunto forman la estructura del DWH. Conforme se vaya desarrollando más Data Mart, el DWH abarca nuevas áreas de la organización.
Sin embargo, Ralph Kimball en [BI24] manifiesta que no existen estas dos técnicas contrastantes y además que no se hace imprescindible la creación de una BD maestra, completamente centralizada en el diseño de un DWH, como prerrequisito para que sus partes sean sumarizadas y publicadas como Data Marts individuales. Ni es factible la creación de un DWH empresarial desde un proceso de ensamblaje de Data Marts construidos discordinadamente y no relacionados. Kimball propone la Arquitectura Bus. -
Arquitectura Bus: Implica que cada dimensión usada en la creación de un Data Mart, debe haber sido previamente definida según las necesidades empresariales de información, y no sólo atendiendo a las necesidades de información atendidas por el Data Mart al que se desea agregar la dimensión. El origen de este requerimiento está en lograr que dicha dimensión responda al enfoque corporativo del sujeto que representa dentro del total de la empresa y no únicamente a la visión que los usuarios de un Data Mart particular puedan tener de el.
ILUSTRACION 13: Arquitectura de Bus [BI24] Donde cada dimensión definida, será replicada en los distintos lugares en que sea usada, en caso de un DWH corporativo distribuido, o simplemente compartida por todas las estructuras dimensionales que intervienen en los distintos Data Marts constituyentes del DWH. Las dimensiones definidas así, mantienen el concepto corporativo que relaciona los datos del sistema y se denominan dimensiones conformadas. En el mismo sentido se definen los hechos conformados como la reconciliación de las diferentes medidas con la misma semántica que sería posible definir en cada Data Mart. Finalmente el concepto de bus se refiere a la representación gráfica, donde un bus formado por las dimensiones definidas corporativamente, se conecta a cada nuevo Data Mart que se crea. Desde este enfoque los Data Mart, son un subconjunto lógico del DWH completo; es decir son una restricción del DWH a un simple proceso de negocio o a un grupo de procesos de negocio relacionados. Kimball impone algunos requerimientos de diseño específicos para los Data Mart, como que cada Data Mart debe estar representado por un modelo dimensional y dentro de un único DWH y todos los Data Mart que formen un DWH deben estar construidos desde dimensiones conformadas y hechos conformados1, respetando así la Arquitectura de Bus definida. Y manifiesta que un Data Mart no debe estar formado por datos sumarizados, sino que sostiene que los Data Mart deben estar basados en datos atómicos, y pueden o no contener sumarizaciones que mejoren la performance. Es preciso señalar que el Enfoque de la Arquitectura Bus es fácil de escalar para el futuro, sin la necesidad de modificar las estructuras DWH que se ha construido. Se debe especificar que Técnica de Diseño se usará para el diseño. 1
Dimensiones conformadas y los Hechos conformados en lo sucesivo se llamarán simplemente como Dimensiones y Hechos respectivamente.
X. Estudio e identificación de las fuentes de datos
Es importante identificar y estudiar los recursos de la data que se usará para cargar el modelo antes de comenzar con el diseño del DWH. Las entidades de las fuentes se necesitan y deben ser documentados para mejorar la consistencia del mapeo. También se toman en cuenta las reglas de negocios, conversiones de dominio, etc., toda la metadata respecto al origen de los datos se debe documentar para el modelo del DWH. XI. Diseño
Conceptual
Para llevar a cabo el Diseño Conceptual, se elegirá el Modelo CMDM (Conceptual Multidimensional Data Model) [BI18], por tener un lenguaje gráfico, restricciones de integridad que enriquecen la capacidad de expresión del modelo. CMDM es un modelo conceptual orientado al diseño de estructuras multidimensionales que propone estructuras de datos y un mecanismo de especificación de restricciones de integridad. El Modelo CMDM distingue entre las Dimensiones que identifican los objetos de la realidad y las Relaciones Dimensionales que representan las relaciones multidimensionales existentes entre dichos objetos. La estructura básica del CMDM se conforma de: [BI18] - Niveles: Un nivel representa un conjunto de datos. -
−
Dimensiones: Representan los criterios de análisis.
Con jerarquías formadas por niveles: Los niveles se representan en jerarquías. Cada jerarquía esta compuesta por una o mas niveles. En cada jerarquía se tiene una relación uno a muchos entre objetos de nivel superior e inferior.
Dimensionalidad genérica: Las medidas se tratan como dimensión más.
Relaciones Dimensionales: Representan cruzamientos entre dimensiones.
Ejemplo:
Para que se facilite el entendimiento de la estructura básica del Modelo CMDM se da el siguiente ejemplo. En la siguiente Ilustración se muestra la definición gráfica de la Dimensión Artículos, Clientes, Vendedores, Fechas y Cantidades del Modelo CMDM, las Dimensiones se estructuran en Jerarquías con diferentes niveles de detalle; el nombre de la dimensión está en la esquina superior izquierda del recuadro, los cuadros de texto son los niveles de la dimensión, sus nombres aparecen en negrita y subrayados, debajo de estos nombres, se hallan los atributos que la conforman y las jerarquías de niveles se representan por flechas entre los niveles, del nivel con menos agregación (hijo) al nivel con más agregación (padre).
ILUSTRACION 14: Representación Gráfica de Dimensiones en CMDM [BI04] Los cruzamientos entre dimensiones se denominan Relaciones Dimensionales, en la siguiente ilustración se muestra la definición de la Relación Dimensional Venta en el Modelo CMDM. En la relación se cruzan las Dimensiones: Artículos, Clientes, Vendedores, Fechas y Cantidades.
ILUSTRACION 15: Representación Gráfica de las Relaciones Dimensionales en CMDM [BI02]
En CMDM, una Relación Dimensional representa un espacio de cubos resultante de cruzar niveles de las dimensiones. Una Relación Dimensional en realidad representa a muchos cubos y este espacio de cubos puede restringirse mediante las restricciones de integridad del propio modelo. Las restricciones se construyen en base a predicados con cuantificadores ( ∀ , ∃, ¬) para indicar que “Todos los cubos deben tener”, o “Debe existir un cubo que tenga” o “Ningún cubo debe tener” dicha estructura. Ejemplo: Debe existir un cubo que cruce el nivel Mes con el nivel Producto. Estas restricciones sugieren qué cubos sería interesante tener y cuáles no deberían existir. Sin embargo, la decisión de cuáles de esos cubos se deben materializar se debe tomar posteriormente. XII. Diseño
Lógico Específico
En [BI02] al Diseño Lógico se le divide en Diseño Lógico Específico y Diseño Lógico General, al cual se hará referencia. El Diseño Lógico Específico se basa fundamentalmente en el Diseño Lógico Dimensional. Se realizan las siguientes actividades: −
Definición del tipo de almacenamiento:
Se define el tipo de almacenamiento dependiendo del uso de tecnología relacional o Dimensional. Según consideraciones de tamaño y grado de dispersión de la data existente (por ejemplo, se puede optar por la tecnología relacional para el almacenamiento de más bajo nivel de granularidad y tecnología Dimensional para los resúmenes precalculados. Para esta propuesta fundamentalmente se enfoca en la Tecnología Dimensional. Y para que se obtenga tal fin se utilizarán los Lineamientos y Mapeos.
Los Lineamientos:
Son información de Diseño Lógico que complementan al Modelo Conceptual y permiten al diseñador dar pautas sobre el Esquema Lógico deseado para el DWH. Mediante los Lineamientos, el diseñador define el estilo de diseño para el DWH (copo de nieve, estrella, mixto) e indica requerimientos de performance y almacenamiento (por ejemplo indicando que cubos implementar), etc. En todos los casos se trata de información adicional ingresada por el diseñador en forma explícita. Existen 3 tipos de lineamientos: [BI04] •
Materialización de Relaciones:
Permite indicar qué cubos se quieren materializar o realizar, atendiendo a los requerimientos de performance y almacenamiento; es decir, este lineamiento permite indicar qué cubos se quieren desarrollar. En este contexto, materializar un cubo corresponde a precalcular los valores para los cruzamientos de las dimensiones y almacenarlos en una tabla. Luego se pueden obtener otros cruzamientos mediante operaciones efectuadas sobre éstos. En CMDM, un cubo se define mediante una macro que indica los niveles y la medida del cubo [BI18]. Un cubo debe tener al menos un nivel de cada dimensión, uno de ellos en el rol de medida. Consideramos que esta característica es demasiado restrictiva y excluye algunos casos de interés y que se necesita una definición de cubos más libre o relajada, donde además de los cubos que se pueden especificar en CMDM se puedan representar: ♦
Cubos que no tengan medidas. Esto es interesante para representar sólo cruzamientos.
♦
Cubos que omitan algunas de las dimensiones de la relación dimensional. Esto tiene sentido cuando se quiere sumarizar totalmente la dimensión, es decir, no se quiere detalle a ningún nivel sino simplemente el total de la dimensión.
Como lineamiento, el diseñador debe indicar el conjunto de cubos que serán implementados y almacenados físicamente en el DWH. Para que la materialización se corresponda con el esquema conceptual, se debe indicar al menos un cubo que materialice cada relación dimensional. Un cubo esta formado por un nombre, una relación a la cual materializa, un conjunto de niveles que forman su nivel de detalle, u opcionalmente un nivel que es elegido como medida. Gráficamente se representan con un cubo unido a varios niveles (rectángulo blanco) que conforman el nivel de detalle. El nombre está dentro del cubo, y entre paréntesis el nombre de la relación que materializa. Las medidas corresponden a los niveles marcados por una flecha. Por ejemplo, si se desease materializar tres cubos para la Relación Dimensional Venta: 1- Con detalle de Artículos, Clientes, Vendedores y Meses. 2- Con detalle de Artículos, Rubros, Vendedores y Meses. 3- Con detalle de Artículos y Meses.
ILUSTRACION 16: Materialización de Relaciones, Cubo Ventas [BI04] Se materializó la Relación Dimensional Ventas y se obtuvo: Cubo Ventas-1, Cubo Ventas-2, Cubo Ventas-3 de la Relación Dimensional Ventas. El Cubo Ventas-1 tiene por niveles: Meses, Artículos, Clientes, Vendedores; y por medida a Cantidades. •
Fragmentación Vertical de Dimensiones:
Permite elegir el estilo de diseño deseado para el DWH, indicando el grado de normalización que se desee desarrollar para las dimensiones, por ejemplo, un esquema estrella, denormalizar todas las dimensiones en una sola tabla; o un esquema copo de nieve, normalizando todas las dimensiones; o estrategias mixtas, en este último caso, se indica qué dimensiones desnormalizar, normalizar o fragmentar. También se puede tratar de forma diferente cada dimensión, indicando para cada una si se normaliza, denormaliza o efectúa una estrategia intermedia, indicando, en este último caso, qué niveles se guardaran juntos. En este lineamiento para cada dimensión, se indica qué niveles se desean almacenar juntos, conformando una fragmentación de los niveles de la dimensión. Un fragmento es un subconjunto de los niveles de la dimensión que se desean almacenar juntos. Se define por extensión una función que a cada dimensión le haga corresponder un conjunto de fragmento. Para que una fragmentación tenga sentido los niveles de cada fragmento deben estar relacionados jerárquicamente; es decir, si se considera el grafo
que representa a la jerarquía de la dimensión, el subgrafo inducido por los niveles del fragmento debe ser semejante. [BI04] Ejemplo: Si se decide seguir las siguientes estrategias de diseño para las dimensiones: [BI04] o
o
o o o
Clientes: 2 fragmentos, uno con cliente y rubro, y el otro con los restantes. Artículos: 3 fragmentos, uno con artículo y tamaño, otro con producto y duración, y el otro con familia. Vendedores: Denormalizada. Fechas: Denormalizada. Cantidades: No se implementará, será utilizada como medidas.
La siguiente Ilustración muestra la representación gráfica de los fragmentos. Los niveles coloreados con el mismo color pertenecen al mismo fragmento, lo que significa que quieren almacenarse juntos.
ILUSTRACION 17: Fragmentación de Dimensiones [BI04] •
Fragmentación Horizontal de Cubos:
Permite almacenar por separado datos históricos, o dividir la instancia de los cubos de acuerdo a los criterios del diseñador. Una tabla hechos puede contener gran cantidad de información histórica lo que la vuelve ineficiente para las consultas. Esta tabla se puede fragmentar horizontalmente, guardando un subconjunto de las tuplas en cada fragmento, lo que se denomina Bandas . Para definir una fragmentación, las condiciones que distinguen una banda de otra, deben ser expresadas en términos de los ítems de los niveles del cubo. Existen dos propiedades [BI04] que se debe cumplir en la fragmentación horizontal: Completitud y Disjuntez. La propiedad de completitud exige que cada tupla esté en alguno de los fragmentos, y la propiedad de Disjuntez exige que cada tupla que esté en a lo sumo un fragmento. Ejemplo: Se considera la siguiente fragmentación:
La fragmentación no es completa, ya que las tuplas correspondientes a 1999 no pertenecen a ningún fragmento; y no es disjunta, ya que las tuplas correspondientes a 1997 pertenecen a los dos fragmentos. En el contexto de BD distribuidas, estas propiedades se deben cumplir para asegurar la completitud de los datos consultados, minimizando la redundancia. En el contexto del DWH, es importante que se considere estas propiedades, pero no es necesario que se cumplan. Si no se cumple la propiedad de Disjuntez se obtiene redundancia, pero esto no es necesariamente un problema en un DWH. Por ejemplo, es común mantener Tablas de Hechos con toda la historia, y tablas de hechos para los datos del último año. Respecto a la Completitud , es relevante evitar la pérdida de información a nivel global, pero no siempre se debe cumplir localmente en la fragmentación de cada cubo. Ejemplo: Se consideran dos cubos que materializan la Relación Dimensional Venta, uno con detalle mensual y otro con detalle anual. Se realiza la siguiente fragmentación sobre los mismos:
La fragmentación del cubo mensual es completa, pero la del cubo anual sólo tiene información de los últimos años. Sin embargo, las tuplas que no pertenecen al fragmento del cubo anual, pueden obtenerse a partir de los fragmentos del cubo mensual, por lo que no hay pérdida de información.
Al haber redundancia, la completitud de las fragmentaciones debe ser considerada globalmente. En esta propuesta no se exigirá que se cumplan las propiedades, pero se sugiere tenerlas en cuenta durante la definición de la fragmentación. Ejemplo: Gráficamente la fragmentación se representa como un bloque de llamada a partir del cubo, dentro del bloque se escriben las franjas. La ilustración muestra un conjunto de franjas asociado al Cubo venta-1. Las dos primeras franjas determinan las ventas posteriores a enero de 2000 del vendedor Pérez y del resto de los vendedores (menos Pérez). La tercera franja determina las ventas anteriores a ene de 2000 de cualquier vendedor. La fragmentación es completa y disjunta. [BI04]
ILUSTRACION 18: Fragmentación de Cubos [BI04]
Un Mapeo:
Es una función que muestra como corresponden los objetos del Esquema Conceptual con la(s) fuente(s) de origen. Los mapeos son funciones que asocian a cada ítem de un objeto del Esquema Conceptual una expresión de mapeo, construida en base a las tablas y atributos de la fuente de origen. Estas funciones son definidas por el diseñador en forma explícita. Se tiene una función de mapeo para cada fragmento de la Dimensión y una función de mapeo para cada Cubo. Un cubo puede mapearse a las fuentes mediante una función de mapeo (mapeo explícito) o puede indicarse como efectuar un drill-up respecto a otro cubo ya mapeado, que tiene más detalle. Una expresión de mapeo puede ser un atributo de una tabla fuente (directo), o un cálculo que involucra varios atributos de una tupla (cálculo simple), o una totalización que involucra varios atributos de varias tuplas (cálculo agregado) o algo externo a las fuentes como una constante, una estampa de tiempo o dígitos de versión.
Esta vinculación se realiza definiendo una función de mapeo que haga corresponder los ítems del fragmento o cubo con las tablas fuentes. Inicialmente se tiene una función de mapeo para cada fragmento de dimensión, y una función de mapeo para cada cubo. Al fragmentar los cubos se obtiene una función para cada franja de cada cubo. Gráficamente una función de mapeo se representa por flechas entre los ítems de un esquema intermedio y los atributos de las tablas fuentes. Cuando el mapeo es directo se representa con una línea corrida, cuando es un cálculo se representa con una línea cortada a cada atributo que interviene en el cálculo y se adjunta la definición del cálculo y cuando es externo no se utilizan líneas pero se adjunta la expresión a la que mapea. En la vinculación de un fragmento o un cubo pueden existir condiciones, por ejemplo que un atributo se encuentre en determinado rango. Estas condiciones pueden deberse a restricciones en el esquema conceptual o a restricciones que deseen aplicarse a las fuentes. Las funciones de mapeo se utilizan en dos contextos: •
Mapeo de Fragmentos:
Este mapeo vincula los fragmentos de dimensiones con las tablas de las fuentes de origen. Para mapear un fragmento se debe definir una función de mapeo para todos sus ítems, esto incluye algunos ítems de niveles superiores. Si corresponde, se debe definir una condición que deban cumplir los atributos de las fuentes. Cada función de mapeo representa una vista o expresión SQL que tiene en el cabezal (SELECT) las expresiones de mapeo y obtiene los datos (FROM) de las tablas referenciadas en dichas expresiones, imponiendo los links entre las tablas como condición de Join (WHERE). Las tablas involucradas deben tener links definidos, no tienen sentido los productos cartesianos. En este ejemplo se asocia al fragmento de la Dimensión Geografía la siguiente vista SQL:
Desde el punto de vista de las instancias, la instancia de la vista SQL debe coincidir con la instancia esperada para el fragmento o cubo que se quiere mapear (se mapea a sus ítems). La vista SQL no se implementará, la generación del esquema lógico se hará a través de transformaciones de esquemas que conducirán al mismo resultado (posteriormente realizadas). En la ilustración se muestra una función de mapeo para la Dimensión Geografía, con un único fragmento (color rosa). El ítem país tiene un mapeo externo de tipo constante, el ítem zona tiene un mapeo calculado en base al atributo zona de la Tabla Departamentos. Los demás ítems tienen mapeos directos.
ILUSTRACION 19: Mapeo de Fragmentos [BI04] Además en el ejemplo, el nivel Zona puede tener una restricción indicando que sólo interesan las zonas menores a 10, que pueden ser por ejemplo, las zonas uruguayas. Esta es una restricción del esquema conceptual. También puede ocurrir que en la Tabla Ciudades se almacenen ciudades necesarias en varios sistemas o secciones y que para el DWH sólo interesen las que tienen Clasificación R. Esta es una restricción respecto a las fuentes. Ambas restricciones deben tenerse en cuenta al establecer los mapeos e incorporar una condición tipo: Estas restricciones pueden verse como condiciones adicionales de la vista SQL. Para el ejemplo anterior se agregaría a la expresión:
Gráficamente las condiciones se representan como llamadas (Callouts). La siguiente ilustración muestra la incorporación de las condiciones al mapeo anterior.
ILUSTRACION 20: Incorporación de Callouts en el Mapeo de Fragmentos [BI04] Formalmente, las condiciones son predicados sobre atributos de las tablas fuentes. Como en una condición pueden intervenir atributos de varias tablas, se les pone como prefijo el nombre de la tabla para evitar ambigüedades. Para definir las condiciones el diseñador debe tener en cuenta las restricciones del esquema conceptual y expresarlas en término de los atributos a los que mapean. Esta tarea se podría semi-automatizar tomando como entrada las restricciones del esquema conceptual. El diseñador además se debe basar en su conocimiento de las BD fuentes. Considerar el mapeo de fragmentos como una consulta SQL ayuda en la elección de los ítems adecuados. [BI04] •
Mapeo de Cubos:
Este mapeo vincular los cubos con las tablas fuentes. Gráficamente un mapeo base de cubo se representa en forma análoga a un mapeo de fragmento. En los niveles identificados por un único ítem pueden omitirse los ítems. En los niveles identificados por varios ítems deben detallarse todos. Dichos ítems pueden ser del nivel o identificadores de niveles superiores cuando el nivel tiene clave débil. Mediante un pentágono se especifican los predicados de roll-up para las medidas. En la siguiente ilustración se muestra una función de mapeo para el cubo Venta-1.
ILUSTRACION 21: Representación gráfica de un Mapeo del Cubo Venta-1 [BI04] Un mapeo recursivo de cubo se representa uniendo los cubos por una flecha gruesa. Se expresa la función de mapeo entre los ítems de los niveles base y nuevos de manera análoga un mapeo base. Mediante un pentágono se especifican los predicados de Roll-Up para las medidas. La siguiente ilustración se muestra el mapeo del cubo venta-2 como un Drill-Up del Cubo Venta-1 en la Dimensión Clientes (del nivel cliente, a los niveles ciudad y rubro), por ello se indica mediante un mapeo como realizar el Drill-Up.
ILUSTRACION 22: Representación gráfica de un Mapeo Recursivo de un Cubo. [BI04]
Y por ultimo en la ilustración siguiente se muestra el mapeo del Cubo Venta-3 como Drill-Up del Cubo Venta-1 eliminando dimensiones.
ILUSTRACION 23: Representación gráfica del Cubo Venta-3 [BI04] Los mapeos base pueden pensarse como una consulta SQL al igual que los mapeos de fragmentos. Valen las mismas consideraciones de elección de atributos que para fragmentos, con la distinción de que se trata de realizar la menor cantidad posible de joins por razones de performance. Es decir, que siempre que se tengan definidas claves foráneas o se tenga confianza en la calidad de los datos, se puede evitar el join de algunas tablas. En el ejemplo del mapeo del Cubo Venta-2 se mapea el ítem id-cliente del nivel cliente al atributo cliente de la Tabla Facturas en lugar de realizar un join con la tabla Clientes y mapearlo allí. La instancia de esa consulta SQL debe coincidir con la instancia esperada para el cubo. Los mapeos recursivos simplifican la tarea de definición de mapeos. Alcanza con que el diseñador realice los mapeos de los Drill-Up, en forma análoga a como mapea un fragmento. Los mapeos de los fragmentos de las dimensiones pueden ayudar a definir los mapeos de los Drill-Up. Se podría realizar un mecanismo semi-automático para deducirlos a partir de los mapeos de fragmentos. −
Presentación del Esquema Lógico:
Se presenta el Esquema Lógico conformado por el Modelo Dimensional resultante e ilustración de los esquemas resultantes del Modelo Dimensional, compuestos por las Tablas de Hechos y sus respectivas Tablas de Dimensiones.
Modelo Dimensional:
Una vez que se diseñó los cubos, con sus respectivas Tablas de Hechos, Dimensiones y medidas, se procede a realizar el Esquema Lógico , modelo de la nueva BD que formará el DWH. Como los DWH se organizan en Esquemas de Estrella o Copo de Nieve, implica una mayor facilidad del entendimiento de la información y los datos por parte de o los usuarios, un mejor desempeño en las
consultas a la BD para aplicaciones de soporte de decisiones y demanda menor espacio de almacenamiento para las BD robustas. Como resultado de lo que se analizó anteriormente, se obtiene gráficamente el Esquema Lógico o Modelo Dimensional, se indica que esquemas lo conforman (Copos de Nieve, Estrella) representados por las Tablas de Hechos, sus respectivas Dimensiones y las Relaciones entre ellas. La siguiente ilustración es un ejemplo del Esquema Lógico o Modelo Dimensional resultante para [BI02]. Este Modelo Dimensional esta compuesto de tres Esquemas Copos de Nieve y un Esquema Estrella.
ILUSTRACION 24: Esquema Lógico o Modelo Dimensional [BI02]
Sub-esquemas resultantes del Modelo Dimensional:
Para que se comprenda mejor el Modelo Dimensional del DWH que se obtuvo, se detallan los sub-esquemas que lo componen, conformados por las Tablas de Hechos y las Dimensiones relacionadas y finalmente en cada uno de ellos se realiza su descripción. Ejemplo: Del Modelo Dimensional anterior, se extrae el esquema resultante siguiente: Tabla Hechos Ventas 1:
La ilustración indica las relaciones existentes entre la Tabla de Hechos Ventas 1 y las Dimensiones: Vendedor, Clientes, Producto y Tiempo. Los atributos cod_producto, cod_cliente, cod_vendedor e id_tiempo; compuestos, conforman la Clave Primaria de la Tabla de Hechos. Este esquema permite obtener información para el análisis de las ventas realizadas durante un determinado período de tiempo, con un detalle mensual, y por cada ítem o línea de producto. [BI02]
ILUSTRACION 25: Esquema Dimensional en Copo de Nieve de la Tabla de Hechos Ventas1 [BI02] XIII. Diseño Lógico General
El Diseño lógico General consta de dos partes: −
Esquema General:
Lo conforman la definición y la forma en que se va ha realizar la obtención de los datos, transformación de los mismos, carga y descarga del modelo y la explotación del DWH. El esquema a utilizar en el desarrollo del proyecto contempla las siguientes características, cada una de ellas se detalla a continuación: (para ejemplificar esta etapa se extrae el ejemplo de [BI02]) 1. Base Operacional:
Se indica la BD que contiene los datos a analizar. Ejemplo: Progress versión 8.3b: Esta no posee un driver ODBC por lo cual los datos son extraídos mediante un procedimiento desarrollado sobre la plataforma. 2. Archivos de Datos:
Éstos se crean al ejecutar el procedimiento y contienen los datos de la base fuente. Los archivos serán creados en un formato Excel .
3. Transformación de Datos:
Será realizada mediante la herramienta que posee Microsoft SQL Server 2000 (Servicio de Transformación de Datos). 4. Arquitectura: Se utiliza el sistema MOLAP incorporado en Microsoft SQL Server 2000 en la herramienta de Analysis Services. Ésta posee una arquitectura de dos niveles: La BD Dimensional, la cual es la encargada del manejo, acceso y obtención del dato y el motor analítico, que es el responsable de la ejecución de los requerimientos OLAP. El nivel de presentación se integra con el de aplicación y proporciona una interfaz a través del cual los usuarios finales visualizan los análisis OLAP. 5. Herramienta Front-End:
Tiene por función presentar la información de una manera más entendible al usuario final, la cual pude contener datos tabulados y/o gráficos de diferentes estilos. Ejemplo: La herramienta a utilizar en esta propuesta será Excel , puesto que los usuarios finales, ejecutivos de la organización tienen un mayor manejo en tal. La ilustración que se muestra a continuación, describe gráficamente el proceso de las cinco etapas descritas.
ILUSTRACION 26: Esquema General del Desarrollo [BI02] −
Diseño del Proceso ETL
Se diseñan los procesos de extracción, transformación, de carga/descarga del modelo y refresque que poblarán el DWH, implican estrategias de limpieza, notificación de errores y notificación de cambios detectados en los cambios provenientes de las bases fuentes. Se considera el uso de herramientas en lugar de realizar una codificación específica debido a dos facilidades principales que ofrecen: La generación automática de metadatos (data acerca de la ejecución de los procesos de carga de los datos) y las facilidades para el mantenimiento de los programas de extracción, transformación y carga.
Para el Proceso de Carga, primeramente se realiza la carga de las Tablas de Dimensiones, y luego la carga de las Tablas de Hechos, ya que durante el proceso de carga de una Tabla de Hechos se deben consultar todas las Tablas de Dimensiones intervinientes previamente cargadas. Ejemplo:
Para el caso en particular el diseño de las ETL se detalla a continuación: [BI02] Los archivos generados en formato Excel por el sistema QAD (fuente de origen) son extraídos, transformados y cargados al DWH por medio de una herramienta de SQL Server 2000, más específicamente DTS (Data Tranformation Services, Servicio de Transformación de Datos). En la ilustración se indica el Diseño del Proceso ETL para el caso de estudio en [BI02].
ILUSTRACION 27: Diseño del Proceso ETL. [BI02] XIV. Diseño de la
Metadata
Se debe diseñar como se estructurara la metadata. Un ejemplo nos presenta la Metodología de IBM en [BI09].
ILUSTRACION 28: Diagrama completo de la Metadata para el DWH [BI09] XV. Diseño
de Objetivos Adicionales
La razón fundamental de diseñar los objetivos adicionales es performance. Son objetivos derivados desde el diseño original de Tablas de Hechos y Tablas Dimensionales. Se debe considerar un máximo permitible de tiempo para una obtener resultados de una interrogante. La metadata para objetivos adicionales debe ser el mismo como los hechos y dimensiones originales, además la metadata debe contener las razones para crear los objetivos adicionales. No es común pronosticar que Objetivos Adicionales se necesitará en la Etapa de Diseño del DWH, debe existir una justificación clara para su creación. Ejemplo:
Si un usuario frecuentemente ejecuta una interrogante que suma a través de una dimensión y explora toda la tabla de hechos, seria recomendable que un objetivo adicional se deba crear con la dimensión eliminada e indicadores sumados para producir una tabla con menos filas para esta interrogante. Se debe crear sólo una dimensión adicional si la dimensión original no se unirá apropiadamente con un hecho adicional.
En la Etapa del Diseño del DWH que se propone se tiene en cuenta que las tareas presentadas son aspectos básicos del diseño, si al momento del desarrollo se requieren agregar módulos y/o profundizar en los temas de diseño estos fácilmente se adaptarán a la propuesta, se presenta el diseño del DWH en términos generales con el fin de obtener una metodología consistente, coherente y completa en sus fases de desarrollo. XVI. Estimación del Tamaño del DWH
Concluido el modelo y diseño del DWH se puede estimar la cantidad de espacio requerido para almacenar datos en cada tabla. Para ello se efectúan los siguientes pasos: (extraídos de [BI21]).
Para entender mejor este algoritmo, se extraen tablas de la misma fuente y se estima la cantidad del espacio siguiendo al algoritmo. Las tablas son:
TABLA 4: Tablas del DWH del Sistema de Apoyo Gerencial Universitario [BI21]
Nombre Tabla
Cant col
Cant filas
Esp fijo
Cant filas var
Max long var
Null bitmap
Tam dato var
Tam col
Pag por filas
Filas libres por pag
Filas por pag
dwi_a_enc_rta
10
10
30
2
260
4
266
304
26
0
1
Tam tabla
8192
a l b a t a l e d s o t u b i r t a #
dwi_act
8
. x o r p a r a l u c l a C
19309
4 2 = B 4 x 6 : t n i 2 = B 2 x 1 : t n i l l a m s 4 = B 4 x 1 : e m i t e t a d l l a m s
24
a l b a t a l n e r a h c r a v #
1
5 = ) 5 ( r a h c r a v 5 5 2 = ) = 5 5 2 ( r a h c r a v
10
: 3 O S A P
4 = ) 8 / ) 7 + 0 1 ( ( + 2 0 1 = s l o C _ m u N : e d n o D
3
: 4 O S A P
6 6 2 =
14
: 6 O S A P
4
4 0 3 (
4 + +
0 6 2
+ ) 2 * 2 ( + 2 : e d n o D 2 = s e l b a i r a v l_ o c _ m u N 0 6 2 = x a m r_ a v _ o ñ a m a T
: 5 O S A P
6 6 2
+
: e d n o D 0 3 = s o j i f s_ o t a d _ o ñ a m a t 6 6 2 = r a v s_ o t a d _ o ñ a m a t 4 = p a m t i B _ l l u N
0 3
45
) 2 +
/ 6 9 0 8 : e d n o D 4 0 3 = l o c _ m a t
172
: 7 O S A P
0 0 1 = r o t c a F _ l l i F
0
: 8 O S A P ) 0 6 2 (
/ 0 1 : e d n o D 0 1 = s a l i f _ o r e m u N 6 2 = a n i g a p r_ o p s_ a l i F 0 = s e r b i l s_ a n i g a p r_ o p s_ a l i F
113
: 9 O S A P
2 9 1 8 = 1 * 2 9 1 8 : e d n o D 1 = s a n i g á P _ o r e m ú N
925696
a l b a t a l e d s o t u b i r t a #
. x o r p a r a l u c l a C
6 1 = B 4 x 4 : t n i 4 = B 2 x 2 : t n i l l a m s 4 = B 4 x 1 : e m i t e t a d l l a m s
a l b a t a l n e r a h c r a v #
0 1 = ) 0 1 ( r a h c r a v
: 3 O S A P
3 = ) 8 / ) 7 + 8 ( ( + 2 8 = s l o C _ m u N : e d n o D
: 4 O S A P
4 1 =
0 1
+ ) 2 * 1 ( + 2 : e d n o D 1 = s e l b a i r a v l_ o c _ m u N 0 1 = x a m r_ a v _ o ñ a m a T
: 5 O S A P
4 +
3
+
4 1
+
4
2 : e d n o D 4 2 = s o j i f s_ o t a d _ o ñ a m a t 4 1 = r a v s_ o t a d _ o ñ a m a t 3 = p a m t i B _ l l u N
: 6 O S A P
) 2 + 5 4 ( / 6 9 0 8 : e d n o D 5 4 = l o c _ m a t
: 7 O S A P
0 0 1 = r o t c a F _ l l i F
: 8 O S A P ) 0 2 7 1 (
/
: e d n o D 9 0 3 9 1 = s a l i f _ o r e m u N 2 7 1 = a n i g a p r_ o p s_ a l i F 0 = s e r b i l s_ a n i g a p r_ o p s_ a l i F
9 0 3 9 1
: 9 O S A P
6 9 6 5 2 9 = 3 1 1 * 2 9 1 8 : e d n o D 3 1 1 = s a n i g á P _ o r e m ú N
TOTAL BYTES
TABLA 5: Cálculo del espacio para las tablas indicadas como ejemplo [BI21]
933.888
Después de realizar el cálculo, se obtiene 934 MB de espacio que requiere el DWH, se recomienda aumentar a esta cantidad en un 25% promedio (de acuerdo a los criterios del equipo del DWH), este porcentaje es relativo, quedando 1.2 GB que se requiere de espacio para almacenar el DWH en el disco.
ETAPA 2.6: Validación del Diseño El objetivo en esta etapa es garantizar que las tareas del diseño se hayan realizado eficientemente y que se tuvo en cuenta los requerimientos especificados en la Fase de Visionado y de las etapas anteriores de la Fase de Planificación del DWH. La Tabla siguiente muestra el bosquejo de la Validación del Diseño. Tareas del Diseño del DWH
Selección de las Técnicas de Diseño
Requisitos
Verificación de los Requisitos
Estado Final de las tareas de Diseño
(se indican requisitos involucrados en cada Todos/Ninguno/ tarea del diseño) indicar cuales
Estudio e identificación de las fuentes de datos Diseño Conceptual Diseño Lógico Específico Diseño Lógico General Diseño de la Metadata Diseño Objetivos Adicionales
TABLA 6: Validación del Diseño del DWH [FP] También la Validación del Diseño se lleva a cabo con el usuario, el hands-on testing es la mejor aproximación, se deja al usuario que intente responder las interrogantes a pesar de la manipulación de un test objetivo. Aparte del testing, se revisa con el usuario algunas adiciones y cambios para el modelo para asegurar que sean comprendidas.
Esta claro que lo que no se entienda o presente cualquier tipo de problema retorna a la Etapa de Análisis de Requerimientos para su aclaración y retroalimentación al diseño, la data validada del modelo pasa a una Fase Anexa, de Pruebas, para que luego se pueda continuar con el Proceso de Elaboración del DWH.
MILESTONE 2: Plan de Proyecto Aprobado Es la culminación de la Fase de Planificación, en este milestone los clientes y los miembros del equipo están de acuerdo en los detalles en que se entregarán y cuando. El equipo vuelve a evaluar los riesgos, actualiza las prioridades y establece los últimos detalles de las estimaciones para los recursos y programas, aprueban especificaciones. Los roles y responsabilidades son bien definidas y los mecanismos sirven para direccionar las áreas de los riegos del proyecto. Al terminar este milestone no significa que todas las decisiones que llegan a la Fase de Planificación sean finales, el equipo debe revisar y aprobar algunas sugerencias cambiantes.
Entregables − − − − − − −
Trabajo en Power Point, presentación de la Fase de Planificación del DWH. Plan de Proyecto Master. Documento de Especificaciones de los Requerimientos. Documento del Diseño de la Metadata y de los Objetivos Adicionales para el Proyecto del DWH. Informe de Validación del Modelado. Informe de la Validación del Diseño. Documento del Modelo del DWH (Modelamiento, Diseño del DWH).
Roles y Responsabilidades del Equipo en la Fase de Planificación Administración del Producto: Desarrollo del Diseño Conceptual, Análisis de los Requerimientos del Negocio, plan de comunicación. 8 Administración del Programa: Desarrollo del Diseño Conceptual y Lógico (específico y general), Especificaciones de los requerimientos, plan principal del proyecto, proyecto principal del programa. 9 Desarrollo: Evaluación de la tecnología, Diseño Lógico y Físico, desarrollo del Plan/Programa, desarrollo de las estimaciones. 10 Experiencia del Usuario: Uso de escenarios/uso de casos, requerimientos del usuario, localización y accesibilidad de los requerimientos, documentación del usuario/preparación del plan/programas para la utilidad de las pruebas, capacitación. 11 Pruebas: Validación del modelo, Validación del Diseño, pruebas del modelado, pruebas del diseño, Prueba plan/programa. 7
12
Administración de Versiones: Evaluación del Diseño.
FASE 3: DESARROLLO Durante la fase de Desarrollo el equipo logra la mayor parte de la construcción de los componentes de la solución (se desarrolla código, se pobla el DWH con datos, etc.); sin embargo, parte de este trabajo continúa en la Fase de Estabilización en respuesta a las pruebas. La Fase de Desarrollo involucra más que desarrollo de código y de software; la infraestructura también se desarrolla durante esta fase y todos los roles están activos en los entregables del desarrollo y las pruebas que los criterios de aceptación sean conocidos. Un aspecto importante de esta fase es la preparación de un documento de mantenimiento que informa sobre futuras referencias, entre ellas las características de las versiones futuras, procesos de mantenimiento, etc. La siguiente ilustración muestra las Etapas de la Fase de Desarrollo.
ILUSTRACION 29: Fase de Desarrollo del Ciclo de Vida del DWH [FP]
ETAPA 3.1: Consideraciones de la Solución Se debe tener en cuenta los siguientes ítems: [BI10]
−
Definir el mejor diseño físico para el modelo de datos. El diseño físico debe estar orientado a generar buen rendimiento en el procesamiento de consultas, a diferencia del modelo lógico que está orientado al usuario y a la facilidad de consulta.
−
Definir los procesos de Extracción, filtro, Transformación de información y Carga de datos que se deben efectuar para poblar el Modelo de Datos.
−
Definir los procesos de Administración de la data que permanece en el DWH.
−
Definir técnicas de explotación explotación del DWH dependiendo dependiendo del tipo de aplicación que se le de a la data: Query & Reporting, OLAP, Sistemas de Información Ejecutivos, Sistema de Apoyo a Decisiones, Decisiones, Visualización Visualización de la información, información, Minería de Datos, etc. etc. Esta Estass técn técnic icas as debe debenn esta estarr dire direct ctam amen ente te vinc vincul ulad adas as con con el Proc Proces esoo de Inteligencia de Negocios que el equipo posteriormente empleará.
ETAPA 3.2: Construcción del Documento del Desarrollo En esta etapa se especifica los módulos desarrollados del DWH, ilustrando lo realizado con gráficas y cualquier método que el equipo lo acuerde.
ETAPA ETAPA 3.3: Validación del Desarrollo Des arrollo Es imp import ortant antee que los módulo módulos, s, proces procesos os de desarr desarroll olloo de softwa software, re, y cualqu cualquie ier r aplicación que se desarrolle se verifique probando la funcionalidad, previamente a las fases posteriores con la finalidad de ir refinando la solución para que culmine sin errores. Esta etapa la efectúa el Equipo del DWH y los usuarios.
MILESTONE 3: Alcance completo La Fase de Desarrollo culmina con al Milestone Alcance Completo. En este milestone, todas las características se completan y la solución esta preparada para pruebas externas y la estabilización. Este milestones es la oportunidad para clientes y usuarios, operaciones y apoyo al personal y evaluar la solución e identificación de algún tema restante que debe ser diseccionado antes que la solución haya sido liberada. Es importante señalar que número de Build se realizó, así como por ejemplo: Build Interno N completo, Build Interno N+1 completo.
Entregables -
Trabajo en Power Point, presentación de la Fase de Desarrollo del DWH. Fuentes de Código y Ejecutables. Documento de Instalaciones y configuraciones. Documento del Desarrollo del DWH.
Roles y Responsabilidades del Equipo en la Fase de Desarrollo 1
Administración del Producto: Expectativas del Cliente.
2
Administración del Programa: Admin Administ istrac ración ión de las las Espec Especifi ificac cacion iones es de los requer requerimi imient entos os,, traye trayecto ctoria ria del proyecto, actualización de planes.
3
Desarrollo: Desa Desarr rrol ollo lo de códi código go,, infr infrae aest stru ruct ctur uraa de desa desarr rrol ollo lo,, Fu Fuen ente tess de Códi Código go y Ejecutables.
4
Experiencia del Usuario: Trabajo en Power Point, Preparación del Documento del Desarrollo del DWH.
5
Pruebas: Prueba Funcional, temas de identificación, actualización del plan de prueba.
6
Administración de Versiones: Creación y/o actualizaciones del Plan de Extensión y planes pilotos.
FASE 4: ESTABILIZACION La Fase de Estabilización se conduce por las pruebas que se efectúan a las soluciones que sean completas. Estas pruebas enfatizan el uso y operación bajo condiciones de un ambiente real, el equipo se enfoca en resolver errores y preparar la solución para las versiones. Durante esta fase son comunes las pruebas para reportar los errores. La siguiente ilustración muestra las Etapas de la Fase de Estabilización.
ILUSTRACION ILUSTRAC ION 30: Fase de Estabilización del Ciclo de Vida del DWH [FP]
ETAPA ETAPA 4.1: Verificaciones Verifica ciones Para asegurar la estabilidad y el correcto funcionamiento del DWH, se deben priorizar tareas diferentes a diferencia de los sistemas operacionales, operacionales, debido a su orientación a la toma de decisiones. Las pruebas garantizan la estabilidad del DWH antes de que sea llevado con el cliente y/o usuarios. I. Identificación y corrección de los errores
En esta tarea se pretende detectar los errores de todo nivel y darles su inmediata corrección, a fin de que se evite su propagación. Se verifica la data que ingresa al DWH, el funcionamiento del DWH, etc.
MILESTONE 4: Versión aprobada Este milestone ocurre cuando el equipo tiene direccionado todos los temas destacables esta etapa y tiene versionada la solución o un lugar en el servicio. Una vez que se ha corregido los errores entonces la versión esta lista para ser Aprobada y utilizada. Al término de las verificaciones verificaciones que realiza el Equipo del DWH, estas se concluyen con la Aprobación Aprobación Formal de la Prueba de Aceptación del DWH. Esta aprobación involucra verificar que la prueba de un ambiente específico se tiene que ejecutar y se incluya las funcionalidades funcionalidades basados en los requerimientos, además esta Aprobación Formal es parte del milestone.
Entregables − − −
Trabajo en Power Point, presentación de la Fase de Estabilización del DWH. Informe de la ejecución de las pruebas y los resultados a los módulos de la solución (test, herramientas de prueba, Fuentes de Código y ejecutables probados). Informe del Milestone Versión Aprobada.
Roles y Responsabilidades del Equipo en la Fase de Estabilización 1 2 3 4 5 6
Administración del Producto: Desarrollar las planificaciones. Administración del Programa: Seguir la trayectoria del proyecto, identificar identificar errores. Desarrollo: Resolución Resolución de errores, optimización de código. Experiencia del Usuario: Trabajo en Power Point, Estabilización y entrenamiento con el usuario. Pruebas: Realización Realización de pruebas, reporte r eporte de errores y estados. Administración de Versiones: Programa piloto y apoyo, uso de la planificación.
FASE 5: UTILIZACION Durante esta fase, el equipo utiliza el núcleo de la tecnología, sitúa los componentes, estabiliza el uso, transiciona al DWH para operaciones y apoyo; y obtiene la aprobación final de los clientes y/o usuarios del DWH. Después de la utilización el equipo conduce al DWH a la revisión y a una encuesta de satisfacción del cliente. Las tareas de estabilización pueden continuar durante este periodo como componente del DWH se transfiere desde un ambiente de prueba para un ambiente de producción. La siguiente ilustración muestra las Etapas de la Fase de Utilización. FASE DE UTILIZACION
Actividades para el uso del DWH
MILESTONE 5:
Implantación aprobada
ILUSTRACION 31: Fase de Utilización del Ciclo de Vida del DWH [FP]
ETAPA 5.1: Actividades para el uso del DWH I. Preparar material de capacitación del DWH
Se realiza material impreso y/o gráfico sobre el uso y funcionalidad del DWH, presentando un resumen del Ciclo de Vida del DWH en la organización y de la importancia de un uso efectivo. Se recomienda presentar esta información en un formato amigable para la organización. II. Comparación
Alcance/Solución
Se efectúa una comparación entre el Alcance definido en la Fase de Visionado y la Solución que se obtuvo con el fin de contrastar la coherencia de ambos. III. Definir los siguientes pasos a seguir
Esta propuesta metodológica nos permite culminar la Fase1 del proceso de Inteligencia de Negocios, que es el Desarrollo del DWH , el equipo se debe proyectar a los nuevos objetivos que el proceso de BI y la organización lo requiera.
MILESTONE 5: Implantación aprobada Este milestone culmina la Fase de Estabilización, la solución de esta fase debe estar proporcionando las expectativas del valor del negocio para el cliente y el equipo debe tener eficazmente terminado los procesos y las actividades para llegar a alcanzar las metas. El cliente debe estar de acuerdo que el equipo ha conocido sus objetivos antes de que estos sean declarados como una solución en el DWH o se haya concluido el proyecto.
Entregables − − − −
Trabajo en Power Point, presentación de la Fase de Utilización del DWH. Guía/Manual del DWH realizado (funcionalidad, uso, proceso de elaboración). Informe del Milestone Implantación Aprobada (datos de satisfacción del cliente y/o usuario). Documento de Comparación Alcance/Solución y de la Definición de los siguientes pasos a realizar para continuar el Proceso de Inteligencia de Negocios.
Roles y Responsabilidades del Equipo en la Fase de Utilización 1 2 3 4 5 6
Administración del Producto: Retroalimentación al cliente, revisiones. Administración del Programa: Comparación solución/alcance. Desarrollo: Resolución del problema. Experiencia del Usuario: Entrenamiento de la administración del DWH. Pruebas: Prueba de performance. Administración de Versiones: Cambios aprobados.
FASE 6: EVALUACIÓN La Fase de Evaluación es la fase final y analítica del proceso del DWH y nos permite estimar algunos aspectos del valor agregado para la organización y las tomas de decisiones respectivamente. La siguiente ilustración muestra las Etapas de la Fase de Evaluación.
ILUSTRACION 32: Fase de Evaluación del Ciclo de Vida del DWH [FP]
ETAPA 6.1: Impactos del DWH Como ya se hizo referencia el éxito de un proceso de DWH no se encuentra exclusivamente en su elaboración, sino en su uso efectivo para mejorar procesos empresariales, operaciones y decisiones. Posicionar un DWH para que sea usado efectivamente, requiere entender los impactos de elaboración en los siguientes aspectos. [BI05] I. Impactos Humanos
Son aquellos resultados que se presentan sobre la gente de la organización. −
Construcción del DWH:
A diferencia del desarrollo de sistemas en los cuales los requerimientos de la organización se encuentran bien definidos a través del tiempo, construir un DWH depende de la realidad organizacional como de sus condiciones actuales, las cuáles determinan qué debe contener el DWH. La gente de la organización debe participar activamente durante el ciclo de vida del DWH. −
Accediendo al DWH:
El DWH proveerá data que permitirá a los usuarios a acceder a su propia información cuando ellos la requieran. Esta aproximación implica lo siguiente:
−
La gente de la empresa puede necesitar aprender nuevas destrezas. La aparición de nuevas oportunidades en la organización para los especialistas de información. La gran cantidad de reportes en papel serán reducidas o eliminadas. La madurez del DWH dependerá del uso activo y retroalimentación de sus usuarios.
Usando aplicaciones para el sistema (especialmente en el Proceso de BI):
Los usuarios de estas aplicaciones necesitarán menos experiencia para construir su propia información y desarrollar nuevas destrezas. Es decir, que para los usuarios, el
DWH extiende el alcance de la información para que puedan acceder directamente en línea, lo que a la vez contribuye en su capacidad para operar con mayor efectividad las tareas diarias relacionadas con la toma de decisiones. Los usuarios del DWH pueden acceder a una variada información que puede ser vista de forma multidimensional, presentada como una fuente única confiable y disponible directamente por medio de sus estaciones de trabajo. Los usuarios pueden usar sus herramientas familiares, hojas de cálculo, procesadores de textos y software de análisis de datos y análisis estadístico para manipular y evaluar la información obtenida desde el DWH. II. Impactos −
Empresariales
Procesos Empresariales y Decisiones Empresariales:
Se deben considerar los beneficios empresariales potenciales de los siguientes impactos:
−
Los Procesos de Toma de Decisiones pueden ser mejorados mediante la disponibilidad de información, las decisiones se realizan más rápidas y con gente más informada. Los procesos empresariales pueden ser optimizados. El tiempo perdido esperando por información que finalmente es incorrecta o no encontrada, es eliminada. Conexiones y dependencias entre procesos empresariales se vuelven más claros y entendibles, las secuencias de los procesos organizacionales se pueden optimizar para ganar eficiencia y reducir costos. Procesos y datos de los sistemas operacionales, así como los datos en el DWH, son usados y examinados; cuando la data se organiza y estructura para tener significado empresarial, la gente aprende mucho de los sistemas de información; se exponen posibles defectos en aplicaciones actuales, siendo posible entonces mejorar la calidad de las nuevas aplicaciones.
Comunicación e Impactos Organizacionales:
Cuando el DWH comienza a ser la fuente primaria de información empresarial consistente, los siguientes impactos pueden comenzar a presentarse:
La gente tiene mayor confianza en las decisiones empresariales que se toman. Quienes toman la decisión y los afectados conocen que ésta se basa en información confiable. La gente queda mejor capacitada para entender su propio rol y responsabilidades como también los efectos de sus contribuciones y a la vez, desarrollan un mejor entendimiento y apreciación con las contribuciones de otros. La información compartida conduce a un lenguaje común, conocimiento común, y mejoramiento de la comunicación en la empresa; mejorándose así la confianza y cooperación entre distintas áreas de la organización. La visibilidad, accesibilidad y conocimiento de los datos producen mayor confianza en los sistemas operacionales y fomenta aún más su uso.
III. Impactos
Técnicos del DWH
Se tienen los siguientes impactos técnicos: −
Nuevas destrezas de desarrollo:
Cuando se elabora el DWH, el impacto más grande sobre la gente técnica está dada por la curva de aprendizaje, muchas destrezas nuevas se deben aprender, incluyendo conceptos y estructura del DWH.
−
El DWH introduce muchas tecnologías nuevas (ETL, Acceso de Datos, Catálogo de Metadatos, etc.), y cambia la manera que se usa la tecnología existente. Nuevas responsabilidades de soporte, nuevas demandas de recursos y nuevas expectativas, son los efectos de estos cambios. Destrezas de diseño y análisis donde los requerimientos organizacionales no son posibles de definir de una forma estable a través del tiempo. Técnicas de desarrollo incremental y evolutivo. Trabajo en equipo cooperativo con gente de negocios como participantes activos en el desarrollo del proyecto.
Nuevas responsabilidades de operación:
Los cambios sobre los sistemas y datos operacionales deben ser examinados cuidadosamente para determinar el impacto que estos cambios tienen sobre ellos y sobre el DWH. El DWH enriquece las capacidades del usuario autosuficiente y hace que la gerencia pueda ofrecer nuevos servicios a los usuarios, sin interferir con las aplicaciones cotidianas de producción, aunque se requiere una asignación de tiempo y personal técnico para el mantenimiento y operación del DWH.
ETAPA 6.2: Valor del DWH para la Toma de Decisiones El valor de un DWH queda descrito en tres dimensiones: [BI06] −
Mejorar la Entrega de Información:
Información completa, correcta, consistente, oportuna y accesible; información que la gente necesita, en el tiempo que la necesita y en el formato que la necesita. −
Facilitar el Proceso de Toma de Decisiones:
Con un mayor soporte de información se obtienen decisiones más rápidas y la gente de negocios adquiere mayor confianza en sus propias decisiones y las del resto, y se logra un mayor entendimiento de los impactos de sus decisiones. −
Impacto Positivo sobre los Procesos Organizacionales:
Cuando se accede a una mejor calidad de información, la organización puede mejorar:
Eliminando los retardos de los procesos empresariales que resultan de información incorrecta, inconsistente y/o no existente. Integrar y optimizar procesos organizacionales a través del uso compartido e integrado de las fuentes de información.
Eliminar la producción y el procesamiento de datos que no son usados ni necesarios, producto de aplicaciones mal diseñados o ya no utilizados.
ETAPA 6.3. Balance Costo/Valor Lograr una cuantificación económica de los factores de valor no es fácil ni natural a diferencia de los factores de costos, agregar valor económico a los factores de valor resulta ser en extremo complejo y subjetivo. Una alternativa es hacer una valoración desde la perspectiva de costos evitables, relacionados con los costos de no disponer en la organización de información apropiada, para el proceso de Toma de Decisiones. En este tipo de proyectos es difícil estimar de antemano con exactitud los beneficios económicos, aunque si el valor que introduce en la organización que se implementa, pero se puede mostrar en base a estadísticas realizadas el beneficio que se obtendrá al mediano y largo plazo. En un estudio encargado a la compañía Gartner Group por 20 vendedores y consultores, se encontró un Retorno Promedio Total de la Inversión (Return On Investment, ROI) de 401% en 2.3 años. El estudio se realizó sobre 62 organizaciones que implementaron sistemas de apoyo gerencial basados en un DWH. En este estudio se excluyeron los proyectos fracasados, así como los ejecutados por fuera del cronograma y costos debido a que sólo interesan los proyectos que fueron ejecutados e implementados correctamente desde el punto de vista de todas las áreas de Ingeniería de Software (fundamentalmente Planificación y Gestión de Cambios). [BI21] Este estudio se resume en siguiente tabla:
ILUSTRACION 33: ROI de proyectos de DWH [BI21] El DWH es una estrategia de largo plazo. Al elaborar un DWH, se debe evaluar el costo y el valor considerando un período de tiempo razonable para obtener beneficios. El retorno sobre la inversión de un DWH, se comienza a percibir bastante más tarde del tiempo en el cual se realizó la inversión inicial. Hacer un análisis del costo/valor desde una perspectiva a corto plazo, después de un tiempo de haber concluido el DWH, los costos serán significativamente más altos en proporción al valor inicial, de esta manera se evalúa el valor agregado en los procesos involucrados en el DWH de la organización
Entregables −
Trabajo en Power Point, presentación de la Fase de Evaluación del DWH.
−
Documento General de la Evaluación del DWH.
Roles y Responsabilidades del Equipo en la Fase de Evaluación El Rol Cluster de Administración del Producto, Administración del Programa, Desarrollo, Experiencia del Usuario, Pruebas, Administración de Versiones, en su conjunto se encargan de evaluar el Impacto, Valor y Balance Costo/Beneficio del DWH en la organización.
9.1 CONSIDERACIONES IMPORTANTES Esta metodología se realizó creando el Plan Multi-Versiones basando en la guía metodológica Microsoft Solution Framework, quedando así: Primera Versión:
Realización del centro funcional de la metodología; es decir, la elaboración propiamente dicha de la propuesta metodológica integrada con el Modelo de Procesos y el Modelo de Equipo de MSF, además de recomendaciones y guías que MSF presenta. Segunda Versión:
En esta versión, se centra en el tema de la Calidad de la Data y la integración de esta en la propuesta metodológica ya realizada. Versiones Posteriores:
En las versiones posteriores y ajenas al alcance de este trabajo de tesis, se dejan aspectos de Administración de Riesgos (mayor detalle), Administración de Proyectos, Administración de la Preparación y otros aspectos que se presenta en MSF, no siendo estos menos importantes que los primeros. Un aspecto fundamental a considerar es que en la elaboración de la propuesta metodológica se elaboró mediante este Plan Multi-Versiones, pero al momento de desarrollar un DWH se recomienda constantemente realizarlo también por Versiones para la mejora constante del DWH, las funciones de cada versión se debe asignar por el equipo de desarrollo. La elección de algún Algoritmo de Optimización del DWH, se basa fundamentalmente en la manera de adaptarse a las necesidades o a la realidad del DWH, quedando su uso a disposición del equipo del DWH como ya se mencionó. Para la realización de esta propuesta se tuvo varios motores de interés para desarrollar un proyecto de esta magnitud, entre ellos es la ausencia de una metodología abierta que cubra el aspecto inicial de la Inteligencia de Negocios que es el Desarrollo del DWH, ahora bien dentro de las pocas metodologías para este fin, se observó claramente la poca consistencia en su forma de trabajo y dentro de la bibliografía consultada se obtuvo como referencia inicial de la revista “ Best of Business Intelligence: A Year in Review, 2005-2006 ”,Volumen 3 de The Data Warehousing Institute (TDWI), cuyo artículo “ Diez errores para evitar en la Administración de los Almacenes de Datos ”, de Larissa Moss,
Senior Consultant de Cutter's Business Intelligence Practice, nos señala como errores lo siguiente: 1º Falta y falla para usar una metodología
Las metodologías tradicionales para desarrollar software, nos presentan productos finales, no incluyen tareas de integración a través de la organización, no tienen integración con otros productos. Una metodología para un DWH debe tomar en cuenta que su ambiente DWH no pude ser construido todo de una sola vez; es decir, no entregar productos finales, este tiene que ser expandido y mejorado. Si un DWH se considera exitoso entonces cada versión debe de generar nuevos requerimientos. Estos nuevos requerimientos pueden solicitar que nuevas tecnologías se evalúen y se adquieran. Una metodología de un DWH proporciona apropiadas tareas para todas estas actividades, administra múltiples sub-proyectos en paralelo, la metadata es un importante entregable, merece una especial mención cuando se discute metodologías. Se resalta que no todas las tareas tienen que ser ejecutadas en cada proyecto, pero se debe de conocer todas las tareas, que el equipo deberá considerar en cada versión; el rol de la metodología es proporcionar una lista de todas las posibles tareas, sus dependencias, roles y responsabilidades asignadas para ejecutarlos y los entregables resultantes de cada uno de ellos. No usar una metodología nos garantiza que las tareas vitales se omitan, requiriendo retrabajo de los mismos que pueden ser evitados con el uso de una metodología para DWH. 2º Ineficiente estructura del equipo del proyecto
El equipo del DWH debe ser mucho más flexible y dinámico que el equipo tradicional. Los miembros del equipo deben estar disponibles al 100% desde el inicio hasta el fin del proyecto de DWH. A cada persona en el núcleo del equipo puede tener múltiple responsabilidades de acuerdo a la organización del equipo en el proyecto. 3º Falta y falla del involucramiento de la gente del negocio
Es importante que la gente del negocio participe en el proyecto, la razón más importante es para acelerar y mejorar el trabajo del DWH. La gente del negocio es una parte indispensable e invaluable del equipo de un DWH eficaz porque ellos tienen cierto conocimiento y autoridad con su tecnología que la contraparte no la tiene. En resumen, la gente del negocio entiende la intensidad y el impacto monetario de los problemas de los negocios de la organización y están en posición y autoridad de negociar las prioridades del proyecto del DWH. 4º Falta y falla para tener versiones de las aplicaciones
La mejor manera para ilustrar las eficientes versiones de las aplicaciones es el reconocido concepto de Prototipo, se enfoca como pequeño (parcial e incompleto) alcance que no es completo. Cada siguiente prototipo incluye porciones pequeñas de todo el alcance siendo más complejo y funcional el DWH. Repitiendo este proceso hasta que la aplicación sea totalmente funcional. En el desarrollo del DWH se debe tener en cuenta este aspecto debido al constante y futuro cambio en el DWH.
5º Falta y falla para tener un estatuto activo proyecto
Este documento es frecuentemente conocido como un documento de entendimiento, acuerdos del proyecto, acuerdos de alcance o estatutos del proyecto. Una vez que el proyecto termina este documento desaparece y nunca no se vuelve a ver. Este documento es muy útil y debe ser usado activamente para monitoreo y actividades del control del proyecto durante el ciclo de vida del DWH, debe de contener secciones como: Alcance del proyecto, riesgos, limitaciones, suposiciones, etc. 6º Falta de una planificación para la preparación
Los administradores de proyectos atienden conferencias de DWH y aprenden mejores prácticas para el ciclo de vida del DWH, pero cuando retornan a su realidad a querer aplicar ello se encuentran con la resistencia de los usuarios de la organización. Este error en los administradores de los proyectos hacen no darse cuenta que la organización no se encuentra preparada para un proyecto de esta tipo; por lo tanto, las organizaciones inicialmente deben ser evaluadas y finalmente se debe de determinar si está preparadas para un proyecto de DWH o no. Temas como: Metas, objetivos, calidad, software de soporte, entendimiento de los usuarios que el DWH no es sólo un sistema, tratar y analizar que los usuarios tengan expectativas realistas y además que comprendan la importancia de su participación en las actividades del proyecto; son solo algunos de los temas que se deben tener en cuanta en la organización antes de emprender un proyecto de DWH. 7º Inadecuadas pruebas
Las pruebas en un DWH generalmente se realizan pobremente y muchas veces el equipo lo considera como versiones posteriores, si estas pruebas toman tiempo en el momento de realizar el DWH, posteriormente tomará aun más tiempo. Las pruebas en el DWH deben ser porque en las siguientes versiones serán largos y más complicados. El proyecto del DWH debe tener una Unidad de Pruebas que constantemente se encarguen de esta función, además cada miembro del equipo deben probar sus módulos individualmente. La aceptación de las pruebas es hecha por los usuarios de los negocios, ellos validan la funcionabilidad del DWH. 8º Subestimar los esfuerzos en la limpieza de datos
Muchas organizaciones consideran innecesarias, costosas y tiempo perdido a la limpieza de datos, esto genera dos situaciones claramente: Los defectos en los datos se propagan inadvertidamente en el DWH y la data sucia se descubre tarde (pruebas ETL o mientras se carga el DWH). Un DWH tendrá confiabilidad en el procesos de toma de decisiones, si y sólo si su data es real, consistente y limpia de errores. 9º Ignorar la metadata
La metadata es parte del DWH, tomando un nuevo nivel de importancia porque nos permite ayudar a la gente del negocio a localizar, administrar, entender y usar la data en el DWH. Además nos indica que datos están disponibles en que BD, que eso significa, de donde viene, como fue procesado, cuan limpio esta, como se usa en reportes y consultas; es decir, toda la información acerca de los datos y procesos del DWH, desde
su procedencia, usos, modelos, diseños, etc. Esta información nos permite tener un conocimiento superior del DWH y además dejar una guía del DWH para futuros mantenimientos y/o adiciones en el mismo. 10º Ser un esclavo de las herramientas de Administración de Proyectos
El análisis, planificación y control de los proyectos no es una tarea trivial y toma un tiempo adicional, y se debe ajustar al plan de proyecto, no significando tomar una herramienta y automatizar estas labores, las herramientas nos sirven de apoyo pero no de solución a los mencionados aspectos entre los más resaltantes. Para Larissa Moss estos son los 10 errores que se comenten en el desarrollo de un DWH y se deben de evitar; de acuerdo a la bibliografía consultada estos errores son los que comúnmente ocurren, entonces en esta propuesta de tesis se cohesiono lo que se debe de evitar de tal manera que nuestra propuesta tenga un porcentaje menor de fracaso. 10 errores que evitar en un Proceso de DWH
Se evitó en la propuesta
1º Falta y falla para usar una metodología
SI
Se realizó una metodología para desarrollar un DWH, con aquellos aspectos propios del DWH
2º Ineficiente estructura del equipo del proyecto
SI
Se estructuró al equipo de acuerdo a MSF, siendo estos activamente en todo el proceso del DWH y con roles puntuales en cada fase de elaboración del DWH.
3º Falta y falla del involucramiento de la gente del negocio
SI
En la mayor parte de las fases se considera vital el involucramiento de la gente del negocio.
4º Falta y falla para tener versiones de las aplicaciones
SI
Al ser una propuesta iterativa e incremental.
5º Falta y falla para tener un estatuto activo proyecto
SI
Este documento se crea por el equipo en un inicio, para organizar el trabajo y limitarlo.
6º Falta de una planificación para la preparación
SI
Existen etapas y tareas que nos permiten determinar si la organización está lista para iniciar el proceso del DWH y si no se encuentra se realizan las medidas pertinentes para que lo
En que parte se tomo en cuenta
este. 7º Inadecuadas pruebas
SI
La propuesta del DWH tiene una unidad de pruebas, además de las pruebas individuales de los módulos.
8º Subestimar los esfuerzos en la limpieza de datos
SI
Se cuenta con políticas sobre el tema de la Calidad de los Datos en un DWH.
9º Ignorar la metadata
SI
La metadata es un aspecto que se incrementa a medida que se llega al final del proceso del DWH.
10º Ser un esclavo de las herramientas de Administración de Proyectos
SI
Las herramientas se consideran como apoyo a la búsqueda de la solución, no como una guía estricta al cual ceñirnos.
TABLA 7: Evaluación del DWH según Larissa Moss [FP] Una vez que se ha considerado y a su vez evitado estos errores, surge la pregunta ¿Por qué es que las metodologías fracasan?, Larissa Moss presenta los diez errores para evitar en el proceso del DWH, pero estos no son todos los aspectos para lograr un éxito en un proyecto de DWH; con la propuesta de nuestra metodología se pretende automatizar algunas etapas, tareas; pero el equipo está conformado por personas y a muchas de ellas le es pesado seguir las pautas y documentar lo asignado en la propuesta para desarrollar un DWH. Por otro lado es complicado que el equipo realice actividades del proceso del DWH automáticamente como si fueran máquinas. Al inicio del proceso del DWH se evalúa si la organización se encuentra preparada para este tipo de proyecto y si no lo está se toman las acciones pertinentes, pero no se evalúa al equipo de desarrollo, este es un factor critico porque a pesar de que la organización este lista para desarrollar un DWH, si el equipo no lo está, se obtendría un posible fracaso, entonces ¿quien o quienes son los encargados de evaluar al equipo del DWH? y ¿cuales son los requisitos básicos que este equipo necesita para iniciar?. Más que evaluación del equipo del DWH es reconocer las habilidades de cada uno como parte del equipo, de la forma como este se organice y reconozcan sus habilidades y experiencias en las fases, etapas y tareas del DWH es un punto de inicio. Los requisitos básicos que debe de cumplir una persona como parte del equipo no se enfoca en sus conocimientos y destrezas porque estas se solucionan aprendiendo , es algo más importante y es que las personas sean disciplinadas, sólo las Personas Disciplinadas son capaces de adherirse a seguir los procesos definidos (propuesta metodológica) y presentan las siguientes características fundamentales: Son consecuentes (siempre cumplen sus obligaciones a menos que tengan una razón esencial para no hacerlo),
