REQUERIMIENTOS DEL NEGOCIO, Requerimientos del sistema de la bodega de datos. PDF

Preview

Summary

Diseño e Implementación del subsistema de Extracción, Transformación y Carga (ETL) Y TALEND STUDIO....

Description

UNIVERSIDAD ANTONIO NARIÑO FACULTAD DE INGENIERIA Y TECNOLOGIA PROGRAMA DE INGENIERIA DE SISTEMAS

BASE DE DATOS II (GRUPO # 02) PROYECTO FINAL BASE DE DATOS

FABIAN LEONARDO ARZUAGA ARZUAGA LEONARDO DAVID ORTIZ MADRID

CUCUTA 2019

Tabla de contenido 1. INTRODUCCION..............................................................................................................................3 2. FORMULACION DEL PROBLEMA.....................................................................................................4 3. JUSTIFICACION...............................................................................................................................4 4. OBJETIVOS.....................................................................................................................................4 4.1 OBJETIVOS ESPECIFICOS...........................................................................................................4 5. MARCO TEORICO............................................................................................................................5 5.1 DATAWAREHOUSE....................................................................................................................5 5.2 ARQUITECTURA DE UNA BODEGA DE DATOS...........................................................................6 5.3 FUNCIONES Y OBJETIVOS DE LA BODEGA DE DATOS...............................................................6 6. METODOLOGÍA KIMBALL................................................................................................................8 6.1 Planificación del Proyecto.........................................................................................................9 6.2 Definición de Requerimientos del Negocio..............................................................................9 6.3 Modelado Dimensional..........................................................................................................10 6.4 Diseño Físico...........................................................................................................................10 6.5 Diseño e Implementación del subsistema de Extracción, Transformación y Carga (ETL)........11 6.6 Implementación.....................................................................................................................11 6.7 Mantenimiento y Crecimiento del Data Warehouse..............................................................11 6.8 Especificación de aplicaciones de BI.......................................................................................11 6.9 Diseño de la Arquitectura Técnica..........................................................................................12 7. MODELADO DIMENSIONAL..........................................................................................................12 8. MODELO CONCEPTUAL................................................................................................................13 9. PLANIFICACIÓN DEL PROYECTO....................................................................................................13 10. DEFINICIÓN DE REQUERIMIENTOS DEL NEGOCIO......................................................................14 11. Requerimientos del sistema de la bodega de datos...................................................................14

1. INTRODUCCION En la actualidad el análisis de la información para la toma de decisiones es muy necesario en cualquier empresa, dado que así las acciones tomadas por la empresa para el mejoramiento y crecimiento del negocio van a ser coherentes con las tendencias en los movimientos de la empresa, lo cual llevara a un gran impacto que se verá reflejado en las ganancias de la empresa. Este documento describe paso a paso el diseño e implementación de una solución de inteligencia de negocios basado en una bodega de datos en la cual se analizara la información a partir de las necesidades del negocio, partiendo de las fuentes de datos entregada.

2. FORMULACION DEL PROBLEMA ¿Cómo ayudar de forma clara a desarrollar una Datawarehouse para el área de ventas de una empresa en general?

3. JUSTIFICACION La importancia de contar con una guía general de implementación de una bodega de datos, radica en los tiempos de implementación del modelo y en los estándares de documentación que se generan como proceso para la construcción de los cubos multidimensionales que aporten valor agregado a la empresa.

4. OBJETIVOS Diseñar una guía general para la implementación de un Bodega de datos para el área de ventas de una empresa.

4.1 OBJETIVOS ESPECIFICOS   

Llevar a cabo el levantamiento y análisis de las diferentes fuentes de datos de un área de ventas. Integrar los componentes elementales involucrados en la solución. Identificar las herramientas para generar los cubos multidimensionales.

5. MARCO TEORICO 5.1 DATAWAREHOUSE Un Datawarehouse es una base de datos corporativa que se caracteriza por integrar y depurar información de una o más fuentes distintas, para luego procesarla permitiendo su análisis desde infinidad de pespectivas y con grandes velocidades de respuesta. La creación de un datawarehouse representa en la mayoría de las ocasiones el primer paso, desde el punto de vista técnico, para implantar una solución completa y fiable de Business Intelligence. La ventaja principal de este tipo de bases de datos radica en las estructuras en las que se almacena la información (modelos de tablas en estrella, en copo de nieve, cubos relacionales... etc.). Este tipo de persistencia de la información es homogénea y fiable, y permite la consulta y el tratamiento jerarquizado de la misma (siempre en un entorno diferente a los sistemas operacionales). El término Datawarehouse fue acuñado por primera vez por Bill Inmon, y se traduce literalmente como almacén de datos. No obstante, y como cabe suponer, es mucho más que eso. Según definió el propio Bill Inmon, un datawarehouse se caracteriza por ser: 







Integrado: los datos almacenados en el datawarehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas. La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios. Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla del datawarehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar. Histórico: el tiempo es parte implícita de la información contenida en un datawarehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, la información almacenada en el datawarehouse sirve, entre otras cosas, para realizar análisis de tendencias. Por lo tanto, el datawarehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones. No volátil: el almacén de información de un datawarehouse existe para ser leído, pero no modificado. La información es por tanto permanente, significando la actualización del datawarehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.

Otra característica del datawarehouse es que contiene metadatos, es decir, datos sobre los datos. Los metadatos permiten saber la procedencia de la información, su periodicidad de refresco, su fiabilidad, forma de cálculo... etc.

5.2 ARQUITECTURA DE UNA BODEGA DE DATOS El sistema es bodega de datos consta de 3 niveles, el primero conformado por las bases de datos fuente; el segundo una base de datos resumidos extraídos de las bases de producción (Data Warehouse) y el ultimo construido por las interfaces orientadas a usuarios que extraen información para la toma de decisiones (Reinosa, 2012, p.196). Figura 1. Arquitectura de una bodega de datos

Base de datos fuentes Estos datos tratan de información contenida en bases de datos de producción que pueden residir en sistemas relacionales, pero también información contenida en bases de archivos o textos. Estos tipos de datos son atómicos, y que no permiten un análisis grande puesto que están hechos para mantener consistencia de los registros contenidos. Base de datos con datos resumidos – Back Room Los datos contenidos en estas bases, son más destacados para los análisis pues influyen en la toma de decisiones, este es el Datawarehouse, contiene por lo general agrupaciones y totalizaciones de datos previamente calculados y relevantes que vienen de la información de fuentes. Interfaces orientadas a usuarios – Front Room Se trata de toda la extracción y presentación en forma de análisis, consultas o reportes, las interfaces usadas son generalmente especializadas en el manejo de datos dimensionales o modelos en forma de estrella.

5.3 FUNCIONES Y OBJETIVOS DE LA BODEGA DE DATOS En una bodega de datos, se tiene como principal objetivo la conversión de los datos de las aplicaciones que vienen de las fuentes, ya sean del ambiente transaccional o de datos provenientes de estructuras distintas. Posteriormente deben ser trabajados y almacenados en sistemas OLAP para facilitar el acceso a los usuarios y puedan tener la posibilidad de realizar

análisis de los datos. Además de recibir carga de datos de forma periódica. En una bodega de datos se pueden evidenciar cuatro grupos de funciones que se deben cumplir en para la construcción y procesamiento, estas funciones son: 







Acceso a Fuentes: dentro de este grupo se incluye todos los procesos responsables o que se van a aplicar en las bases transaccionales y planos donde se hará el trabajo de transferencia, Vale resaltar, que incluye el mapeo de los datos que pueden ser replicados para otros esquemas o para bases de datos físicas localizadas fuera de la organización. Es el grupo en el que se destina un porcentaje bastante alto pues se debe hacer un trabajo exhaustivo de mapeo , integración y muestreo de todos los datos, así como la verificación de las aplicaciones que trabajan con dicha información. Carga: dentro de este grupo se organizan y asocian todos los procesos de migración de los datos, pero no solo de eso, la extracción , depuración , conversión y carga de estos datos; de acá se desprenden pasos que se deben tener en cuenta al momento de la carga, comenzando por la extracción de los datos o acceso a los datos, para ello se entablan diferentes herramientas o formas de acceder, por un lado pueden ser consultados mediante querys , vistas, aunque cuales quiera de las dos primeras formas es válida, existe una recomendación en el uso de la extracción puesto que es importante tener en cuenta que durante un query podemos obtener datos que queden desactualizados por estar en transacción de actualización, por lo cual es recomendable el uso de vistas para el acceso a esta información , aunque sacrifique el almacenamiento. Durante este proceso es necesario la verificación de la integridad y calidad de la extracción, es necesario identificar inconsistencias para no perder información al paso del datawarehouse. Como segundo proceso importante dentro de la carga se encuentra la conversión que es el último paso para la preparación de los datos que se van a cargar a la bodega, básicamente se trata de los cálculos necesarios para transferir a la bodega o manipulación del dato original. Almacenamiento: este grupo abarca la arquitectura necesaria para ingresas los datos al datawarehouse, si bien es cierto que la bodega es un solo almacenamiento, se tiene que tener estructurado la forma en la que se obtendrá dicha información. Consultas: el acceso final de los datos procesados, convertidos en gráficos, estadísticas, tendencias, permiten al usuario analizar y producir reportes que luego serán utilizados para toma de decisiones.

6. METODOLOGÍA KIMBALL La Metodología Kimball, es una metodología empleada para la construcción de un almacén de datos (data warehouse, DW) que no es más que, una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza. La metodología se basa en lo que Kimball denomina Ciclo de Vida Dimensional del Negocio (Business Dimensional Lifecycle). Este ciclo de vida del proyecto de DW, está basado en cuatro principios básicos:   



Centrarse en el negocio Construir una infraestructura de información adecuada Realizar entregas en incrementos significativos (este principio consiste en crear el almacén de datos (DW) en incrementos entregables en plazos de 6 a 12 meses, en este punto, la metodología se parece a las metodologías ágiles de construcción de software) Ofrecer la solución completa (En este se punto proporcionan todos los elementos necesarios para entregar valor a los usuarios de negocios, para esto ya se debe tener un almacén de datos bien diseñado, se deberán entregar herramientas de consulta ad hoc, aplicaciones para informes y análisis avanzado, capacitación, soporte, sitio web y documentación).

La construcción de una solución de DW/BI (Datawarehouse/Business Intelligence) es sumamente compleja, y Kimball nos propone una metodología que nos ayuda a simplificar esa complejidad. Las tareas de esta metodología (ciclo de vida) se describen a continuación: Figura 2. Metodología Kimball (ciclo de vida)

6.1 Planificación del Proyecto En este proceso se determina el propósito del proyecto de DW/BI, sus objetivos específicos y el alcance del mismo, los principales riesgos y una aproximación inicial a las necesidades de información. Esta tarea incluye las siguientes acciones típicas de un plan de proyecto:      

Definir el alcance (entender los requerimientos del negocio). Identificar las tareas Programar las tareas Planificar el uso de los recursos. Asignar la carga de trabajo a los recursos Elaboración de un documento final que representa un plan del proyecto.

Además en esta parte definimos cómo realizar la administración o gestión de esta subfase que es todo un proyecto en sí mismo, con las siguientes actividades:   

Monitoreo del estado de los procesos y actividades. Rastreo de problemas Desarrollo de un plan de comunicación comprensiva que direccione la empresa y las áreas de TI

6.2 Definición de Requerimientos del Negocio La definición de requerimientos, es un proceso de entrevistar al personal de negocio y técnico, aunque siempre conviene, tener un poco de preparación previa. En esta tarea, se debe aprender sobre el negocio, los competidores, la industria y los clientes del mismo. Se debe dar una revision a todos los informes posibles de la organización; rastrear los documentos de estrategia interna; entrevistar a los empleados, analizar lo que se dice en la prensa acerca de la organización, la competencia y la industria y se deben conocer los términos y la terminología del negocio. Se sugiere entrevistar al personal que se encuentra en los cuatro grupos que se mencionan a continuación:    

El directivo responsable de tomar las decisiones estratégicas. Los administradores intermedios y de negocio responsables de explorar alternativas estratégicas y aplicar decisiones El personal de sistemas, si existe (estas son las personas que realmente saben qué tipos de problemas informáticos y de datos existen en la organización) El personal que se entrevista por razones políticas.

Entre las tareas antes descritas, existe una flecha bidireccional, esto indica que los requerimientos del negocio son el soporte inicial de las tareas subsiguientes, también tiene influencia en el plan de proyecto.

Si avanzamos por el camino central del diagraman, encontramos las tareas asociadas al área de Datos, en esta, diseñaremos e implementaremos el modelo dimensional, y desarrollaremos el

subsistema de Extracción, Transformación y Carga (Extract, Transformation, and Load - ETL) para cargar el DW. Las tareas pertenecientes al área, se describen a continuación:

6.3 Modelado Dimensional Es un proceso dinámico y altamente iterativo. Comienza con un modelo dimensional de alto nivel obtenido a partir de los procesos priorizados y descritos en la tarea anterior, y El proceso iterativo consiste en cuatro pasos: A. Elegir el proceso de negocio: que consiste en, elegir el área a modelizar. Esta es una decisión de la dirección, y depende fundamentalmente del análisis de requerimientos y de los temas analíticos anotados en la etapa anterior. B. Establecer el nivel de granularidad: La granularidad significa especificar el nivel de detalle. La elección de la granularidad depende de los requerimientos del negocio y lo que es posible a partir de los datos actuales. La sugerencia general es comenzar a diseñar el DW al mayor nivel de detalle posible, ya que se podrían realizar agrupamientos posteriores, al nivel deseado. C. Elegir las dimensiones: Las dimensiones surgen naturalmente de las discusiones del equipo, y facilitadas por la elección del nivel de granularidad y de la matriz de procesos/dimensiones (que se realiza en la tarea 4.2) Las tablas de dimensiones tienen un conjunto de atributos (generalmente textuales) que brindan una perspectiva o forma de análisis sobre una medida en una tabla hechos. Una forma de identificar las tablas de dimensiones es que sus atributos son posibles candidatos para ser encabezado en los informes, tablas pivot, cubos, o cualquier forma de visualización, unidimensional o multidimensional. D. Identificar medidas y las tablas de hechos: Este paso, consiste en identificar las medidas que surgen de los procesos de negocios. Una medida es un atributo (campo) de una tabla que se desea analizar, sumando o agrupando sus datos y usando los criterios de corte conocidos como dimensiones. Las medidas habitualmente se vinculan con el nivel de granularidad del punto 2, y se encuentran en tablas que denominamos tablas de hechos (fact en inglés). Cada tabla de hechos tiene como atributos una o más medidas de un proceso organizacional, de acuerdo a los requerimientos. Un registro contiene una medida expresada en números, como ser cantidad, tiempo, dinero, etc., sobre la cual se desea realizar una operación de agregación (promedio, conteo, suma, etc.) en función de una o más dimensiones. La granularidad, en este punto, es el nivel de detalle que posee cada registro de una tabla de hechos.

6.4 Diseño Físico En esta tarea, se contestan las siguientes preguntas: ¿Cómo puede determinar cuán grande será el sistema de DW/BI? ¿Cuáles son los factores de uso que llevarán a una configuración más grande y más compleja? ¿Cómo se debe configurar el sistema?

¿Cuánta memoria y servidores se necesitan? ¿Qué tipo de almacenamiento y procesadores? ¿Cómo instalar el software en los servidores de desarrollo, prueba y producción? ¿Qué necesitan instalar los diferentes miembros del equipo de DW/BI en sus estaciones de trabajo? ¿Cómo convertir el modelo de datos lógico en un modelo de datos físicos en la base de datos relacional? ¿Cómo conseguir un plan de indexación inicial? ¿Debe usarse la partición en las tablas relacionales?

6.5 Diseño e Implementación del subsistema de Extracción, Transformación y Carga (ETL) El subsistema de Extracción, Transformación y Carga (ETL) es la base sobre la cual se alimenta el Data warehouse. Si se diseña adecuadamente, puede extraer los datos de los sistemas de origen de datos, aplicar diferentes reglas para aumentar la calidad y consistencia de los mismos, consolidar la información proveniente de distintos sistemas, y finalme...