Universidad de las Americas

Transcripción

1 Universidad de las Americas Facultad de Ingeniería de Sistemas Data Warehouse Corporativo Aplicado a Procesos de Análisis Comercial Trabajo de titulación presentado en conformidad a los requisitos Para obtener el título de Ingeniero en Sistemas Profesor Guía: Ing. Maritzol Tenemaza MSc. Juan Alcívar Llacsahuanga Gómez 2004

2 AGRADECIMIENTOS Este trabajo de titulación es el resultado de una ardua labor, dedicación y disciplina de muchas personas que han hecho posible hacer realidad un sueño en un inicio y que posteriormente se fue convirtiendo en una aspiración, hasta convertirse en una realidad. Aprovecho este espacio para agradecer la lucha incansable de mis padres: al señor Feliciano Llacsahuanga y la señora Olga I. Gómez, quienes con su ejemplo y calor forjaron hijos de bien. En este momento, llega a mi mente profesoras y profesores que desde mi infancia contribuyeron en cada paso de mi carrera educativa, pese a grandes sacrificios, con mucha vocación dedican gran parte de su vida para engrandecer este querido país, difundiendo sus sabios conocimientos. Maritzol es una digna representante, quien con gran disciplina educa y transmite fuente ejemplar de superación. Gracias Maritzol.

3 DEDICATORIA A mi amada esposa Taty y mi grandioso hijo Fabry

4 RESUMEN Con este mundo globalizado, donde todos los modos de vivencia y supervivencia están siendo invadidas entre si y con ello intercambios de información difundida desde muchos rincones de la tierra y desde hace una variedad de tiempos. Con ello el ser humano, cada día, debe manipular grandes volúmenes de información y con muchos enfoques, para tomar decisiones. Con esta variada información sumada la competitividad existente en las empresas, se torna indispensable utilizar herramientas que permitan manejar dichos volúmenes de datos. En el presente trabajo se expone una herramienta corporativa que facilitará la concentración de información de toda una vida empresarial, proporcionando herramientas amigables para visualizar y analizar esta información. Si bien a principios de los noventa se iniciaron los primeros proyectos palpables de Data Warehouse, con el pasar de los años ha evolucionado de forma muy dinámica. En la actualidad es una herramienta tecnológica que abarca grandes problemáticas de todas las áreas empresariales, convirtiéndose en una herramienta extremadamente poderosa e indispensable como soporte en la toma de decisiones.

5 INDICE 1 CAPITULO I: ASPECTOS GENERALES ÁMBITO PROBLEMA OBJETIVO GENERAL OBJETIVOS ESPECÍFICOS JUSTIFICACIÓN PRÁCTICA DEL PRESENTE PROYECTO ALCANCE DEL PROYECTO ASPECTOS METODOLÓGICOS CAPÍTULO: FUNDAMENTO TEÓRICO SISTEMAS OLAP Definición Cubos... 9 FIGURA 2-1 EJEMPLIFICACIÓN DE UN CUBO Funcionalidad Reglas OLAP Tipos de implementación OLAP MOLAP OLAP Multidimensionales ROLAP OLAP Relacionales HOLAP OLAP Híbridos DIFERENCIAS ENTRE SISTEMAS OLTP Y SISTEMAS OLAP DEFINICIÓN DE DATA WAREHOUSE Orientado a temas específicos Ubicación en el tiempo Historial de datos Recuperación de información y soporte a la toma de decisiones Datos atómicos y datos sumariados ÁREAS DE APLICABILIDAD DE UN DATA WAREHOUSE... 17

6 2.5 OBJETIVOS DEL DATA WAREHOUSE Hacer que la información de la organización sea fácilmente accesible Presentar la información consistentemente Ser adaptable y flexible a cambios Debe ser un baluarte seguro que proteja la información Servir como fundamento para decisiones imprevistas COMPONENTES DE UN DATA WAREHOUSE FIGURA 2-3 ELEMENTOS BÁSICOS DE UN DATA WAREHOUSE Sistemas fuente Área de recopilación de datos Área de presentación de datos Área de herramientas de acceso ARQUITECTURA Flujo de procesos en un Data Warehouse FIGURA 2-4FLUJO DE PROCESOS TÍPICO EN UN DATA WAREHOUSE Interfase de extracción y carga Control del proceso Cuando iniciar la extracción Carga de datos Herramientas para manejo de copias y depuración de datos Procesos de depuración y transformación Procesos de administración de consultas ESTRATEGIA PARA LA IMPLEMENTACIÓN DEL DATA WAREHOUSE Método de desarrollo incremental FIGURA 2-5MODELO INCREMENTAL Metodología para implementar un Data Warehouse Selección del ámbito de la implementación Definición del enfoque arquitectónico... 33

7 Solo Data Warehouse Solo Mercado de datos Data Mart Data Warehouse y Mercado de datos Separación de plataforma e infraestructura Arquitectura Cliente/Servidor de dos capas Arquitectura Cliente/Servidor de tres capas Determinación del Alcance Justificación del proyecto Equipo de trabajo Patrocinador del negocio Gerente del proyecto Líder de negocio Analista de negocio Desarrollador de aplicaciones analíticas Líder técnico del proyecto Arquitecto técnico Modelador de datos Administrador de la base datos Coordinador de la metadata Diseñador del área de recopilación de datos Desarrollador del área de recopilación de datos Soporte de Data Warehouse Establecimiento del presupuesto y plan de trabajo CAPITULO III: CONSTRUCCIÓN DEL DATA WAREHOUSE INGENIERÍA DE SOFTWARE Definición del enfoque arquitectónico Determinación del alcance del proyecto Descripción Definición del alcance Exclusiones Criterios de éxito... 45

8 Riesgos del proyecto y riesgo de reducción del plan original Justificación del proyecto Equipo de trabajo Establecimiento del presupuesto y plan de trabajo ANÁLISIS DE REQUERIMIENTOS Descripción del desarrollo FIGURA 3-4 ESQUEMA DE DESARROLLO DE DATA WAREHOUSE Casos de usos Diccionario de casos de uso Extracción datos fuentes Descripción Flujo de eventos Precondiciones Postcondiciones Transformar datos hacia Data Mart Descripción Flujo de eventos Precondiciones Postcondiciones Generación de consultas y reportes Descripción Flujo de eventos Precondiciones Impresión de Consultas y reportes Descripción Flujo de eventos Precondiciones ANÁLISIS Y DISEÑO Modelo Estático Sistema Fuente Modelo de datos... 57

9 Diccionario de datos Área de recolección e integración de sistemas fuente Modelo de datos Diccionario de datos Data Mart Modelo de datos Diccionario de datos Modelo Dinámico Extracción y carga datos fuente al área de recolección e integración Ciudades Clientes Direcciones Empleados Ordenes de compra Detalle de ordenes de compra Países Productos Transformación y carga a Estructuras Data Mart Tabla de hechos Dimensión de clientes Dimensión de productos Dimensión de empleados CONSTRUCCIÓN Oracle Oracle Warehouse Builder Despliegue de mappings a la base Oracle Discoverer Diagrama de componentes PRUEBAS FUNCIONALES Datos predefinidos en el área de recolección Tabla de catálogo... 80

10 Datos fuente Ciudades Clientes Direcciones Empleados Ordenes Países Productos Ingreso Oracle Sql-plus Ejecución de Scripts de carga desde fuente Ejecución de scripts de carga a Data Mart Despliegue de resultados CAPITULO IV: CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES BIBLIOGRAFÍA ANEXOS DICCIONARIO DE DATOS SISTEMA FUENTE DICCIONARIO DE DATOS DEL ÁREA DE RECOLECCIÓN DICCIONARIO DE DATOS DEL DATA MART MANUAL DE USUARIO Extracción, Carga y transformación Reportes y consultas GLOSARIO

11 Tabla de figuras Figura 2-1 Ejemplificación de un cubo Figura 2-2Sistemas OLAP vs. OLTP Figura 2-3 Elementos básicos de un Data Warehouse Figura 2-4Flujo de procesos típico en un data Warehouse Figura 2-5Modelo incremental Figura 2-6 Organigrama Figura 3-1 Equipo de trabajo Figura 3-2 Plan de trabajo Figura 3-3 Presupuesto Figura 3-4 Esquema de desarrollo de Data Warehouse Figura 3-5 Diagrama de componentes... 79

12 1 1 Capitulo I: Aspectos Generales 1.1 Ámbito Las empresas enfocadas al mundo competitivo, requieren de un manejo adecuado de la información actual e información histórica, con el fin de dirigir sus esfuerzos a objetivos claros. Las información actual de la empresa podría se manipulada con un sistema transaccional u operacional; pero aquella información histórica se torna complejo manipular por los grandes volúmenes de información disponible, acumulada a través del tiempo. Si a esto consideramos la degradación del sistema transaccional, el cual debe tener un tiempo de respuesta mínimo en línea. En corporaciones donde abarca a más de una compañía, es importante mantener el control de dicha información generada por cada una de las compañías. Esta integración puede ser obtenida con la implementación de un Data Warehouse. Los trabajos de análisis de información y proyecciones, requieren de información unificada. En algunos tipos de reportes se requiere de información resumida; pero con la posibilidad de llegar al más mínimo detalle.

13 2 1.2 Problema Las necesidades que promueven el desarrollo e implementación de un Data Warehouse se enumeran a continuación: Integración de información, dispersa entre varias compañías y/o varios sistemas Análisis financieros Proyecciones de ventas Focalización de clientes Consolidación contable Reportes legales Soporte en las áreas de mercadeo En suma, las necesidades para implementar un Data Warehouse se originan en actividades que involucran procesamiento de grandes volúmenes de información. En la construcción del prototipo de Data Warehouse del presente trabajo de titulación se orienta a solucionar necesidades de: Integración de sistemas Proyecciones de ventas Soporte en las áreas de mercadeo

14 3 Se plantea realizar el proceso de integración de sistemas, definiendo un área unificada que permita extraer información desde más de un sistema fuente. Se definirá un modelo de información consolidado en el tiempo sobre ventas de artículos de vestir, el cual ayudará en las tareas de proyección y soporte en las áreas de mercadeo. 1.3 Objetivo General Analizar, Diseñar y construir un proyecto Data Warehouse aplicado a procesos de análisis comercial. 1.4 Objetivos Específicos Conceptualizar el Data warehouse como sistema en la toma de decisiones Establecer una arquitectura adecuada para integrar sistemas transaccionales enfocados a operaciones comerciales. Definir una metodología para el desarrollo de un proyecto Data Warehouse. Diseñar el prototipo del Data Warehouse para un sistema transaccional comercial. Construir el proyecto, utilizando como motor de base de datos Oracle 9i.

15 4 1.5 Justificación práctica del presente proyecto El presente proyecto servirá como guía para desarrollo de un Data Warehouse orientado a las diferentes áreas de interés, tales como: Educación Salud Comunicaciones Transporte Recursos humanos Clientes Mercadeo Contabilidad Servicios financieros Ventas Comercio electrónico

16 5 Seguros Para ello aporta con bases para el conocimiento de un Data Warehouse y una metodología propuesta para construir un Data Warehouse. El prototipo construido para sustentar el presente trabajo de titulación, se especializa en el área comercial, tomando como base a una empresa comercial que vende artículos de vestir. 1.6 Alcance del proyecto El presente trabajo de titulación propone un enfoque metodológico y teórico, necesario para la construcción de un Data Warehouse, sustentándolo con un desarrollo práctico de un prototipo dirigido a sistemas comerciales sobre ventas de artículos de vestir. Para ello contiene: Aspectos teóricos sobre Data Warehouse Definición y diferencias entre sistemas OLTP (Procesos transaccionales) y OLAP(Procesos analíticos en línea) Componentes de un Data Warehouse Arquitectura de un Data Warehouse Metodología en la construcción de Data Warehouse

17 6 Construcción de un prototipo dirigido a sistemas comerciales sobre ventas. 1.7 Aspectos metodológicos Paradigma Incremental Ingeniería de Software Metodología de Ralph Kimball Definir del enfoque arquitectónico Determinación del alcance Justificación del proyecto Definición del equipo de trabajo Establecimiento del presupuesto y plan de trabajo Justificación del proyecto Métodos Análisis de requerimientos Descripción del desarrollo Casos de usos Diccionario de casos de uso Análisis y diseño Modelo Estático Sistema Fuente o Modelo de datos o Diccionario de Datos área de recolección de datos o Modelo de datos o Diccionario de Datos Data Mart o Modelo de datos o Diccionario de Datos Modelo Dinámico Diagramas de Extracción,

18 7 carga y transformación o Del sistema fuente al área de recolección o Del área de recolección al Data Mart Construcción Oracle Warehouse Builder Diagrama de componentes Oracle Discoverer Pruebas Funcionales Mantenimiento

19 8 2 Capítulo: Fundamento Teórico 2.1 Sistemas OLAP Definición Las siglas OLAP, provienen de las palabras en ingles On Line Analytical Processing; lo cual significa procesamiento analítico en línea 1. Es una tecnología cada vez más popular que permite mejorar de manera muy significativa las tareas de análisis del negocio, constituyéndose en un componente clave en el proceso de almacenamiento de datos (data warehousing) pudiendo personalizarse para tareas que van desde informes corporativos hasta soporte avanzado a la toma de decisiones. El sistema OLAP es un sistema interactivo que permite a los analistas ver diferentes resúmenes de los datos multidimensionales. En línea implica que los analístas deben poder solicitar nuevos resúmenes y obtener respuestas en línea, en pocos segundos, y no deberían estar obligados a esperar mucho tiempo para ver el resultado de sus consultas 2. Se han desarrollado varias extensiones de SQL que permitan soportar las herramientas OLAP, las cuales permiten realizar tareas que con las herramientas 1 Silberschatz, Fundamentos de Bases de datos, 2002, Cuarta Edición, Mc Graw Hill, Pág

20 9 básicas de agregación y agrupamiento no se podría lograr. Estas tareas se agrupan en: Búsqueda de percentiles Distribuciones acumulativas o agregados sobre ventanas deslizantes de datos ordenados secuencialmente Una visión práctica del desarrollo propuesto en el presente proyecto, en lo referente a los procesos OLAP, están orientados en el poblamiento de la tabla de hechos, y dimensiones (Data Mart) y luego desplegados mediante la utilización Oracle Discoverer Cubos 1 La generalización de las tablas dinámicas que son bidimensionales, a n dimensiones puede visualizarse como cubos n dimensionales, los cuales se denominan Cubos de datos. Las tablas dinámicas son tabulaciones cruzadas en las que los valores de uno de los atributos forman las cabeceras de las filas, los valores del otro atributo forman las cabeceras de las columnas y los valores de cada celda representan los valores de análisis. Las tablas dinámicas pueden contener también una fila y columna que represente los valores resumidos. La siguiente figura ejemplifica un cubo considerando los atributos de dimensión nombre-artículo, color y talla y el atributo de medida número. 1 Silberschatz, Fundamentos de Bases de datos, 2002, Cuarta Edición, Mc Graw Hill, Pág 540

21 Oscuro Pastel Color Blanco Pequeña Mediana Todos Todos Grande Talla Faldas Vestido Camisas Pantalon Todos Nombre - articulo Figura 2-1 Ejemplificación de un cubo (Fuente: Fundamentos de Bases de datos, Silberschatz) Con los sistemas OLAP, los analístas de datos pueden ver diferentes tabulaciones cruzadas para los mismos datos seleccionados de manera interactiva los atributos de las tabulaciones cruzadas. Cada tabulación cruzada es una vista bidimensional del cubo de datos multidimensional.

22 Funcionalidad 1 Las siguientes son funcionalidades que debe permitir un sistema OLAP Rotar y drill down (Despliegue de la información en sucesivos niveles de detalle) Crear y examinar datos calculados incrementalmente en grandes volúmenes de datos Determinar diferencias comparativas o relativas Desplegar excepciones y análisis de tendencias Ejecutar funciones avanzadas de análisis por ejemplo: o o o Proyecciones Modelamiento Análisis de regresiones Reglas OLAP 2 Vista conceptual multidimensional.- Permitiendo aplicar múltiples dimensiones en los modelos de Warehouse. Transparencia.- Transparente al usuario, sin fijarse en detalles técnicos Accesibilidad.- Debe permitir acceder a los datos de forma segura y efectiva. Rendimiento consistente de reportes.- Con el fin de determinar tiempos de respuestas aceptables en la ejecución de reportes. Arquitectura cliente-servidor.- Con lo cual se permite compartir la carga de procesamiento; de esta manera se deriva las arquitecturas n capas. Dimensionalidad genérica.- Permitiendo la generación de dimensiones de cualquier tipo dependiendo del modelo de negocio 1 Silberschatz, Fundamentos de Bases de datos, 2002, Cuarta Edición, Mc Graw Hill, Pág Oracle Warehouse builder: Implementation Volume 2 Student Guide, 2002, Edición 2.0

23 12 Manejo dinámico de la matriz esparcida.- Permitir análisis de la información a través de varios enfoques. Multiusuario.- Acceso a varios usuarios simultáneamente. Operaciones no restringibles de la tabulación cruzada.- Con el fin de cruzar datos entre dimensiones. Manipulación intuitiva de datos.- Para facilitar el manejo de la información amigable al usuario. Generador de reportes flexible.- Lo cual permite realizar análisis requeridos por el modelo de negocio. Dimensiones ilimitadas y niveles de agregación.- Permite definir modelos de Warehouse con dimensiones variados e ilimitados y definición de múltiples niveles de sumarización. El límite lo impone las características del hardaware Tipos de implementación OLAP MOLAP OLAP Multidimensionales En un inicio los sistemas OLAP se desarrollaron utilizando estructuras multidimensionales, con la utilización de arreglos. Las siguientes son características de MOLAP. Datos o o o Arreglos Cache Carga desde el servidor 1 Ralph Kimball, The Data Warehouse Lifecycle tolkit, Wiley, 1998

24 13 Eficiente almacenamiento y procesamiento Alta complejidad para el usuario El análisis se realiza utilizando resúmenes preagregados y medidas precalculadas La interfase con la aplicación, almacena datos en las estructuras multidimensionales La interfase de presentación provee vistas multidimensionales ROLAP OLAP Relacionales Los servicios OLAP se integran en los sistemas relacionales y los datos se almacenan en bases de datos relacionales. Las siguientes son características de ROLAP: Warehouse almacena datos atómicos La interfase con la aplicación genera sentencias SQL para las vistas tridimensionales La interfase de presentación provee vistas multidimensionales Los datos y metadatos son manejados y almacenados en el servidor Alta conectividad Tamaño ilimitado de base de datos Criterio ilimitado de consultas Complejas instrucciones SQL generados por herramientas

25 HOLAP OLAP Híbridos 1 Los sistemas OLAP híbridos contienen características de los anteriores, de tal manera que almacenan alguna información de resúmenes en la memoria y datos básicos y otros resúmenes en bases de datos relacionales. Implica que en un Data Warehouse, se podría construir modelos de análisis utilizando ROLAP y otros modelos utilizando MOLAP. 2.2 Diferencias entre sistemas OLTP y sistemas OLAP 2 Las siglas OLTP, provienen de las palabras en ingles On Line Transactional Processing; lo cual significa procesamiento transaccional en línea. Considerando que los sistemas OLTP son aquellos sistemas que permiten la operatividad con las transacciones, los cuales se considera fuentes de datos para Warehouse con procesamiento OLAP. Las siguientes son características comparativas entre los sistemas OLAP de Data Warehouse y los sistemas OLTP Propiedades OLTP OLAP Warehouse 1 Ralph Kimball, The Data Warehouse Lifecycle tolkit, Wiley, Oracle Warehouse builder: Implementation Volume 2 Student Guide, 2002, Edición 2.0

26 15 Actividad Procesos Análisis Tiempo de respuesta Menores de segundos Segundos a horas Operaciones DML (Siglas en inglés Principalmente Solo Data Manipulation consulta Language: Lenguaje de manipulación de datos) Naturaleza de los datos Datos muy detallados, Fotografías (Snapshots) actualizados en corto periódicas tiempo Organización de datos Por aplicación Por tema específico, por tiempo Dimensión Pequeño a largo Largo a muy largo Fuente de datos Operacional, interno Operacional, interno, externo Figura 2-2Sistemas OLAP vs. OLTP (Fuente: Oracle Warehouse builder. Data Warehouse compared to OLTP) 2.3 Definición de Data Warehouse Un Data Warehouse es simplemente un singular, completo y consistente almacén de datos obtenidos de una fuente variada, dejándolos disponibles para los usuarios finales de manera que puedan entender y usar en el contexto de su negocio 1. Esto implica que un Data Warehouse es más que solo datos, también son procesos involucrados en la obtención de estos datos desde la fuente a tablas y obtención desde tablas a usuarios finales. En otras palabras un Data Warehouse es los datos (Metadatos/hechos/dimensión/agregación) y los administradores de procesos (carga/almacén/consulta), lo cual deja la información disponible, habilitandoles de buena infomación a los usuarios finales (analístas) en la toma de decisiones. 1 Devlin, Data Warehouse, from Architecture to Implementation, 1997, Pág 20

27 16 Un Data Warehouse es un repositorio empresarial estructurado de datos temas - orientados, tiempo - variación, usados para recuperar información y soporte a la toma de decisiones. Data Warehouse almacena datos atómicos y datos sumariados. Las definiciones indicadas de Data Warehouse, describen algunas de las características más significativas como: Orientado a temas específicos Mientras que los datos en un sistema OLTP son almacenados para soportar procesos de un negocio específico (por ejemplo: ingreso de ordenes, administrador de publicidad, etc.) tan eficientemente como sea posible; en Data Warehouse los datos son almacenados basados en áreas comunes de temas (ejemplo, clientes, productos, etc.) para fácil acceso. Un Data Warehouse es diseñado para proveer a los usuarios finales fácil acceso a los datos y que pueda responder a preguntas sobre estados actuales o a futuro Ubicación en el tiempo Data Warehouse contiene cortes de datos a través de diferentes periodos de tiempo. Con estos cortes los usuarios pueden visualizar reportes de datos actuales o pasados Historial de datos Un típico Data Warehouse contiene datos de algunos años, lo cual es necesario para soportar regresiones, proyecciones y ejecución de reportes basados en el tiempo, tales como el año actual comparado con años anteriores.

28 Recuperación de información y soporte a la toma de decisiones Un Warehouse ayuda a obtener información y responder preguntas. Esto no quiere decir que las entradas de datos son directas; En el proceso de extracción, carga y transformación de datos es común que se realice utilizando procesos en batch Datos atómicos y datos sumariados Dependiendo de los propósitos del Data Warehouse, este podría contener datos atómicos, datos sumariados o ambos. Los datos atómicos son aquellos datos que son obtenidos de forma pura de la fuente de información, los cuales ya no pueden ser subdivididos; mientras que los datos sumariados o resumidos son datos resultantes de aplicar algún tipo de cálculo, como suma, promedio, variación, etc. 2.4 Áreas de Aplicabilidad de un Data Warehouse Uno de los activos más importantes de cualquier organización es su información, esta información es siempre guardada de dos maneras: mediante el registro de sistemas operacionales y como Data Warehouse. Los usuarios de un sistema operacional ponen a funcionar las ruedas de la organización. Ellos toman órdenes, crean nuevos usuarios y receptan desconformidades. Siempre tratan al menos con un registro, ejecutando las mismas tareas operacionales una y otra vez.

29 18 Los usuarios de un Data Warehouse en cambio, observan cómo funcionan las ruedas de la organización. Cuentan las nuevas órdenes y las comparan con las de semanas pasadas y preguntan por qué se registran nuevos clientes y cuáles son los clientes que presentaron desconformidades. Nunca tratan con una fila a la vez, más bien buscan con cientos y miles de filas comprimidas en un conjunto de respuestas. En definitiva los usuarios continuamente cambian las claves de preguntas. Hasta ahora es ampliamente reconocido que Data Warehouse ha profundizado diferentes necesidades, entre ellas cuentan 1 : Puntos de venta (Minoreo) Inventarios Manejador de ordenes Administrador relación con clientes CRM (Siglas en inglés: Customer Relationship Manager) Contabilidad Administrador de recursos humanos Servicios financieros Telecomunicaciones Transporte Educación Salud Comercio electrónico Seguros 1 Ralph Kimball, The Data Warehouse Toolkit, Second Edition, Wiley, 1998

30 Objetivos del Data Warehouse Hacer que la información de la organización sea fácilmente accesible Los contenidos de Data Warehouse deben ser entendibles. Los datos deben ser intuitivos y obvios para los usuarios del negocio, no para el desarrollador. Entendible implica legibilidad; los contenidos de Data Warehouse necesitan ser etiquetados de forma significativa. Los usuarios del negocio quieren separar y combinar los datos en Warehouse en combinaciones infinitas, un proceso comúnmente referido como Slicing and dicing. Las herramientas para acceder al Data Warehouse deben ser sencillas y fáciles de usar, además deben retornar resultado de las consultas en el mínimo tiempo de espera Presentar la información consistentemente Los datos en Data Warehouse deben ser creíbles. Deben ser cuidadosamente ensamblados desde una variedad de fuentes de la organización, depurados, asegurando su calidad y entregado solo cuando esté listo para su utilización. La información de un proceso del negocio podría ser enlazada con información proveniente de otro proceso. Si dos medidas de ejecución tienen el mismo nombre, entonces implica que las dos medidas significan los mismo; de forma inversa, si dos medidas no significan lo mismo, entonces deben ser etiquetados de manera diferente. Información consistente implica información de alta calidad. 1 Ralph Kimball, The Data Warehouse Toolkit, Second Edition, Wiley, 1998

31 Ser adaptable y flexible a cambios Las necesidades de usuarios, las condiciones del negocio, los datos, y la tecnología son todos sujetos de cambio en el tiempo. El Data Warehouse debe ser diseñado para manejar estos inevitables cambios. Cambios para el Data Warehouse podrían ser contradictorios, principalmente porque no se puede anular los datos existentes o aplicaciones. Los datos existentes o aplicaciones no podrían ser modificados o eliminados cuando la comunidad empresarial formula nuevas preguntas o nuevos datos son agregados al Data Warehouse. Si las descripciones de datos son modificados, entonces se debe contabilizarlos para modificarlos apropiadamente Debe ser un baluarte seguro que proteja la información El Data Warehouse debe controlar de manera efectiva el acceso a la información confidencial de la organización Servir como fundamento para decisiones imprevistas Data Warehouse debe contener datos correctos para el soporte en la toma de decisiones. Existe solo una salida verdadera desde un Data Warehouse: Las decisiones que se realizan a partir del Data Warehouse determinan el impacto del negocio y valores atribuibles al Warehouse. 2.6 Componentes de un Data Warehouse En el entorno de Data Warehouse, se distinguen cuatro componentes principales 1, estos son: 1 Ralph Kimball, The Data Warehouse lifecycle toolkit, Wiley, 1998

32 21 1. Sistemas fuente 2. Área de recopilación de datos 3. Área de presentación de datos 4. Área de herramientas de acceso El siguiente gráfico esquematiza los elementos básicos de un Data Warehouse: Sistemas fuente operacionales Área de recopilación de datos Área de presentación de datos Herramientas de acceso a datos Extracción Servicios: Limpieza, combinación y estándares conforme a dimensiones NO SERVICIOS DE CONSULTA Carga Data Mart #1 Datos dimensionales, atómicos y sumariados basados en un singular proceso del negocio Acceso Herramientas de consulta específica (ad hoc) Generador de reportes Extracción Extracción Almacenamiento de datos: Archivos planos y tablas relacionales Procesamiento: Ordenamiento y procesamiento secuencial Carga DW Bus: Conformación de hechos y dimensiones Data Mart #2 (Diseñado de forma similar) Acceso Aplicaciones analíticas Modelado: Proyecciones (Forecasting) Calificación (Scoring) Minería de datos (Data mining) Figura 2-3 Elementos básicos de un Data Warehouse (Fuente: The Data Warehouse Lifecycle toolkit)

33 Sistemas fuente 1 Los sistemas fuentes deberían ser conceptualizados fuera del ámbito de Data Warehouse porque probablemente no se tiene mayor control sobre el contenido y formato de los datos en estos sistemas operacionales predecesores (Legacy systems). Las principales prioridades de los sistemas fuentes son rendimiento en el procesamiento y disponibilidad. La capacidad de mantener datos históricos es limitada en estos sistemas, por lo cual con la utilización de un Data Warehouse disminuirá la carga en los sistemas fuentes en el almacenamiento de dicha información histórica Área de recopilación de datos 1 El área de recopilación de datos es a la vez un área de almacenamiento y un conjunto de procesos comúnmente conocidos como Extracción Transformación Carga con sus siglas en inglés (ETL: Extract transformation load). Se encuentra entre los sistemas fuentes y el área de presentación de datos. Es similar a la cocina de un restaurante donde productos crudos son transformados en un delicado alimento. De forma análoga en Data Warehouse datos operacionales crudos son transformados en un almacén adecuado entregable para consultas de usuarios y utilización. 1 Ralph Kimball, The Data Warehouse lifecycle toolkit, Wiley, 1998

34 23 Es un área accesible únicamente por profesionales capacitados, en la que no puede estar dedicada a responder consultas de los usuarios, así como también los usuarios finales no pueden operar sobre ella. Es aceptable crear una base de datos normalizada para soportar los procesos del área de recopilación; sin embargo, este no es un objetivo final. Las estructuras normalizadas deben estar fuera de los límites para consultas de usuarios porque degradaría la comprensibilidad y el rendimiento. Por defecto, las bases de datos normalizadas son excluidas del área de presentación, la cual podría ser estrictamente dimensionalmente estructurada Área de presentación de datos 1 El área de presentación de datos es el lugar donde los datos son organizados, almacenados, y hechos disponibles para consultas directas de usuarios, generador de reportes y otras aplicaciones analíticas. El área de presentación es el Data Warehouse en cuanto a lo concerniente a la comunidad empresarial. Implica todo lo que la comunidad empresarial requiere ver y manipular mediante las herramientas de acceso. El uso del Modelamiento normalizado en el área de presentación del Data Warehouse degradaría todo el propósito de Data Warehousing, a saber, datos intuitivos y alto rendimiento en la recuperación de datos. 1 Ralph Kimball, The Data Warehouse lifecycle toolkit, Wiley, 1998

35 Área de herramientas de acceso 1 Una herramienta de acceso puede ser tan simple como una herramienta de query especializado (ad-hoc) o tan complejo como una sofisticada minería de datos (data minery) o modelado de aplicaciones. 2.7 Arquitectura Flujo de procesos en un Data Warehouse Los grandes procesos que constituyen un data Warehouse, estan orientados a la extracción, carga y transformación de datos, a los cuales se aplican procesos de consultas y reportes orientados a los usuarios finales. A continuación se detallan los procesos que conforman un Data WareHouse 2 : 1. Extracción y carga de datos 2. Refresco y transformación de datos, de manera que se pueda cubrir con un gran volumen de datos y proveer un buen rendimiento en las consultas 3. Respaldos y archivo de datos 4. Administración de consultas, y dirigirlos a la apropiada fuente de datos 1 Ralph Kimball, The Data Warehouse lifecycle toolkit, Wiley, Anahory S. Data Warehouse In the real world, 1997, Addison Wesley Pág 22

36 25 Fuente Warehouse Usuarios Transformación y movimiento de datos Extracción Y Carga Archivo de datos Consultas Figura 2-4Flujo de procesos típico en un data Warehouse (Fuente: Anahory S. Data Warehouse In the real world) Interfase de extracción y carga 1 La extracción de datos, toma los datos de los sistemas fuentes y los deja disponibles para el data Warehouse; la carga toma los datos extraídos y los carga en el data Warehouse. La información puede ser definida como datos con contexto y significado. En los procesos de extracción y carga, se toma los datos y se agrega contexto y significado, de esta manera se convierte en un valor agregado para la información del negocio. En Data Warehouse, esto se logra mediante la extracción de datos del sistema fuente (Sistema comercial), cargándolos en una base de datos, quitando cualquier detalle que 1 Anahory S. Data Warehouse In the real world, 1997, Addison Wesley

37 26 se encuentre para soportar al sistema operacional (Sistema comercial) y no como requerimiento del negocio, agregando mayor contexto (esto es, mas referencia de datos), y luego reconciliando los datos con otras fuentes. En la extracción y carga, es necesario considerar las siguientes actividades: Control del proceso 1 Los mecanismos que determinen cuando iniciar la extracción de datos, correr la transformación y chequeo de la consistencia, son muy importantes. Podría ser inapropiado extraer los datos del sistema comercial, hasta que todas las transacciones hayan sido recibidas por el sistema comercial y auditadas. En la práctica el proceso de extracción podría empezar antes de que todos los datos hayan sido recibidos, lo cual podría dificultar resolver la consistencia de los datos entregados si todos los datos no están disponibles. Así para asegurar que las herramientas y programas son ejecutados en la secuencia correcta y en el tiempo correcto, es necesario un mecanismo de control para disparar cada módulo cuando sea apropiado. En la construcción del prototipo del presente proyecto de titulación, el control de la secuencia apropiada en la ejecución de carga, extracción y transformación de los datos, se basará en la elaboración de un script que contenga el orden de ejecución de los diferentes procesos generados y efectúe la ejecución. 1 Anahory S. Data Warehouse In the real world, 1997, Addison Wesley

38 Cuando iniciar la extracción 1 Los datos deberían estar en un estado consistente cuando son extraídos desde el sistema fuente. Mas aún, la información en el Data Warehouse representa una fotografía de la información corporativa, de esta manera el usuario observa una sencilla, consistente, versión de la realidad. Los datos fuente deberían ser extraídos únicamente en un punto donde representa la misma instancia en la extracción de otras fuentes de datos. Considerando el sistema comercial planteado como prototipo, en un Data Warehouse perfilando, es ilógico unificar la lista de clientes el viernes a las 19H00 desde una base de datos de clientes, con eventos de pro-formas (solicitud de compra) del día jueves a las 19h00 desde una base de eventos de clientes. Esto podría significar encontrarnos probablemente clientes para quienes no existen pro-formas asociadas. Este problema se agrava cuando los datos operacionales representan al mismo tiempo periodos diferentes entre sistemas fuentes Carga de datos Una vez los datos son extraídos desde los sistemas fuentes, típicamente son almacenados en un repositorio temporal con el fin de ser depurados y darles consistencia. Estos chequeos pueden ser tan complejos e identificar entregas consistentes cuando se integra datos desde algunas fuentes. 1 Anahory S. Data Warehouse In the real world, 1997, Addison Wesley

39 28 Tomando el ejemplo de la empresa comercial, donde se mezcla una base de detalles de los clientes con la base de eventos de clientes: Esto es, una base de datos que contenga una fotografía de todos los clientes registrados, con una base de datos que contenga las transacciones respectivas de estos clientes. En definitiva, el proceso de carga de datos debe ser capaz de ejecutar automáticamente; es decir, tener la inteligencia para reportar errores en la carga y removerlos y solicitar intervención del usuario. Por ello es importante tener cuidado cuando se realiza el diseño del proceso de carga (Se consigue con la definición del el Modelo de Warehouse, Data Mart para el caso del presente trabajo), para asegurar de esta manera en el diseño integral el reestablecimiento por errores Herramientas para manejo de copias y depuración de datos 1 Como se puede observar, son complejos la mayoría de los chequeos de consistencia requeridos. La mayor parte de herramientas para el manejo de copias tienen la capacidad de aplicar estos chequeos directamente. Específicamente algunos productos que requieren tener esta facilidad implementada, permitiendo a los usuarios técnicos codificar en cada instrucción SQL, procedimiento almacenado, o sus propios lenguajes de programación. Esto significa que un considerable tiempo de desarrollo es gastado implementando esta lógica. Este problema nos guía a recomendar que se deba investigar el costo beneficio del uso de una herramienta para manejo de copias, antes de decidir realizar la compra. Si un sistema fuente no solapa mucho los datos y los chequeos de consistencia son 1 Anahory S. Data Warehouse In the real world, 1997, Addison Wesley

40 29 sencillos, una herramienta para manejo de copias quitará los esfuerzos de codificación requeridos Procesos de depuración y transformación 1 Este es el proceso del sistema que toma los datos cargados y los estructura para optimizar las consultas y con ello minimizar los costos operacionales. En esencia existen 3 pasos en el proceso: 1. Depuración y transformación de datos cargados en estructuras que agilice las consultas. 2. Particionamiento de los datos con el fin de agilizar las consultas, optimizar el rendimiento del hardware y simplificar el manejo del Data Warehouse. 3. Crear agregaciones para agilizar las consultas comunes. Los datos necesitan ser depurados y chequeados de la siguiente manera: 1. Asegurar que los datos son consistentes así mismos. 2. Asegurar que los datos son consistentes con otros datos en la misma fuente. 3. Asegurar que los datos son consistentes con datos en otros sistemas fuentes. 1 Anahory S. Data Warehouse In the real world, 1997, Addison Wesley

41 30 4. Asegurar que los datos son consistentes con la información existente en el Data Warehouse Procesos de administración de consultas 1 El proceso de administración de consultas es el proceso del sistema que maneja las consultas, agilizándolas y direccionándolas a las fuentes de datos más efectivas. Este proceso también se debe asignar y definir de tal manera que los recursos del sistema sean utilizados de la manera más efectiva, usualmente con la ejecución de consultas (queries) calendarizadas. El proceso para manejo de consultas podría también ser requerido para monitorear los perfiles de las consultas actuales. Esta información podría luego ser utilizada por el proceso de administración del Data Warehouse para determinar que agregaciones generar. De manera diferente a procesos de otros sistemas, la administración de consultas, generalmente no opera durante la carga regular de la información en el Data Warehouse. Este proceso opera en todo el tiempo que el Data Warehouse está disponible a los usuarios finales. 1 Anahory S. Data Warehouse In the real world, 1997, Addison Wesley

42 Estrategia para la implementación del Data Warehouse Método de desarrollo incremental El modelo incremental entrega el software en partes pequeñas, pero utilizables, llamadas incrementos. En general, cada incremento se construye sobre aquel que ya ha sido entregado. El modelo incremental combina elementos del modelo lineal secuencial con la filosofía interactiva de construcción de prototipos. El modelo incremental aplica secuencias lineales de forma escalonada en el tiempo. Cuando se utiliza el modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión detallada). Como un resultado de utilización y/o evaluación, se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y características adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.

43 32 Incremento 1 Análisis Diseño Código Prueba Entrega incremento Incremento 2 Análisis Diseño Código Prueba Entrega incremento Incremento 3 Análisis Diseño Código Prueba Entrega incremento Incremento 4 Análisis Diseño Código Prueba Entrega incremento Figura 2-5Modelo incremental (Fuente: Pressman, Ingeniería del software, Quinta Edición) Metodología para implementar un Data Warehouse Selección del ámbito de la implementación 1 En la mayoría de las organizaciones, la motivación principal del proyecto de Data Warehouse es una primera implantación que produzca beneficios inmediatos a un grupo de usuarios. Después de definir un rumbo general y un conjunto general de objetivos para el Data Warehouse, se hace necesario derivar con rapidez un ámbito limitado para la primera implementación. 1 Ralph Kimball, The Data Warehouse Lifecycle toolkit, Wiley, 1998

44 33 El ámbito del proyecto de Data Warehouse puede restringirse entre muchas dimensiones. Las dimensiones se dividen en dos categorías principales: 1. Ámbito determinado a partir de la perspectiva del usuario empresarial del Data Warehouse 2. Determinación del ámbito con base en consideraciones tecnológicas Definición del enfoque arquitectónico 1 El implementador dispone de las siguientes opciones arquitectónicas: Solo Data Warehouse Por lo general, todas las aplicaciones del Data Warehouse requieren diversas operaciones que se aplican sobre las fuentes de datos Solo Mercado de datos Data Mart Cada departamento funcional en una organización tiene sus propias necesidades específicas y que un solo Data Warehouse corporativo no puede satisfacer todas las necesidades Data Warehouse y Mercado de datos 1

45 34 Las necesidades del Data Warehouse específicas de un departamento se deben abordar junto con la necesidad de un Data Warehouse corporativo Separación de plataforma e infraestructura Los cortes arquitectónicos se usan para separar la plataforma para el Data Warehouse, los mercados de datos, las fuentes de datos y las herramientas del usuario final Posee flexibilidad y se pueden compartir plataformas Arquitectura Cliente/Servidor de dos capas Consiste en emplear dos capas de plataformas, una capa contiene a los clientes aplicaciones gráficas y la otra al servidor estación de trabajo, microcomputadora Arquitectura Cliente/Servidor de tres capas Consiste en emplear tres capas: 1. Capa del cliente, que es las estaciones de trabajo del usuario 2. Capa intermedia, sobre un servidor 3. Capa de datos establecida en una macrocomputadora

46 Determinación del Alcance Establecer el alcance requiere de la participación de la organización de tecnología de la información, así como también de la dirección de la empresa. El alcance del proyecto de Data Warehouse debe ser magnificado en términos del valor de la organización y su manejabilidad. Cuando se inicia un proyecto de Data Warehouse, se debe primeramente focalizar en los datos de un simple proceso del negocio. Se debe ahorrar más desafíos de proyectos de procesos cruzados para después. Algunas veces los alcances son manejados por periodos calendarios, tales como el final del periodo fiscal. Se puede manejar el alcance a una fecha efectiva, pero hacer esto podría presentar riesgos adicionales. Incluso enmarcado en un periodo de tiempo, se requiere mantener el enfoque del alcance del proyecto en función de hacerlo forzado y que sea realizable. Algunas veces los equipos de proyectos han experimentado que el tiempo de entrega es desechado, incluso cuando se inició antes una planeación del proyecto. Determinar la prioridad de los procesos, los cuales se describen durante la definición de los requerimientos del negocio, pueden ser usados para convencer a la dirección de información tecnológica y de la empresa a realizar los ajustes necesarios.

47 Justificación del proyecto 1 La justificación del proyecto requiere una estimación de beneficios y costos asociados con el Data Warehouse; Se espera que los beneficios pesen mucho más que los costos. La dirección de tecnología de la información usualmente es responsable de definir los gastos. Por ello se requiere determinar costos aproximados para los requisitos de hardware y software. Data Warehouse tiende a expandirse rápidamente, por tanto se debe asegurar que los costos estimados permitan algunos espacios para términos cortos de crecimiento. Data Warehouses, comúnmente son justificados basados en incrementadas ganancias u oportunidades de ingresos antes que meramente focalizar en reducción de gastos. Entregar información veraz o un acceso flexible a los datos no es una justificación suficiente. Para ello es necesario analizar mucho más para determinar el impacto cuantificable de hacer posible el mejoramiento en los procesos de toma de decisiones. Cuando la justificación del Data Warehouse se torna muy combativa, es probable que se haya centrado en un patrocinador equivocado o en un problema equivocado. 1 Ralph Kimball, The Data Warehouse toolkit, Second Edition, Wiley, 1998

48 Equipo de trabajo 1 Un proyecto de Data Warehouse requiere de la integración de un equipo con recursos del negocio y de comunidades de tecnología de la información (técnicos). Es común que una misma persona asuma más de un rol, especialmente porque son pocas las personas que conocen de esta tecnología. Las asignaciones de los recursos, dependen de la magnitud del proyecto y el alcance, tanto como de habilidades individuales, capacidad y experiencia. Para el desarrollo de un Data Warehouse se definen los siguientes roles más representativos, desde la perspectiva del negocio: Patrocinador del negocio El patrocinador es el cliente fundamental del Data Warehouse, así como su más fuerte defensor. Este rol muchas veces toma la forma de un comité ejecutivo directivo, especialmente en empresas de intereses cruzados Gerente del proyecto Si el proyecto se aplica a una gran organización, el patrocinador podría ser también removido o inaccesible al equipo del proyecto. 1 Ralph Kimball, The Data Warehouse toolkit, Second Edition, Wiley, 1998

49 38 En este caso algunas veces el patrocinador delega sus responsabilidades a un gerente medio en la organización. Este conductor, podría tener las mismas características que un patrocinador Líder de negocio El líder de negocio es igualmente una persona respetable, quien esta altamente involucrada con el proyecto, mantiene una muy buena comunicación con el Líder técnico del proyecto. La misma persona que se desempeña como Gerente del proyecto o Experto podría desempeñar este rol Analista de negocio Se requiere involucrarlos inicialmente y muchas veces deben participar en la determinación del alcance del proyecto y los requerimientos. Es crítica la participación de los usuarios analístas del negocio involucrados para la aceptación del Data Warehouse. Sin los usuarios, el Data Warehouse sería únicamente un ejercicio técnico vano. Estas personas pueden ser recursos técnicos que entienden del negocio o recursos usuarios (negocio) que entienden de tecnología. Son los responsables de determinar las necesidades del negocio y trasladarlos a la arquitectura, datos, y requerimientos de la aplicación analítica; así como también entienden cual es el significado de los datos, como son usados, y donde se podrían presentar las inconsistencias de los datos. Su análisis e incursión en los datos es

50 39 extremadamente utilizada, especialmente durante el Modelamiento y aplicación de procesos analíticos Desarrollador de aplicaciones analíticas Los desarrolladores de aplicaciones analíticas son responsables de diseñar y desarrollar el conjunto inicial de plantillas analíticas, tales como las definidas con business intelligence Líder técnico del proyecto El líder técnico del proyecto se ubica en una posición crítica en el desarrollo del Data Warehouse, puesto que en esta persona se asienta la responsabilidad de la dirección técnica del proyecto; por ello debe sentirse cómodo y respetado por los ejecutivos del negocio, tanto como analistas técnicos Arquitecto técnico El arquitecto técnico es responsable de toda la arquitectura técnica y arquitectura de seguridad. Debe desarrollar el plan que junta la funcionalidad técnica requerida y ayuda a evaluar productos en base a toda la arquitectura.

51 Modelador de datos Abarca conceptos de modelos dimensionales y enfatizar los requerimientos del negocio antes que centrarse estrictamente en ahorro de espacio o reducir las áreas de carga Administrador de la base datos Igualmente que el Modelador de datos el administrador de base de datos debe dejar aparte algunos conceptos tradicionales de administración de base de datos, tales como solo definir un índice en una tabla relacional; esto puesto que la estructuras de un Data Warehouse en muchas ocasiones deben ser denormalizados para optimizar tiempo de respuesta, con lo cual difieren de los sistemas transaccionales de procesamiento en línea Coordinador de la metadata Se asegura que toda la metadata ha sido recolectada, manipulada y depurada. Como un guardián, el coordinador es responsable recordar al resto de personas la obligación de mantener la metadata centralizada. Adicionalmente es responsable de lograr acuerdos en la empresa para establecer las tablas de hecho y dimensiones Diseñador del área de recopilación de datos Es responsable del diseño de los procesos de recopilación de datos: extracción, transformación y carga.

52 Desarrollador del área de recopilación de datos Es responsable de la programación de de los procesos de recopilación de datos: extracción, transformación y carga Soporte de Data Warehouse Se involucran en el back end y front end. A menudo es asignado a individuos quienes se involucraron al proyecto, previo una capacitación inicial. Figura 2-6 Organigrama Establecimiento del presupuesto y plan de trabajo Uno de los aspectos más importantes de la planeación consiste en poder cumplir con las siguientes actividades:

53 42 Articular tanto un plan de programa como un conjunto de planes de proyecto. Un plan de programa es una visión general de la actividad del Data Warehouse y su función en la vida diaria y semanal de la organización. El plan de programa proporciona la estrategia y los planes de proyecto proporcionan la táctica Reservar un presupuesto adecuado para el programa al tiempo que se compromete el gasto para proyectos específicos. La planeación de este presupuesto se basa en dos enfoques: o Estimación del costo, con base en el historial de la organización en el desarrollo del software. o Estimación del costo, con base en la arquitectura de referencia. Proporcionar medidas para la estimación de la retribución del Data Warehouse.

54 43 3 Capitulo III: Construcción del Data Warehouse 3.1 Ingeniería de Software Definición del enfoque arquitectónico El enfoque arquitectónico a utilizar en el desarrollo del presente proyecto está conformado por los siguientes tipos de arquitecturas: Solo Mercado de datos Data Mart Se optó por este enfoque arquitectónico, considerando que se orienta la solución a necesidades específicas, las cuales son originadas por el análisis de ventas; no habiendo la necesidad de distribuir datos a otras áreas Arquitectura Cliente / Servidor de tres capas Se selecciona esta arquitectura para mejorar el rendimiento en la generación de las consultas y reportes efectuados sobre el Data Mart propuesto La primera capa se refiere al procesamiento del cliente en la estación de trabajo, con la utilización de Oracle Discoverer Client. La segunda capa está concentrada en el proceso de administración de consultas, lo cual está específicamente representado con la utilización de Oracle Discoverer Administration.

55 44 La tercera capa contiene a los datos recopilados en el Data Warehouse, representado por el Data Mart propuesto Determinación del alcance del proyecto Descripción El proyecto a desarrollar contempla la construcción de un Data Warehouse orientado a sistemas comerciales; específicamente en el área de ventas. Se focaliza la implementación únicamente en el área de ventas con el objeto de proporcionar una herramienta que ayude a los analistas de producto y mercado a visualizar las ventas y tendencias en las que se encuentra la empresa Definición del alcance Implementación de los procesos de extracción y carga desde los sistemas fuentes hacia el área temporal de integración y recolección de datos Implementación de los procesos de transformación del área de Data Warehouse, constituido por un Data Mart Generación de una consulta sobre cantidad y montos vendidos por: o o o o Producto Empleado Cliente Ciudad destino (Domicilio del cliente)

56 45 Esta información dada en el tiempo por: o o o o o o o Fecha específica Semanal Mensual Quincenal Bimestral Semestral Anual Exclusiones No contempla el proyecto, Optimización de la base de datos en cuanto a procesos externos de agregación y respaldos del Data Warehouse No contempla una interfase gráfica para la ejecución de los procesos de extracción, carga y transformación No contempla áreas de hold para reproceso a inconsistencias de data Criterios de éxito El éxito logrado en la construcción del presente proyecto, está dado por la calidad del producto y la entrega a tiempo en un año calendario, tiempo en el cual dura el proyecto de titulación

57 Riesgos del proyecto y riesgo de reducción del plan original Posibles bugs existentes en las herramientas utilizadas para la construcción, sobre Windows XP. Para ello se prevé un equipo con windows 2000 de soporte, en el cual las herramientas Oracle son mayormente probadas Justificación del proyecto Si bien el proyecto incurre en gastos de acuerdo al presupuesto mostrado en los acápites siguientes y considerando los beneficios que brinda el proyecto tal como: Agilidad en la toma de decisiones Información actualizada y a tiempo Proyección de mercado Facilidad en la generación de consultas y reportes gerenciales Presentación de la información agregada y detallada, conocido como Drill Down. Queda justificado el presente proyecto, puesto que son mayores los beneficios que los gastos a incurrir.

58 Equipo de trabajo No. Cargo Responsable 1 Patrocinador del negocio Universidad de las Américas 2 Gerente del proyecto Ing. Maritzol Tenemaza Msc. 3 Líder de negocio Sr. Alcívar Llacsahuanga 4 Analista del negocio Sr. Alcívar Llacsahuanga 5 Desarrollador de aplicaciones analíticas Sr. Alcívar Llacsahuanga 6 Líder técnico del proyecto Sr. Alcívar Llacsahuanga 7 Arquitecto técnico Sr. Alcívar Llacsahuanga 8 Modelador de datos Sr. Alcívar Llacsahuanga 9 Administrador de la base de datos Sr. Alcívar Llacsahuanga 10 Coordinador de la metadata Sr. Alcívar Llacsahuanga 11 Diseñador del área de recopilación Sr. Alcívar Llacsahuanga 12 Desarrollador del área de recopilación Sr. Alcívar Llacsahuanga 13 Soporte de Data Warehouse Sr. Alcívar Llacsahuanga Figura 3-1 Equipo de trabajo

59 Establecimiento del presupuesto y plan de trabajo Plan de trabajo No. Actividad Responsable Fecha entrega 1 Elaboración del plan del proyecto Sr. A. Llacsahuanga 2003/10/17 2 Levantamiento teórico Sr. A. Llacsahuanga 2004/01/01 3 Análisis del sistema Sr. A. Llacsahuanga 2004/03/01 4 Elaboración del diseño Sr. A. Llacsahuanga 2004/06/01 5 Desarrollo de mapping Sr. A. Llacsahuanga 2004/08/01 6 Desarrollo de consulta Sr. A. Llacsahuanga 2004/09/01 7 Documentación Sr. A. Llacsahuanga 2004/09/15 8 Pruebas funcionales Sr. A. Llacsahuanga 2004/10/01 9 Documentación de usuario Sr. A. Llacsahuanga 2004/10/20 Figura 3-2 Plan de trabajo El presupuesto planteado está definido en base al enfoque arquitectónico propuesto en la construcción del prototipo del presente trabajo, el cual consiste en el modelo de Data mart Presupuesto de desarrollo del proyecto propuesto Cant. Rubro Costo 720 Días de trabajo de un recurso humano. Se toma como base ,00 USD60,oo diarios por 12 personas durante 2 meses hombre 1 Computador portátil para desarrollo 1.500,00 1 Servidor de Aplicaciones Discoverer Administrador ,00 11 Alquiler de estaciones de trabajo 3.300,00

60 49 1 Licencia Oracle 9i Data Base para 1 procesador ,00 3 Licencia Oracle 9i Warehouse Builder ,00 1 Licencia Oracle 9i Oracle Discoverer 1 0,00 TOTAL ,00 Figura 3-3 Presupuesto 1

61 Análisis de requerimientos Descripción del desarrollo El esquema de negocio correspondiente al sistema fuente y al desarrollo de Data Warehouse, esta enfocado en una empresa dedicada a la comercialización de artículos de vestir, tales como telas, pantalones, camisas, zapatos, faldas, etc. El desarrollo del prototipo del presente proyecto consiste en definir un área de extracción de datos del sistema fuente utilizado para efectuar las ventas, con mínimas transformaciones, denominada Staging área o área de recopilación. Esta área a su vez podrá ser considerada como un integrador, permitiendo recopilar información de otros sistemas fuentes; sin embargo para presentación del prototipo se realizará en función únicamente del sistema de ventas. Por tal motivo el desarrollo del presente prototipo iniciará a partir de un modelo de datos y diccionario de datos del sistema fuente de ventas. Posteriormente al Staging área se definirá un modelo Data Mart utilizando el modelo estrella en la construcción de Data Warehouse. En este proceso se realizarán las transformaciones fuertes de la información en una estructura denormalizada. Los procesos de extracción, carga y transformación de la información, se la realiza utilizando Oracle Warehouse Builder. Finalmente la información almacenada en el Data Warehouse obtenido será desplegada a través de un reporte para soporte de ventas y mercadeo, utilizando Oracle Discoverer.

62 51 El grafico siguiente, representa el esquema planteado para el desarrollo del prototipo: Figura 3-4 Esquema de desarrollo de Data Warehouse

63 Casos de usos Caso de Uso: Warehouse Autor: Alcívar Llacsahuanga Fecha: 2004/10/25 Extracción datos fuente Usuario Técnico Validar Usuario Transformar datos de Base de datos hacia Data Mart Generar Consultas y reportes Usuario del negocio Imprimir Consultas y reportes

64 Diccionario de casos de uso Extracción datos fuentes Descripción Este caso de uso especifica la extracción, carga y transformaciones mínimas realizadas desde las estructuras del sistema fuente hacia el área de recopilación de datos Flujo de eventos Ingresar mediante herramientas de conexión a la base de datos Ejecutar script que contiene el proceso de extracción por cada tabla definida en los mapeos Precondiciones El usuario técnico accesa correctamente a la base de datos Postcondiciones En caso de existir errores en la carga, Se debe utilizar Oracle Warehouse Builder para permitir reprocesar Transformación hacia Data Mart

65 Transformar datos hacia Data Mart Descripción Una vez que el proceso de extracción, transformación y carga se completó con éxito, se debe ejecutar el proceso para carga y transformación del área de recolección hacia las tablas correspondientes del Data mart Flujo de eventos Ingresar mediante herramientas de conexión a la base de datos Ejecutar script que contiene el proceso de extracción por cada tabla definida en los mapeos Precondiciones El usuario técnico accesa correctamente a la base de datos Postcondiciones En caso de existir errores en la carga, Se debe utilizar Oracle Warehouse Builder para permitir reprocesar Transformación hacia Data Mart

66 Generación de consultas y reportes Descripción Obtiene los datos almacenados en el área de Data Mart y procesa la consulta predefinida, considerando las dimensiones definidas para la generación de la consulta Flujo de eventos Ingresar mediante Oracle Discoverer Seleccionar reporte a generar Precondiciones El usuario final accesa correctamente a la base de datos al área definida para ejecución de reportes y consultas Impresión de Consultas y reportes Descripción Permite imprimir las consultas generada con el Discoverer, para ello utiliza las funcionalidades de Oracle Discoverer Flujo de eventos Ingresar mediante Oracle Discoverer Client Seleccionar reporte a generar Seleccionar el menú imprimir

67 Precondiciones El usuario final ha realizado correctamente a la base de datos al área definida para ejecución de reportes y consultas. El usuario final ha generado la consulta

68 Análisis y diseño Modelo Estático Sistema Fuente Modelo de datos

69 58

70 Diccionario de datos Ver anexo Diccionario de datos del sistema Fuente

71 Área de recolección e integración de sistemas fuente Esta área almacena temporalmente los datos recopilados desde el sistema fuente, con mínimas transformaciones. Se plantea esta área con el fin de representar un área que permita integrar a más de una sistema fuente OLTP operable por la empresa o corporación. Para el caso de la construcción del presente prototipo, se desarrolla el proceso de extracción, transformación y carga de un sistema fuente orientado a ventas. De acuerdo a las recomendaciones de la metodología planteada en la construcción de Data Warehouse, las tablas integrantes de esta área no se referencia con claves foráneas, puesto que el proceso de carga debe ser ágil, con un mínimo tiempo de respuesta. En el presente prototipo se extrae todos los datos del sistema fuente; cargándolos en el área de recolección. Si bien en el Data Mart todos los datos no son utilizados para el modelo propuesto, habiendo información sin uso para este modelo, principalmente en lo relacionado a datos de dimensión; sin embargo quedan disponibles para incorporación posterior en el Data Mart o en otros Data Mart o modelos de análisis Modelo de datos

72 61

73 Diccionario de datos Ver anexo Diccionario de datos del área de recolección

74 Data Mart Modelo de datos

75 Diccionario de datos Ver anexo Diccionario de datos del Data Mart

76 Modelo Dinámico Extracción y carga datos fuente al área de recolección e integración Ciudades

77 Clientes 66

78 Direcciones 67

79 Empleados 68

80 Ordenes de compra 69

81 Detalle de ordenes de compra Países

82 Productos 71

83 Transformación y carga a Estructuras Data Mart Tabla de hechos

84 Dimensión de clientes 73

85 Dimensión de productos Dimensión de empleados

86 Construcción Oracle Oracle, es una empresa de software considerada muy importante dentro del desarrollo tecnológico del país y el mundo, cuyas actividades productivas se enfocan a proporcionar herramientas para almacenamiento de datos, desarrollo e implementación de sistemas informáticos Oracle Warehouse Builder Oracle Warehouse builder es una herramienta proporcionada por la compañía Oracle, cuya función primordial consiste en facilitar el desarrollo de procesos para la extracción, carga, transformación de un Data Warehouse. El proyecto planteado, está desarrollado con la utilización de esta herramienta en la elaboración de las interfases para extraer, transformar y cargar datos desde el área fuente hacia el área de recolección y finalmente hacia el Data Mart Despliegue de mappings a la base Luego de definidos los mapeos de carga, transformación y carga, es necesario realizar el despliegue, dando como resultado paquetes almacenados en la base de datos con las rutinas necesarias para ejecutar este proceso. A continuación se muestra los pasos aplicados para realizar el despliegue del mapeo para cargar los productos:

87 76 1. En el ambiente de Oracle Warehouse Builder, se debe acceder al módulo que contiene los mapeos de carga. Para la ilustración, tomamos el mapeo correspondiente a los productos, seleccionando Generar

88 77 2. posteriormente se debe seleccionar generara scripts 3. Se genera el script, con lo cual se debe indicar ejecutar el despliegue

89 78 4. Inmediatamente se debe ingresar el usuario e instancia de la base de datos donde se va a realizar el despliegue, lo cual consiste en crear el paquete con las rutinas necesarias para ejecutar los procesos de extracción, carga y transformación Oracle Discoverer Oracle Discoverer es una herramienta que permite generar reportes basado en procesamiento OLAP. Para ello se divide en dos componentes: Administración, en la cual se genera los un área de usuario y área de negocio; El segundo componente es el procesamiento en el cliente con la elaboración de las consultas y reportes.

90 Diagrama de componentes Extracción de datos Carga de Data Mart del sistema fuente Consultas y reportes Figura 3-5 Diagrama de componentes

91 Pruebas funcionales Datos predefinidos en el área de recolección Tabla de catálogo código de catalogo Descripción 1 Países 2 Ciudades 3 Idiomas Código de catálogo Secuencia de catálogo Código ISO Descripción 1 1 ECU Ecuador 1 2 CHI Chile 1 3 COL Colombia 2 1 UIO Quito 2 2 GYE Guayaquil 2 3 CUE Cuenca 2 4 SNT Santiago 2 5 IQQ Iquique 2 6 BOG Bogotá 2 7 CAL Cali 2 8 MAN Manisales 3 1 ESP Español 3 2 ENG Inglés 3 3 FRA Francés

92 Datos fuente Ciudades Código de ciudad Nombre Ciudad Fecha de proceso 1 Quito 10/20/ Guayaquil 10/20/ Cuenca 10/20/ Santiago 10/20/ Iquique 10/20/ Bogotá 10/20/ Cali 10/20/ Manizales 10/20/ Clientes Código de cliente Tipo ID Identificación Nombres Apellidos Idioma Cupo Estado Civil Sexo Fecha Nacimiento Fecha Proceso 1 C Juan Llacsahuanga C M 3/21/ /20/2004 Alcívar 2 C Tatiana Zabalaga C F 10/24/ /20/2004 Marisol 3 P SH226 Juan Pérez S M 1/2/ /20/2004 Eduardo 4 C Ignacio Solís 1 S M 4/16/ /20/ Direcciones Cód Direcc Tip Dir Dirección Cod. Postal Cod. Ciudad Cod. Provincia Cod. País Cod Cli Cod Emp Cod prov Fecha proceso 1 1 Av. 10 de QUI /20/2004 Agosto 2 1 Av. Florida XXX /20/ Av. Shiris SHI /20/ Malecón 2000 MALECON /20/2004

93 Empleados Cód Tip Identifica Nombres Apellidos Telf. S E Código Sueldo Fecha Fecha D Fecha Emp ID e S Escalafón Ingreso Nacimiento e Proceso x t. p o e C n i d v e i l 1 C Luis Fernando 2 C Xavier Eduardo Tipan Almeida Robles Conde luis@hotmail.com M C /20/2000 2/20/ /20/2004 Xavier@yahoo.com M S /20/2000 5/24/ /20/ C Maria Barrera Esther@hotmail.com F C /20/2000 5/10/ /20/2004 Esther 4 C Marco Rueda Marco@interactive.co M S /20/2000 1/10/ /20/2004 Vinicio Estupiñán m

94 Ordenes Cod Orden Fecha Status Total Cod Emp Cod Cli Cod Prom Cod Prov Fecha proceso Ciudad 1 10/20/2004 V /20/ /20/2004 V /20/ /20/2004 V /20/ /20/2004 V /20/ Cod Orden Secuencia Cantidad Precio unitario Cod Prod Fecha proceso /20/ /20/ /20/ /20/ Países Código de país Nombre de país Zona geo Fecha de proceso 1 Ecuador 1 10/20/ Chile 1 10/20/ Colombia 1 10/20/ Productos Cod. Prod Nombre Nomb. Corto Medida Color Costo Fecha proceso 1 Pantalón Azul Pantalón pantalón AZUL /20/ Camisa CamisaF Camisa BLANCO 80 10/20/2004 Formal 3 Zapato casual 1 ZapCasual1 Zapato NEGRO /20/2004

95 Ingreso Oracle Sql-plus Para ejecutar los scripts de carga, se plantea realizarlo a través de Sql-plus, el cual provee una interfase para conectarse a la base de datos y ejecutar los scripts obtenidos de los mapeos realizados con Oracle Warehouse Builder Ejecución de Scripts de carga desde fuente Una vez ingresado al utilitario Sql-plus de Oracle, se ejecuta el script tesis_mapeofuente.txt, el cual invoca a los store procedures correspondientes a la extracción, transformación y carga desde el sistema fuente al área de recopilación de datos

96 Ejecución de scripts de carga a Data Mart Luego que los datos han sido obtenidos satisfactoriamente desde el sistema fuente, se debe ejecutar el proceso para transformación de datos desde el área de recolección hacia las estructuras del Data Mart. Estos procesos están desplegados en la base de datos como paquetes almacenados. El script a ejecutar se denomina tesis_datamart.txt, el cual será ejecutado con la utilización de Oracle Sql-plus Despliegue de resultados Una vez los datos han sido cargados al Data Mart, se podrán realizar las consultas y reportes necesarios, dirigidos a las necesidades del negocio y en consecuencia con el Data Mart definido. Para propósitos del presente proyecto, se despliega información sumariada de las ventas realizadas por año, País, Ciudad, con información de los clientes y vendedores.

97 86 En la siguiente pantalla se muestra la información de las ventas utilizando Oracle Discoverer. Los datos consultados pueden ser impresos con el formato siguiente: Considerando los pasos escenciales del proceso de depuración, transformación y consistencia de datos, a continuación se explica la aplicación de dichos pasos en el presente prototipo:

98 87 1. La depuración y transformación de datos fueron cargados en estructuras sin referencias foráneas, con el fin de que el proceso de carga tenga un menor tiempo de respuesta. 2. La tabla de hechos es particionada por el campo de fecha de proceso (FechaProceso) 3. Las agregaciones son generadas por Oracle Discoverer utilizado para presentar las consultas y reportes. 4. La consistencia de los datos se asegura tomando en consideración: a. Los datos son validados así mismos, comparando el número de datos en el sistema fuente versus los datos cargados al área de recolección. Para ello en cada proceso de de carga se ejecuta la validación de postmapping. b. Los datos son válidos con otros datos del sistema fuente, al comprar que los datos de las órdenes de compra sean consistentes con los datos de clientes, productos, promociones, proveedores y ciudades. Para ello en el proceso de órdenes de pago se ejecuta la validación de post-mapping. c. Los datos son válidos con la información del Data Warehouse, puesto que los datos que conforman las claves foráneas de la tabla de hechos existen en las tablas de dimensiones.

99 88 4 Capitulo IV: Conclusiones y recomendaciones 4.1 Conclusiones 1. En la actualidad las empresas están destinadas a competir, tanto en calidad como en precio de los productos y servicios que distribuye, por tal motivo Data Warehouse, se convierte en una herramienta que facilite focalizar segmentos y tendencias de mercados, permitiendo de esta manera orientar de forma optima los productos y/o servicios. 2. La información con la que cuenta un gerente de una empresa es extremadamente extensa como para utilizarla como una herramienta efectiva en la toma de decisiones; por ello las herramientas OLAP facilitan la manipulación de grandes volúmenes de información; permitiendo la toma de decisiones de una manera acertada y oportuna. 3. Data Warehouse ya se convirtió en un sistema de misión crítica en las empresas de distintas áreas de negocio; y, a la par las herramientas para el desarrollo de un proyecto de Data Warehouse están evolucionando; con lo cual genera mayor confianza en los sistemas de Data Warehouse.

100 Recomendaciones 1. Para una mayor exactitud en la toma de decisiones, se recomienda que las empresas de toda dimensión utilicen un sistema de Data Warehouse 2. En vista de que un proyecto de Data Warehouse se puede tornar extenso y con ello adquirir complejidad, se recomienda interactuar permanentemente entre usuarios y técnicos, asegurando en lo posible que el equipo de trabajo sea el mismo desde el inicio del proyecto hasta su finalización. 3. Se recomienda definir al grupo de analistas del negocio, personas con perfil técnico y de usuario con conocimiento consistente del negocio. 4. Con el fin de facilitar el desarrollo e implementación de Data Warehouse, se recomienda utilizar un kit compatible de herramientas. En lo posible utilizar herramientas de una sola marca.

101 90 5 Bibliografía 1. Silberschatz, Fundamentos de Bases de datos, Cuarta Edición, Mac Graw Hill, Presuman, Ingeniería de software, Quinta Edición, Ralph Kimball, The Data Warehouse Toolkit, Second Edition, Wiley, Ralph Kimball, The Data Warehouse Lifecycle toolkit, Wiley, Anahory, Data Warehousing in the real world, Adiós Wesley, Devlin, Data Warehouse from Architecture to Implementation, Addison Wesley, Booch, El lenguaje unificado de modelado, Addison Wesley, Oracle 9i, Warehouse Builder: Implementation, Volume 2: Student Guide,

102 91 6 Anexos 6.1 Diccionario de datos Sistema Fuente Tabla: Descripción TSRC_BODEGA Contiene la información de la bodega que se encuentra el producto Columna Tipo dato CP Default Descripción Codbodega Number Si Identificador único de la Bodega Nombrebodega varchar2(100) Contiene el nombre de la Bodega Direccion varchar2(100) La dirección donde se encuentra la Bodega Fechaproceso Date Fecha en que fue ingresado/ actualizado el registro Tabla: Descripción TSRC_CIUDAD Contiene información sobre las Ciudad Columna Tipo dato CP Default Descripción Codciudad Number Si Identificador único de la ciudad Nombreciud varchar2(100) Contiene el nombre de la ciudad Fecha en que fue ingresado/ Fechaproceso Date actualizado el registro

103 92 Tabla: Descripción TSRC_CLIENTE Contiene la información sobre el Cliente Columna Tipo dato CP Default Descripción Codcliente Number Si Identificador único del cliente Tipoid varchar2(1) Contiene el tipo de identificación de cliente como la cedula Identifica varchar2(20) Contiene el numero de identificación del cliente Nombre varchar2(100) Contiene los nombre del cliente Apellidos varchar2(100) Contiene los apellidos del cliente Codidioma Number Contiene el código de idioma y hace referencia a la tabla tsc_idioma Cupo Number El cupo máximo de crédito que va ha tener el cliente Estadociv varchar2(1) El estado civil del cliente Sexo varchar2(1) Describe el sexo del cliente Fechanac Date Contiene la fecha de nacimiento del cliente fechaproceso Date Contiene la fecha en que fue procesada la información

104 93 Tabla: Descripción TSRC_DETORDEN Contiene la información del detalle de la Factura Columna Tipo dato CP Default Descripción Codorden Number Si Identificador único del detalle de orden y hace referencia a la tabla tsrc_detorden Seqdetail Number Secuencia del detalle de orden Cantidad Number Número de artículos vendidos Preciouni Number Precio unitario del producto Codprod number Código del producto y hace referencia ha la tabla tsrc_producto fechaproceso date Fecha en que fue procesada la información

105 94 Tabla: Descripción TSRC_DIRECCION Contiene información sobre las Direcciones tanto de cliente, empleado y Proveedor de la empresa Columna Tipo dato CP Default Descripción coddireccion Number Si Identificador único de la dirección Tipodir Varchar2(1) El tipo de dirección como postal dirección Varchar2(200) Detalle de la dirección (calles y demás detalles) Codpostal Varchar2(20) Contiene el código postal Codciudad Number El código de ciudad y hace referencia a la tabla tsr_ciudad codprovincia Number El código de la provincia y hace referencia ha la tabla tsr_provincia codpais number El código del país y hace referencia a la tabla tsr_pais codcliente number El código del cliente y hace referencia a la tabla cliente codemp number Código del empleado. Hace referencia a la tabla empleados codproveedor number Código del empleado. Hace referencia a la tabla proveedores fechaproceso date fecha en que fue procesada la información

106 95 Tabla: Descripción TSRC_EMPLEADO Contiene información del Empledado Columna Tipo dato CP Default Descripción codemp number Si Identificador único del empleado Tipoid varchar2(1) Contiene el tipo de identificación del empleado como cédula identifica varchar2(20) Contiene la identificación del empleado nombres varchar2(100) Contiene los nombres del empleado apellidos varchar2(100) Contiene los apellidos del empleado e_mail varchar2(100) Contiene el correo electrónico del empleado telefono varchar2(100) Contiene el numero de teléfono del empleado Sexo varchar2(1) Indica el género del empleado estadociv varchar2(1) Describe el estado civil del empleado codescalafon number Contiene el código del escalafón y se relaciona con la tabla tsrc_escalafon Sueldo number Contiene el sueldo del empleado fechaingreso date Contiene la fecha de ingreso del empleado a la empresa fechanac date Contiene la fecha de nacimiento

107 96 del empleado dependiente number Contiene de quien depende el empleado es decir su jefe inmediato superior fechaproceso date Contiene la fecha en que fue procesada la información Tabla: Descripción TSRC_ESCALAFON Contiene el Escalafón de Funciones de la Empresa Columna Tipo dato CP Default Descripción codescalafon number Si Identificador único del escalafón Titulo varchar2(100) Contiene las profesiones salariomin number Contiene el salario mínimo por escalafón salariomax number Contiene el salario máximo por escalafón fechaproceso date Contiene la fecha en que fue procesada la información

108 97 Tabla: Descripción TSRC_IDIOMA Contiene la información de los Idiomas Columna Tipo dato CP Default Descripción codidioma Number Si Identificador único de idioma descripcion varchar2(100) Contiene la descripción o tipo de idioma fechaproceso Date Contiene la fecha en que fue procesada la información Tabla: Descripción TSRC_INVENTARIO Contiene información sobre el Inventario Columna Tipo dato CP Default Descripción codprod Number Si Identificador único del producto y hace referencia ha la tabla tsrc_producto codbodega number Identificador único del producto y hace referencia ha la tabla tsrc_bodega cantidad number La cantidad de productos que hay en inventario fechaproceso date Fecha en que fue procesada la información

109 98 Tabla: Descripción TSRC_ORDEN Contiene la información de la factura de venta Columna Tipo dato CP Default Descripción codorden number Si Identificador único del orden Fecha date Información de la fecha de emisión de la factura Status varchar2(1) El estatus que se encuentra la factura Total number Monto total de la venta codemp number Código del empleado y hace referencia a la tabla tsrc_empleado codcliente number Código del cliente y hace referencia a la tabla tsrc_cliente codprom number Código de la promoción y hace referencia a la tabla tsrc_promocion codproveedor number Código del proveedor y hace referencia ha la tabla tsrc_proveedor fechaproceso date Fecha en que fue procesada la información Codciu number Código de ciudad. Referencia a la tabla de ciudades

110 99 Tabla: Descripción TSRC_PAIS Contiene la información de los Países Columna Tipo dato CP Default Descripción codpais number Si Identificador único del país nombrepais varchar2(100) Contiene el nombre del país codzona Number Contiene el código de la zona geográfica que pertenece al país y se relaciona con la tabla tsrc_zonageo fechaproceso Date Contiene la fecha en que fue procesada la información

111 100 Tabla: Descripción TSRC_PRODUCTOS contiene la información de los Países Columna Tipo dato CP Default Descripción codprod Number Si Identificador único del producto nombreprod varchar2(100) El nombre del producto en forma completa nombrecorto varchar2(15) El nombre corto del producto Medida varchar2(10) La medida que va ha tener el producto Color varchar2(20) El color del producto Alto Number La altura del producto Ancho Number La anchura del producto Fondo Number El fondo del producto Status Number El estado del producto Costo Number Contiene el valor de costo del producto garantia Number La garantía que va ha tener el producto fechaproceso Date Fecha en que fue procesada la información

112 101 Tabla: Descripción TSRC_PROMOCION contiene la promociones que va ha ofrecer la Institución Columna Tipo dato CP Default Descripción codprom number Si Identificador único de la promoción promtipo number El tipo de promoción que se ofrece descripcion varchar2(100) La descripción de la promoción como es el nombre categoria varchar2(20) La categoría que tiene la promoción fechavigencia date La fecha en que entro en vigencia la promoción fechafinal date La fecha en que termina la promoción o caduca fechaproceso date Fecha de ingreso o actualización del registro Tabla: Descripción TSRC_PROVEEDOR Contiene información sobre los proveedor de la Empresa Columna Tipo dato CP Default Descripción codproveedor number SI Identificador único del proveedor nombreprovee varchar2(200) Contiene el nombre del proveedor fechaproceso date Fecha en que fue procesada la información

113 102 Tabla: Descripción TSRC_PROVINCIA Contiene información sobre las Provincias Columna Tipo dato CP Default Descripción codprovincia number Si Identificador único de provincia nombreprov varchar2(100) Nombre de la provincial fechaproceso date Fecha en que fue procesada la información Tabla: Descripción TSRC_ZONAGEO contiene la información de las Zonas Geográficas Columna Tipo dato CP Default Descripción codzona number Si Identificador único de la zona geográfica descripcion varchar2(100) Contiene el nombre o la descripción de la zona geográfica zonaref Number Contiene la información de las zona geográfica que hace referencia fechaproceso Date Contiene la fecha en que fue procesada la información

114 Diccionario de datos del área de recolección Tabla: Descripción TSTG_CIUDAD Tabla de integración, Contiene información sobre las Ciudad. Repositorio temporal, sin foreign key. Columna Tipo dato CP Default Descripción Codciudad Number Identificador único de la ciudad Nombreciud varchar2(100) Contiene el nombre de la ciudad fechacarga Date Fecha en que fue procesada la información Tabla: Descripción TSTG_PAIS Tabla de integración, Contiene la información de los Países. Repositorio temporal, sin foreign key. Columna Tipo dato CP Default Descripción codpais Number Identificador único del país nombrepais Varchar2(100) Contiene el nombre del país codzona Number Contiene el código de la zona geográfica que pertenece al país y se relaciona con la tabla TSTG_zonageo fechacarga Date Contiene la fecha en que fue procesada la información

115 104 Tabla: Descripción TSTG_CLIENTE Tabla de integración, Contiene la información sobre el Cliente. Repositorio temporal, sin foreign key. Columna Tipo dato CP Default Descripción codcliente number Identificador único del cliente Tipoid varchar2(1) Contiene el tipo de identificación de cliente como la cedula identifica varchar2(20) Contiene el numero de identificación del cliente nombre varchar2(100) Contiene los nombre del cliente apellidos varchar2(100) Contiene los apellidos del cliente codidioma Number Contiene el código de idioma y hace referencia ha la tabla tsc_idioma Cupo Number El cupo máximo de crédito que va ha tener el cliente estadociv varchar2(1) El estado civil del cliente Sexo varchar2(1) Describe el sexo del cliente fechanac Date Contiene la fecha de nacimiento del cliente fechacarga Date Contiene la fecha en que fue procesada la información

116 105 Tabla: Descripción TSTG_DIRECCION Tabla de integración, Contiene información sobre las Direcciones tanto de cliente, empleado y Proveedor de la empresa. Repositorio temporal, sin foreign key. Columna Tipo dato CP Default Descripción coddireccion Number Identificador único de la dirección Tipodir varchar2(1) El tipo de dirección como postal dirección varchar2(200) Dirección (Calle, número de casa, etc) codpostal varchar2(20) Contiene el código postal codciudad Number El código de ciudad y hace referencia a la tabla tsr_ciudad codprovincia Number El código de la provincia y hace referencia ha la tabla tsr_provincia codpais Number El código del país y hace referencia a la tabla tsr_pais codcliente Number El código del cliente y hace referencia a la tabla cliente codemp Number El código del empleado y hace referencia a la tabla empleados codproveedor Number fechacarga Date Fecha en que fue procesada la información

117 106 Tabla: Descripción TSTG_EMPLEADO Tabla de integración, Contiene información del Empleado. Repositorio temporal, sin foreign key. Columna Tipo dato CP Default Descripción codemp number Identificador único del empleado Tipoid varchar2(1) Contiene el tipo de identificación del empleado como cédula identifica varchar2(20) Contiene la identificación del empleado nombres varchar2(100) Contiene los nombres del empleado apellidos varchar2(100) Contiene los apellidos del empleado e_mail varchar2(100) Contiene el correo electrónico del empleado teléfono varchar2(100) Contiene el numero de teléfono del empleado Sexo varchar2(1) Describe el sexo del empleado estadociv varchar2(1) Describe el estado civil del empleado codescalafon Number Contiene el código del escalafón y se relaciona con la tabla TSTG_escalafon Sueldo Number Contiene el sueldo del empleado fechaingreso Date Contiene la fecha de ingreso del empleado a la empresa

118 107 fechanac date Contiene la fecha de nacimiento del empleado dependiente number Contiene de quien depende el empleado es decir su jefe inmediato superior fechacarga date Contiene la fecha en que fue procesada la información

119 108 Tabla: Descripción TSTG_ORDEN Tabla de integración, Tabla de integración, Contiene la información de la factura de venta. Repositorio temporal, sin foreign key. Columna Tipo dato CP Default Descripción codorden number Identificador único del orden Fecha date Información de la fecha de emisión de la factura Status varchar2(1) El estatus que se encuentra la factura Total number codemp number Código del empleado y hace referencia a la tabla TSTG_empleado codcliente number Código del cliente y hace referencia a la tabla TSTG_cliente codprom number Código de la promoción y hace referencia a la tabla TSTG_promocion codproveedor number Código del proveedor y hace referencia ha la tabla TSTG_proveedor fechacarga date Fecha en que fue procesada la información Codciu number

120 109 Tabla: TSTG_DETORDEN Tabla de integración, Contiene la Informacion el detalle de la Factura. Descripción Repositorio temporal, sin foreign key. Columna Tipo dato CP Default Descripción codorden number Identificador único del detalle de orden y hace referencia ha la tabla TSTG_detorden seqdetail number Secuencia del detalle de orden cantidad number Número de productos preciouni number Precio unitario del producto codprod number Código del producto y hace referencia ha la tabla tstg_producto fechacarga date Fecha en que fue procesada la informacion

121 110 Tabla: Descripción TSTG_PRODUCTOS Tabla de integración, contiene la información de los Países. Repositorio temporal, sin foreign key. Columna Tipo dato CP Default Descripción codprod number Identificador único del producto nombreprod varchar2(100) El nombre del producto en forma completa nombrecorto varchar2(15) El nombre corto del producto medida varchar2(10) La medida que va ha tener el producto Color varchar2(20) El color del producto Alto number La altura del producto Ancho number La anchura del producto Fondo number El fondo del producto Status number El estado del producto Costo number garantia number La garantía que va ha tener el producto fechacarga date Fecha en que fue procesada la información

122 Diccionario de datos del Data Mart Tabla: T_DIMPRODUCTOS Contiene el catalogo de productos que la empresa dispone para la Descripción venta Columna Tipo dato CP Default Descripción Identificador único del producto en Codproducto Number(3) Si la tabla dimensión de productos Producto Nomcorto Varchar2(30) Varchar2(10) Contiene la información o nombre del producto Contiene el nombre corto del producto Color Varchar2(20) Contiene información sobre el color de producto Medida Varchar2(10) Información sobre las medidas del producto Fechacarga DATE si Fecha de caraga de los datos

123 112 Tabla: Descripción T_DIMEMPLEADO Contiene la información del empleado Columna Tipo dato CP Default Descripción Codemp Number Si identificador único del empleado Tipoid Varchar2(1) El tipo de identificación, tal como la cedula de identidad Identifica Varchar2(20) El numero de la identificación Nombres Varchar2(200) Contiene los nombres del empleado e_mail Varchar2(100) Contiene el mail del empleado teléfono Varchar2(100) Información del teléfono del empleado Sexo Varchar2(15) Descripción del sexo del empleado estadociv Varchar2(20) Información del estado civil del empleado Sueldo Number Información sobre el sueldo del empelado Fechaingreso Date Información sobre la fecha que el empleado entro ha la empresa Fechanac Date Información sobre la fecha de nacimiento del empleado Dependiente Number Información sobre el numero de dependientes Fechacarga Date si Fecha de carga de los datos

124 113 Tabla: Descripción T_DIMFECHA Contiene la información de la fecha de ventas Columna Tipo dato CP Default Descripción Fecha Date Si Contiene información de la fecha semana Number Contiene información de la semana Mes Number Contiene información del mes bimestre Number Contiene la información bimestral trimestre Number Contiene la información Trimestral semestre Number Contiene la información Semestral Anio Number Contiene la información del Año

125 114 Tabla: Descripción T_DIMCLIENTE Contiene la información de dimensiones de clientes Columna Tipo dato CP Default Descripción Codcliente number Si Código interno del cliente TipoId Varchar2(1) Tipo de identificación Identifica Varchar2(20) Número de identificación Nombre Varchar2(200) Nombres y apellidos CodPais Varchar2(10) Código iso del país Pais Varchar2(100) Nombre del pais CodCiud Varchar2(10) Código Iso de la ciudad Ciudad Varchar2(100) Nombre de la ciudad Cupo Number Cupo asignado de compra EstadoViv Varchar2(20) Descripción del estado civil Sexo Varchar2(15) Descripción del género Fechacarga Date Fecha de carga de datos

126 115 Tabla: Descripción T_FACTVENTAS Contiene la información del total de ventas de los productos Columna Tipo dato CP Default Descripción fechacarga Date Contiene la fecha que fue procesada la información. codprod Number Código de identificador del producto Codcliente Number Código de identificador del producto Codpromocion Number Código de identificador de la promoción Cantidad Number Contiene la cantidad de productos vendidos Montoventa Number Contiene el monto de ventas Codciud Varchar2(10) Código identificador de ciudad Ciudad Varchar2(30) Nombre de la ciudad de las ventas Codorden Number Identificador único de la orden de facturación Codemp Number Identificador único del empleado

127 Manual de usuario Extracción, Carga y transformación 1. Hacer clic en botón inicio de windows, seguidamente hacer clic en programas, luego en Oracle client y finalmente en y finalmente sql-plus 2. Ingresar el nombre de usuario, la clave y la conexión a la base de datos: Login: tesis_staging Clave:latino Host string: latino9i 3. En el prompt de sql-plus ejecutar el script de extracción con la siguiente instrucción siguiente: 4. Posteriomente ejecutar el script: Reportes y consultas 1. Hacer clic en botón inicio de windows, seguidamente hacer clic en programas, luego en Oracle9i Developer Suite y finalmente en y finalmente Discoverer Desktop

128 Se desplegará la pantalla siguiente En ella se debe ingresar el usuario, contraseña y string de conexión a la base de datos donde se encuenta el catálogo definido por el Oracle Discoverer Administrador 3. Posteriormente en la pantalla siguiente pulsar Open an existing workbook

129 Seguidamente seleccionar My computer para elegir el reporte grabado en el disco duro del computador o en el drive donde se encuentre el archivo Reporte_ventas.dis 5. Una vez seleccionado el reporte, se desplegará en pantalla la información correspondiente de ventas de productos por fechas. El formato de la pantalla de consulta y el reporte se muestra en el acápite Despliegue de resultados