Creación de un almacén de datos para apoyar los procesos operacionales ejecutados por el área de Crédito de una empresa automotriz.

Transcripción

1 UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE CIENCIAS ESCUELA DE COMPUTACIÓN CENTRO DE INFORMACIÓN DE SISTEMAS DE INFORMACIÓN Creación de un almacén de datos para apoyar los procesos operacionales ejecutados por el área de Crédito de una empresa automotriz. Trabajo Especial de Grado presentado ante la ilustre Universidad Central de Venezuela por el Bachiller: Macovei Ramos, Luis Carlos Para optar al título de Licenciado en Computación Tutora: Prof. Paola Saputelli Junio 2013

2 ACTA Quienes suscriben, miembros del jurado designado por el Consejo de la Escuela de Computación de la Facultad de Ciencias de la Universidad Central de Venezuela, para examinar el Trabajo Especial de Grado titulado: Creación de un almacén de datos para la consolidación y centralización de información que permita apoyar los procesos operacionales ejecutados por el área de Crédito de una empresa automotriz, presentado por el bachiller Luis Carlos Macovei Ramos C.I: , a los fines de optar por el título de Licenciado en Computación, dejan constancia de lo siguiente: Dicho trabajo, leído por cada uno de los miembros del jurado, se fijó el día 10 de Junio de 2013, a las 5:00 pm, para que su autor lo defendiera en forma pública en la Escuela de Computación, mediante una presentación oral de su contenido, luego de lo cual se respondieron las preguntas formuladas. Finalizada la defensa pública del Trabajo Especial de Grado, el jurado decidió, sin hacerse solidario a las opiniones emitidas por el presentador, aprobarlo con la nota de puntos. En fe de lo cual se levanta la presente Acta, en Caracas a los diez (10) días del mes de Junio del año dos mil trece (2013), dejando constancia de que actuó como coordinador del jurado la Profesora Paola Saputelli. Prof. Paola Saputelli (Tutora) Prof. Carlos Acosta (Jurado) Prof. Antonio Silva (Jurado)

3 AGRADECIMIENTO A mi madre por ser mi guía absoluta en todos los momentos de mi vida. A mi omama por ser el bastión sobre el cual todos nos apoyamos. A mi hermana por apoyarme en todas las veces que lo he necesitado. Una persona suele ser bendecida con una sola madre. Yo he sido bendecido tres veces. Este trabajo es para ustedes. A todas las personas que a lo largo de estos diez años me han acompañado y han hecho posible de una u otra forma este trabajo. La perseverancia y la fe son clave para conseguir todo lo que se desea

4 Universidad Central de Venezuela Facultad de Ciencias Escuela de Computación CISI Creación de un almacén de datos para apoyar los procesos operacionales ejecutados por el área de Crédito de una empresa automotriz. Autor: Luis Carlos Macovei Ramos Tutor: Prof. Paola Saputelli. Fecha: 10/06/2013. RESUMEN El presente Trabajo Especial de Grado tiene como objetivo dar una visión clara y concisa del origen y los fundamentos de los Data Warehouse y los Data Mart desde sus comienzos, y el propósito para el que hoy en día se construyen, con una aplicación directa en el ámbito empresarial para el área de negocios de una empresa automotriz. Para ello se hará uso de una metodología que define de manera detallada cada uno de los pasos o fases involucradas en la correcta implementación de este tipo de sistemas de información; abarcando desde la planificación del proyecto hasta el despliegue del mismo. De esta manera se logra el objetivo de poder brindarle al área de esta empresa un mecanismo que les sirva de apoyo a su proceso de toma de decisiones de una manera rápida y versátil. Palabras Claves: Sistemas de Información, Almacén de Datos, Data Marts, Crédito, OLAP, Sistema de Apoyo de Decisiones

5 ÍNDICE GENERAL ACTA AGRADECIMIENTO ÍNDICE GENERAL ÍNDICE DE FIGURAS Y GRÁFICOS ÍNDICE DE TABLAS INTRODUCCIÓN CAPÍTULO I PLANTEMIENTO DEL PROBLEMA PLANTEAMIENTO DEL PROBLEMA ALCANCE JUSTIFICACIÓN OBJETIVO GENERAL OBJETIVOS ESPECÍFICOS CAPÍTULO II MARCO CONCEPTUAL CONCEPTOS TECNOLOGÍAS DE INFORMACIÓN SISTEMAS DE INFORMACIÓN BASES DE DATOS ALMACÉN DE DATOS DEFINICIÓN CARACTERÍSTICAS PRINCIPALES DIFERENCIAS ENTRE SISTEMAS DE INFORMACIÓN OPERACIONALES Y DATA WAREHOUSE ARQUITECTURA Arquitectura Básica Arquitectura Data Warehouse con Área de Organización Arquitectura de Data Warehouse con Área de Organización y Data Marts MODELADO DIMENSIONAL Pasos básicos al momento del modelado de datos Consideraciones al momento del modelado de datos Síntesis BENEFICIOS Y LIMITACIONES Beneficios Limitaciones

6 2.3 TECNOLOGÍAS Y HERRAMIENTAS SOFTWARE LIBRE SOFTWARE PROPIETARIO HERRAMIENTAS PARA LA IMPLEMENTACIÓN DE UN DATA WAREHOUSE Oracle 9i Herramientas y Componentes de Oracle 9i Ventajas SÍNTESIS PROCESO DE GENERACIÓN DE CRÉDITOS DEL ÁREA CREDITICIA DE LA EMPRESA AUTOMOTRIZ Crédito Proceso de tramitación del Crédito Recepción de la documentación y apertura de la Solicitud de Crédito Análisis de la Solicitud de Crédito Liquidación del Contrato Ciclo de vida del Contrato Terminación del Contrato CAPÍTULO III MARCO METODOLÓGICO ENFOQUE TOP-DOWN Metodología propuesta por Bill Inmon Parte 1: Desarrollo de Sistemas Operacionales Parte 2: Desarrollo del Data Warehouse Parte 3: Uso del Data Warehouse Plan de Migración (Migration Path) ENFOQUE BOTTOM-UP Metodología propuesta por Ralph Kimball Administración del proyecto y requerimientos Diseño de datos o modelado dimensional Arquitectura Implementación Despliegue y Crecimiento ANÁLISIS DE LOS ENFOQUES (W. INMON VERSUS R. KIMBALL) CAPÍTULO IV MARCO APLICATIVO METODOLOGÍA DE DESARROLLO DE DATA WAREHOUSE UTILIZADA Fase de Planificación del Proyecto Definición de los requerimientos Requerimientos funcionales generales Requerimientos funcionales del Data Mart de Crédito Requerimientos para los Indicadores Fijos de Crédito Requerimientos para los Indicadores Dinámicos de Crédito Requerimientos para el esquema de Visualización Web Requerimientos para el esquema de Visualización Excel

7 Modelado Dimensional Definición del Proceso de Negocio Definición del Grano Elección de las Dimensiones Identificación de los hechos que poblarán cada fila de la tabla de hechos Detalle de las tablas de dimensión Diseño Físico del Data Warehouse Diseño y Desarrollo de la Presentación de los Datos Diseño de la Arquitectura Técnica Selección de Productos e Instalación Especificación de Aplicaciones para Usuarios Finales Mecanismo de Control del Data Mart Mecanismo para los Indicadores de Gestión Especificación de Aplicaciones para Usuarios Finales Desarrollo de Aplicaciones para Usuarios Finales Mecanismo de control del Data Mart Mecanismo para los Indicadores de Gestión Resultado de las Aplicaciones para Usuarios Finales Despliegue Mantenimiento y Crecimiento Gestión del Proyecto CONCLUSIONES BIBLIOGRAFÍA ANEXOS Ejemplos de consultas SQL para los aplicativos Aplicativo Web: Aplicativo Escritorio

8 ÍNDICE DE FIGURAS Y GRÁFICOS Figura 1: Funciones de un sistema de Información Figura 2: Diferencias entre Sistemas Operacionales y Data Warehouse Figura 3: Estructura básica de un Data Warehouse Figura 4: Arquitectura Data Warehouse básica Figura 5: Arquitectura de un Data Warehouse con Área de Organización Figura 6: Arquitectura de un Data Warehouse con área de organización y Data Marts Figura 7: Ejemplo de un esquema en estrella Figura 8: Ejemplo de un esquema de Copo de Nieve Figura 9: Ejemplo de esquema Dimensional Figura 10: OLAP Oracle; vista de arquitectura Figura 11: Componentes de Oracle 9i Figura 12: Metodología orientada a Datos Figura 13: Ciclo de Vida de la Metodología de Ralph Kimball Figura 14: Planificación del Proyecto Figura 15: Tabla de Dimensión Concesionarios Figura 16: Tabla de Hechos y Dimensiones Figura 17: Tabla de hechos de segundo nivel para Solicitudes Figura 18: Tabla de hechos de segundo nivel para Contratos Figura 19: Extracto de atributos de la dimensión Tiempo Figura 20: Dimensión Tiempo en los procesos de Solicitudes y Contratos Figura 21: Extracto de atributos de la Dimensión Concesionarios Figura 22: Dimensión Concesionarios en los procesos de Solicitudes y Contratos Figura 23: Extracto de atributos de la Dimensión Producto Figura 24: Dimensión Producto en los procesos de Solicitudes y Contratos Figura 25: Extracto de atributos de la Dimensión Grado de Riesgo Figura 26: Dimensión Grado de Riesgo en los procesos de Solicitudes y Contratos Figura 27: Extracto de los atributos de la Dimensión Estatus Figura 28: Dimensión Estatus en los procesos de Solicitudes y Contratos Figura 29: Extracto de atributos de la Dimensión Ejecutivo Figura 30: Dimensión Ejecutivo en los procesos de Solicitudes y Contratos Figura 31: Dimensión Vendedor en los procesos de Solicitudes y Contratos Figura 32: Extracto de atributos de la Dimensión Canal Figura 33: Dimensión Canal en los Procesos de Solicitudes y Contratos Figura 34: Extracto de atributos de la Dimensión Plan Figura 35: Dimensión Plan en los Procesos de Solicitudes y Contratos Figura 36: Extracto de atributos de la Dimensión Zona Figura 37: Dimensión Zona en los Procesos de Solicitudes y Contratos Figura 38: Extracto de atributos de la Dimensión Origen Figura 39: Dimensión Origen en los Procesos de Solicitudes y Contratos Figura 40: Extracto de atributos de la Dimensión Marca/Modelo Figura 41: Dimensión Marca/Modelo en los Procesos de Solicitudes y Contratos Figura 42: Comparación del modelo lógico y físico Figura 43: Arquitectura para el proyecto DM de Crédito Figura 44: Modelo de datos para el Mecanismo de Control

9 Figura 45: Extracto de campos de la tabla TSV_CFG_ETL Figura 46: Extracto de campos de la tabla TSV_CFG_RELACION_ETL_CARGAS Figura 47: Extracto de campos de la tabla TSV_CFG_ESTATUS Figura 48: Extracto de campos de la tabla TSV_CFG_FRECUENCIA Figura 49: Extracto de campos de la tabla TSV_CFG_CARGAS Figura 50: Extracto de campos de la tabla TSV_CFG_TIPO_REGISTRO Figura 51: Extracto de campos de la tabla TSV_CFG_TIPO_DATO Figura 52: Extracto de campos de la tabla TSV_TRN_PROCESOS Figura 53: Extracto de campos de la tabla TSV_TRN_EVENTOS Figura 54: Modelo de Datos para el Mecanismo de Indicadores de Gestión Figura 55: Extracto de campos de la tabla TSV_CFG_UMBRAL Figura 56: Extracto de campos de la tabla TSV_CFG_INDICADORES_GENERAL Figura 57: Extracto de campos de la tabla TSV_CFG_MENU_INDICADORES Figura 58: Extracto de campos de la tabla TSV_SOLICITUD_INDICADORES Figura 59: Diagrama 1 Casos de Uso, Nivel Figura 60: Diagrama 2 Casos de Uso, Nivel Figura 61a: Diagrama 3 Casos de Uso, Nivel Figura 61b: Diagrama 4 Casos de Uso, Nivel Figura 62: Diagrama 5 Patrones de Interacción Figura 63: Diagrama 6 Casos de Uso, Nivel Figura 64: Diagrama 7 Casos de Uso, Nivel Figura 65: Diagrama 8, Casos de Uso, Nivel Figura 66: Diagrama 9 Patrones de Interacción Figura 67: Diagrama de procesos de Carga y Extracción Figura 68: Aplicativo Web Menú Principal Figura 69: Aplicativo Web (Monitoreo Data Warehouse Reproceso Data Warehouse) Figura 70: Aplicativo Web (Monitoreo Data Warehouse Monitoreo Proceso) Figura 71: Aplicativo Web (Indicadores de Gestión Resumen Solicitudes) Figura 72: Aplicativo Web (Indicadores de Gestión Resumen Contratos) Figura 73: Aplicativo Web (Indicadores de Gestión Detalle Solicitudes) Figura 74: Aplicativo Web (Indicadores de Gestión Detalle Contratos) Figura 75: Aplicativo Escritorio Menú Principal Figura 76: Aplicativo Escritorio (Solicitudes Detalle Gestión Diaria) Figura 77: Aplicativo Escritorio (Solicitudes Gestión Mensual) Figura 78: Aplicativo Escritorio (Contratos Detalle Gestión Diaria) Figura 79: Aplicativo Escritorio (Contratos Gestión Mensual) Figura 80: Aplicativo Escritorio (Contratos Motivos de Retención) Figura 81: Log de Defectos para la Capa de Datos en ambiente de pruebas Figura 82: Log de Defectos para el Aplicativo Web en ambiente de pruebas Figura 83: Log de Defectos para el Aplicativo Escritorio en ambiente de pruebas Figura 84: Log de Defectos para el Aplicativo Web en ambiente de pruebas Figura 85: Log de Defectos para el Aplicativo Escritorio en ambiente de pruebas Figura 86: Imagen del query para obtener la información del cierre diario de Contratos Figura 87: Imagen del query para obtener la información del cierre mensual de Contratos Figura 88: Imagen del query para obtener la información del cierre diario de Solicitudes Figura 89: Imagen del query para obtener la información del cierre mensual de Solicitudes Figura 90: Imagen del query para obtener la información de los motivos de retención de Contratos

10 ÍNDICE DE TABLAS Tabla 1: Diferencias entre Data Warehouse y las Bases de Datos Estándar Tabla 2: Marco de trabajo de la Arquitectura Tabla 3: Diseño físico de la tabla de hechos de solicitudes con el grano más bajo Tabla 4: Diseño físico de la tabla de hechos de solicitudes con el grano menos detallado Tabla 5: Diseño físico de la tabla de hechos de contratos con el grano más bajo Tabla 6: Diseño físico de la tabla de hechos de contratos con el grano menos detallado Tabla 7: Diseño físico de la dimensión Concesionarios Tabla 8: Diseño físico de la dimensión Producto Tabla 9: Diseño físico de la dimensión Grado de Riesgo Tabla 10: Diseño físico de la dimensión Estatus Tabla 11: Diseño físico de la dimensión Ejecutivo Tabla 12: Diseño físico de la dimensión Plan Tabla 13: Diseño físico de la dimensión Vendedor Tabla 14: Diseño físico de la dimensión Zona Tabla 15: Diseño físico de la dimensión Canal Tabla 16: Diseño físico de la dimensión Origen Tabla 17: Diseño físico de la dimensión Tiempo Tabla 18: Diseño físico de la dimensión Vehículo (Marca/Modelo) Tabla 19: Establecimiento de los índices

11 INTRODUCCIÓN Hoy en día, los sistemas manejadores de bases de datos (SMBD) existentes en las empresas almacenan los datos necesarios para la actividad diaria de la organización que son utilizados por los sistemas diferentes Sistemas de Información Corporativos. Dada la importancia que cada vez mas toma la Información como un activo de las empresas, actualmente se hace necesario utilizar herramientas que permitan convertir los datos contenidos en las bases de datos corporativas de las organizaciones, en información mas táctica y estratégica no solo operativa y ésta, a su vez, en conocimiento útil en el proceso de toma de decisiones estratégicas de las organizaciones. El Data Warehouse es una herramienta que va a permitir a los directivos de las organizaciones formular preguntas, realizar consultas y analizar los datos en el momento, forma y cantidad que precisen sin necesidad de tener que acudir al personal informático de la empresa. Esta tecnología de la información se perfila como el entorno idóneo para la consulta y el análisis de la información procedente tanto de los sistemas transaccionales internos, como de las fuentes de información externas de interés para la empresa. En los últimos años, el concepto de Data Warehouse ha ido perfeccionándose (gracias al aumento de la capacidad de almacenamiento, la expansión de internet y las nuevas herramientas de consulta de datos) y adaptándose a las necesidades crecientes de información de las empresas de forma que los actuales Data Warehouse pueden proporcionar soluciones a todo tipo de usuarios. Es esta evolución de los Data Warehouse el que ha producido el elemento que más adelante competerá a este trabajo de grado, el Data Mart, que por ahora se puede decir que son una versión más reducida de un Data Warehouse. Estos Data Mart a menudo contienen información específica de algún departamento concreto de la organización como pueden ser tesorería, cobranza, crédito, entre otros

12 Es por eso que surge este Trabajo Especial de Grado, en apoyo a la necesidad de información que permita apoyar los procesos operacionales ejecutados por el área de Crédito de una empresa automotriz. Este trabajo está estructurado en 4 capítulos, los cuales se describen a continuación: Capítulo 1: Planteamiento del problema, planteamiento general de la solución, objetivo general del Trabajo Especial de Grado (TEG), objetivos específicos y alcance. Capítulo 2: Presentación del marco conceptual, es decir, el conjunto central de elementos, conceptos y definiciones (que juntas conforman las bases teóricas de la investigación) que sirven para contextualizar el entorno en el que se va a desarrollar el TEG. Capítulo 3: Consta de la descripción y análisis de los métodos que se emplearán en el estudio de esta investigación, describiendo principalmente las dos metodologías más empleadas para el desarrollo de un DWH; la metodología de Bill Inmon y la metodología de Ralph Kimball. Finalmente se hace un análisis comparativo entre ambas y se escoge la metodología con la que se desarrollará el resto de este trabajo. Capítulo 4: Contiene el marco aplicativo, en el cual se explica cómo se implementó el Data Mart para el área de Crédito de la empresa automotriz a partir de la metodología seleccionada en el capítulo 3, detallando cada una de las fases de dicha metodología y su impacto en el desarrollo del Data Mart. Finalmente se presentan las Conclusiones asi como las referencias bibliográficas que apoyaron todos los conceptos desarrollados a lo largo del documento, y algunos anexos que complementan el entendimiento del presente Trabajo Especial de Grado

13 CAPÍTULO I PLANTEMIENTO DEL PROBLEMA En este capítulo se presenta el problema que motiva este Trabajo Especial de Grado, una descripción general de las soluciones posibles y de la solución propuesta, alcance, objetivo general y objetivos específicos del TEG. 1.1 PLANTEAMIENTO DEL PROBLEMA Actualmente la arquitectura tecnológica del negocio en cuestión está compuesta por un core, o núcleo, basado en un motor de Oracle, con sus esquemas respectivos, que le dan soporte a los diferentes departamentos que conforman a la Empresa (dentro del cual se encuentra el departamento de Crédito). Estos esquemas son poblados de datos periódicamente por los diferentes usuarios que acceden a los aplicativos de: Solicitudes de crédito, análisis de crédito, generación de contratos, entre otros; y manejan datos sobre diversos procesos, que se llevan a cabo dentro de la compañía, como: contratos, solicitudes, clientes, cobranzas, etc. Ahora bien, aunque operativamente la Empresa puede manejarse de manera eficiente con la infraestructura anteriormente descrita, el negocio requiere un mecanismo que le permita interpretar de manera lógica y rápida todos estos datos que constantemente se almacenan en el core. Las razones principales de esta necesidad son que actualmente los pocos análisis que el personal del área de crédito puede realizar sobre dichos datos deben hacerlo de manera manual y esto suele consumir mucho tiempo, lo cual pone en riesgo la operatividad del área, y también aumenta considerablemente el margen de error sobre los resultados obtenidos. La propuesta para el Trabajo Especial de Grado es dar foco al mecanismo para la generación de la solución que apoyará a la necesidad de creación de indicadores de gestión e interpretación de los datos de la empresa específicamente para el área de crédito

14 1.2 ALCANCE La solución que se plantea pretende ser de gran utilidad a la empresa automotriz en cuestión ya que existe la necesidad por parte de la misma de poder interpretar de una manera sencilla, versátil y rápida todos los datos que se generan a raíz de sus procesos de negocio y así poder tomar decisiones efectivas que incrementen su productividad. Se realizará el análisis, diseño e implementación de dicha solución que abarcará, además del alcance estándar de un Data Warehouse, la creación de los diferentes indicadores de gestión los cuales en conjunto con el Data Warehouse permitirán al departamento de Crédito poder ejercer un mejor control sobre sus procesos. 1.3 JUSTIFICACIÓN Si bien la Empresa posee ya un sistema en el cual cargan la información de todos sus procesos de manera diaria, el mismo es un sistema transaccional y por lo tanto incapaz de satisfacer de manera directa la necesidad de la empresa de poder analizar todos esos datos desde un punto de vista gerencial. Al mismo tiempo, la generación de reportes usando como fuente dicho sistema transaccional tiende a ser un proceso bastante lento y manual, lo que suele hacerlo susceptible a errores humanos. Por esta razón y para dar respuesta a la necesidad anteriormente planteada se le ha propuesto a la empresa desarrollar una capa de análisis de procesos de negocios o Data Warehouse, que podrá comunicarse directamente con los esquemas propios de bases de datos de la organización. La idea es poder centralizar en esta nueva capa toda la información que servirá para llevar un control de los procesos de solicitudes y contratos principalmente, pues estos son los que abarcan al área de Crédito. Todo lo anterior, aunado a los indicadores de gestión, permitirá a los usuarios soportarse en dicha capa de análisis de procesos de negocios para poder tomar decisiones de negocio más precisas

15 1.4 OBJETIVO GENERAL Creación de un almacén de datos o Data Mart empleando tecnología Oracle para la consolidación y centralización de información que permita apoyar en la toma de decisiones a los procesos relacionados con las operaciones sobre solicitudes y contratos ejecutados por el área de Crédito. 1.5 OBJETIVOS ESPECÍFICOS Definir indicadores de gestión y requerimientos generales del área de Crédito. Analizar y definir las fuentes de datos que permitan alimentar al Data Warehouse. Realizar el diseño de la base de datos asociada al Data Warehouse Diseñar, implementar y probar procesos Extracción Transformación y Carga (con sus siglas en inglés ETL) para la consolidación de la información dentro del Data Warehouse. Diseñar, implementar y probar esquema de visualización de la información consolidada en el Data Warehouse. Diseñar, implementar y probar esquema de visualización de indicadores de gestión y de monitoreo del DW

16 CAPÍTULO II MARCO CONCEPTUAL En este capítulo se abordan todos los elementos a emplear como base teórica para el desarrollo del Seminario. Las secciones que las conforman son las siguientes: En la primera sección se detallan los conceptos de Tecnologías de Información y de Sistemas de Información, seguidos por la definición de Bases de Datos y sus características. En la segunda sección se define qué es un Almacén de Datos y sus características, continuando con las propiedades que diferencian a dichos almacenes de datos de los sistemas de información operacionales, luego se detallan los diferentes tipos de arquitecturas existentes para los almacenes de datos así como también los modelos más usados para su diseño y finalmente se abordan los beneficios y limitaciones asociadas a estos almacenes. Finalmente, en la tercera sección se detallan las principales tecnologías para el desarrollo de un almacén de datos tanto desde el punto de vista del software libre como desde el punto de vista del software propietario con sus ventajas y desventajas y luego se plantea un análisis cualitativo de cada una de estas tecnologías. 2.1 CONCEPTOS Antes de abordar el entorno de los Almacenes de Datos se deben definir un conjunto de conceptos previos para facilitar su entendimiento TECNOLOGÍAS DE INFORMACIÓN Las tecnologías de información consisten en todo el hardware (como computadoras, impresoras, asistentes digitales) como software (como sistemas operativos, programas

17 de cómputo) que una empresa requiere para alcanzar sus objetivos de negocio. (Laudon y Laudon, 2008) SISTEMAS DE INFORMACIÓN La definición del autor James S. Senn en el libro Análisis y Diseño de Sistemas de Información señala que la definición de Sistemas de Información Es el proceso de examinar la situación de una empresa con el propósito de mejorarla con métodos y procedimientos más adecuados. Un sistema de información también se puede definir como un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo. Figura 1: Funciones de un sistema de Información Fuente: Laudon y Laudon

18 Hay tres actividades básicas en un sistema de información que producen la información que esas organizaciones necesitan para tomar decisiones, controlar operaciones, analizar problemas y crear nuevos productos o servicios. Estas actividades son la entrada, procesamiento y salida. La entrada captura o recolecta datos en bruto tanto de la organización como de su entorno. El procesamiento convierte esta entrada de datos en forma significativa. La salida transfiere la información procesada a las personas o actividades destino. Los sistemas de información también requieren retroalimentación que es la salida que se analiza para evaluar o corregir la entrada. (Laudon y Laudon, 2008) BASES DE DATOS Un sistema manejador de base de datos es un conjunto de información que está almacenada en forma sistemática, de manera tal que los datos que la conforman puedan ser utilizados en forma fragmentada cuando sea necesario. (Abraham Silberschatz, 2008) Los datos almacenados pueden ser muy diversos: nombres, números telefónicos, direcciones, años, etc. Todo depende de la finalidad para la que sea construida. Actualmente, muchos sistemas cotidianos para nosotros se sustentan en una base de datos: cajeros automáticos, catálogo de bibliotecas o librerías, páginas amarillas, listado de medicamentos, etc. Todo cuenta con una base de datos a la cual recurrir para consultar la información y mantenerla actualizada. Características generales de las bases de datos: (Abraham Silberschatz, 2008) Redundancia mínima de datos: Se trata de usar la base de datos como repositorio común para distintas aplicaciones, y combinarla con el acceso a la distribución espacial de los datos, pues los datos pueden encontrarse en otra habitación, otro edificio e incluso otro país y el usuario no tiene por qué preocuparse de la localización de los datos que accede

19 Integridad de datos: Se refiere a las medidas de seguridad que impiden que se introduzcan datos erróneos ya sea por motivos físicos (debido a causas externas), como de operación (introducción de datos incoherentes), esto puede ser mediante encriptación de la información o protección con contraseña de acceso. Consultas complejas optimizadas y brindar seguridad de acceso y auditoría: Esto se refiere al derecho de acceso a la información contenida en la base de datos por parte de personas o grupos, además debe brindar respaldo de información y recuperación de información. Acceso a través de lenguajes de programación estándar: Se refiere a la posibilidad de acceder a la información de una base de datos mediante programas diseñados a la medida de los usuarios. 2.2 ALMACÉN DE DATOS Lo que actualmente se entiende por almacén de datos (DW 1 ) suele implicar algún tipo de elemento de Base de Datos que puede proporcionar múltiples funciones a un número determinado de usuarios, es un concepto que puede entenderse mejor desde el contexto de su implementación que de una definición conceptual pues no existe una definición oficial de DW apoyada por un comité de estándares DEFINICIÓN El almacén de datos (DW) es un término anglosajón el cual, al igual que muchas expresiones en el mundo tecnológico, no tiene una traducción precisa al castellano, aunque una de las que más se le aproxima es Repositorio de Datos. De cualquier manera, si dicha traducción fuese precisa entonces los datos almacenados en este 1 Data Warehouse, por sus siglas en inglés

20 repositorio no podrían brindar ninguna especie de soporte o ayuda en el proceso de toma de decisiones. El DW suele percibirse entonces como una réplica masiva de los datos disponibles en las bases de datos operacionales, de tal forma que su estructura ya no responda a las necesidades del modelo relacional, que suele emplearse en los sistemas operacionales, puro puesto que sobre dicha data no se van a estar efectuando los procesos que suelen realizar los citados sistemas operacionales. Por lo dicho hasta ahora parece que un DW puede definirse como una simple copia de datos sobre los que posteriormente se efectúan procesos empresariales de consultas de negocio. Sin embargo, la problemática asociada a la obtención y tratamiento que de sus datos se hace, convierten al DW en una nueva estructura con una nueva problemática asociada muy concreta y diferenciada de las bases de datos operacionales. Al realizar el proceso de investigación de diferentes fuentes bibliográficas se observa que el origen del término DW se atribuye usualmente a dos fuentes distintas. La primera fuente hace referencia a Barry Devlin y Paul Morphy, quienes en 1988 escribieron An Architecture for a Bussiness and Information Systems (Devlin, 1988) el cual se publicó en el IBM Systems Journal y es considerado como uno de los primeros artículos que describe la arquitectura de un DW, que fue desarrollado entre 1985 y 1986 para uso interno de IBM Europa en Dublín. En dicho artículo se hizo uso del término Information Warehouse para hacer referencia al proyecto, esta frase suele usarse de manera general en la actualidad para referirse a un DW. Luego Devlin (1997) definió que Data Warehouse es un único, completo y consistente almacén de datos obtenido de una variedad de fuentes y puesto a la disposición de los usuarios finales de manera que ellos puedan entender y usar en el contexto del negocio (Devlin, 1997)

21 Ahora bien, la segunda fuente hace referencia a William H. Inmon a quien se le atribuye el término de DW. Un Data Warehouse es un conjunto de datos orientados hacia una materia, integrados, no transitorios y que varían en el tiempo, los cuales apoyan el tema de toma de decisiones de una administración (Inmon, 1992). Inmon es considerado el padre del Data Warehouse y como tal ha escrito una serie de libros junto con otros autores donde abordan diversos tópicos relacionados con la arquitectura Data Warehouse. Por su parte Rob Mattison (1996) define cuatro características de un DW; esta organizado como un área de almacén de datos neutral, es usado para data-mining y otras aplicaciones, abarca un determinado conjunto de requerimientos y se usa para satisfacer y apoyar un conjunto previamente definido de criterios de negocio. Dichas características suelen coincidir con la definición establecida por Inmon. El contexto DW define en sí mismo un nuevo entorno de trabajo donde aparecen una serie de términos novedosos y con los cuales se debe estar familiarizado pues los mismos sirven como fundamento a dicho contexto CARACTERÍSTICAS A nivel general un DW se caracteriza principalmente por ser: Integrado: Los datos almacenados en el DW deben estar integrados en una estructura que sea capaz de eliminar cualquier tipo de inconsistencias existentes entre los diversos sistemas operacionales que sirven de fuentes de datos. Al mismo tiempo, la información suele estructurarse en distintos niveles de detalle para adecuarse a los requerimientos preestablecidos por todos los usuarios finales. Temático: Sólo los datos necesarios para generar información del negocio se integran desde el entorno operacional. Los datos se organizan por temas, no por aplicación, así se facilita el acceso y entendimiento por parte de los

22 usuarios finales a los datos contenidos en el DW. Eventualmente, esta característica permite realizar análisis y minería de datos. Histórico: El tiempo es parte implícita de la información contenida en un DW. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, en el DW se cargan con los distintos valores que puede tomar una variable en el tiempo para poder hacer comparaciones y análisis, soportando de esta manera el proceso de toma de decisiones. No volátil: El DW se construye para ser leído, y no modificado. La información que existe en un DW es permanente, su actualización consiste en la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin alteración de los datos que ya existían. Además de las características previamente mencionadas otras, quizás menos relevantes, pero que igualmente sirven para remarcar la potencialidad de un DW son las siguientes: Contiene datos diversos: es un repositorio unificado de información. Los datos de toda la organización aunque pertenezcan a aplicaciones disímiles son integrados en el DW. Optimizado para la consulta masiva: el diseño físico de un DW tiene un objetivo diferente al de las bases de datos transaccionales, mejorar los tiempos de respuesta de procesos de consultas de datos masivas de información, tomando en cuenta que deben ser orientadas a temas así como también brindar facilidad de entendimiento al usuario final. La interfaz de usuario está dirigida a los ejecutivos: las aplicaciones que se desarrollan para explotar las bondades de un Data Warehouse serán utilizadas principalmente por altos ejecutivos y diversos analistas, por lo que deben ser amigables e intuitivas

23 Gran volumen: Cuando se habla de Data Warehouse el espacio de almacenamiento suele medirse en Gigabytes y Terabytes debido a la cantidad de información sumarizada. Cabe destaca que un DW admite redundancia de datos y un tiempo de vida de la información entre 5 y 10 años PRINCIPALES DIFERENCIAS ENTRE SISTEMAS DE INFORMACIÓN OPERACIONALES Y DATA WAREHOUSE Como ha sido mencionado previamente la existencia de un Data Warehouse no conlleva exclusivamente el hecho de que se realice una copia masiva de datos, sino que esa copia tiene un determinado fin y que su propia existencia involucra una dinámica de trabajo particular. Una diferencia entre ambas formas de almacenamiento se encuentra en la orientación de los datos y su organización: en el mundo operacional, los datos están dirigidos a procesos o transacciones, mientras que en el entorno de toma de decisiones los datos deben estar orientados al tema, es decir orientados a los conceptos que tengan relevancia en la organización en la que existe. Por sí solo, este hecho ya implica la existencia de procesos diferentes a los existentes en las bases de datos operacionales de la organización. Sin embargo, este proceso no debe afectar de ninguna manera el rendimiento de dichos sistemas, por lo tanto se deben buscar los momentos adecuados en los que realizarlo, lo que suele llevar a modificaciones en la dinámica de trabajo de la organización. La siguiente figura muestra las diferencias fundamentales entre el ambiente operacional y el DW

24 Figura 2: Diferencias entre Sistemas Operacionales y Data Warehouse Fuente: Inmon 1992 Estas diferencias representan un cambio radical en cuanto al enfoque que le da a los sistemas de información y al rol que desempeña el equipo de tecnología de la información dentro de la organización. Ellas se encuentran resumidas en la tabla 1 Base de Datos Estándar Data Warehouse En su mayor parte son actualizaciones En su mayor parte son lecturas Muchas transacciones pequeñas Las consultas son largas y complejas Mb Gb de Datos Gb Tb de Datos Snapshots Actuales Historia Datos Crudos Datos sumarizados y consolidados Los usuarios son oficinistas Los usuarios son analistas, toman decisiones Tabla 1: Diferencias entre Data Warehouse y las Bases de Datos Estándar

25 2.2.4 ARQUITECTURA El hecho que la tecnología Data Warehouse es fácilmente entendible ha hecho que el desarrollo de los mismos crezca rápidamente. De hecho, un Data Warehouse puede representar mejor que otros sistemas la compleja estructura de una empresa a la hora de administrar sus propios datos gerenciales. Según Claudio Caseres (1999), debido a que el proceso de construcción de un DW es un proceso bastante crítico en el desarrollo de una herramienta de BI, resulta importante revisar algunos aspectos esenciales para dicho proceso. Base de datos operacional, nivel de base de datos externos: como se ha explicado anteriormente los sistemas operacionales proporcionan una estructura de procesamiento eficiente para un gran número de transacciones comerciales bien definidas. Por otro lado, la meta del DW es utilizar la información que se almacena en bases de datos operacionales y combinarla con la información que proviene de otras fuentes de datos, generalmente externas. Nivel de acceso a la información: el nivel de acceso a la información de la arquitectura DW 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. Este nivel incluye el hardware y software involucrados en mostrar información en pantalla y emitir informes, hojas de cálculo, gráficos y diagramas para el análisis y presentación. Nivel de acceso a los datos: el nivel de acceso a los datos de la arquitectura Data Warehouse está relacionado con el nivel de acceso a la información en el nivel operacional

26 El nivel de acceso a los datos conecta diferentes manejadores de Bases de Datos y sistemas de archivos sobre el mismo hardware y protocolos de red. Una de las claves de una estrategia DW es proveer a los usuarios finales de un acceso universal a los datos. El acceso a los datos universales significa que, teóricamente por lo menos, los usuarios finales sin tener en cuenta la herramienta de acceso a la información o la ubicación, deberían ser capaces de acceder a cualquier o todos los datos en la empresa que son necesarios para ellos. El nivel de acceso a los datos entonces es responsable de las 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 DW. Nivel de directorio de datos (metadatos): a fin de proveer el acceso a los datos universales, es absolutamente necesario mantener alguna forma de directorio de datos o metadatos. Los metadatos son información sobre los datos dentro de la empresa. Con el objetivo de tener una base de datos 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 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 la que están almacenados. 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 DW y la información del directorio de datos. Este nivel depende del nivel de trabajo de los procesos encargados de mantener el DW actualizado

27 Nivel de mensaje de la aplicación: el nivel de mensaje de la aplicación tiene que ver con el transporte de información alrededor de la red de la empresa. Puede usarse para aislar aplicaciones operacionales o estratégicas a partir de un formato de datos exacto, recolectar transacciones o los mensajes y entregarlos a una ubicación segura en un tiempo específico. Nivel Data Warehouse: Es el repositorio central altamente flexible de información donde residen copias de los datos operacionales usados principalmente para fines estratégicos. En un DW físico las copias de datos operacionales y/o externos se almacenan de forma que sea fácil de acceder. Actualmente, los DW se almacenan en plataformas cliente/servidor, pero también existen configuraciones sobre mainframes y/o equipos externos optimizados para su acceso, mediante consulta. Nivel de organización de datos: el componente final de la arquitectura Data Warehouse es la organización de los datos. Incluye todos los procesos necesarios para seleccionar, editar, resumir, combinar y cargar datos en el Data Warehouse y para acceder a la información desde bases de datos operacionales y/o externas. La organización de datos involucra en muchas ocasiones una programación compleja, pero cada vez con mayor frecuencia se están creando herramientas de Data Warehouse para ayudar en este proceso. En la siguiente figura se pueden observar los principales niveles o capas de un Data Warehouse; el nivel de organización, el nivel de directorio y por último el nivel de gestión de procesos:

28 Figura 3: Estructura básica de un Data Warehouse Fuente: Inmon, 1992 La forma de implementar un Data Warehouse está sujeta a la forma en la que se va a estructurar el almacenamiento de los datos dentro del mismo. Independientemente del modelo que se escoja el objetivo principal es escoger uno que satisfaga las necesidades empresariales. Según el manual Data Warehousing Manual (2005) los modelos de arquitecturas que generalmente se manejan son los siguientes: Arquitectura Básica Los usuarios finales acceden directamente a los datos desde diferentes sistemas de recursos a través del Data Warehouse. La siguiente figura ejemplifica este tipo de arquitectura

29 Figura 4: Arquitectura Data Warehouse básica Fuente: Inmon, 1992 En la figura se puede visualizar la data cruda (raw data) propia de un sistema operacional. Por su parte, los elementos tipo summary data o datos resumen, son datos que se utilizan para calcular con antelación las operaciones más costosas. Los datos resumen suelen ser empleados con bastante frecuencia en los sistemas de soporte de decisiones (DSS 2 ) ya que son menos voluminosos y muchos más fáciles de gestionar que los datos detallados. Desde la perspectiva del acceso y presentación, el resumen de datos es una manera ideal para construir análisis a futuro y los ya existentes no se repitan. Es por eso que el resumen de datos es una parte esencial de los entornos DSS Arquitectura Data Warehouse con Área de Organización Este modelo se basa en el hecho de que para que los datos puedan ser cargados en el Data Warehouse primer deben procesarse y limpiarse para así poder almacenarse. 2 Decision Support System, por sus siglas en inglés

30 Estas actividades de limpieza y procesamiento pueden hacerse mediante programación, sin embargo en este tipo de arquitectura se incorpora un área de organización y de gestión. La siguiente figura ejemplifica la definición previamente planteada. Figura 5: Arquitectura de un Data Warehouse con Área de Organización Fuente: Inmon, 1992 El área de organización es donde se colocan los datos antes de llegar al Data Warehouse, usualmente proceden de la capa previa de procesamiento ETL 3. El proceso consiste en resumir los datos, de manera de poder sintetizar la información hasta el menor detalle. Ahora bien, la forma en la que estos datos se almacenan físicamente dependerá de los administradores de bases de datos y demás analistas, aunque usualmente suele preferirse un esquema de estrella. 3 Extraction, Transformation, Load, por sus siglas en inglés

31 Arquitectura de Data Warehouse con Área de Organización y Data Marts Un data mart representa la capa de acceso en un entorno DW y se usa para extraer data desde el DW al usuario. El data mart es un subconjunto del DW que está orientada hacia una línea del negocio o del equipo de trabajo. En algunas especificaciones de DW, cada departamento o unidad de negocio es considerada la dueña de su propio Data Mart, incluyendo todo el hardware, software y datos. Esto posibilita a cada departamento para usar y manipular la data de la mejor manera posible; sin que ello interfiera con otros data marts dentro del DW. Ahora bien, este modelo combina los primeros dos expuestos anteriormente, abarcando desde el repositorio o almacén empresarial hasta los departamentales. Se dispone de una base de datos, que contiene información común para todos los usuarios y al mismo tiempo cada área dispone de su propia base de datos. Suele ser un modelo arquitectónico común y lo suficientemente flexible como para personalizarse según los diferentes grupos que existen en la organización. Esta arquitectura se realiza mediante la implementación de Data Marts debido a que permiten la personalización propia de este esquema porque suelen estar orientados a una determinada línea de negocio

32 Figura 6: Arquitectura de un Data Warehouse con área de organización y Data Marts Fuente: Inmon, 1992 Los Data Marts se diseñan con la finalidad de poder brindar soporte a un área específica dentro del negocio en la toma de decisiones. En este contexto los datos pueden ser agrupados, explorados y propagados de múltiples formas para que los grupos interesados realicen la minería o explotación de los mismos de la manera que mejor satisfaga sus necesidades. Esto se debe a que son sistemas que se orientan a la consulta y en los que los procesos de carga en lotes suelen tener una frecuencia baja y conocida. Los Data Marts en conjunto con herramientas OLAP podrán brindar una visión multidimensional de la información a los usuarios interesados MODELADO DIMENSIONAL Por modelo dimensional se entiende el conjunto de reglas, conceptos y convenciones que nos permiten detallar y manipular los datos que se desean almacenar en una base de datos

33 El modelado dimensional es una de las técnicas de modelado favoritas en el proceso de Data Warehousing. En el proceso de modelado dimensional, un modelo de tablas y relaciones se constituye con el propósito de optimizar el soporte de toma de decisiones a nivel del performance del query en base de datos relacionales relativo al proceso de negocio que se esté modelando. En contraste, los modelos convencionales de Entidad- Relación se constituyen para; eliminar la redundancia en el modelo de datos, facilitar la obtención de registros en base a indicadores establecidos y por lo tanto optimizar el nivel de performance de los sistemas OLTP 4 (sistemas transaccionales). En general, la estructura básica de un Data Warehouse para el modelado multidimensional está definida por dos elementos: esquemas y tablas. A nivel de tablas se tiene: Tablas de Hechos (Tablas Fact): es la tabla central en un esquema dimensional. Es en ella donde se almacenan las mediciones numéricas del negocio. Estas medidas son realizadas en base al grano, o la unidad básica de la tabla. El grano o la granularidad de la tabla va a depender del nivel de detalle que se vaya a almacenar en la tabla. El grano revierte las unidades atómicas en el esquema dimensional. Cada medida suele tomarse en base a la intersección de las dimensiones que la definen. Suele estar compuesta por valores numéricos que puedan ser evaluados y sumarizados. La razón de estas características es que así se facilita que los miles de registros que involucran una consulta sean comprimidos en unas pocas líneas en un set de respuesta. 4 OnLine Transaction Processing, por sus siglas en inglés

34 La clave de la tabla fact suele llamarse clave compuesta, debido a que se forma de la unión de todas las claves primarias de las tablas dimensionales que la constituyen. Por lo tanto pueden diferenciarse dos tipos de columnas dentro de las tablas fact; las columnas fact que son las que almacenan la medida de negocio previamente definida y las columnas primarias o key que es la que forma parte de la clave compuesta de la tabla. Tablas Dimensionales (Tablas Lock-up): estas tablas son las que se conectan a la tabla fact, son las que nutren a la tabla fact. Una tabla del tipo lock-up almacena un conjunto de valores que están relacionados a una dimensión en particular. Este tipo de tablas no contempla hechos, en su lugar sus valores son los que determinan la estructura de las dimensiones. Por lo tanto, la tabla alberga el detalle de la dimensión determinada. Una tabla dimensional está compuesta por una clave primaria que identifica unívocamente una fila de la tabla junto con una serie de atributos, y dependiendo del diseño del modelo puede existir una clave foránea que relaciones a una tabla dimensional con otra tabla dimensional. Para determinar si un campo de datos es un atributo o un hecho solo hace falta analizar la curva de cambio en el tiempo de dicho campo. Si varía continuamente implicaría tomarlo como un hecho, caso contrario será un atributo. Los atributos dimensionales son un rol determinante en un DW. Esto significa que la base de datos será como lo sean los atributos dimensionales, mientras más descriptivos, manejables y de buena calidad, mejor será el DW

35 Sobre los esquemas se tiene: Esquema Estrella: este esquema es el más sencillo de los esquemas de almacenamiento de datos. Se llama así porque el diagrama se asemeja a una estrella, con los puntos que irradian desde el centro. El centro de la estrella consiste de una o más tablas fact y las puntas de la estrella son las tablas dimensionales. En este esquema la tabla de hechos es la única tabla que tiene múltiples sentencias JOIN que la conectan con otras tablas. El resto de las tablas del esquema (tablas de dimensión) únicamente hacen JOIN con esta tabla de hechos. Las tablas de dimensión se encuentran además totalmente desnormalizadas, es decir, toda la información referente a una dimensión se almacena en la misma tabla. En concreto este esquema en estrella es ideal por su simplicidad y velocidad para ser usados en análisis multidimensionales, ya que permite acceder tanto a datos agregados como de detalle. La siguiente figura muestra un ejemplo de diagrama utilizando el Esquema en Estrella

36 Figura 7: Ejemplo de un esquema en estrella Fuente: Kimball, 1993 Esquema Copo de Nieve (Snowflake): este esquema es una derivación del esquema en estrella, en el que las tablas de dimensión se normalizan en múltiples tablas. Por esta razón, la tabla de hechos deja de ser la única tabla del esquema que se relaciona con otras tablas, y aparecen nuevas sentencias JOIN entre tablas gracias a que las dimensiones de análisis se representan ahora en tablas de dimensión normalizadas. En la estructura dimensional normalizada, la tabla que representa el nivel base de la dimensión es la que hace JOIN con la tabla de hechos. La diferencia principal entre ambos esquemas en la estructura de las tablas de dimensión. Para conseguir un esquema en copo de nieve se debe tomar un esquema en estrella y conservar la misma tabla de hechos, cambiando entonces la estructura de las tablas de dimensiones de elementos desnormalizados a una serie de elementos que se encuentran normalizados. La normalización va a depender de las necesidades del requerimiento, por lo que vamos a conseguir Snowflakes completos (todas las tablas normalizadas) y Snowflakes parciales (solo algunas tablas normalizadas)

37 La siguiente figura muestra un ejemplo de diagrama usando el esquema de Copo de Nieve. Figura 8: Ejemplo de un esquema de Copo de Nieve Fuente: Inmon, 1992 Esquema Dimensional: este esquema se basa en la utilización de la Tercera Forma Normal (3FN) para el modelado de los datos. El modelado de la Tercera Forma Normal es una técnica empleada usualmente en bases de datos relacionales que se basa en reducir la redundancia de datos a través de la normalización de los mismos. En comparación con un esquema de estrella, el esquema 3FN contiene un número mayor de tablas debido al proceso de normalización. Este tipo de esquema se recomienda para grandes almacenes o repositorios de datos, especialmente en ambientes con requisitos críticos de carga de datos y ejecutar consultas de larga ejecución. Este esquema proporciona un diseño de esquema neutral e independiente de cualquier aplicación y a su vez puede requerir menos transformación de datos que otros esquemas como el de estrella si pueden requerir

38 La siguiente figura muestra un ejemplo de diagrama usando el esquema Dimensional Figura 9: Ejemplo de esquema Dimensional Fuente: Kimball, Pasos básicos al momento del modelado de datos Decidir cuáles serán los procesos de negocio que se desean modelar, en base al levantamiento de la información que previamente debe realizarse y a la interacción propia con los usuarios, resultado de dicho proceso. Ejemplo: Gastos realizados por cada mercado para cada ítem a nivel mensual. Definir el nivel del grano de la tabla de hechos de cada proceso de negocio. Ejemplo: Producto x Mercado x Tiempo. El grano es el que determina las dimensiones del Data Warehouse. Cada dimensión debe tener el grano más pequeño que se pueda puesto que las respuestas otorgadas a los usuarios deben cortar la base de la manera más precisa posible. Decidir las dimensiones a través del grano. Las dimensiones presentes en la mayoría de los Data Warehouse son: tiempo, mercado, producto, cliente. Un grano bien elegido determina la dimensionalidad de la tabla de hechos

39 Consideraciones al momento del modelado de datos Se consideran los siguientes aspectos: Dimensión Tiempo: virtualmente se debe garantizar que cada Data Warehouse deberá tener una tabla dimensional de tiempo, debido a la perspectiva de almacenamiento histórica que tiene la información. Por lo general es la primera dimensión en crearse, ya que esta es la que contiene los intervalos sobre los cuales debe almacenarse la información, lo cual otorga un orden implícito. Dimensiones que varían lentamente en el tiempo: son aquellas dimensiones que se mantienen casi sin cambios en el tiempo y que pueden preservar la estructura dimensional independiente del tiempo, con unos pocos agregados para poder capturar su naturaleza cambiante en el tiempo. Este tipo de dimensiones puede manejarse de tres maneras diferentes; una de estas maneras consiste en sobreescribir el viejo valor con el nuevo, con la desventaja de perder la capacidad de seguir a dicho valor en la historia, otra manera consiste en crear un registro adicional que permita registrar el cambio presentado por el valor del atributo. De esta forma se tendría una historia completa en el tiempo del cambio, finalmente la tercera manera consiste en crear un campo adicional que en primera instancia va a almacenar el valor del atributo como un campo espejo del campo original, y por cada cambio del valor del atributo se actualizará dicho campo espejo. De esta manera se mantiene el valor que el atributo tuvo por vez primera y el valor que tiene en la actualidad, pero no contendrá el historial de cambio. Niveles: un nivel representa un elemento particular de agregación dentro de la dimensión; cada nivel sobre el nivel base representa la sumarización total del nivel inferior. Ejemplo: Consideremos la dimensión Tiempo en tres niveles: Mes, Semestre, Año. El nivel Mes representa el nivel base, el nivel Semestre representa la sumarización de los totales por Mes y el nivel Año

40 representa la sumarización de los totales para los Semestres. Los niveles de sumarización otorgan flexibilidad para los usuarios a la hora de analizar los datos. Jerarquías: las jerarquías son un conjunto de atributos que siguen un orden preestablecido. Una jerarquía implica una organización de niveles dentro de una dimensión, con cada nivel representando el total agregado de los datos del nivel anterior. Las jerarquías son las que definen cómo serán sumarizados los niveles. Una dimensión típica soporta una o más jerarquías naturales Síntesis Una vez analizados los modelos de datos más comúnmente usados, el siguiente planteamiento es cuál sería el modelo más conveniente. En base a los atributos de cada uno de los modelos se puede establecer que la forma más natural de construir el diseño es mediante el modelo de estrella, donde solo se establece una relación entre la tabla de hechos y las tablas de dimensiones. La principal razón es porque de esta manera las consultas se mantienen lo más simples posibles y así se proporcionan servicios rápidos de consulta con un tiempo re respuesta bastante corto ya que se almacena toda la información de cada nivel en pocas tablas. Ahora bien, el esquema de Copo de Nieve proporciona un nivel alto de familiaridad en torno al usuario final. El principal argumento de este esquema es que al estar normalizadas las tablas de dimensiones entonces se evitará la redundancia de datos y se ahorrará espacio. Sin embargo, actualmente las consideraciones de espacio suelen tener menos importancia cuando se comparan con las consideraciones de rendimiento de un sistema, por lo que usar este esquema se presenta como una mala opción ya que el hecho de disponer de más de una tabla por cada dimensión implica tener que realizar sentencias (queries) más complejas que a su vez se ejecutarían en un tiempo mayor, debido en parte al mayor número de sentencias JOIN que se deberán realizar. Por lo tanto, usar un esquema de Copo de Nieve en un Data Warehouse es posible siempre y

41 cuando el factor de rendimiento no sea un elemento crítico para los usuarios. Cabe destacar que un diseño basado en el modelo relacional puro presenta las mismas desventajas que acaban de describirse. En resumen, el esquema en estrella se presenta como la opción mas aconsejable cuando la principal preocupación del proyecto está marcada por los factores de espacio y rendimiento debido a que dicho modelo permite indexar las dimensiones de forma individualizada sin que repercuta en el rendimiento de la base de datos en su totalidad BENEFICIOS Y LIMITACIONES De acuerdo con diversos especialistas en la materia, cuando una empresa se decide a desarrollar un Data Warehouse busca satisfacer las siguientes necesidades: Mayor poder de procesamiento y una herramienta más sofisticada Demanda de mejora del acceso de datos Necesidad de información para la toma de decisiones Recopilación de información Cualquier solución propuesta del tipo de Data Warehouse debe estar definida y delimitada por las necesidades del negocio que la requiera y debe ser compatible con la arquitectura técnica existente y planificada de la compañía. En caso contrario es necesario que se estudie y determinen si los beneficios que se obtendrían de esta implementación pueden compensar la inversión a realizar en nuevas arquitecturas. Muchos autores suelen coincidir con que un DW no se puede comprar hecho, debe construirse a la medida. Esto quiere decir que la construcción de un DW es un proceso evolutivo que debe seguir una metodología diseñada para este tipo de procesos y un sistema de seguimiento que permita mantener el desarrollo dentro de esta metodología. También es fundamental incluir una fase de formación sobre el aplicativo que vaya a explotar las bondades del DW para un máximo aprovechamiento. Seguir los pasos de la

42 metodología y comenzar el DW por un área específica de la empresa es lo que siempre suele recomendarse porque permitiría obtener resultados tangibles en un corto espacio de tiempo. La función de un DW es contribuir a identificar elementos desconocidos del entorno de negocio y transformar la información en conocimiento a partir del análisis detallado de los datos recopilados. Es por ello que resulta de suma importancia no confundir una gran base de datos estructurada con un auténtico DW ya que este trata de crear un método, un sistema para explotar la información en beneficio del negocio. Otra de las premisas que deben tenerse claras es que un proyecto de DW no es únicamente un proyecto tecnológico, debe amalgamarse con la manera en la que la organización opera día a día y como tal debe contar con el apoyo de todo el personal involucrado en el proceso. Es importante por lo tanto que, dentro de la empresa, impere la cultura de compartir la información, es decir que no solo una persona conozca el funcionamiento del negocio Beneficios Hay muchas ventajas por las que es recomendable usar un repositorio o almacén de datos. Entre ellas podemos considerar: Los repositorios de datos facilitan el funcionamiento de las aplicaciones de los sistemas de apoyo de decisión tales como informes de tendencia (como por ejemplo, obtener los ítems con la mayoría de las ventas en un área en particular dentro de los últimos dos años). Los repositorios de datos pueden trabajar de manera conjunta para así aumentar el valor operacional de las aplicaciones empresariales

43 Acceso a toda la información de la empresa. La información que proviene de sistemas origen diferentes se consolida, sin importar si provienen de la misma o varias fuentes. Consistencia de la información al consolidarla desde varios departamentos origen a un solo destino. Esto facilita la posterior toma de decisiones al poder hacer un mejor análisis de la información. Beneficios en costes, tiempos y productividad de la empresa. Un Data Warehouse ayuda a obtener mejores tiempos de respuesta y supone una mejora en los procesos de producción. Otras ventajas son: Alto desempeño de las consultas, el diseño del Data Warehouse lo permite. La información se encuentra disponible todo el tiempo, aún si los sistemas fuentes no. El procesamiento local en los sistemas fuentes no se afecta, todos los análisis necesarios para soporte a la toma de decisiones se trasladan hacia el Data Warehouse y este se actualiza cuando los sistemas operacionales están fuera de línea sin ocasionar interrupciones innecesarias. La información que más se necesita ya está lista cuando se requiere. Consultas sólo en el ámbito del Data Warehouse. En el Data Warehouse se puede realizar consultas que fuera de él sería muy costosas de conseguir, por restricciones de recursos y tiempo Limitaciones Utilizar repositorios de datos plantea algunos inconvenientes, como por ejemplo:

44 Una herramienta tan imprescindible para la empresa de hoy, necesita de un constante y costoso soporte técnico. Debido a su complejidad, el Data Warehouse es muy particular en cuanto a su funcionamiento se refiere, por lo que se hace necesaria su continua revisión. Una vez implementado puede ser complicado añadir nuevas fuentes de datos. En un proceso de implementación pueden encontrarse dificultades ante los diferentes objetivos que pretende una organización. El diseño e implementación del Data Warehouse resulta caro y toma mucho tiempo puesto que se necesitan obtener muchos datos, y estos se tienen que organizar de la mejor manera para que el Data Warehouse pueda realmente cumplir con su tarea. 2.3 TECNOLOGÍAS Y HERRAMIENTAS Las aplicaciones Cliente/Servidor en conjunto con los Data Warehouses y los sistemas de soporte de decisiones son considerados los primeros éxitos tangibles para un DBMS 5 relacional. La razón principal de dicho éxito se debió a que los almacenes de datos y los sistemas de soporte de decisiones han logrado aprovechar la flexibilidad y capacidad de efectuar consultas con un único objetivo concreto propias del DBMS relacional. Ahora bien, la flexibilidad de los RDBMS 6 es un elemento que puede explotarse principalmente en aquellas estructuras de datos que se encuentran normalizadas, es decir, que carecen de redundancia y que representan las entidades básicas y las relaciones descritas por los datos. Sin embargo, para un procesamiento analítico en línea suele 5 Data Base Management Systems, por sus siglas en inglés 6 Relational Data Base Management Systems, por sus siglas en inglés

45 requerir de varias operaciones de unión para poder conseguir el conjunto de datos requeridos. Es por eso que el rendimiento de los RDBMS suele ser mejor para consultas basadas en claves que para consultas basadas en contenidos. Es por ello que los diversos proveedores de entornos RDBMS han decidido, en posteriores versiones de sus propios productos RDBMS, dotarlos de características que permiten dar soporte de Data Warehouses denominadas características súper relacionales. Estas características van desde soportar extensiones de datos y operadores relacionales hasta implementar diagramas de indexación especializados. Sin embargo, los RDBMS no son un manejador de bases de datos multidimensionales propiamente, por lo que para lograr una estructura multidimensional simulada deben valerse de tablas múltiples, índices y otros elementos que se suelen orientar más a los entornos relacionales. Si bien en el mercado actual existen una gran cantidad de tecnologías y herramientas que permiten construir soluciones como la anteriormente descrita, la elección de estas depende principalmente de las necesidades de las organizaciones que deseen utilizarlas como solución. De esta manera, se presenta a continuación, un análisis entre el software libre y de uso privado y se explican varias de estas herramientas SOFTWARE LIBRE El software libre debe permitir a los usuarios del mismo, ejecutar, copiar, distribuir estudiar, cambiar y mejorar el software. Esto se define mediante las siguientes cuatro libertades básicas (GNU ORG, s.f.): Libertad 0: La libertad de ejecutar el programa para cualquier propósito. Libertad 1: La libertad de estudiar el código del programa y modificarlo para que realice otras funciones o quitarle aquellas que no necesite

46 Libertad 2: La libertad de distribuir el programa para ayudar al prójimo. Libertad 3: La libertad de distribuir copias de sus versiones modificadas a terceros. Aparte de esto debería tener la libertad de hacer modificaciones del código sin tener que notificar a nadie de los cambios efectuados y compartirlo con otros de manera libre y no regulada es decir, sin tener que notificar a su programador o a algún ente específico. Para el software libre se debe proveer acceso gratuito al código fuente del programa de manera tal de cumplir las libertades 1 y 3 que necesitan acceso al código fuente del programa y permiso para modificarlo. Ventajas del software libre: Permite ahorrar o eliminar por completo los costos relacionados con la adquisición de licencias. Existen aplicaciones para todos los sistemas operativos. Es una manera efectiva de combatir la copia ilícita de software. Permite proveer beneficios sociales y tecnológicos a las comunidades. Los programas son puestos a la orden del público para la prueba, detección de fallas y corrección de las mismas. Desventajas del Software libre: Presenta una curva de aprendizaje mayor. No tiene una garantía proveniente del autor, se usa bajo responsabilidad propia. No existe una compañía única que respalde la tecnología. La variedad de distribuciones, licencias de uso, herramientas similares y métodos de empaquetamiento pueden crear confusiones. Puede presentar menor compatibilidad con el hardware

47 2.3.2 SOFTWARE PROPIETARIO El software propietario es un programa informático en el cual el programador o empresa desarrolladora del mismo tiene todos los derechos sobre el mismo, causando así que los usuarios o el público en general tenga limitaciones en cuanto a usarlo, modificarlo o redistribuirlo. Generalmente su código fuente no está disponible o las modificaciones se encuentran prohibidas por motivos de derechos de autor (GenteGeek, 2006). Ventajas del Software Propietario Las empresas desarrolladoras por lo general tienen un departamento de control de calidad que lleva a cabo múltiples pruebas antes de producir el software. El software es de uso generalizado y se puede conseguir personas capaces con experiencia en el uso de los mismos. Generalmente los recién egresados tienen mayor experiencia con el software propietario por los acuerdos entre las universidades y las empresas desarrolladoras. Se encuentra mucha bibliografía especializada en los programas de software privativo y las prácticas para su mejor uso. Las empresas desarrolladoras tienen el presupuesto para la investigación y para contratar a los mejores profesionales en el área de desarrollo de software. Desventajas del Software Propietario Generalmente no existen versiones para todos los sistemas operativos. El funcionamiento del mismo no es conocido por los usuarios

48 Es ilegal modificarlo o distribuirlo sin permiso del fabricante. Presenta restricciones en cuanto a su uso. El costo de las licencias es considerablemente mayor. Se depende de la empresa propietaria para el soporte técnico HERRAMIENTAS PARA LA IMPLEMENTACIÓN DE UN DATA WAREHOUSE Durante esta investigación varias fueron las herramientas analizadas y comparadas. Partiendo desde el mundo del software libre, con Pentaho, hasta el mundo propietario con SQL Server 2000 y Oracle 9i. En este apartado se describen las principales características, herramientas y ventajas de la tecnología Oracle 9i ya que la misma fue la seleccionada para el desarrollo de la solución. De igual manera se coloca una breve Síntesis de los resultados de la comparación realizada entre las distintas herramientas analizadas Oracle 9i Oracle (que en lenguaje griego se refiere a alguien que se encuentra en contacto con las divinidades y que en latín viene de la palabra oraculum o anuncio divino) se ha establecido con el paso de los años en el líder mundial de proveedores de software para el manejo y administración de información de información siendo mejor conocido por sus productos sofisticados de bases de datos relacionales o RDBMS (especialmente Oracle 9i) que suelen ser usados por los más grandes comercios electrónicos de todo el mundo. La base de datos relacional de Oracle fue el primer producto del mundo en ofrecer soporte para el lenguaje estructurado de queries (SQL), ahora un estándar en la industria

49 Cuando el CEO de Oracle, Lawrence J. Ellison, y algunos otros asociados fundaron Oracle en 1997 su objetivo principal fue el de demostrar la equivocación de aquellas personas que soportaban la teoría que las bases de datos relacionales no eran viables comercialmente hablando. Como prueba de su éxito apostaron una cifra inicial de 2000 dólares de inversión y eventualmente llegaron a obtener una ganancia anual de aproximadamente 9.7 billones de dólares. Para Lawrence J. Ellison, CEO de Oracle, la compañía se enfoca principalmente en estaciones de trabajo de alto nivel y les asigna el rol de servidores sobre los cuales corren sus sistemas de bases de datos. Junto con Sun Microsystems, Oracle se considera como un elemento de guía y de estándar de las redes de computadoras. Incluso Oracle se ha autoproclamado como la primera compañía de sistemas en desarrollar y lanzar una línea de productos de software empresariales habilitadas para las conexiones en Internet que abarcan: bases de datos, servidores, aplicaciones de negocios empresariales y herramientas para el desarrollo de aplicaciones que brinden soporte al proceso de toma de decisiones. De hecho, citando a Ellison: si la Internet resulta no ser el futuro de la computación, estamos fritos. Pero si lo es, estamos en el camino correcto Herramientas y Componentes de Oracle 9i En su artículo de Internet ( Oracle 9i makes data warehousing easy to implement, 2002), TechRepublic presenta las herramientas Oracle que, a su criterio, facilitan el proceso de implementación de un DW. Aunque no todas son específicas para el proceso de Data Warehousing pueden ser utilizadas de apoyo:

50 Figura 10: OLAP Oracle; vista de arquitectura Fuente: Constructor de Warehouse (Warehouse Builder): este es uno de los wizards o ayudante de proceso más efectivos que existe. El Warehouse Builder le permite al usuario definir las fuentes de datos; implementar flujos de datos entre fuentes y destinos (procesos ETL extracción, transformación y carga); diseñar y desplegar esquemas; definir todas las tablas con fáciles procesos para el dimensionamiento y definiciones de importación; y diseñar y generar un ambiente para los queries, incluyendo los propios del proceso OLAP. El Warehouse Builder abarca un gran número de opciones para poder personalizar el DW con un nivel alto de detalle. Sin embargo, su uso no es aconsejable para los primeros desarrollos de Warehouses debido a que acarrea el problema común para todos los wizards, intentar modificar algo sobre una estructura ya creada podría volverse una tarea incómoda. Explorador (Discoverer): mediante esta herramienta administrativa/visualizadora se pueden configurar y probar reportes determinados. El poder de esta herramienta se basa en el hecho que funciona con browsers y está integrada con el portal de Oracle. De esta manera, tanto los usuarios internos como externos tienen acceso a este mecanismo de reportes vía Web que puede accesar al DW directamente

51 Enterprise Manager: la arquitectura del DW Oracle está tan bien definida que el Enterprise Manager, que puede ser usado en cualquier base de datos, se convierte en una herramienta ideal de administración para usar con el DW. Con el mismo se puede manejar el transporte de data, respaldo, monitoreo del sistema y cualquier otra actividad administrativa. Servidor de Aplicaciones (Application Server 9iAS): la suite para aplicaciones de Internet de Oracle es una herramienta que han sabido adaptar bien al entorno DW. Elementos como: Internet, seguridad interna, mantenimiento del portal, manejo del tráfico en la red, mensajería entre otros son manejados a través del 9iAS (de hecho, el Enterprise Manager y el Discoverer son parte de él). Otras funcionalidades dentro de estas herramientas son: Oracle tiene mecanismos para facilitar el mecanismo de transformación de la data a través de procesos estacionarios, los cuales suelen ser particularmente útiles en el proceso de ETL del DW. La migración de datos desde las tablas que se encuentran en los sistemas convencionales OLTP hacia el DW se ve mejorada. Oracle también cuenta con mecanismos para el manejo automático de memoria. Esto es particularmente útil en sistemas como los Data Warehouses debido a las constantes fluctuaciones en tamaños de tablas, entre otros elementos. Por otra parte, el soporte Web de Oracle (docs.oracle) indica que la distribución 9i cuenta con los siguientes componentes para brindar soporte a aplicaciones OLAP sobre las cuales funcionan los Data Warehouses:

52 Figura 11: Componentes de Oracle 9i Fuente: Motor de Cálculo: el motor de cálculo OLAP ofrece soporte a la selección y cálculos rápidos de data multidimensional. El estatus de una sesión particular persiste para ofrecer soporte a uno o múltiples queries, lo cual suele ser un requerimiento típico de aplicaciones analíticas; es decir, el resultado de un query puede ser usado como el insumo para otro query. Espacio de trabajo de Análisis: un espacio de trabajo de análisis puede almacenar múltiples objetos de datos multidimensionales y procedimientos escritos en el DML (lenguaje de manipulación de datos) de OLAP. Dentro de una base de datos, muchos espacios de trabajo de análisis pueden ser creados y compartidos entre los usuarios. Al igual que las tablas relacionales, un espacio de trabajo de análisis pertenece a un usuario en particular pero se les puede otorgar acceso a otros usuarios al mismo también. Estos espacios pueden ser temporales (mientras dure la sesión) o pueden ser persistentes, es decir, se mantienen entre sesiones. Los espacios de trabajo de análisis proveen otra alternativa a las vistas materializadas como un medio para el almacenamiento de data agregada

53 OLAP DML: el DML de OLAP es un lenguaje de manipulación de datos que es entendido por el motor de cálculo explicado anteriormente. El DML de OLAP amplia las capacidades de análisis de los lenguajes basados en queries como el SQL y el componente API del OLAP para así incluir predicciones, modelados y simulaciones. Los desarrolladores de aplicaciones pueden crear procedimientos almacenados o stored procedures que usen algún condicional lógico así como la extensa librería de comandos en DML y sus respectivas funciones para realizar análisis complejos de datos. Dicho DML es considerado un lenguaje de cálculo bastante accesible. El DML de OLAP ofrece comandos y funciones en las siguientes categorías: agregaciones, selección de data, operaciones sobre el tiempo y fecha, lectura y escritura de archivos, operaciones financieras, predicciones, manipulación numérica, modelos, operaciones estadísticas y manipulación de textos. Mediante este DML, los administradores de base de datos y los desarrolladores de aplicaciones pueden crear objetos multidimensionales que son almacenados en los espacios de trabajo de análisis. El DML de OLAP opera sobre datos que se encuentran almacenados en dichos objetos. Funciones SQL sobre tablas: las funciones SQL sobre tablas permiten tomar una fila de datos de una tabla como insumo y producir una fila de datos como resultado que puede ser empleada para alguna funcionalidad determinada. Los desarrolladores de aplicaciones que usan SQL pueden accesar a paquetes SQL determinados que usan funciones sobre tablas para crear vistas de datos multidimensionales. Posteriormente, las aplicaciones SQL pueden accesar dichas vistas. API de OLAP: el API de OLAP de Oracle es una interfase de programación para Oracle OLAP. Es un lenguaje basado en queries que selecciona y manipula los datos para ser mostrados en clientes Java. Debido a que el API de OLAP esta hecho completamente en Java el mismo ofrece soporte para aplicaciones de análisis que puedan ser explotadas por usuarios de

54 diferentes comunidades de Internet. Debido a que es un elemento orientado a objetos entonces el desarrollador define el resultado que espera, no el proceso mediante el cual el resultado se obtiene. El API de OLAP se conecta a la base de datos mediante JDBC. Catalogo OLAP: los metadatos son usualmente definidos como datos de datos. El catalogo de metadatos de OLAP es creado y almacenado en tablas relacionales de las bases de datos. Las aplicaciones OLAP pueden realizar diversos queries sobre este repositorio de metadatos para conocer cuáles datos se encuentran disponibles para análisis y muestra. Los metadatos contienen información sobre la localización física de los datos, es decir, si se encuentran almacenados en alguna tabla relacional particular o en un espacio de trabajo de análisis. Ya sea que los datos se encuentran almacenados en esquemas relacionales o en espacios de trabajo analíticos, los metadatos identifican elementos como las dimensiones, los niveles y los atributos. Los metadatos ofrecen información crítica e importante sobre la selección, manipulación y muestra de los datos Ventajas Como se ha analizado hasta el momento, los tópicos descritos en el apartado anterior son algunos de los diversos elementos que ofrece Oracle para facilitar el desarrollo de aplicaciones OLAP como los Data Warehouses. Incluso en una versión como la que se está discutiendo se han podido observar grandes esfuerzos y avances sobre el área de desarrollo de Data Warehouses validando de esta manera la importancia que trae consigo este tipo de tecnología para el ámbito empresarial. Se pueden inferir de (Burleson Consulting, 2005) los elementos que ofrece Oracle para aumentar el rendimiento (performance) y los tiempos de respuesta de un Data Warehouses

55 A nivel de mejora en el rendimiento: Vistas materializadas: este elemento del entorno Oracle se vale de la replicación para permitir la sumarización y la unión (JOIN) anticipada de tablas. Lo mejor de todo, es que dichas vistas están integradas con el elemento de reescritura de queries de Oracle, por lo tanto, cualquier query que pueda beneficiarse de dicha sumarización anticipada será reescrito para referenciar dicha vista, por lo tanto el procesamiento se estaría ahorrando tiempo en la inspección de grandes cruces de tablas. Carga de repositorio automatizada: este elemento va de la mano con el elemento anterior ya que a través de diversos procesos de análisis de datos puede crear las vistas materializadas más óptimas para el DW. Se podría decir que este es un elemento heurístico crítico para el proceso de evolución (tunning) del DW y para la identificación de vistas materializadas. Optimización del query estrella (STAR): dicho elemento permite realizar queries que soportan el proceso de toma de decisiones a velocidades bastante eficientes. A nivel de mejora del procesamiento de datos: Proceso de captura de cambios de datos asíncrono: este elemento permite lo que se conoce como extracción incremental, es decir, solo se extrae la data de los sistemas fuentes que ha sido modificada. Por ejemplo, si un DW extrae datos de un sistema operacional semanalmente, entonces el DW requiere únicamente la data que ha sido modificada desde la última extracción (es decir, la data modificada en los últimos siete días). Flujos Oracle: los mecanismos de flujos Oracle permiten capturar sólo aquellos datos que han sido modificados de las fuentes de datos origen y enviarlos al DW destino. Esta es la base sobre la que se ejecuta el proceso

56 explicado anteriormente (proceso de captura de datos asíncrono) y su ventaja recae en el hecho que de esta manera se evita la saturación de la base de datos de producción. A nivel mejora del tráfico de datos y manejo del disco: Administración automática del almacenamiento: mediante este método el subsistema de procesos I/O del disco elimina la tarea tediosa de balancear los procesos de carga I/O y la administración propia del mismo (disco). Mediante este mecanismo todos los discos pueden formar un cluster, dando origen a grupos de discos, y los data files o archivos de datos pueden repartirse a lo largo de dichos grupos. Manejo especializado del buffer de datos: mediante este elemento los desarrolladores pueden determinar cuáles tablas dimensionales o de hechos deberían permanecer siempre en caché, de esta manera se optimizan los procesos de búsqueda de información particularmente a nivel del tiempo empleado para las mismas (búsquedas) SÍNTESIS Se puede cerrar el entorno comparativo establecido en este capítulo indicando que no es del todo cierto asumir que Oracle 9i es mejor que el SQL Server 2000 de Microsoft o viceversa y que ambos son mejores que Pentaho por sus propiedades de software propietario. Los 3 productos pueden ser usados para construir sistemas estables y eficientes. Dicha eficiencia y estabilidad, tanto de las aplicaciones como de las bases de datos, van a depender más de la experiencia de los administradores y desarrolladores de las bases de datos que del proveedor de la solución. Pentaho tiene una enorme ventaja a su favor, está basado en código abierto y por lo tanto hereda sus libertades. Prácticamente cualquier persona entendida en la materia puede tener acceso a esta solución en su versión gratuita y puede adaptarlo a cualquiera de sus necesidades

57 SQL Server 2000 tiene dos puntos a su favor muy importantes; es más barato de adquirir que Oracle 9i y usualmente es considerado como un producto más fácil de instalar y administrar. Por otro lado, el costo elevado del Oracle 9i se ve compensado con el hecho de que puede ser soportado por múltiples plataformas así como también por el hecho de poseer un lenguaje transaccional más potente que SQL Server 2000 y Pentaho así como también de parámetros de configuración, que pueden establecerse desde el inicio, mas granulares que sus competidores. Por lo tanto, la decisión va a depender de qué tipo de necesidades desee cubrir la empresa y cuánto capital esté dispuesta a invertir en implementar una solución que satisfaga dichas necesidades. El caso específico de este TEG la decisión de la Corporación en la que será desarrollado fue utilizar Oracle 9i. 2.4 PROCESO DE GENERACIÓN DE CRÉDITOS DEL ÁREA CREDITICIA DE LA EMPRESA AUTOMOTRIZ Crédito El término crédito proviene del latín creditum, de crederek, tener confianza. La confianza es la base del crédito, aunque al mismo tiempo implica un riesgo. El crédito sin la confianza es inconcebible, crédito es confianza. John Stuar Mill en su Economía Política definió al crédito como el permiso para usar el capital de otro. En los negocios, crédito es la confianza dada o tomada a cambio de dinero, bienes o servicios

58 La operación de crédito puede definirse como: la entrega de un valor actual, sea dinero, mercancía o servicio, sobre la base de confianza, a cambio de un valor equivalente esperado en un futuro, pudiendo existir adicionalmente un interés pactado. Hay crédito siempre que exista un contrato a término (verbal o escrito); esto es, un contrato que engendre obligaciones cuya ejecución sea diferida para una de las partes en lugar de exigirla a ésta inmediatamente. Por eso en su acepción jurídica el crédito es una promesa de pago que establece un vínculo jurídico entre el deudor y el acreedor. Por una parte el deudor tiene la obligación de pagar, y por otra, el acreedor tiene derecho de reclamar el pago Proceso de tramitación del Crédito Según el análisis general del proceso de tramitación de reembolso del área de Crédito de la empresa automotriz a estudiar, el proceso consta de 5 fases que se listan a continuación: Recepción de la documentación y apertura de la Solicitud de Crédito Análisis de la solicitud Liquidación del contrato Ciclo de vida del contrato Terminación del contrato Recepción de la documentación y apertura de la Solicitud de Crédito En esta primera etapa el empleado de la empresa automotriz recibe toda la documentación necesaria, por parte del cliente, para poder realizar la apertura de una solicitud de crédito. Realiza una primera verificación sobre la documentación recibida y la contrasta con la lista de recaudos mínimos necesarios para realizar la apertura. Si todo se encuentra correcto entonces procede a crear en el sistema la solicitud de crédito

59 Además de realizar la apertura de solicitudes nuevas, en esta fase también se realiza la reconsideración de solicitudes existentes. De cualquier forma una reconsideración significa para la empresa automotriz la creación de una nueva solicitud. Por lo tanto la misma debe atravesar nuevamente todo el ciclo. En esta fase todas las solicitudes se cargan con un estatus por defecto llamado abierto Análisis de la Solicitud de Crédito En esta fase los diversos analistas crediticios de la empresa hacen un estudio con mayor profundidad de la solicitud que se creó en la fase anterior. En dicho estudio contemplan toda la información enviada por el cliente y determinan si la misma se adapta a los criterios de aceptación de la empresa con la finalidad de aprobar de manera satisfactoria la solicitud ó si por el contrario rechazarla. Como se mencionó en el apartado anterior además de solicitudes nuevas también deben estudiarse solicitudes reconsideras. Dichas reconsideraciones pueden suceder por los siguientes motivos: Una solicitud aprobada no se liquidó en el lapso indicado y por lo tanto caducó. Sin embargo, si el cliente desea reactivarla entonces la misma se reconsidera para su nueva aprobación. Una solicitud es rechazada por un motivo que permite la reconsideración. En este caso se corrigen los motivos que generaron su rechazo en primer lugar y la solicitud vuelve a analizarse para una posible aprobación. Una solicitud de crédito debe terminar el día con uno de los siguientes tres estados terminales definidos por la empresa: Preaprobado: Es el estado por defecto en el que debe terminar la solicitud si durante el día no pudo ser debidamente analizada

60 Aprobada: Es el estado óptimo en el que se especifica que la solicitud ha sido recibida, analizada y procesada de manera satisfactoria. De esta manera sólo faltaría convertir a la solicitud en un contrato. Rechazada: Es el estado que determina que ocurrió algún inconveniente en alguna de las fases y que por lo tanto la solicitud no puede ser procesada de manera exitosa Liquidación del Contrato En esta fase sólo entran las solicitudes que han sido aprobadas en la fase anterior. Desde el momento en el que la solicitud es aprobada comienza a correr un tiempo de aproximadamente tres meses para que la solicitud pueda ser convertida en un contrato. En esta fase pueden generarse los siguientes comportamientos: Si el cliente logra consignar los documentos necesarios y los mismos se encuentran correctos entonces la solicitud se vuelve un contrato. Si el cliente consigna los documentos pero los mismos no cumplen los criterios de la empresa entonces comienza un proceso de iteración entre el cliente y la empresa para que dicha documentación pueda consignarse de manera correcta y por lo tanto poder generar un contrato. En este comportamiento la solicitud entra en un estado de retención. Si transcurre el tiempo de gracia (los tres meses mencionados anteriormente), y el cliente no consignó ningún documento o no pudo solventar los errores que evitaron que la solicitud pasara a ser convertida en contrato entonces dicha solicitud se vence. Sin embargo el cliente puede optar a una reconsideración de la misma con la salvedad mencionada en la fase anterior

61 La liquidación del contrato ocurre entonces cuando la solicitud ha sido convertida exitosamente en un contrato y la empresa ha transferido el monto del mismo hacia el cliente Ciclo de vida del Contrato En esta fase entran aquellos contratos que han sido liquidados de manera exitosa. Esta fase es de alguna manera más automática que las anteriores porque se basa en el estudio y seguimiento que se va realizando sobre el contrato en términos de cancelación de cuotas (interés y capital) y generación de morosidad. Esta área la controla de manera más precisa el departamento de cobranzas de la empresa Terminación del Contrato Esta es la fase final del ciclo de vida de un crédito para la empresa. La terminación del contrato por parte de la empresa puede ocurrir por algunos de los siguientes motivos: Todas las cuotas han sido canceladas exitosamente y por lo tanto el contrato culmina su ciclo de vida de manera satisfactoria. Por diversos motivos la empresa no pudo seguir percibiendo ganancias por el cobro de las cuotas del contrato y por lo tanto debe ejercer medidas extraordinarias para garantizar la finalización exitosa del contrato. Si aún así es imposible para la empresa seguir obteniendo ganancias por dicho contrato entonces deciden terminarlo pero de manera insatisfactoria

62 CAPÍTULO III MARCO METODOLÓGICO Como se ha venido explicando en capítulos anteriores, el desarrollo de un Data Warehouse debe tomar en cuenta las necesidades de los usuarios en cuanto a la presentación de informes y análisis. De no tener presente este precepto entonces el Data Warehouse pasaría a ser un simple repositorio de datos del que sería difícil obtener la información requerida por los usuarios. Para que un Data Warehouse pueda cumplir el objetivo para el cual se desarrolla, los procesos de negocio deben seleccionarse minuciosamente con el objetivo de modelarlos, estableciendo de esta manera una granularidad para cada uno de ellos. Es por ello que resulta sumamente importante entender todos los datos de los diferentes sistemas sobre los que se va a nutrir el Data Warehouse y sus respectivas relaciones. La gestión de estas relaciones, que suelen ocurrir en el momento de la carga, es crucial en todo el proceso. Un enfoque exitoso de Data Warehousing debe contemplar mucho más que el proceso de diseño. Las situaciones envuelven la arquitectura de datos del Data Warehouse, la cultura organizacional, los roles y responsabilidades cambiantes, la calidad de datos, integración de datos y demás, por lo que es imperativo reconocer que no existe un único método aplicable a toda empresa u organización pues cada una es única, sino mas bien conocer y comprender cuales son las filosofías y metodologías más exitosas para utilizarlas y obtener mayores beneficios, en lugar de enfocarse en una sola y disminuir la perspectiva. Sin importar el autor de las metodologías lo que todas tienen en común es que pueden agruparse en dos grandes grupos; las metodologías top-down y las metodologías bottom-up. 3.1 ENFOQUE TOP-DOWN

63 Este enfoque es ideal cuando se tiene un conocimiento previo de la tecnología y las necesidades de la empresa. Se trata de un método sistémico, que minimiza los problemas de integración pero que resulta ser costoso debido a la gran cantidad de datos que debe manejarse y a la poca flexibilidad inherente en esta metodología. La esencia de esta metodología es ir desde lo más general a lo más específico. Esto quiere decir que primero debe formularse un resumen del sistema sin especificar detalles para luego redefinir cada parte del sistema con mayor detalle y así sucesivamente hasta que la especificación completa sea lo suficientemente detallada para validar el modelo. Uno de los elementos que más suele ayudar en el diseño son las llamadas cajas negras aunque las mismas no expliquen en detalle los componentes individuales. Una de las principales ventajas de este enfoque radica en que mediante el mismo el Data Warehouse resultante se enfoca realmente en las necesidades del cliente y por lo tanto su proceso de apoyo al proceso de toma de decisiones es más preciso. Por otro lado, este enfoque tiene como inconveniente principal que aumenta la complejidad en la obtención de información para la carga de datos, sobre todo en los casos en los que las fuentes no se encuentran automatizadas. Este enfoque se basa en la visión de Bill Inmon quien considera que el repositorio de datos debe responder a las necesidades de todos los usuarios en la organización y no solo a un pequeño grupo. Bill Inmon fue el primero en definir y defender el concepto de Data Warehouse, por lo cual se le conoce como el padre del Data Warehouse, además de proponer estructuras como el ODS (Operational Data Store) o la Fábrica de Información Corporativa (Corporate Information Factory) y de una estrategia corporativa para la construcción de Data Warehouses

64 3.1.1 Metodología propuesta por Bill Inmon Esta metodología fue definida por el autor en el año 1992 en el libro Building the Data Warehouse (Bill Inmon, 1992). En él se proponen los mecanismos necesarios para llevar a cabo la correcta realización de un Data Warehouse. Inmon presenta dos descripciones del camino a seguir para la construcción de un Data Warehouse. Un plan de migración y una metodología. La metodología describe actividades específicas, y el orden en el que deben ejecutarse las actividades sin embargo, las dinámicas inherentes a los procesos no son descritas. Mientras que el plan de migración describe actividades generales dinámicamente que deben ejecutarse a lo largo de todo el desarrollo. Cuando ambos elementos se miran en conjunto conforman la esencia del Data Warehouse que desea construirse. A continuación se explorará de manera general ambas descripciones. Figura 12: Metodología orientada a Datos Fuente: Inmon,

65 Sobre la metodología, Bill Inmon argumenta que los ambientes del Data Warehouse son dirigidos por los datos en comparación con los sistemas clásicos los cuales tienen un ciclo de vida de desarrollo dirigido por los requerimientos. Él mantiene que los requerimientos son el último elemento a ser considerado en el ciclo de vida del proceso de desarrollo del soporte de decisiones, los mismos son finalmente entendidos luego que el Data Warehouse ha sido poblado con data y los resultados de los queries han sido analizados por los usuarios. Uno de los aspectos sobresalientes de la metodología dirigida por los datos es que la misma construye a partir de esfuerzos previos construye sobre ambos código y procesos que han sido desarrollados con anterioridad. La única forma en que el desarrollo sobre esfuerzos previos pueda ser completado es mediante el reconocimiento de aspectos comunes. Esto quiere decir que antes que el desarrollador inicie su trabajo, él o ella necesita entender y conocer lo que realmente existe y como eso se relaciona con el desarrollo del Data Warehouse. Esta fase es esencial en la metodología. Una metodología dirigida por los datos tiene dos características importantes (Inmon, 1992): Se enfoca en utilizar el código y los datos que han sido elaborados previamente como base para la nueva construcción en lugar de construir alrededor de ellos. Para realizar esto, es imperativo el reconocimiento de aspectos comunes en los datos y el procesamiento, la clave para este reconocimiento es el modelo de datos. Hay un énfasis en el repositorio central de datos El Data Warehouse como la base para el procesamiento de soporte a la toma de decisiones, lo que reconoce que el procesamiento de soporte a la toma de decisiones tiene un ciclo de vida de desarrollo sumamente diferente a los sistemas operacionales. La metodología propuesta por Inmon explica los resultados que deben obtenerse y el orden en el que deben estar ejecutados los pasos. La manera en la que los resultados sean logrados es un elemento que se deja enteramente a juicio del desarrollador. La

66 metodología la dividió en tres partes componentes, incluye actividades las actividades clásicas necesarias para que sea una metodología dirigida por los datos (Inmon, 1992). A continuación se definirán de manera general los elementos constitutivos de cada una de las partes componentes de la metodología (Inmon, 1992) Parte 1: Desarrollo de Sistemas Operacionales Actividades iniciales del proyecto: se basa en la recolección de cada uno de los requerimientos a través de entrevistas, recopilación de datos. Uso de código y datos existentes: como la premisa indica, en este elemento debemos considerar todos los elementos reutilizables posibles. Determinación de tamaño y fases: en este punto se divide el proyecto en fases lo más pequeñas y manejables posibles. Formalización de los requerimientos: asegurar que los requerimientos sean completos, organizados, legibles, comprensibles y a un nivel de detalle que permita ser efectivos. Sobre el Modelado de Datos Diagrama Entidad Relación: a partir de los requerimientos ya definidos se definen los elementos constitutivos del sistema y la relación de cardinalidad entre ellos. Conjunto de Elemento de Datos: cada tema es dividido en conjunto de elementos de datos (CED). Los CED contiene los atributos de los datos, agrupamiento de los atributos, claves, tipos de datos, conectores y agrupamiento secundario de los datos. Solo los datos primitivos se manejan aquí

67 Análisis de Desempeño: este elemento permite pulir los elementos de ingreso y actualización de data haciendo el proceso más eficiente. Diseño físico de la Base de Datos: se obtienen las tablas y bases de datos diseñadas físicamente, luego de transformar todas las consideraciones lógicas de diseño de datos, desempeño, actualización, ingreso, disponibilidad, etc. Sobre el Especificaciones de Proceso Descomposición Funcional: es la descripción de todas las actividades a ser realizadas durante el desarrollo desde el nivel alto hasta un nivel bajo. Nivel de Contexto 0: corresponde a D1, Diagrama Entidad-Relación, en el modelado de datos. Nivel de Contexto 1-n: los niveles restantes de la descomposición funcional describen más detalladamente las actividades que ocurren, de manera ordenada, organizada, completa y en concordancia con el flujo de actividades. Diagramas de Flujo de Datos (DFD): existe un DFD para cada nivel de contexto n, indica la entrada de un proceso, la salida del proceso, el almacenamiento de datos necesario para establecer el proceso y una breve descripción del proceso. Especificaciones Algorítmicas: los procesos de cada DFD se dividen en especificaciones algorítmicas detalladas, tomando en cuenta los aspectos de desempeño que deben ser resueltos en el diseño de los programas. Pseudocódigo: los algoritmos y especificaciones de programas se refinan en pseudocódigo, el cual debe incluir completitud, orden de ejecución, todos los casos requeridos. Corresponde a D4 en modelado de datos

68 Codificación: construcción del código fuente. La traducción completa y eficiente de pseudocódigo en código, incluyendo la documentación en código. Caminata: explicación verbal del código a los colegas, para encontrar y corregir la mayor cantidad de errores posibles antes de las pruebas. Compilación: el código fuente es compilado y se corrigen todos los errores encontrados. Pruebas unitarias: pruebas del código a diferentes niveles. Implementación: esta etapa incluye actividades como; descarga inicial de datos, conversión de datos, escritura de la documentación y establecimiento de procesos de respaldo Parte 2: Desarrollo del Data Warehouse Este es el componente de la metodología que se ocupa del desarrollo de sistemas y procesamiento de soporte a la toma de decisiones. Análisis del Modelo de Datos: confirmación que el modelo de datos de la organización es sólido y que contiene la identificación de los temas de mayor interés, cada tema tiene separada su propia definición de datos: subtipos de datos, atributos, relaciones, identificación de claves, entre otros. Análisis Breadbox: permite la determinación del tamaño estimación brutadel entorno de los sistemas de soporte de toma de decisiones. Simplemente proyecta, en términos crudos, qué cantidad de datos mantendrá el Data Warehouse

69 Valoración Técnica: contiene definiciones técnicas que tienen la habilidad de manejar grandes cantidades de datos, permitir que los datos sean ingresados flexiblemente, organizar los datos de acuerdo al modelo de datos y tanto recibir como enviar datos a una amplia variedad de tecnologías. Preparación del entorno técnico: instalación, ubicación y desarrollo de los componentes técnicos que recibirán los datos. Análisis de los temas del Data Warehouse: determinación del tema que será el primero en implementarse. Diseño del Data Warehouse: este subelemento toma en cuenta las siguiente características; acomodación de los niveles de granularidad, orientación de los datos a los principales temas de organización, la ausencia de datos que no apoya al sistema de soporte de las decisiones, desnormalización donde sea aplicable y finalmente adaptar los datos del entorno operacional al entorno analítico. Análisis de los sistemas fuentes: identificación del sistema de registro, es decir el mapeo de los datos del ambiente operacional al ambiente analítico. Especificaciones: aquí verifica qué datos operacionales deben ser obtenidos y cómo guardarlos. Programación: programas de transformación que permitan la extracción, integración y ubicación en perspectiva de tiempo de los datos. Población: Ejecución de los programas desarrollados en las etapas anteriores. Se deben resolver los aspectos de frecuencia de población, reglas de purga, administración de múltiples niveles de granularidad y refrescamiento. Con este paso final se obtiene un Data Warehouse poblado y funcional, accesible y comprensible que sirve las necesidades de las comunidades de los sistemas de soporte a la toma de decisiones

70 Parte 3: Uso del Data Warehouse Este último componente describe el uso del Data Warehouse para propósitos de análisis. Repetición del desarrollo estándar: para la obtención de reportes estándares, el procesamiento analítico repetitivo debe seguir el procesamiento normal descrito en la Parte 1, exceptuando el modelado de datos, porque la fuente de datos es el mismo Data Warehouse. Una vez comentados los elementos constitutivos de cada una de las partes de la metodología vamos a abordar el segundo elemento de la visión de Inmon, el Migration Path Plan de Migración (Migration Path) El punto de arranque del plan de migración es el modelo de datos. El modelo suele representar las necesidades de la organización, no necesariamente lo que realmente tiene. Según Inmon (1992), el modelo de datos debe representar lo siguiente: Atributos Las claves Los grupos repetitivos de atributos y claves Conectores entre las áreas de los temas principales Relaciones de subtipos Una vez que se ha definido el modelo de datos es necesario definir el sistema de registros, el cual se define en términos de los sistemas existentes que la organización ya tiene

71 La determinación de la mejor fuente de datos se basa en los siguientes criterios: Datos más precisos Datos más cercanos a la fuente de entrada Datos más cercanos a la estructura del modelo de datos Datos más completos El siguiente paso consiste en diseñar el Data Warehouse. Si el modelo de datos está elaborado correctamente solo se deben cambiar algunos aspectos para hacerlo más fiel a un diseño de Data Warehouse. Luego del diseño de datos, el siguiente paso es diseñar y construir las interfaces entre el sistema de registro y el Data Warehouse, las cuales poblarán el Data Warehouse en periodos de tiempo regulares. Entre las actividades que realizan las interfaces tenemos: Integración de los datos Alteración de las bases de tiempo de los datos Condensación de los datos La etapa final de este plan de migración es iniciar la población del Data Warehouse con el primer tema de interés. Es importante que sólo una parte del Data Warehouse sea poblada, de esta manera cuando surjan los cambios, a partir de los procesos iterativos de análisis y reconocimiento de la data, los mismos sean fáciles de manejar e implementar. Una vez que el usuario final tiene acercamiento a los datos y proporciona retroalimentación al arquitecto de datos, entonces puede ser sano poblar cantidades mayores de datos. De esta manera podemos ver la relación que establece Inmon entre los dos componentes de su visión. El componente Migration Path es quien dictamina los pasos a ejecutar para el desarrollo del Data Warehouse, mientras que el componente de metodología describe cuáles son los pasos que debe ejecutarse dentro de cada paso del Migration Path

72 A modo de síntesis, la visión de Inmon orientada a los datos y no a los requerimientos puede traer consigo mucho riesgo a la compañía, ya que invierte grandes esfuerzos en el desarrollo del Data Warehouse y no es hasta la aparición de los Data Marts cuando se empieza a explotar la inversión y obtener beneficios. Este riesgo se sustenta en el hecho de que los cambios no empiezan a surgir sino ya muy avanzado el desarrollo, de hecho en fases iniciales de pruebas, lo que trae consigo que intentar implementar dicho cambio pueda resultar bastante costoso para la compañía y poner en peligro el éxito de todo el proyecto. Lo cual podría evitarse con una detección temprana de los cambios en base a un primer avance del Data Warehouse. Finalmente, la naturaleza global del enfoque de Inmon hace que su visión resulte más atractiva a la hora de desarrollar un Data Warehouse a gran escala, pero para desarrollos de Data Warehouses más pequeños, en los que el factor tiempo también es importante, esta metodología no suele resultar como la más atractiva. 3.2 ENFOQUE BOTTOM-UP Este enfoque tiene como motor de funcionamiento el mecanismo de experimentos y prototipos y cuyo costo suele ser menor que el enfoque anterior. En el enfoque bottom-up se van construyendo Data Marts relativamente independientes para ir midiendo las ventajas a medida que se va avanzando. A medida que los Data Marts resultan exitosos se comienzan a enlazar con otros Data Marts previamente realizados y así sucesivamente hasta que se tiene la completitud del sistema. Las estrategias bajo las que funciona el enfoque bottom-up se basan en el conocimiento de todas las variables que circundan al sistema. Entre las ventajas que manera este enfoque tenemos: Asegura que el Data Warehouse maneje toda la información de los sistemas OLTP que requiera

73 Permite automatizar los procesos de carga de data para así simplificar procesos de mantenimiento y administración de la información. Por otro lado, algunos de los inconvenientes de este enfoque son: Integrar los diversos Data Marts probados puede llegar a ser una tarea bastante compleja, particularmente porque las iteraciones de un Data Mart son diferentes a las del siguiente. Bajo este enfoque se excluye del modelo de datos información que el Data Warehouse podría necesitar para su proceso de toma de decisiones. Este enfoque se adapta a la visión de Ralph Kimball quien considera que el factor tiempo a la hora de explotar las bondades de un Data Warehouse es un elemento determinante a la hora de decidirse por esta tecnología. Este enfoque parte de los requerimientos de negocio, mientras que el enfoque top-down deja la validación de requerimientos para el final del proceso Metodología propuesta por Ralph Kimball Junto con Inmon, Ralph Kimball se ha vuelto un punto de referencia esencial en el área del desarrollo de sistema de apoyo a las decisiones empresariales. En su primer libro, The Data Warehouse Toolkit (R. Kimball, 1995), el autor hace su primer acercamiento al mundo del Data Warehouse mostrando cómo usar el modelado multidimensional para diseñar un Data Warehouse. Posteriormente, en la edición de The Data Warehouse Toolkit (R. Kimball, 1998), el autor presenta y explica la metodología que hace uso de las técnicas de la edición anterior para la construcción de Data Warehouses y Data Marts más completos. Esta metodología se basa en la reinterpretación de la frase Ciclo de Vida, que suele usarse en el argot computacional para referirse a todos los pasos del proceso de desarrollo de software pero adaptados a la visión de desarrollo de Data Warehouses, en

74 ella se describe paso a paso cómo diseñar, desarrollar y desplegar Data Warehouses y Data Marts. El libro también aborda el proceso de construcción de inicio a fin de forma iterativa y también se muestra la utilización de las técnicas del modelado dimensional. En el mismo, Kimball se muestra mucho más técnico que los autores anteriores logrando descripciones más detalladas. La siguiente figura ejemplifica la visión del Ciclo de Vida propuesto por Ralph Kimball: Figura 13: Ciclo de Vida de la Metodología de Ralph Kimball Fuente: Kimball, 1995 A partir de la figura anterior se puede entonces dividir la metodología en: Administración del proyecto y requerimientos En su metodología Kimball plantea que los pasos iniciales para el desarrollo de un Data Warehouse son la planeación del proyecto y la obtención de requerimientos. Cada elemento cumple funciones determinadas

75 Planeación y Gestión del Proyecto: Este es el primer paso que debe llevarse a cabo para poder iniciar el desarrollo del Data Warehouse. En este paso se establece la situación actual de la empresa y se elabora un plan para el proyecto, definiendo el alcance del mismo. Obtención de Requerimientos: Este paso se refiere a la implementación de los mecanismos necesarios para poder obtener datos de la información que la empresa desea que se manejen en el Data Warehouse. Dichos datos son los que le darán sentido al Data Warehouse. Los mecanismos a emplear para obtener dicha información van desde entrevistas hasta sesiones con un facilitador Diseño de datos o modelado dimensional El modelado dimensional, según su creador Ralph Kimball, es el diseño tanto físico como lógico que se va a encargar de transformar las fuentes de datos, previamente definidas en el paso anterior, en estructuras aptas para el Data Warehouse. Cada modelo dimensional está compuesto de una tabla que tiene una clave compuesta llamada tabla de hechos y un conjunto de tablas más pequeñas llamadas dimensiones. Cada tabla dimensión tiene una clave primaria simple, que a su vez forma parte de la clave compuesta de la tabla de hechos. Esta descripción se refiere al esquema estrella explicado en el Capítulo 2. Para Kimball (R. Kimball, 1998), los pasos necesarios para convertir un Diagrama Entidad-Relación (ERD) a un conjunto de diagramas que se basan en el modelado dimensional son: Separar el Diagrama Entidad-Relación en procesos finitos y discretos e irlos modelando por separado. Determinar cuáles serán las tablas de hechos mediante la selección de las relaciones muchos a muchos del modelo que no tengan claves primarias simples

76 Crear las tablas dimensionales desnormalizando todas las tablas y añadiéndoles claves primarias simples. Definir también las tablas dimensionales conformadas que son aquellas que sirven de dimensión a más de una tablas de hechos. Así mismo, Kimball se fundamenta en las siguientes ventajas para proponer el modelado dimensional (R. Kimball, 1998): Soporta cambios inesperados en el comportamiento del usuario. Es capaz de crecer y extenderse para aceptar nuevos elementos de datos y de diseño. Otros elementos que se toman en cuenta dentro del aspecto del modelado dimensional son: La Arquitectura de Bus del Data Warehouse Según Kimball, la arquitectura del bus de Data Warehouse se basa en la idea que un Data Warehouse está compuesto por muchos Data Marts. Cada Data Mart a su vez debe estar representado dentro de un modelo dimensional y compuesto por tablas de hechos y tablas dimensionales. Por lo tanto el autor plantea que es necesario al principio del proyecto definir una arquitectura estricta y finita de datos sobre la cual se desarrollará el Data Warehouse. Posteriormente, y basándose en la arquitectura previamente definida, deben irse construyendo los Data Marts. Kimball explica que cada Data Mart para que sea práctico debe ser basado en los datos más granulares (atómicos) que sea posible colectar y almacenar (Kimball, 1998). La correcta adherencia entre un Data Mart y otro se consigue a través de las tablas dimensionales conformadas, ya que a través de ellas se logra (R. Kimball, 1998): Una tabla dimensional solo puede ser usada contra múltiples tablas de hechos en el mismo espacio de base de datos

77 Las interfaces de usuario y los datos que contienen son consistentes en cualquier instante en que se utilice la dimensión. Existe una interpretación consistente de los atributos en cada Data Mart. A partir de lo anteriormente expuesto podemos entender que las dimensiones conformadas son las que hacen de bus en el Data Warehouse. Por lo tanto, al definir una interfase estándar de bus (mediante dimensiones conformadas) un nuevo Data Mart puede añadirse al Data Warehouse y coexistir con los otros sin ningún inconveniente. Elementos del Modelado Dimensional Los siguientes son elementos esenciales para el Modelado Dimensional Hechos: un hecho es una observación del mercado de trabajo. Atributos: usualmente son campos de texto que describen las características de algo tangible, como las descripciones del producto. Dimensiones: se refiere a los atributos que describen al objeto y que a su vez se correlacionan entre ellos. Método de Diseño de cuatro pasos para diseñar una tabla de hechos Los siguientes son pasos necesarios para un diseño lógico de un esquema dimensional (R. Kimball, 1998): Escoger el Data Mart: como se desea en primera instancia mantener un nivel de simplicidad adecuado entonces es recomendable en lo posible escoger una única fuente de datos para el Data Mart. Declarar la granularidad de la tabla de Hechos: consiste en definir qué se considera una tabla de hechos para el diseño dimensional que se propone

78 Escoger las dimensiones: escoger, en lo posible, aquellas dimensiones que sean capaces de tomar un valor único en el contexto de un conjunto dado de medidas del negocio. Escoger los hechos: los hechos deben ser siempre específicos a la granularidad de la tabla de hechos. No se deben hacer manipulaciones convenientes a otros cálculos porque eso podría afectar la naturaleza del hecho. Construcción de Modelos Dimensionales Kimball concibe cada Data Mart como un modelo dimensional separado y el conjunto de modelos dimensionales constituye el diseño lógico del Data Warehouse. Para la construcción de los Data Marts Kimball propone emplear un enfoque arribaabajo al que llama Matriz de Arquitectura del Data Warehouse, en el cual se identifican todos los Data Marts que se puedan construir y a su vez todas las dimensiones que implican a cada Data Mart, posteriormente se deben relacionar ambos elementos para así definir cuáles dimensiones podrán ser utilizadas por más de un Data Mart. Dichas dimensiones pasarán a formar el denominado Bus de Data Warehouse. En la siguiente etapa, una vez que se han identificado los Data Mart a construir junto con sus respectivas dimensiones, se procede a realizar los diseños físicos y lógicos de las tablas individuales usando el método de cuatro pasos explicado anteriormente. Con todos estos elementos se podrá elaborar entonces un borrador inicial del sistema el cual permitirá identificar los hechos base y los hechos derivados que deberán ser incluidos y así pulir el modelo para adaptarlo mejor a las características y exigencias del negocio. En este proceso se podrán realizar todos los cambios necesarios, los cuales deben estar debidamente documentados, junto a todas las decisiones que se realicen, desde elegir las fuentes de datos hasta determinar las fórmulas de cálculo de los hechos derivados y demás

79 Arquitectura En la siguiente tabla se resume el modelo de arquitectura que propone Kimball. La misma recibe el nombre de marco de trabajo de la arquitectura, donde las columnas muestran las principales área de la arquitectura: datos, técnica e infraestructura y las filas representan los niveles de detalle en orden creciente: requerimientos del negocio, modelo de arquitectura, modelo detallado, implementación. Tabla 2: Marco de trabajo de la Arquitectura Arquitectura de Datos Este nivel abarca tanto el diseño físico y lógico de los modelos de datos. Todo lo relacionado a dicho diseño ya fue explicado en puntos anteriores. Arquitectura Técnica El área de la arquitectura técnica cubre los procesos y herramientas que se aplican a los datos (Kimball, 1998). Esta área está dividida a su vez en dos elementos con sus requerimientos y mecanismos propios: Back Room: responsable de la obtención y preparación de los datos. Es el cuarto de máquinas del Data Warehouse (R. Kimball, 1998, p335). La función principal de este elemento es resolver los problemas de migración y

80 transformación de datos desde las fuentes de datos hasta el entorno Data Warehouse. En la arquitectura del back room, se debe analizar los aspectos relativos a: los sitios donde se almacenan los datos (sistemas fuente), los servicios que proporcionará (extracción, transformación, carga) y la administración de los activos del back room (respaldo y recuperación, entre otros). Front Room: responsable de entregar los datos a los usuarios determinados. La función principal de este elemento es de servir de intermediario entre los usuarios y la información, de manera tal de poder ofrecerle a dichos usuarios lo que necesiten pero sin que los mismos vean las complejidades latentes en dichos procesos. En la arquitectura del front room se deben analizar los aspectos relativos a: los sitios donde se almacenan los datos (herramientas de acceso a los almacenes, entre otros) y los servicios que proporcionarán para el acceso de datos (navegación, acceso y seguridad, administración de consultas, entre otros). Arquitectura de Infraestructura y Metadatos Este apartado se refiere a las plataformas sobre las cuales se va a cimentar el Data Warehouse. La infraestructura incluye el hardware, la red y elementos de bajo nivel que no suelen ser competencia de las otras áreas. Los elementos a tomar en consideración para esta área son: Los requerimientos del negocio: los cuales son los que determinan la dirección a tomar por parte del Data Warehouse. Los factores de la infraestructura del back room: tamaño de datos, volatilidad de la data, hardware, sistema operativo, entre otros

81 Los factores de infraestructura del front room: servidores de aplicación, entre otros. Factores de redes y conectividad: ancho de banda, acceso remoto, conectividad a la base de datos, entre otros Implementación En esta fase de la metodología es necesario contemplar todos aquellos factores que durante fases iniciales y de diseño no fueron contempladas. A nivel del diseño lógico se debe realizar una última revisión sobre el diseño lógico para determinar cuáles hechos deben ser agregados con respecto a qué dimensiones para mejorar así el rendimiento del Data Warehouse. A nivel del diseño físico el mismo debe culminarse. La secuencia básica es iniciar con elementos de planeación, que se refieren a establecer estándares de nomenclatura, de bases de datos, estrategias de seguridad, entre otros. Luego, a partir del estado del diseño físico, realizar un corte preliminar en el tamaño de la base de datos y su respectiva tasa de crecimiento. Al mismo tiempo, cuando se tienen ya definidas todas las tablas, se debe hacer un corte para la estrategia de establecimiento de índices. A partir de este momento se puede dar por concluido el diseño físico y se puede iniciar realmente el proceso de implementación pues se cuenta con suficiente información acerca de lo que ocurre en la base de datos en sus mínimos detalles. Posteriormente quedarían pendientes dos elementos dentro de esta fase de la metodología: la consolidación de datos y construir aplicaciones al usuario final. Sobre la consolidación de datos Kimball propone dividir este proceso en un plan de 10 pasos para conseguir con éxito el proceso de consolidación de los Datos en el Data Warehouse (R. Kimball, 1998):

82 Plan Crear un esquema de alto nivel, muy consolidado, del flujo de fuente a destino. Probar, escoger e implementar la herramienta de consolidación de datos. Bosquejar gráficamente cualquier reestructuración o transformación de datos compleja. Carga de Dimensiones Construir y probar la carga de una tabla de dimensión estática. Construir y probar el proceso de cambio lento para una dimensión. Construir y probar la carga de las dimensiones faltantes. Tablas de hechos y automatización Construir y probar la carga de las tablas de hechos históricas. Construir y probar el proceso de carga incremental. Construir y probar la carga de las tablas de agregaciones. Diseñar, construir y probar las aplicaciones de automatización del proceso de conciliación. Debido a que en esta etapa deben cuidarse todos los detalles de data y los inherentes a la implementación entonces suele considerarse que la etapa de conciliación de datos es una de las más complicadas en el proceso de desarrollo de un Data Warehouse. Sobre la construcción de aplicaciones de usuario final, este proceso está relacionado a la herramienta que se vaya a emplear para el acceso a los datos y por lo tanto deberá brindar soporte a los usuarios con requerimientos de análisis tanto definidos como improvisados

83 Despliegue y Crecimiento Un despliegue exitoso de un Data Warehouse requiere: Planeación del despliegue Despliegue es la convergencia de tecnología, datos y aplicaciones en los escritorios de los usuarios de negocios, junto con la necesaria educación y estructura de soporte al usuario (R. Kimball, 1998). La planeación del despliegue se puede dividir en varias partes. En una de ellas se determina la disponibilidad de los escritorios de los usuarios para su instalación, en otra parte se desarrolla una estrategia para educar al usuario final sobre la mejor manera de explotar las bondades del Data Warehouse. El desarrollo de un plan para brindar soporte al usuario final sobre el uso de la herramienta es fundamental para cimentar el proceso de aprendizaje y así garantizar el éxito del proyecto. Un último elemento a ser tomado en consideración es el desarrollo de un marco de trabajo para la emisión del despliegue. Cada emisión estará definida dentro de nuevos requerimientos que vayan añadiéndose al Data Warehouse o nuevos grupos de usuarios que vayan a hacer uso del mismo. Es importante que cada emisión de despliegue esté debidamente documentada. Mantenimiento y Crecimiento del Data Warehouse Este el último componente dentro de la metodología propuesta por Ralph Kimball. Este apartado se basa en la constante retroalimentación que deberá existir entre los usuarios finales y el equipo técnico de forma de poder medir y proyectar el éxito del proyecto y también gestionar adecuadamente las operaciones del Data Warehouse

84 3.3 ANÁLISIS DE LOS ENFOQUES (W. INMON VERSUS R. KIMBALL) De las metodologías abordadas anteriormente se puede hacer un análisis cualitativo de sus atributos y limitantes, a continuación el análisis: William Inmon El enfoque de W. Inmon ha sido determinante en el proceso de determinar exactamente qué es un Data Warehouse y ha ayudado enormemente al desarrollo de la industria debido al detalle de sus procedimientos a la hora de construir un Data Warehouse. La metodología se W. Inmon se sustenta en el principio que señala que el ambiente de origen de datos y el ambiente de acceso de datos debe estar separado en Bases de Datos y equipos diferentes. Otro de los principios sobre el cual se sustenta el Data Warehouse de Inmon es el de utilizar un Data Warehouse para guardar datos históricos continuos debido a que para poder realizar análisis de información relevante es importante poder hacerlo en base a una franja de tiempo considerable. El enfoque de Inmon suele estar más enfocado a entornos empresariales, donde todo el ámbito empresarial es tomado en consideración desde el principio y no atienden incrementos sino hasta luego de haber culminado el diseño. La idea de esta consideración es para asegurar una solución integral y así evitar la aparición de situaciones inesperadas en el futuro debido a que se conoce con antelación y bastante exactitud la estructura que presentarán los principales núcleos de desarrollo. En su filosofía un Data Mart es sólo una de las capas del Data Warehouse, los Data Marts son independientes del depósito central de datos o Data Warehouse Corporativo y por lo tanto se construyen luego de él. En su visión, Inmon también aboga por usar el modelado dimensional para los Data Mart, sin embargo está convencido que un diseño basado en Diagramas de Entidad- Relación es mucho más adecuado para el Data Warehouse central de mayor magnitud

85 Uno de los problemas que trae este enfoque es que es ideal para los propósitos de desarrollo del equipo de Tecnología de Información pero no para las finanzas de la organización. Debido a que el sistema no puede ser dividido en partes modulares que puedan construirse primero y eventualmente ir explotando mientras se arma todo el proyecto se debe esperar a que todo el desarrollo esté en su lugar para comenzar a sacar provecho del mismo. Es con los Data Marts que se puede empezar a explotar la inversión, sin embargo, en el enfoque de Inmon los Data Marts solo pueden empezar a desarrollarse una vez que el Data Warehouse central esté culminado. Otro de los riesgos inherentes a esta estrategia es que se hace imposible conocer en avance cuáles son las necesidades concretas de información de una empresa, el ambiente dinámico en que se mueve la organización, el cambio de estructura que conlleva el desarrollo de la nueva plataforma y los consiguientes cambios a los sistemas transaccionales que su introducción implica; es muy probable también que una vez que se haya finalizado y puesto en explotación el Data Warehouse se hagan evidentes algunas modificaciones que, por no poder detectarse en un primer avance del Data Warehouse que no existe en este enfoque, traigan consigo inversiones de dinero considerables para poder implementarse. Finalmente, otra de las restricciones suele ser el factor tiempo ya que el enfoque de Inmon consume mucho más tiempo que otras metodologías. Por lo tanto las empresas suelen inclinarse por aquellas metodologías donde puedan obtener resultados tangibles en un espacio menor de tiempo. Ralph Kimball Bajo el enfoque de Kimball el Data Mart es el Data Warehouse, esto se afirma en el sentido de que Kimball expone que al construir los Data Marts ya se está construyendo el Data Warehouse de una manera incremental. Debido a que el Data Mart suele enfocarse más a esfuerzos departamentales que globales es por el que a Kimball se le suele asociar a este tipo de entorno

86 El punto central de la metodología de Kimball se basa en el modelado dimensional. Específicamente en el diseño de los Data Marts, para lo cual utiliza el modelado dimensional en la versión del esquema estrella. El esquema estrella se centra en la desnormalización óptima de los datos para adaptarlos mejor a los requerimientos del usuario. Como hemos indicado anteriormente el enfoque Kimball tiene como premisa abordar el Data Warehouse como un proceso Data Mart a Data Mart que él denomina Implementación Gradual, sin embargo Kimball también pone en claro que lo primero que debe hacerse es analizar la sólida base que representa el Diagrama Entidad- Relación de la empresa y a partir de allí comenzar con el modelado dimensional, es decir, partiendo del entorno global empresarial se identifican los procesos discretos del negocio y partir de allí establecer los posibles Data Marts para finalmente decidir cuál será el que se implementará primero procediendo con el ciclo de vida que expone en su metodología. Para lograr una correcta unión y engranaje entre todos los Data Marts Kimball establece el método de dimensiones conformadas y les asigna el rol de Bus del Data Warehouse. El enfoque Kimball también propone un marco de trabajo sólido, flexible y extensible sobre el cual se constituye la arquitectura que soportará toda la construcción del Data Warehouse. Como se comentó en puntos anteriores dicho marco de trabajo se divide en tres áreas: Datos, Tecnología e Infraestructura, los cuales tienen cuatro niveles de detalles siendo el más bajo la implementación física del Data Warehouse. A nivel de consideraciones, los expertos afirman que el enfoque Kimball trabaja mejor si primero existe una estrategia de implementación en la organización pues de esta forma el equipo puede prepararse con antelación ante las eventualidades de cambios o incluso evitarlos. Otra consideración sobre la metodología de Kimball se enfoca en el corazón de la misma, el modelado dimensional. Un esquema de estrella se construye en base a la modelación de los requerimientos del usuario, lo cual suele determinar la forma y contenido de la estrella. Es por eso que un esquema en estrella suele ser el más óptimo

87 usualmente para el conjunto de usuarios involucrados en el proceso de levantamiento de información o para aquellos usuarios pertenecientes a un mismo departamento y con una idea similar de lo que desean. Sin embargo, cada usuario maneja e interpreta sus requerimientos de manera diferente, por lo que no es de sorprender que diferentes estrellas resulten óptimas para diferentes usuarios y similares entre sí. No tener en cuenta esta visión a la hora de entrar en fase de diseño podría traer como consecuencia que el resultado de una estrella sea inconsistente con el resultado obtenido por otra estrella y poder conciliar dichos resultados se vuelva una tarea titánica que por la incapacidad de realizarse conlleve a cambios en todo el plan de diseño. Es trabajo del equipo de desarrollo lograr un consenso para poder satisfacer, de la manera más completa posible, a todos los usuarios y sus requerimientos. Síntesis La principal diferencia entre las metodologías de Inmon y Kimball radica en la escala, Data Warehouse Corporativo versus Data Warehouse por incrementos. Aunque todos coinciden en que es necesario al iniciar el proyecto analizar el modelo de datos con el que cuenta la empresa, sin embargo, a partir de aquí: Kimball propone desnormalizar el Diagrama Entidad Relación para identificar procesos de negocio más discretos con sus posibles tablas de hechos y dimensiones. Y a partir de ahí comenzar el desarrollo de manera iterativa, un proceso a la vez. Inmon propone un modelado Entidad Relación sobre todo el conjunto de datos empresariales durante la primera iteración del proyecto, de modo que se conozcan qué datos son meramente operativos y qué datos son de soporte a la toma de decisiones. En cada etapa se implementa un área de interés pero solo cuando el Data Warehouse central esté culminado

88 Si se logra determinar que la complejidad de toda la solución de Inteligencia de Negocios a implementar es de una magnitud considerable entonces la visión de Inmon es la solución para dar lugar a un Data Warehouse que satisfaga primeramente este requerimiento. Debido a que el Data Warehouse central es una estructura que está separada de los Data Marts entonces en dicho elemento intermedio se pueden ejecutar tareas de consolidación y limpieza de datos con el fin de alimentar los Data Marts. Para el desarrollo de esta propuesta la metodología a emplear será la de Ralph Kimball debido a que el enfoque que tendrá la solución, la cual radica en un principio sobre un departamento de la empresa, se adapta de manera más efectiva a la visión de este autor en lo referente a la implementación de un Data Warehouse. Otras razones de interés son que a través de dicha metodología se podrán obtener resultados tangibles en tiempos relativamente cortos y también porque se ha logrado determinar que el número de fuentes de orígenes de datos para este departamento es bastante reducido. Todas estas características hacen que la visión de Kimball sea más atractiva para su uso como guía en el desarrollo del Data Warehouse que la de Inmon

89 CAPÍTULO IV MARCO APLICATIVO 4.1 METODOLOGÍA DE DESARROLLO DE DATA WAREHOUSE UTILIZADA La esencia del Data Warehousing en sí es una metodología para alcanzar soluciones a los requerimientos de información del negocio. En este capítulo se describirá el ámbito aplicativo de la presente investigación. El mismo abarca todas las fases que fueron consideradas pertinentes para el desarrollo del proyecto a partir de la metodología para la implementación de Data Warehouses propuesta por Ralph Kimball y que fue explicada en apartados anteriores. De manera implícita se podrá observar cómo cada fase fue cumpliendo con una parte de los diferentes objetivos específicos hasta tener la totalidad de dichos objetivos completada Fase de Planificación del Proyecto Como en todo proyecto software, es necesario realizar una planificación del mismo para tratar de garantizar que el desarrollo se realiza según las fechas previstas. A continuación se presenta la planificación prevista para el proyecto de Data Mart que se está realizando: Figura 14: Planificación del Proyecto Como se puede observar en la figura 14, el mayor tiempo se destina al modelado dimensional, fase que agrupa cuatro subtareas que son: definir modelo del negocio,

90 definir el grano, elegir las dimensiones, identificar los hechos y detallar las dimensiones. A partir de allí comienzan las diferentes fases de implementación que abarcan las aristas del orquestador de cargas (elemento que se encargará de conducir la correcta ejecución del Data Warehouse), implementación de las cargas de los elementos dimensionales y ETLs asociados al Data Mart de crédito y finalmente la implementación de los esquemas de visualización para los indicadores de gestión. Finalmente la fase de pruebas sobre las estructuras previamente diseñadas y construidas Definición de los requerimientos Una vez establecido el planteamiento del problema y los objetivos que brindarán solución a dicho problema se procede a detallar de forma más concreta los requisitos que engloban dichos objetivos; detallando, entre otros atributos, su prioridad, tipo de requerimiento, necesidad y una breve descripción Requerimientos funcionales generales Estos requerimientos deberán aplicar tanto al DM de Crédito como a los otros DM que eventualmente se vayan creando. Identificador Req_Gen00 Nombre Coordinador de Ejecución Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá conducir de manera precisa la corrida diaria de los Descripción: DM asociados mediante un mecanismo de control

91 Requerimientos funcionales del Data Mart de Crédito Estos requerimientos deberán ser satisfechos para considerar al DM de Crédito completado Requerimientos para los Indicadores Fijos de Crédito Identificador Req_Cre00 Nombre Total Solicitudes Retenidas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el total de solicitudes retenidas Descripción: generadas en el mes. Identificador Req_Cre01 Nombre Total Solicitudes Reprocesadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el total de solicitudes reprocesadas Descripción: en el mes. Identificador Req_Cre02 Nombre Total Solicitudes Nuevas - Rechazadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el total de solicitudes nuevas Descripción: generadas en el mes que fueron rechazadas. Identificador Req_Cre03 Nombre Total Solicitudes Nuevas - Preaprobadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el total de solicitudes nuevas Descripción: generadas en el mes que fueron preaprobadas. Identificador Req_Cre04 Nombre Total Solicitudes Nuevas - Aprobadas Tipo: Funcional Fecha:

92 Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el total de solicitudes nuevas Descripción: generadas en el mes que fueron aprobadas. Identificador Req_Cre05 Nombre Total Solicitudes Nuevas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el total de solicitudes nuevas generadas en el mes. Total que resulta de la suma de las solicitudes nuevas-preaprobadas, nuevas-aprobadas y nuevas-rechazadas en el Descripción: mes. Identificador Req_Cre06 Nombre Total Solicitudes Aprobadas No Liquidadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el total de solicitudes que se encuentran aprobadas pero que aún no han originado un contrato en el Descripción: mes. Identificador Req_Cre07 Nombre Total Global de solicitudes Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el total global de solicitudes que se manejaron en el mes. El total global surge a partir de la suma del total de solicitudes nuevas más el total de solicitudes reprocesadas en el Descripción: mes. Identificador Req_Cre08 Nombre Total Contratos liquidados Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el total global de solicitudes que se manejaron en el mes. El total global surge a partir de la suma del total de solicitudes nuevas más el total de solicitudes reprocesadas en el Descripción: mes

93 Identificador Req_Cre09 Nombre Ratio de Solicitudes Reprocesadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el ratio de solicitudes reprocesadas en el mes. Este ratio surge de la relación del total de solicitudes Descripción: reprocesadas en el mes entre el total global de solicitudes en el mes. Identificador Req_Cre10 Nombre Ratio de Solicitudes Rechazadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el ratio de solicitudes rechazadas en el mes. Este ratio surge de la relación del total de solicitudes Descripción: rechazadas en el mes entre el total de solicitudes nuevas en el mes. Identificador Req_Cre11 Nombre Ratio de Solicitudes Rechazadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el ratio de solicitudes rechazadas en el mes. Este ratio surge de la relación del total de solicitudes Descripción: rechazadas en el mes entre el total de solicitudes nuevas en el mes. Identificador Req_Cre12 Nombre Ratio de Solicitudes Pre-aprobadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el ratio de solicitudes pre-aprobadas en el mes. Este ratio surge de la relación del total de solicitudes preaprobadas Descripción: en el mes entre el total de solicitudes nuevas en el mes. Identificador Req_Cre13 Nombre Ratio de Solicitudes Aprobadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el ratio de solicitudes aprobadas en el mes. Este ratio surge de la relación del total de solicitudes aprobadas Descripción: en el mes entre el total de solicitudes nuevas en el mes

94 Identificador Req_Cre14 Nombre Promedio diario de Solicitudes Retenidas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el promedio diario de solicitudes que Descripción: fueron retenidas en el mes. Identificador Req_Cre15 Nombre Promedio diario de Solicitudes Reprocesadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el promedio diario de solicitudes que Descripción: fueron reprocesadas en el mes. Identificador Req_Cre16 Nombre Promedio diario de Solicitudes Nuevas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el promedio diario de solicitudes Descripción: nuevas aperturadas en el mes. Identificador Req_Cre17 Nombre Promedio diario del Total de Solicitudes Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el promedio diario del total global Descripción: solicitudes en el mes. Identificador Req_Cre18 Nombre Promedio diario de Contratos Liquidados Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el promedio diario de contratos que Descripción: fueron liquidados en el mes

95 Identificador Req_Cre19 Nombre Promedio de Monto Financiado Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el promedio del total del monto financiado en el mes. El monto financiado proviene a partir del contrato Descripción: liquidado en el mes. Identificador Req_Cre20 Nombre Promedio diario de Días de Retención Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer el promedio de la cantidad de días de retención en los que estuvieron cada una de las solicitudes retenidas Descripción: en el mes Requerimientos para los Indicadores Dinámicos de Crédito Identificador Req_Cre21 Nombre Cantidad de Solicitudes Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la cantidad de solicitudes por las Descripción: dimensiones que se hayan definido. Identificador Req_Cre22 Nombre Total del monto solicitado en las Solicitudes Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la suma del monto de las solicitudes Descripción: del mes por las dimensiones que se hayan definido. Identificador Req_Cre23 Nombre Cantidad de contratos liquidados Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la cantidad de contratos que se Descripción: liquidaron en el mes por las dimensiones que se hayan definido

96 Identificador Req_Cre24 Nombre Total del monto financiado de los contratos Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la suma del monto financiado de los contratos liquidados en el mes por las dimensiones que se hayan Descripción: definido. Identificador Req_Cre25 Nombre Cantidad de Solicitudes Aprobadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la cantidad de solicitudes aprobadas Descripción: por las dimensiones que se hayan definido. Identificador Req_Cre26 Nombre Cantidad de Solicitudes Pre-aprobadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la cantidad de solicitudes preaprobadas Descripción: por las dimensiones que se hayan definido. Identificador Req_Cre27 Nombre Cantidad de Solicitudes Rechazadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la cantidad de solicitudes Descripción: rechazadas por las dimensiones que se hayan definido. Identificador Req_Cre28 Nombre Cantidad de Solicitudes Reprocesadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la cantidad de solicitudes Descripción: reprocesadas por las dimensiones que se hayan definido. Identificador Req_Cre29 Nombre Cantidad de Solicitudes Aprobadas No Liquidadas Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí

97 Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la cantidad de solicitudes aprobadas Descripción: no liquidadas por las dimensiones que se hayan definido. Identificador Req_Cre30 Nombre Cantidad de Contratos Retenidos Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir conocer la cantidad de contratos retenidos Descripción: por las dimensiones que se hayan definido Requerimientos para el esquema de Visualización Web Identificador Req_Cre31 Nombre Monitoreo Corrida Data Mart Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir visualizar el resultado de la corrida de cada uno de los Data Mart con información de: procesos asociados a dicho Descripción: data mart y eventos generados a partir de los procesos anteriores. Identificador Req_Cre32 Nombre Visualización de Indicadores Generales Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí El sistema deberá permitir visualizar los indicadores generales que se generan en el Data Mart de Crédito con una frecuencia mensual tanto para el último mes que haya cerrado como para todos los otros del año fiscal en curso. Esta funcionalidad está planificada para el nivel Descripción: gerencial de la empresa Requerimientos para el esquema de Visualización Excel Identificador Req_Cre33 Nombre Visualización de Indicadores Dinámicos Tipo: Funcional Fecha: Prioridad: Alta Necesidad: Sí Estabilidad: Normal Verificable: Sí Descripción: El sistema deberá permitir visualizar los indicadores dinámicos que se

98 generan en el Data Mart de Crédito a partir de las Tablas de Hechos asociadas a dicho Data Mart y al mismo tiempo poder filtrar por las dimensiones definidas. Todo esto para ambos procesos Modelado Dimensional El proceso de diseño dimensional propuesto por Kimball se distinguen 5 fases: Definición del Proceso de Negocio En este primer paso se seleccionan los procesos de negocio del modelo. Es decir, todas aquellas actividades que se realizan en la organización y que normalmente cuenta con un sistema de recogida de datos. Para el caso que compete los procesos de negocio se seleccionaron mediante sesiones de trabajo con los usuarios involucrados, abarcando desde el área gerencial del departamento hasta el área operativa, que incluyeron tanto entrevistas como el estudio de la interacción de dichos usuarios con sus sistemas transaccionales. Como se mencionó en el Capítulo 2, el resultado de las sesiones de trabajo ha permitido conocer que el área de Crédito de la empresa automotriz seleccionada gira en torno a dos elementos esenciales; las solicitudes de crédito y los contratos. Ambos elementos son manejados en un proceso general, que a su vez se divide en varias fases, y se denomina Proceso de Tramitación de Crédito. A continuación se vuelven a repasar las fases que constituyen el proceso de tramitación de crédito: Apertura de la Solicitud de Crédito En esta fase se recibe la documentación necesaria por parte del cliente que desea aplicar a un crédito con la compañía. Si todos los recaudos se encuentran correctos entonces se crea la solicitud en el sistema transaccional

99 Además de realizar la apertura de solicitudes nuevas, en esta fase también se realiza la reconsideración de solicitudes existentes. De cualquier forma una reconsideración significa para la empresa automotriz la creación de una nueva solicitud. Por lo tanto la misma debe atravesar nuevamente todo el ciclo. En esta fase todas las solicitudes se cargan con un estatus por defecto llamado abierto. Análisis de la Solicitud de Crédito En esta fase los diversos analistas crediticios de la empresa hacen un estudio con mayor profundidad de la solicitud que se creó en la fase anterior. En dicho estudio contemplan toda la información enviada por el cliente y determinan si la misma se adapta a los criterios de aceptación de la empresa con la finalidad de aprobar de manera satisfactoria la solicitud ó rechazarla en caso contrario. Como se mencionó en el apartado anterior además de solicitudes nuevas también deben estudiarse solicitudes reconsideras. Dichas reconsideraciones pueden suceder por los siguientes motivos: Una solicitud aprobada no se liquidó en el lapso indicado y por lo tanto caducó. Sin embargo, si el cliente desea reactivarla entonces la misma se reconsidera para su nueva aprobación. Una solicitud es rechazada por un motivo que permite la reconsideración. En este caso se corrigen los motivos que generaron su rechazo en primer lugar y la solicitud vuelve a analizarse para una posible aprobación. Una solicitud de crédito debe terminar el día con uno de los siguientes tres estados terminales definidos por la empresa:

100 Preaprobado: Es el estado por defecto en el que debe terminar la solicitud si durante el día no pudo ser debidamente analizada. Aprobada: Es el estado óptimo en el que se especifica que la solicitud ha sido recibida, analizada y procesada de manera satisfactoria. De esta manera sólo faltaría convertir a la solicitud en un contrato. Rechazada: Es el estado que determina que ocurrió algún inconveniente en alguna de las fases y que por lo tanto la solicitud no puede ser procesada de manera exitosa. Liquidación del Contrato En esta fase sólo entran las solicitudes que han sido aprobadas en la fase anterior. Desde el momento en el que la solicitud es aprobada comienza a correr un tiempo de aproximadamente tres meses para que la solicitud pueda ser convertida en un contrato. En esta fase pueden generarse los siguientes comportamientos: Si el cliente logra consignar los documentos necesarios y los mismos se encuentran correctos entonces la solicitud se vuelve un contrato. Si el cliente consigna los documentos pero los mismos no cumplen los criterios de la empresa entonces comienza un proceso de iteración entre el cliente y la empresa para que dicha documentación pueda consignarse de manera correcta y por lo tanto poder generar un contrato. En este comportamiento la solicitud entra en un estado de retención y se le asigna un motivo. Si transcurre el tiempo de gracia (los tres meses mencionados anteriormente), y el cliente no consignó ningún documento o no pudo solventar los errores que evitaron que la solicitud pasara a ser convertida en

101 contrato entonces dicha solicitud se vence. Sin embargo el cliente puede optar a una reconsideración de la misma con la salvedad mencionada en la fase anterior. La liquidación del contrato ocurre entonces cuando la solicitud ha sido convertida exitosamente en un contrato y la empresa ha transferido el monto del mismo hacia el cliente. Ciclo de vida del Contrato En esta fase entran aquellos contratos que han sido liquidados de manera exitosa. Esta fase es de alguna manera más automática que las anteriores porque se basa en el estudio y seguimiento que se va realizando sobre el contrato en términos de cancelación de cuotas (interés y capital) y generación de morosidad. Esta área la controla de manera más precisa el departamento de cobranzas de la empresa. Terminación del Contrato Esta es la fase final del ciclo de vida de un crédito para la empresa. La terminación del contrato por parte de la empresa puede ocurrir por algunos de los siguientes motivos: Todas las cuotas han sido canceladas exitosamente y por lo tanto el contrato culmina su ciclo de vida de manera satisfactoria. Por diversos motivos la empresa no pudo seguir percibiendo ganancias por el cobro de las cuotas del contrato y por lo tanto debe ejercer medidas extraordinarias para garantizar la finalización exitosa del contrato. Si aun así es imposible para la empresa seguir obteniendo ganancias por dicho contrato entonces deciden terminarlo pero de manera insatisfactoria

102 A partir de la información anterior se entiende que la necesidad de información y análisis radica en conocer la cantidad de solicitudes y contratos por cada uno de los estados asociados al flujo de trabajo de cada elemento así como el total de solicitudes y contratos que representa la sumatoria de todos los estados; esto tanto para el cierre del día como para el cierre al mes. En general, el DM permitirá analizar los elementos de solicitudes y contratos que conforman al departamento de Crédito separándolos por los diferentes estatus que conforman el flujo de trabajo de cada elemento y agrupándolos por las diferentes aristas o dimensiones que complementan sus respectivos ciclos de vida. La información almacenada en el DM proporcionará el conocimiento indispensable para saber cuántas solicitudes y cuántos contratos se encuentran en cada estado y cuánto dinero representa para la compañía dicha cantidad. De esta manera el departamento podrá actuar a tiempo para acelerar el flujo de trabajo tanto de las solicitudes y los contratos evitando de esta manera cuellos de botella innecesarios en sus ciclos de vida y mejorando de manera estratégica la rentabilidad mensual del departamento Definición del Grano Una vez definidos los procesos de negocio asociados al departamento de Crédito se procede a definir la granularidad, o lo que es lo mismo, hasta qué nivel de detalle se quiere alcanzar en el modelo de Data Mart y más concretamente en la tabla de hechos. De acuerdo con la metodología de Kimball el objetivo es estructurar el modelo en torno a una granularidad baja obtenida a partir de los procesos de negocio determinados. Es decir, en torno a una información lo más detallada posible de tal manera que esta no se pueda desglosar. La ventaja de estas informaciones básicas o atómicas es que ofrecen una gran flexibilidad en su análisis, y los datos en un modelo de dimensión permiten las consultas directas por parte de los usuarios. Además, permiten responder a consultas que no podrían responderse con mayor granularidad

103 Por otro lado, siempre es posible declarar un nivel de granularidad más alto para un proceso de negocio que representa una agregación de datos atómicos. Sin embargo, esta opción también implica una limitación a la hora de detallar las dimensiones. Este aumento de la granularidad dará una mayor dificultad al usuario a la hora de profundizar en los detalles, sin embargo son recomendables cuando se tiene certeza de que un número indicado de requerimientos o necesidades de información podrán ser satisfechas con la información contenida en este nivel y que a su vez las consultas asociadas a estos requerimientos de información se verán beneficiadas a nivel del desempeño o performance del query debido a que la cantidad de registros que deberán consultar será menor a la cantidad que se encontraría en un nivel más bajo. Con estas perspectivas se ha elaborado una estructura dual de tablas de hechos. Para la primera tabla de hechos, tanto para el elemento de solicitudes como para el elemento de contratos, el grano más apropiado consiste en asignar una fila por cada elemento que agrupa al sistema. De manera que se pueda estructurar la información en torno a los datos que se puedan obtener de cada uno de los elementos a modelar. Para el caso de las solicitudes se encuentran los siguientes: Fecha de creación de la solicitud Número de solicitud para el sistema transaccional Número de solicitud para las visuales de usuario Tipo de solicitud que se está cargando Fecha y hora en la que se recibió la solicitud para el primer análisis Fecha y hora en la que culminó el primer análisis realizado sobre la solicitud Estatus de la solicitud Grado de riesgo asociado al usuario que realizó la solicitud Identificador del ejecutivo que estudió la solicitud Canal por el que se recibió la solicitud Identificador del plan asignado a la solicitud Identificador del concesionario asociado al cliente que realizó la solicitud Identificador del vendedor asociado al concesionario Monto de la solicitud

104 Nombre del cliente Identificador del cliente Etc. Para el caso de los contratos se encuentran los siguientes: Fecha de creación del contrato Número de contrato para el sistema transaccional Número de contrato para las visuales de usuario Número de solicitud que originó el contrato Fecha de término del contrato Tipo de contrato que se está cargando Estatus del contrato Grado de riesgo asociado al cliente a quien se le generó el contrato Monto aprobado en el contrato Identificador del concesionario dueño del carro que será adquirido por el cliente Identificador del vendedor asociado al concesionario Identificador de la marca del vehículo Identificador del modelo del vehículo Identificador del color del vehículo Nombre del cliente Identificador del cliente Etc. Para la segunda tabla, tanto para el elemento de solicitudes como para el elemento de contratos, el grano más apropiado consiste en la cantidad de registros que se logren agrupar a partir de las dimensiones almacenas en la primera tabla. De esta manera, para el elemento de solicitudes en su segunda tabla tenemos: Fecha en la que ocurre la agrupación de registros Mes asociado a la fecha en la que ocurre la agrupación de registros Identificador del estado de las solicitudes

105 Tipo de solicitud que se está almacenando Identificador del concesionario dueño del carro en cuestión Suma del monto de la solicitud en base a los registros agrupados Cantidad de solicitudes agrupadas en el día Cantidad de solicitudes acumuladas en el mes Etc. Similar al elemento de solicitudes, para el elemento de contratos tenemos: Fecha en la que ocurre la agrupación de registros Mes asociado a la fecha en la que ocurre la agrupación de registros Identificador del estado de los contratos Tipo de contrato que se está almacenando Identificador del concesionario dueño del carro en cuestión Suma del monto original del vehículo en base a los registros agrupados Suma del monto de venta del vehículo en base a los registros agrupados Cantidad de solicitudes agrupadas en el día Cantidad de solicitudes acumuladas en el mes Etc. Está claro que debido al interés en conocer la evolución de las solicitudes y los contratos en sus respectivos flujos de trabajo a lo largo del tiempo, la dimensión más importante que surge en el sistema es el tiempo. El tiempo engloba no solo la fecha en la que una solicitud fue aperturada, sino que incluye diferentes hitos que se deben ir acumulando como parte de la información. Como resultado de ello se puede conocer en el nivel con el grano más detallado, por ejemplo, cuándo fue aperturada una solicitud o un contrato, cuándo una solicitud pasó a un estado determinado (aprobada, rechazada, reconsiderada, etc.); cuáles solicitudes o contratos pertenecen a un determinado concesionario, modelo de vehículo, grado de riesgo, etc

106 Igualmente, en el nivel con un grano menos detallado se puede conocer cuántas solicitudes fueron aprobadas el día de hoy, cuántos contratos han sido liquidados en lo que ha transcurrido del mes, cuántas solicitudes o contratos pertenecen a una determinada marca, grado de riesgo, modelo, concesionario, etc. Como se puede observar, el nivel más bajo de granularidad ofrece al usuario un gran abanico de posibilidades a la hora de utilizar el DM que se construirá. Todo ello gracias a un grano fino, que permite combinar los datos de multitud de maneras. Sin embargo, de las sesiones de trabajo se pudo comprender que ese nivel más básico de información ya es satisfecho por el sistema transaccional de la empresa y que su debilidad de información actual puede ser satisfecha de manera más directa con el nivel más alto de granularidad explicado anteriormente. De ahí la importancia del mismo. Finalmente recalcar que aún y cuando el nivel de tablas de hechos a utilizar será el que tiene un grano menos detallado la importancia del nivel con un grano más detallado recae en que el mismo servirá de base o insumo para el segundo nivel y que la estructura de indicadores de gestión se va a nutrir principalmente de este primer nivel de tablas. Es por esa razón que el conjunto de tabla se denominó estructura dual de tablas Elección de las Dimensiones En este paso se incorporan a la tabla de hechos el conjunto de dimensiones que representan los valores que asumen todas las posibles descripciones en cada contexto del proceso de negocio. Una vez que se ha escogido el grano se procede a analizar qué dimensiones tiene asociadas. Para el DM que compete las dimensiones más apropiadas son: origen, producto, estatus, grado de riesgo, ejecutivo, canal, plan, concesionario, zona, vendedor y vehículo. Todas estas dimensiones serán explicadas con detalle en un apartado posterior

107 Cada dimensión se define por su clave principal, designado por la notación de PK7 en la figura 15, que muestra la estructura de una de las dimensiones, el concesionario. Esta clave primaria sirve como base para la integridad referencia con la tabla de hechos a la que se une. Como ha sido mencionado anteriormente las tablas dimensionales son catálogos de información complementaria necesaria para la presentación de los datos a los usuarios. Es decir, la información general complementaria a cada uno de los registros de la tabla de hechos. Para Kimball, las tablas de dimensión desempeñan un papel vital en el almacén de datos. Según este autor el poder del almacén de datos es directamente proporcional a la calidad y profundidad de los atributos de cada dimensión. Siguiendo las mejores prácticas recomendadas por el autor cada dimensión estará compuesta por atributos que miden valores discretos y consisten en palabras reales en lugar de abreviaturas crípticas. Por ejemplo en la dimensión concesionario se incluyen como atributos típicos el nombre del concesionario (de 100 caracteres máximo), el identificador de la zona a la que pertenece el concesionario, el nombre de la zona a la que pertenece el concesionario, el identificador para agrupar a todos los concesionarios, la descripción asociada al identificador para agrupar a todos los concesionarios, el identificador para agrupar a todas las zonas, la descripción asociada al identificador para agrupar a todas las zonas y una serie de campos de control para monitorear la efectividad de la corrida del DM. 7 Primary Key, por sus siglas en inglés

108 Figura 15: Tabla de Dimensión Concesionarios En la figura 16 se pueden observar las dimensiones definidas para el Data Mart de Crédito. La dimensión Fecha proporciona valores temporales. La dimensión origen indica si el registro en cuestión pertenece a la cartera de clientes de la empresa automotriz o a una cartera externa que la empresa automotriz ayuda a gestionar. La dimensión producto indica si el registro en cuestión está relacionado con un vehículo ó un seguro. La dimensión estatus indica en qué estado se encuentra el registro en el momento que se almacena en la tabla de hechos. La dimensión grado de riesgo indica el nivel de compromiso de pago que le asigna la empresa automotriz al cliente que desea optar por un crédito; mientras más bajo sea el nivel más probabilidades de problemas en el pago existirán para la empresa. Así mismo, la dimensión ejecutivo detalla la información del empleado que gestionó la solicitud o se encuentra gestionando los procesos del contrato dentro de la empresa automotriz. La dimensión canal indica por cuál canal fue remitido el contrato o la solicitud hacia la empresa automotriz. La dimensión plan especifica el plan de pago asociado a la solicitud y por consecuencia al contrato cuando el mismo es liquidado. Por su parte la dimensión concesionario permite identificar a cuál concesionario pertenece el vehículo sobre el cuál se estará tramitando la solicitud y un eventual contrato. La dimensión zona indica a cuál zona pertenece el concesionario en cuestión. La dimensión vendedor describe al empleado del concesionario que atendió en su oportunidad al cliente que eventualmente realiza la solicitud de crédito hacia la empresa automotriz. Finalmente la dimensión

109 vehículo indica con detalle la marca, el modelo, el año y la descripción del vehículo sobre el cuál se ejecutará el crédito. Figura 16: Tabla de Hechos y Dimensiones De igual manera, en la figura 16 que representa el esquema de estrella para este proyecto, cada una de las dimensiones tiene una clave primaria que posteriormente aparecerá en la tabla de hechos en forma de clave foránea. Las tablas de hechos por su parte no tendrán clave primaria debido a que no existe relevancia para el campo en vista que no se desea analizar el comportamiento de un único elemento sino el comportamiento del conjunto definido por las dimensiones que complementan a dicho elemento Identificación de los hechos que poblarán cada fila de la tabla de hechos

110 Los hechos se usan para definir qué es lo que se quiere medir. Para Kimball, todos los hechos candidatos en un diseño deben ser fieles al grano definido en el paso y los hechos que pertenezcan claramente a otro grano deben separarse en una tabla de hechos diferente. Esta es otra razón que valida la creación de la estructura dual de tablas tanto para el elemento de solicitudes como para el elemento de contratos. Al mismo tiempo Kimball define tres formas diferentes de gestionar los hechos dentro de una tabla de hechos. Para efectos de la gestión dentro de las tablas de hechos de primer grado, las cuales poseen un grano de bajo nivel, se ha seleccionado la forma de gestión denominada transacciones. Las transacciones dentro de la tabla de hechos representan una acción atómica que ocurre en un instante determinado del tiempo. A menudo no hay ninguna garantía de que un registro exista para un determinado instante en la tabla de hechos de transacciones, ya que un registro sólo existe cuando se ha producido su transacción correspondiente. Por el contrario, no hay límite para el número de registros de un determinado hecho. La fecha en el registro de transacciones puede determinar un día concreto o puede contener una mayor precisión con las horas y minutos. Normalmente los hechos representan cantidades y su valor depende de la clave de la transacción. Una vez insertada en la tabla, no suele volverse a revisar dicha transacción con el fin de hacer actualizaciones. Por otro lado, la forma de gestión de hechos seleccionada para las tablas de hechos de segundo grado, con un grano de nivel más elevado, se denomina instantáneas periódicas. Las instantáneas periódicas son tablas de hechos que representan un intervalo de tiempo predefinido. A diferencia de las transacciones, suelen existir registros para un determinado instante en el tiempo. Por lo general, existe un único registro para cada combinación de las claves de las dimensiones importantes. Las instantáneas periódicas pueden tener cualquier número de hechos, dependiendo de qué medidas son posibles o útiles para calcular. Algunos de estos hechos serían

111 extraordinariamente difíciles de calcular si se utilizaran las transaccionales. A menudo la instantánea periódica es la única tabla que puede generar fácilmente una vista regular y predecible de las medidas importantes de una empresa. Siguiendo la metodología de Kimball el cual aconseja que los hechos a almacenar en una tabla de hechos sean casi siempre valores numéricos, enteros o reales para así poder mostrar cantidades al usuario que surjan a partir de la suma de una o más cantidades de la tabla de hechos y teniendo en cuenta toda la información que se puede acumular por cada conjunto de elementos de solicitudes y contratos se procede a guardar lo siguiente en la tabla de hechos de segundo nivel solicitudes: Figura 17: Tabla de hechos de segundo nivel para Solicitudes

112 De manera similar al proceso de solicitudes se procede a guardar lo siguiente en la tabla de hechos de segundo nivel de contratos: Figura 18: Tabla de hechos de segundo nivel para Contratos Detalle de las tablas de dimensión A continuación se define de manera clara y concisa cada una de las dimensiones que se han identificado para el proyecto y que ya se esbozaron en la figura 16, definiendo todos los atributos que componen las mismas:

113 Dimensión Tiempo Debido a que los hechos dentro de las tablas de hechos se irán almacenando conforme vayan ocurriendo en el tiempo se necesita entonces de una estructura que sea capaz de tener en cuenta series de registros a lo largo del tiempo. El diseño de la dimensión tiempo suele ser bastante particular en vista que prácticamente DM hace uso de ella. La forma empleada para el diseño considera como clave principal (PK) de la tabla la fecha y posteriormente todos los atributos que el negocio emplea para realizar sus análisis. A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión tiempo construida: Figura 19: Extracto de atributos de la dimensión Tiempo El resultado final de la tabla dimensión tiempo es el reflejado en la figura 20 donde se muestra también la relación entre la dimensión tiempo y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos

114 Figura 20: Dimensión Tiempo en los procesos de Solicitudes y Contratos Dimensión Concesionarios La dimensión concesionarios describe a qué concesionario de automóviles pertenece el vehículo por el cual el cliente que desee adquirirlo realizará una solicitud de crédito que eventualmente podría materializarse en un contrato

115 Sólo aquellos concesionarios que tienen una relación comercial con la empresa automotriz aparecerán en la tabla del sistema transaccional de la compañía la cual sirve a su vez como insumo para la conformación de la dimensión concesionarios del DM del departamento de crédito. De igual manera, cada concesionario se encuentra ubicado dentro de una de las cinco zonas regionales en las que la empresa automotriz ha divido al país. Dicha información también se refleja en el detalle de la dimensión concesionarios. A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión concesionarios construida: Figura 21: Extracto de atributos de la Dimensión Concesionarios El resultado final de la tabla dimensión concesionarios es el reflejado en la figura 22 donde se muestra también la relación entre la dimensión concesionarios y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos

116 Figura 22: Dimensión Concesionarios en los procesos de Solicitudes y Contratos Dimensión Producto La dimensión Producto describe la naturaleza de la solicitud o crédito que se está realizando. Actualmente los dos productos disponibles son automóviles y seguros. Es decir, el proceso de solicitud de crédito sólo puede hacerse bien sea por un automóvil ó por el seguro de un automóvil. Esta clasificación aplica también para el contrato. A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión concesionarios construida:

117 Figura 23: Extracto de atributos de la Dimensión Producto El resultado final de la tabla dimensión producto es el reflejado en la figura 24 donde se muestra también la relación entre la dimensión producto y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos. Figura 24: Dimensión Producto en los procesos de Solicitudes y Contratos

118 Dimensión Grado de Riesgo La dimensión Grado de Riesgo describe la clasificación asignada al cliente producto del análisis crediticio que se le aplica a sus balances personales en combinación con una fórmula propia del departamento de crédito de la compañía. El grado de riesgo está relacionado con la capacidad de pago que tendrá el cliente una vez que la solicitud se materialice en un contrato y deban cancelarse las cuotas asociadas al mismo. Es importante indicar que los análisis que suelen hacerse desde la perspectiva del grado de riesgo también suelen acompañar al atributo denominado naturaleza del cliente, el cual indica si el mismo es un cliente natural ó un cliente jurídico. Sin embargo este atributo no es relevante para la dimensión grado de riesgo. A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión grado de riesgo construida: Figura 25: Extracto de atributos de la Dimensión Grado de Riesgo El resultado final de la tabla dimensión grado de riesgo es el reflejado en la figura 26 donde se muestra también la relación entre la dimensión grado de riesgo y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos

119 Figura 26: Dimensión Grado de Riesgo en los procesos de Solicitudes y Contratos Dimensión Estatus La dimensión Estatus describe todos los posibles estados por los que puede pasar una solicitud o un contrato durante todo su flujo de trabajo. Aún y cuando no es menester del DM de Crédito analizar el flujo de trabajo de una solicitud o contrato sino cada uno de los pasos que engloban dichos flujos de trabajo, las tablas de hechos almacenan en una serie de bloques de datos el resultado de una solicitud al cierre del día. Estos bloques de datos son el resultado del análisis tanto de todas las sesiones de trabajo establecidas con el usuario como de los sistemas transaccionales empleados por los mismos. Cada bloque se encuentra definido dentro de un proceso ETL que será explicado más adelante. Los análisis de cada uno de los elementos que conforman el flujo de trabajo tanto de solicitudes como de contratos se sirven entonces de esta dimensión para brindar más detalles sobre el identificador del estado de la solicitud que se almacena en las tablas de hechos respectivas

120 A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión estatus construida: Figura 27: Extracto de los atributos de la Dimensión Estatus El resultado final de la tabla dimensión estatus es el reflejado en la figura 28 donde se muestra también la relación entre la dimensión estatus y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos. Figura 28: Dimensión Estatus en los procesos de Solicitudes y Contratos

121 Dimensión Ejecutivo La dimensión Ejecutivo describe a todos los trabajadores de la empresa automotriz. La razón por la que la dimensión contiene a la totalidad de empleados en lugar de únicamente a los que trabajan en el departamento de Crédito se debe a que se espera que esta dimensión actúe como una de las integrantes del bus del Data Warehouse completo y como tal permita que varios DM puedan integrarse entre sí. A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión ejecutivo construida: Figura 29: Extracto de atributos de la Dimensión Ejecutivo El resultado final de la tabla dimensión ejecutivo es el reflejado en la figura 30 donde se muestra también la relación entre la dimensión ejecutivo y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos

122 Figura 30: Dimensión Ejecutivo en los procesos de Solicitudes y Contratos Dimensión Vendedor Esta dimensión es bastante similar a la dimensión Ejecutivo explicada anteriormente. La misma describe a todos los empleados pertenecientes a los diferentes concesionarios que mantienen relaciones comerciales con la empresa automotriz. De la misma manera que la dimensión ejecutivo, se espera emplear la dimensión vendedor como una de las integrantes del bus del Data Warehouse para así poder conectar de manera transparente diversos DM. El resultado final de la tabla dimensión ejecutivo es el reflejado en la figura 31 donde se muestra también la relación entre la dimensión vendedor y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos

123 Figura 31: Dimensión Vendedor en los procesos de Solicitudes y Contratos Dimensión Canal La dimensión canal describe el medio por el cual una solicitud de crédito o un contrato pueden llegar a la empresa automotriz en conjunto con sus respectivos recaudos. En el extracto que se muestra a continuación se tienen los dos canales oficiales que maneja la empresa hasta el momento. Figura 32: Extracto de atributos de la Dimensión Canal El canal oficina se refiere a que los documentos requeridos, ya sea para una solicitud o contrato, llegan de manera física a la empresa por primera vez. Por otro lado, el canal online se refiere a que dichos recaudos llegan por primera vez de manera digital. Para el segundo caso, aún y cuando la primera vez llegan de manera digitalizada los mismos deben consignarse posteriormente de manera física

124 El resultado final de la tabla dimensión canal es el reflejado en la figura 33 donde se muestra también la relación entre la dimensión canal y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos. Figura 33: Dimensión Canal en los Procesos de Solicitudes y Contratos Dimensión Plan La dimensión plan describe todos los planes a los que puede estar asociado el mecanismo de pago del vehículo en caso que la solicitud de crédito logre materializarse en un contrato. Cada plan, según su naturaleza, puede describir bien sea el número de meses de gracia en los que no se cancelará cuota en absoluto, el número de meses iniciales donde solo se cancelará monto capital o también el número de meses donde la cuota de pago será fija. A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión plan construida:

125 Figura 34: Extracto de atributos de la Dimensión Plan El resultado final de la tabla dimensión plan es el reflejado en la figura 35 donde se muestra también la relación entre la dimensión plan y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos. Figura 35: Dimensión Plan en los Procesos de Solicitudes y Contratos

126 Dimensión Zona La dimensión zona describe las 4 zonas en las que la empresa automotriz ha dividido el mapa político-territorial de Venezuela. Cada zona agrupa a una serie de concesionarios según la ubicación geográfica de los mismos. Adicionalmente se ha creado una nueva zona que es exclusiva para la empresa automotriz. La razón de esta necesidad es que en ocasiones la empresa suele actuar como un concesionario y por lo tanto lleva a cabo procesos de ventas de vehículos de manera directa, por lo tanto para mantener una consistencia en los datos se emplea esta zona especial que únicamente contiene a la empresa. A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión zona construida: Figura 36: Extracto de atributos de la Dimensión Zona El resultado final de la tabla dimensión zona es el reflejado en la figura 37 donde se muestra también la relación entre la dimensión zona y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos

127 Figura 37: Dimensión Zona en los Procesos de Solicitudes y Contratos Dimensión Origen La dimensión origen describe a qué cartera pertenece la solicitud o el contrato. Actualmente todas las solicitudes pertenecen a la cartera activa de la empresa, sin embargo los contratos pueden variar. Un contrato puede pertenecer a la cartera activa de la empresa o a una cartera de alguna institución bancaria pero que la empresa se encarga de administrar. La razón de este segundo punto se debe a que en algún punto de la vida activa de la empresa se vieron en la necesidad de tercerizar la cartera que tenían para ese momento, de ahí que existan contratos que tengan un código de origen distinto. A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión origen construida:

128 Figura 38: Extracto de atributos de la Dimensión Origen El resultado final de la tabla dimensión origen es el reflejado en la figura 39 donde se muestra también la relación entre la dimensión origen y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos. Figura 39: Dimensión Origen en los Procesos de Solicitudes y Contratos Dimensión Marca/Modelo La dimensión marca/modelo describe todos los automóviles que se encuentran tanto en cada uno de los concesionarios que mantienen relaciones comerciales con la empresa como en la empresa matriz encargada de ensamblar los nuevos vehículos

129 Cada vehículo tiene un código identificador único, así como también una serie de descripciones que sirven para detallar la naturaleza del mismo; el año del vehículo, la marca, el modelo, entre otros. A continuación se muestra un extracto con algunos de los campos más empleados dentro de la dimensión marca/modelo construida: Figura 40: Extracto de atributos de la Dimensión Marca/Modelo El resultado final de la tabla dimensión marca/modelos es el reflejado en la figura 41 donde se muestra también la relación entre la dimensión y las tablas de hechos tanto del elemento de solicitudes como el elemento de contratos

130 Figura 41: Dimensión Marca/Modelo en los Procesos de Solicitudes y Contratos Diseño Físico del Data Warehouse Siguiendo con la metodología de Ralph Kimball, el siguiente paso en el desarrollo del DM es el diseño físico del mismo. El modelo dimensional desarrollado en el segmento anterior debe convertirse ahora en un diseño físico. En el diseño físico se deben incluir los nombres de columnas físicos, los tipos de los datos, las declaraciones de clave (si procede) y la posibilidad de incluir valores nulos. Contrariamente a la creencia general, añadir más hardware no es la única manera, ni la más eficaz, de ajustar el rendimiento. La creación de índices y tablas de hechos que agrupen uno o más niveles por encima de las tablas de hechos con el grano más bajo son

131 alternativas mucho más rentables. En la figura 42 se pueden apreciar las diferencias entre los modelos lógicos y físicos. Figura 42: Comparación del modelo lógico y físico Mientras que en el modelo lógico se definen los objetos o entidades, sus atributos, sus claves primarias y las relaciones entre dichas entidades atendiendo a consideraciones lógicas, en el modelo físico se implementan estas estructuras de la manera más eficiente desde el punto de vista de la máquina. Durante el proceso de diseño físico se trasladan los esquemas lógicos previstos a las estructuras reales. En este momento hay que transformar las entidades en tablas, crear las relaciones entre las dimensiones y la tabla de hechos mediante claves foráneas, transformar atributos en columnas y transformar los identificadores únicos primarios en claves primarias. Las siguientes tablas muestran las descripciones de las tablas de hechos del proceso de solicitudes desde el punto de vista físico:

132 NOMBRE CAMPO TIPO DATO ADMITE NULOS FECHA_CALENDARIO DATE No NUMERO_SECUENCIA NUMBER Yes CODIGO_COLA NUMBER Yes CODIGO_ORIGEN NUMBER Yes ID_TIPO_FLUJO NUMBER Yes ID_ESCENARIO VARCHAR2(1 CHAR) Yes NUMERO_SOLICITUD VARCHAR2(20 CHAR) Yes COD_PRODUCTO VARCHAR2(5 CHAR) Yes FECHA_SOLICITUD DATE Yes FECHA_INICIO DATE Yes HORA_INICIO VARCHAR2(25 CHAR) Yes FECHA_FIN DATE Yes HORA_FIN VARCHAR2(25 CHAR) Yes MINUTOS_CALLBACK_TIME NUMBER Yes DIAS_RETENCION NUMBER Yes ID_ESTATUS VARCHAR2(4 CHAR) Yes DESC_ESTATUS VARCHAR2(20 CHAR) Yes TIPO_SOLICITUD NUMBER Yes GRADE VARCHAR2(1 CHAR) Yes ID_ESTATUS_RECHAZO VARCHAR2(4 CHAR) Yes DETALLE_ESTATUS_RECHAZO VARCHAR2(200 CHAR) Yes ID_EJECUTIVO VARCHAR2(4 CHAR) Yes NOMBRE_EJECUTIVO VARCHAR2(100 CHAR) Yes CANAL VARCHAR2(3 CHAR) Yes ID_PLAN VARCHAR2(3 CHAR) Yes DESC_PLAN VARCHAR2(200 CHAR) Yes EMPLEADO VARCHAR2(2 CHAR) Yes NUEVO_USADO VARCHAR2(5 CHAR) Yes TOTAL_CUOTAS NUMBER Yes MONTO_ORIGINAL FLOAT Yes MONTO_SOLICITUD FLOAT Yes MONTO_INICIAL FLOAT Yes ID_CONCESIONARIO NUMBER(10,0) Yes NOMBRE_CONCESIONARIO VARCHAR2(200 CHAR) Yes ID_VENDEDOR VARCHAR2(5 CHAR) Yes NOMBRE_VENDEDOR VARCHAR2(100 Yes

133 CHAR) ID_REGION NUMBER(3,0) Yes DESC_REGION VARCHAR2(25 CHAR) Yes CO_VEHICULO VARCHAR2(20 CHAR) Yes ID_MARCA NUMBER(5,0) Yes DESC_MARCA VARCHAR2(100 CHAR) Yes ID_MODELO VARCHAR2(10 BYTE) Yes DESC_MODELO VARCHAR2(100 CHAR) Yes AGNO_CARRO NUMBER(4,0) Yes ID_CLIENTE VARCHAR2(20 CHAR) Yes NATURALEZA_CLIENTE VARCHAR2(10 CHAR) Yes NOMBRE_CLIENTE VARCHAR2(100 CHAR) Yes SEXO VARCHAR2(2 CHAR) Yes EDAD NUMBER(3,0) Yes ESTADO_HABITACION VARCHAR2(20 CHAR) Yes INGRESO_MENSUAL FLOAT Yes CONFIRMADO VARCHAR2(2 BYTE) No FECHA_REGISTRO DATE No MES_PROCESO VARCHAR2(20 CHAR) No ID_LOTE NUMBER No Tabla 3: Diseño físico de la tabla de hechos de solicitudes con el grano más bajo NOMBRE CAMPO TIPO DATO ADMITE NULOS FECHA_CALENDARIO DATE No MES_PROCESO VARCHAR2(20 CHAR) No CODIGO_ORIGEN NUMBER Yes ID_TIPO_FLUJO NUMBER Yes COD_PRODUCTO NUMBER Yes ID_ESCENARIO VARCHAR2(1 CHAR) Yes ID_ESTATUS VARCHAR2(4 CHAR) Yes TIPO_SOLICITUD NUMBER Yes GRADE VARCHAR2(1 CHAR) Yes ID_ESTATUS_RECHAZO VARCHAR2(4 CHAR) Yes DETALLE_ESTATUS_RECHAZO VARCHAR2(200 CHAR) Yes ID_EJECUTIVO VARCHAR2(4 CHAR) Yes CANAL VARCHAR2(3 CHAR) Yes

134 ID_PLAN VARCHAR2(3 CHAR) Yes EMPLEADO VARCHAR2(2 CHAR) Yes NUEVO_USADO VARCHAR2(5 CHAR) Yes ID_CONCESIONARIO NUMBER(10,0) Yes ID_ZONA NUMBER(3,0) Yes ID_VENDEDOR VARCHAR2(5 CHAR) Yes CO_VEHICULO VARCHAR2(20 CHAR) Yes NATURALEZA_CLIENTE VARCHAR2(10 CHAR) Yes SEXO VARCHAR2(2 CHAR) Yes SUM_MONT_ORIG_AGRUP NUMBER Yes SUM_MONT_SOL_AGRUP NUMBER Yes SUM_MONT_INI_AGRUP NUMBER Yes CANT_SOL_TOTAL_DIA NUMBER Yes CANT_SOL_TIPO_DIA NUMBER Yes CANT_SOL_AGRUP_DIA NUMBER Yes CANT_MINUT_CALLBACK_AGRUP_DIA NUMBER Yes CANT_SOL_TOT_ACUM NUMBER Yes CANT_SOL_TIPO_ACUM NUMBER Yes PROM_SOL_TOT_DIARIO NUMBER Yes PROM_SOL_TIPO_DIA NUMBER Yes PROM_MINUT_CALLBACK_TOT_DIA NUMBER Yes PROM_MINUT_CALLBACK_TIPO_DIA NUMBER Yes CONFIRMADO VARCHAR2(2 BYTE) No FECHA_REGISTRO DATE No ID_LOTE NUMBER No Tabla 4: Diseño físico de la tabla de hechos de solicitudes con el grano menos detallado Por su parte, las siguientes tablas muestran las descripciones de las tablas de hechos del proceso de contratos desde el punto de vista físico: NOMBRE CAMPO TIPO DATO ADMITE NULOS FECHA_CALENDARIO DATE No NUMERO_SECUENCIA NUMBER(18,0) Yes CODIGO_PRODUCTO VARCHAR2(2 BYTE) Yes NUMERO_TS NUMBER(18,0) Yes NUMERO_MESA VARCHAR2(5 BYTE) Yes

135 CODIGO_ORIGEN NUMBER(18,0) Yes ID_ESCENARIO VARCHAR2(1 BYTE) Yes NUMERO_CONTRATO NUMBER(18,0) Yes NUMERO_SOLICITUD VARCHAR2(10 BYTE) Yes FECHA_INICIO DATE Yes FECHA_VENCIMIENTO DATE Yes ID_ESTATUS VARCHAR2(5 BYTE) Yes DESC_ESTATUS VARCHAR2(100 BYTE) Yes TIPO_CONTRATO NUMBER(4,0) Yes GRADE VARCHAR2(2 BYTE) Yes ID_EJECUTIVO VARCHAR2(10 BYTE) Yes DESC_EJECUTIVO VARCHAR2(100 BYTE) Yes CANAL VARCHAR2(3 BYTE) Yes ID_PLAN VARCHAR2(3 BYTE) Yes DESC_PLAN VARCHAR2(200 BYTE) Yes EMPLEADO VARCHAR2(3 BYTE) Yes NUEVO_USADO VARCHAR2(10 BYTE) Yes SUBSIDIADO VARCHAR2(3 BYTE) Yes DOMICILIADO VARCHAR2(3 BYTE) Yes NUMERO_TOTAL_CUOTAS NUMBER(3,0) Yes NUMERO_CUOTA_ACTUAL NUMBER(3,0) Yes NUMERO_CUOTAS_RESTANTES NUMBER(3,0) Yes NUMERO_CUOTAS_FIJAS NUMBER(3,0) Yes MONTO_INICIAL NUMBER(20,2) Yes MONTO_VENTA NUMBER(20,2) Yes MONTO_ORIGINAL NUMBER(20,2) Yes PORC_INICIAL NUMBER(20,2) Yes TASA_CLI NUMBER(10,2) Yes TASA_TABLA NUMBER(10,2) Yes DIA_PAGO NUMBER(2,0) Yes FALTA_FIJA NUMBER(3,0) Yes ID_CONCESIONARIO NUMBER(10,0) Yes NOMBRE_CONCESIONARIO VARCHAR2(200 BYTE) Yes ID_VENDEDOR NUMBER(10,0) Yes DESC_VENDEDOR VARCHAR2(200 BYTE) Yes ID_REGION_CONCES NUMBER(3,0) Yes DESC_REGION_CONCES VARCHAR2(25 CHAR) Yes

136 ID_MARCA NUMBER(5,0) Yes DESC_MARCA VARCHAR2(100 CHAR) Yes ID_MODELO VARCHAR2(10 BYTE) Yes DESC_MODELO VARCHAR2(100 CHAR) Yes ID_AGNO NUMBER(4,0) Yes COD_VEHICULO VARCHAR2(20 CHAR) Yes DESC_VEHICULO VARCHAR2(200 BYTE) Yes TIPO_VEHICULO VARCHAR2(100 BYTE) Yes ID_COLOR NUMBER(5,0) Yes DESC_COLOR VARCHAR2(250 BYTE) Yes DESC_SEGURO VARCHAR2(250 BYTE) Yes BROKER VARCHAR2(250 BYTE) Yes ID_BANCO VARCHAR2(5 BYTE) Yes DESC_BANCO VARCHAR2(250 BYTE) Yes ID_CLIENTE NUMBER(10,0) Yes RIF_CLIENTE VARCHAR2(40 BYTE) Yes NOMBRE_CLIENTE VARCHAR2(250 BYTE) Yes NATURALEZA_CLIENTE VARCHAR2(10 BYTE) Yes TIPO_CLIENTE VARCHAR2(15 BYTE) Yes FECHA_NACIMIENTO DATE Yes EDAD NUMBER(3,0) Yes SEXO VARCHAR2(3 BYTE) Yes ESTADO_HABITACION VARCHAR2(20 CHAR) Yes FIJO_INDEP VARCHAR2(20 BYTE) Yes TIEMPO_EMPLEO NUMBER(5,2) Yes TIEMPO_RESIDENCIA NUMBER(5,2) Yes TELEFONO VARCHAR2(3 BYTE) Yes TIPO_VIVIENDA VARCHAR2(15 BYTE) Yes RELAENDEUDA NUMBER(5,0) Yes ESCALA VARCHAR2(3 BYTE) Yes EXP_TSV VARCHAR2(12 BYTE) Yes INGRESO NUMBER(20,2) Yes FECHA_REGISTRO DATE No MES_PROCESO VARCHAR2(10 BYTE) No

137 ID_LOTE NUMBER(10,0) No CONFIRMADO VARCHAR2(1 BYTE) No Tabla 5: Diseño físico de la tabla de hechos de contratos con el grano más bajo NOMBRE CAMPO TIPO DATO ADMITE NULOS FECHA_CALENDARIO DATE No MES_PROCESO VARCHAR2(10 BYTE) No CODIGO_PRODUCTO VARCHAR2(2 BYTE) Yes CODIGO_ORIGEN NUMBER(18,0) Yes ID_ESCENARIO VARCHAR2(1 BYTE) Yes ID_ESTATUS VARCHAR2(5 BYTE) Yes TIPO_CONTRATO NUMBER(4,0) Yes GRADE VARCHAR2(2 BYTE) Yes ID_EJECUTIVO VARCHAR2(10 BYTE) Yes CANAL VARCHAR2(3 BYTE) Yes ID_PLAN VARCHAR2(3 BYTE) Yes EMPLEADO VARCHAR2(3 BYTE) Yes NUEVO_USADO VARCHAR2(10 BYTE) Yes DIA_PAGO NUMBER(2,0) Yes ID_CONCESIONARIO NUMBER(10,0) Yes ID_ZONA NUMBER(3,0) Yes ID_VENDEDOR NUMBER(10,0) Yes CO_VEHICULO VARCHAR2(20 CHAR) Yes ID_COLOR NUMBER(5,0) Yes NATURALEZA_CLIENTE VARCHAR2(10 BYTE) Yes SEXO VARCHAR2(3 BYTE) Yes TIPO_CLIENTE VARCHAR2(15 BYTE) Yes SUM_MONT_INI_AGRUP NUMBER(20,2) Yes SUM_MONT_VEN_AGRUP NUMBER(20,2) Yes SUM_MONT_ORIG_AGRUP NUMBER(20,2) Yes SUM_MONT_INI_ACUM NUMBER(20,2) Yes SUM_MONT_VEN_ACUM NUMBER(20,2) Yes SUM_MONT_ORIG_ACUM NUMBER(20,2) Yes CANT_CONT_TIPO_DIA NUMBER Yes CANT_CONT_AGRUP_DIA NUMBER Yes CANT_CONT_TOTAL_ACUM NUMBER Yes CANT_CONT_TIPO_ACUM NUMBER Yes CONFIRMADO VARCHAR2(1 BYTE) No

138 FECHA_REGISTRO DATE No ID_LOTE NUMBER(10,0) No Tabla 6: Diseño físico de la tabla de hechos de contratos con el grano menos detallado A continuación se muestra el diseño de cada una de las dimensiones: Concesionarios NOMBRE CAMPO TIPO DATO ADMITE NULOS ID_CONCESIONARIO NUMBER(10,0) No DESC_CONCESIONARIO VARCHAR2(100 BYTE) Yes ID_ZONA_CONCESIONARIO VARCHAR2(20 BYTE) Yes DESC_ZONA_CONCESIONARIO VARCHAR2(25 BYTE) Yes ID_TODOS_CONCESIONARIOS NUMBER(10,0) Yes DESC_TODOS_CONCESIONARIOS VARCHAR2(25 BYTE) Yes ID_TODAS_REGIONES NUMBER(10,0) Yes DESC_TODAS_REGIONES VARCHAR2(100 BYTE) Yes COD_RIESGO_CONCE VARCHAR2(20 BYTE) Yes CONFIRMADO VARCHAR2(1 BYTE) No ID_LOTE NUMBER(38,0) No Tabla 7: Diseño físico de la dimensión Concesionarios Producto NOMBRE CAMPO TIPO DATO ADMITE NULOS ID_PRODUCTO VARCHAR2(2 BYTE) No DESC_PRODUCTO VARCHAR2(10 BYTE) Yes ID_TODOS_PRODUCTOS NUMBER Yes DESC_TODOS_PRODUCTOS VARCHAR2(20 BYTE) Yes CONFIRMADO VARCHAR2(1 BYTE) No ID_LOTE NUMBER No Tabla 8: Diseño físico de la dimensión Producto

139 Grado de Riesgo NOMBRE CAMPO TIPO DATO ADMITE NULOS ID_GRADE VARCHAR2(1 BYTE) No DESC_GRADE VARCHAR2(50 BYTE) Yes CONFIRMADO VARCHAR2(1 BYTE) No ID_LOTE NUMBER No Tabla 9: Diseño físico de la dimensión Grado de Riesgo Estatus ADMITE NULOS NOMBRE CAMPO TIPO DATO ID_ESTATUS VARCHAR2(4 BYTE) No VARCHAR2(100 DESC_ESTATUS BYTE) Yes ID_TODOS VARCHAR2(20 BYTE) Yes DESC_TODOS VARCHAR2(100 BYTE) Yes CONFIRMADO VARCHAR2(20 BYTE) Yes ID_LOTE NUMBER No CO_EVENTO VARCHAR2(20 BYTE) No Tabla 10: Diseño físico de la dimensión Estatus Ejecutivo ADMITE NULOS NOMBRE CAMPO TIPO DATO ID_EJECUTIVO VARCHAR2(4 BYTE) No VARCHAR2(200 DESC_EJECUTIVO BYTE) Yes ID_TODOS VARCHAR2(20 BYTE) Yes DESC_TODOS VARCHAR2(200 BYTE) CONFIRMADO VARCHAR2(20 BYTE) No ID_LOTE VARCHAR2(20 BYTE) No Tabla 11: Diseño físico de la dimensión Ejecutivo Yes

140 Plan ADMITE NULOS NOMBRE CAMPO TIPO DATO ID_PLAN VARCHAR2(3 BYTE) No VARCHAR2(200 DESC_PLAN BYTE) Yes ID_TODOS VARCHAR2(20 BYTE) Yes DESC_TODOS VARCHAR2(200 BYTE) CONFIRMADO VARCHAR2(20 BYTE) No ID_LOTE VARCHAR2(20 BYTE) No Tabla 12: Diseño físico de la dimensión Plan Yes Vendedor ADMITE NULOS NOMBRE CAMPO TIPO DATO ID_VENDEDOR VARCHAR2(5 BYTE) No VARCHAR2(200 DESC_VENDEDOR BYTE) Yes ID_TODOS VARCHAR2(20 BYTE) Yes DESC_TODOS VARCHAR2(200 BYTE) CONFIRMADO VARCHAR2(20 BYTE) No ID_LOTE NUMBER No Tabla 13: Diseño físico de la dimensión Vendedor Yes

141 Zona NOMBRE CAMPO TIPO DATO ADMITE NULOS ID_ZONA NUMBER No DESC_ZONA VARCHAR2(50 BYTE) Yes ID_TODOS NUMBER Yes DESC_TODOS VARCHAR2(20 BYTE) Yes CONFIRMADO VARCHAR2(20 BYTE) No ID_LOTE NUMBER No Tabla 14: Diseño físico de la dimensión Zona Canal NOMBRE CAMPO TIPO DATO ADMITE NULOS ID_CANAL VARCHAR2(3 BYTE) No DESC_CANAL VARCHAR2(10 BYTE) Yes ID_TODOS NUMBER Yes DESC_TODOS VARCHAR2(20 BYTE) Yes CONFIRMADO VARCHAR2(20 BYTE) No ID_LOTE NUMBER No Tabla 15: Diseño físico de la dimensión Canal Origen ADMITE NULOS NOMBRE CAMPO TIPO DATO ID_ORIGEN VARCHAR2(20 BYTE) No VARCHAR2(200 DESC_ORIGEN BYTE) Yes ID_TODOS VARCHAR2(20 BYTE) Yes DESC_TODOS VARCHAR2(200 BYTE) CONFIRMADO VARCHAR2(20 BYTE) No ID_LOTE NUMBER No Tabla 16: Diseño físico de la dimensión Origen Yes

142 Tiempo NOMBRE CAMPO TIPO DATO ADMITE NULOS DAY_ID DATE No DAY_TIME_SPAN NUMBER Yes DAY_END_DATE DATE Yes WEEK_DAY_FULL VARCHAR2(9 BYTE) Yes WEEK_DAY_SHORT VARCHAR2(3 BYTE) Yes DAY_NUM_OF_WEEK NUMBER Yes DAY_NUM_OF_MONTH NUMBER Yes DAY_NUM_OF_YEAR NUMBER Yes MONTH_ID VARCHAR2(8 BYTE) Yes MONTH_TIME_SPAN NUMBER Yes MONTH_END_DATE DATE Yes MONTH_SHORT_DESC VARCHAR2(8 BYTE) Yes MONTH_LONG_DESC VARCHAR2(15 BYTE) Yes MONTH_SHORT VARCHAR2(3 BYTE) Yes MONTH_LONG VARCHAR2(10 BYTE) Yes MONTH_NUM_OF_YEAR NUMBER Yes QUARTER_ID VARCHAR2(7 BYTE) Yes QUARTER_TIME_SPAN NUMBER Yes QUARTER_END_DATE DATE Yes QUARTER_NUM_OF_YEAR NUMBER Yes YEAR_ID VARCHAR2(4 BYTE) Yes YEAR_TIME_SPAN NUMBER Yes YEAR_END_DATE DATE Yes PERIODO_COBRANZA NUMBER(2,0) Yes HOLIDAY_ID VARCHAR2(1 BYTE) Yes CLOSING_DATE_ID VARCHAR2(1 BYTE) Yes FY_ID VARCHAR2(4 BYTE) Yes MONTH_NUM_OF_FY NUMBER(3,0) Yes QUARTER_FY_ID VARCHAR2(7 BYTE) Yes QUARTER_NUM_OF_FY NUMBER(3,0) Yes DAY_NUM_OF_FY NUMBER(3,0) Yes Tabla 17: Diseño físico de la dimensión Tiempo

143 Vehículo (Marca/Modelo) NOMBRE CAMPO TIPO DATO ADMITE NULOS CODIGO_VEHICULO VARCHAR2(20 BYTE) No ID_MARCA VARCHAR2(20 BYTE) Yes DESC_MARCA VARCHAR2(200 BYTE) Yes ID_MODELO VARCHAR2(20 BYTE) Yes DESC_MODELO VARCHAR2(200 BYTE) Yes ID_AGNO VARCHAR2(20 BYTE) Yes DESC_TITULO VARCHAR2(200 BYTE) Yes TIPO_VEHICULO VARCHAR2(20 BYTE) Yes ID_TODOS_VEHICULOS VARCHAR2(20 BYTE) Yes DESC_TODOS_VEHICULOS VARCHAR2(200 BYTE) Yes ID_TODAS_MARCAS VARCHAR2(20 BYTE) Yes DESC_TODAS_MARCAS VARCHAR2(200 BYTE) Yes ID_TODOS_MODELOS VARCHAR2(20 BYTE) Yes DESC_TODOS_MODELOS VARCHAR2(200 BYTE) Yes FAMILIA VARCHAR2(20 BYTE) Yes CONFIRMADO VARCHAR2(20 BYTE) No ID_LOTE NUMBER No Tabla 18: Diseño físico de la dimensión Vehículo (Marca/Modelo) Para completar el diseño físico del DM es necesario definir y establecer cada uno de los índices a emplear en cada nivel de tablas de hechos. La siguiente tabla muestra dónde es empleado cada uno de los índices propuestos. NIVEL DE GRANO CAMPOS INDICE NIVEL DE GRANO BAJO MEDIO SOLICITUD CONTRATO SOLICITUD CONTRATO FECHA_CALENDARIO X X X X NUMERO_SECUENCIA X X N/A N/A NUMERO_SOLICITUD X N/A N/A N/A ID_ESTATUS X X X X GRADE N/A N/A X X

144 CANAL N/A N/A X X ID_PLAN N/A N/A X X ID_CONCESIONARIO X X X X ID_REGION N/A N/A X X CO_VEHICULO X X X X COD_PRODUCTO N/A N/A X X COD_ORIGEN N/A N/A X X Tabla 19: Establecimiento de los índices Diseño y Desarrollo de la Presentación de los Datos Este es el último paso en el desarrollo de los datos o la puesta en escena del sistema ETL. En esta fase se llevan a cabo los procesos de extracción, transformación y carga de los datos dentro del diseño del Data Mart. Para el desarrollo de esta capa fueron construidos una serie de procedimientos encargados de recolectar toda la información de los sistemas transaccionales de la empresa, recodificar aquellos datos para poder hacerlos entendibles para el Data Mart y finalmente almacenarlos en las tablas correspondientes. Alrededor de estos elementos se ha construido también una estructura de control que sirva tanto para el monitoreo de la correcta ejecución de dichos procesos como para la interacción con las aplicaciones de usuario final. Dicha estructura y los elementos que la componen será explicada en un apartado posterior. A continuación se van a detallar las especificaciones funcionales de todos los elementos o procedimientos que conforman la capa de presentación de los datos para este proyecto: TSV_ACT_DIM_ESTATUS Este procedimiento se encarga de extraer la información relacionada con los estatus que pueden tomar los procesos de solicitudes y contratos manejados por la transaccional de la empresa automotriz y así completar la dimensión Estatus. TSV_ACT_DIM_ORIGEN

145 Procedimiento encargado de extraer la información sobre todas las carteras existentes o vehículo originario de la transacción y de esta forma completar la dimensión Origen. TSV_ACT_DIM_PLAN Este procedimiento se encarga de extraer toda la información relacionada con los planes de pago asociados a las solicitudes y a los contratos y de esta manera completar la dimensión Plan. TSV_ACT_DIM_EJECUTIVO Con este procedimiento se completa toda la información que se encuentra en los sistemas transaccionales relacionada con los ejecutivos de la empresa automotriz que gestionan los procesos de solicitudes y contratos, conformando de esta forma la dimensión Ejecutivo. TSV_ACT_DIM_VENDEDOR Procedimiento similar al anterior en el que se busca toda la información relevante sobre los vendedores que se encuentran laborando en los concesionarios que mantienen relaciones comerciales con la empresa automotriz. De esta manera se constituye la dimensión Vendedor. TSV_ACT_DIM_MARCA_MODELO Con este procedimiento se obtiene toda la información importante relacionada con el vehículo por el cual se aplica una solicitud o se genera un contrato. La marca, el modelo, la familia, entre otros, son atributos que son completados en la dimensión Vehículo (Marca/Modelo). TSV_ACT_DIM_CONCESIONARIOS

146 Mediante este procedimiento se constituye la dimensión Concesionarios consultando los sistemas transaccionales para extraer la información importante de la misma. Para efectos de practicidad en esta dimensión se almacena la zona de la región a la que pertenece el concesionario aún y cuando existe una dimensión aparte relacionada con dicho elemento. TSV_ACT_DIM_ZONA Con este procedimiento se completan la información de la dimensión Zona. Sin embargo este procedimiento no corre de manera automática sino a solicitud del departamento de tecnología debido a que el cambio de la distribución regional del país en zonas no ocurre casi nunca. TSV_ACT_DIM_GRADE Este procedimiento carga la información básica relacionada con los grados de riesgos en los que la empresa automotriz cataloga a sus clientes previo análisis de sus estados crediticios, completando de esta forma la dimensión Grado de Riesgo. Al igual que con el procedimiento anterior, este corre solo a pedido del departamento de tecnología debido a que el cambio de la distribución del grado de riesgo ocurre muy poco. TSV_ACT_DIM_PRODUCTO Este procedimiento llena las diferentes naturalezas por las cuales una solicitud o contrato pueden ser generados, completando de esta forma la dimensión Producto. De manera similar al procedimiento de grados de riesgo, este último solo corre a demanda del departamento de tecnología. TSV_ACT_DIM_CANAL Con este procedimiento se constituye la dimensión Canal. Mediante el mismo se recolecta la información relacionada con los diversos canales por los cuales una solicitud, contrato o recaudos de ambos puede llegar a la empresa automotriz para su procesamiento respectivo

147 TSV_ACT_FACT_SOLICITUD_DET_NEW Este procedimiento almacena el primer bloque de información dentro de la tabla de hechos de grano más bajo para el mundo de solicitudes (este almacenamiento por bloques se mencionó brevemente anteriormente). Este primer bloque consiste en todas las solicitudes que el negocio entiende como nuevas, es decir, solicitudes que se cargaron durante el día y que culminaron dicho día con un estado preaprobado, rechazado o aprobado. Este procedimiento solo almacena las solicitudes del día de corrida que recibe el procedimiento como parámetro. Todas las solicitudes dentro de este bloque se identifican con el número 1 en el campo tipo_solicitud. TSV_ACT_FACT_SOLICITUD_DET_REP Este procedimiento almacena el segundo bloque de información dentro de la tabla de hechos de grano más bajo para el mundo de solicitudes. Este segundo bloque consiste en todas las solicitudes que el negocio entiende como reprocesadas por reconsideración. Se debe recordar que las solicitudes reprocesadas por reconsideración son aquellas solicitudes que en algún momento fueron rechazadas por un motivo que permite una reconsideración sobre las mismas como el vencimiento de la fecha para consignar los recaudos, entre otros. Este procedimiento solo almacena las solicitudes del día de corrida que recibe el procedimiento como parámetro. Todas las solicitudes dentro de este bloque se identifican con el número 2 en el campo tipo_solicitud. TSV_ACT_FACT_SOLICITUD_MEN_RET Este procedimiento almacena el tercer bloque de información dentro de la tabla de hechos de grano más bajo para el mundo de solicitudes. Este tercer bloque consiste en todas las solicitudes que el negocio entiende como retenidas. Es importante recordar que una solicitud retenida es aquella que cumple con un número importante de requisitos necesarios para poder liquidarse y convertirse en contrato pero que sin embargo todavía espera para que todos los recaudos se encuentren en correcto estado y proceder a la liquidación. Este procedimiento almacena las solicitudes totales al día de corrida que recibe el procedimiento como parámetro, es decir almacena el acumulando diario durante el mes todas estas

148 solicitudes. Todas las solicitudes dentro de este bloque se identifican con el número 3 en el campo tipo_solicitud. TSV_ACT_FACT_SOLICITUD_DET_LIQ Este procedimiento almacena el cuarto bloque de información dentro de la tabla de hechos de grano más bajo para el mundo de solicitudes. Este cuarto bloque consiste en todas las solicitudes que el negocio entiende como liquidadas. Se debe recordar que las solicitudes liquidadas son aquellas que han cumplido satisfactoriamente con todos los recaudos y pasos necesarios para poder convertirse en un contrato y por lo tanto pasan a formar uno (contrato). Este procedimiento solo almacena las solicitudes del día de corrida que recibe el procedimiento como parámetro. Todas las solicitudes dentro de este bloque se identifican con el número 4 en el campo tipo_solicitud. TSV_ACT_FACT_SOLICITUD_MEN_NEW Este procedimiento almacena el quinto bloque de información dentro de la tabla de hechos de grano más bajo para el mundo de solicitudes. Este quinto bloque es una derivación del primer bloque. Lo anterior quiere decir que el principio de recolección de la información en este bloque es casi igual al del primer bloque, la única diferencia es que durante este proceso se almacena la información acumulada a la fecha de ejecución sobre el mes al cual dicha fecha se refiera en lugar de únicamente almacenar la información del día de ejecución (como lo hace el primer bloque). Todas las solicitudes dentro de este bloque se identifican con el número 5 en el campo tipo_solicitud. TSV_ACT_FACT_SOLICITUD_DET_RET Este procedimiento almacena el sexton bloque de información dentro de la tabla de hechos de grano más bajo para el mundo de solicitudes. Este sexto bloque es una derivación del tercer bloque. Esto quiere decir que el principio de recolección de la información en este bloque es casi igual al del cuarto bloque, la única diferencia es que durante este proceso se almacena solo la información del día de ejecución en lugar de almacenar la información acumulada a la fecha de ejecución sobre el mes al cual dicha fecha se refiera (como lo

149 hace el tercer bloque). Todas las solicitudes dentro de este bloque se identifican con el número 6 en el campo tipo_solicitud. TSV_ACT_FACT_SOLICITUD_CONSOL Este procedimiento se encarga de cargar la tabla de hechos de solicitudes de nivel de grano medio con toda la información proveniente de la tabla de hechos de solicitudes de nivel de grano bajo agrupando por el conjunto de dimensiones que se han definido para este proceso así como también otro grupo de variables. Este procedimiento solo aplica sobre los mundos con información del día. TSV_ACT_FACT_SOLIC_MEN_CONSOL Este procedimiento se encarga de cargar la tabla de hechos de solicitudes de nivel de grano medio con toda la información proveniente de la tabla de hechos de solicitudes de grano bajo de manera similar al proceso de consolidación anterior. Por su parte, este procedimiento solo aplica sobre los mundos con información acumulada al día. TSV_ACT_FACT_CONTRATO_DET_NEW Este procedimiento almacena el primer bloque de información dentro de la tabla de hechos de grano más bajo para el mundo de contratos. Este primer bloque consiste en todos los contratos que el negocio entiende como liquidados. Un contrato liquidado es sencillamente aquel contrato que acaba de nacer durante el transcurso del día. Este procedimiento solo almacena los contratos del día de corrida que recibe el procedimiento como parámetro. Todos los contratos dentro de este bloque se identifican con el número 1 en el campo tipo_contrato. TSV_ACT_FACT_CONTRATO_CONSOL Este procedimiento se encarga de cargar la tabla de hechos de contratos de nivel de grano medio con toda la información proveniente de la tabla de hechos de solicitudes de grano

150 bajo agrupando por el conjunto de dimensiones que se han definido para este proceso así como también otro grupo de variables Diseño de la Arquitectura Técnica Por arquitectura técnica se entiende el modelo de los servicios técnicos del DM y de sus elementos. El plan de la arquitectura técnica sirve como marco de organización para apoyar la integración de las tecnologías. La arquitectura permite detectar los problemas a priori y trata de minimizar al comienzo del proyecto las sorpresas que pudieran surgir. En el Capítulo 2, marco conceptual, se mencionaron los componentes importantes de la arquitectura técnica, como el área de datos de organización, los servicios de acceso a datos y los metadatos. A continuación se dirigirá la atención a la arquitectura aplicable al proyecto de DM que nos compete, Data Mart del departamento de Crédito. Sobre las tres arquitecturas planteadas en el citado capítulo 2 se ha considerado más apropiado para este proyecto emplear la arquitectura con área de organización y Data Marts que puede observarse nuevamente en la figura

151 Figura 43: Arquitectura para el proyecto DM de Crédito Fuente: Kimball, 1995 Se ha elegido esta arquitectura debido a que presenta los elementos que mejor se adaptan a la presente necesidad; entre ellos tenemos al área de organización, el cual es un área temporal donde se almacenarán los datos necesarios de los sistemas origen y posteriormente serán enviados a sus respectivas tablas finales. Mediante el elemento de área de organización ha sido posible estructurar la información de la manera más coherente posible para posteriormente proceder a almacenarlas en las tablas finales correspondientes. Una vez que los datos están cargados el Data Mart se independiza de los sistemas origen hasta la siguiente carga. Esta arquitectura permite también que las herramientas de reporte que se implementen puedan acceder principalmente al Data Mart, pero también puedan realizar consultas directamente sobre el DWH, sobre todo cuando sea necesario mostrar a la vez información que se encuentre en diferentes Data Marts

152 El otro elemento importante de esta arquitectura es el lugar o área donde se crean los Data Marts. Estos se obtienen a partir de la información recopilada en el área de DWH. En dicha área es donde residirá el Data Mart de Crédito desarrollado en el presente proyecto. En la figura 43 se pueden observar diferentes Data Mart dentro de la arquitectura de un DWH empresarial modelo y más concretamente se puede particularizar en el Data Mart Crédito desarrollado en este proyecto. Dentro de la arquitectura de DWH para un entorno empresarial, también habría que destacar la creación de otros Data Marts como pudieran ser los destinados al departamento de Tesorería o el departamento de Cobranza. Por otro lado los usuarios del sistema, análisis extracción de informe y minería de datos consultan los diferentes Data Mart con el fin de obtener la información que desean Selección de Productos e Instalación Esta fase de la metodología no tuvo impacto alguno debido a que la empresa ya cuenta con una arquitectura tecnológica y una serie de productos instalados que les cubren todas las necesidades de tecnología actual y por lo tanto se procedió a trabajar con dichas tecnologías como base para la construcción del Data Mart. Por lo tanto, no entra en el alcance de este proyecto especificar con detalle las tecnologías más óptimas a emplear para el desarrollo de un proyecto de esta naturaleza Especificación de Aplicaciones para Usuarios Finales Como ha sido mencionado en el Capítulo 3, marco metodológico, para esta fase Kimball recomienda entender cuáles serán los perfiles de los usuarios que podrán consultar el Data Mart en vista que no todas las personas cumplen las mismas funciones dentro de un departamento empresarial. En base a lo anterior se logra identificar dos perfiles importantes, el perfil gerencial y el perfil analista. El perfil gerencial está enfocado en visualizar bloques de información fijos y concretos, una medida que surja a partir del análisis previo desarrollado por el área

153 analítica. Por otro lado, el perfil analista está enfocado en entender la información que el Data Mart le presenta desde tantas aristas sea necesario. El perfil analista debe servir de apoyo al perfil gerencial en miras de poder entender, con un nivel de detalle definido previamente, las razones de la información que el perfil gerencial observa, es decir qué genera dicha información; de esta manera el empleado dentro del perfil gerencial podrá tomar decisiones mucho más informadas sobre cuál será el curso de acción para un determinado patrón de información que no le convenza en el tiempo o por el contrario, y en el mejor de los casos, entender el impacto de sus decisiones de negocio cuando estas han sido efectivas. Es por ello que las aplicaciones, aún y cuando comparten atributos similares diferenciándose principalmente en la naturaleza del origen de datos que consultan, para los usuarios finales han sido divididas en dos vertientes; los usuarios finales con perfil gerencial están enfocados a una aplicación de consulta de información en la Web mientras que los usuarios finales con perfil de analista están enfocados a una aplicación de consulta de información en un programa de escritorio (Excel). Sin embargo, antes de ahondar en las particularidades de cada una de estas vertientes se procede a explicar la estructura de control que rodea al Data Mart de crédito debido a que de dicha estructura dependen algunas funcionalidades implementadas en el apartado Web. Otra razón es que a partir de dicha explicación se va a poder entender de manera más precisa la funcionalidad de algunos de los campos contenidos en las tablas de hechos y de dimensiones explicadas anteriormente. De igual manera se va a explicar con detalle la estructura detrás del mecanismo de indicadores de gestión Mecanismo de Control del Data Mart El apartado de control del DM de Crédito esta constituido por una serie de elementos que se encargan de gestionar el correcto funcionamiento de todos los procesos de cargas de insumos manuales (en caso de ser necesarios), cargas de dimensiones y de la ejecución de los procesos ETL

154 En la siguiente figura se puede observar el modelo de datos definido para dicho mecanismo de control. Figura 44: Modelo de datos para el Mecanismo de Control Cada una de las tablas cumple con una función determinada, los procesos de ejecución asociados a dichas tablas se explicarán en el próximo apartado; en ese sentido tenemos: Tabla TSV_CFG_ETL Esta tabla almacena la información relacionada con los procesos ETL que deben correr para poblar las tablas de hechos tanto del DM de Crédito como de cualquier otro DM que se implemente en un futuro. Además también almacena la información relacionada con los procesos que se encargan de generar los indicadores de gestión, sobre los que se profundizarán más adelante. A continuación se muestra un pequeño extracto sobre los campos más empleados dentro de esta tabla:

155 Figura 45: Extracto de campos de la tabla TSV_CFG_ETL Como se puede observar, esta tabla almacena entre otros valores; el query que el proceso de control debe ejecutar cada vez que se realice una corrida del DM, un identificador del proceso ETL, un identificador de estatus para que el proceso de control sólo considere aquellos que se encuentran activos, una descripción del proceso ETL y una frecuencia de corrida que es clave para determinar la periodicidad de corrida del proceso. Otros campos que contiene esta tabla son; el orden de ejecución, para garantizar la prioridad de aquellos procesos que sean dependientes de otros, el nombre de la tabla de datos que el proceso va a afectar en la corrida y un código de departamento para identificar el área de negocio dueña de dicho proceso. Tabla TSV_CFG_RELACION_ETL_CARGAS En esta tabla se almacena la información que permite a su proceso asociado identificar que aquellos procesos de ETL que sean dependientes de otros puedan ejecutarse efectivamente. A continuación se muestra un pequeño extracto sobre los campos dentro de esta tabla:

156 Figura 46: Extracto de campos de la tabla TSV_CFG_RELACION_ETL_CARGAS Esta tabla contiene solo los identificadores de aquellos procesos ETL dependientes de otros procesos. De esta forma se logra garantizar que si los procesos que preceden a dicho proceso han corrido de manera fallida dicho proceso no se ejecute. Tabla TSV_CFG_ESTATUS Esta tabla contiene la información relacionada con todos los estatus en los que puede terminar la corrida de un proceso en particular. A continuación se muestra un pequeño extracto sobre los campos dentro de esta tabla: Figura 47: Extracto de campos de la tabla TSV_CFG_ESTATUS Tabla TSV_CFG_FRECUENCIA Esta tabla almacena los diferentes tipos de frecuencias que determinan la periodicidad de un determinado proceso ETL, de carga de dimensiones o de generación de indicadores de gestión

157 A continuación se muestra un pequeño extracto sobre los campos dentro de esta tabla: Figura 48: Extracto de campos de la tabla TSV_CFG_FRECUENCIA Tabla TSV_CFG_CARGAS Esta tabla es muy similar en almacenamiento a la tabla TSV_CFG_ETL. En esta se almacena la información relacionada con la carga de insumos manuales o de dimensiones relacionadas a la corrida de un DM. A continuación se muestra un pequeño extracto sobre los campos más empleados dentro de esta tabla: Figura 49: Extracto de campos de la tabla TSV_CFG_CARGAS Como se puede observar, esta tabla almacena entre otros valores; el identificador de carga asociado al proceso, la descripción de la carga que se va a realizar, el query que el proceso de control debe ejecutar para poder realizar la correcta ejecución de ese proceso y el código del departamento dueño del proceso de carga. Al igual que su tabla hermana, esta también posee entre otros campos; un identificador del orden de

158 ejecución pensado para aquellas cargas que tengan procesos que la precedan y el nombre de la tabla de datos que el proceso va a afectar en la corrida Tabla TSV_CFG_CARGA_DETALLE Esta tabla está pensada para detallar aquellos procesos de carga asociados a insumos manuales. En ella se almacenarán todos los campos que componen a un determinado archivo que clasifique como insumo manual de manera que el proceso asociado a dicha corrida sepa exactamente cómo manipular el archivo y guardar su información en las tablas destino que se creen para dicho mecanismo. Para el momento de la implementación del DM de Crédito el mismo no posee ningún insumo que clasifique como manual, por lo que esta tabla no posee información relevante. Tabla TSV_CFG_TIPO_REGISTRO Esta tabla también está asociada a aquellos procesos de carga sobre insumos manuales. Con ella se busca brindar un nivel más granular de detalle sobre el tipo de información que se vaya a almacenar en las tablas respectivas indicando la naturaleza del registro almacenado. A continuación se muestra un pequeño extracto sobre los campos más empleados dentro de esta tabla: Figura 50: Extracto de campos de la tabla TSV_CFG_TIPO_REGISTRO

159 Tabla TSV_CFG_TIPO_DATO Esta tabla complementa la información de la tabla anterior y sirve para brindar un nivel más rico de detalle sobre el subtipo de registro que se almacena en una tabla asociada a un proceso de carga manual sobre el meta-tipo. A continuación se muestra un pequeño extracto sobre los campos más empleados dentro de esta tabla: Figura 51: Extracto de campos de la tabla TSV_CFG_TIPO_DATO Tabla TSV_TRN_PROCESOS En esta tabla se almacena, de acuerdo a lo definido para la periodicidad de la corrida del DM, todos los procesos que deben ser ejecutados en dicho momento y su estatus final de corrida. A continuación se muestra un pequeño extracto sobre los campos más empleados dentro de esta tabla: Figura 52: Extracto de campos de la tabla TSV_TRN_PROCESOS

160 Esta tabla tiene de manera resumida el resultado de la corrida del DM para un día en particular identificando entre otros valores; al proceso que debe ejecutarse, el nombre de la actividad o proceso a ejecutarse, el resultado de dicha corrida, el lote al que pertenecen todos esos procesos y finalmente el departamento dueño de dichos procesos de corrida. TSV_TRN_EVENTOS Esta tabla actúa como el elemento de bitácora detallada de todo el DM de Crédito. En dicha tabla se almacena el paso a paso de la ejecución de cada uno de los procesos que deban ejecutarse para el día de corrida. Esta tabla es una agregación de la tabla TSV_CFG_PROCESOS porque es la que contiene el detalle que permite conocer la razón por la que la corrida de un proceso determinado termina con el estatus final que posea. A continuación se muestra un pequeño extracto sobre los campos más empleados dentro de esta tabla: Figura 53: Extracto de campos de la tabla TSV_TRN_EVENTOS En la figura se puede observar por ejemplo, los pasos por los que pasa el proceso de ETL que carga las solicitudes que el negocio entiende como nuevas, el cual fue explicado en el apartado anterior. De esa forma se comporta entonces la bitácora de cada evento

161 Mecanismo para los Indicadores de Gestión Por otro lado, el apartado de indicadores de gestión define el conjunto de tablas y procedimientos que permiten congelar en el tiempo los valores asociados al mundo de solicitudes y contratos que resultan más relevantes para el área gerencial del departamento de Crédito de la empresa automotriz. En la siguiente figura se puede observar el modelo de datos definido para dicho mecanismo de control. Figura 54: Modelo de Datos para el Mecanismo de Indicadores de Gestión Al igual que en el mecanismo anterior, cada una de las tablas cumple con una función determinada; en ese sentido tenemos:

162 TSV_CFG_UMBRAL Esta tabla almacena la información relacionada con la configuración de un determinado umbral para un determinado indicador. Un umbral, como su nombre lo indica, es una franja que define el éxito o el fracaso de un determinado elemento. Es decir, una medida para determinar su efectividad. Por lo tanto, cada vez que un indicador es generado el mismo procesamiento debe evaluar la efectividad del valor del indicador comparando con el umbral de aceptación configurado para el mismo. A continuación se muestra un pequeño extracto sobre los campos contenidos dentro de esta tabla: Figura 55: Extracto de campos de la tabla TSV_CFG_UMBRAL TSV_CFG_INDICADORES_GENERAL Esta tabla contiene la configuración general para cada indicador. Valores como el identificador del indicador, nombre del indicador, departamento al que pertenece, frecuencia con la que debe ser generado, entre otros, se ubican en esta tabla. A continuación se muestra un pequeño extracto sobre los campos contenidos dentro de esta tabla:

163 Figura 56: Extracto de campos de la tabla TSV_CFG_INDICADORES_GENERAL TSV_CFG_MENU_INDICADORES Esta tabla es la encargada de configurar las entradas en el menú del aplicativo Web desarrollado para el área gerencial del departamento de Crédito. En ella se almacena la información sobre cómo será el muestreo de la información del menú para el usuario final. A continuación se muestra un pequeño extracto sobre los campos contenidos dentro de esta tabla: Figura 57: Extracto de campos de la tabla TSV_CFG_MENU_INDICADORES TSV_SOLICITUD_INDICADORES y TSV_CONTRATO_INDICADORES La tabla de los indicadores de solicitudes y contratos almacenan todos y cada uno de los indicadores definidos para cada mundo por cada una de las dimensiones solicitadas. De esta misma manera, también cuentan con un elemento adicional que es el resumen

164 global que contiene un nivel mucho más condensado sobre las informaciones de solicitudes y contratos que el área gerencial espera ver a final de mes. A continuación se muestra un pequeño extracto sobre los campos contenidos dentro de la tabla de indicadores de solicitudes en vista que en la tabla de contratos la información se almacena de manera similar: Figura 58: Extracto de campos de la tabla TSV_SOLICITUD_INDICADORES Especificación de Aplicaciones para Usuarios Finales Tal como se mencionó al principio de este apartado, en esta fase es donde se diseñan las aplicaciones que van a emplear los usuarios finales. Los roles o jerarquías de usuarios surgen a partir de las sesiones de trabajo y de los requerimientos previamente establecidos. De esta manera tenemos usuarios con perfil de analista y usuarios con perfil gerencial. Para los usuarios con perfil gerencial la necesidad es un aplicativo Web que de manera sencilla les permita consultar la información ya condensada o indicadores que el DM va a generar de manera mensual. Por su parte, para los usuarios con perfil analista la necesidad es un aplicativo de escritorio, bajo tecnología Excel, que les permita consultar las diversas tablas de hechos para obtener un nivel de información más rico en comparación a los indicadores de gestión observados por los integrantes del perfil gerencial y de esta manera brindar respuestas rápidas a cualquier tipo de interrogante que pueda surgir de dicho nivel gerencial. Básicamente ambos aplicativos cumplirán las mismas funciones, es decir la consulta de información. La diferencia entre ambos se centrará en los orígenes de datos que las aplicaciones consultarán para satisfacer las necesidades de información de cada nivel

165 Para el sitio Web se cuenta con los siguientes diagramas de uso: Figura 59: Diagrama 1 Casos de Uso, Nivel 0 Figura 60: Diagrama 2 Casos de Uso, Nivel

166 Figura 61a: Diagrama 3 Casos de Uso, Nivel

167 Figura 61b: Diagrama 4 Casos de Uso, Nivel 2 A continuación de describen los casos de uso definidos: Nivel 1: Caso de Uso Actor Eventos Pre condiciones Post condiciones 1. Consulta indicadores de Gestión Usuario El sitio muestra las opciones que le permitirán al usuario decidir cuál tipo de indicador desea visualizar El usuario selecciona las opciones de solicitudes o contratos de los niveles de detalle o de resumen para visualizar la información que desea El usuario tiene conocimientos básicos sobre el manejo de menús Caso de Uso 2. Monitoreo del Data Warehouse

168 Actor Eventos Pre condiciones Post condiciones Administrador El sitio muestra las opciones que le permitirán al administrador decidir cuál opción manejar El usuario selecciona las opciones de reprocesamiento del Warehouse o de monitoreo de procesos si desea una información detallada sobre la última corrida realizada por el Data Warehouse El administrador entiende a detalle cuál es el resultado de la corrida del Warehouse. Se almacena en el sitio el reprocesamiento en caso de así desearlo. Nivel 2: 1. Consulta indicadores de Gestión Caso de Uso Actor Eventos Pre condiciones Post condiciones 1.1 Indicadores resumen de Solicitudes Usuario El sitio despliega un menú para que el usuario seleccione las opciones que necesite sobre el mundo de solicitudes El usuario debe conocer cuáles son las dimensiones asociadas al reporte que desea visualizar para que entienda la naturaleza del mismo El usuario entiende el resultado del reporte. El usuario está familiarizado con el manejo de umbrales de gestión Caso de Uso Actor Eventos Pre condiciones 1.2 Indicadores resumen de Contratos Usuario El sitio despliega un menú para que el usuario seleccione las opciones que necesite sobre el mundo de contratos El usuario debe conocer cuáles son las dimensiones asociadas al reporte que desea visualizar para que

169 Post condiciones entienda la naturaleza del mismo. El usuario entiende el resultado del reporte. El usuario está familiarizado con el manejo de umbrales de gestión Caso de Uso Actor Eventos Pre condiciones Post condiciones 1.3 Indicadores detalle de Solicitudes Usuario El sitio despliega un menú para que el usuario seleccione las opciones que necesite sobre el mundo de solicitudes El usuario debe conocer cuáles son las dimensiones asociadas al reporte que desea visualizar para que entienda la naturaleza del mismo. El resultado será una tabla con todos los meses del año fiscal en curso y con información en aquellos meses ya concluidos. El usuario entiende el resultado del reporte. El usuario está familiarizado con el manejo de umbrales de gestión El usuario está familiarizado con análisis comparativos de meses Caso de Uso Actor Eventos Pre condiciones Post condiciones 1.4 Indicadores detalle de Contratos Usuario El sitio despliega un menú para que el usuario seleccione las opciones que necesite sobre el mundo de contratos El usuario debe conocer cuáles son las dimensiones asociadas al reporte que desea visualizar para que entienda la naturaleza del mismo. El resultado será una tabla con todos los meses del año fiscal en curso y con información en aquellos meses ya concluidos. El usuario entiende el resultado del reporte. El usuario está familiarizado con el manejo de umbrales de gestión

170 El usuario está familiarizado con análisis comparativos de meses 2. Monitoreo del Data Warehouse Caso de Uso Actor Eventos Pre condiciones Post condiciones 2.1 Reproceso Data Warehouse Administrador El sitio despliega un rango de fechas en el que deben insertarse valores lógicos a fin de poder realizar el reprocesamiento completo del Data Warehouse El administrador debe conocer las fechas en las que desea reprocesar el Data Warehouse. El administrador entiende el impacto del reprocesamiento del Data Warehouse y la sensibilidad del mismo. El administrador conoce cómo verificar que la corrida sea exitosa. Caso de Uso Actor Eventos Pre condiciones Post condiciones 2.2 Monitoreo Procesos Administrador El sitio despliega la fecha de última corrida del Data Warehouse y su resultado por departamentos El administrador conoce de antemano cuál es el departamento sobre cuya corrida desea verificar. El administrador conoce cómo verificar que la corrida sea exitosa. Así mismo, la siguiente figura representa el diagrama de patrones de interacción correspondiente al sitio Web, donde se muestra las tareas que puede realizar el usuario en el sitio y los elementos de interfaz contenidos en el sitio:

171 Figura 62: Diagrama 5 Patrones de Interacción A continuación se describen los elementos del diagrama de Patrones de Interacción: Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Patrón de sistema. Luis Macovei. El usuario desea, mediante indicadores de gestión, el comportamiento de los procesos de Crédito de manera general. Crear un sitio Web que le permita realizar las consultas de una manera clara y precisa. Consulta de Información Está dirigida a usuarios que tengan computadora y acceso a internet - Eficiencia en la ejecución - Portabilidad de la información

172 - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Monitoreo Data Warehouse. Patrón de tarea. Luis Macovei. El usuario con rol de administrador desea verificar de manera constante las corridas del Data Warehouse para validar su correcto funcionamiento. Crear el sitio Web con una sección que contenga los elementos de control necesarios para el usuario. El usuario selecciona alguno de ellos. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Indicadores de Gestión. Patrón de tarea. Luis Macovei. El usuario con rol de usuario desea consultar en cualquier momento los diferentes resúmenes de información para los procesos de solicitudes y contratos de manera de entender el éxito o fracaso del mes. Crear el sitio Web con una sección que contenga los elementos de consulta necesarios para el usuario. El usuario selecciona alguno de ellos. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a

173 Usabilidad internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Resumen Indicador. Patrón de tarea. Luis Macovei. El usuario con rol de usuario desea consultar en cualquier momento los diferentes resúmenes de información para los procesos de solicitudes y contratos de manera de entender el éxito o fracaso del mes mediante el contraste de dicha información con umbrales de gestión previamente definidos. Crear el sitio Web con una sección que contenga los elementos de consulta necesarios para el usuario. El usuario selecciona alguno de ellos. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario Nombre, Clasificación, Autor Problema Detalle Indicador. Patrón de tarea. Luis Macovei. El usuario con rol de usuario desea consultar en cualquier momento los diferentes detalles de información para los procesos de solicitudes y contratos de manera de entender el éxito o fracaso del mes mediante la comparación del último mes generado con los meses que le anteceden del año fiscal en

174 Solución Contexto Fuerzas Usabilidad curso. Crear el sitio Web con una sección que contenga los elementos de consulta necesarios para el usuario. El usuario selecciona alguno de ellos. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Reproceso Data Warehouse. Patrón de elemento compuesto. Luis Macovei. El usuario con rol de administrador desea poder enviar una solicitud al Data Warehouse para que este se reprocese con un rango de fechas definidos previamente en vista que para dicho rango de fechas la corrida del Data Warehouse presentó problemas. Una vez que el usuario se encuentra en esta interfaz coloca la fecha con la que desea reprocesar el Data Warehouse. El cálculo del rango se hace de manera automática. El rango consiste en la misma fecha introducida para ambos extremos. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario

175 Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Monitoreo de Procesos. Patrón de elemento compuesto. Luis Macovei. El usuario con rol de administrador desea poder ver en detalle los procesos involucrados en la corrida del Data Warehouse por departamento. Igualmente desea conocer las tareas involucradas en la ejecución de cada proceso. Una vez que el usuario se encuentra en esta interfaz puede ir descendiendo mediante un mecanismo de links para poder observar los detalles asociados a la corrida de los diferentes DM y posteriormente en las tareas asociadas a cada proceso. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Resumen de Solicitudes. Patrón de elemento compuesto. Luis Macovei. El usuario con rol de usuario desea conocer de manera resumida el resultado del cierre mensual para el mundo de solicitudes. Incluyendo la comparativa de dicho resultado con un umbral de aceptación previamente definido. Una vez que el usuario se encuentra en esta interfaz debe seleccionar una serie de elementos como; dimensión, año, mes, indicador, entre otros y de esta forma generar el reporte. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a

176 Usabilidad internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Resumen de Contratos. Patrón de elemento compuesto. Luis Macovei. El usuario con rol de usuario desea conocer de manera resumida el resultado del cierre mensual para el mundo de contratos. Incluyendo la comparativa de dicho resultado con un umbral de aceptación previamente definido. Una vez que el usuario se encuentra en esta interfaz debe seleccionar una serie de elementos como; dimensión, año, mes, indicador, entre otros y de esta forma generar el reporte. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Detalle de Solicitudes. Patrón de elemento compuesto. Luis Macovei. El usuario con rol de usuario desea conocer de manera detallada el resultado del cierre mensual para el mundo de solicitudes. Incluyendo la comparativa de dicho resultado con los meses previamente generados para realizar de esta manera análisis de gestión y de comportamiento. Una vez que el usuario se encuentra en esta interfaz debe

177 Contexto Fuerzas Usabilidad seleccionar una serie de elementos como; dimensión, año, mes, indicador, entre otros y de esta forma generar el reporte en una tabla con todos los meses del año fiscal seleccionado. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Detalle de Contratos. Patrón de elemento compuesto. Luis Macovei. El usuario con rol de usuario desea conocer de manera detallada el resultado del cierre mensual para el mundo de contratos. Incluyendo la comparativa de dicho resultado con los meses previamente generados para realizar de esta manera análisis de gestión y de comportamiento. Una vez que el usuario se encuentra en esta interfaz debe seleccionar una serie de elementos como; dimensión, año, mes, indicador, entre otros y de esta forma generar el reporte en una tabla con todos los meses del año fiscal seleccionado. Sitio Web para el control del Data Warehouse y la Consulta de Indicadores de Gestión. Está dirigida a usuarios que tengan computadora y acceso a internet - Eficiencia en la ejecución - Portabilidad de la información - Satisfacción del usuario

178 Por su parte, el aplicativo de escritorio cuenta con los siguientes diagramas de casos de uso: Figura 63: Diagrama 6 Casos de Uso, Nivel 0 Figura 64: Diagrama 7 Casos de Uso, Nivel

179 Figura 65: Diagrama 8, Casos de Uso, Nivel 2 A continuación de describen los casos de uso definidos: Nivel 1: Caso de Uso Actor Eventos Pre condiciones Post condiciones 1. Consulta información de Solicitudes Usuario El sitio muestra las opciones sobre el universo de solicitudes que el usuario puede consultar El usuario selecciona la opción que necesite. Debe conocer de antemano la fecha que quiere consultar El usuario tiene conocimientos básicos sobre el manejo de menús El usuario entiende como seleccionar la fecha que desea consultar

180 Caso de Uso Actor Eventos Pre condiciones Post condiciones 2. Consulta información de Contratos Usuario El sitio muestra las opciones sobre el universo de contratos que el usuario puede consultar El usuario selecciona la opción que necesite. Debe conocer de antemano la fecha que quiere consultar El usuario tiene conocimientos básicos sobre el manejo de menús El usuario entiende como seleccionar la fecha que desea consultar Nivel 2: 1. Consulta información de Solicitudes Caso de Uso Actor Eventos Pre condiciones Post condiciones 1.1 Información de Cierre de día Usuario Al seleccionar esta opción la aplicación muestra por defecto la información del último día de cierre que se haya consultado sobre el mundo de solicitudes El usuario debe conocer de antemano la fecha que quiere consultar El usuario entiende como seleccionar la fecha que desea consultar El usuario está familiarizado con la información que se despliega El usuario conoce los tipos de solicitudes que puede consultar Caso de Uso Actor Usuario 1.2 Información de Cierre de mes

181 Eventos Pre condiciones Post condiciones Al seleccionar esta opción la aplicación muestra la información de los meses ya cerrados para el mundo de solicitudes El usuario debe conocer de antemano el mes que quiere consultar El usuario entiende como filtrar por el mes que desea consultar El usuario está familiarizado con la información que se despliega 2. Consulta información de Contratos Caso de Uso Actor Eventos Pre condiciones Post condiciones 2.1 Información de Cierre de día Usuario Al seleccionar esta opción la aplicación muestra por defecto la información del último día de cierre que se haya consultado sobre el mundo de contratos El usuario debe conocer de antemano la fecha que quiere consultar El usuario entiende como seleccionar la fecha que desea consultar El usuario está familiarizado con la información que se despliega El usuario conoce los tipos de contratos que puede consultar Caso de Uso Actor Eventos 2.2 Información de Cierre de mes Usuario Al seleccionar esta opción la aplicación muestra la información de los meses ya cerrados para el mundo de contratos

182 Pre condiciones Post condiciones El usuario debe conocer de antemano el mes que quiere consultar El usuario entiende como filtrar por el mes que desea consultar El usuario está familiarizado con la información que se despliega Caso de Uso Actor Eventos Pre condiciones Post condiciones 2.3 Información de Motivos de Retención Usuario Al seleccionar esta opción la aplicación muestra por defecto la información del último mes de cierre que se haya consultado sobre el mundo de contratos El usuario debe conocer de antemano el mes que quiere consultar El usuario entiende como filtrar por el mes o por el portafolio que desea consultar El usuario está familiarizado con la información que se despliega Así mismo, la siguiente figura representa el diagrama de patrones de interacción correspondiente al sitio de Escritorio, donde se muestra las tareas que puede realizar el usuario en el sitio y los elementos de interfaz contenidos en el sitio:

183 Figura 66: Diagrama 9 Patrones de Interacción A continuación se describen los elementos del diagrama de Patrones de Interacción: Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Sitio Escritorio para la consulta de la información de los procesos de Solicitudes y Contratos. Patrón de sistema. Luis Macovei. El usuario desea poder consultar de una manera detallada la información de los diferentes procesos de solicitudes y contratos. Crear un sitio Escritorio, mediante tecnología Excel, que le permita realizar las consultas de una manera clara y precisa. Consulta de Información Está dirigida a usuarios que tengan computadora. - Eficiencia en la ejecución - Satisfacción del usuario Nombre, Clasificación, Consulta Información de Solicitudes Patrón de tarea

184 Autor Problema Solución Contexto Fuerzas Usabilidad Luis Macovei. El usuario desea poder consultar de una manera detallada la información de los procesos de solicitudes. Por las diferentes dimensiones definidas. Crear un sitio Escritorio, mediante tecnología Excel, que le permita realizar las consultas de una manera clara y precisa. Sitio Escritorio para la consulta de la información de los procesos de Solicitudes y Contratos. Está dirigida a usuarios que tengan computadora. - Eficiencia en la ejecución - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Consulta Información de Contratos Patrón de tarea. Luis Macovei. El usuario desea poder consultar de una manera detallada la información de los procesos de contratos. Por las diferentes dimensiones definidas. Crear un sitio Escritorio, mediante tecnología Excel, que le permita realizar las consultas de una manera clara y precisa. Sitio Escritorio para la consulta de la información de los procesos de Solicitudes y Contratos. Está dirigida a usuarios que tengan computadora. - Eficiencia en la ejecución - Satisfacción del usuario Nombre, Clasificación, Autor Problema Detalle Cierre de Día de Solicitudes Patrón de elemento compuesto. Luis Macovei. El usuario desea poder consultar de una manera detallada la información de los procesos de solicitudes para el último día dado por cierre

185 Solución Contexto Fuerzas Usabilidad Una vez en la interfaz el usuario podrá seleccionar el tipo de gestión o de solicitud, el mes de proceso y el día dentro de dicho mes para poder visualizar el reporte. Igualmente podrá desplegar la lista de dimensiones por las que podrá permutar la información obtenida para brindar mayor detalle. Sitio Escritorio para la consulta de la información de los procesos de Solicitudes y Contratos. Está dirigida a usuarios que tengan computadora. - Eficiencia en la ejecución - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Detalle Cierre de Mes de Solicitudes Patrón de elemento compuesto. Luis Macovei. El usuario desea poder consultar de una manera detallada la información de los procesos de solicitudes para aquellos meses que ya hayan cerrado. Una vez en la interfaz el usuario podrá seleccionar el mes de proceso para poder visualizar el reporte. Igualmente podrá desplegar la lista de dimensiones por las que podrá permutar la información obtenida para brindar mayor detalle. Sitio Escritorio para la consulta de la información de los procesos de Solicitudes y Contratos. Está dirigida a usuarios que tengan computadora. - Eficiencia en la ejecución - Satisfacción del usuario Nombre, Clasificación, Autor Problema Detalle Cierre de Día de Contratos Patrón de elemento compuesto. Luis Macovei. El usuario desea poder consultar de una manera detallada la información de los procesos de contratos para el último día

186 Solución Contexto Fuerzas Usabilidad dado por cierre. Una vez en la interfaz el usuario podrá seleccionar el tipo de gestión o de contrato, el mes de proceso y el día dentro de dicho mes para poder visualizar el reporte. Igualmente podrá desplegar la lista de dimensiones por las que podrá permutar la información obtenida para brindar mayor detalle. Sitio Escritorio para la consulta de la información de los procesos de Solicitudes y Contratos. Está dirigida a usuarios que tengan computadora. - Eficiencia en la ejecución - Satisfacción del usuario Nombre, Clasificación, Autor Problema Solución Contexto Fuerzas Usabilidad Detalle Cierre de Mes de Contratos Patrón de elemento compuesto. Luis Macovei. El usuario desea poder consultar de una manera detallada la información de los procesos de contratos para aquellos meses que ya hayan cerrado. Una vez en la interfaz el usuario podrá seleccionar el mes de proceso para poder visualizar el reporte. Igualmente podrá desplegar la lista de dimensiones por las que podrá permutar la información obtenida para brindar mayor detalle. Sitio Escritorio para la consulta de la información de los procesos de Solicitudes y Contratos. Está dirigida a usuarios que tengan computadora. - Eficiencia en la ejecución - Satisfacción del usuario Nombre, Clasificación, Autor Problema Motivo de Retención de Contratos al cierre del mes Patrón de elemento compuesto. Luis Macovei. El usuario desea poder consultar de una manera detallada la

187 Solución Contexto Fuerzas Usabilidad información de los motivos por los cuales los contratos fueron retenidos durante el mes y por consecuencia evitando que pudieran liquidarse. Una vez en la interfaz el usuario podrá seleccionar el mes de proceso y el portafolio para poder visualizar el reporte. Igualmente podrá desplegar la lista de dimensiones por las que podrá permutar la información obtenida para brindar mayor detalle. Sitio Escritorio para la consulta de la información de los procesos de Solicitudes y Contratos. Está dirigida a usuarios que tengan computadora. - Eficiencia en la ejecución - Satisfacción del usuario Desarrollo de Aplicaciones para Usuarios Finales En este apartado se explican los elementos que en conjunto con las estructuras de datos definidas en el apartado anterior dan funcionamiento al mecanismo que soporta a las aplicaciones de usuarios finales Mecanismo de control del Data Mart Para este mecanismo se implementaron los siguientes procesos: TSV_SP_CENTRO_CONTROL Este es el proceso principal que se encarga de gestionar todos los otros procesos de la corrida del DM. Este proceso se encuentra supeditado por una tarea con una periodicidad determinada y su funcionamiento se básico consiste en la búsqueda de todos aquellos procesos de carga de dimensiones, data manual (si las hay) y ETLs que deban correr para ese día y

188 colocarlos en una tabla tsv_trn_procesos (definida en el apartado anterior) para posteriormente gestionar su ejecución. TSV_SP_ORQUESTADOR_CARGAS Este proceso es invocado por el centro de control. Su función básica es ejecutar todos los procesos de carga manual (si los hay) y de dimensiones que se encuentran dentro de la tabla tsv_trn_procesos (definida en el apartado anterior) para el día de la corrida. TSV_SP_CARGAR_DATA_QUERY Este proceso es invocado por el orquestador de cargas. Su función básica es ejecutar todos los procesos de carga de dimensiones que el centro de control haya cargado en la tabla tsv_trn_procesos (definida en el apartado anterior) para el día de la corrida. TSV_SP_ORQUESTADOR_ETL Este proceso es muy similar en comportamiento al proceso de carga de dimensiones. El enfoque de este proceso es el de la ejecución de los procesos de ETL que el centro de control haya cargado en la tabla tsv_trn_procesos para el día de la corrida. TSV_SP_CONFIRMAR_CARGA Con este procedimiento se confirman de manera exitosa todos los registros de los procesos que se hayan ejecutado de manera exitosa. Como el DM es atómico en su funcionamiento, es decir, todos los procesos deben ser exitosos para que la corrida sea considerada exitosa, de lo contrario la corrida se considerará fallida, mediante este procedimiento también se hace rollback de la información en caso que la corrida no haya resultado exitosa

189 TSV_SP_REGISTRAR_EVENTO Este procedimiento es el que se encarga de escribir en la tabla tsv_trn_eventos (explicada en el apartado anterior) todos y cada uno de los pasos por los que transcurre un proceso determinado durante su ejecución. Igualmente almacena en dicha tabla cualquier error nativo del manejador de base de datos Oracle durante la ejecución de cualquiera de los procesos asociados a la corrida del DM Mecanismo para los Indicadores de Gestión Para este mecanismo se implementaron los siguientes procesos: TSV_SP_SOLIC_IND_CONCESIONARIO / TSV_SP_CONTR_IND_CONCESIONARIO Este procedimiento se encarga de generar los indicadores de gestión asociados al universo de solicitudes y contratos respectivamente, usando como dimensión el concesionario. TSV_SP_SOLIC_IND_GRADE / TSV_SP_CONTR_IND_GRADE Este procedimiento se encarga de generar los indicadores de gestión asociados al universo de solicitudes y contratos respectivamente, usando como dimensión el grado de riesgo asociado al cliente. TSV_SP_SOLIC_IND_ORIGEN / TSV_SP_CONTR_IND_ORIGEN Este procedimiento se encarga de generar los indicadores de gestión asociados al universo de solicitudes y contratos respectivamente, usando como dimensión la cartera a la que pertenece la solicitud. TSV_SP_SOLIC_IND_ZONA / TSV_SP_CONTR_IND_ZONA

190 Este procedimiento se encarga de generar los indicadores de gestión asociados al universo de solicitudes y contratos respectivamente, usando como dimensión la zona regional asociada al concesionario. TSV_SP_SOLIC_IND_RESUMEN Este procedimiento se encarga de generar los indicadores de gestión asociados al universo de solicitudes y contratos más generales. Es decir, no toma en cuenta ninguna dimensión y se centran en el flujo de trabajo de ambos procesos para definir métricas mensuales de cada una de las fases que constituyen dicho flujo. La siguiente figura ejemplifica de manera más clara cómo funcionan todos los procesos explicados en los dos tópicos anteriores: Figura 67: Diagrama de procesos de Carga y Extracción

191 Resultado de las Aplicaciones para Usuarios Finales aplicativos: En esta sección se mostrarán las interfaces resultantes para cada uno de los Aplicativo Web Menú Principal Figura 68: Aplicativo Web Menú Principal En esta interfaz aparecen las opciones mediante las cuales un usuario con rol de usuario o administrador pueden consultar. El aplicativo Web no maneja mecanismos de seguridad debido a que la empresa automotriz acordó que se usaran los privilegios que ya poseen en su intranet por defecto en vista que este aplicativo Web estará incrustado dentro de dicha intranet

192 Monitoreo Data Warehouse Reproceso Data Warehouse Figura 69: Aplicativo Web (Monitoreo Data Warehouse Reproceso Data Warehouse) Esta interfaz cuenta con el campo para el ingreso de la fecha en la que se desea reprocesar con validaciones básicas como el hecho que la fecha de reproceso no puede ser mayor ni igual a la fecha del día, entre otras. El botón reprocesar se encarga de activar la tarea que controla al proceso de centro de control (explicado anteriormente) para que el mismo se active y cumpla su propósito

193 Monitoreo Data Warehouse Monitoreo Proceso Figura 70: Aplicativo Web (Monitoreo Data Warehouse Monitoreo Proceso) En esta interface el usuario con privilegio de administrador puede observar con detalle el resultado de la corrida del Data Warehouse separado por DM (cada departamento representa un DM). Aquí se evidencia el mecanismo de links o enlaces que se comentó anteriormente y que son los que permiten ir decantando en el nivel de detalle. Se observan entonces un extracto de los procesos asociados a la corrida del DM del departamento de Crédito y posteriormente en la sección Detalle Eventos Actividad cada una de las actividades ejecutadas por uno de dichos procesos

194 Indicadores de Gestión Resumen Solicitudes Figura 71: Aplicativo Web (Indicadores de Gestión Resumen Solicitudes) En esta interfaz se observan los pasos que debe ejecutar el usuario para poder obtener un determinado reporte. De esa forma se tiene que primero debe seleccionar el año calendario, luego el mes, posteriormente el indicador, dimensión y tipo de vehículo asociado al reporte. Finalmente debe ejecutar la consulta y observar el reporte resultante. A nivel del reporte se observa como muestra los valores correspondientes a la consulta. En ese caso la consulta es sobre la dimensión de grado de riesgo, por lo que el reporte resultante muestra la cantidad de solicitudes y el monto de dicha cantidad agrupado por cada uno de los distintos tipos de grados de riesgos. La columna umbral debe valorar mediante una coloración verde, amarilla o roja (donde verde es un valor óptimo mientras rojo es un valor crítico) el resultado de dicha medida. Sin embargo, a la fecha no se encuentra ningún umbral definido para esta dimensión

195 Indicadores de Gestión Resumen Contratos Figura 72: Aplicativo Web (Indicadores de Gestión Resumen Contratos) Esta interfaz es muy similar a la interfaz anterior, de esa manera también se pueden observar los pasos que deben llevarse a cabo para poder emitir un reporte con información relacionada al mundo de contratos. En este caso la consulta es sobre la dimensión zona por lo que el reporte resultante muestra la cantidad de contratos y el monto de dicha cantidad agrupado por cada una de las zonas regionales en los que se ubican los concesionarios que mantienen relaciones comerciales con la empresa automotriz. Al igual que lo explicado anteriormente, actualmente no existen umbrales de aceptación definidos para este indicador, por lo que la columna se muestra con la figura en blanco en lugar de alguno de los tres colores explicados en la interfaz anterior

196 Indicadores de Gestión Detalle Solicitudes Figura 73: Aplicativo Web (Indicadores de Gestión Detalle Solicitudes) En esta interfaz, al igual que en las dos anteriores se muestran inicialmente los parámetros que el usuario debe escoger para poder visualizar el reporte. En este caso se ha escogido el indicador de Solicitudes Aprobadas del conjunto de opciones que se pueden observar en la figura y de la misma forma a la interfaz de la figura 73 se escogió la dimensión de grado de riesgo. La idea de esta parametrización es para poder apreciar las diferencias entre los reportes emitidos por cada interfaz. En esta interfaz se puede observar que el reporte resultante genera una tabla con cada uno de los meses del año fiscal en curso (ordenados inclusive por la metodología del año fiscal y no del año calendario) y llena con información todos aquellos meses que ya han cerrado para dicho año fiscal. Por lo tanto y a diferencia de la otra interfaz se puede observar el detalle del indicador por meses en lugar de únicamente el mes que se escoja

197 Indicadores de Gestión Detalle Contratos Figura 74: Aplicativo Web (Indicadores de Gestión Detalle Contratos) Siguiendo con la misma metodología, en esta interfaz se observa inicialmente los parámetros que deben escogerse antes de poder visualizar el reporte. Al igual que lo explicado en la interfaz anterior se decidió escoger la misma dimensión que en la interfaz de la figura 74 para así visualizar la diferencia entre los reportes. Mientas un reporte es únicamente para el mes que se seleccione (figura 74), el reporte que compete muestra una distribución de todos los meses del año fiscal seleccionado y los valores para cada mes que ya haya concluido o cerrado

198 Aplicativo Escritorio Menú Principal Figura 75: Aplicativo Escritorio Menú Principal En esta interfaz se puede apreciar el look & feel del aplicativo para escritorio que está orientado a los usuarios con perfil analista. Cada una de las opciones permite explotar la riqueza de información del Data Warehouse, para este caso el DM de Crédito desde sus dos vertientes principales; solicitudes y contratos. A la interfaz se le añadió también un identificador del ambiente en el que está corriendo el aplicativo al igual que la versión del mismo. Esto para hacer más fácil el manejo de versiones cuando el mismo deba migrarse a otras máquinas

199 Solicitudes Detalle Gestión Diaria Figura 76: Aplicativo Escritorio (Solicitudes Detalle Gestión Diaria) En esta interfaz se puede observar la naturaleza del reporte que se va a estar generando. Aunque las medidas siempre serán la cantidad de solicitudes y el monto de la solicitud la riqueza y enorme variedad de reportes que se pueden emitir a través de esta tabla dinámica viene dado por la columna de la derecha la cual muestra todas las dimensiones por las que dicha cantidad y monto pueden discriminarse. Así mismo se han añadido filtros por defecto; el tipo de gestión (que para este caso son las solicitudes que el negocio entiende como nuevas), el mes de procesamiento y el día dentro de este mes (dado que esta es la interfaz de gestión diaria). Para el caso del reporte de la figura 78 las dimensiones por la que se observa la información so estatus y tiempo, sin embargo como se mencionó anteriormente, las posibilidades de detalle está dado por todas las dimensiones listadas a la derecha y sus diferentes combinaciones

200 Solicitudes Gestión Mensual Figura 77: Aplicativo Escritorio (Solicitudes Gestión Mensual) En esta interfaz es similar a la interfaz Web porque al igual que su contraparte de la Web muestra la información al cierre de mes sobre aquellos meses que ya han cerrado del año fiscal en curso. Sin embargo, la diferencia (al igual que con la interfaz de la figura 78) se basa en las posibilidades de combinación de las diferentes dimensiones definidas para el DM lo cual hace que el nivel de información pueda descender lo suficiente como para poder brindar un detalle más rico en relación a su contraparte de la Web. Para el caso de la figura 79 se observa que la información se está desplegando mediante la combinación del atributo de la naturaleza del cliente en combinación con la dimensión grado de riesgo asociada al cliente

201 Contratos Detalle Gestión Diaria Figura 78: Aplicativo Escritorio (Contratos Detalle Gestión Diaria) Esta interfaz se asemeja mucho a la interfaz de la figura 78 debido a que muestra información al cierre diario, la diferencia es que la información que esta interfaz despliega es sobre el proceso de Contratos. Al igual que la interfaz de la figura 79 mantiene los mismos filtros por defectos de tipo de gestión (en este caso los contratos liquidados), el mes de proceso y el día sobre el mes de proceso. Para este reporte la información que se está desplegando combina las dimensiones plan y tiempo

202 Contratos Gestión Mensual Figura 79: Aplicativo Escritorio (Contratos Gestión Mensual) Esta interfaz es muy similar a la interfaz de la figura 79. En ese sentido, también tiene como único filtro el mes del año fiscal en curso que ya ha cerrado. Por ser una interfaz relacionada con contratos entonces la información de cantidad y montos son sobre dicha vertiente. Para el caso de este reporte se han combinado dos atributos de la dimensión vehículo, la marca y el modelo. Esto con el motivo de demostrar nuevamente la riqueza de información alcanzada con este aplicativo

203 Contratos Motivos de Retención Figura 80: Aplicativo Escritorio (Contratos Motivos de Retención) Esta interfaz es única para este nivel de aplicativos. En ella se pueden visualizar los diferentes motivos de retención por los que una solicitud no puede terminar de materializarse en un contrato. En este caso la única medida es la cantidad de elementos que puedan ser agrupados por las diferentes dimensiones. Los únicos filtros que aplican para esta interfaz son el portafolio o cartera dueña de la solicitud y el mes de proceso a consultar. Sin embargo, como en todas las interfaces anteriores de este aplicativo, la lista de la derecha muestra las diferentes dimensiones o aristas por los que la información puede ser observada

204 Despliegue El despligue es la siguiente fase luego de la construcción. En dicha fase se manejan los últimos detalles, se enciende el Data Warehouse y se les permite a los usuarios conocer sus beneficios. El principal objetivo de la fase de despliegue se refiere al entrenamiento y soporte que cada persona que hará uso de los diferentes aplicativos conectados al Data Warehouse debe tener. Esta actividad fue llevada a cabo por el gerente del proyecto en dos sesiones de trabajo en conjunto con los usuarios. Para esta fase las siguientes actividades, del lado de desarrollo, ya fueron concluidas: La infraestructura se encuentra sincronizada con los componentes y ha sido probada. La validez de la arquitectura ya ha sido verificada. La base de datos se encuentra definida. La asignación de espacio para las diferentes tablas ha culminado. Los procesos de extracción, transformación y carga han sido probados en el ambiente de desarrollo. Se han hecho pruebas de cargas de datos iniciales e incrementales en el ambiente de desarrollo. Las herramientas o aplicativos para la visualización han sido probadas en el ambiente de desarrollo. Por lo tanto todos los elementos de pruebas, con excepción de la aceptación del usuario, han concluido satisfactoriamente. El despliegue del Data Mart fue realizado por partes. En una primera parte se procedió a migrar todas las estructuras de datos y procesos que conforman al Data Mart de Crédito al ambiente de pruebas preparado por la empresa para tal fin

205 Es en este ambiente de pruebas donde se realizarán todas las pruebas en conjunto con el usuario. Esto debido a que el despliegue final, o puesta del proyecto en ambiente de Producción, debe ser considerado sencillamente como una promoción de ambiente, mas no como un ambiente para validar. Sobre esta primera fase se llevó a cabo una bitácora de defectos donde se examinaron las actividades principales relacionadas con la corrida del DM desde el punto de vista de la capa de datos. Las actividades y sus resultados se pueden observar de manera resumida en la figura 81. La aceptación del usuario para esta primera parte corre por cuenta del departamento de tecnología. Figura 81: Log de Defectos para la Capa de Datos en ambiente de pruebas Efectivamente todas las actividades relacionadas con el despliegue de la capa de Datos del Data Warehouse fueron exitosas. Para la segunda parte se procedió a promover los aplicativos a emplear por los diferentes usuarios al ambiente de pruebas. A nivel del aplicativo Web se instaló en el servidor que la empresa designó para su uso bajo dicho ambiente y se configuraron los parámetros necesarios para que el aplicativo dirija sus elementos de consulta a dicho ambiente. Por su parte, el aplicativo Escritorio fue instalado en todas aquellas máquinas de los usuarios designados para la fase de prueba y se parametrizó para que sus elementos de consulta, al igual que el aplicativo Web, se dirijan a dicho ambiente. Al igual que con la primera fase, con la segunda también se llevó a cabo una bitácora de defectos por parte de los usuarios guiados por el departamento de tecnología de la empresa. En dicha bitácora se examinaron todos los ítems que permitieran la aceptación de los aplicativos por cada una de las interfaces involucradas

206 En la figura 82 se puede observar de manera resumida el log de defectos asociado al aplicativo Web. Figura 82: Log de Defectos para el Aplicativo Web en ambiente de pruebas Se puede observar que el aplicativo Web en su primer ciclo de evaluación no aprobó todos sus ítems. Sin embargo, se puede observar que a nivel de data la validación fue exitosa, por lo que a la consistencia de data de la primera fase se le suma ahora la integridad de información de la segunda. Por su parte, en la figura 83 se pueden observar de manera resumida los elementos que conforman la bitácora de defectos para el aplicativo Escritorio. Figura 83: Log de Defectos para el Aplicativo Escritorio en ambiente de pruebas

207 Al igual que con el aplicativo Web, el aplicativo Escritorio no aprobó todos sus ítems en la primera fase de pruebas. Sin embargo, se puede ver que las razones por las que falló en algunos de sus ítems vuelven a estar orientadas hacia la presentación de los datos y no a la integridad de la misma. De hecho, para el aplicativo de Escritorio la integridad de los datos fue validada de manera positiva en todas sus interfaces. En vista que los cambios para cada una de las interfaces son considerados de bajo impacto se procede a implementarlos. En las figuras 86 y 87 se observan los las bitácora de defecto generadas para cada aplicativo. Figura 84: Log de Defectos para el Aplicativo Web en ambiente de pruebas Figura 85: Log de Defectos para el Aplicativo Escritorio en ambiente de pruebas Efectivamente los errores inicialmente reportados han sido corregidos para cada aplicativo y los mismos han sido aprobados de manera satisfactoria por el usuario. Para el momento de la elaboración de este documento las pruebas continúan. El plan es esperar a que de manera natural el Data Warehouse produzca toda la información relacionada con el cierre de mes (métricas, indicadores, entre otros), y comparar dichos resultados con los que el departamento de Crédito elabora actualmente de manera manual