Universidad de Cuenca

Transcripción

1 RESUMEN El sistema a desarrollar se enmarca en una arquitectura de Data Warehouse, cuyo objetivo es extraer información de los Sistemas Transaccionales disponibles en Etapatelecom para ser usada en una Base de Datos orientada a la toma de decisiones (Data Warehouse) para el Área Comercial de la Empresa. El procedimiento se inicia con un análisis de los requerimientos de los usuarios estratégicos del Área Comercial de Etapatelecom donde se identifican los indicadores de negocio (Medidas) y las Dimensiones a través de las cuales van a ser analizados los indicadores de negocio, para luego proceder a realizar un diseño de un modelo conceptual y lógico que satisfaga los requerimientos analizados en el inicio del proceso. En este punto se inicia la implementación del esquema a ser utilizado definiendo las Dimensiones, Medidas y Hechos (estos últimos utilizados para realizar el cálculo de las Medidas), así como sus respectivas tablas de las bases de datos, y los procesos ETL (Extracción, Transformación y Carga, por sus siglas en Inglés) en donde se realiza una Ing. Roberto Vélez I. 1

2 verificación y corrección de la información a ser utilizada de manera que se disponga de un repositorio de información único, confiable y libre de errores. El desarrollo e implementación de este proyecto será realizado utilizando GeneXus, que es la plataforma de desarrollo adoptada por Etapatelecom. Ing. Roberto Vélez I. 2

3 Tabla de contenido Capítulo 1: Introducción Antecedentes Determinación de la necesidad a ser satisfecha Justificación del Proyecto de Tesis Objetivos Capítulo 2: Marco Teórico Sistemas de Procesamiento de Transacciones en Línea (OLTP) Sistemas de Inteligencia de Negocios Qué es un Data Warehouse Qué es un Data Mart Que es un ODS Formas Comunes Para Su Diseño e Implementación Herramientas a utilizar Capítulo 3: Delineación del Proyecto Alcance del Proyecto Entorno al cual se Integra la Solución Capítulo 4: Análisis Previo de la Estructura de la Información Comercial Objetivos del Análisis Identificación y Selección de Requerimientos Identificación de Fuentes de Datos Evaluación de Calidad de Fuentes de Datos Evaluación de las Condiciones de Excepción Capítulo 5: Diseño del Componente Comercial de las bases DSS Ing. Roberto Vélez I. 3

4 Estructura Sugerencias y Requerimientos al Sistema Transaccional 113 Diseño de Procesos ETL Capítulo 6: Implementación (Con GeneXus) Conceptos y Terminología Manejada por GeneXus Vistas a datos OLTP Estructura de Base de Datos Procesos ETL y pruebas Work Panels Publicación de la Metadata Acceso con Herramientas de Usuario Final (GXplorer) Capítulo 7: Conclusiones y Recomendaciones Resultados Finales Conclusiones y Recomendaciones Bibliografía y Fuentes de Información Índice de Gráficos Glosario de Términos y Abreviaturas Anexos Anexo 01 Modelo Conceptual para los procesos ETL Anexo 02 Método de Trabajo GeneXus Ing. Roberto Vélez I. 4

5 UNIVERSIDAD DE CUENCA FACULTAD DE INGENIERÍA MAESTRIA EN TELEMÁTICA IMPLEMENTACIÓN DE UN PILOTO DEL COMPONENTE COMERCIAL DEL DATA WAREHOUSE DE ETAPATELECOM Proyecto de Graduación previo a la Obtención del Título de MAGÍSTER EN TELEMÁTICA AUTOR: Ing. Roberto José Vélez Iñiguez DIRECTOR: Ing. Lucía Méndez Tapia MAYO, 2008 CUENCA - ECUADOR Ing. Roberto Vélez I. 5

6 CERTIFICACIÓN ING. LUCÍA MÉNDEZ TAPIA, CATEDRÁTICO DE LA UNIVERSIDAD DE CUENCA, DIRECTOR DE LA TESIS DE MAESTRÍA EN TELEMÁTICA. CERTIFICA: Que la presente tesis ha sido realizada por el Ing. Roberto José Vélez Iñiguez, además de haber sido dirigida, orientada y revisada, observando las disposiciones emanadas por las autoridades de la Universidad de Cuenca, a través de la Facultad de Ingeniería y la Maestría en Telemática, considerando también las normas que la Metodología de la Investigación Científica sugiere.... Ing. Lucía Méndez Tapia Ing. Roberto Vélez I. 6

7 AGRADECIMIENTO Quisiera agradecer a mi Directora de Tesis, Ing. Lucía Méndez Tapia, quien me guió durante todo el proceso de investigación y desarrollo de este proyecto, así como también al Personal de Etapatelecom S. A. por su apoyo e invalorables aportes a este trabajo. Finalmente y de manera muy especial, agradezco a Dios, a mi esposa, mis hijas y a mis padres, que han sido la guía constante en mi vida y que siempre me han brindado el apoyo incondicional para alcanzar mis metas con éxito. Ing. Roberto Vélez I. 7

8 DEDICATORIA Universidad de Cuenca A mi esposa e hijas, quienes estuvieron contantemente a mi lado siendo mi inspiración y fortaleza, quienes con su apoyo incondicional y sacrificio constante colaboraron con la finalización y éxito del presente proyecto. Ing. Roberto Vélez I. 8

9 AUTORÍA Universidad de Cuenca El contenido del presente proyecto de tesis es de absoluta responsabilidad de su autor, Ing. Roberto Vélez Iñiguez ING: ROBERTO VÉLEZ I. Ing. Roberto Vélez I. 9

10 ABSTRACT The System to be developed is based in a Data Warehouse architecture, where it s main objective is to Extract information from the Transactional Systems available at Etapatelecom to be used in a Decision Take oriented Data Base (Data Warehouse) for the Commercial Area of the Organization. The process begins with an analysis of the requirements of the strategic users of the Commercial Area of Etapatelecom, where the Business Indicators (Measures) and the Dimensions, thru which the Business Indicators will be evaluated, are identified, then we ll proceed to the design of an conceptual and logic model that satisfies the requirements analyzed during the beginning of this process. At this point, the schema implementation begins with the definition of the Dimension, Measure and Fact Tables (to be used for the information process and load into the Measure Tables, and also the definition of the Data Base Tables and the ETL (Extraction, Transformation and Load) processes that perform a verification and correction of the information to be Ing. Roberto Vélez I. 10

11 used with the purpose to have a Unique, reliable and error Free information repository. The development and implementation of this project will be done using GeneXus, which is the development platform adopted by Etapatelecom Ing. Roberto Vélez I. 11

12 Capítulo 1: Introducción Antecedentes En la actualidad, Etapatelecom S.A., a través de su Subgerencia de Informática, se encuentra desarrollando un proyecto para la implementación de un Data Warehouse Empresarial, cuyo avance hasta el momento incluye el desarrollo de los siguientes componentes: Regulación - Técnico: permite la generación de informes periódicos solicitados por el ente regulador, en el monitoreo de la prestación de los servicios de Telefonía Fija y Pública, Valor Agregado y Portadores. Financiero: fuente de consulta y generación de reportes en temas de facturación, cartera, recaudación. Call-Center: incorpora la temática de atención telefónica a los clientes Dentro de un ambiente dinámico como es el de las Telecomunicaciones, el área comercial desempeña un papel fundamental dentro de la Empresa como es el de definir las estrategias de ventas y comercialización de los productos de una manera eficiente y oportuna, y justamente el objetivo final Ing. Roberto Vélez I. 12

13 de este proyecto es el de implementar una herramienta que permita realizar un análisis estratégico para la toma de decisiones. El objeto de este proyecto de tesis de grado es el de implementar un piloto del componente comercial de Data Warehouse de Etapatelecom, se ha escogido esta área debido a su rol tan importante, ya que es el área que se encarga de generar los ingresos para la Empresa. Determinación de la necesidad a ser satisfecha El área Comercial de Etapatelecom S.A. en la actualidad no cuenta con una herramienta de análisis y toma de decisiones que le permita consolidar y administrar datos de distintos orígenes, obtener una visión única de la información del negocio, y definir o certificar determinados comportamientos estratégicos que lleven a lograr un mejor posicionamiento de la Empresa en el mercado. Con el desarrollo evolutivo de aplicaciones y sistemas de tipo transaccional, surgen varios aspectos que generan problemas e inconvenientes a la hora de realizar un análisis para la toma estratégica de decisiones, orientadas y alineadas con la Ing. Roberto Vélez I. 13

14 estrategia de negocio definida para la Empresa. Estos problemas se relacionan principalmente con: Credibilidad de los Datos Los diferentes departamentos de la Empresa realizan análisis y preparan informes a partir de los datos que generan los sistemas transaccionales disponibles, pero muchas veces ocurre que llegan informes de distintas áreas sobre un mismo tema con información y resultados diferentes. Esta situación provoca que las decisiones que se toman sobre la información disponible no sea la óptima ni la más adecuada, pudiendo inclusive afectar de una manera negativa a la consecución de las metas planteadas. Las principales razones para que esto se produzca son: No se cuenta con una base histórica común para los datos. Utilización de algoritmos diferentes para manejar los datos con un mismo objetivo. Niveles distintos de extracción de los datos. No hay una fuente integrada y validada de los datos. La productividad Ing. Roberto Vélez I. 14

15 Es un punto muy importante a tener en cuenta, especialmente en organizaciones como la nuestra que poseen datos con historicidad. Cuando surge la necesidad de generar un informe corporativo utilizando muchos almacenamientos y datos que la organización ha acumulado a través de los años, el proceso de extracción debe: Localizar y analizar los datos a incluir en el informe Buscar fuentes alternativas para datos faltantes Consolidar los datos para el informe Destinar recursos de programación y análisis para la tarea Validar la información integrada Distribuir el informe Aspectos adicionales a considerar durante la extracción: Existe un nivel de incapacidad para transformar datos en información Los sistemas transaccionales no fueron construidos pensando en la integración de sus datos para la toma de decisiones, sino con el fin de satisfacer necesidades netamente operativas. Ing. Roberto Vélez I. 15

16 En determinados casos, la historicidad de los datos en línea no alcanza para satisfacer los requerimientos de información del usuario final. El usuario final demanda flexibilidad en las condiciones de presentación de los informes. Para resolver los distintos problemas mencionados, las organizaciones necesitan implementar un cambio de arquitectura de sus sistemas de decisión, y es aquí donde juega un papel muy importante el Data Warehouse. El Data Warehouse suple las incapacidades que poseen los sistemas transaccionales en la prestación de funcionalidades estratégicas, gestionando datos que poseen las siguientes características: Orientados a la toma de decisiones Consolidados No volátiles, no hay bajas ni modificaciones substanciales Gran historicidad Justificación del Proyecto de Tesis Existen varias razones que justifican la creación del componente comercial del Data Warehouse para obtener la Ing. Roberto Vélez I. 16

17 información necesaria en los procesos de gestión Comercial, en lugar de obtener esa información directamente de las bases de datos de las aplicaciones operacionales: Rendimiento: se tarda mucho menos en acceder a los datos de los repositorios del Data Warehouse que en hacer una consulta a varias bases de datos distintas. Además, el ejecutar consultas complejas a las bases de datos de los sistemas operacionales suele degradar el tiempo de respuesta de estos sistemas para otros usuarios, interfiriendo la operación normal. Múltiples orígenes de datos: combinar los datos de distintas fuentes suele ser una tarea bastante complicada para las personas encargadas de tomar decisiones con esa información. Normalmente hay que homogenizar los datos de una forma u otra. Por ejemplo, es probable que no se utilicen los mismos criterios de almacenamiento (nombres de las entidades, atributos considerados, tipos etc.) en las bases de datos de distintos departamentos. Sin embargo, en el Data Warehouse los datos se homogenizan durante el proceso de carga. Ing. Roberto Vélez I. 17

18 Limpieza de los datos: las Empresas no siempre cuentan con aplicaciones homogéneas para cada parte de la operación del negocio, sino que pueden poseer replicaciones y distintos sistemas para atender un mismo conjunto de operaciones, y en esos caso es probable que las bases de datos de los sistemas operacionales contengan datos duplicados, a veces erróneos, superfluos o incompletos. Estos datos se corrigen durante el proceso de carga al Data Warehouse. Ajustes: en ocasiones se hace necesario un ajuste de los datos para posibles comparaciones. Por ejemplo si se está combinando información financiera de distintas fuentes habrá que ajustar toda esta información conforme a una única norma contable para hacerla comparable. Esos ajustes ya se realizan en el Data Warehouse durante el proceso de carga mencionado. Periodicidad: La periodicidad de los datos en las distintas bases de datos puede ser distinta diaria, semanal, mensual etc. Como en los casos anteriores para posibles comparaciones es necesaria la homogeneización ya realizada en el Data Warehouse. Ing. Roberto Vélez I. 18

19 Datos históricos: Los datos históricos suelen permanecer con alta disponibilidad en los sistemas operacionales, pero son un elemento esencial de cualquier análisis estratégico. El Data Warehouse es el lugar adecuado para estos datos. Datos agregados: Muchas veces para tomar decisiones, no es necesario entrar en la línea de más nivel de detalle durante el análisis. En este sentido, en el Data Warehouse se suelen guardar sólo los agregados necesarios (por ejemplo el importe total de ventas trimestralmente en cada punto de venta). Por tanto, la plataforma Data Warehouse lejos de ser un punto final en la cadena de automatización de la actividad y gestión del conocimiento de la organización, se ha convertido en la puerta hacia una nueva dimensión en la concepción de las corporaciones. El Data Warehouse junto con una nueva serie de herramientas, permiten no sólo el análisis de la información, sino también, y esto es lo realmente importante y diferencial, el planteamiento y descubrimiento automático de hechos e Ing. Roberto Vélez I. 19

20 hipótesis (patrones, reglas, grupos, funciones, modelos, secuencias, relaciones, correlaciones...) que pueden desembocar: En importantes descubrimientos para la gestión comercial de información y/o conocimiento no visibles a partir de los grandes volúmenes de datos almacenados en las bases de datos de los sistemas operacionales de las corporaciones. En un aumento de la eficacia y productividad para las Empresas en el terreno comercial. Objetivos Objetivos generales Con el desarrollo de este proyecto de Tesis, se buscan los siguientes objetivos generales: Desarrollar una solución informática para satisfacer las necesidades de análisis estratégico-táctico de información que tiene al momento la Gerencia Comercial de Etapatelecom, integrándola (la solución) al sistema de Soporte a la Toma de Decisiones. Crear una fuente de información de datos históricos para el Área Comercial de Etapatelecom, asociados con los usuarios que manejan los productos comercializados por Etapatelecom; no se incluirá información sobre productos Ing. Roberto Vélez I. 20

21 que no son de propiedad de la Empresa como es el caso de Telefonía Móvil y Etapanet. Objetivos específicos Implementar una herramienta piloto que permita a los usuarios del área Comercial de Etapatelecom acceder a información de calidad presentada coherentemente como una fuente única, confiable y disponible incorporada al Data Warehouse, que permita a sus usuarios estratégicos: o Conocer el estado de la gestión del área Comercial en el momento que se necesite, y con diferentes niveles de detalle o Obtener Información Estratégica bajo demanda y por autoservicio de los usuarios estratégicos. o Seleccionar la información deseada para la generación de reportes personalizados o Realizar evaluación de resultados de la gestión comercial con base en la información disponible en una fuente única Crear una fuente de información de datos históricos para: o Mantener la información relevante para la toma de decisiones en un solo lugar y por el tiempo necesario Ing. Roberto Vélez I. 21

22 o Descubrir patrones a partir de la información almacenada en el Data Warehouse o Identificar, medir y controlar factores críticos del negocio Ing. Roberto Vélez I. 22

23 Capítulo 2: Marco Teórico Sistemas de Procesamiento de Transacciones en Línea (OLTP) Los sistemas OLTP de Etapatelecom manejan Datos operativos / sistemas transaccionales. Los datos operativos son los que los que la organización maneja en su operatoria diaria. Estos datos se almacenan, se consultan y se actualizan por medio de los sistemas transaccionales. Ejemplos de sistemas transaccionales son: un sistema de manejo de cuentas corrientes, un sistema de toma de pedidos, un sistema de facturación. Cuando se toman datos de los sistemas transaccionales para colocar en el Data Warehouse, los datos pasan por operaciones tales como: Consolidación a diferentes niveles Denormalización y replicación para acelerar las consultas (ya que al no haber actualizaciones la redundancia no es perjudicial) Incorporación regular de nuevos datos al Data Warehouse desde los sistemas transaccionales Ing. Roberto Vélez I. 23

24 Reestructuración para adaptarse al uso por parte de los sistemas de soporte a las decisiones Sistemas de Inteligencia de Negocios Para poder acercarse al tema, se necesita establecer claramente los objetivos y fines que se persiguen con la construcción y la puesta en marcha, no solo de los Data Marts sino del Data Warehouse, de la cual es necesario mencionar que no es un producto construido con estándares que se puede aplicar indistintamente del tipo de Empresa que desea adquirirlo a través de una suma de dinero, sino más bien consiste en un proceso que debe ser obligatoriamente construido, evolutivo y duradero en el tiempo para que la Empresa pueda obtener los resultados o metas que se propuso con su implementación. Unido al trabajo que se pretende alcanzar con el Data Warehouse, debe mencionarse que los Data Marts son bodegas de datos con información de interés particular para un determinado sector de la Empresa y aunque su enfoque sea para una sola perspectiva departamental, esto no lo exime de tener que seguir los lineamientos generales de implementación que posee el Data Warehouse; éstos son: Recolección y análisis de requerimientos. Ing. Roberto Vélez I. 24

25 Creación del modelo de datos y su diseño físico. Definición de los orígenes de los datos. Selección de la tecnología de base de datos y hardware a utilizar. Extracción de los datos desde sistemas operacionales, su limpieza, transformación y carga al Data Warehouse. Selección de las formas de acceso, herramientas de análisis, reporte y presentación. Desarrollo de los reportes y aplicaciones necesarias. Actualización del componente del Data Warehouse. En el ambiente en que se desenvuelven hoy en día los negocios, entender y administrar la información de la Empresa es vital para tomar decisiones a tiempo y responder a las condiciones siempre cambiantes del negocio. Muchas organizaciones están obteniendo ventajas competitivas a través del uso de uno de sus activos más valiosos: la información. Los sistemas transaccionales, que manejan las operaciones diarias de la organización, generan enormes cantidades de datos. Los estudios indican que esa cantidad se duplica cada cinco años. La Inteligencia de Negocios (Business Ing. Roberto Vélez I. 25

26 Intelligence, BI) surge como una herramienta poderosa para convertir esa montaña de datos a menudo proveniente de almacenamientos no dinámicos y aislados en información significativa útil para formular mejores pronósticos y tomar mejores decisiones. BI implica el uso de herramientas de hardware y software para administrar de manera provechosa grandes cantidades de datos en diferentes grados de consolidación. Estas herramientas permiten recolectar, consultar, analizar y presentar la información en el nivel adecuado. Pieza fundamental de la implementación de BI es la construcción de bases de datos separadas de los sistemas transaccionales. Estas base de datos se integran jerárquicamente en ODSs (almacenamientos de datos operacionales, en sus versiones de Replicación y de Análisis), y Data Warehouse. En conjunto, reciben el nombre de Bases de Datos de Soporte a la Toma de Decisiones (DSS) Conceptos básicos de Business Intelligence Data Marts Ing. Roberto Vélez I. 26

27 Hemos dicho que un Data Warehouse contiene los datos de toda la organización. Un Data Mart es una estructura análoga a un Data Warehouse pero cuyo alcance es un grupo de trabajo, una temática, un macro-proceso, o en las primeras fases de integración, un departamento. Hay dos tipos de Data Marts: Data Marts dependientes, que contienen información que proviene del Data Warehouse. Este Data Mart contiene la información del Data Warehouse que es relevante para el grupo de usuarios al que va dirigido. Data Marts independientes, que se generan volcando información proveniente de los Sistemas Transaccionales. El trabajo de generar un Data Mart independiente es análogo al de un Data Warehouse, excepto a la fuente de donde proviene. Cuando se implementan varios Data Marts independientes, una buena pauta de diseño es hacer que las dimensiones que ellos comparten se definan de la misma manera. Esta técnica, denominada "dimensiones conformes" permite combinar información de dos o más Data Marts y permite disponer de la Ing. Roberto Vélez I. 27

28 información que contendría un Data Warehouse, sólo que la implementación es más gradual y se dispone más pronto de resultados. Análisis Multidimensional/OLAP Las bases de datos relacionales almacenan los datos en un formato bidimensional: tablas con filas y columnas. Los sistemas de análisis multidimensional (llamadas soluciones OLAP) ofrecen una extensión al modelo relacional para brindar una visión multidimensional de los datos. Por ejemplo, si hablamos de entidades tales como sucursales, productos, períodos de tiempo, canales de ventas, promociones, estas entidades contribuyen a dar sentido a datos como importes de ventas, cantidad de unidades o costos. Un número aislado (p. Ej. 43) no dice mucho, pero sí lo dice si esta es la cantidad de unidades de un cierto producto vendido en una cierta sucursal en un cierto período por un cierto canal de ventas bajo una cierta promoción. Una solución multidimensional permite: Analizar grandes cantidades de datos con tiempos de respuesta casi inmediata. Ing. Roberto Vélez I. 28

29 Elegir ciertas dimensiones para ver los datos, consolidando las demás. Esto permite realizar cruces entre dimensiones. Cambiar el nivel de detalle con que se ven los datos: drill down para obtener mayor detalle (por ejemplo pasar de datos por trimestre a datos por mes) y drill up para menor detalle (consolidar datos sobre productos individuales en totales por tipo de producto). Identificar rápidamente tendencias o áreas problemáticas que de otra forma hubieran pasado inadvertidas. La definición de estructuras de datos multidimensionales se hace a través de un esquema "estrella", donde hay una tabla de hechos (datos numéricos que se pueden consolidar de diferentes formas) y tablas de dimensiones, donde cada tabla contiene los atributos de una dimensión. Este esquema se puede implementar a través de una extensión de los motores de bases de datos relacionales (lo que se denomina ROLAP, o sea OLAP Relacional) o a través de una estructura especial llamada MOLAP (OLAP Multidimensional). Ing. Roberto Vélez I. 29

30 Qué es un Data Warehouse Un Data Warehouse (literalmente "depósito de datos") es una base de datos separada de los sistemas transaccionales para evitar que el análisis de datos interfiera con la eficiencia de éstos. El Data Warehouse tiene ciertas propiedades que lo hacen adecuado para el análisis de datos: Está orientada a un proceso de negocios: Todos los datos relevantes acerca de ese proceso de negocios se recolectan y se guardan en un formato apto para el uso por los analistas de negocios. Es integrada: Los datos provenientes de fuentes heterogéneas de estructura disímil se almacenan en el Data Warehouse compatibilizando nomenclaturas, formatos, codificaciones, y asegurando la coherencia, la exactitud y la completitud de la información. Es no volátil: Los datos una vez almacenados en el Data Warehouse no se modifican (eventualmente se borran y se vuelven a cargar). Periódicamente el Data Warehouse se renueva, es decir, se incorpora nueva información. La frecuencia con que se realizan estas renovaciones depende Ing. Roberto Vélez I. 30

31 de la naturaleza de la información y del uso que hagan de ella los analistas de negocios. Es variable en el tiempo: El horizonte temporal del Data Warehouse es mayor que el de los sistemas transaccionales, ya que disponer de datos históricos permite analizar variaciones, tendencias y efectuar comparaciones de distinto tipo que ayudan en la toma de decisiones. Estructura del Data Warehouse Los Data Warehouse tienen una estructura distinta. Hay niveles diferentes de esquematización y detalle que delimitan el Data Warehouse. La estructura general de un Data Warehouse se muestra en la Figura 2.1. Detalle de datos actuales En gran parte, el interés más importante radica en el detalle de los datos actuales, debido a que: Refleja las ocurrencias más recientes, las cuales son de gran interés Es voluminoso, ya que se almacena al más bajo nivel de granularidad. Ing. Roberto Vélez I. 31

32 Casi siempre se almacena en disco, el cual es de fácil acceso, aunque su administración sea costosa y compleja. Detalle de datos antiguos La información antigua es aquella que se almacena sobre alguna forma de almacenamiento masivo. No es frecuente su acceso y se almacena a un nivel de detalle, consistente con los datos detallados actuales. Mientras no sea prioritario el almacenamiento en un medio de almacenaje alterno, a causa del gran volumen de datos unido al acceso no frecuente de los mismos, es poco usual utilizar el disco como medio de almacenamiento. Datos ligeramente resumidos La información ligeramente resumida es aquella que proviene desde un bajo nivel de detalle encontrado al nivel de detalle actual. Este nivel del Data Warehouse casi siempre se almacena en disco. Los puntos en los que se basa el diseñador para construirlo son: Ing. Roberto Vélez I. 32

33 Que la unidad de tiempo se encuentre sobre la esquematización hecha. Qué contenidos (atributos) tendrá la información ligeramente resumida. Altamente Resumido Ligeramente Resumido METADATA Detalle Actual de Datos Detalle Histórico de Datos Figura 2.1. Estructura de datos en un Data Warehouse A veces se encuentra en el ambiente de Data Warehouse y en otros, fuera del límite de la tecnología que ampara al Data Warehouse. Metadatos Ing. Roberto Vélez I. 33

34 Los metadatos juegan un rol especial y muy importante en el Data Warehouse y son usados como: Un directorio para ayudar al analista a ubicar los contenidos del Data Warehouse. Una guía para la trazabilidad de los datos, de cómo se transforma, desde el ambiente operacional hacia el del Data Warehouse. Una guía de los algoritmos usados para la esquematización entre el detalle de datos actual, con los datos ligeramente resumidos y éstos, con los datos completamente resumidos, etc. Los metadatos juegan un papel mucho más importante en un ambiente Data Warehousing que en un operacional clásico. Otro paso necesario es crear los metadatos que describen los contenidos del Data Warehouse. Los metadatos consisten de definiciones de los elementos de datos en el depósito, sistemas de los elementos fuente. Como la información, se integra y transforma antes de ser almacenada en información similar. Ing. Roberto Vélez I. 34

35 Otro aspecto de la arquitectura de Data Warehouse es crear soporte a metadatos que es la información sobre los datos que se alimenta, se transforma y existe en el Data Warehouse. Típicamente, los metadatos incluyen los siguientes ítems: Las estructuras de datos que dan una visión de los datos al administrador de datos. Las definiciones del sistema de registro desde el cual se construye el Data Warehouse. Las especificaciones de transformaciones de datos que ocurren tal como la fuente de datos se replica al Data Warehouse. Algunas implementaciones de metadatos también incluyen definiciones de las vistas presentadas a los usuarios del Data Warehouse. Típicamente, se definen vistas múltiples para favorecer las preferencias variadas de diversos grupos de usuarios. En otras implementaciones, estas descripciones se almacenan en un Catálogo de Información. Los esquemas y subesquemas para bases de datos operacionales, forman una fuente óptima de entrada cuando se crean metadatos. Hacer uso de la documentación Ing. Roberto Vélez I. 35

36 existente, especialmente cuando está disponible en forma electrónica, puede acelerar el proceso de definición de metadatos del ambiente Data Warehousing. Arquitectura de un Data Warehouse Una de las razones por las que el desarrollo de un Data Warehouse crece rápidamente, es que realmente es una tecnología muy entendible. De hecho, Data Warehousing puede representar mejor la estructura amplia de una Empresa para administrar los datos informacionales dentro de la organización. A fin de comprender cómo se relacionan todos los componentes involucrados en una estrategia Data Warehousing, es esencial tener una Arquitectura Data Warehouse (Figura 2.2). Ing. Roberto Vélez I. 36

37 Figura 2.2 Elementos constituyentes de una Arquitectura Data Warehouse Una Arquitectura Data Warehouse (Data Warehouse Architecture - DWA) es una forma de representar la estructura total de datos, comunicación, procesamiento y presentación, que existe para los usuarios estratégicos de la Empresa. La arquitectura está integrada por un conjunto de Niveles interconectados: Base de datos transaccional / Base de datos externo Acceso a la información Acceso a los datos Directorio de datos (Metadatos) Gestión de proceso Mensaje de la aplicación Data Warehouse Organización de datos Base de datos operacional / Base de datos externo Los sistemas operacionales procesan datos para apoyar las necesidades operacionales críticas. Para hacer eso, se han creado las bases de datos operacionales históricas que Ing. Roberto Vélez I. 37

38 proveen una estructura de procesamiento eficiente, para un número relativamente pequeño de transacciones comerciales bien definidas. Sin embargo, a causa del enfoque limitado de los sistemas operacionales, las bases de datos diseñadas para soportar estos sistemas tienen dificultad al acceder a los datos para otra gestión o propósito informático. Esta dificultad en acceder a los datos operacionales es amplificada por el hecho que muchos de estos sistemas tienen de 10 a 15 años de antigüedad. El tiempo de algunos de estos sistemas significa que la tecnología de acceso a los datos disponible para obtener los datos operacionales, es igualmente antigua. Ciertamente, la meta del Data Warehousing es liberar la información que es almacenada en bases de datos operacionales y combinarla con la información desde otra fuente de datos, generalmente externa. Nivel de acceso a la información Ing. Roberto Vélez I. 38

39 El nivel de acceso a la información de la arquitectura Data Warehouse, es el nivel del que el usuario final se encarga directamente. En particular, representa las herramientas que el usuario final normalmente usa día a día. Por ejemplo, herramientas ofimáticas como EXCEL, Project, Access; Sistemas Integrados como SAP; interfaces de aplicaciones específicas, etc. Este nivel también incluye el hardware y software involucrados en mostrar información en pantalla y emitir reportes de impresión, hojas de cálculo, gráficos y diagramas para el análisis y presentación. Hace dos décadas que el nivel de acceso a la información se ha expandido enormemente, especialmente a los usuarios finales quienes se han volcado a los PCs personales y los PCs en redes. Actualmente, es posible contar con mayor variedad de herramientas para gestionar, analizar y presentar los datos; sin embargo, hay problemas significativos al tratar de convertir los datos desde el estado original tal como fueron recolectados y almacenados en los sistemas operacionales, hacia su nuevo estado, como información fácil y transparente para las herramientas de los usuarios finales. Una de las Ing. Roberto Vélez I. 39

40 claves para esta conversión es encontrar un lenguaje de datos común que puede usarse a través de toda la Empresa. Nivel de acceso a los datos El nivel de acceso a los datos de la arquitectura Data Warehouse está involucrado con el nivel de acceso a la información para conversar en el nivel operacional. Uno de los adelantos claves de los últimos años ha sido el desarrollo de una serie de "filtros" de acceso a datos para acceder a casi todo los Sistemas de Gestión de Base de Datos (Data Base Management Systems - DBMSs) y sistemas de archivos de datos, relacionales o no. Estos filtros permiten a las herramientas de acceso a la información, acceder también a la información almacenada en sistemas de gestión de base de datos (DBMSs) que tienen hasta veinte años de antigüedad. El nivel de acceso a los datos no solamente conecta DBMSs diferentes y sistemas de archivos sobre el mismo hardware, sino también a los fabricantes y protocolos de red. Una de las claves de una estrategia Data Warehousing es proveer a los usuarios finales de "acceso universal a los datos". Ing. Roberto Vélez I. 40

41 El acceso universal a los datos significa que, teóricamente por lo menos, los usuarios finales sin tener en cuenta la ubicación de la información, o la herramienta de acceso que utilicen, estarán en capacidad de acceder a cualquier dato necesario para realizar su trabajo. El nivel de acceso a los datos entonces es responsable de la interfaces entre las herramientas de acceso a la información y las bases de datos operacionales. En algunos casos, esto es todo lo que un usuario final necesita. Sin embargo, en general, las organizaciones desarrollan un plan mucho más sofisticado para el soporte del Data Warehousing. Nivel de Directorio de Datos (Metadatos) A fin de proveer el acceso universal a los datos, es absolutamente necesario mantener alguna forma de directorio de datos o repositorio de los metadatos que representan la información alrededor de los datos dentro de la Empresa. A fin de tener un depósito totalmente funcional, es necesario tener una variedad de metadatos disponibles, información sobre las vistas de datos de los usuarios finales e información sobre las bases de datos operacionales. Idealmente, los Ing. Roberto Vélez I. 41

42 usuarios finales deberían de acceder a los datos desde el Data Warehouse sin tener que conocer dónde residen los datos o la forma en que se han almacenado. Nivel de Gestión de Procesos El nivel de gestión de procesos tiene que ver con la programación de diversas tareas que deben realizarse para construir y mantener el Data Warehouse y la información del directorio de datos. Este nivel puede depender del alto nivel de control de trabajo para muchos procesos (procedimientos) que deben ocurrir para mantener el Data Warehouse actualizado. Nivel de Mensaje de la Aplicación El nivel de mensaje de la aplicación tiene que ver con el transporte de información a través de la red de la Empresa. El mensaje de aplicación se refiere también como "subproducto", pero puede involucrar sólo protocolos de red. Puede usarse por ejemplo, para aislar aplicaciones operacionales o estratégicas a partir del formato de datos Ing. Roberto Vélez I. 42

43 exacto, recolectar transacciones o los mensajes y entregarlos a una ubicación segura en un tiempo seguro. Nivel Data Warehouse (Físico) En el Data Warehouse (núcleo) es donde se almacena la información, empleada principalmente para usos estratégicos. En algunos casos, uno puede pensar del Data Warehouse simplemente como una vista lógica o virtual de datos. En muchos ejemplos, el Data Warehouse puede no involucrar almacenamiento de datos. En un Data Warehouse físico, copias, en algunos casos, muchas copias de datos operacionales y/o externos, son almacenadas realmente en una forma que es fácil de acceder y es altamente flexible. Cada vez más, los Data Warehouse son almacenados sobre plataformas cliente/servidor, pero por lo general se almacenan sobre mainframes. Nivel de Organización de Datos El componente final de la arquitectura Data Warehouse es la organización de los datos. Se llama también gestión de copia o réplica, pero de hecho, incluye todos los procesos necesarios como seleccionar, editar, resumir, combinar y Ing. Roberto Vélez I. 43

44 cargar datos en el depósito y acceder a la información desde bases de datos operacionales y/o externas. La organización de datos involucra con frecuencia una programación compleja, pero cada vez más, están creándose las herramientas Data Warehousing para ayudar en este proceso. Involucra también programas de análisis de calidad de datos y filtros que identifican modelos y estructura de datos dentro de los Datos operacionales existentes. Operaciones en un Data Warehouse En la Figura 2.3 se muestra algunos de los tipos de operaciones que se efectúan dentro de un ambiente Data Warehousing. Figura 2.3 Tipos de Operaciones de un Data Warehousing Ing. Roberto Vélez I. 44

45 Sistemas Operacionales Los datos administrados por los sistemas de aplicación operacionales son la fuente principal de datos para el Data Warehouse. Las bases de datos operacionales se organizan como archivos indexados, bases de datos de redes/jerárquicas o sistemas de base de datos relacionales. Extracción, Transformación y Carga de los Datos Se requieren herramientas de gestión de datos para extraer datos desde bases de datos y/o archivos operacionales, luego es necesario manipular o transformar los datos antes de cargar los resultados en el Data Warehouse. La transformación o a la integración de datos consiste en tomar los datos desde varias bases de datos operacionales y/o fuentes externas, y convertirlos al formato requerido para la arquitectura empresarial. Las bases de datos operacionales, diseñadas para el soporte de varias aplicaciones de producción, frecuentemente difieren en el formato. Ing. Roberto Vélez I. 45

46 Los mismos elementos de datos, si son usados por aplicaciones diferentes o administrados por diferentes software DBMS, pueden tener diferentes definiciones, utilizar nombres inconsistentes, formatos incompatibles y/o ser codificados de manera diferente. Todas estas diferencias deben resolverse antes que los elementos de datos sean almacenados en el Data Warehouse. Acceso de usuario final Los usuarios acceden al Data Warehouse por medio de herramientas de productividad basadas en GUI (Graphical User Interface - Interfase gráfica de usuario). Pueden proveerse a los usuarios del Data Warehouse muchos de estos tipos de herramientas. Estos pueden incluir software de consultas, generadores de reportes, procesamiento analítico en línea, herramientas de minería de datos, etc., dependiendo de los tipos de usuarios y sus requerimientos particulares. Plataforma del Data Warehouse La plataforma para el Data Warehouse es casi siempre un servidor de base de datos relacional. Los extractos de la Ing. Roberto Vélez I. 46

47 información integrada/transformada se cargan en el Data Warehouse. El sistema ejecuta las consultas que se pasa a los datos por el software de acceso a los datos del usuario. Aunque un usuario visualiza las consultas desde el punto de vista de un GUI, las consultas típicamente se formulan como pedidos SQLpor ser éste un lenguaje estándar para el acceso a datos. Datos Externos Dependiendo de la aplicación, el alcance del Data Warehouse puede extenderse por la capacidad de acceder a la información externa. Por ejemplo, los datos accesibles por medio de servicios en línea y/o vía Internet, pueden estar disponibles a los usuarios del Data Warehouse. Transformación de Datos Uno de los desafíos de cualquier implementación de Data Warehouse, es el problema de transformar los datos. La transformación se encarga de las inconsistencias en los formatos de datos y la codificación, que pueden existir dentro de una base de datos única y que casi siempre existen Ing. Roberto Vélez I. 47

48 cuando múltiples bases de datos contribuyen al Data Warehouse. En la Figura 2.4 se ilustra una forma de inconsistencia, en la cual el género se codifica de manera diferente en tres bases de datos diferentes. Los procesos de transformación de datos se desarrollan para direccionar estas inconsistencias. Género: F, M TRANSFORMACION Género: 1, 0 Data Warehouse Género: F, M Género: Masculino, Femenino Figura 2.4 Una forma de inconsistencia La transformación de datos también se encarga de las inconsistencias en el contenido de datos. Una vez que se toma la decisión sobre que reglas de transformación serán establecidas, deben crearse e incluirse las definiciones en las rutinas de transformación. Ing. Roberto Vélez I. 48

49 Se requiere una planificación cuidadosa y detallada para transformar datos inconsistentes en conjuntos de datos conciliables y consistentes para cargarlos en el Data Warehouse. Flujo de Datos Existe un flujo de datos normal y predecible dentro del Data Warehouse. La Figura 2.5 muestra ese flujo. Los datos ingresan al Data Warehouse desde el ambiente operacional. (Hay pocas excepciones a esta regla). Al ingresar al Data Warehouse, la información va al nivel de detalle actual, tal como se muestra, permaneciendo almacenada y siendo utilizada hasta que ocurra uno de los tres eventos siguientes: Eliminación Resumen Archivación Con el proceso de desactualización en un Data Warehouse se mueve el detalle de la información actual a información Ing. Roberto Vélez I. 49

50 antigua, basado en el tiempo de los datos. El proceso de esquematización usa el detalle de los datos para calcular los datos en forma ligera y completamente resumidos. Hay pocas excepciones al flujo mostrado. Sin embargo, en general, para la mayoría de datos encontrados en un Data Warehouse, el flujo de la información es como se ha explicado. Proceso de Esquematización Sistema Operacional de Registro Detalle Actual Proceso de envejecimiento Figura 2.5. Flujo de datos en el Data Warehouse Ing. Roberto Vélez I. 50

51 Existen dos corrientes acerca de Data Warehousing propuestas por Bill Inmon y por Ralph Kimball, el primero sostiene que el Data Warehouse es una parte del sistema de Inteligencia de Negocio. Una Empresa tiene un Data Warehouse y los Data Marts obtienen su información a partir del Data Warehouse, mientras que el segundo sostiene que el Data Warehouse es el conglomerado de todos los Data Marts dentro de la Empresa. Qué es un Data Mart La manera de desarrollar e implementar Data Marts (bodegas de datos a nivel departamental) en una Empresa, está relacionada con los requerimientos específicos de los distintos análisis que se quiere realizar en cada departamento, así como la estructura general que ésta posea. Existen tres modelos de desarrollo generales, Top Down, Bottom Up y el modelo Paralelo además se cuenta con los modelos de desarrollo alternativos. Generalidades de los Data Marts Todos los lineamientos de los sistemas de Inteligencia de Negocios se derivan de la implementación de los Data Warehouse pero debido a la relación estructural que existe Ing. Roberto Vélez I. 51

52 con el diseño de los Data Marts, permite que se empleen en ellos también. Pese a esta relación, los Data Mart no se pueden considerar como un Data Warehouse en escala inferior, ya que ellos están diseñados para satisfacer las necesidades especificas de los departamentos o divisiones en las Empresas esto permite asegurar que sin lugar a duda los Data Marts utilizan un planteamiento de divide y vencerás, que a menudo es la solución, cuando el Data Warehouse crece desmedidamente, a tal punto que se hace incontrolable su operación. Ante esta característica los Data Marts tienen ventaja en comparación con los Data Warehouse, en puntos como el campo de acción, la perspectiva de los datos, fuentes de los datos, tiempo de implantación, espacio de almacenamiento, cantidad de datos, tiempo de consultas, esto tomándolo desde una perspectiva global. En términos específicos, se puede mencionar entre otras características, que los Data Marts requieren de una aplicación específica al estar enfocados a una sola área de la Empresa, esto permite que la estructura de su información Ing. Roberto Vélez I. 52

53 esté altamente detallada, las consultas se realizan en forma rápida, su proceso al estar orientado a una sola área puede usarse con medidas específicas de la Empresa como mercadeo de un producto específico, proyección de ventas o promociones. En este proceso de diseño y construcción de los Data Marts, existen diversos patrones de desarrollo, entre los cuales podemos mencionar tres: el primero conocido como Top Down el cual tiene como base un sistema de Data Warehouse para toda la Empresa y a partir de este se desarrollan los Data Marts para las divisiones o departamentos. Un segundo patrón denominado Bottom - up, el cual se fundamenta en la construcción de los Data Marts de cada departamento o división de la Empresa, a partir de los cuales se construye el Data Warehouse; y un tercer modelo, el cual consiste en llevar una construcción paralela entre ambas estructuras, sin definir como padre el Data Warehouse sobre el Data Mart, ni viceversa. Ing. Roberto Vélez I. 53

54 Dentro de esta categorización de los modelos, existen tres variaciones, una para cada uno de ellos, dicha variación consiste en incluir en cada patrón de desarrollo el uso de retroalimentación de datos. Los Data Marts por las consideraciones mencionadas, se convierten en una fuente de datos calidad para el análisis y el soporte para la toma de decisiones en pequeñas y medianas Empresas, por su versatilidad, corto tiempo de desarrollo y bajo costo económico, así como la obtención de los resultados esperados a un corto plazo. Para tener un panorama general sobre los Data Marts, es preciso pasar a especificar de forma clara y detallada cada uno de los tres modelos de patrones de desarrollo así como sus variaciones. Modelos Generales de Desarrollo En esta categoría de modelos no es tomada en consideración la retroalimentación, la cual permite agregar datos que no estén presentes en el Data Warehouse. Los tipos de modelos son los siguientes: el modelo Top Down, el Botton Up y el Paralelo. Modelo Top Down Ing. Roberto Vélez I. 54

55 El modelo Top Down está basado en la estructura del Data Warehouse, la cual se construye a partir de los datos que se puedan obtener de los diferentes sistemas operacionales o externos (datos aislados) a través de un proceso de extracción, transformación y carga (ETL). Todos los datos necesarios para el apoyo a la toma de decisiones se encuentran en el Data Warehouse después de que el Data Warehouse está implementada con la información procesada, solamente es necesario distribuir los datos según las necesidades de información por departamento, generando los Data Marts como subgrupos de datos específicos para los requerimientos particulares de cada departamento. Es importante hacer notar que los Data Marts en este modelo son derivados del Data Warehouse y debido a esta estrecha relación se da una inconsistencia al querer definir una nueva necesidad de información para un departamento, ya que en este caso es necesario modificar primero el Data Warehouse para que ocurra el respectivo cambio en el Data Mart. Modelo Bottom up Ing. Roberto Vélez I. 55

56 En este modelo los Data Marts se construyen a partir de los datos dispersos y el Data Warehouse se construye a partir de los Data Marts existentes, esta construcción se realiza a través de dos procesos diferentes de extracción, transformación y transportación. En el primer proceso cada Data Mart se construye con los datos aislados que son necesarios para satisfacer las funciones del departamento por medio de los procesos de extracción, transformación y transportación. Es necesario enfatizar que por la naturaleza de su diseño no existe ninguna relación entre un Data Mart y cualquier otro. Un segundo proceso de tratamiento de datos (ETL) ocurre en el sentido de los Data Marts hacia el Data Warehouse. Este Data Warehouse que ha sido construida a través de los diversos Data Marts, contendrá toda la información que la Empresa requiera de acuerdo a la necesidad o análisis que quiera realizar. El Modelo Paralelo El diseño del modelo paralelo se basa en dos alternativas, en la primera se tratan los Data Marts con entidades Ing. Roberto Vélez I. 56

57 independientes de los Data Warehouse y en la segunda, esta independencia se trata de forma temporal. En el primer caso se enfoca la construcción de los Data Marts como entidades independientes del Data Warehouse, utilizando el modelo de construcción de esta. Esto consiste en utilizar el mismo modelo de datos que se emplea en la construcción del Data Warehouse propuesto por la Empresa. La ventaja de que este modelo funcione de esta forma es que permite detectar y controlar problemas, como la falta y la redundancia de información presentes en el modelo del Data Warehouse. Esto permite el mejoramiento del modelo de construcción en los futuros Data Marts y en el mismo Data Warehouse. Por otra parte este modelo puede verse desde otro punto de vista donde los Data Marts se construyen con una independencia temporal del Data Warehouse, lo que indica que una vez que están implementados pasan a ser parte de ella, como un subconjunto de datos que conforma el Data Warehouse que existe en la Empresa. Ing. Roberto Vélez I. 57