Universidad Nacional del Sur

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Universidad Nacional del Sur"

Transcripción

1 Universidad Nacional del Sur Departamento de Ciencias e Ingeniería de la Computación Tesis de Licenciatura en Ciencias de la Computación Data Warehousing. Relevamiento y aplicación de técnicas de modelado dimensional Alumna: María Cecilia Dómina Directoras: Mg. Elsa Estévez y Lic. Mercedes Vitturini Bahía Blanca Diciembre

2 Resumen Este trabajo ha sido desarrollado por la alumna María Cecilia Dómina bajo la dirección de la Mg. Elsa Estévez y la Lic. Mercedes Vitturini. Se presenta como tesis de la carrera de grado Licenciatura en Ciencias de la Computación de la Universidad Nacional del Sur. En este proyecto se estudia la utilización de herramientas de Data Warehousing para el análisis de datos. Se destaca la importancia de la aplicación de estas tecnologías para el conocimiento de la información de cualquier institución y la toma de decisiones basada en datos ciertos y concretos. La tesis se organiza en dos secciones. En la primera parte, se presentan y ejemplifican los principales conceptos teóricos desarrollados en esta área de las ciencias de la computación y se presentan las principales técnicas de diseño de Data Warehouses actuales. En la segunda sección se desarrolla un ejemplo de aplicación de los conceptos y técnicas estudiadas enfocados hacia una propuesta de análisis de desgranamiento de alumnos universitarios. El diseño apunta a la identificación de perfiles y patrones de los alumnos universitarios que abandonan la actividad académica. Para el caso de estudio se utiliza como modelo organizacional de partida al modelo de datos usado por el Sistema de Gestión de Académica de Alumnos SIUGuaraní. El sistema SIUGuaraní actualmente se utiliza como sistema de gestión académica en la mayoría de las universidades nacionales argentinas y particularmente en la Universidad Nacional del Sur. El presente trabajo se realizó con la colaboración del SIU1, que facilita el uso de la herramienta O3 de la empresa IdeaSoft para la implementación del caso práctico y los desarrollos y documentación que poseen sobre el tema de estudio y lo referente al SIUGuaraní. Todo lo desarrollado como parte de esta tesis queda a disposición del SIU para su publicación y futura aplicación. 1 El SIU es un área del Ministerio de Educación que desarrolla sistemas informáticos para las Universidades Nacionales. 2

3 Agradecimientos Quiero darles las gracias a todas las personitas que de alguna manera colaboraron conmigo para que este trabajo esté hoy realizado. A Mercedes por la buena predisposición de siempre y su paciencia. A Darío por su enorme colaboración. Al SIU en general por brindar las herramientas, el material, y el conocimiento para la construcción del caso práctico. Y a mi familia, amigos, compañeros y todo el equipo del SIU por su apoyo y empuje, por estar. Gracias!, sin ustedes todo hubiese sido más difícil. 3

4 Índice Resumen...2 Agradecimientos...3 Índice Introducción Sistemas para Análisis de Información Evolución de los Sistemas de Soporte de Decisiones Qué es un Data Warehouse? Objetivos de un Data Warehouse Entorno del Data Warehouse...17 Fuentes de datos...18 Limpieza y transformación de los datos...18 Almacenamiento y presentación de los datos...21 Análisis de información Aplicaciones tradicionales versus aplicaciones para análisis de información...23 Caracterización de las diferencias...24 Nivel de datos físico para análisis de información Tendencias en sistemas para análisis de información El mercado de Data Warehousing y Business Intelligence El proceso de creación de modelos analíticos Introducción al modelado multidimensional...34 Dimensiones, hechos y medidas...37 Navegación del modelo multidimensional...38 Tabla de hechos...38 Tablas de dimensión...39 Esquema estrella Ciclo de vida de un proyecto de Data Warehousing...40 Hitos del mapa de ruta del BDL...40 Planificación del proyecto...41 Definición de requerimientos...42 Diseño de la arquitectura técnica

5 Selección de Productos e Instalación...43 Modelado Dimensional lógico...43 Diseño Físico...44 Diseño de las Extracciones y Transformaciones de Datos...44 Especificación de Aplicaciones para Usuarios Finales...45 Desarrollo de Aplicaciones para Usuarios Finales...47 Puesta en producción...47 Mantenimiento y crecimiento...49 Gerenciamiento del Proyecto Técnicas para el modelado dimensional...50 Elección del Data Mart...51 Tablas de Hechos y Granularidad...52 Diseño de las dimensiones...57 Definición de las medidas...66 Diseño multidimensional avanzado Presentación del caso de estudio Qué es el SIU? El sistema de software SIUGuaraní Deserción y desgranamiento de alumnos Presentación de la solución Requerimientos y especificación del Data Mart...77 Datos considerados...77 Datos que quedaron excluidos y motivos Arquitectura del caso práctico Matriz y modelo lógico del Data Mart Modelo físico y consideraciones de diseño...83 Diseño físico de las tablas del DW que se usan para el Data Mart...84 Diseño físico del Data Mart Personalización del proceso ETL Problemas de calidad de datos...93 Controles en la definición del modelo y la generación del cubo...93 Controles en los procesos de extracción y transformación de datos...94 Problemas de calidad en el origen del dato Uso de la herramienta y análisis de datos

6 6.1 Acceso al cubo y operaciones básicas...96 Acceso al cubo y vista inicial...96 Operaciones básicas de consulta Un ejemplo de análisis sobre evolución de la matrícula Cantidad de alumnos por año académico Análisis de ingresantes Seguimiento de una cohorte Ejemplos de análisis de procedencia Análisis a nivel de país y calidad de datos Exploración de los niveles de la dimensión procedencia Articulación de colegios y carreras Un ejemplo de desgranamiento basado en la actividad académica y rendimiento Último año con actividad Personas y alumnos Actividad anual de las cohortes Seguimiento de una cohorte Seguimiento de subconjunto mayoritario de una cohorte. Análisis por carrera y rendimiento Conclusiones y trabajo futuro Conclusiones Trabajo futuro Apéndice. Documentación técnica del caso de estudio Descripción técnica de las variables del cubo Consideraciones especiales Estructuras de los archivos de texto Generación del cubo Archivos adjuntos Bibliografía

7 Capítulo 1 Introducción 1 Introducción Sin lugar a dudas, el Data Warehousing es parte integral de lo que algunos autores definen como la era de la información ya que posibilita la construcción y mantenimiento de estructuras destinadas al análisis de los datos, transformando los datos en información y la información en conocimiento [Mst2005]. El concepto de Data Warehouse (DW), cuya traducción literal sería almacén o repositorio de datos, surge en los años 90 con la necesidad y oportunidad de obtener información de los datos que habían sido recolectados durante los años anteriores por los sistemas de gestión. Así, el DW nace producto de la evolución de los sistemas para soporte de decisiones. Hasta ese momento, la información que requerían las organizaciones se obtenía a partir de consultas y procesamientos sobre las bases de datos de los sistemas operacionales. Con el transcurso del tiempo se comenzó a evidenciar que ese entorno no era suficiente para resolver las necesidades analíticas. Los sistemas del ambiente de procesamiento de transacciones en línea OLTP (online transaction processing) en general carecen de integración y no mantienen en línea la información histórica requerida para la toma de decisiones estratégicas en una organización. Además las consultas de tipo gerencial, con información resumida y desde distintas vistas, demandan el procesamiento de importantes volúmenes de datos, requiriendo recursos y deteriorando notablemente el rendimiento de los sistemas operacionales. Por esta razón generalmente debían ser disparados en horarios en que éstos no se estuvieran utilizando en producción. La práctica muestra que deben existir dos ambientes diferentes debido a que el procesamiento analítico en línea OLAP (online analytical processing) tiene necesidades, usuarios, estructuras y ritmos profundamente diferentes a los sistemas operacionales. Los datos que se utilizan son diferentes, y la tecnología que los soporta también. Se necesita del diseño de una nueva arquitectura para cubrir los requerimientos analíticos de los usuarios que sea lo suficientemente robusta para alcanzar las necesidades futuras. En este nuevo esquema para el sistema de soporte de decisiones DSS (decision support systems) el DW cumple un rol fundamental, convirtiéndose en el repositorio central y la única fuente de datos consolidados consultable para el análisis de información de toda la organización. Así, se puede organizar al sistema de información en dos grandes sectores: el de los sistemas operacionales, donde se registran los datos, y el del DW donde se procesan los volúmenes de información para obtener conocimiento. Un DW es un tipo especial de base de datos orientado a la exploración de la información histórica que contiene. El modelo que soporta la información se encuentra diseñado, estructurado e implementado con la finalidad y propósito del análisis y navegación de los datos y recibe el nombre de modelo multidimensional. 7

8 Capítulo 1 Introducción El modelado multidimensional es una técnica para diseñar modelos de datos simples y entendibles. Se busca visualizar el contenido de la base de datos como un cubo de tres, cuatro, cinco o más dimensiones. Bajo este paradigma, los usuarios se pueden imaginar navegando la información y realizando cortes a ese cubo a través de cada una de sus dimensiones. Se entiende por navegación o drilling de los datos, a la capacidad de ver información correspondiente a diferentes contextos o entornos. Por ejemplo, analizar los egresados de un determinado año y poder detallarlos por carrera. Luego analizar más profundamente una carrera para ver cómo se discriminan los egresados por cada cohorte2, etc. El modelo dimensional organiza y presenta los datos definiendo dimensiones. Se define como dimensiones a las líneas o áreas temáticas del negocio, como por ejemplo producto, sucursal, tiempo. Son entidades independientes que sirven como punto de entrada para el análisis de la información contenida en el modelo multidimensional. Llevado al ámbito universitario y para el análisis información académica de alumnos se podrían considerar a las dimensiones: carreras, lugar de procedencia, año de ingreso, entre otras. Dentro de las dimensiones pueden existir diferentes niveles de análisis o jerarquías. Para el caso de procedencia se podrían considerar los niveles país, provincia, localidad y colegio, por ejemplo. Las dimensiones se relacionan a través de hechos. Se consideran hechos a sucesos o eventos que ocurren, como por ejemplo alumnos que cursan carreras, o que rinden exámenes. Este último ejemplo estaría relacionando a las dimensiones: materia, alumno, y fecha, entre otras. Los hechos o eventos generalmente se asocian con una o más medidas (el resultado o nota, en este caso). Las medidas, métricas o indicadores, son variables numéricas que ayudan a medir el rendimiento de un negocio o proceso. En esta tesis se presentan los principales conceptos y técnicas de diseño y se resaltan la importancia y potencial de estas tecnologías para la toma de decisiones y el mejoramiento de los sistemas de gestión y la calidad de datos. La tesis se completa con un ejemplo práctico que muestra la aplicación de los conceptos teóricos. Dado que el desarrollo está basado en el modelo de datos de un sistema gestión transaccional de uso real, los resultados obtenidos podrán utilizarse para colaborar en el análisis de la problemática de deserción universitaria. El desarrollo de la tesis se organizó de la siguiente manera: en el capítulo 2 se describe la evolución de los DSS que dio origen al DW; se define y conceptualiza el área de DW y sus objetivos y se lo ubica dentro de la arquitectura de un DSS. Luego se detallan los principales componentes del entorno, destacando las diferencias de este ambiente (OLAP) respecto al de los sistemas operacionales o de gestión (OLTP). Finalmente se presentan las principales herramientas del mercado. En el capítulo 3 se especifican las características de los modelos dimensionales y las principales técnicas para diseñarlos. También se presenta una metodología de producción de DW o ciclo de vida de DW. 2 Entiéndase por cohorte al año académico en que el alumno ingresa a la carrera. 8

9 Capítulo 1 Introducción La segunda parte de esta tesis consta de tres capítulos destinados al caso de aplicación. Se presenta la temática a abordar, se desarrolla la solución explicando las decisiones de diseño adoptadas y luego se muestra el uso a través de ejemplos concretos. En este caso la temática elegida es el desgranamiento de alumnos universitarios. La deserción universitaria es un tema que ha despertado mucho interés en el último tiempo. El costo económico para el estado nacional de un alumno en la universidad, la creciente necesidad de profesionales en algunas áreas y otras causas sociales son algunos de los motivos que conducen a la pregunta de por qué una persona comienza sus estudios universitarios y luego los abandona. El caso práctico de esta tesis, además de mostrar un ejemplo de aplicación de los conceptos desarrollados busca transmitir la experiencia adquirida mediante el análisis de distintas alternativas para implementar y usar la solución. Los ejemplos de análisis de datos intentan mostrar como sería posible encontrar dentro de una institución dónde se concentran los mayores problemas, e identificar las posibles causas. Como OLTP fuente de datos se usa el sistema SIUGuaraní. El SIUGuaraní es un sistema de gestión de alumnos universitarios que administra información de gestión académica: carreras, planes de estudio, títulos, materias, egresados, inscripciones y resultados de exámenes, profesores asociados a las cátedras, asignación de aulas, asistencias, cursos de ingreso, actividades extracurriculares, equivalencias, certificados, encuestas, etc. Este sistema está desarrollado por el SIU y actualmente está implementado en la Universidad Nacional del Sur desde agosto del 2004 y también en varias universidades nacionales argentinas3. 3 A mayo del 2008 se totalizan más de 200 instalaciones 9

10 Capítulo 2 Sistemas para Análisis de Información 2 Sistemas para Análisis de Información El término de Data Warehouse (DW) surge en los años 90 con la necesidad y oportunidad de obtener información a partir de los datos que habían sido recolectados durante los años anteriores por los sistemas de gestión. En las últimas décadas el objetivo de los sistemas de información no es simplemente servir a las necesidades operacionales sino también cubrir necesidades analíticas de la información. En principio se utilizaron los mismos repositorios de datos para los diferentes propósitos referentes al procesamiento de información: de transacciones, batch y analítico. Con el transcurso del tiempo surgieron problemas que dejaron en evidencia que no es apropiado utilizar el entorno donde se opera con los datos para analizar información. Las principales razones para separar el entorno operacional del analítico radican en los datos que se utilizan, las tecnologías que los soportan y la comunidad usuaria, entre otras. Este trabajo presenta el entorno analítico o sistema para soporte de decisiones (DSS). En él, el DW cumple el rol de ser la única fuente de datos consultable. 2.1 Evolución de los Sistemas de Soporte de Decisiones La evolución de los DSS esta bien detallada en [Inm2002]. El autor plantea cómo fue la evolución natural de los sistemas y los problemas que originaron el diseño de un ambiente específico con una arquitectura estructurada en diferentes niveles de información, centrada en un DW. A continuación se resumen los hechos más importantes que dieron origen a esta evolución. Una vez que los sistemas de gestión habían sido implementados y funcionaban correctamente surgió la necesidad de obtener información a partir de los datos recolectados. Naturalmente en las organizaciones estas necesidades comenzaron a resolverse realizando consultas a sus bases de datos operacionales, dentro de lo que se conoce como ambiente OLTP. Cada sector requería diferentes extracciones de acuerdo a la información buscada. También utilizaba y reutilizaba estos datos para producir información, basándose en sus propias reglas y definiciones. Así, el procesamiento de extracciones de datos comenzó a formar una red de información que se asemeja a la estructura de una tela araña como se ilustra en la figura 1. Primero hubo extracciones, luego extracciones de extracciones, y luego extracciones de extracciones de extracciones, y así sucesivamente. Este comportamiento fuera de control en el proceso de extracción a través de la organización es tan común que se le ha dado un nombre propio: arquitectura naturalmente evolutiva o arquitectura de evolución natural. 10

11 Capítulo 2 Sistemas para Análisis de Información IndicadorA=x IndicadorA=y Figura 1. Arquitectura naturalmente evolutiva y problema de credibilidad de la información. Esta arquitectura presenta algunos problemas importantes, entre los cuales se pueden destacar la falta de credibilidad de los datos, la baja productividad, y la inhabilidad para transformar datos en información. Estos problemas se hacen más notorios con el crecimiento de la organización. La carencia de credibilidad de datos se puede ejemplificar en que un mismo indicador o reporte tiene resultados diferentes en puntos distantes de la organización (figura 1). Entonces pueden obtenerse reportes en conflicto y la información pierde credibilidad. La causa de estas inconsistencias es no tener a la información sincronizada. Las diferencias más importantes en la forma de obtener la información final en general se deben a: La referencia temporal de los datos. Los períodos considerados difieren y/o la información no está actualizada a la misma fecha. Los algoritmos de cálculo. Algunos criterios considerados de formas diferentes en la definición de datos. El nivel de extracción. Cada nivel de extracción exagera los otros problemas que ocurren en los niveles anteriores. Datos externos considerados. Pueden ser de diferentes fuentes y por lo tanto contener información diferente. Múltiples fuentes. No contar con una fuente de datos en común desde el comienzo. La productividad de este esquema es también un gran problema, especialmente cuando hay necesidad de analizar datos a través de diferentes áreas para obtener reportes corporativos. Generalmente esto requiere localizar y analizar los datos para el reporte, compilarlos, y asignar recursos al programador o analista para acompañar estas tareas. Localizar los datos requiere entre otras cosas: revisar muchos archivos, acceder a datos de lugares diferentes, para los cuales tal vez se requiera diferentes perfiles de acceso y permisos; definir qué datos tomar cuando un dato o indicador se repite y no es exactamente igual. Para compilar los datos es necesario escribir muchos programas de extracción de datos, cada uno de ellos debe ser personalizado y tiene que 11

12 Capítulo 2 Sistemas para Análisis de Información cruzar la barrera tecnológica que use la compañía. A estos dos inconvenientes de tener que localizar los datos y compilarlos hay que agregar que en general cuando el primer reporte se obtiene no se conocen los requerimientos para reportes futuros y a no ser en circunstancias muy inusuales el trabajo realizado para el primer reporte no allana el camino para los reportes siguientes, por lo que resultan costosos todos los informes. Además de los problemas de productividad y credibilidad, hay una carencia mayor de la arquitectura evolutiva naturalmente y es la inhabilidad de ir desde los datos a la información. En la mayoría de los casos para obtener determinada información hay que consultar datos que se encuentran en aplicaciones heredadas y que no están integradas. En las aplicaciones a veces se encuentran datos que sólo existen en un lugar y no pueden relacionarse con otras aplicaciones, datos distintos con igual nombre y datos iguales nombrados de diferentes formas. La integración de datos es un tema muy importante a la hora de querer obtener información. Otro obstáculo para realizar esta tarea es la falta de datos históricos en las aplicaciones. Es frecuente que en las bases de datos transaccionales sólo se guarden los datos para cumplir las necesidades operacionales, que suelen no ser suficientes para satisfacer las necesidades analíticas4. Los requerimientos de evolución propios de los sistemas de gestión los hacen inadecuados para soportar las necesidades de los DSS. Carecen de integración y existe una discrepancia entre el horizonte de tiempo necesario para el procesamiento analítico y el existente en las aplicaciones. Además esta arquitectura no es suficientemente robusta para alcanzar las necesidades futuras. Entonces se necesita un cambio estructural importante. Nivel Operacional Información: Detallada Día a día Valores corrientes/actuales Alta probabilidad de acceso Orientado a aplicaciones Nivel del Data Warehouse (datos atómicos) Información: Mayormente detallada (most granular) Asociada a período de tiempo (time variant) Integrada Orientada a una o más temáticas (subject oriented) Algo agregada o resumida (some summary). Nivel Departamental (Data Marts) Información: Parcializada, correspondiente al área en cuestión (parochial) Contiene algunos datos derivados y otros primitivos. Nivel Individual Información: Temporaria Ad hoc 5 Heurística No repetitiva Basada en pc o estaciones de trabajo. Figura 2. Arquitectura de los sistemas para la toma de decisiones diseñada en función de los niveles de información. 4 El SIUGuaraní sí mantiene la información histórica. Este sistema no tiene las características de un sistema transaccional típico donde se cargan continuamente operaciones y se maneja un gran volumen de información diaria, como podría ser un sistema de ventas por menor o un sistema de registro de transacciones bancarias, o de reservas de vuelos. 5 Entiéndase ad hoc como un análisis particular con un fin específico. 12

13 Capítulo 2 Sistemas para Análisis de Información Todo ello plantea la necesidad de una nueva arquitectura [Inm2002], basada principalmente en los tipos de datos que se utilizan, si se trata de datos primitivos y datos derivados. Esta arquitectura consta de cuatro niveles, y se muestra en la figura 2 Las principales diferencias entre los datos primitivos u operacionales y los datos derivados o datos DDS son: Los datos primitivos son datos a nivel de detalle y son usados para realizar las operaciones diarias de una compañía. Los derivados son datos sumarizados o de algún modo calculados para cumplir con las necesidades de la gestión de la compañía. Los datos primitivos se actualizan mientras que los datos derivados se recalculan, pero no se pueden actualizar. Los datos primitivos son principalmente valores actuales. Los derivados frecuentemente se corresponden con datos históricos. Los datos primitivos son operados sobre procedimientos repetitivos mientras que los derivados son operados heurísticamente, por programas y procedimientos analíticos. Los datos operacionales, que soportan las funciones del trabajo diario de oficina, son primitivos. Los datos DDS, para toma de decisiones, que soportan las funciones gerenciales, son derivados. Ejemplo: En un sistema de gestión académica, un dato primitivo sería: el alumno Juan Pérez matrícula 6767 rindió la materia Análisis matemático I, cuyo código es 7865, el día 20/10/2005; aprobó con calificación 8, y fue registrado en el acta, folio Z. En contrapartida, el dato derivado sería: Juan Pérez rindió 5 materias durante el 2005, aprobó el 80% de los exámenes rendidos durante ese año y promedia 7,25 en la carrera. En la figura 2 se observa que el nivel operacional de datos mantiene aplicaciones orientadas a datos primitivos solamente y se basa en el procesamiento de transacciones. El nivel de DW mantiene datos integrados, datos primitivos históricos que no pueden ser actualizados y datos derivados. El nivel de Data Marts contiene casi exclusivamente datos derivados, aunque el nivel de datos depende de los requerimientos de los usuarios finales y las necesidades de cada departamento. Y el nivel individual de datos es donde se hace mucho análisis heurístico. A este nivel, de análisis gerencial, se utiliza información agregada. Como se puede observar en la figura el DW se constituye como el repositorio central y única fuente de datos consolidados para análisis de información. Cumple un rol fundamental y debe tener determinadas características para asegurar el correcto funcionamiento de esta arquitectura. 13

14 Capítulo Qué es un Data Warehouse? En forma sencilla se puede decir que un DW es una colección de datos, obtenidos a partir de los datos transaccionales y específicamente estructurados para realizar consultas y analizar la información [Kim1992]. Comúnmente se dice que los DW son fuentes secundarias de información pues no generan datos por sí mismos, sino que son alimentados desde sistemas existentes internamente en la organización o desde datos externos. Típicamente los usuarios del DW tienen sólo permisos de lectura sobre este repositorio de datos. Los DW o bases de datos para procesamiento analítico (OLAP) están específicamente estructurados o diseñados para cumplir con un conjunto de metas bien diferentes a los objetivos de un sistema operacional OLTP. Por ejemplo, una meta de los OLTP es maximizar la concurrencia de actualizaciones; dicho objetivo no es pertinente en el diseño de DW donde las consultas son sólo de lectura [Mst2005]. En contrapartida, las metas de un diseñador de DW deben focalizarse en entregar un análisis multidimensional y capacidades de reportes ad hoc6 [Mst2005] y brindarlos de manera eficiente. Estos requerimientos necesitan un diseño específico de la base de datos, que se presenta en el capítulo siguiente como diseño o modelo multidimensional. La definición más tradicional del término DW fue especificada por Bill Inmon a principios de la década de los 90, quién lo definió como una colección de datos orientados al sujeto, integrados, variables en el tiempo y no volátiles para ayudar al proceso de toma de decisiones gerenciales [Inm2002] [Mst2005], donde: Orientados al Sujeto: datos que brindan información sobre un sujeto o asunto del negocio en particular, en lugar de concentrarse en la dinámica de las transacciones de la organización. Se dice que un DW está orientado a los sujetos de una organización y no a sus operaciones o procesos. En el ambiente universitario se puede pensar en alumnos, carreras, egresados, en lugar de inscripciones, registro de actas de exámenes, gestión de títulos, etc. Integrados: los datos con los que se nutre el DW provienen de diferentes fuentes y son integrados para dar una visión global coherente. Cuando se integran datos de diferentes fuentes hay que contemplar cuestiones como la estandarización de codificaciones (ejemplo: sexo como F y M, o 1 y 2, o V y M), formatos de campos (por ejemplo de fechas), nomenclaturas (datos que significan lo mismo con nombres distintos, y datos diferentes con el mismo nombre) y diferentes formas de medir algunos atributos. Variables en el Tiempo: todos los datos en el DW están asociados con un período de tiempo específico. En los sistemas operacionales se lleva tanto información asociada a algún período de tiempo, por ejemplo el año académico en que el alumno ingresa a la carrera, o fecha en que rinde un examen; así como también se lleva información corriente, ligada al momento actual, por ejemplo condición de regularidad de los alumnos. Cuando 6 Reportes ad hoc refiere a la generación de reportes personalizados por parte de usuarios expertos basados en el conocimiento del negocio. Más adelante en este trabajo se explica en detalle las características de análisis multidimensional y ad hoc. 14

15 Capítulo 2 se extraen datos de los sistemas fuentes para pasar al DW estos quedan asociados siempre a un período de tiempo en el que esa información es válida. Se puede decir que es el tiempo que corresponde al momento en que se toma la foto del sistema. El DW puede concebirse entonces como una serie de fotos tomadas en algún momento de tiempo. El elemento de tiempo puede tomar diferentes formas, desde una estampilla de tiempo en cada registro del DW hasta una estampilla de tiempo de la base de datos completa. Este último es el caso del trabajo práctico. No volátiles: los datos son estables en el DW. Se pueden agregar más datos, pero los datos existentes no son removidos. Cuando un dato ingresa al DW se carga como una foto, estática. Si ocurren cambios se cargan fotos nuevas y se mantiene la historia. Obviamente que esta definición, ya clásica, se debe tomar como la definición pura sobre DW. Sin embargo, con los años, algunos términos han sido modificados según las necesidades y capacidades del mercado, dando origen a otros conceptos como el de Data Marts (para referirse a DW sobre áreas específicas en lugar del warehouse corporativo) y otras variantes de DW donde por ejemplo es válido actualizar datos ya existentes. 2.3 Objetivos de un Data Warehouse Una de la las cosas más valiosas de una organización es su información. Esta es generalmente mantenida en dos formas: el sistema operacional de registros y el DW. En forma simplificada, el sistema operacional es donde los datos ingresan y el DW es donde se realiza análisis y se extrae información. El DW vendría a cumplir el rol de ser la fuente donde los usuarios pueden acceder a sus datos. Los objetivos fundamentales de un DW particular se van a desprender de las inquietudes que tengan los directivos de una organización. En [Kim1998] se establecen como requerimientos las siguientes consideraciones de calidad: El DW debe proveer acceso fácil a la información de una organización. Información accesible significa que administradores y analistas de una organización deben poder conectarse al DW desde sus computadoras personales. La conexión debe ser inmediata, a demanda y de alta velocidad. No es aceptable que el acceso sea a través de otra persona, sea inseguro o lento. El DW no es sólo los datos, sino también un conjunto de herramientas para consultar, analizar y presentar la información. Las herramientas de acceso deben ser simples y fáciles de usar. Los contenidos del DW deben ser entendibles y navegables. Esto quiere decir que deben estar correctamente etiquetados y que los datos pueden ser separados y combinados por el significado de toda posible medida del negocio. 15

16 Capítulo 2 Los datos del DW deben ser consistentes y de buena calidad. La información del DW debe ser creíble. Consistencia implica resolver las correspondencias entre la información de diferentes partes de la organización. Si dos medidas de una organización tienen el mismo nombre deben tener el mismo significado. Inversamente si dos medidas difieren en significado deben etiquetarse de manera distinta. Información consistente y de alta calidad significa que toda la información debiera ser tenida en cuenta y que es completa. También implica que deben estar disponibles para los usuarios las definiciones comunes (diccionario de datos) de los contenidos del DW. Los datos que se publican en el DW deben ser útiles. Como los datos provienen de diferentes fuentes de información, deben ser combinados cuidadosamente, atravesar una etapa de limpieza que debe asegurar la calidad antes de pasar a ser parte del DW. La calidad de los datos del DW debe ser una conductora para la reingeniería del negocio. El DW no puede arreglar la pobre calidad de los datos. Si los datos son opcionales y no están completos no hay nada que el DW pueda hacer. La única forma de mejorar la calidad afecta a las personas que ingresan datos al sistema y a los administradores y consiste en volver al origen del dato con mejores sistemas, mejores administraciones y mejor visibilidad del valor de buen dato. Muchas veces al publicar los datos incompletos la gente ve lo valioso que sería contar con datos de mejor calidad. De esta forma el DW puede jugar un rol clave en los esfuerzos de reingeniería del negocio de una organización. Debe ser una fuente de información adaptable y flexible a los cambios. El DW debe estar diseñado para manejar los cambios continuos de las necesidades de los usuarios, las condiciones del negocio, los datos y las tecnologías. Los datos y aplicaciones existentes en el DW no deben sufrir modificaciones cuando se agregan nuevos datos y/o nuevas preguntas a realizar. El DW debe ser un lugar seguro donde la información se encuentre protegida. El DW contiene información muy valiosa para la organización. Es necesario que existan controles de acceso efectivo a los datos. También se debe permitir a sus dueños visualizar los usos y abusos de los datos, incluso luego de haber abandonado el DW. Debe ser la base para la toma de decisiones. El DW debe contener los datos correctos para soportar la toma de decisiones. Hay sólo una verdadera salida del DW: las decisiones que son tomadas a partir de él. El DW tendrá más valor cuanto más impacte en las decisiones del negocio. Recordar que el DW surge para constituirse como la parte central de un sistema para la toma de decisiones que es lo que finalmente se está tratando de construir. Debe ser aceptado por la comunidad usuaria para considerarse exitoso. No importa si la solución construida es elegante y usa los mejores productos y plataformas si el DW no se utiliza para el propósito que fue concebido. Su uso muchas veces es opcional, a diferencia de los sistemas operacionales donde los usuarios están obligados a 16

17 Capítulo 2 utilizarlos. La aceptación de los usuarios de estas herramientas pasa por la simplicidad sobre todas las cosas. Si la comunidad del negocio no adopta al DW y continua usándolo activamente seis meses después del entrenamiento, entonces habrá fallado el test de aceptación. De esta lista es fácil ver que para poder implementar exitosamente un DW se requiere mucho más que un buen equipo técnico. Es necesario conocer las reglas del negocio, involucrar a los usuarios y contar con datos de buena calidad. Se requiere conformar un equipo de trabajo con diferentes perfiles para lograr éxito en el proyecto. 2.4 Entorno del Data Warehouse. La figura 3 presenta un esquema con los principales componentes que definen el marco para un DW. Como se mencionó anteriormente el DW es el núcleo de toda la arquitectura de un DSS. Área de limpieza y transformación de datos (Data Staging Area) E E E Servicios: limpieza, combinación y estandarización. Ajustar dimensiones comunes. No hay servicios de consultas de usuarios. Almacenamiento de datos: archivos planos y tablas relacionales. Procesamiento: ordenamiento y procesamiento secuencial Área de almacenamiento y presentación de datos (DW y Data Marts) Área de análisis de información (Herramientas de acceso a los datos, aplicaciones de usuario final) Reportes C A R G A DW A C C E S O Fuentes de datos (Sistemas operacionales y datos externos) Alertas OLAP (interfaces) Scorecards & Dashboards E Data Mining Proceso ETL DATOS INFORMACIÓN CONOCIMIENTO Figura 3. Arquitectura técnica de un sistema para la toma de decisiones basado en un DW. A continuación se dan las definiciones para cada componente del entorno, tomando como base bibliográfica [Kim1998], [Kim2002], [Inm2002], [10], [11], [12] y [13]. Los elementos se presentan en el orden en que se desarrolla esta cadena que conduce al conocimiento, que comienza con los productores de datos y finaliza en los consumidores de información. Antes de describir a cada elemento se aclara que el gráfico de la figura 3 es una adaptación propia de los vistos en la bibliografía y demás referencias consultadas y está basado principalmente en la propuesta de [Kim2002] [Kim1998]. Se puede observar la correspondencia con los niveles de información planteados en la figura 1. Esta arquitectura también concuerda la arquitectura La Fábrica de Información Corporativa (CIF)7. La propuesta de Kimball no coincide 7 Ver gráficos en referencias [10] y [11] de la sección de bibliografía. 17

18 Capítulo 2 en la forma de plantear la existencia física del DW y los Data Marts como subconjuntos de este, sino que inversamente plantea la existencia de Data Marts y el concepto de DW como unión de estos, que deben basarse en hechos (facts) y dimensiones acordadas. La visión de Inmon es más integradora, considera al DW como la fuente central de información y a partir de donde se construyen los Data Marts para los sectores. Por su parte Kimball plantea que en principio el desarrollo de un DW puede tornarse una tarea de dimensiones infinitas, y sugiere comenzar con el desarrollo de Data Marts teniendo en mente la construcción de un DW como unión de estos (desarrollo bottomup). Ambas propuestas son válidas y dependerá del problema particular cuál puede resultar más apropiada. Si el diseño de los Data Marts está bien pensado puede construirse un DW a partir del trabajo realizado, y se van obteniendo resultados a corto plazo. La definición de dimensiones y hechos conformados es esencial para el éxito a largo plazo de esta metodología de trabajo. Se observa que el gráfico de la figura 3 no considera un aspecto importante como es la retroalimentación en lo que respecta a la calidad de datos. El análisis de determinada información generalmente genera nuevas necesidades. Cuando se profundiza en la información que se quiere obtener se detectan gran parte de los problemas de calidad existentes, especialmente en los datos. Esto debe trasladarse a los sistemas fuentes y realizar las correcciones necesarias para la evolución del sistema. Esta retroalimentación y evolución es un proceso cíclico. Fuentes de datos Los sistemas operacionales son las fuentes de datos principales donde se registra toda la gestión de la organización. Son los sistemas centrales que soportan las operaciones diarias del negocio. Se acceden a través de las interfaces de las aplicaciones (APIs). Los datos que recopilan estos sistemas son la principal fuente de información del DW. También se los conoce como sistemas transaccionales o sistemas heredados. El éxito o fracaso de toda la solución de DW depende fuertemente de que los sistemas operacionales provean los datos necesarios para entender el negocio y la historia necesaria para evaluar su evolución. La calidad de los datos de estos sistemas es fundamental. Otras fuentes pueden ser datos externos a la organización (información demográfica, crediticia, financiera, etc. por ejemplo la cotización de alguna moneda), planillas de cálculos, etc. Limpieza y transformación de los datos Se utiliza el término data staging area para referirse al área de almacenamiento y al conjunto de procesos que limpian, transforman, combinan, estandarizan, archivan y preparan los datos de origen para ser usados en el DW. Es donde se realiza el proceso de transformación de datos. Las tareas principales de esta área son el ordenamiento y procesamiento secuencial de datos. 18

19 Capítulo 2 Este componente no provee ningún servicio de consulta ni presentación de información, simplemente porque esta área no está pensada ni preparada para brindar la seguridad y tiempo de respuesta propios del área de almacenamiento o presentación de datos. La forma de almacenamiento utilizada es en general la de archivos planos. Una tarea dentro de esta área es el aseguramiento de la calidad de los datos. Es para ello que se testea la consistencia, completitud e idoneidad de los datos a ser publicados a la comunidad usuaria. La creación de índices es otra tarea que también puede considerarse parte de esta etapa de gestión de datos. El proceso de Extracción, Transformación y Carga de datos El término popular ETL corresponde a la sigla en inglés de ExtractTransformLoad y significa extraer, transformar y cargar. El proceso ETL implica las tareas de capturar, integrar, transformar, limpiar, reestructurar, validar, filtrar, analizar la calidad y cargar datos en el DW. Este proceso organiza el flujo de los datos entre los diferentes sistemas operacionales principales de una organización y el área de almacenamiento y presentación de datos. Aporta los métodos y herramientas necesarias para mover datos desde múltiples fuentes, limpiarlos, reformatearlos y cargarlos en un DW o Data Mart. En ese momento los datos quedan disponibles para ser analizados por los usuarios. Otros nombres que recibe este proceso son gestión de los datos, adquisición de datos y en inglés data staging o data cleansing. Cabe destacar que la integración y transformación de datos es uno de los procesos más importantes de todo el entorno del DW. Tiene la tarea crítica de convertir el caos de datos del mundo operacional en un mundo ordenado de información. Este proceso asimila datos procedentes de tecnologías heterogéneas dentro de un entorno integrado y consistente, apto para ser consumido por los procesos de soporte de decisiones. Uno de los mayores desafíos se produce cuando los datos recibidos provienen de fuentes que los han organizado alrededor de claves diferentes. Por ejemplo en el SIUGuaraní una persona se identifica por el número de inscripción dentro de una unidad académica. En el SIUPampa8 la identificación de la persona se hace por su número de legajo. Estas fuentes necesitan ser integradas para dar una visión única de persona. Este proceso puede involucrar sofisticadas reglas de mapeo de elementos, normalizaciones y estandarización de nombres, direcciones y otros datos comunes a las fuentes para determinar cuales son los datos válidos. El nivel de esfuerzo necesario para integrar y transformar datos está fundamentalmente afectado por el nivel de conocimiento que se tenga sobre estos. Cuanto más familiar resulten los datos operacionales y los procesos que los producen más fácil resultarán estas tareas. El proceso ETL en general tiende a ser subestimado, sin embargo es altamente demandante y puede abarcar la mayor parte del tiempo de desarrollo de un DW, ocupando hasta el 80% del tiempo en un proyecto de gran magnitud. A continuación se detallan las tareas que incluye: 8 El SIUPampa es el sistema utilizado en las universidades para la gestión de recursos humanos y la liquidación de sueldos. 19

20 Capítulo 2 Limpieza de datos. Consiste en la corrección de errores de tipeo, resolución de dominios conflictivos (por ejemplo una ciudad que es incompatible con el código postal), manejo de datos perdidos (nulos o vacíos, referencias a datos que no existen), conversión a formatos estandarizados, y resolución de inconsistencias. Selección de atributos que son útiles para el DW. Por ejemplo, si lo que se quiere analizar es el rendimiento académico de los alumnos interesará saber, entre otras cosas, cuántas materias aprueba por año. Puede resultar útil saber cuáles son esas materias y las notas obtenidas; pero no interesará saber el número de acta y folio donde se registró esta información ni el día en que el dato fue ingresado al sistema. Combinación de fuentes de datos. Las fuentes se pueden combinar por medio de los valores claves o realizando mapeos difusos ( fuzzy matches ) sobre atributos que no son claves. Este ejemplo surgió en el ámbito del SIU al integrar bases de datos del SIUGuaraní de diferentes unidades académicas de una universidad9. La información de colegios secundarios era mantenida en forma independiente y no sincronizada en las diferentes implementaciones. Cada unidad académica generaba sus propios códigos y nombres. Al integrar los datos se hallaron casos como los mostrados en la figura siguiente. Unidad académica Facu1 Facu2 Facu2 Facu1 Código de colegio Cod1 Cod1 Cod2 Cod3 Colegio correspondiente Cole1 Cole2 Cole1 Cole1 Descripción utilizada Desc1Cole1 Desc1Cole2 Desc2Cole1 Desc3Cole1 Ejemplo Escuela Normal Superior N 1 Esc Sup de Comercio Esc Normal Sup Nro 1 Normal Nro 1 Figura 4. Ejemplo de problema de calidad de datos. Crear claves. Asociar un nuevo identificador a cada registro de dimensión y evitar la dependencia de las claves definidas en las fuentes. El proceso de generación de nuevas claves sustitutas (o subrogadas) impone la integridad referencial entre las tablas de dimensiones y las tablas de hechos10. Lo recomendable para las claves de dimensión es que sean numéricas y secuenciales y totalmente independientes de las claves de los sistemas operacionales. El costo de todas las tareas descriptas depende en gran medida de la calidad de los datos en los sistemas fuentes y apuntan a garantizar la calidad de los datos en el DW. La calidad debe ser una línea conductora en todo el proceso de análisis de información y toma de decisiones. El DW será actualizado con cierta frecuencia sobre la base de una carga controlada de datos correctos. La carga de datos al DW recibe también el nombre de carga en masa. La creación de agregados, esto es información agrupada que se guarda en el DW, así como también la creación de índices pueden considerarse como parte del proceso de carga de datos al DW. Estas tareas apuntan exclusivamente a resolver posibles problemas de performance. 9 En la mayoría de las universidades la implementación del SIUGuaraní se realiza por unidad académica, contando así a nivel global con diferentes bases de datos independientes. 10 Las definiciones de los conceptos de tablas de hechos y tablas de dimensiones están en el capítulo siguiente dentro de la sección de modelado multidimensional. 20

21 Capítulo 2 Almacenamiento y presentación de los datos El área de almacenamiento y presentación de datos, también denominada servidor de presentación es el lugar donde se ubican el DW y los Data Marts. En esta área los datos se organizan y guardan para ser consultados en forma directa por los usuarios, generadores de reportes y otras aplicaciones. Los datos deben ser presentados y almacenados en un formato dimensional. La definición de DW se presentó en la sección 2.2. Como se anticipó la definición clásica ha dado origen a otros conceptos para adaptarse a las diferentes realidades. El término más resonante es el de Data Mart. Un Data Mart es un subconjunto lógico del DW. Contiene datos personalizados y/o sumarizados derivados del DW, confeccionados para soportar los requerimientos analíticos de un determinado sector o función del negocio. Cada Data Mart utiliza una visión empresarial común de los datos estratégicos y provee sectorizaciones más flexibles. Entre las características de los Data Marts se destacan: Los Data Marts pueden o no localizarse físicamente en la misma máquina que el DW. Esto permite a los consumidores de la información elegir la mejor tecnología que soporte el estilo de análisis que necesiten. Los Data Marts deben ser implementados como una extensión del DW, no como una alternativa. La estrategia a largo plazo dicta que es necesario contar con la infraestructura completa para tener un DSS saludable. La construcción de Data Marts para soporte de decisiones es ideal. Sin embargo hay que tener en cuenta que la simplicidad de su diseño puede conducir a tener mucha cantidad de ellos implicando así un alto costo para administrarlos. Kimball define a un Data Mart como una porción de la torta completa que representaría el DW. Así mismo este autor presenta una metodología bottomup comenzando por el desarrollo de Data Marts para construir luego un DW como unión de estos. Argumenta que un Data Mart representa un proyecto que puede llegar a ser terminado comparado con la imposible responsabilidad galáctica de desarrollar un DW. Generalmente se ve al Data Mart como una restricción del DW a un simple proceso del negocio o a un grupo de procesos del negocio relacionados dirigidos hacia un grupo particular de usuarios. En todo Data Mart se imponen requerimientos específicos de diseño. Todo Data Mart se representa por un modelo dimensional y se construye a partir de dimensiones y hechos pactados11 para luego poder ser combinado y usado en conjunto con otros Data Marts (DW Bus Architecture). Sin la adhesión a esta arquitectura un Data Mart se convierte en una solución específica y aislada que no puede ser compartida con otras áreas del negocio en lugar de pertenecer a una solución en conjunto. Si los Data Marts se diseñan con dimensiones y hechos conformados es posible combinarlos y usarlos juntos [Kim1998]. Se dice que las dimensiones están conformadas o 11 Kimball utiliza el término fact (hecho) como sinónimo de medida o métrica. Debe interpretarse así cuando se hace referencia a hechos conformados o pactados. En general en este trabajo se utiliza el término hecho para referirse más bien al evento que tiene asociadas medidas, que a las medidas en sí. 21

22 Capítulo 2 pactadas cuando son exactamente iguales (incluyendo las claves) o una es un perfecto subconjunto de la otra. Si dos dimensiones están conformadas pueden ser combinadas perfectamente. Hechos o medidas de múltiples tablas están conformados cuando las definiciones semánticas de estos son equivalentes. Si tienen esta característica pueden tener el mismo nombre en tablas separadas y pueden ser combinados y comparados matemáticamente. Si los hechos no concuerdan entonces cada interpretación debe recibir un nombre diferente. No se cree que los dos puntos de vista sobre la construcción topdown y bottomup de un DW sean contradictorios. La perspectiva extrema topdown es completamente centralizada, la base de datos principal se debe diseñar totalmente antes de que sus partes sean sumarizadas y publicadas en Data Marts individuales. La perspectiva extremadamente bottomup es que el DW de toda la organización puede ser ensamblado a partir de Data Marts dispares y no relacionados. Ninguno de estos extremos es prácticamente posible. La idea es entonces combinar ambas propuestas, teniendo una arquitectura que guíe el diseño de todas las piezas separadas [Kim1998]. Análisis de información En la figura 3 se ejemplifican diferentes estilos de análisis de información. Estos estilos se implementan con diferentes herramientas y aplicaciones. Todo esto forma parte del área de análisis de información. Listados en texto plano y planillas de cálculo usadas para la toma de decisiones también pueden incluirse dentro de esta área. A continuación se proveen las definiciones de las herramientas más usadas para el análisis de información: Aplicaciones de usuario final. Se refiere así a la colección de herramientas que consultan, analizan y presentan información buscada para soportar una necesidad del negocio. El conjunto mínimo de estas aplicaciones de usuario consiste de herramientas de acceso a datos, planillas de cálculo, paquetes gráficos, y facilidades de interfaz de usuario para obtener simples presentaciones de pantalla. Herramientas de acceso a datos de usuario final. Se trata de herramientas que corren en clientes y que sirven para consultar, buscar, o administrar datos guardados en el DW o Data Marts. Pueden tomar la forma de editores de consultas SQL, cuya salida es en un listado de datos en pantalla o un reporte o un gráfico. Una herramienta de acceso a datos puede ser algo tan simple como una herramienta de consultas ad hoc como una sofisticada herramienta de data mining. Este último tipo de aplicaciones resulta interesante para detección de patrones y pronósticos. Herramientas de consultas ad hoc. Son un tipo especial de herramientas de acceso a datos que invitan a los usuarios a diseñar sus propias consultas en el momento. Es difícil tener un patrón de consultas cuando se utiliza análisis ad hoc. Por este motivo es conveniente que el modelo de la base de datos sea lo más simétrico posible para que todas las consultas luzcan igual. Esta es una fortaleza del modelado multidimensional de un DW. 22

23 Capítulo 2 Este tipo de consultas tan poderosas pueden ser efectivamente usadas y entendidas solo por el 10% de los usuarios potenciales del DW. El 90% restante de los usuarios potenciales debe disponer de aplicaciones preconstruidas que ofrezcan modelos de consultas (templates) en lugar de que el usuario deba construirlas. Aplicaciones analíticas. Se trata de aplicaciones de acceso a datos preconstruidas previstas para usuarios que consultan el DW no muy frecuentemente. Típicamente parametrizadas con flexibilidad para analizar innumerables combinaciones. Tales aplicaciones representan una oportunidad de encapsular las mejores prácticas de análisis de una organización. Aplicaciones para análisis de riegos, o análisis de mercados son algunos ejemplos. Aplicaciones estadísticas. Son aplicaciones establecidas para realizar análisis estadísticos difíciles y complejos como análisis de excepciones, medias, promedios y patrones. El DW es la fuente de datos para estos análisis. Estas aplicaciones analizan cantidades masivas de datos detallados y requieren un entorno razonablemente eficiente. Aplicaciones de modelado. Incluye a una variedad de aplicaciones cliente sofisticadas, con capacidades analíticas que transforman o resumen la salida del DW. Dentro de estas aplicaciones se encuentran, entre otras: Modelos de pronóstico (forecasting) que buscan hacer predicciones analizando comportamientos pasados. Modelos de clasificación de comportamientos (clustering) que agrupan y clasifican perfiles. Por ejemplo, en el ámbito universitario se podría agrupar alumnos según características personales, demográficas o socio económicas. Minería de datos. Son un tipo de consultas indirectas que buscan encontrar patrones ocultos en los datos. Los resultados más valiosos son agrupamientos, clasificaciones, estimaciones, predicciones, y asociaciones de cosas que ocurren juntas12. Hay muchos tipos de herramientas para minería de datos. Las principales incluyen árboles de decisión, redes neuronales, razonamiento basado en casos o reglas de asociación, herramientas de visualización, algoritmos genéticos, lógica difusa, y estadística clásica. Esta área también recibe el nombre de descubrir conocimiento en bases de datos KDD (Knowledge Discovery in Databases). 2.5 Aplicaciones tradicionales versus aplicaciones para análisis de información Para finalizar la descripción del entorno del DW y antes de desarrollar las perspectivas y técnicas necesarias para diseñarlo, hay que resaltar una característica importante: el DW es muy diferente a los sistemas transaccionales u OLTP. Las diferencias radican en: los objetivos principales de construcción, el perfil de los usuarios y sus necesidades, los datos que contienen 12 Un ejemplo típico en el análisis de compras en supermercados es el patrón que indica que las personas que compran pañales compran cerveza. Este tipo de resultados sirve para decidir la distribución de las góndolas. 23

24 Capítulo 2 (resaltando diferentes aspectos de estos: orientación o alineación de su estructura, integración e historicidad), el acceso y manipulación de datos (patrones de uso, ritmos de carga de datos, administración de datos, etc.). También difiere el hardware, el software, la administración y la gestión del sistema. Todo esto hace que las técnicas e instintos de diseño apropiados para el procesamiento de transacciones sean inapropiados. Es importante resaltar las diferencias entre ambos ambientes pues, la mejor manera de entender OLAP, es entender las diferencias con los sistemas transaccionales tradicionales [Mst2005]. Caracterización de las diferencias Sobre los objetivos principales Los OLTP tienen como objetivos asistir a aplicaciones específicas, y mantener la integridad de los datos. Mientras que los OLAP apuntan a asistir en el análisis del negocio, identificando tendencias, comparando períodos, gestiones, mercados, índices, etc. mediante el almacenamiento de datos históricos. Sobre el perfil de usuarios El perfil del usuario que interactúa con los sistemas OLTP se encuadra dentro de los empleados operativos de una organización. Los usuarios de un OLTP hacen que la compañía funcione. Tienen como función principal la entrada de datos. También realizan consultas a nivel de un registro por vez. Los usuarios OLTP realizan las mismas tareas una gran cantidad de veces. Por el contrario, dado el objetivo estratégico y el nivel de información que manejan los DW, el perfil del usuario sobre este tipo de sistemas corresponde a la comunidad gerencial, la cual está a cargo de la toma de decisiones. Los usuarios de un DW miran como funciona la organización y definen el rumbo a seguir. Miran qué datos son nuevos, piden que los datos erróneos sean corregidos. Los usuarios de un DW casi nunca consultan por un registro en particular, usualmente requieren que cientos o miles de registros sean buscados y sean comprimidos en un pequeño conjunto de datos de respuesta. Estos usuarios cambian continuamente los tipos de preguntas. Aunque la estructura de las consultas es similar el impacto en la base de datos varía en ir a buscar de cientos a millones de registros para ser resumidos en el pequeño conjunto de respuesta. Sobre los datos Los datos existentes en el ambiente transaccional difieren de los del entorno analítico en las siguientes características: Alineación de los datos: los OLTP están alineados por aplicación. Diferentes sistemas tienen distintos tipos de datos, los cuales son estructurados por aplicación. Se focaliza en el cumplimiento de requerimientos de una aplicación o una tarea específica. 24

25 Capítulo 2 En cambio, los sistemas OLAP están alineados por dimensión. Todos los tipos de datos están integrados en un solo sistema. Los datos son organizados definiendo dimensiones del negocio (áreas temáticas o sujetos). Se focaliza en el cumplimiento de requerimientos del análisis del negocio. Integración de datos: los datos típicamente no están integrados entre los diferentes sistemas OLTP. Son calificados como datos primitivos o datos operacionales. Son estructurados independientemente uno de otros, pudiendo tener diferentes estructuras de claves y convenciones de nombres. En los ambientes OLAP, los datos deben estar integrados. El DW, con el objetivo de alinear los datos por áreas temáticas, necesita integrar datos operacionales estandarizando estructuras y convenciones de nombres. Historia: Los OLTP usualmente retienen datos por un período de tiempo determinado, después son resguardados en almacenamientos secundarios fuera de línea. También es común que contengan sólo valores corrientes, referentes a la situación actual, y no valores históricos. Puede no incluir el tiempo como un componente de la clave. En cambio los OLAP almacenan tanta historia como sea necesario para el análisis del negocio. Retienen los valores de cada período. Es decir, almacenan una serie de fotos instantáneas de datos operacionales. La frecuencia con la cual se define el nivel de detalle es la que se indica como nivel más bajo de la dimensión tiempo. Toda esta cantidad y tipo de historia apunta a ayudar a la generación de reportes de comparación de tendencias y períodos de tiempo. Por otro lado, las bases de datos orientadas al análisis siempre contienen el tiempo como clave dado que una de las principales razones para la construcción del DW es el almacenamiento de datos históricos y el análisis a lo largo del tiempo. Sobre el acceso y manipulación de los datos Las diferencias de ambos ambientes en los objetivos, usuarios y datos implican naturalmente que tanto el uso como la administración de los datos sean diferentes. Se pueden destacar los siguientes puntos: 25

26 Capítulo 2 Ritmos de actualización Un sistema OLTP típico, como puede ser un sistema de venta por menor en un supermercado, un sistema de reserva de vuelos, o un sistema para cajeros automáticos, etc. procesa miles o incluso millones de transacciones por día. Cada transacción contiene una pequeña pieza de datos. Un sistema OLAP procesa una única transacción diaria que contiene miles o incluso millones de registros. En lugar de llamarse transacción se la denomina carga de datos de producción o copia masiva. Patrones de uso Los sistemas transaccionales normalmente mantienen un patrón de uso constante requiriendo grandes cantidades de recursos y consumiendo sólo el tiempo referido a la transacción. En contraposición, los DW tienen un patrón de uso liviano con picos de usos eventuales en el tiempo. Los picos de uso suceden cuando los datos nuevos están por primera vez disponibles y los días en que el negocio necesita determinados reportes. Manipulación de datos Los sistemas operacionales realizan una manipulación de datos registro por registro con funcionalidades de actualización de datos. Además necesitan de rutinas de validación y operaciones a nivel de registro. Generalmente involucran pocos datos en un proceso o transacción. Para el procesamiento de transacciones la base de datos dispara mecanismos de bloqueos y asignación de recursos. En cambio, los DW tienen una carga y acceso masivo a los datos y no se realizan ABMs. La carga y refresco es batch. La validación de datos se realiza antes o después de la carga. Principalmente se realizan consultas sobre varios registros y tablas, teniendo grandes volúmenes de datos involucrados en un único proceso o análisis. Es por ello que generalmente no se respetan las formas normales tan necesarias en los sistemas operacionales clásicos. Las anomalías que tienden a subsanar estas reglas de normalización no se presentan en los sistemas OLAP donde la carga de la información está automatizada y puede permitirse el manejo de redundancia controlada como punto para la mejora de los tiempos de respuesta de las consultas a la base de datos. Performance Se requiere que el sistema OLTP sea eficiente para realizar las tareas repetitivas de la comunidad operativa. No se permiten actividades opcionales que lo lentifiquen, como por ejemplo ejecutar una consulta que agrupe registros (al menos no se permiten mientras el sistema transaccional esté siendo accedido por usuarios). La mayoría de los reportes de un OLTP son listados de tablas enteras. La administración de estos sistemas se basa en el aseguramiento de la performance y la confiabilidad. Los procesos de extracción de datos para análisis suelen ejecutarse en horarios en que el sistema operacional no está en producción. 26

27 Capítulo 2 La performance en un DW es tan importante como en un sistema OLTP, pero de una forma diferente. Se esperan tiempos de respuesta rápidos a consultas agrupadoras de datos que requerirían mucho tiempo para ser resueltas en un sistema OLTP. Se requiere disponibilidad del sistema especialmente en determinados momentos y/o situaciones. Consistencia Tanto el OLTP como el DW están altamente involucrados con la consistencia de los datos. Sin embargo en los sistemas OLTP la consistencia es microscópica. Lo que importa es que se hayan procesado todas y cada una de las transacciones que se presentaron al sistema. En un DW la consistencia se mide globalmente. Se cuida que la carga actual de datos nuevos sea un conjunto completo y consistente de datos. En vez de una perspectiva microscópica se tiene una perspectiva de aseguración de calidad. En lugar de un cálculo técnico de consistencia existe una visión o juicio gerencial de esta. Se tiene cuidado sobre los estados consistentes del sistema antes de comenzar la carga de datos de producción y al finalizarla con éxito. Si forzadamente hubiera que detener una carga de datos de producción antes de que esté completa, no se podrá volver atrás registro por registro; en cambio habrá que sobrescribir el sistema entero con una nueva foto del sistema tomada antes de que comience la carga. Nivel de datos físico para análisis de información En sus orígenes el término OLAP estuvo asociado exclusivamente a bases de datos propietarias multidimensionales, también denominadas cubos13, que fue la arquitectura predominante para DW durante la década del 80. Con la evolución de las bases de datos en cuanto a funcionalidad y rendimiento a principio de los 90 s comienzan a desarrollarse DW en motores de base de datos relacionales, dando origen a los conceptos OLAP multidimensional (MOLAP), OLAP relacional (ROLAP) y OLAP Híbrido (HOLAP). En la sección anterior se explicó en detalle los sistemas OLAP. Brevemente se puede decir que se refiere a la actividad general de consulta y presentación de datos numéricos y de texto desde el DW así como también el estilo dimensional de la consulta y presentación de la información. El procesamiento analítico es el uso de los datos para tomar decisiones del negocio. Frecuentemente involucra análisis de tendencias, comparaciones de períodos, y navegación de datos. El modelo lógico de los datos para OLAP debe seguir el diseño multidimensional. Sin embargo la tecnología de la base de datos donde se implementa puede ser multidimensional o relacional, dando origen a tres categorías de productos OLAP: MOLAP, ROLAP y HOLAP. 13 El concepto de cubo será presentado en el capítulo siguiente. 27

28 Capítulo 2 OLAP Multidimensional (MOLAP) Refiere a una tecnología de bases de datos multidimensional y propietaria, también denominada cubo de datos. La performance es la característica principal. Tanto los datos detallados (o fuente) como los datos agregados o precalculados residen en el mismo formato multidimensional. Optimiza las consultas, pero suele requerir más espacio de disco y diferente software. OLAP Relacional (ROLAP) Es una tecnología que proporciona la misma funcionalidad que MOLAP con la diferencia de que los datos son guardados en una base de datos relacional. La palabra que mejor describe a ROLAP es escalabilidad, dado que puede cubrir un amplio conjunto de datos. Tanto los datos precalculados y agregados como los datos fuente residen en la misma base de datos relacional. Puede presentar problemas en los tiempos de respuestas cuando el volumen de la información a agrupar es muy grande. OLAP Híbrido (HOLAP) Es una combinación de los anteriores. La palabra que describe a esta tecnología es compromiso. Los datos agregados y precalculados se almacenan en estructuras multidimensionales y los de menor nivel de detalle en una base de datos relacional. Requiere un buen trabajo de análisis para identificar cada tipo de dato. Comparación de las distintas implementaciones ROLAP es una arquitectura flexible y general, que crece para dar soporte a amplios requerimientos OLAP. MOLAP es una solución particular, adecuada para soluciones departamentales con volúmenes de información y número de dimensiones más modestos. Al momento de optar por una de estas tecnologías deberán evaluarse: la performance que se necesita, el volumen de datos que se maneja, la escalabilidad y como se adapta la arquitectura propuesta por cada proveedor a la realidad de la organización. La tendencia del mercado de estas herramientas es hacia los sistemas HOLAP. Tanto los proveedores clásicos de MOLAP como los ROLAP están incluyendo el otro estilo dentro de su solución para abarcar las ventajas de ambos: gran capacidad de análisis y alta performance. HOLAP está bien representado en la arquitectura de la figura 3, implementando el DW en una base de datos relacional y la gran mayoría de los Data Marts como cubos multidimensionales, que pueden estar conectados al DW mediante consultas prediseñadas para mostrar información más detallada. 28

29 Capítulo Tendencias en sistemas para análisis de información El DW es el corazón de un DSS. El término DSS se suele usar como sinónimo de Data Warehousing y de Business Intelligence. En un sentido estricto, las definiciones de estos conceptos presentan algunas diferencias. El término Data Warehousing se utiliza para referir al conjunto de herramientas, tecnologías y metodologías que permiten la construcción, uso, manejo y mantenimiento del hardware y software tanto de un DW como de los datos en sí mismos. Un DSS es un sistema que colabora en las toma de decisiones gerenciales. Usualmente involucra el análisis de muchas unidades de datos de una manera heurística. Un DSS da soporte a los tomadores de decisiones en cualquier nivel gerencial, tanto en situaciones semiestructuradas y no estructuradas, a través de la combinación del juicio humano e información objetiva. De alguna manera es el nombre precedente a Data Warehousing, y el hecho de usar los datos para tomar decisiones en una organización es el fundamento de la existencia del DW. Como regla general, el procesamiento DSS no involucra la actualización de datos, sino que sólo provee los mecanismos de acceso a los datos que están en el DW y el análisis de estos. Un DSS debiera estar basado en técnicas de Data Warehousing, pero ambos conceptos tienen existencia propia. Durante mucho tiempo las organizaciones trabajaron con DSS pero no tenían el volumen ni la calidad de información que brinda el DW. Por otro lado, los DW pueden ser utilizados en sistemas expertos que guardan información histórica. Las tareas de aprendizaje, como las de análisis predictivos, escapan el alcance del concepto clásico de DSS y dan origen al término Business Intelligence (BI). La inteligencia de negocio o inteligencia empresarial, hace referencia al conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de los datos de la organización o empresa. Este conjunto de herramientas y metodologías tienen en común las características de garantizar el acceso a la información con independencia de la procedencia de los datos, brindar apoyo en la toma de decisiones, y estar orientadas al usuario final, logrando independencia de los conocimientos técnicos. El desafío principal de BI es reunir y presentar de manera organizada la información referente a todos los factores relevantes que conducen el negocio y habilitar el acceso al conocimiento a los usuarios finales de manera fácil y eficiente, con el efecto de maximizar el éxito de una organización. Existen cinco estilos diferentes y complementarios de BI, a saber: [3] [4] Análisis OLAP. Es el BI más clásico y universal. Esta funcionalidad provee la forma más sencilla de análisis, permitiendo que cualquier usuario pueda ver de manera minuciosa subconjuntos de datos interrelacionados o cubos. Sirve para descubrir relaciones entre los datos, analizar tendencias y realizar comparaciones históricas. 29

30 Capítulo 2 Tableros de comandos y paneles de control (scorecards y dashboards). Proveen facilidades de análisis sumariado y altamente repetitivo, en línea, focalizado en determinados tópicos. Se basa en una serie de indicadores. Es apropiado para gerentes y ejecutivos que requieren una visión integral del rendimiento del negocio y hacer seguimientos exhaustivos a través del tiempo de temas especiales. Notificaciones de alertas y excepciones (broadcasting). Transmiten información a diferentes puntos de la organización cuando determinados hechos suceden. Un análisis que no es en línea. Reporte empresarial (enterprise reporting). Generación de información con alto nivel de detalle para un nivel gerencial que se utiliza para tomar decisiones. Es el estilo de BI más utilizado. El énfasis está en la parte gráfica. No es en línea ni como tableros. Lo que importa es la presentación. Análisis avanzados y predictivos (data mining). Análisis estadístico de datos para generar patrones predictivos, pudiéndose delegar parte de las decisiones al sistema. Brinda capacidades completas y muy poderosas para investigaciones profundas de cualquier sector y para encontrar los detalles que se esconden tras los resultados. Desde el punto de vista técnico las áreas más importantes incluidas dentro de BI son [14]: DW arquitectura, diseño, administración, procesamiento y carga. Limpieza de datos y aseguramiento de la calidad (incluye el proceso ETL). Data mining, análisis estadísticos y pronósticos. OLAP procesamiento analítico en línea y análisis multidimensional. DSS, Sistemas de Información Ejecutiva (EIS), y otros sistemas expertos, agrupados en el término de Gestión de Sistemas de Información (Management Information Systems o MIS). Sistemas para analizar la información de otros sistemas y que sirve para la toma de decisiones. Elaboración de reportes, visualización de información y paneles de control (dashboards). Gestión en relación con los clientes (Customer Relationship Management o CRM). Otras definiciones utilizadas en sistemas de análisis de información: Sistemas de Información Ejecutiva (EIS: Executive Information Systems). Son sistemas diseñados para los ejecutivos más altos de una organización. Entre las características más importantes permiten análisis de desgranamiento (drill down) y de tendencias. Un EIS es una herramienta de BI que permite monitorear el estado de las variables de un área o unidad de la empresa a partir de información interna y externa. Se puede considerar que un EIS es un tipo de DSS cuya finalidad principal es que el responsable de un departamento o compañía tenga acceso, de manera instantánea, al estado de los indicadores de negocio que le afectan, con la posibilidad de estudiar con 30

31 Capítulo 2 detalle aquellos aspectos que no estén cumpliendo con los objetivos establecidos en su plan estratégico u operativo, y así determinar las medidas de contingencia más adecuadas. Una de las características más importantes de un EIS es que permite a usuarios con perfil no técnico construir nuevos informes y navegar por los datos de la compañía, con el objetivo de descubrir información que les resulte relevante. Esto se debe, entre otras cosas, a que la interfaz gráfica de estas aplicaciones suele ser muy atractiva e intuitiva. El EIS suele incluir también alertas de negocio, informes históricos comparativos y análisis de tendencias. Un EIS suele necesitar de un DW o Data Mart que actúe como fuente central de información, unificando, depurando e integrando las distintas bases de datos operacionales de la compañía [15]. Fábrica de información corporativa (CIF: Corporate Information Factory). Es un modelo de arquitectura propuesto por Inmon que contiene un DW, Data Marts, un almacén de datos operativos (ODS), sistemas operativos, aplicaciones para soporte de decisiones, distintas interfaces para usuarios, herramientas de data mining y demás componentes. Amplia la arquitectura de la figura 3. Para obtener más detalles consultar referencias [10] y [11]. Almacén de datos operativos (ODS: operacional data store). Un ODS es una colección de datos orientada a temáticas (subjectoriented), integrada, con valores actuales y volátiles, usada para soportar el proceso de toma de decisiones tácticas para una organización o la administración del negocio. Este concepto difiere del de DW por contener datos actuales en lugar de históricos y volátiles en lugar de permanentes. Los DW y Data Marts están orientados principalmente a soportar procesos de decisiones estratégicas. El ODS es el núcleo de la administración del negocio (business management). Ambos conceptos se complementan. No siempre es necesario implementar un ODS, sólo cuando se requiera acceso a datos actuales en forma integrada. Esto es especialmente útil cuando hay muchos sistemas operacionales que crecen en forma independiente unos de otros y necesitan consultarse en forma integrada para obtener información. La razón principal de un ODS es proveer reportes inmediatos y consistentes de resultados actuales. Requiere soportar accesos operacionales constantes y actualizaciones, por eso debe mantenerse en forma separada al DW. Juega un rol operacional, de tiempo real. Si los objetivos son sólo prever reportes y soporte de decisiones hay que evaluar su implementación y ver si estas necesidades no debieran ser cubiertas directamente por el DW. Como un ODS es necesariamente una extracción de datos transaccionales, este puede también jugar el rol de fuente del DW. 31

32 Capítulo El mercado de Data Warehousing y Business Intelligence En los últimos años la utilización de este tipo de soluciones ha crecido muchísimo dando origen a una expansión del mercado y desarrollo de diferentes herramientas. No es objetivo de esta tesis realizar un análisis del mercado. Se presenta sólo un panorama muy general. Para interiorizarse en las características de cada solución, que difieren bastante en arquitectura, funcionalidad, interfaz con el usuario y costo, entre otras cosas, se pueden consultar [19] al [40].. Se trata de un mercado variado. Existen tanto soluciones pequeñas y específicas como otras abarcativas y ambiciosas, todas en continuo crecimiento e intentando cubrir mejor y más aspectos dentro del área de BI. Existen empresas de mediana escala que sólo desarrollan soluciones de BI (denominadas pureplay ), vendedores de megaaplicaciones de software, y también soluciones pequeñas, innovadoras y especializadas (denominadas niche players ). El mercado actual está dominado por las soluciones pureplay, pero los tres tipos de proveedores tienen fuerte demanda. Varios vendedores de grandes aplicaciones e infraestructura de software se han convertido en el último tiempo en competidores mucho más fuertes en esta área, en parte por contar con otros productos propios ya implementados en las empresas y por los costos de las soluciones BI que proponen, que suelen ser menores que algunas soluciones puras, y además porque han comprado soluciones ya existentes para incorporarlas a su empresa. Los principales proveedores del mercado mundial son: Microsoft, Hyperion, Cognos, Business Objects, MicroStrategy y SAP, en ese orden, según destaca The Olap Report, la revista mundial en Business Intelligence [5]. En Argentina quienes se destacan como referentes internacionales de BI son Cognos, Business Objects son los más antiguos, operan desde los 80 MicroStrategy, SAS y SPSS. Cognos es muy fuerte en los Estados Unidos en empresas medianas y pequeñas, mientras que Business Objects es líder en Europa. MicroStrategy es fuerte en sectores como venta por menor (retail) y en grandes empresas. SAS y SPSS son tradicionales líderes en data mining. Y el segmento en Argentina lo lidera MicroStrategy, seguido por Cognos, SAP, Oracle y Microsoft, en este orden. La razón principal es el tiempo que llevan instalados en el país [3]. Otros proveedores importantes son: IBM, Pentaho, QlikView y Stratebi. La mayoría de los proveedores (denominados players o vendors) de estas soluciones se han comenzado con uno de los estilos de BI, y luego fueron extendiéndose a los demás. Cuantos más estilos abarca cada proveedor, obviamente brinda una solución más completa. La tendencia es tener una solución completamente integrada que cubra todos los aspectos de BI, lo que en el mercado se denomina suite o plataforma. Cognos y MicroStrategy se especializaron originalmente en OLAP y Business Objects en tableros. Y desde hace unos años comenzó la carrera por sumar los estilos faltantes. Algunos de los movimientos más resonantes fueron la compra de Crystal 32

33 Capítulo 2 Decisions (líder en enterprise reporting) que concretó Business Objects. Oracle compró Siebel, Hyperion compró Brio, y Cognos a Adaytum y también a Applix. Y las más recientes e importantes son la compra de Hyperion por Oracle, y la de Cognos por IBM junto con el acuerdo realizado entre SAP y Business Object. También hubo cantidad de operaciones más pequeñas. Así como algunas empresas compraron otras e integraron las soluciones, otras, como es el caso de MicroStrategy, han desarrollado sus propias herramientas. Como se puede observar, es un mercado en continuo movimiento, y la tendencia es que las grandes empresas líderes en tecnología de información se consoliden también como líderes del mercado de BI. También se espera un importante crecimiento de Pentaho, que es el más completo de los productos de software libre. El fuerte de esta herramienta está en la interfaz para manipular y limpiar datos. Tiene diferentes módulos para desarrollo de cubos, reportes, tableros de control, y data mining integrados. La solución es aún un poco dura en lo que respecta a funcionalidad e interfaz con el usuario, pero es uno de los casos más prometedores por contar con licenciamiento gratuito. Para la implementación del caso práctico su utilizó O3 de la empresa uruguaya, con sede en Argentina, IdeaSoft. Esta herramienta está disponible en el SIU para el desarrollo de este tipo de soluciones y actualmente se está utilizando en aproximadamente 15 universidades nacionales del país. Una de las ventajas de la herramienta es que permite una metodología de desarrollo práctica y sencilla de implementar, además de tener un costo de licenciamiento accesible. 33

34 Capítulo 3 El proceso de creación de modelos analíticos 3 El proceso de creación de modelos analíticos En el capítulo anterior se detallan las diferencias de ambientes y objetivos entre los sistemas OLAP y OLTP. Estas diferencias hacen que las técnicas de diseño y el modelo del ciclo de vida clásico utilizados para desarrollar un sistema operacional no resulten apropiados para el entorno analítico. En este capítulo se presentan las técnicas y metodologías principales para garantizar el éxito de un proyecto de Data Warehousing. 3.1 Introducción al modelado multidimensional El modelado multidimensional es una técnica para diseñar bases de datos simples y entendibles. Se busca visualizar a la base de datos como si fuera un cubo de tres, cuatro, cinco o más dimensiones. Cuando esto sucede, los usuarios finales pueden imaginarse navegando la información contenida, realizando cortes (slicing and dicing14) a ese cubo a través de cada una de sus dimensiones [Kim1996]. Los modelos multidimensionales brindan la habilidad de visualizar datos en una forma concreta y tangible que facilita la comprensión de estos. En un ejemplo simple aplicado al ámbito académico universitario: los alumnos rinden exámenes de diferentes materias en alguna fecha, registrándose la nota o resultado obtenido ; es sencillo pensar este hecho como un cubo de datos, con etiquetas en cada una de las aristas del cubo como se muestra en la figura 5. Figura 5. Ejemplo de cubo sobre exámenes rendidos. Cualquier punto dentro del cubo es la intersección de las coordenadas definidas por los lados. Para el ejemplo los lados del cubo son nombrados: alumno, materia y fecha. Es posible imaginar que en los puntos interiores es donde se guardan las medidas asociadas a la combinación de alumno, materia y fecha, en este caso el resultado o nota. 14 Slicing y dicing se traduce como rebanar y cortar en dados. Refleja la acción de partir un cubo de información en cubos más pequeños para focalizar el análisis. 34

35 Capítulo 3 El proceso de creación de modelos analíticos Dim_Alumno Alumno_cod Alumno_desc Dim_Fecha Fecha Mes Año Examenes Dim_Materia Materia_cod Materia_desc Alumno_cod Materia_cod Fecha Nota Figura 6. Ejemplo de modelo dimensional sencillo sobre exámenes rendidos. En la figura 6 se muestra el modelo dimensional que refleja la situación planteada, mientras que en las figuras 7 y 8 se puede apreciar parte del modelo típico de dependencias entre datos15, permitiendo la comparación entre ambos diseños. Figura 7. Ejemplo de modelo de dependencias de datos del SIUGuaraní referente a exámenes rendidos. Las figuras 7 y 8 ciertamente revelan con más detalle las relaciones entre los datos que la figura del modelo dimensional, pero no contribuyen al entendimiento la situación que describen 16. Desafortunadamente la mayoría de las personas no pueden retener en la mente un diagrama como este y no pueden entender como navegarlo útilmente. Para el problema de análisis de información, las relaciones existentes entre los datos se ven mejor dinámicamente en una pantalla que en diagramas estáticos que el usuario trata de mantener en su mente. Ambos modelos (dimensional y de dependencias de datos) de un negocio son capaces de guardar exactamente los mismos datos, y son capaces de soportar exactamente 15 El modelo de dependencias de datos también es llamado a veces diagrama entidad relación (DER). Aunque no sean lo mismo. De hecho, también es posible usar un DER para representar un modelo dimensional. 16 Se muestran sólo algunas tablas relacionadas con el ejemplo de todo el modelo de datos del SIUGuaraní. El modelo de datos real es más complejo. 35

36 Capítulo 3 El proceso de creación de modelos analíticos el mismo análisis final. Es sólo que se elige presentar los datos de una manera diferente, en un formato simétrico. En el ejemplo, el modelo dimensional provee un sentido natural para descomponerlo en los componentes alumno, materia y fecha. Los usuarios usarán la palabra dimensión en una conversación estén o no visualizando un cubo de datos. La atracción central del modelo dimensional es su simplicidad, que permite a los usuarios entender las bases de datos, que el software las navegue eficientemente y tiene la capacidad de adecuarse a los cambios. Figura 8. Ejemplo de modelo de dependencias de datos del SIUGuaraní. Detalle de tablas principales sobre información de exámenes rendidos. La distinción entre los modelos dimensionales y de dependencias de datos está centrada en el diseño de un DW. Un DW debe ser construido desde la simple perspectiva dimensional en lugar que desde la compleja perspectiva de las dependencias de datos para servir a su propósito17. Un modelo dimensional se basa conceptualmente en uno o más hechos. Cada hecho está asociado a una o más medidas y a un conjunto de dimensiones18. Se implementa mediante un conjunto de tablas. Las tablas pueden contener hechos (tablas de hechos), o descripciones de las dimensiones (tablas de dimensiones, de búsqueda o de catálogo). Las tablas de hechos relacionan dimensiones en su nivel de granularidad respectivo y contienen las medidas asociadas a los hechos que describen. El modelo multidimensional de un DW se compone de diferentes submodelos, también dimensionales, que se corresponden con los diferentes Data Marts. Cada Data Mart debe tener al 17 El DW debe responder a un modelo lógico multidimensional, más allá de que sea implementado en una base de datos multidimensional (MOLAP) o en una relacional (ROLAP). 18 En muchos textos no se distingue entre los términos hecho y medida, utilizándose el término fact para referirse a ambos. Aquí en general se utiliza el término hecho para referirse más bien al evento o suceso a medir que a la medida, o métrica en sí. 36

37 Capítulo 3 El proceso de creación de modelos analíticos menos una tabla de hechos, y en general tiene muchas tablas de dimensiones. También cada tabla de hechos define en sí misma un submodelo dimensional que es parte de otros que lo contienen. Dimensiones, hechos y medidas El modelo dimensional organiza y presenta los datos definiendo dimensiones. Las dimensiones son líneas o áreas temáticas del negocio. Por ejemplo en un sistema de ventas, son dimensiones producto, sucursal, tiempo. Representan a las entidades independientes que sirven como punto de entrada para el análisis de la información. En el ámbito universitario y sobre el análisis de comportamiento académico de alumnos se podrían considerar a las dimensiones: carrera, lugar de procedencia, año de ingreso, entre otras. Cada elemento de una dimensión tiene una clave, que lo identifica en el mayor nivel de detalle y un conjunto de atributos. Los atributos representan categorías o agrupaciones de elementos y tienen la finalidad de mostrar a la información de cada dimensión en diferentes niveles de detalle y agrupar los elementos para ser analizados. Las relaciones entre los atributos de cada dimensión determinan jerarquías. Las jerarquías son ordenamientos lógicos y puede que exista más de una jerarquía dentro de la misma dimensión, pero siempre podrá identificarse una jerarquía principal. Por ejemplo para la dimensión lugar de procedencia, la clave está dada por la identificación del colegio. El colegio determina a la localidad, la localidad a la provincia y esta última al país, presentando cuatro niveles de granularidad para analizar a la información. La jerarquía principal (y única de esta dimensión) está dada por los atributos país, provincia, localidad y colegio, en ese orden. En este caso la relación entre los atributos, viéndola del nivel más detallado al más agrupado es siempre de muchos a uno. Este tipo de relación padrehijos en las jerarquías de atributos de una dimensión es el caso más general, pero no el único. Algunas de las soluciones, como es el caso de O3, tienen la limitación de permitir modelar una jerarquía única por dimensión y donde los niveles deben estar determinados por relaciones de tipo padrehijos. En caso de necesitar representar diferentes jerarquías estas deberán modelarse como dimensiones separadas19. Los atributos de diferentes dimensiones se relacionan a través de hechos. Se consideran hechos a sucesos o eventos que ocurren, como por ejemplo alumnos que cursan carreras, o que rinden exámenes. Estos eventos generalmente están asociados a una o mas medidas. Las medidas, métricas o indicadores son variables numéricas que ayudan a medir el rendimiento de un negocio. Estas medidas pueden ser de dos tipos: básicas y derivadas. Las medidas básicas existen dentro del DW junto a los atributos que las caracterizan. Pueden provenir de diferentes fuentes, tener diferentes niveles de granularidad y estar determinadas por diferentes 19 Un ejemplo puede ser la dimensión producto, donde la jerarquía principal estaría dada por el código de producto, la línea, la categoría y el rubro, y además pueden existir jerarquías secundarias como el color o la marca. 37

38 Capítulo 3 El proceso de creación de modelos analíticos hechos o eventos. Por ejemplo la variable unidades vendidas puede definirse a nivel de día para la dimensión tiempo mientras que la variable unidades en stock puede ser llevada semanal o mensualmente. Las medidas derivadas se calculan a partir de las básicas y pueden o no estar almacenadas físicamente en el DW. Un ejemplo de medida derivada podría ser el cálculo de las ganancias a partir de las ventas menos los costos. Navegación del modelo multidimensional Se entiende por navegación o drilling a la acción de consultar datos dentro de un modelo multidimensional. Estas facilidades están determinadas por las dimensiones y sus jerarquías, que definen el mapa de caminos para la navegación de los datos. Existen distintos modos de buscar información. Se utilizan términos específicos según el tipo de consulta que se realice: Navegar (drilling o slice and dice20) es la habilidad de acceder al DW o Data Mart a través de sus diferentes dimensiones. Es el proceso de separar y combinar datos de una misma manera. Agregar (drillup o rollup) es la acción de moverse hacia un atributo superior dentro de la jerarquía de una dimensión (navegación ascendente, también denominada agregación dinámica). Desagregar (drilldown o rolldown) es cuando se analiza información a mayor nivel de detalle dentro de una dimensión (navegación descendente). Trasversar (drillacross) para analizar información de dimensiones acordadas sobre diferentes hechos (navegación entre diferentes tablas de hechos, modelos o cubos). También se utiliza este término para referirse a la navegación interdimensional. Atravesar (drillthrough). Esto es cuando los Data Marts de tipo MOLAP se conectan al DW a través de consultas predeterminadas para visualizar información con un grado de detalle que no está incluido en el cubo. La operación más común en análisis de tipo OLAP es el drilldown. La mayoría de las herramientas brindan esta operación como la acción por defecto al seleccionar o hacer clic sobre algún valor. Tabla de hechos Una tabla de hechos es una tabla primaria en cada modelo (o submodelo) dimensional que contiene medidas del negocio. Cada medida es interpretada como la intersección de todas las dimensiones que la definen. Toda tabla de hechos representa una relación muchos a muchos entre las dimensiones y contiene un conjunto de dos o más claves foráneas que la vinculan a sus respectivas tablas de dimensión. Las tablas de hechos representan los sucesos ocurridos. No se debiera intentar llenarlas con ceros representando que nada ha sucedido. 20 El término slice and dice refiere a la acción de rebanar y cortar en cuadraditos un cubo de información. 38

39 Capítulo 3 El proceso de creación de modelos analíticos El nivel de detalle de cada dimensión que se utiliza en la tabla de hechos define la granularidad de las medidas. Las medidas más útiles son numéricas y aditivas. Pero no todas las medidas son aditivas, existen medidas semiaditivas y no aditivas. También es posible que la tabla de hechos no contenga medidas y sólo represente las relaciones entre dimensiones. Tablas de dimensión Las tablas de dimensión son un conjunto de tablas compañeras o guías para una tabla de hechos. Cada dimensión es definida por su clave primaria que sirve como base para la integridad referencial con cualquier tabla de hechos a la cual se une. La mayoría de las tablas de dimensión contienen muchos atributos o campos de texto que sirven para restringir y agrupar las consultas del DW y determinan los niveles de análisis. El objetivo de los atributos de las estas tablas es servir como filtros o encabezamientos de las consultas de usuarios. Por ejemplo al consultar cantidad de alumnos de un determinado año discriminados por carreras, la dimensión año se está usando como restricción, para filtrar un valor, y la dimensión carreras como encabezamiento del reporte. Algunas veces un atributo numérico puede confundirse con una medida. En estos casos hay que preguntarse si se usa para describir una dimensión o para medir algo del negocio. El tamaño de un producto y la edad de un alumno son ejemplos de atributos numéricos. Hay tablas de dimensión que son íntegramente descriptivas. Otras, llamadas tablas de catálogo o de búsqueda, además de contener las descripciones asociadas a la clave primaria, se utilizan para representar relaciones entre dimensiones relacionadas. De esta forma se evita la redundancia del dato en la tabla de hechos cuando el valor de una dimensión depende del valor de otra (a estos casos se los denomina subdimensiones). Por ejemplo, si en la tabla de hechos se representa la actividad académica de los alumnos y el identificador de persona se utiliza en la tabla de hechos, datos como el sexo, la localidad de procedencia y otros que dependen de la persona, y no de cada examen rendido, pueden guardarse en una tabla de catálogo y obtenerse de ahí en lugar de estar repetidos en cada registro de la tabla de hechos. Es una forma primaria de normalizar algunos datos para evitar redundancia y reducir el tamaño de la tabla de hechos21. Esquema estrella Cada tabla de hechos está entonces rodeada por un conjunto de tablas de dimensiones que describen precisamente el contexto de cada registro medido. Por esta característica la estructura de los modelos dimensionales es llamada esquema estrella. Lo primero que se observa en el esquema dimensional resultante es su simplicidad y simetría. Se ha demostrado que los modelos dimensionales son entendibles, predecibles, extendibles y altamente resistentes para el análisis de información del negocio que se busca. La 21 Cabe aclarar que la estructura interna final de una solución MOLAP estará totalmente desnormalizada, sin embargo pueden considerarse algunas normalizaciones en las etapas intermedias de construcción. 39

40 Capítulo 3 El proceso de creación de modelos analíticos naturaleza simétrica de este modelo soporta especialmente las consultas adhoc de los usuarios del negocio y resulta eficiente en los tiempos de respuesta. 3.2 Ciclo de vida de un proyecto de Data Warehousing Las metodologías para construir un DW difieren claramente del clásico ciclo de vida de desarrollo de sistemas operacionales. Mientras que este último está guiado por los requerimientos de los usuarios, el desarrollo de un DW es conducido por los datos. Una vez que se identifican los datos existentes, se los integra, se desarrollan las herramientas de explotación y finalmente se atiende a los requerimientos de consultas de los usuarios. Más específicamente, la construcción de un DW está guiada por las necesidades de los usuarios y por los datos existentes para saciarlas. La metodología para construcción de un DW más utilizada es la propuesta por Kimball, que recibe el nombre de ciclo de vida dimensional del negocio o BDL (Business Dimensional Lifecycle). Las etapas del BDL se ilustran en la figura 9. En el diagrama se puede observar la secuencialidad, dependencia y concurrencia de las tareas. Las etapas no están temporalmente organizadas, es decir no se determinan tiempos, plazos, ni duración de las tareas. Diseño de la arquitectura técnica Selección de productos e instalación Modelado dimensional Planificación del proyecto Diseño fisico Diseño de Requerimientos Especificación de aplicaciones para usuarios finales Diseño de las Extracciones y Transformaciones de Datos Puesta en producción Mantenimiento y crecimiento Desarrollo de aplicaciones para usuarios finales Gerenciamiento del proyecto Figura 9. Ciclo de vida dimensional del negocio (BDL). Hitos del mapa de ruta del BDL El ciclo de vida de un DW comienza con la planificación del proyecto. Es en este momento donde se evalúa la buena disposición de la organización para una iniciativa de Data Warehousing, se establece el alcance preliminar, los recursos, y se lanza el proyecto. Luego, la gestión continua del proyecto servirá para mantener el resto del ciclo de vida dentro de la planificación realizada. La tarea siguiente se focaliza en la definición de los requerimientos del negocio. Observar que existe una flecha con doble dirección entre la planificación del proyecto y esta etapa debido a que hay mucha interrelación entre ambas actividades. La alineación del DW con los requerimientos del negocio es absolutamente crucial. La mejor tecnología no salvará a un DW que 40

41 Capítulo 3 El proceso de creación de modelos analíticos falla en focalizar en ellos. Los diseñadores del DW deben entender las necesidades de los usuarios y trasladarlas en consideraciones de diseño. Los usuarios del negocio y sus requerimientos tienen impacto en casi todas las decisiones de diseño e implementación a realizarse durante el transcurso del proyecto de Data Warehousing. En la figura se observa que siguiendo a la definición de los requerimientos se desprenden tres líneas de trabajo paralelas. La línea superior tiene que ver con la tecnología. El diseño de la arquitectura técnica establece el entorno general para soportar la integración de múltiples tecnologías. Luego, en función de esta arquitectura se pueden evaluar y seleccionar los productos específicos. Observar que la selección de productos no es una de las primeras actividades del ciclo de vida. Es un error frecuente seleccionar productos antes de entender bien que es lo que se está tratando de lograr. La línea de trabajo del centro se focaliza en los datos. Se comienza trasladando los requerimientos en un modelo dimensional que luego es transformado en una estructura física. Durante las actividades de diseño físico se presta especial atención a las estrategias de puesta a punto para lograr buenos tiempos de respuesta (performance tuning). Esta actividad incluye la creación de agregaciones, índices y particiones. La última parte es la etapa donde se diseñan y desarrollan los procesos ETL. El tercer conjunto de tareas que siguen a la definición de requerimientos es el diseño y desarrollo de aplicaciones analíticas. Estas aplicaciones son necesarias para completar el proyecto de Data Warehousing y deben satisfacer un gran porcentaje de los requerimientos analíticos de los usuarios del negocio. Luego se unen la tecnología, los datos y las aplicaciones, junto con una buena dosis de conocimiento y soporte, para realizar una implementación armoniosa. De ahí en más el mantenimiento constante es necesario para asegurar que el DW y su comunidad usuaria se mantengan saludables. Finalmente el crecimiento futuro del DW se realiza iniciando proyectos posteriores. Cada uno de ellos lleva a retornar nuevamente al comienzo del ciclo de vida [Kim2002]. Presentado el mapa de ruta general se pasará a describir con más detalle cada una de las actividades de las etapas del BDL. Planificación del proyecto La planificación busca identificar la definición y el alcance del proyecto de DW, incluyendo justificaciones del negocio y evaluaciones de factibilidad. Se focaliza sobre recursos, perfiles, tareas, duraciones y secuencialidad. El plan resultante identifica todas las tareas asociadas con el BDL y las partes involucradas. 41

42 Capítulo 3 El proceso de creación de modelos analíticos Antes de comenzar un proyecto de DW o Data Mart hay que evaluar la buena predisposición para su realización. Debe existir la demanda. Se debe contar con al menos un usuario sponsor sólido y con el entusiasmo de otros. El usuario sponsor debiera tener una visión del impacto potencial del DW dentro de la organización. Otro factor crítico es la viabilidad: técnica, de recursos, pero especialmente de datos. Si no se cuenta con datos de buena calidad el proyecto fracasará. Otro punto importante de esta etapa es la conformación del equipo de trabajo. Los perfiles del personal afectado a la construcción de un DW son amplios y variados. Se requieren: usuarios del negocio, sponsors, líderes, gerentes del proyecto, analistas, arquitectos, administradores de bases de datos, diseñadores, responsables de extracción, desarrolladores, instructores, soporte técnico, seguridad informática, programadores, analistas de aseguramiento de calidad, entre otros. Definición de requerimientos Otro factor determinante en el éxito de un proceso de Data Warehousing es la interpretación correcta de los diferentes niveles de requerimientos expresados por los distintos niveles de usuarios. Los diseñadores de los DW deben entender los factores claves que guían al negocio para determinar efectivamente los requerimientos y traducirlos en consideraciones de diseño apropiadas. Los requerimientos del negocio deben determinar el alcance del DW (qué datos debe contener, cómo debe estar organizado, cada cuánto debe actualizarse, quiénes y desde dónde accederán, etc.) e impactan en todos los aspectos del proyecto. La forma de relevar los requerimientos es entrevistando a los usuarios finales. Durante este proceso los diseñadores descubren las necesidades y expectativas de la comunidad usuaria. El proceso de entrevistas debe intercalarse entre grupos de usuarios del DW y grupo de técnicos de los sistemas fuentes. A medida que se van planteando las necesidades de análisis se precisa conocer si esas necesidades pueden satisfacerse con los datos y estructuras existentes. Las entrevistas deben ser preparadas en función del perfil del usuario a entrevistar y no debieran durar más de una hora. Una vez obtenidos los requerimientos, estos deberán ser priorizados y consensuados con los usuarios. Diseño de la arquitectura técnica La arquitectura técnica es el anteproyecto para los servicios y elementos técnicos del DW. Sirve para integrar las numerosas tecnologías. En el capítulo anterior se presentó la estructura general de esta arquitectura. Dicha estructura debe ser adaptada al caso a desarrollar, basándose principalmente en las necesidades del negocio. Para establecer el diseño de la arquitectura técnica del ambiente de Data Warehousing se deben tener en cuenta tres factores: los requerimientos del negocio, los ambientes técnicos actuales y las directrices técnicas estratégicas planificadas a futuro. 42

43 Capítulo 3 El proceso de creación de modelos analíticos Se puede hacer una analogía entre los planos arquitectónicos de una casa y la arquitectura de un DW. Es necesario tener un plano de lo que se desea antes de comenzar, no se trata simplemente de reordenar y explotar la información. Al igual que en una construcción, los planos sirven para comunicar los deseos entre los clientes y el arquitecto, como así también para medir esfuerzos y materiales necesarios para la obra (comunicación, planificación, flexibilidad y mantenimiento, documentación, productividad y reutilización), y también serán de ayuda cuando haya que remodelar o incorporar modificaciones. La arquitectura técnica se divide en dos partes, la parte interna del DW (back room) y la cara pública (front room), que interactúan constantemente. Mientras los requerimientos del negocio indican qué se necesita hacer, la arquitectura técnica responde el interrogante de cómo se hará [Mst2005]. Selección de Productos e Instalación Utilizando el diseño de la arquitectura técnica como marco, es necesario evaluar y seleccionar los componentes específicos como ser la plataforma de hardware, el motor de base de datos, la herramienta de ETL o el desarrollo pertinente, herramientas de acceso, etc. Una vez evaluados y seleccionados los componentes se procede con la instalación y prueba de los estos dentro de un ambiente integrado [Mst2005]. Modelado Dimensional lógico Una vez recolectados los requerimientos del negocio y habiendo auditado los datos existentes en los sistemas operacionales están dadas las condiciones para comenzar con el diseño del DW. Diseñar los modelos de datos para soportar los requerimientos analíticos de los usuarios requiere un enfoque diferente al usado en los sistemas operacionales. Básicamente se comienza con una matriz donde se determina la dimensionalidad de cada indicador y luego se especifican los diferentes grados de detalle (atributos) dentro de cada concepto del negocio (dimensión), como así también la granularidad de cada indicador (variable o métrica) y las diferentes jerarquías que dan forma al modelo dimensional del negocio, BDM (Business Dimensional Model) o mapa dimensional. En [Kim1998] se propone una metodología para construir modelos dimensionales que comienza identificando los correspondientes Data Marts (como conjunto de indicadores) y las dimensiones de estos. Luego sigue con la construcción de una matriz dimensional de alto nivel (DW Bus Architecture Matrix). En la matriz se ubican a los Data Marts como filas y a las dimensiones como columnas y se marcan las intersecciones de aquellas dimensiones que intervienen en cada Data Mart. La metodología continúa con el diseño multidimensional de cada Data Mart. Se definen cuatro pasos: primero la elección del Data Mart, segundo la declaración de la granularidad, tercero la elección de las dimensiones y cuarto la elección de las medidas o 43

44 Capítulo 3 El proceso de creación de modelos analíticos indicadores. Además, recomienda un conjunto de diagramas que serán de gran ayuda en esta etapa del proyecto: DW Bus Architecture Matrix, diagrama de tabla de hechos, detalle de tablas de hechos y diagrama de dimensiones. También el análisis de alto nivel de los sistemas fuentes colabora en mejorar las estimaciones y alcances del modelo realizado. Una de las pautas que se resalta es la comunicación y la validación del diseño entre el equipo de desarrollo del DW y la comunidad usuaria. Diseño Físico El diseño físico de las base de datos se focaliza en la selección de las estructuras necesarias para soportar el diseño lógico. En el modelado dimensional el diseño lógico y el físico se asemejan mucho. Algunos de los componentes de esta etapa son la definición de convenciones y estándares de nombres y seteos específicos del ambiente de la base de datos. El diseño físico se enfrenta a las actividades de puesta a punto de la performance del DW que consisten principalmente en la creación de índices y tablas agregadas. Las estrategias de particionamiento son también determinadas en esta etapa. Las agregaciones son la técnica de puesta a punto de mejor impacto sobre el tiempo de respuesta de las consultas que efectuarán los usuarios. Este tema es abordado al final de la próxima sección. Otros puntos a resaltar de esta etapa son: planes de desarrollo del modelo físico, convenciones de nombres y estándares, uso de sinónimos, uso de herramientas de modelado para la generación y mantenimiento del modelo físico, estimaciones de volúmenes, planes y estrategias de indexación, consideraciones sobre memoria y tamaño de bloque, parametrización, particionamiento de tablas con gran volumen de datos, sistemas de tolerancia a fallas, monitoreo, etc. En este trabajo no se profundizan estos temas. Se recomienda leer [Kim1998] junto con la documentación particular del motor de base de datos que se decida utilizar. Diseño de las Extracciones y Transformaciones de Datos Esta etapa consiste del diseño y desarrollo del proceso ETL, descripto en el capítulo 2, y es típicamente la más subestimada de las tareas en un proyecto de DW. Todas las actividades de esta etapa son altamente críticas pues tienen que ver con la materia prima: los datos. La calidad de los datos es un factor determinante en el éxito de cualquier proyecto de análisis de información. Es en esta etapa donde deben sanearse todos los inconvenientes relacionados con la calidad de los datos fuente. La desconfianza y pérdida de credibilidad del DW serán resultados inevitables si el usuario encuentra información inconsistente. 44

45 Capítulo 3 El proceso de creación de modelos analíticos Son muchos los desafíos que deben enfrentarse para lograr datos de alta calidad de los sistemas fuentes. Esta etapa siempre termina abarcando más tiempo del previsto, sobre todo lo que refiere a la transformación de datos. Algunos ítems que ayudarán a guiar esta etapa del BDL [Kim1998]. Plan: Crear un diagrama de flujo fuentedestino esquemático de muy alto nivel. Probar, elegir e implementar una herramienta de limpieza de datos. Se pueden utilizar algunas de las que existen en el mercado para facilitar estas tareas y lograr una mejor documentación que sea útil para futuras modificaciones22. Profundizar en detalle por tabla destino. Describir gráficamente las reestructuraciones o transformaciones complejas. Ilustrar la generación de las nuevas claves sustitutas23. Y realizar un desarrollo preliminar de la secuencialidad de los trabajos. Carga de dimensiones: Construir y probar la carga de una tabla dimensional estática. La principal meta de este paso es resolver los problemas de infraestructura que pudieran surgir (conectividad, transferencia, seguridad, etc.) Construir y probar los procesos de actualización de una dimensión. Construir y probar las cargas de las restantes dimensiones. Tablas de Hechos y automatizaciones: Construir y probar la carga histórica de las tablas de hechos (carga masiva de datos de nivel atómico, sólo de tablas base). Esta tarea incluye la búsqueda y sustitución de claves. Construir y probar los procesos de cargas incrementales. Construir y probar la generación de agregaciones y/o de cubos MOLAP Diseñar, construir y probar la automatización de los procesos. En [Kim2004] se encuentra un detalle de las técnicas y consideraciones a tener en cuenta en la extracción, transformación y carga de los datos que formarán parte de las tablas de dimensiones y de las tablas de hechos. Especificación de Aplicaciones para Usuarios Finales Las aplicaciones proveen el mecanismo clave para fortalecer la relación entre el equipo del proyecto y la comunidad usuaria. Sirven para presentar el DW a los usuarios y para acercar a los desarrolladores de aplicaciones las necesidades del negocio. Estas aplicaciones ayudan a 22 Existen herramientas de ETL en software libre, por ejemplo Pentaho. Este concepto se describe más adelante. Refiere a nuevas claves, diferentes a las de los sistemas operacionales, otorgadas a los elementos de las dimensiones

46 Capítulo 3 El proceso de creación de modelos analíticos mostrar el valor del DW rápidamente, a facilitar el acceso de la mayoría de la comunidad usuaria y, a través de los ejemplos, colaboran con los usuarios avanzados a construir reportes más complejos. No todos los usuarios del DW necesitan el mismo nivel de análisis. En esta etapa se identifican los diferentes roles o perfiles de usuarios. En base al alcance de los diferentes perfiles (gerencial, analista del negocio, vendedor, etc.) se determinan los distintos tipos de aplicaciones necesarias. Existen usuarios con un perfil más estratégico, menos predecibles (power users), usuarios netamente operacionales que consumen una serie de reportes estándares (final users), usuarios gerenciales con uso de interfaces básicas (EIS users), entre otros. Mientras que algunos usuarios aprovecharán al máximo las facilidades de análisis ad hoc, otros necesitarán aplicaciones analíticas parametrizadas, más limitadas. En general se requiere de la creación de aplicaciones estándar parametrizables. Estas aplicaciones tipo plantilla para usuarios finales proveen el marco y la estructura de un reporte para ser especializado por un conjunto de parámetros. El usuario selecciona los parámetros de una lista o acepta los valores por defecto cuando ejecuta el modelo para crear sus propias versiones personalizadas de ese reporte, con diferentes niveles de análisis y filtros de la información (por ejemplo visualizar por mes en lugar de por trimestre, o elegir una determinada sucursal). Las variantes de los reportes las resuelven los propios usuarios sin la necesidad de la intervención del departamento sistemas y maximizando el tiempo de análisis por sobre el tiempo de construcción e integración de la información. Este enfoque orientado a parámetros permite a los usuarios generar docenas o potencialmente cientos de reportes de estructura similar. Todo esto de forma amigable y con interfaces gráficas. Es recomendable comenzar con la especificación de las aplicaciones tan pronto como se finalice el relevamiento de requerimientos, cuando se tienen bien presentes las necesidades de los usuarios, y documentar explícitamente. Algunas consideraciones para llevar adelante esta tarea [Kim1998]: Determinación del conjunto de patrones iniciales (identificar reportes candidatos, clasificarlos y priorizarlos) Diseño de la estrategia de navegación dentro de la aplicación (esquema de pantallas, esquema de carpetas o directorios, criterios de agrupamiento por datos, por dueño, por regla del negocio, etc.) Determinación de estándares (nombre y ubicación de los objetos, formato de las salidas) Detalle de las especificaciones (definición del nombre, descripción o propósito, frecuencia, parámetros, restricciones, diseño, etc.) 46

47 Capítulo 3 El proceso de creación de modelos analíticos Desarrollo de Aplicaciones para Usuarios Finales Esta etapa sigue a la especificación de las aplicaciones para usuarios finales El proceso de desarrollo es bastante estándar excepto que se basa en la herramienta de acceso a datos que se haya elegido. A lo largo del desarrollo es importante focalizar en los estándares de las aplicaciones (convenciones de nombre, cálculos, librerías y codificación). Esta etapa debiera comenzar una vez que existen datos en el DW (aunque no sean más que datos de prueba), es decir pronto a finalizados el diseño lógico y el físico. El motivo es que al desarrollar las aplicaciones pueden descubrirse problemas en la calidad de datos que no habían surgido en la primera etapa del ETL y que obliguen a realizar modificaciones. También es el momento de revisar las estrategias de optimización de performance probando los tiempos de respuestas de las consultas. En [Kim98] se establecen las siguientes tareas como parte del proceso de desarrollo de las aplicaciones: Selección de un enfoque de implementación. Decidir si la interfaz será web, o el acceso será basado en herramientas de acceso directo, en interfaces ejecutivas, en interfaces personalizadas, etc. Desarrollo de la aplicación. Definición de la herramienta de acceso a la meta data, desarrollo de moldes y esquema de navegación de la aplicación, selección de reportes que serán preejecutados, etc. Prueba y verificación de datos. Testeo y verificación de descripciones, información duplicada, relaciones entre atributos, consistencia e integridad de datos con sistemas fuentes. Documentación y salida a producción. Retroalimentación con los resultados de la puesta en producción Mantenimiento y monitoreo de performance. Puesta en producción La tecnología, los datos y las aplicaciones de usuarios finales convergen en esta etapa de implementación. Desafortunadamente esta convergencia no sucede naturalmente y requiere ser planificada. Es muy importante que no se realice la implementación del DW hasta que los datos no estén listos para ser mostrados. De todas formas no se necesitan sólo datos de buena calidad, sino que hay varios factores extras que aseguran una correcta implementación del proyecto. Entre estos factores se encuentran: la capacitación a los usuarios, el soporte técnico, la comunicación y las estrategias de feedback. Todas estas tareas deben ser tenidas en cuenta antes de que cualquier usuario pueda tener acceso al DW. 47

48 Capítulo 3 El proceso de creación de modelos analíticos La educación de los usuarios es uno de los pilares fundamentales de esta etapa y es un requisito para el éxito del proyecto. Para cumplir exitosamente con esta tarea se recomienda que el alcance de la capacitación contemple tres aspectos claves: el contenido del DW (los datos), las aplicaciones y las herramientas de acceso. No debe realizarse sólo sobre las herramientas de acceso. La educación sobre las herramientas es inútil al menos que se complemente con conocimientos sobre el contenido del DW (cuáles datos están disponibles, qué significan, cómo se usan y para qué usarlos). También es importante la metodología de presentación. Para los usuarios finales no es fácil entender los límites entre las aplicaciones, los contenidos y las herramientas. Para ellos el DW es un todo, por lo tanto la educación también debe reflejar la misma perspectiva. Otro factor clave es la correcta capacitación por niveles según el perfil del usuario (usuario final, power user, etc.). El armado de un ambiente de capacitación es siempre recomendable. Dos buenas premisas para el éxito del proyecto en esta etapa final del ciclo de vida: capacitar a los usuarios finales sólo si el DW está listo y establecer la política de que si el usuario no recibió capacitación no puede acceder a él. El soporte técnico es la otra columna que ayudará a implementar con éxito el proyecto. Se deberá definir claramente los niveles de soporte (a nivel aplicación, modelo, calidad de datos) de forma transparente para el usuario. La documentación juega un papel importantísimo en la ayuda a usuarios finales.. Respecto a la metodología de implementación es bueno seguir un esquema de versionado. Primero se pasa por la versión Alpha, donde el grupo de trabajo conduce por primera vez una prueba completa del sistema. Todos los componentes del sistema deben ser testeados (infraestructura técnica, extracción, transformación, carga, procedimientos de calidad, performance, moldes, etc.). Típicamente es de naturaleza iterativa y sólo puede decirse que se termina esta versión cuando el grupo de trabajo confía plenamente en la calidad del DW como un todo. Durante la etapa Alpha solo se provee acceso a un conjunto limitado de usuarios finales, aquellos que pertenecen al grupo de trabajo. Luego viene la versión Beta. El objetivo de esta versión es conducir una prueba a nivel usuario de principio a fin. El grupo Beta está formado por los power users24. La cantidad de personas que accederán al DW en esta instancia debe ser suficiente para asegurar que la aplicación se probará adecuadamente. Una vez superadas estas dos versiones se llega a un estado de disponibilidad general. Toda modificación posterior debiera pasar internamente por un estado Alpha y Beta aunque externamente sea una nueva versión. Finalmente, la tecnología que reside en el escritorio del usuario es la última pieza que debe ser ubicada antes de la salida a producción. Para asegurar que la infraestructura 24 Los power users son los usuarios que explotarán al máximo las capacidades del DW, haciendo uso de análisis ad hoc. 48

49 Capítulo 3 El proceso de creación de modelos analíticos correspondiente al ambiente del usuario esté correcta y el producto entregado sea de calidad debieran realizarse una serie de tareas antes de la implementación. Estas tareas incluyen: configuración del hardware, conexión a las bases, acceso a intranet o internet, asignación de direcciones de red, auditorias de tecnología sobre las configuraciones de las computadoras de los puestos de trabajo, previsión de actualizaciones de hardware y software (determinación de responsables, proyecto o área de usuario), verificaciones de seguridad (para acceder a la red y a la base de datos), pruebas de procedimientos de instalación en una variedad de máquinas, planificación de instalación, etc. Mantenimiento y crecimiento El desarrollo de un DW es un proceso de etapas bien definidas, con comienzo y fin, pero de naturaleza espiral, pues acompaña a la evolución de la organización durante toda su historia. Se necesita continuar con los relevamientos de forma constante para poder seguir la evolución de las metas por conseguir. Al contrario de los sistemas tradicionales, los cambios en el desarrollo deben ser vistos como signos de éxito y no de falla, porque a medida que los usuarios del negocio utilizan el DW van requiriendo nuevos análisis. Una vez que se ha construido e implementado el DW, rápidamente se debe estar preparado para administrar el mantenimiento y crecimiento del mismo. Si bien las tareas pueden llegar a parecer similares a las tratadas en otras etapas del BDL, existe una diferencia clave: los usuarios están ahora accediendo al DW. Algunas consideraciones a tener en cuenta para mantener exitosamente al DW: el continuo soporte y la constante capacitación a usuarios del negocio, el manejo de la infraestructura (monitoreo de base de datos, tráfico, etc.), ajustes de performance de las consultas, mantenimiento del meta data y procesos ETLs. Otros aspectos involucran el monitoreo regular del cumplimiento de las expectativas (variables de medición del éxito del proyecto que se habían fijado en la etapa de relevamiento), relevamiento de casos de estudio (situaciones reales donde una decisión basada en información del DW tuvo impacto sobre el negocio), constante publicidad interna del uso (permitiendo acceso siempre y cuando se tenga la capacitación correspondiente) y constante comunicación con los sectores del negocio y de sistemas para asegurar la buena salud del DW [Mst2005]. En cuanto al crecimiento del DW, un buen diseño está preparado para evolucionar y crecer controladamente. Iterar sobre el BDL pasando nuevamente por cada una de las etapas para administrar correctamente los cambios a incorporar. Es importante establecer las prioridades para poder manejar los nuevos requerimientos de los usuarios. Es recomendable la creación de un comité conformado por analistas del negocio y personas del área de sistemas que establezca prioridades y procedimientos. El manejo de prioridades discrimina errores (los cuales deben ser resueltos inmediatamente), y mejoras menores o mayores (clasificadas según el impacto en el DW). Como mejoras menores incluye la incorporación de datos sencillos, nuevas agregaciones, cambios en niveles superiores del modelo (atributos de alto nivel, lejanos a las tablas base). 49

50 Capítulo 3 El proceso de creación de modelos analíticos Dentro de las mejoras de mayor impacto se encuentran las que modifican o crean tablas bases o atributos asociados a estas [Mst2005]. Gerenciamiento del Proyecto El gerenciamiento del proyecto es trasversal a todo el ciclo de vida y asegura que las actividades del BDL se lleven en tiempo y forma y de manera sincronizada. Como se indica en el diagrama, el gerenciamiento acompaña todo el ciclo de vida. Entre sus actividades principales se encuentran: la conducción del equipo de trabajo, el monitoreo del estado del proyecto, el mantenimiento del plan y documentación, el manejo del alcance, y la comunicación entre los requerimientos del negocio y las restricciones de los datos para poder manejar correctamente las expectativas. 3.3 Técnicas para el modelado dimensional. En [Kim1992] [Kim2002] se presentan temáticas de análisis típicas mediante las cuales se ejemplifican cuestiones de diseño, algunas comunes y sencillas, otras más específicas y complejas. No es intención de esta tesis abordar estas cuestiones detalladamente, sino presentar las líneas generales más importantes. Varias de las técnicas se ejemplifican luego durante el desarrollo del caso de estudio, donde también se resaltan las particularidades de la temática elegida. Tal como se mencionó previamente, el diseño de un esquema multidimensional consiste básicamente de cuatro pasos: Seleccionar el proceso del negocio o asunto a modelar o Data Mart. Un proceso es una actividad realizada en la organización y generalmente soportada por un sistema fuente. Los procesos del negocio deben modelarse una única vez. No se deben duplicar datos modelando una misma actividad según la perspectiva de análisis de los diferentes departamentos de una organización. Al presentar esta etapa de modelado dimensional dentro del BDL, se dijo que el diseño de un DW comienza con la construcción de una matriz (DW Bus Architecture Matrix) donde se establecen las relaciones entre indicadores (pertenecientes a algún Data Mart) y dimensiones. Este primer paso consiste en elegir qué renglón o renglones de esa matriz van a modelarse. Dentro de la matriz, los diferentes Data Marts pueden solaparse. La cantidad de Data Marts para una organización grande varía entre 10 y 30. Menos de 10 podría significar que quedó muy amplia la definición de cada uno de ellos. Más de 30 o 40 es difícil de mantener, por eso es recomendable juntar los que puedan unirse. 50

51 Capítulo 3 El proceso de creación de modelos analíticos Manifestar la granularidad del proceso del negocio. Declarar la granularidad significa especificar exactamente qué representa cada fila de una tabla de hechos, manifestando el nivel de detalle asociado con las medidas que contiene. Este paso es crítico. Declarar la granularidad inapropiadamente puede atormentar la implementación de un DW y limitará el nivel de análisis. Cargar las tablas de hechos con datos atómicos (el mayor nivel de granularidad posible) brinda la mayor flexibilidad porque permite sumarizar los datos de todas las maneras posibles. En cambio, si la tabla de hechos contiene información agregada algunas sumarizaciones pueden no ser válidas (por ejemplo datos promediados). Elegir las dimensiones que aplican a cada registro de la tabla de hechos. Las dimensiones surgen de la forma en que se describe el proceso del negocio. Estas serán fácilmente identificadas si la granularidad está clara. Al elegir cada dimensión se listan todos los atributos que proveerán el detalle de cada tabla de dimensión. Ejemplos de uso común son fecha, producto, cliente, tipo de transacción, etc. Identificar las medidas para cada tabla de hechos. Las medidas se determinan a partir de las métricas de rendimiento del proceso del negocio seleccionado. Todas las medidas de una tabla de hechos deben tener la misma granularidad. Si la granularidad de alguna es diferente (porque no está definida para alguna dimensión, o lo está pero a otro nivel de detalle) esa métrica debe ser modelada en una tabla de hechos separada. Las medidas típicas son numéricas y aditivas, como cantidades o importes. El entendimiento del negocio será necesario para definir las dimensiones y medidas del modelo dimensional. Claramente deben considerarse tanto los requerimientos de los usuarios como la realidad de los datos fuentes al tomar decisiones sobre los cuatro pasos descriptos. Como cualquier técnica de modelado de datos, el desarrollo del modelo dimensional es un proceso iterativo. Se deberá estar dispuesto a cambiar el modelo a medida que se aprende más (de los requerimientos y de los datos). A medida que se avanza en el diseño, pueden identificarse dimensiones nuevas, o descubrir que dos de ellas son sólo una. También es común realizar cambios en la granularidad. Elección del Data Mart La metodología BDL propone comenzar por la construcción de un Data Mart.. La elección del Data Mart a modelar en el más simple de los casos es elegir la fuente de donde se tomarán los datos. Es recomendable elegir al principio uno que tenga una única fuente de datos en lugar de múltiples para evitar los riesgos de afrontar tareas de extracción más complejas. Se recomienda implementar los Data Marts en forma separada sólo en el contexto de dimensiones y hechos acordados (conforme al DW Bus). A medida que se obtienen los diferentes Data Marts estos deben poder ser ensamblados perfectamente como parte de un todo. Una de las 51

52 Capítulo 3 El proceso de creación de modelos analíticos responsabilidades mayores del equipo de diseño central del DW es establecer, publicar, mantener e imponer las dimensiones acordadas. Las dimensiones acordadas naturalmente serán definidas en el mayor nivel de granularidad posible. También se recomienda que tengan una clave anónima (subrogada) en el DW, diferente a las claves de los sistemas operacionales. Una de las razones de tener una nueva clave es para poder manejar los cambios que podrían sufrir los valores de los atributos de las dimensiones. La creación de las dimensiones acordadas es más una decisión política que técnica, por lo tanto los ejecutivos de alto nivel deben alimentar su uso. Las definiciones de los hechos (medidas) deben ser acordadas cuando se usa la misma terminología a través de los Data Marts y cuando se construyen reportes con información proveniente de más de uno de ellos. Si dos medidas reciben el mismo nombre deben significar lo mismo. En el caso de las medidas calculadas la ecuación de cálculo debe ser equivalente. Las medidas acordadas necesitan estar definidas en el mismo contexto dimensional y con la misma unidad de medición para todos los Data Marts. A veces la unidad de medición de una métrica difiere naturalmente entre las diferentes tablas de hechos. Por ejemplo el flujo de productos en un negocio puede medirse en cantidad de unidades vendidas en el sector de ventas, y en cantidad de pedidos enviados en el sector de envíos. En algunos casos se utiliza un factor de conversión, pero en este ejemplo no sería apropiado, y es conveniente modelarlas como medidas diferentes. Si es difícil o imposible acordar una medida entonces hay que asegurarse de darle nombres diferentes a cada interpretación. Luego de haber implementado varios Data Marts de una sola fuente es razonable combinarlos en uno de múltiples fuentes. El ejemplo clásico es el Data Mart para análisis de rentabilidad que combina los componentes separados de ingresos y costos. Tablas de Hechos y Granularidad Declarar la granularidad es un paso crucial en el diseño. Se recomienda elegir el nivel más bajo de granularidad posible para lograr un diseño más robusto. Esto significa construir las tablas de hechos básicas al nivel naturalmente más bajo de todas las dimensiones que las constituyen. Un nivel muy bajo de granularidad es poderoso y flexible, es mucho mejor para responder nuevas consultas inesperadas y para introducir elementos de datos nuevos. También el nivel más bajo de granularidad es el que tiene el dato de la forma dimensional más natural (por ejemplo del ticket de un cajero automático pueden identificarse las dimensiones tiempo, localidad, cuenta y tipo de transacción). Es en el nivel más bajo donde la mayoría de los atributos de las dimensiones tienen un único valor por registro. Por otro lado, trabajar con el nivel de datos más desagregado en el DW servirá para hacer análisis de data mining y de comportamientos de clientes. Los tres tipos de granularidad de tablas de hechos más útiles son: transacciones individuales, fotografías (snapshots) periódicas (diarias, mensuales, etc.) y fotografías 52

53 Capítulo 3 El proceso de creación de modelos analíticos acumulativas (accumulating snapshop). Cada uno de estos tipos de tablas tiene características particulares que se desarrollan a continuación. Granularidad a nivel de transacción La visión operacional del negocio más importante es a nivel de transacciones individuales. El caso más sencillo de este esquema consiste en crear un registro en la tabla de hechos por cada transacción individual (por ejemplo por cada operación de un cajero automático). Frecuentemente cada registro contiene una única medida, que es el valor de la transacción. En muchos casos se la llama importe (monto, o cantidad). El diseño de un esquema de transacciones es más acotado en cuanto al crecimiento que el de un esquema de fotografías. Se representan eventos que ocurren en un determinado momento de tiempo, y una vez ocurrida la transacción se incorpora al DW y no se vuelve a visitar a ese registro (no se lo modifica). Casi nunca se agregan medidas numéricas porque el sistema de captura de transacciones usualmente sólo retorna un importe. Se pueden agregar nuevos tipos de transacciones a la dimensión pero esto significa agregar datos no cambiar el esquema de la tabla. El nivel de granularidad no necesariamente es el nivel de la transacción en sí, en algunos casos se puede llegar a nivel de línea de ítem. Por ejemplo, para representar ventas mucha información está en el encabezado de la factura (fecha, cliente, sucursal, etc.) que sería la transacción, pero hay un nivel más detallado, el de línea de factura, que contiene el dato del ítem. Para cada ítem existen las medidas cantidad de unidades e importe. Al tener granularidad transaccional en el DW se permite analizar comportamientos al nivel de detalle extremo. Esto no es posible si lo datos están agregados. Este nivel de información permite realizar conteos de comportamiento (como por ejemplo cantidad de transacciones por cliente), análisis de rangos horarios, encolamientos, tiempos entre transacciones, etc. El detalle de las transacciones permite ver el comportamiento secuencial que se aplica para detección de fraudes y advertencia de cancelaciones. Finalmente permite realizar análisis de canasta que consiste en identificar asociaciones de elementos, por ejemplo productos que se venden junto con uno determinado. Muchos de estos ejemplos son análisis típicos de data mining, que requieren tener los datos en su máximo nivel de detalle. La granularidad de nivel de transacción sin embargo no es la más apropiada para otro tipo de análisis, como tener una vista del estado actual del negocio. Por ejemplo si se quiere saber los ingresos no siempre es posible hacerlo sumando las transacciones, porque diferentes tipos de transacciones impactan de formas distintas en este cálculo. Esquema de fotografías Fotografías periódicas son necesarias para ver el rendimiento acumulado del negocio a intervalos de tiempo regulares y predecibles. En lugar de cargar una fila en la tabla de hechos por cada evento que ocurre, se espera hasta el final del día, o del mes, y se captura la actividad que 53

54 Capítulo 3 El proceso de creación de modelos analíticos ocurrió durante ese período. Se dice que se toma una foto de lo ocurrido. Las fotografías tomadas en cada período se van guardando en la tabla de hechos. Este esquema de fotografías es más complejo que la perspectiva de transacciones individuales. Pueden existir varias medidas de la actividad ocurrida durante el período capturado, por ejemplo importe total de ventas, cantidad total de transacciones, cantidad de clientes que realizaron alguna compra en el período, etc. Es importante que todas las medidas se refieran al período corriente. Algunas medidas serán completamente aditivas y otras serán semiaditivas, como el balance de cuentas al momento que se toma la fotografía. Estos casos podrán ser promediados a través del tiempo o tener algún otro método especial de agregación. En algunos casos, como el de ventas por menor, es sencillo pasar de la perspectiva de transacciones individuales a la foto diaria agrupando las transacciones a nivel de día.. Otras veces el patrón de transacciones es muy complejo y la construcción de fotografías no es una simple agregación. Por ejemplo en una contabilidad mensual el cálculo de las ganancias depende de cómo contabiliza cada tipo de transacción (depósitos, pagos por adelantado, etc.). Las fotos mensuales son requeridas en estos casos para obtener la información a ese nivel en forma rápida. La granularidad a nivel de transacciones posibilita la vista total del comportamiento detallado y a nivel de fotografías permite medir rápidamente el estado de la empresa u organización. En muchos casos se necesitan ambas para lograr una vista completa e inmediata del negocio. Fotografías acumulativas Las fotografías acumulativas (o acumuladas) representan un lapso de tiempo indeterminado para cubrir la vida entera de una transacción o de un producto completo. Este esquema es generalmente usado para seguimiento del estado de un ítem cuando atraviesa un proceso en cadena, por ejemplo seguimiento de una orden de pedido. Este diseño sirve para saber el estado actual de una orden y la velocidad en que un producto va superando las diferentes etapas del proceso y permite identificar cuellos de botella e ineficiencias en la cadena del proceso (de producción, de ventas y entregas, etc.). La granularidad de estas tablas de hechos suele ser de un registro por cada línea de ítem de un documento de control. Cada registro puede ser pensado como fotografías evolutivas de esa línea de ítem que se van actualizando. Estas tablas de hechos tienen típicamente múltiples fechas representando hitos en las fases por las que atraviesa la línea de ítem (por ejemplo fecha de la orden de pedido, fecha de entrada a fabricación, fecha de fin de fabricación, fecha de envío a sucursal, fecha de facturación, fecha de recepción del cliente, entre otras). También pueden existir diferentes medidas asociadas a cada etapa. Generalmente se necesita una dimensión de estado para guardar el valor actual de cada ítem. En estas tablas cada registro se actualizará frecuentemente cuando se tenga nueva 54

55 Capítulo 3 El proceso de creación de modelos analíticos información disponible, para reflejar el estado y las métricas acumuladas. Esta es la diferencia fundamental con los otros tipos de tablas. A veces las fotos acumulativas se usan en conjunto con las fotos periódicas. Se puede pensar en un DW que guarde fotos periódicas por mes y que lleve una fotografía acumulativa para la información del mes en curso. En estos casos cuando finaliza el último día del mes la fotografía acumulada pasa a ser una más de las fotos periódicas y se crea una nueva foto acumulativa para registrar la actividad del nuevo mes a partir del día siguiente. La fotografía mensual se construye de forma incremental, agregando el efecto de las transacciones diarias a una fotografía acumulativa. Comparación de los esquemas En la siguiente figura se presenta un cuadro comparativo [Kim2002] respecto a estos tres tipos de granularidad donde destaca las características más distintivas. Característica Granularidad transaccional Punto en el tiempo Granularidad de fotografías periódicas Intervalos regulares y predecibles Granularidad Una fila por evento transaccional Una fila por período Tipo de cargas en tablas de hechos Actualizaciones en tablas de hechos Dimensión fecha Inserciones Inserciones No No Fecha de la transacción Fecha del fin del período Métricas Actividad transaccional Rendimiento para intervalos de tiempo predefinidos Período de tiempo representado Granularidad de fotografías acumulativas. Lapso de tiempo indeterminado, típicamente de corta vida Una fila por vida (al nivel de detalle que se haga el seguimiento) Inserciones y actualizaciones Se actualiza el registro cuando hay actividad. Múltiples fechas para hitos estándares Rendimiento sobre el tiempo de vida finito Figura 10. Comparación de tipos de tablas de hechos. Los tres tipos de granularidades vistos son útiles para diferentes propósitos. La administración y ritmos de carga difieren bastante entre los tres tipos de tablas. Generalmente será necesario tener dos tipos de tablas de hechos complementarios para lograr una imagen completa del negocio. Estas tablas compartirán dimensiones acordadas, para poder ser usadas en conjunto. Familias de tablas de hechos Para modelar muchos de los procesos del negocio es necesario considerar más de una tabla de hechos. Un Data Mart puede constituirse como un conjunto coordinado de tablas de hechos, todas con estructuras similares, no necesariamente de tipos diferentes, y sí con dimensiones y medidas acordadas. Hay diferentes razones para crear estas familias de tablas de hechos [Kim1998]: 55

56 Capítulo 3 El proceso de creación de modelos analíticos Los casos ya mencionados de contar con tablas de diferente granularidad; por ejemplo transaccional y de fotografías para poder realizar análisis detallado y a la vez tener una vista del negocio rápida. La construcción de tablas con información agregada para resolver problemas de performance. Modelar cadenas y círculos. El caso de cadenas es cuando dentro del negocio existe un flujo que involucra que una orden, producto, o cliente atraviese diferentes pasos. En general tiene sentido construir una tabla de hechos separada para cada uno de los procesos. Las tablas de cada paso pueden ser transaccionales o de fotografías periódicas, y estarán relacionadas por las dimensiones y medidas comunes. Se habla de cadenas cuando los subprocesos o etapas están naturalmente ordenados. El caso de los círculos es cuando varias entidades están realizando o midiendo el mismo tipo de transacciones. Un buen ejemplo es la gran organización de cuidado de la salud, donde hospitales, farmacias, laboratorios, clínicas, compañías de seguro y otras entidades rondan alrededor de los tratamientos de los pacientes. Esquemas de productos heterogéneos. Este es el caso de negocios que manejan productos lo suficientemente diferentes que dadas las características propias del tipo de producto deban ser modeladas en forma separada, porque existan muchas dimensiones que no son comunes. Seguramente también se incluya en el modelo una tabla base núcleo que cruce todas las líneas del negocio para tener un análisis global por las dimensiones comunes. Un ejemplo puede ser una empresa que ofrezca productos y también servicios. Tablas de hechos sin medidas Hay un tipo especial de tablas de hechos denominada factless fact tables por tener la característica de no incluir medidas entre sus campos. Hay dos situaciones donde las tablas con esta característica son muy útiles: para seguimiento de eventos y de cobertura. Para el primer caso en la tabla de hechos se registra un evento por línea. Ejemplos típicos de uso son el registro de asistencias y las inscripciones a cursos. Si se piensa en alumnos universitarios inscribiéndose a materias la granularidad de la tabla será de una fila por cada inscripción de un alumno a una materia en un período académico. El período será el nivel más bajo disponible para la registración de eventos. Esta dimensión debe estar de acuerdo con la dimensión de fechas. Este tipo de tablas, compuestas sólo por claves de dimensiones es perfectamente una tabla de hechos25 y es útil para responder preguntas como qué materias tienen mayor cantidad de 25 La existencia de las factless fact tables ha motivado la nomenclatura utilizada en este texto. Nótese la referencia a fact table como tabla de hechos, considerando hecho como suceso o evento en lugar de utilizarlo como sinónimo de medida o métrica al hacer mención a la tabla. 56

57 Capítulo 3 El proceso de creación de modelos analíticos inscripciones, cuál es la cantidad de inscripciones promedio por alumno y período, qué docentes tendrán mayor cantidad de alumnos, cuál es el medio de inscripción más utilizado, etc. Al analizar esta información pueden contarse dos cosas diferentes: por un lado la cantidad de inscripciones y por otro la cantidad de valores diferentes de una dimensión en alguna consulta. Por ejemplo: para un período determinado, se puede contar el total de inscripciones por carrera (asumiendo que cada materia pertenece sólo a una carrera), como también la cantidad de alumnos diferentes por carrera, sin importar en cuantas materias de la carrera se inscribe. El segundo tipo de tablas de hechos sin medidas se utiliza para garantizar cobertura. El mejor ejemplo es el caso de querer analizar las promociones de productos que están a la venta. Sería deseable saber qué productos estaban en promoción y no se vendieron. Agregar la información necesaria para este análisis en la tabla de ventas significaría la incorporación de muchísimos registros con ceros representando los eventos que no sucedieron (todos los productos que no se vendieron), lo que haría crecer enormemente el tamaño de la tabla. Es por eso que en estos casos, cuando la tabla de hechos primaria es rala26, suele utilizarse este esquema de cobertura. Se crea entonces una tabla donde se registran todas las promociones. La respuesta a los productos promocionados y no vendidos se resuelve en dos pasos, primero se consulta cuales estaban promocionados, y con ese resultado se busca en la tabla de ventas cuales no están durante la vigencia de la promoción. Otro ejemplo de cobertura puede ser el análisis de uso y disponibilidad de las instalaciones de una institución. Para cada instalación se podría considerar datos como el edificio, el tipo de instalación (aula, laboratorio, oficina), la capacidad, los servicios (pizarrón, proyector, computadoras) y registrar para cada bloque horario si la habitación se encuentra disponible o no. Diseño de las dimensiones Una vez seleccionado el Data Mart a modelar y habiendo establecido las granularidades correspondientes, el tercer paso del diseño multidimensional consiste en elegir las dimensiones que aplican a cada tabla de hechos. Diferentes características de las dimensiones deberán tenerse en cuenta al momento de diseñar el modelo del negocio. Descripción de los atributos Es vital que las descripciones de los atributos de las dimensiones sean de alta calidad: significativas, entendibles y prolijas. Estas serán mostradas en la interfaz con el usuario y usadas como filtros en las consultas. 26 Rala significa poco densa considerando las combinaciones de los valores de las dimensiones que contiene respecto a todas las posibles. 57

58 Capítulo 3 El proceso de creación de modelos analíticos Claves de las dimensiones Otra característica de diseño importante es que todas las dimensiones deben tener una clave. Las claves de las dimensiones deben ser un sólo campo, numérico y secuencial, y son el nexo entre las tablas de hechos y las dimensiones. Se destaca que no deben usarse las mismas claves que en los sistemas operacionales, sino que es necesario generar claves nuevas o sustitutas. Esquema estrella vs esquema copo de nieve Uno de los puntos más importantes a definir al modelar las dimensiones está relacionado en gran parte con la implementación física. Se trata de la normalización o no de las tablas de dimensión. Algunas dimensiones constan de un único atributo, pero otras constan de varios atributos que forman una jerarquía. Tal es el caso de la dimensión producto, donde se puede identificar la jerarquía: producto, línea, categoría y rubro, por ejemplo, y de la dimensión ubicación geográfica donde se identifican localidades, provincias y países, entre otros atributos. En estos casos la dimensión se puede representar en una única tabla, donde reside toda la información al nivel más bajo, o mediante un conjunto de tablas (a partir de las dependencias existentes entre los atributos) que respeten la tercera forma normal27. El primero de los casos corresponde a un esquema estrella (que consta de una tabla de hechos central y un montón de tablas de dimensiones satélites). Al normalizar las dimensiones se dice que se transforma al modelo estrella en un copo de nieve (también debido al gráfico de su estructura), y por eso a veces se hace referencia a esta acción como snowflaking. En la figura 11 se observa como podría ser la tabla de la dimensión Ubicación, con localidad_id como única clave modelada en ambas formas. Localidad_id Localidad_desc Provincia_id Provincia_desc Pais_id Pais_desc Pais_id Pais_desc Provincia_id Provincia_desc Pais_id Localidad_id Localidad_desc Provincia_id Figura 11. Dimensión Ubicación desnormalizada vs normalizada. 27 La tercera forma normal es una forma de normalización de bases de datos, definida por E.F.Codd. 58

59 Capítulo 3 El proceso de creación de modelos analíticos Es claro que la tabla desnormalizada contiene mucha redundancia de datos. También es claro que en el esquema normalizado se necesitará realizar varias uniones entre tablas para obtener la información del DW agrupada a niveles altos de la jerarquía. Entre un esquema y otro existe una solución intermedia, denominada moderadamente normalizada que es igual al normalizado a excepción que en todas las tablas se incluyen las claves de todos los niveles superiores. De esta manera la cantidad de joins se reduce, siendo a los sumo dos, para cualquier nivel de la jerarquía consultado. El esquema totalmente desnormalizado presenta algunas variantes. Puede contener: Una clave y una descripción genéricas para toda la dimensión, y las claves de los diferentes niveles. Esta opción es rara. Podría usarse para algún caso donde la descripción sea la misma, cualquiera sea el nivel de análisis que se consulte, o si el dato a mostrar se calcula a partir de esa descripción común. Una clave genérica para toda la dimensión y las descripciones de los diferentes niveles. Es válido si no existen tablas de hechos con nivel de granularidad diferente al nivel base de la dimensión. Una clave genérica para toda la dimensión y las claves y descripciones de los diferentes niveles. Este es el caso más común y el mostrado en la figura, sólo que para el ejemplo se toma como clave de la dimensión a la clave del nivel más bajo. Con este esquema totalmente desnormalizado hay que utilizar algún método de indexación eficiente para obtener el listado de valores de los diferentes niveles de la jerarquía, particularmente para resolver rápidamente los cruces con las tablas de hechos donde el nivel de granularidad no sea el base. Caso contrario sería necesario crear tablas adicionales para los distintos niveles y esto generará aún más redundancia de datos, como se puede observar en la figura 12. La discusión entre ambos esquemas surge de considerar el tamaño total de la base de datos (y el consecuente espacio necesario en disco, demoras para backups y otros procesos) y de las limitaciones tradicionales de las bases de datos para resolver las operaciones requeridas en un área de soporte de decisiones. Estas operaciones consisten en unir información de diferentes tablas, agregar o agrupar datos, ordenar datos y recorrer grandes volúmenes de datos. El desarrollo tecnológico a través de los años ha quitado presión al problema del tamaño del DW. Con respecto a las operaciones costosas en la base de datos pueden usarse técnicas para abordarlas: usar un modelo desnormalizado, usar tablas resumidas (evita tener que calcular agregaciones sobre tablas bases), guardar los datos ordenados (para evitar ordenamiento) y crear índices (para evitar recorrer tablas grandes). Todas estas opciones requieren que el diseñador conozca las consultas que serán realizadas frecuentemente para personalizar la base de datos focalizando en la performance de esos casos. 59

60 Capítulo 3 El proceso de creación de modelos analíticos Algunos argumentos a favor de la desnormalización, con una única tabla por dimensión y el uso de índices: Las tablas normalizadas hacen más compleja la presentación de los datos; y el modelo dimensional debe ser simple. Cuantas menos tablas haya más fácil será de entender. Muchas tablas y cruces normalmente perjudican los tiempos de respuestas y dificultan la generación (en SQL) de las consultas. El espacio en disco que se ahorra es mínimo respecto al tamaño de las tablas de hechos y no justifican el esfuerzo. La normalización perjudica la habilidad de navegar los datos dentro de una dimensión, particularmente cuando se consultan al mismo tiempo varios atributos. La normalización rechaza el uso de índices que es una técnica para lograr buena performance. Por el contrario, a favor de un DW normalizado y esquemas estrellas para Data Marts se exponen las siguientes razones: La cantidad de espacio es mínimo. En el modelo desnormalizado las tablas de dimensión son muy grandes. Es flexible y escalable en cuanto a cantidad de atributos dentro de cada dimensión, y cantidad de elementos (valores) dentro de cada atributo. Maneja naturalmente en forma óptima listas desplegables y tablas de hechos con diferente granularidad. El mantenimiento de las tablas de dimensión es más sencillo al no haber redundancia de datos. Soporta mejor los posibles cambios en los valores de los atributos de las dimensiones. Si una descripción cambia debe ser modificada sólo en un lugar en vez de en todos los registros de una tabla de dimensión desnormalizada. Es interesante observar como las diferencias entre las estructuras se hacen más visibles cuando la dimensión tiene muchos niveles, y también cuando hay tablas de hechos con diferentes granularidades (que podrían existir o no, y podrían corresponder a agregaciones28 o a otros hechos). A partir el ejemplo de la figura 11 se podrían obtener las variantes mostradas en las figuras 12, 13 y Consultar sobre la técnica de agregación al final de este capítulo. Las agregaciones tienen sentido cuando existen dimensiones con jerarquía. La razón principal de su creación es reducir la cantidad de registros de una tabla de hechos que son consultados y agrupados para armar una respuesta cuando se pregunta por niveles superiores al nivel base. Se crean tablas adicionales con datos ya resumidos para las consultan frecuentes. 60

61 Capítulo 3 El proceso de creación de modelos analíticos Dim Ubicación base Localidad_id Localidad_desc Depto_id Depto_desc Provincia_id Provincia_desc Pais_id Pais_desc Region_id Region_desc Tabla de hechos base (Dim Ubicación agreg 1) Localidad_id Provincia_id Provincia_desc Pais_id Pais_desc Region_id Region_desc Tabla de hechos nivel pcia Pcia_id (Dim Ubicación agreg 2) Pais_id Pais_desc Region_id Region_desc Tabla de hechos nivel pais Pais_id Figura 12. Esquema altamente desnormalizado para la dimensión Ubicación. Region_id Region_desc Tabla de hechos nivel pais Pais_id Pais_id Pais_desc Region_id Tabla de hechos nivel pcia Provincia_id Provincia_desc Pais_id Pcia_id Depto_id Depto_desc Pcia_id Tabla de hechos base Localidad_id Localidad_id Localidad_desc Depto_id Figura 13. Esquema altamente normalizado para la dimensión Ubicación. Region_id Region_desc Pais_id Pais_desc Region_id Tabla de hechos nivel pais base Pais_id Provincia_id Provincia_desc Pais_id Region_id Depto_id Depto_desc Pcia_id Pais_id Region_id Tabla de hechos nivel pcia Pcia_id Tabla de hechos base Localidad_id Localidad_id Localidad_desc Depto_id Provincia_id Pais_id Region_id Figura 14. Esquema moderadamente normalizado para la dimensión Ubicación. 61

62 Capítulo 3 El proceso de creación de modelos analíticos En el esquema altamente desnormalizado de la figura 12 las tablas adicionales para la dimensión (punteadas en el gráfico) podrían crearse pero esto produciría más redundancia aún; es preferible optar por una buena técnica de creación de índices en la tabla original para obtener en tiempos aceptables los valores distintos del atributo correspondiente al nivel que se consulte. En este esquema todas las consultas se resuelven mediante un join con la tabla de dimensión, realizando el agrupamiento de registros correspondiente al nivel de la jerarquía que se elija. En la figura 13 se puede observar como el esquema altamente normalizado soporta naturalmente las diferentes granularidades de las tablas de hechos. Por otro lado, de no existir tablas de agregación, resolver una consulta sobre la tabla base requiere muchos joins, a nivel de país por ejemplo serían cuatro. Respecto al esquema de la figura 14, las consultas a cualquier nivel de la dimensión se resuelven haciendo a lo sumo dos joins, existan o no tablas de agregación. La elección del esquema adecuado dependerá del caso, de algunos motivos ajenos como: el alcance total del proyecto, los recursos disponibles, las facilidades del motor de base de datos elegido; y de cuestiones propias del modelo como: la cantidad de niveles de las dimensiones, los niveles que sean consultados frecuentemente, y particularmente de la cantidad de registros que contengan la dimensiones. Por ejemplo: no es lo mismo si la tabla contiene la información de todas las localidades del mundo que si contiene información de 100 localidades correspondientes a 20 departamentos, de 2 provincias y del mismo país. En este caso los dos niveles superiores de la dimensión no se consultarán (probablemente ni siquiera se incluyan en el modelo) y las diferencias en los tiempos de respuesta no se notarán, cualquiera sean el esquema y la agregación que se utilicen. Sí es probable que se note la diferencia en la complejidad de la elaboración de consultas. Por último existe una opción totalmente extremista, en la que podría caerse por error al realizar los primeros diseños, que sería desnormalizar a nivel de la tabla de hechos, ingresando como campos de esta tabla a los atributos de la dimensión. Este caso sería un error de diseño porque se pierde el concepto de dimensión en sí. Además habría mucha redundancia de datos, ocuparía mucho espacio y exigiría alto grado de mantenimiento. En las figuras 15 y 16 se muestran dos posibilidades de cómo podría quedar el diseño en caso de implementar esta decisión. En la propuesta de la figura 15 se tratan los diferentes niveles de una dimensión como si fuesen dimensiones diferentes. Todas las consultas se resuelven con un solo join, pero se pierde la posibilidad de drill down que es la base de OLAP. Lo más destacable es la diferencia conceptual, debido a que se generan dimensiones separadas para representar una misma entidad. Esto dificulta el análisis. 62

63 Capítulo 3 El proceso de creación de modelos analíticos Tabla de hechos nivel pais Region_id Region_desc Pais_id Region_id Pais_id Pais_desc Tabla de hechos nivel pcia Pcia_id Pais_id Region_id Provincia_id Provincia_desc Tabla de hechos base Depto_id Depto_desc Localidad_id Depto_id Pcia_id Pais_id Region_id Localidad_id Localidad_desc Figura 15. Desnormalización de la dimensión Ubicación dentro de las tablas de hechos, considerando los niveles de la dimensión como dimensiones independientes. La variante de la figura 16 mantiene el concepto de dimensión y permite modelar a todos los atributos como parte de una jerarquía y hacer drill down. A la vez resolvería todas las consultas con un único join. Pero esta redundancia extrema deforma el modelo y dificulta la elaboración de las consultas. Si el volumen de información fuese grande ocuparía espacios enormes y con volumen chico no se necesita porque la supuesta mejora en la performance no sería evidente. Esta opción complica el entendimiento y mantenimiento del modelo y de los datos. Tabla de hechos base Region_id Region_desc Localidad_id Depto_id Pcia_id Pais_id Region_id Pais_id Pais_desc Region_id Provincia_id Provincia_desc Pais_id Tabla de hechos nivel pcia Pcia_id Pais_id Region_id Depto_id Depto_desc Pcia_id Tabla de hechos nivel pais Localidad_id Localidad_desc Depto_id Pais_id Region_id Figura 16. Desnormalización de la dimensión Ubicación dentro de las tablas de hechos, manteniendo la jerarquía de la dimensión. En general cada dimensión debe estar relacionada por una única clave a cada tabla de hechos, en el nivel de granularidad que corresponda. 63

64 Capítulo 3 El proceso de creación de modelos analíticos Subdimensiones y jerarquías múltiples dentro de una dimensión Hay casos que requieren especial atención respecto a la decisión a tomar sobre normalización. Se trata de las dimensiones que presentan subdimensiones y/o tienen múltiples jerarquías. Se dice que existe una subdimensión cuando dentro de una dimensión se puede identificar una entidad independiente que se relaciona con la principal. Por ejemplo, la ubicación del cliente. Si el cliente está asociado a una localidad, la ubicación geográfica del cliente puede verse como una subdimensión dependiente. No tendría sentido incluir todos los datos de la dimensión ubicación por cada registro que exista en la tabla de cliente. Cualquiera sea el esquema elegido para modelar la dimensión ubicación, dentro de la tabla de cliente sólo deberá incluirse la clave de la ubicación (localidad_id). Tener otros datos de ubicación a nivel de cliente ocuparía muchísimo espacio y dificultaría el mantenimiento de las localidades. Además la independencia de la tabla ubicación permite su reuso en otras dimensiones (como por ejemplo la ubicación de los proveedores). Las subdimensiones muchas veces suelen modelarse de manera separada, generalmente porque hay alguna otra forma de agrupar al nivel inferior de la dimensión de la cual depende a través de atributos de una jerarquía principal. Por ejemplo la dimensión cliente podría consistir de los niveles: tipo de cliente y cliente, y la subdimensión ubicación del cliente podría modelarse en forma separada bajo el nombre de destinos o mercados. Dependiendo de las facilidades de la herramienta que se elija para explotar la información, y en particular si soporta o no modelar más de una jerarquía dentro de las dimensiones, las subdimensiones se podrán visualizar como una jerarquía más o como una dimensión separada. Una situación similar ocurre cuando atributos de una dimensión se modelan como dimensiones separadas. Esto puede suceder cuando una dimensión tiene múltiples jerarquías. Por ejemplo para el caso de la dimensión producto se identifica la jerarquía principal: ítem, línea, categoría y rubro, y también los atributos marca y color. Si la herramienta elegida no permite manejo de múltiples jerarquías, será la principal la que se muestre dentro de la dimensión y las secundarias deberán modelarse como dimensiones separadas. En los cubos MOLAP cuando las subdimensiones y/o las jerarquías secundarias se modelan como dimensiones separadas es necesario incluir las claves de estas en la tabla de hechos. Esto no significa que hay que desnormalizar la tabla de hechos en el DW, puede hacerse directamente en la definición del cubo Observar en el caso práctico los ejemplos de subdimensiones, especialmente de procedencia del alumno, y otros atributos como sexo, edad, nacionalidad. Estos se modelan como dimensiones separadas a través de la definición de campos virtuales en lugar de incluir estos campos en las fuentes de datos. 64

65 Capítulo 3 El proceso de creación de modelos analíticos Dimensiones con valores variables Existen dimensiones completamente estáticas, con valores bien determinados. Tal vez nuevos valores sean agregados, pero los existentes en el DW jamás sufren modificaciones. También hay casos donde el elemento de la dimensión en sí no cambia (la clave en el sistema operacional es la misma) porque se refiere a la misma cosa, pero sí cambia la descripción o alguno de los atributos. Esto puede ocurrir por corrección de errores, o porque el dato sufre alguna modificación en el sistema fuente. A estos casos se los conoce como slowly changing dimension y hay tres opciones para manejarlos: Sobrescribir el registro de la dimensión con el valor nuevo. Esta opción se usa para correcciones de errores, y pierde la historia del elemento. Crear un nuevo registro en la dimensión para el nuevo valor. Es la solución recomendada para manejar los cambios en los atributos. Requiere el uso de claves sustitutas para el DW porque no puede tomarse la misma clave que existe en el sistema operacional. Crear un campo descripcion_anterior en el registro de dimensión para guardar el valor previo inmediato del atributo. Es para cambios no muy importantes, que no determinan una partición histórica. Aunque el valor cambió se puede hacer de cuenta que no se modificó. También existe la posibilidad de no actualizar nunca el valor, bajo ninguna circunstancia. En este caso el DW no reflejará los cambios que se realicen en los sistemas fuentes. El término slowly se utiliza porque generalmente los cambios en las dimensiones no se producen con mucha frecuencia. Sin embargo puede ocurrir que los cambios sean bastante frecuentes. Las técnicas a utilizar son las mismas, sólo que es probable que en estos casos sea más importante guardar la historia de los valores. Otros tipos de dimensiones que merecen especial atención, son los casos de las dimensiones grandes y las dimensiones degeneradas. Se dice que una dimensión es grande cuando contiene gran cantidad de elementos, por ejemplo personas. En muchos casos pueden soportarse bien, cuando se trabaja sobre bases de datos relacionales. Es apto para ambientes ROLAP o HOLAP, no MOLAP. Es necesario aplicar técnicas para mantenerlas controladas, sobre todo cuando cambian rápidamente. Las dimensiones degeneradas son dimensiones donde la descripción es la clave en el sistema operacional, por ejemplo un número de factura, o el número de inscripción. En estos casos los códigos no se regeneran sino que se toman los originales y se ponen en la tabla de hechos. La dimensión consiste sólo del código y por eso se dice que está degenerada (no tendrá tabla asociada). 65

66 Capítulo 3 El proceso de creación de modelos analíticos Definición de las medidas Una vez diseñado el Data Mart, la granularidad de las tablas de hechos y habiendo diseñado las dimensiones resta el último paso en la definición de cada modelo dimensional, que consiste en la definición de las medidas. A continuación se presentan los diferentes tipos de métricas que existen y algunas técnicas para manejarlas. Medidas aditivas, semiaditivas y no aditivas Una medida es aditiva si tiene sentido sumar sus valores a través de todas las posibles dimensiones. Siempre que sea posible deben incorporarse a las tablas de hechos medidas que sean perfectamente aditivas. Métricas de actividad, numéricas y discretas, como unidades o importe correspondientes a una venta, generalmente cumplen con esta característica. Sin embargo las medidas de intensidad, también numéricas, como balances de cuentas y niveles de inventario, no son perfectamente aditivas. En estos casos generalmente es posible sumar los valores a través de todas las dimensiones menos en el tiempo. Medidas de este tipo se pueden combinar a través del tiempo calculando lo que denomina timeaverage o promedio en el tiempo. Esta fórmula de cálculo está basada en el promedio de los hijos. En caso que existan tres niveles: año, mes y día, el valor en el mes será la suma de los valores en cada día del mes dividido la cantidad de días del mes, y el valor en el año será la suma de los valores en los meses dividido doce (o la cantidad de meses correspondiente al año en curso). Para el caso de las medidas no aditivas, como puede ser un valor promedio, o una temperatura, habrá que ver si puede definirse algún método de agregación que sea válido para todas las dimensiones. Otra alternativa es limitar el alcance de las consultas al nivel de granularidad en que está definido el dato. La mayoría de estos casos pueden surgir de no haber elegido bien la granularidad de la tabla de hechos. Los datos en el nivel de granularidad más bajo suelen ser aditivos. En raras ocasiones es posible que una medida sea textual en lugar de numérica. El diseñador deberá intentar modelar estos casos como dimensiones, y de llevar los textos libres a una lista de alternativas. Medidas con múltiples unidades Diferentes medidas de un negocio pueden ser la misma expresada en diferentes unidades de medición. Como ejemplos sencillos podrían considerarse: expresar distancia en metros, kilómetros, millas, leguas, o importe de una venta en pesos, en miles de pesos, en dólares, etc. En los negocios que involucran varios procesos encadenados en etapas y en los cuales se monitorea el flujo de los productos a través del sistema suelen presentarse casos un poco más complejos de conflictos con las medidas de cantidades. Esto es porque existen múltiples medidas en los diferentes puntos de la cadena, debido a que los números son expresados en diferentes 66

67 Capítulo 3 El proceso de creación de modelos analíticos unidades de medición. Por ejemplo, en los distintos sectores pueden contarse: unidades de envío (paquetes y cajas que se trasladan del depósito a la sucursal), unidades vendidas, unidades escaneadas (paquetes de venta), unidades consumibles (contenido individual de los paquetes), etc. De forma similar la cantidad de un producto puede tener varias valuaciones económicas posibles, en términos de valor de inventario, precio de lista, precio de venta original, precio de venta final. Esta situación puede ser agravada si además se tienen muchas métricas diferentes. En estos casos no es correcto incluir en la tabla de hechos sólo a las medidas fundamentales, porque se perdería parte del análisis. Tampoco es correcto incluir a todas las posibles combinaciones de medidas fundamentales expresadas en las diferentes unidades de medida y por cada factor de valuación posible (porque la tabla sería gigante). La solución consiste en identificar a las medidas fundamentales, los factores de conversión y los factores de valuación, e incorporar todos esos valores a la tabla de hechos. De esta forma es posible obtener cualquier medida final que se desee a partir de la combinación correspondiente. A veces se cae en la tentación de incluir los factores de conversión en alguna tabla de dimensión (por ejemplo: contenido individual, cantidad de unidades por paquete de venta, y cantidad de paquetes por caja de envíos, podrían incluirse en la tabla de productos). En general esto no se recomienda porque los factores de conversión suelen variar, lo que obligaría a generar nuevos registros en la tabla de dimensión para mantener los cambios. Estos factores, especialmente los asociados a costos y precios, suelen evolucionar en el tiempo y se asemejan mucho más a medidas que a atributos de dimensión. Empaquetar todas las medidas y todos los factores de conversión juntos en el mismo registro de la tabla de hechos es la manera más segura de garantizar que esos factores serán usados correctamente. Medidas básicas y derivadas Existe una clasificación importante entre las medidas básicas, que existen naturalmente a partir de un evento, y las que se calculan en función de una o más de ellas, denominadas medidas derivadas. Se dice que una medida es básica o base cuando corresponde a una columna de una fuente de datos. Ejemplos suelen ser cantidades e importes. Una medida es derivada si necesita ser calculada, como por ejemplo el importe de ventas acumulado a la fecha, la rentabilidad, la diferencia entre la cantidad de ingresantes del año actual con respecto al mismo valor el año anterior, la tasa de egresados sobre ingresantes, etc. Hay dos tipos de medidas derivadas: 67

68 Capítulo 3 El proceso de creación de modelos analíticos Las aditivas30. Estas pueden ser calculadas enteramente a partir de las otras medidas existentes en el mismo registro de la tabla de hechos. Por ejemplo el caso de múltiples unidades de una medida presentado anteriormente, el cálculo de ganancia (como diferencia entre ventas y costos), etc. Estos casos suelen resolverse mediante vistas que se presentarán a los usuarios. Los cálculos no aditivos, como porcentajes (ratios) o medidas acumulativas expresadas en tablas agregadas. Estos casos muchas veces requieren ser calculados al momento que se consultan por la herramienta de consultas o por quien escribe el reporte. A veces es preferible incluir algunas de estas medidas en las tablas de hechos agregadas para simplificar los cálculos y los tiempos de respuestas. Las herramientas del mercado suelen proveer diferentes formas de definición de medidas derivadas en función de las básicas. Incluyen fórmulas de cálculo complejas y muchas veces evitan tener que realizar cálculos en el DW. Estas fórmulas pueden utilizarse en la etapa de diseño, quedando así las medidas derivadas incorporadas al Data Mart o cubo. También pueden usarse en la interfaz de consulta, permitiendo a los usuarios avanzados definir sus propias medidas y compartirlas. Un error frecuente es finalizar el diseño básico de la base de datos ignorando las medidas derivadas y recién tenerlas en cuenta cuando comienza el desarrollo de las aplicaciones de usuarios. Generalmente serán necesarios muchos cálculos del negocio que habrá que concensuar y es preferible anticiparse a estas tareas, sobre todo para asegurarse que todas las medidas básicas necesarias son tenidas en cuenta. Normalización de tabla de hechos Hay otro tipo de normalización que no se explicó en la sección anterior porque no refiere a las dimensiones sino a las tablas de hechos y en particular a las medidas. Cuando se tienen diferentes medidas asociadas a un evento, por ejemplo monto bruto, descuento, etc., lo más común es modelar estas medidas como columnas separadas dentro de la tabla de hechos. También es válido usar una sola columna denominada monto junto con una dimensión adicional que represente el tipo de monto (en este caso los valores: bruto, descuento, etc.). Esta solución es útil en algunos casos, particularmente cuando se tienen muchas medidas sin valor en muchos de los registros. Caso contrario implica multiplicar la cantidad de registros de la tabla de hechos, aumentando el tamaño de esta. Además, tener las medidas como columnas de un mismo registro es en general mucho más útil para operar con ellas y realizar cálculos (por ejemplo porcentaje del descuento sobre el monto bruto). Estas operaciones se dificultan si los valores están en registros separados. 30 Entiéndase que la medida derivada es perfectamente aditiva por las dimensiones del modelo. No quiere decir que sea calculada como una suma de medidas básicas, sino que la medida resultante puede sumarse. 68

69 Capítulo 3 El proceso de creación de modelos analíticos Diseño multidimensional avanzado. Existen situaciones particulares del modelado dimensional donde la elección de una estructura puede ser muy efectiva, o por el contrario donde se corre el riesgo de elegir un diseño ineficiente. En esta sección se plantean algunas consideraciones a tener en cuenta. Para obtener mayor detalle de los casos planteados, ejemplos y gráficos, consultar bibliografía ([Kim1998] y [Kim2002]). Dimensiones muchos a muchos En la mayoría de las situaciones clásicas de diseño la existencia y granularidad de la tabla de hechos es básica y bien entendida, y las dimensiones adjuntas son obvias y no polémicas. Pero existen casos donde una dimensión puede tener legítimamente más de un valor o ninguno para un mismo registro. A estos casos se los suele denominar dimensiones muchos a muchos. Analizando por ejemplo la temática del cuidado de la salud, se puede crear una tabla de hechos por cada registro de tratamiento realizado a algún paciente. La dimensión diagnóstico es muchos a muchos, dado que el tratamiento aplicado a un paciente puede tener más de un diagnóstico (y también puede no tener ninguno). Para resolver este problema y proveer un número arbitrario de valores (o diagnósticos) se inserta una tabla de relaciones (o tabla puente) entre la tabla de hechos y la dimensión en cuestión. En el ejemplo se crearía una tabla denominada grupo de diagnósticos, con una nueva clave, que es la que se utilizará en la tabla de hechos. La tabla de grupo de diagnósticos tendrá una clave compuesta, consistente de la clave del grupo y la clave del diagnóstico y un campo adicional que es el factor de peso asociado a ese diagnóstico dentro de ese grupo. El factor de peso asociado cumple el rol de poder analizar al total de tratamientos agrupados y correctamente sumarizados según el peso de los diferentes diagnósticos. Alternativamente este factor de peso podría no usarse y contar a cada tratamiento por cada diagnóstico, multiplicando la cantidad de tratamientos, pero permitiendo evaluar el impacto de cada diagnóstico, en términos de la cantidad total de tratamientos asociados. Esta estructura permite ambos análisis. El usuario decidirá cuál consultar. Roles de las dimensiones Un rol en un DW es una situación en la que una misma dimensión aparece varias veces en una misma tabla de hechos. Hay varias maneras en que esto puede ocurrir. Un ejemplo es el caso de las fotos acumulativas que reflejan el seguimiento del flujo de un producto a través de una cadena de procesos. Allí la dimensión fecha aparece repetidas veces representando la fecha de recepción de la orden de pedido, la fecha de facturación, de envío, etc. Otros ejemplos pueden ser aeropuertos de origen y de destino de un vuelo, cliente que realiza una llamada y cliente que la recibe, etc. 69

70 Capítulo 3 El proceso de creación de modelos analíticos Como la entidad en cuestión es la misma (los valores son iguales) no tiene sentido mantener más de una tabla con la misma información. Se crea entonces una única tabla de dimensión, y las diferentes dimensiones del modelo hacen referencia a la misma tabla física, utilizando vistas o alias en las consultas. Cada una de estas dimensiones puede ser usada en forma independiente, cumpliendo roles diferentes en un reporte. Cuando los roles de una dimensión están embebidos dentro de otra, como el caso presentado de la subdimensión ubicación del cliente, requieren ser normalizados para poder ser representados por una única tabla. Pocas o muchas dimensiones Como regla general se dice que la mayoría de los modelos dimensionales contienen entre cinco y quince dimensiones por cada tabla de hechos. Menos de cinco hace sospechar que algunas dimensiones no fueron tenidas en cuenta. Y un número muy grande de dimensiones es usualmente un signo de que muchas de ellas no son totalmente independientes y podrían ser combinadas en una sola dimensión. Distribución de medidas de distinta granularidad Una vez vistos aspectos particulares del modelado de dimensiones, resulta también interesante considerar algunas características de diseño avanzado de las tablas de hechos referentes al manejo de la granularidad y agregaciones. El modelo dimensional es más poderoso cuanto más atómicas son las tablas de hechos. Cuando en un diseño surgen hechos de granularidad diferente lo primero que se debiera hacer es tratar de forzar a todas las medidas al nivel más bajo. Este proceso se conoce como asignación o distribución de medidas de niveles altos hacia niveles inferiores. Existen varios casos donde es necesario aplicar esta técnica en DWs. El más dominante es tal vez la alocación de costos. Por ejemplo en una factura de transporte de mercadería puede ser que el costo esté asociado a la factura completa y no esté inicialmente distribuido en los ítems individuales. De esta forma no podrá calcularse la rentabilidad o ganancia por ítem. La distribución de algunas de estas medidas puede tener una lógica muy compleja. Sería deseable que sea el área del negocio entendida en el tema quien se encargue de realizar estas distribuciones. Si este proceso resulta muy controversial o complicado puede distraer y demorar al equipo de desarrollo del DW. Si la distribución de medidas hacia el nivel de granularidad más bajo no resultara posible, el diseñador no tendrá otra alternativa que representar los niveles más altos en tablas de hechos separadas. Una vez que se ha elegido el nivel de granularidad de una tabla de hechos, es muy importante que todas las medidas aditivas sean presentadas en ese nivel. A veces, con el afán de mejorar los tiempos de respuesta o simplificar las consultas, se comete el error de guardar información agregada que debiera ser calculada dentro de los registros de una tabla de hecho. Por 70

71 Capítulo 3 El proceso de creación de modelos analíticos ejemplo en una tabla con granularidad diaria guardar un dato como el total anual a la fecha. Estos datos pueden resultar confusos porque no son completamente aditivos. Si al consultar los datos se eligiera más de un día se correría el riesgo de contar más de una vez el mismo valor. Agregaciones Luego de haber determinado el diseño global es necesario considerar la estrategia que se usará para agregar tablas de hechos y de dimensiones. Cada nivel de agregación que se decida incorporar debe tener su propia tabla de hechos. Las tablas de dimensión adjuntas a estas nuevas tablas de hechos deben ser, cuando sea posible, versiones encogidas de las tablas de dimensión originales. Las agregaciones, también conocidas como tablas de redundancia, tienen el objetivo de mejorar los tiempos de performance y están ligados a la implementación física del modelo dimensional. La creación de estas dependerá fuertemente del volumen de datos que se esté manejando31. Dado que las agregaciones son la forma de poner a punto la performance será necesario construir algunas de estas tablas, probar los de tiempos de respuestas y revisarlas. También será necesario monitorearlas a través del tiempo y hacer los ajustes necesarios cuando haga falta, en función del crecimiento del DW. Hay dos puntos a considerar al construir las agregaciones: las peticiones comunes del negocio y la distribución estadística de los datos. Primero habrá que determinar qué podría ser útil revisando en la documentación del relevamiento cuáles son las necesidades para reportes de alto nivel. Luego, revisar cada dimensión para determinar los atributos usados comúnmente en reportes, y las combinaciones de estos atributos para ver cuales se utilizan juntos. Cuantas más dimensiones haya más cuidadoso hay que ser porque mayor será la cantidad de combinaciones para las cuales se podrían crear agregaciones. En segundo término se necesita evaluar la distribución estadísticas de los datos. Para esto referirse al prototipo de exploración de datos, la información de diseño de las tablas, y a los datos en sí mismos, buscando contabilizar la cantidad de valores de cada nivel de la jerarquía de cada dimensión. Existen técnicas de diseño más avanzadas sobre agregaciones que incluyen modelado de dimensiones estructuradas con jerarquías parciales, jerarquías con profundidades impredecibles, formas de resolver los casos donde los atributos de las dimensiones cambian de valor, dimensiones de auditoria, cómo manejar la dimensión tiempo (dentro del día) para representar rangos horarios, etc.. 31 Si la tabla de hechos contiene pocos miles de registros probablemente responda rápido y no necesite agregaciones. Diferente es si tiene cientos de miles o millones de registros. 71

72 Capítulo 4 Presentación del caso de estudio 4 Presentación del caso de estudio El ejemplo de aplicación elegido se basa en la temática de deserción de alumnos universitarios. Esto es, contar con información que colabore con la identificación de perfiles y patrones de los alumnos que dejan de tener actividad académica en la universidad. El abordaje del tema se circunscribe a la definición de un modelo dimensional que permita identificar características y comportamientos generales de los alumnos universitarios y realizar un desgranamiento de estos. El tema se encara desde el diseño, no se pretende involucrar cuestiones sociológicas que quedan fuera del alcance computacional. Para el caso de estudio se usa como sistema operativo de partida el sistema de gestión académica de alumnos SIUGuaraní y específicamente su modelo de datos. El SIUGuaraní es un sistema de desarrollo evolutivo diseñado e implementado por el SIU. Actualmente es utilizado con sus personalizaciones particulares como sistema de gestión académica en muchas de las universidades nacionales argentinas. La herramienta sobre la que se desarrolla el ejemplo es O3, de la empresa IdeaSoft. La elección de la herramienta tuvo en consideración que la misma ya está siendo utilizada muchas de las universidades del país, promovida por el SIU mediante los modelos de análisis de información que desarrolla. 4.1 Qué es el SIU? El SIU es un área dependiente de la Secretaría de Políticas Universitarias, perteneciente al Ministerio de Educación, Ciencia y Tecnología32, que desarrolla sistemas de gestión y también sistemas para la toma de decisiones y el análisis institucional en el ámbito de las Universidades Nacionales Argentinas. Además de desarrollar soluciones informáticas, el SIU ayuda en la implementación de las mismas. Dentro de este ámbito también se realizan desarrollos para diferentes áreas de la Secretaría de Políticas Universitarias, donde se recibe y consolida información de todo el sistema universitario nacional. El objetivo del SIU es dotar al sistema universitario de elementos que permitan mejorar la confiabilidad, completitud, disponibilidad e integridad de la información, contribuyendo de esta forma a mejorar la gestión de las instituciones, permitiéndoles optimizar sus recursos y lograr que el software sea aprovechado en toda su potencialidad. La filosofía consiste en utilizar la tecnología al servicio de la institución colaborando así en el mejoramiento de la gestión, agilizando las operaciones diarias de la comunidad universitaria. También se hace hincapié en la calidad de la información que se lleva en los sistemas para su análisis y utilización en la toma de decisiones estratégicas. 32 Información a septiembre del En 2008 el SIU cambia de autoridades pasando a depender de un consorcio de universidades y adoptando el nombre de Consorcio SIU. 72

73 Capítulo 4 Presentación del caso de estudio El SIU tiene una modalidad de trabajo colaborativo en red, involucrando a distintos actores de las universidades. La metodología de trabajo se basa principalmente en la transferencia de conocimiento, el intercambio de productos y la promoción de encuentros [6] [7]. Los sistemas desarrollados abarcan la gestión operativa de las distintas áreas de una universidad: académica, económicafinanciera, recursos humanos, bibliotecas, etc., y su correspondiente visión gerencial. Entre los sistemas desarrollados: SIUPampa/SIUMapuche: Sistema de recursos humanos. Gestión del personal y liquidación de sueldos. SIUComechingones/SIUPilagá: Sistema presupuestariocontable. SIUGuaraní: Sistema de gestión de alumnos (carreras, graduados, aulas, etc.) SIUKolla: Encuestas para seguimiento de graduados SIUAraucano: Sistema estadístico de alumnos. Datos que se informan al Ministerio de Educación. SIUTehuelche: Sistema de gestión de becas universitarias. SIUQuilmes: Sistema de gestión de cobranzas. En la actualidad, el número de implementaciones de los sistemas del SIU en las universidades nacionales y otros organismos es de aproximadamente 800 y en cada una de las universidades nacionales se están utilizando al menos dos de los sistemas del SIU. En los últimos años el SIU ha logrado satisfacer la necesidad de contar con información confiable y oportuna en diferentes niveles de la gestión de las Universidades Nacionales, colaborar en la cultura de la transparencia, acompañar la mejora de los procesos administrativos, incentivar la integración de áreas que tradicionalmente se encuentran atomizadas, estandarizar datos y procesos, arraigar la concepción de la capacitación del personal administrativo como una inversión, e incorporar nuevas tecnologías [7]. Actualmente el SIU se percibe como un importante capital y una avanzada en lo que hace al desarrollo, distribución de sistemas y trabajo cooperativo, sobre todo por pertenecer a la administración pública. 4.2 El sistema de software SIUGuaraní El SIUGuaraní es un sistema de gestión académica desarrollado por el SIU para todas las Universidades Nacionales. Fue concebido con el propósito de proveer a las universidades de una herramienta que les permita administrar la gestión de alumnos en forma segura, con la finalidad de obtener información consistente para los niveles operativos y directivos. El sistema registra y acompaña la actividad formativa del alumno desde que ingresa a la universidad hasta que egresa, llevando registro de toda la actividad académica intermedia, El SIUGuaraní administra toda la 73

74 Capítulo 4 Presentación del caso de estudio información de gestión académica: carreras, planes de estudio, títulos, materias, egresados, inscripciones y resultados de trabajos prácticos y exámenes, profesores asociados a las cátedras, asignación de aulas, asistencias, cursos de ingreso, actividades extracurriculares, equivalencias, certificados, encuestas, etc. Este sistema se caracteriza por ser seguro, auditable y flexible. Se sustenta en una metodología de trabajo colaborativa en red que permite su autosustentabilidad. Hasta el momento cuenta con más de 200 implementaciones en unidades académicas correspondientes a 42 instituciones educativas argentinas, de las cuales 34 son universidades nacionales [6] [7]. Es utilizado por personal administrativo de la universidad, alumnos, docentes y directivos. Los servicios brindados dependen del perfil de acceso. El acceso a usuarios se permite a través de distintas interfaces, cada una con su funcionalidad: de gestión administrativa, terminales de autogestión, Internet, o por teléfono (utilizando tecnologías sms y wap) [6] [7]. Más allá de las características del sistema informático como producto (aspectos tecnológicos, prestaciones, módulos, usuarios, etc.) es interesante resaltar la visión del Guaraní como proyecto. El SIUGuaraní integra componentes sociales, tecnológicos, políticos, culturales y económicos que interactúan entre sí. El objetivo del proyecto es desarrollar un único sistema informático para todas las Universidades Nacionales con una arquitectura técnica que permita que cada institución pueda extenderlo o personalizarlo, manteniendo la compatibilidad. Esto permite al sistema reflejar la realidad particular de las instituciones. El proyecto SIUGuaraní surge hacia fin de año del 1996, luego de un importante trabajo de relevamiento de la situación del sistema universitario argentino. Se decide desarrollar un sistema informático de gestión de alumnos que contemplara la complejidad y heterogeneidad del sistema universitario argentino. Que se adaptara a las realidades de las diferentes unidades académicas, que permitiera acompañarlas en la mejora de sus procesos [6] [7]. El desarrollo del sistema comenzó en agosto del 1997 con la conformación de un comité de desarrollo, integrado por un equipo del SIU y técnicos de las universidades para relevar las necesidades funcionales. Como metodología de trabajo se decidió que el SIU desarrolla todas las funcionalidades transversales y las particularidades son adaptadas por cada universidad. Se entregan todos los programas fuentes a los equipos técnicos de las universidades, quienes son responsables de la implementación, y se establecen como socios del proyecto. Desde el SIU se asesora y colabora. La filosofía de trabajo se puede sintetizar en los siguientes lineamientos: trabajo colaborativo, transparencia, integración y conocimiento compartido. Una evaluación del proyecto permite observar el impacto que ha producido el desarrollo del SIUGuaraní hasta el momento. Se han automatizado áreas de gestión de alumnos, haciendo más eficientes los procesos y brindando integridad, seguridad, completitud y confiabilidad a los datos. Entre otros aspectos, se destacan: el aumento creciente de unidades académicas que han implementado el SIUGuaraní, la extensión del proyecto a otras áreas del sistema educativo, la ampliación del grupo de técnicos y de usuarios operativos capacitados en el sistema, el interés por 74

75 Capítulo 4 Presentación del caso de estudio parte de distintos organismos en incorporar la metodología de trabajo y la consolidación de una filosofía de trabajo en red al interior de las universidades [7]. 4.3 Deserción y desgranamiento de alumnos La deserción universitaria es un tema que ha despertado mucho interés en el último tiempo. El costo económico para el estado nacional de un alumno en la universidad, la creciente necesidad de profesionales en algunas áreas y otras causas sociales son algunos de los motivantes que conducen a preguntarse por qué una persona comienza sus estudios universitarios y luego los abandona. El fenómeno de la deserción, y también el de repitencia, tiene importantes implicancias personales, institucionales, sociales y económicas. En lo personal, implica una condición de fracaso que afecta emocionalmente a los individuos, especialmente en su inserción laboral. En lo institucional implica una disminución del rendimiento académico de la universidad y un incremento innecesario del número de alumnos y el costo de mantenimiento de estos. En lo social, la deserción contribuye a generar inequidad y desequilibrios sociales y desvirtúa los objetivos que la sociedad le ha entregado a la educación superior. También produce un aumento del subempleo y falta de aporte intelectual. En lo económico, el costo que esto implica para los sistemas es enorme. En un estudio de UNESCO realizado en febrero de 2004 en 15 países que cubren un 90% de Latinoamérica el costo de la deserción se estimaba en U$ 11,1 billones de dólares al año, lo que, según se indicó, en países como Brasil equivale al costo de 2 millones de estudiantes universitarios [8] [9]. El problema de la repitencia y la deserción es de una magnitud considerable en todos los países de la región. En Argentina se estima que sólo el 12% de los estudiantes que ingresan a las universidades nacionales se gradúan, y si bien no hay datos oficiales para las instituciones privadas se estima que es del orden de un 30%. Un 50% de la deserción ocurre durante los dos primeros años de la carrera [8]. De los estudios realizados por la UNESCO [9] se ha concluido que las tasas de abandono y las causas difieren mucho entre carreras y centros educativos. Esto lleva a querer establecer una tipología de las carreras universitarias a partir de las formas en las que se producen los fracasos. El sistema argentino tiene sus particularidades, es muy abierto y flexible, se puede ir y volver cuando se desee. Se rinden exámenes cuando se quiere, por lo que las permanencias tienden a ser muy largas. Al respecto existen dos problemas: la deserción y la exclusión. Los factores de la deserción se atribuyen a causas externas como el lugar de residencia, las características socioeconómicas y la educación de los padres y también a causas internas tales como las políticas de administración, la falta de orientación vocacional y el exceso de programas. Entre las posibles acciones para mejorar la situación actual se indicaron la detección 75

76 Capítulo 4 Presentación del caso de estudio temprana de posibles desertores, la prevención, el apoyo, la determinación de momentos problemáticos y la articulación con la escuela media. Como propuestas para superar la deserción se señalaron los programas de becas, los programas de articulación con la educación media, la orientación vocacional, y el establecimiento de ciclos generales de conocimientos básicos. Con ellos se pretende dar respuesta a problemas de deserción, retraso en los estudios, elección de carrera y movilidad institucional [9]. El caso práctico de esta tesis busca plantear un modelo dimensional que ayude a encontrar dónde se concentran los mayores problemas dentro de una institución e identificar posibles causas. Este conocimiento permitirá que desde la universidad puedan tomarse acciones que ayuden a resolver los problemas existentes basándose en datos concretos. El tema seleccionado es complejo y desde el punto de vista de la tesis, sólo se pretende aplicar y explicar los conceptos teóricos presentados previamente en un caso práctico. Como segundo objetivo se espera que los resultados obtenidos sirvan como disparador para su implementación en las universidades que actualmente estén utilizando el SIUGuaraní y que esta primera aproximación hacia obtener conocimiento desde la información incentive desarrollos en esta área. En los próximos capítulos se explica paso a paso el diseño dimensional siguiendo las etapas del ciclo de vida BDL. Sin lugar a dudas las implementaciones concretas y la retroalimentación de usuarios finales reales permitirán que este proyecto siga creciendo. 76

77 Capítulo 5 Presentación de la solución 5 Presentación de la solución Este capítulo consiste en el desarrollo del modelo para el caso práctico que sigue la aplicación personalizada de la metodología BDL presentada en el capítulo 3. Algunas etapas del BDL no tienen sentido dadas las particularidades del ejemplo elegido. 5.1 Requerimientos y especificación del Data Mart Al presentar la etapa de definición de requerimientos como parte del ciclo de vida de un proyecto de Data Warehousing se recalcó la necesidad de contar con usuarios que estén ansiosos por obtener soluciones para analizar datos para lograr el éxito del proyecto. Al momento de desarrollar este trabajo y por tratarse de un trabajo experimental de tesis no se tiene un usuario sponsor que colabore en la especificación de requerimientos. Tampoco se cuenta con usuarios a los cuales realizar las entrevistas planteadas por la metodología para esta etapa. Por lo tanto el análisis de requerimientos para la solución presentada surge de quien escribe y la observación de algunas de las necesidades de información de la comunidad universitaria, por trabajar desde hace unos años ese ámbito. Cómo se planteó anteriormente, mediante este trabajo se busca aplicar en un caso práctico los conceptos teóricos presentados. Adicionalmente se espera que las posibilidades de análisis sirvan como puntapié inicial para incentivar una propuesta que realmente pueda usarse para tomar decisiones. Cabe aclarar que la complejidad de la temática abordada requiere que los datos sean analizados por un grupo interdisciplinario, donde podrían participar sociólogos, psicólogos, estadísticos y otros profesionales capaces de realizar interpretaciones correctas sobre la información, definir variables, agrupadores, y también de esta forma colaborar al crecimiento de la esta solución. Datos considerados La idea principal de este trabajo consiste en la identificación de perfiles de alumnos que dejan de tener actividad académica en la universidad. Para esto se consideran datos en tres niveles diferentes de análisis: el alumno en cada uno de los años académicos en que ha tenido actividad dentro de la carrera, el alumno, evaluado en todo el tiempo transcurrido desde que comenzó la carrera, y por último la persona. Dado que un mismo individuo puede ser alumno de más de una carrera es interesante evaluarlo también como individuo en toda la universidad, independientemente de la o las carreras en que registre actividad. 77

78 Capítulo 5 Presentación de la solución Estos niveles determinan las medidas del cubo: cantidad de personas, cantidad de alumnos y cantidad de alumnos por cada año con actividad. Las dimensiones que se utilizan son variables de evaluación de la actividad académica (por ejemplo el total de materias aprobadas en un año, el total de cursados pendientes de exámenes, etc.), datos de los alumnos (carreras y planes) y otros datos personales (edad, sexo, procedencia, etc.) 33. Datos que quedaron excluidos y motivos En el SIUGuaraní existen datos de los alumnos que hubiese sido interesante tener en cuenta para estudiar el desgranamiento y que quedaron excluidos en este trabajo. Se trata de los datos censales, que reflejan la situación socioeconómica de los alumnos (si trabaja, con quien vive, como financia sus estudios, el nivel de estudio de sus padres, etc.). En este trabajo no fueron incluidos por las siguientes razones: Definiciones poco claras que entorpecen la interpretación de los datos censales. Algunos datos no tienen un significado del todo definido, como es el caso de si trabaja o no. No se sabe si la situación es temporal respecto al momento que se relevó el dato o si es duradera. Muchos datos dependen del criterio de los alumnos si no fueron ingresados al sistema con algún tipo de asesoramiento. Problema para asociar los datos censales con un período académico. Los datos censales pueden completarse y actualizarse en diferentes momentos del año, pudiendo existir más de un registro por persona por año. En las universidades y facultades se toman criterios propios sobre la actualización de estos datos. No se tiene buena calidad en estos datos en la mayoría de las implementaciones. Las universidades no suelen darles importancia porque no son necesarios para las tareas imprescindibles de un sistema académico de alumnos, entonces muchos datos están sin completar o presentan inconsistencias. Por último, en cada instalación de SIUGuaraní se puede personalizar el formulario de datos pedidos, pudiendo diferir no sólo en el significado y contenido sino también en el conjunto de datos existentes y los períodos de relevamiento. De hecho, la UNS cuenta con personalizaciones respecto a esta información. Tener en cuenta estos datos hubiese requerido desarrollar procesos de extracción de datos personalizados. Inicialmente se pensó además en definir categorías de actividad de los alumnos (por ejemplo clasificar la actividad anual en: nula, baja, suficiente, alta y muy alta, en función de la 33 Observar que si el análisis que se pretendiera hacer fuese otro, las medidas y dimensiones podrían considerarse totalmente diferentes. Por ejemplo el alumno podría ser una dimensión y la cantidad de cursados aprobados, cursados desaprobados, finales aprobados, etc. podrían ser medidas. 78

79 Capítulo 5 Presentación de la solución cantidad de finales y cursados), intensión de actividad (en cuántas materias se inscribe o se presenta a rendir) y categorías de rendimiento (en función de los resultados obtenidos). Finalmente se desechó la propuesta. Resulta complicado en una aplicación real definir estos parámetros que en gran medida dependen del plan de estudio, lugar geográfico, situaciones sociales, etc. Para realizar una clasificación justa habría que tener en cuenta variables dependientes de la carrera: la cantidad de materias del plan, las materias en sí, si el plan contempla sistema de puntos, materias promocionables y la realidad de los alumnos de la universidad o facultad: horarios de cursado disponibles, si la mayoría de los alumnos trabaja, provienen de otro lugar, viven lejos de la universidad, etc. Todo esto terminaba oscureciendo las fórmulas y alejándonos de los objetivos del caso de estudio. Otras variables que resultan de interés para el análisis de deserción y desgranamiento refieren a la lentificación en la carrera (respecto al plan de estudio o al promedio histórico de tiempo desde el ingreso hasta la graduación en la carrera), la repitencia (si el alumno debe recursar materias, o rendir muchas veces algún final) y la movilidad (si se producen cambios de carrera). Es muy difícil definir este tipo variables. Al intentarlo surgen preguntas como por ejemplo: Qué alumnos deben ser considerados para calcular el promedio histórico? A partir de qué cohorte se considera? Existen todos los datos necesarios en la base de datos OLTP SIUGuaraní? Cómo calcular lentificación?, es la cantidad de materias cursadas sobre la cantidad total del plan actual del alumno? Y si el alumno se cambió de plan, cómo debieran contarse las materias del plan anterior? Qué sucede si el plan está compuesto de materias y créditos? Cuándo se considera que un alumno se movió de carrera?: porque quedó de baja?, porque ya no se inscribe a materias? Qué sucede cuando sólo registra actividad en materias comunes? Para trabajar con este tipo de datos es necesario que exista un equipo que respalde las definiciones y que vaya a utilizar los datos definidos. Por el momento no tiene sentido considerar estas cuestiones porque implican una complejidad conceptual imposible de abordar en este trabajo. 5.2 Arquitectura del caso práctico La arquitectura de la solución propuesta se presenta en la figura 17 y es una adaptación de la presentada en la figura 3. En este caso, la base de datos del sistema SIUGuaraní es la única fuente de datos. La sección de transformación de datos no existe explícitamente34. La extracción de datos se realiza mediante la ejecución de procesos que se incorporan en la base de 34 Debido a diversos motivos del sistema universitario, pero principalmente a la falta de maduración en estas temáticas, resulta difícil crear y administrar tanto un DW como un área de transformación de datos. Estas tareas, junto con la implementación de una herramienta de ETL y la conexión de los cubos al DW (planteado en la figura) se dejan para trabajo futuro. 79

80 Capítulo 5 Presentación de la solución datos del SIUGuaraní. Estos procesos generan archivos de texto plano que se utilizan para generar el Data Mart o cubo. Las escasas transformaciones de datos que se realizan se incluyen dentro de dichos procesos. La tarea de diseño consiste en crear un modelo multidimensional, propietario. Este modelo o meta data se utiliza como dato de entrada del componente que genera el cubo (O3 Builder) en la etapa de carga de datos. En la figura 17 se observan los diferentes módulos de la herramienta O3. Estos se pueden clasificar en tres grandes categorías: los componentes de la interfaz de usuario (que serán las únicas herramientas para análisis de información que se utilizarán en este trabajo), los de diseño y construcción de cubos y los de administración de cubos en un servidor (O3 Server y O3 Administration Server, para configurar usuarios y permisos de acceso por perfiles). O3 Builder Load O3 Browser (escritorio) t x t BD SIUGuaraní E.T. (sp) O3 Report t x t t x t O3 Dashboard Modelo del cubo (.mdl) META DATA O3 Scorecard O3 Rules O3 Process O3 Portal (web) O3 Designer O3 Query O3 Server Área de usuario Idealmente sería un DW (O3 Query) DW O3 Adm Server Figura 17. Arquitectura de la solución propuesta. 5.3 Matriz y modelo lógico del Data Mart La matriz que resulta del análisis de requerimientos planteados en la sección se muestra en la figura 18. Se pueden ver claramente los tres niveles de análisis contenidos en el Data Mart (persona, alumno y alumno por año con actividad) y las dimensiones planteadas, junto con los cruces válidos. El gráfico presenta los ejes intercambiados respecto a la propuesta original sólo para obtener una mejor visualización La mayoría de las dimensiones (unidad académica, edad, título secundario, cantidad de carreras activo, etc.) están asociadas a la persona y por lo tanto se heredan en las otras dos medidas. Carrera no está definida a nivel de persona porque puede haber más de una y es la razón por la cual se distingue entre personas y alumnos. La dimensión Año informado corresponde sólo para la medida que cuenta alumnos en cada año que tienen actividad. 80

81 Unidad Académica Año de Ingreso Unidad Académica Año de Ingreso a la Universidad Año de Ingreso a la Carrera Año Informado Último Año de Actividad en la Universidad Último Año de Actividad en la Carrera Edad al Ingreso a la Universidad Edad al Ingreso a la Carrera Edad al año Informado Sexo Nacionalidad País Provincia Localidad Colegio Título Secundario Año de Egreso del secundario Orientación Vocacional Cantidad de carreras inscripto Cantidad de carreras activo/inscripto Cantidad de carreras egresado Carrera Cursados Aprobados Totales por Persona Cursados Aprobados Totales en la Carrera Cursados Aprobados en la Carrera y Año Informado Año Informado Último Año de Actividad Edad Sexo Nacionalidad Procedencia Título Secundario Año de Egreso del secundario Orientación Vocacional Cantidad de carreras inscripto activo Cantidad de carreras egresado Carrera Cursados Aprobados Cantidad de alumnos por año con actividad Niveles Cantidad de alumnos Dimensiones Cantidad de personas Capítulo 5 Presentación de la solución 81

82 Capítulo 5 Presentación de la solución Cursados Desaprobados Cursados Promovidos Finales Aprobados Finales Desaprobados Equivalencias Externas Cursados Desaprobados Totales por Persona Cursados Desaprobados Totales en la Carrera Cursados Desaprobados en la Carrera y Año Informado Cursados Promovidos Totales por Persona Cursados Promovidos Totales en la Carrera Cursados Promovidos en la Carrera y Año Informado Finales Aprobados Totales por Persona Finales Aprobados Totales en la Carrera Finales Aprobados en la Carrera y Año Informado Finales Desaprobados Totales por Persona Finales Desaprobados Totales en la Carrera Finales Desaprobados en la Carrera y Año Informado Equivalencias Externas Totales por Persona Equivalencias Externas Totales en la Carrera Equivalencias Externas en la Carrera y Año Informado Figura 18. Matriz correspondiente al Data Mart del caso práctico. Varias de las dimensiones (las referentes a cantidades de materias y Edad ) presentan tres niveles de análisis, uno correspondiente a cada medida. Debe seleccionarse la combinación de nivel y medida adecuada a la consulta deseada. Por ejemplo, si se quiere ver lo ocurrido dentro de una carrera y un año en particular (utilizando la dimensión Año Informado ) se debe utilizar la medida Cantidad de alumnos por año con actividad y consultar estas dimensiones en el nivel más bajo (por ejemplo: Cursados Aprobados en la Carrera y Año Informado ). Si se desea evaluar lo realizado dentro de la carrera, sin discriminar por año académico será necesario elegir la medida Cantidad de Alumnos y utilizar el nivel intermedio que refiere a la actividad dentro del alcance de cada carrera (por ejemplo: Cursados Aprobados Totales en la Carrera ). En el nivel superior se resume la actividad a nivel de persona ( Cursados Aprobados Totales por Persona ). También es posible comparar lo ocurrido dentro de un año académico con el total acumulado en la carrera, por ejemplo. Esto se logra consultando la medida Cantidad de alumnos por año con actividad y la dimensión Cursados Aprobados en sus niveles en la carrera y año informado y totales en la carrera en forma simultánea. La dimensión Año de Ingreso también presenta dos niveles de análisis: ingreso a la universidad (o unidad académica) e ingreso a la carrera. El modelo de datos resultante tal como se visualiza al realizar consultas en el cubo se muestra en la figura 19. Las tablas de color gris son las tablas de hechos, que muestran las relaciones con las dimensiones. El resto son dimensiones. Las dimensiones que tienen más de un nivel o jerarquía se indican en color amarillo en el diagrama, por ejemplo procedencia y cursados aprobados. 82

83 Capítulo 5 Presentación de la solución Figura 19. Modelo de datos lógico del caso práctico. Tablas de hechos y dimensiones. Observar que como un alumno es una persona, también podrá consultarse la cantidad de alumnos por edad, o nacionalidad, y las demás dimensiones y niveles que se muestran asociadas a la persona. Todos los datos definidos en un determinado nivel son heredados en los inferiores, es decir que, por ejemplo, se podría consultar Cantidad de alumnos por año con actividad según cursados aprobados para una carrera en un determinado año académico ( Cursados Aprobados en la Carrera y Año Informado y Año Informado ) según la edad de la persona al momento en que comenzó sus estudios universitarios (sin importar la carrera, Edad al Ingreso Universidad ), pero no se podrá consultar Cantidad de Personas según Edad al Año Informado o Edad al Ingreso Carrera, porque esa medida no está definida en esos niveles de granularidad. 5.4 Modelo físico y consideraciones de diseño El modelo físico puede pensarse en dos partes: por un lado la estructura de los archivos de texto plano que contienen los datos para el cubo, y por otro el modelo de datos que define la forma de visualización del mismo, y mapea la estructura de los archivos de texto en el cubo MOLAP (archivo con extensión mdl). 83

84 Capítulo 5 Presentación de la solución Diseño físico de las tablas del DW que se usan para el Data Mart En este ejemplo, las tablas de hechos son tres, todas se utilizan dentro del mismo cubo. La tabla con el nivel de granularidad más bajo es la de Alumnos por Año Académico en que presenta actividad. Esta tabla puede considerarse del tipo fotografías periódicas con una foto por alumno y año académico. Las otras dos tablas pueden considerarse de tipo fotografías acumulativas, pero donde se guarda sólo el último estado, reflejando la información acumulada a la fecha del alumno o la persona. Estas tablas cumplen una doble función como tablas de dimensión con atributos (y se definen como tablas locales en O3 dentro del archivo con extensión mdl). También representan una agregación de la tabla cuyo nivel de detalle la precede. En los tres casos se trata de tablas de hechos sin medidas, ya que la única medida asociada a cada tabla es la cantidad de registros. La estructura de los archivos de texto respetan cierto nivel de normalización por los siguientes dos motivos: para que a futuro pasen a formar parte de un DW. Se consideran dimensiones acordadas con otros cubos ya existentes sobre el SIUGuaraní. Se intenta minimizar las transformaciones necesarias en los datos para lograr la arquitectura de la solución definitiva. y para que el tamaño de los archivos sea menor. La correspondiente desnormalización necesaria para el diseño final del Data Mart se logra dentro de la definición propia del cubo de O3 y se realiza al momento de la construcción de este. Esto produce un incremento en el tiempo de generación del cubo y mayor complejidad en el archivo.mdl; pero se prioriza normalizar las tablas por los motivos expuestos. Una vez implementado el DW, la desnormalización podría realizarse en él, o en las consultas SQL que surjan de modificar la definición del cubo para consumir los datos. Las tablas diseñadas para formar parte del DW son mostradas en la figura

85 Capítulo 5 Presentación de la solución Figura 20. Estructuras de los archivos de texto. Notar que muchas de las dimensiones planteadas en el modelo de la figura 19 no necesitan implementarse mediante una tabla porque el código de la dimensión es la descripción de la misma y el nivel de agrupamiento que se utiliza se define dentro del modelo del cubo. Estos casos se modelan como dimensiones directamente en la definición del cubo (archivo mdl). Tal es el caso de los años (año informado, año de ingreso, etc.) y las cantidades de materias (cursados aprobados, cursados desaprobados, finales aprobados, etc.). Observar que las dimensiones que cuentan cantidades de materias se definen en las tres tablas de hechos. Esto es así porque representan cosas diferentes, cada una cuenta en el nivel de granularidad en que se define, y por eso tienen nombres diferentes. Luego se combinan como diferentes niveles de análisis de una misma dimensión sólo para simplificar el modelo final y no tener muchas dimensiones similares que dificulten el análisis. Es importante destacar que los datos sumarizados se calculan en las tablas de alumnos y personas porque se decidió utilizarlos como dimensiones. Si en otro modelo de análisis se decidiera usar estas cantidades como medidas no será necesario calcularlas, se haría solo, definiendo la medida en el nivel más bajo (de alumno en año académico) y utilizando el método de agregación suma. Algunos datos contenidos en estas tablas no se usan en el modelo final. Se incluyeron porque pueden utilizarse a futuro para armar diferentes cubos, focalizando en análisis más específicos. 85

86 Capítulo 5 Presentación de la solución Diseño físico del Data Mart Respecto al diseño final que verá el usuario, este respeta la forma de la figura 19. En el cubo de O3 las estructuras internas deben aplanarse completamente, formando un esquema estrella. Para esto las claves de todas las dimensiones deben estar en la tabla donde se encuentra la medida (en el nivel correspondiente). Cuando no están se definen especialmente mediante la utilización de tablas locales y campos virtuales. Si las tablas estuvieran en una base de datos, en lugar de ser archivos de texto, el aplanamiento podría realizarse mediante uniones de tablas en las consultas en SQL y la creación de tablas locales y campos virtuales no sería necesaria en la mayoría de los casos. Definición de fuentes de datos Específicamente dentro de la herramienta O3 el diseño de un cubo comienza con la definición de las fuentes de datos, que en este caso son los archivos de texto. Para tomar un archivo de texto como fuente se establece la ruta de acceso (figura 21) y se definen los campos con sus respectivos tipos (figura 22). Para la ruta de acceso puede utilizarse un parámetro, como en este caso ( raiz ). Figura 21. Definición de fuentes de datos en O3. Tabla de hechos correspondiente al archivo de texto con información de personas (int_de_personas.txt) En la definición de los campos y tipos de datos (figuras 22_1 y 22_2) puede utilizarse la función de autollenado si el archivo de texto tiene como cabecera los nombres (e indicar expresamente saltar ese primer registro como se puede observar en la figura 21). 86

87 Capítulo 5 Presentación de la solución Figura 22_1. Definición de campos que componen el archivo de la fuente int_dw_desercion_alumnos_anio. Figura 22_2. Definición de campos que componen el archivo de la fuente int_dw_personas, que además se utiliza como tabla local La información entre tablas se vincula automáticamente por los nombres de los campos, que deben coincidir exactamente para considerarse iguales. De esta forma por ejemplo el campo NACIONALIDAD de la tabla int_dw_personas (figura 22_2), se considera igual al de la tabla LT_Nacionalidades (figura 23). 87

88 Capítulo 5 Presentación de la solución Figura 23. Definición de tabla de dimensión en O3. Definición de dimensiones La definición de las dimensiones se realiza identificando los códigos únicos de los valores para cada nivel de estas y las descripciones correspondientes. En la figura 24 se muestra la definición de la dimensión Nacionalidad, compuesta por un único nivel. Figura 24. Definición de una dimensión con solamente un nivel. 88

89 Capítulo 5 Presentación de la solución Las dimensiones deben tener al menos un nivel, pero pueden tener más de uno. Tal es el caso de Procedencia. Para cada nivel se indica el campo que es la clave que identifica los distintos valores y las descripciones correspondientes. Y en la dimensión se indica si el nivel más bajo identifica unívocamente al resto de los niveles o no. Observar en la figura 25 la indicación de Colegio como nivel único de la dimensión. En estos casos sólo es necesario incluir en las tablas de hechos la clave de ese nivel, el más bajo. Figura 25. Definición de dimensión con varios niveles: Procedencia. Definición de medidas Por último se definen las medidas, que pueden ser básicas (corresponden a un campo de la fuente), o derivadas (se calculan a partir de medidas básicas y/o datos adicionales). Figura 26. Definición de medida Cant Personas como medida básica. 89

90 Capítulo 5 Presentación de la solución Para las medidas básicas se indica el campo de la fuente al que corresponde, el método que se utiliza cuando es agregada en los niveles superiores de las dimensiones y el alcance (cada una de las dimensiones y niveles para los que está definida la medida). Esto se muestra en las figuras 26, 27 y 28. Figura 27. Método de agregación para la medida Cant Personas. Suma indica que por ejemplo en el nivel Localidad de la dimensión Procedencia se contará la suma de las personas de los colegios correspondientes. Figura 28_1. Parte de la definición del alcance de la medida Cant Personas. Figura 28_2. Parte de la definición del alcance de la medida Cant Personas. La definición del alcance de cada medida es una tarea importante y debe estar acorde a la lógica de los datos. En las figuras 28_1 y 28_2 se observa parte de lo realizado para Cant Personas. El nivel de cada dimensión que existe en la fuente de datos de la medida (int_dw_personas) es el primero para el cual queda definida y se indica con el símbolo del diskette. De ese nivel para arriba en la jerarquía se utiliza en general la agregación (símbolo de suma). En algunos casos podría optarse por dejarlo indefinido (signo de interrogación) para obligar a que las 90

91 Capítulo 5 Presentación de la solución consultas se hagan seleccionando uno o más valores del primer nivel para el cual la medida queda definida. Del nivel del diskette para abajo hay que indicar que la medida no está definida y no puede consultarse. Observar, por ejemplo, como se utiliza la agregación en la dimensión Procedencia, la indefinición completa de la dimensión Carrera, la diferencia en la visualización final (al consultar el cubo) respecto a Año Informado y la definición del alcance sólo para el nivel superior en las dimensiones que cuentan materias35. Uso de tablas locales y campos virtuales Anteriormente se dijo que ciertos datos de la persona pueden proyectarse a los niveles de alumno y alumno por año académico. Como no fueron incluidos explícitamente en los archivos de texto fuente de las medidas correspondientes esto debe indicarse al diseñar el modelo en O3, mediante la utilización de tablas locales y campos virtuales. En la figura 29 se puede apreciar la definición de la tabla local con los datos de las personas que se utilizan para desnormalizar las otras tablas de hechos. Figura 29. Tabla local TPersonas. Incluye datos como sexo, nacionalidad, colegio secundario, etc. que podrán obtenerse a partir de la combinación de unidad académica y número de inscripción. En la figura 30 se muestra la definición del campo NACIONALIDAD como campo virtual. Esto se utiliza para incorporar ese dato en los niveles de granularidad alumno y alumno en año académico correspondientes a las otras tablas de hechos. 35 El detalle de las posibles combinaciones del alcance de las medidas es específico de la herramienta y queda fuera de este trabajo. 91

92 Capítulo 5 Presentación de la solución Figura 30. Recuperación del valor correspondiente a NACIONALIDAD mediante de la definición de un campo virtual. Esto se utiliza cuando el campo no está en la fuente de datos (caso de int_dw_alumnos e int_dw_desercion_alumnos_anio) En la figura 30 también se puede observar que los campos virtuales pueden ser utilizados con otros propósitos: para calcular valores derivados a partir de los datos fuentes (ejemplo: EDAD_IngrUniv ), para indicar valores por defecto para el caso de nulos ( DV_COLEGIO y otros), entre otros posibles usos, como definición de medidas, definición de descripciones a partir de más de un campo, etc. 5.5 Personalización del proceso ETL El ejemplo elegido consta de tres niveles diferentes de definición de tablas de hechos. El proceso de extracción consiste principalmente en la creación de esas tres tablas, las cuales se construyen de la siguiente manera: En la tabla de alumno por año, se crea un registro para cada año por cada individuo que tiene actividad académica en cada carrera, comenzando por el año de ingreso de esa persona a la universidad hasta el año académico corriente. Para cada alumno (persona en una determinada carrera) se cuenta la cantidad de cursados aprobados, cantidad de cursados desaprobados, cantidad de finales aprobados, entre otras cosas, durante cada año académico y se agrega el registro a la tabla si alguna de esas cuentas es diferente a cero. La tabla de hechos de alumnos, recopila información del alumno dentro de la carrera: año de ingreso a la carrera, datos del plan y cantidades totales de cursados, finales y equivalencias, desde el ingreso a la carrera hasta la fecha. Para calcular estas cantidades se realiza una suma sobre los datos de la tabla anterior a través de los distintos años. La tabla de hechos de personas también calcula las cantidades de materias como suma, en este caso a partir de la tabla de alumnos. Se consideran todas las carreras en las que es alumno36. Además en esta tabla se definen otros atributos de las personas que se representan 36 Tener en cuenta que las materias comunes se contarán dos veces, dependiendo de cómo se estén registrando en el SIUGuaraní, seguramente se cuente como materia aprobada en una carrera y como equivalencia en la otra. 92

93 Capítulo 5 Presentación de la solución como dimensiones (sexo, edad, procedencia, etc.). Los procesos de creación de las tablas y llenado de las mismas se adjuntan en el apéndice. Para este caso práctico la transformación de datos es casi nula y se incluye como parte del proceso de extracción. Esto es debido a que, por el momento, no se implementa la arquitectura completa de un proyecto de DW y no se dispone de un espacio especial para esta tarea. Una de las recomendaciones básicas es la creación de claves sustitutas. Esto no se realiza por los siguientes motivos: La fuente de datos es única. No se implementa por ahora la etapa de limpieza y transformación de datos, dejando esta tarea para desarrollo futuro. Utilizar los códigos originales facilita el control de datos extraídos y sirve para mejorar la calidad de los datos del sistema de gestión. En este caso práctico tampoco es posible ejemplificar algunas consideraciones respecto a la integración de datos, porque estos son extraídos de un único sistema fuente donde ya se encuentran integrados. 5.6 Problemas de calidad de datos Los problemas de calidad pueden manifestarse en tres lugares diferentes y serán evidenciados cuando el cubo esté generado. Será necesario testear adecuadamente: el estado de los datos en la fuente, el proceso ETL y la definición del modelo del cubo para asegurarse que la solución es correcta. Si la calidad de datos en el origen no es buena no habrá mucho que se pueda hacer. De todas formas durante los procesos de extracción, transformación y carga de datos podrán tomarse algunas decisiones que resuelvan los problemas de calidad de diferentes formas. Por ejemplo se puede decidir descartar un registro que contenga algún campo nulo, o rellenarlo con algún valor por defecto. Lamentablemente la mayoría de los problemas se hacen evidentes al generar el cubo con información real, ya que es difícil contemplar todas las posibles anomalías que podrían presentar los datos. Lo más sencillo y útil es examinar los datos reales y los problemas de calidad que presentan y dedicarse a solucionarlos. En lugar de pensar todas las posibles inconsistencias que podrían existir, trabajar sobre las pocas o muchas que realmente surjan. Controles en la definición del modelo y la generación del cubo De los controles a realizar el más sencillo es sobre la definición del modelo del cubo. Una vez generado el cubo hay que controlar que todo el contenido de los archivos de texto haya sido 93

94 Capítulo 5 Presentación de la solución incorporado para la visualización final del usuario. El log de la generación registrará errores y advertencias que serán de utilidad. Debe controlarse: Cada medida. En este caso la cantidad de registros de cada archivo de tabla de hechos debe ser igual a la cantidad total de la medida correspondiente en el cubo. Si no coincide, puede ser que haya registros que por algún motivo se hayan excluido. Posiblemente el motivo de exclusión sea algún campo nulo, o no existente en otra tabla (falta de integridad referencial entre los datos). Si hubiese otras medidas además de cantidades, debieran controlarse al menos que los totales de los valores coincidan. Cada dimensión. Puede ocurrir que falten valores en las tablas de dimensiones o existan códigos no adecuados en las tablas de hechos. Estos casos podrán visualizarse al desplegar los valores de las dimensiones utilizando la interfaz de acceso al cubo. También debe controlarse que las dimensiones contengan los valores adecuados, y descartar así posibles errores en la definición del modelo: al asociar los campos, las claves, las descripciones, definir niveles únicos, etc. Suele ocurrir que valores diferentes coinciden en la descripción y entonces es necesario utilizar también el código para diferenciar estos casos. Controles en los procesos de extracción y transformación de datos Respecto al proceso ETL se requiere un riguroso testeo sobre los datos aportados al DW. Hay que tener cuidado de no descartar datos sin la intención explícita de hacerlo y testear cuidadosamente la lógica utilizada para la extracción. De todas formas es conveniente chequear las cantidades del cubo con reportes y otras consultas provenientes del/los sistemas de gestión correspondiente. Si existiese un área de transformación de datos sería necesario tomar algunos indicadores generales (totales de registros, totales de campos nulos o con valores incorrectos, cantidades de valores posibles, etc.) en las fuentes de datos y en diferentes niveles de los procesos de transformación para asegurarse que los datos van evolucionando de forma adecuada y no se pierden valores. Problemas de calidad en el origen del dato Por último, el cubo puede presentar inconsistencias o anormalidades provenientes del sistema de gestión. En este caso si el SIUGuaraní se usa correctamente y con los controles necesarios activados no existirán estos problemas en la base de datos. Sin embargo en muchas ocasiones se descubren datos inconsistentes y/o falta de información en el sistema de gestión. 94

95 Capítulo 5 Presentación de la solución Estas situaciones se deben generalmente a procesos de migración de información de otro sistema que se incorpora al SIUGuaraní con controles desactivados o en forma incompleta. También existe información incompleta cuando se decide no ingresar al sistema datos no imprescindibles, o datos no obligatorios o desconocidos que son dejados en blanco o completados con datos incorrectos. Estos casos suelen ser detectados más tarde a partir de la observación de los valores de las dimensiones del cubo y los cruces de variables permitidos. Por ejemplo, edades fuera de rangos razonables indican que la fecha de nacimiento de las personas que figura en la base de datos no es correcta. Datos de procedencia desconocida surge del hecho que el colegio secundario no esté cargado para muchas personas. Otro caso que podría ocurrir es alumnos que tuviesen actividad académica anterior al año de ingreso37. Todos estos casos son ejemplos de la retroalimentación que generan las soluciones para análisis de datos en los sistemas operacionales. Debieran ser corregidos en el sistema operativo de origen y luego regenerar el cubo con la información correcta. 37 En este trabajo estos casos se descartan antes, directamente no se los extrae de la fuente de datos. 95

96 Capítulo 6 Uso de la herramienta y análisis de datos 6 Uso de la herramienta y análisis de datos Una vez generado, el cubo se encuentra en condiciones de ser consultado 38. Podrá accederse como archivo local directamente utilizando el O3 Browser (abrir el archivo dm_desgranamiento_alumnos.cube desde la ubicación correspondiente) o publicarse en el servidor de O3 y accederse a través de las interfaces que se hayan instalado (escritorio o web) y con los permisos que pudiesen haberse configurado39. Este capítulo tiene el propósito de mostrar la funcionalidad básica de la herramienta y algunos ejemplos de las amplias posibilidades de análisis brindadas por el cubo diseñado. Los datos sobre los cuales se trabaja son inventados, no son reales. Han sido generados para poder ejemplificar algunas cuestiones y pueden presentar inconsistencias propias de no provenir de una base de datos real de SIUGuaraní. 6.1 Acceso al cubo y operaciones básicas Acceso al cubo y vista inicial Al abrir el cubo se obtiene la vista inicial, consistente de la medida Cant Personas y las dimensiones Unidad Académica y Año Ingreso (en el nivel Año Ingreso a la Universidad ). Figura 31. Vista inicial predeterminada del cubo dm_desgranamiento_alumnos generado con datos de prueba. Observaciones: en el ejemplo se consideraron datos de una facultad solamente En la sección 8.4 del apéndice se explica cómo generar el cubo. En los ejemplos de este trabajo se accede con la interfaz de escritorio de forma local. 96

97 Capítulo 6 Uso de la herramienta y análisis de datos Existen datos con problemas de calidad, no debieran existir casos con año de ingreso en 0. Esta consulta es la forma de acceso al cubo predeterminada y queda definida por el cruce de las dos primeras dimensiones del modelo y la primera medida, sin ningún filtro. A partir de esta vista puede navegarse el cubo. Es posible regresar a la misma desde el menú Explorar Vista inicial o con el botón de acceso rápido. Los usuarios pueden confeccionar reportes o vistas propias para consultas frecuentes y utilizarlas para acceder al cubo en lugar de hacerlo mediante la vista inicial predeterminada. Estas vistas pueden contener filtros, otro tipo de gráfico, fórmulas calculadas, muchas dimensiones y medidas. A partir de ellas también es posible navegar el cubo, pudiendo retornar al punto de partida con la opción de vista inicial. Operaciones básicas de consulta Las operaciones más comunes y sencillas sobre los datos consisten en: reemplazar o agregar dimensiones a una consulta, seleccionar diferentes medidas, realizar filtros y desagregar información. Selección de dimensiones La selección se realiza arrastrando la dimensión deseada al gráfico, superponiéndola con la que se quiere reemplazar. Cuando esta operación se realiza en el modo gráfico la dimensión a ser reemplazada se colorea de amarillo en el momento en que se debe soltar el arrastre del ratón. Figura 32. Ejemplo de reemplazar la dimensión Unidad Académica por Sexo en la consulta, para obtener Cant Personas por Año de Ingreso (a la Universidad) y Sexo. 97

98 Capítulo 6 Uso de la herramienta y análisis de datos Al trabajar en el modo grilla la dimensión a reemplazar se colorea de gris. En este caso es posible no sólo reemplazar dimensiones existentes en una consulta sino también agregar, creando así tablas con más de una variable en las filas y/o en las columnas. El lugar donde se insertará la dimensión que se incorpora a la consulta es señalado con una barra amarilla. Es posible cambiar el orden de presentación arrastrando las dimensiones dentro de la tabla. Para pasar del modo gráfico a grilla usar la opción Desplegar tabla del menú Ver, o el botón de acceso directo. Figura 33. Ejemplo de consulta en formato de tabla utilizando muchas dimensiones. Selección de medidas Es posible cambiar cualquier medida simplemente desplegando el listado correspondiente y eligiendo la deseada. También pueden utilizarse las medidas dentro de la visualización de la consulta, como si fuesen los valores de una dimensión. Esta opción generalmente se utiliza para comparar medidas. En las figuras 34 y 35 pueden apreciarse ejemplos en modo gráfico y grilla respectivamente. 98

99 Capítulo 6 Uso de la herramienta y análisis de datos Figura 34. Comparación de Cant Personas vs. Cant Alumnos abierto por Sexo. Figura 35. Comparación de medidas Cant Personas y Cant Alumnos, discriminadas por Año de Ingreso (a la universidad) y Sexo. Visualización en formato de grilla. Desagregar información y filtrar Se puede acceder a un nivel de información desagregado haciendo clic sobre el valor deseado, o seleccionándolo de la lista desplegable de la dimensión (siempre que forme parte de la consulta y se utilice la opción por defecto Explorar hijos ). 99

100 Capítulo 6 Uso de la herramienta y análisis de datos Si el nivel consultado es el último, el más detallado, dentro de la jerarquía de la dimensión, la operación de desagregación no muestra nuevos valores, sino que actúa como un filtro sobre la consulta anterior, dejando visible sólo el valor elegido. Figura 36. Izquierda: filtro a partir de figura 35, seleccionando el valor Mujeres en Sexo. Gráficos restantes: drill down sobre valores de la dimensión Procedencia, eligiendo país Argentina y luego provincia San Juan. Los filtros también pueden realizarse sobre valores de dimensiones que no estén siendo visualizadas en la consulta corriente. Los filtros que se efectúen modificarán los resultados actuales. No hay que perderlos de vista al momento de interpretar los valores mostrados en las consultas para evitar confusiones. También es posible seleccionar más de un valor de las dimensiones eligiendo la opción de lista de elementos. Y se puede consultar el desgranamiento de más de un valor al mismo tiempo, lo que significaría un múltiple drill down. Para esto la herramienta propone las opciones expandir todos los hijos, expandir todo el nivel, explorar nivel y mostrar nivel. Figura 37. Izquierda: filtro de lista de elementos para los años de ingreso 2000 a Derecha: Drill down de más de un elemento utilizando la exploración por niveles (opción: expandir hijos) 100

101 Capítulo 6 Uso de la herramienta y análisis de datos Para volver al nivel anterior (drill up) hay que seleccionar el valor correspondiente en la dimensión (el padre, un nivel más arriba), asegurándose de tener la opción de visualización por defecto ( explorar hijos, no lista de elementos ). La opción atrás es también útil muchas veces para retornar a consultas anteriores. 6.2 Un ejemplo de análisis sobre evolución de la matrícula Una de las temáticas a abordar con la información contenida en el caso práctico es la evolución de la matrícula. En esta sección se muestra como analizar las variaciones sobre la cantidad de alumnos en los últimos diez años. Se comienza con una consulta general y se va profundizando en subconsultas sobre los casos más llamativos. El ejemplo es a modo de guía, pudiéndose retomar consultas intermedias y seguir analizando sobre otras alternativas. En toda la sección 6.2 se consideran sólo las personas inscriptas en una única carrera para simplificar la interpretación de los gráficos y las consultas. Es decir que siempre se asume el filtro de cantidad de carreras inscripto igual a uno en las consultas40. Cantidad de alumnos por año académico Para comenzar se evalúa la cantidad de alumnos por cada año académico41. Partiendo de la vista inicial del cubo seleccionar la medida de cantidad de alumnos por año académico ( Cant Alum Año c/activ ) y arrastrarla al gráfico en el eje, en lugar de Unidad Académica. Luego reemplazar la dimensión Año de Ingreso por Año Informado y seleccionar los años académicos que resulten de interés, por ejemplo los últimos diez. 40 Al filtrar a las personas inscriptas sólo en una carrera coinciden la cantidad de alumnos con la cantidad de personas, el año de ingreso a la carrera con el año de ingreso a la universidad y todos los datos agregados de totales de materias y demás. 41 Se cuentan sólo a los alumnos que presentan algún tipo de actividad, considerando como actividad el hecho de realizar una inscripción (sea a cursado, examen o carrera). 101

102 Capítulo 6 Uso de la herramienta y análisis de datos Figura 38. Cantidad de alumnos por año académico en que presentan actividad, para los años En el gráfico de la figura 38 se puede observar que el crecimiento más importante en la matrícula ocurre en el año También se ve claramente un descenso importante en el año 2006, el último año considerado para este cubo. Es muy importante que el analista de información tenga en cuenta el contexto de los datos. En este caso ocurre que la información correspondiente al último año no está completa, y ese es el motivo que explica la diferencia. Posiblemente lo más conveniente sea descartar este año al hacer análisis comparativos. También al generar el cubo habrá que considerar si el último año académico ya está cerrado o no. Otra característica importante a tener en cuenta refiere a la migración de datos. Puede ser que la política de migración de datos al SIUGuaraní no incluya la totalidad de datos antiguos, y por ejemplo quienes ya hubiesen egresado al momento de implementar este sistema no se hayan migrado, presentando así grandes diferencias en el volumen de la información y en el rendimiento de los alumnos. Retomando el ejemplo del gráfico, se podría sospechar que la matrícula del año 2000 presente un pico justificado por un incremento en la cantidad de ingresantes (por ejemplo provocado por el inicio de una nueva carrera). Siguiendo esta hipótesis en la figura siguiente se muestra la apertura de los alumnos según el año de ingreso a la carrera y se calcula el porcentaje que representan los ingresantes sobre la totalidad de alumnos de cada año académico. Figura 39. Apertura de cantidad de alumnos por año con actividad según año de ingreso a la carrera. 102

103 Capítulo 6 Uso de la herramienta y análisis de datos Porcentaje correspondiente a los ingresantes sobre el total de alumnos de cada año académico. En la gráfica se observan dos ventanas con la misma vista para mostrar parte de los años En la figura 39 para cada año académico de la dimensión Año Informado se calculó el porcentaje correspondiente a los ingresantes. Se puede observar que este dato representa casi un 35% del total del alumnado en el año 2000, mientras que en el resto de los años se mantiene alrededor de un 20%. La fórmula utilizada para el cálculo del porcentaje42 respeta la sintaxis requerida por la herramienta y consiste en sumar los valores de año de ingreso a la carrera coincidentes con el año informado y calcular el porcentaje sobre el total, para cada año académico. Por lo tanto en este caso se valida la hipótesis de que el incremento en la cantidad de alumnos en el año 2000 se debe a un aumento en la cantidad de ingresantes (y no de reinscriptos). Otra forma de visualizar esta información puede ser mediante la consulta de la figura siguiente, donde se permite ver el cruce de todos los años de forma más compacta, facilitando la comparación. Figura 40. Porcentaje de cada cohorte sobre el total de alumnos de cada año académico. El gráfico se obtiene colocando la dimensión año de ingreso como columna y utilizando la opción desplegar porcentajes por fila en lugar de utilizar una función calculada como es el caso de la figura anterior. En la figura 40 se puede detectar una influencia importante de la cohorte 2000 en los años siguientes, en comparación con las restantes. Análisis de ingresantes Ahora se podría continuar el análisis haciendo hincapié en los ingresantes y prestando especial atención a la cohorte Informado") == Etiqueta([this.leaf(i)],"Año Ingreso"))? [this.leaf(i)] : 0)*100 /["Total"] 103

104 Capítulo 6 Uso de la herramienta y análisis de datos Sobre la vista inicial del cubo elegir la medida Cant Alumnos, y seleccionar para la dimensión Año Ingreso los valores que interese evaluar, por ejemplo de 1996 a Si hubiese más de una facultad se podría seleccionar una. Siempre es importante seleccionar la medida adecuada para evitar confusiones posibles y cruces de variables no válidos. En las gráficas siguientes se utiliza la medida Cant Alumnos, que es diferente a la de las figuras anteriores, Cant Alum x Año c/activ, donde se reflejaba la relación muchos a muchos entre alumnos y años académicos en que tienen actividad. En la gráfica de la figura 41 se observa que hubo un pico de ingresantes en el año 2000 superando por más del doble a los años precedentes. La cantidad de alumnos que ingresaron a las diferentes carreras cayó notoriamente en los años siguientes. Se observa que del año 2000 en adelante fue disminuyendo, presentando un descenso importante en el año Figura 41. Evolución de ingresantes en los últimos 11 años para la facultad 1. Para el gráfico se usaron las opciones de lista de elementos para filtrar los valores de la dimensión Año Ingreso, intercambiar ejes y mostrar valores 43. Se puede hacer la apertura por carrera dentro de esa facultad intentando explicar las subas y bajas. Es necesario reemplazar la dimensión Unidad Académica por Carrera. La gráfica se muestra en modo tabla en la figura siguiente. 43 Los años se muestran en el orden en que se los tilda, que se puede cambiar. 104

105 Capítulo 6 Uso de la herramienta y análisis de datos Figura 42. Comparación de Ingresantes por cohorte y carrera. De la figura 42, se observa que muchas carreras son despreciables en cuanto a la cantidad que aportan al total de ingresantes. También se observa que en el año 2000 se abrió la inscripción a la carrera 08 (anteriormente no tiene ingresantes) lo que en principio justifica el pico de ingresos en ese año. En la figura 43 se muestra el gráfico de barras comparativo de las tres carreras con mayor cantidad de ingresantes en cada año. Figura 43. Evolución de ingresantes de las carreras 07, 08 y

106 Capítulo 6 Uso de la herramienta y análisis de datos Se podría corroborar que el incremento de ingresantes en el año 2000 se debe al comienzo de la carrera 08 seleccionando dicha carrera y consultando también el año de egreso del secundario de los ingresantes. Luego, calcular el porcentaje de alumnos correspondiente a cada año de egreso del secundario sobre el total de la cohorte, definiendo una fórmula como la mostrada en la figura 44. Figura 44. Ingresantes a la carrera 08 según año de egreso del secundario, y fórmula de porcentaje sobre total de alumnos de la cohorte. Observando los diferentes años (figura 45) se puede ver que en general alrededor del 40% de los ingresantes de cada cohorte finalizan el secundario el año anterior al que comienzan la carrera universitaria. En el año 2000 los porcentajes son muy diferentes, la cantidad de alumnos que terminaron el secundario en el año 1998 es equivalente a aquellos que lo hicieron en 1999, mientras que para los demás años la relación suele ser equivalente a la mitad. 106

107 Capítulo 6 Uso de la herramienta y análisis de datos Figura 45. Análisis de ingresantes por cohorte y año de egreso del secundario para la carrera 08 y los años 2005, 2004, 2001 y Seguimiento de una cohorte Puede resultar interesante seleccionar esa cohorte (año de ingreso = 2000) y analizar qué sucedió con esos ingresantes, particularmente evaluar y comparar a quienes egresaron del secundario en 1998 y Se podría tener por ejemplo la sospecha que quienes esperaron un año para poder ingresar a la carrera estarían más seguros y entusiasmados en su decisión de estudiar; su rendimiento académico y su perseverancia podría superar a los ingresantes recién salidos del secundario. Una posible consulta a realizar es la apertura de estos alumnos según el último año en que registran actividad (inscripción a cursado o examen en alguna materia de la carrera) y según si han egresado o no (usando la dimensión cantidad de carreras egresado ). El gráfico de la figura 46 se obtiene seleccionando el valor 2000 en año de ingreso, 1998 y 1999 en año de egreso del secundario (usando la opción de listas de elementos ), cambiando la ubicación de la dimensión año de egreso del secundario, para facilitar la comparación, y arrojando al gráfico las dimensiones último año con actividad y cant carreras egresado. 107

108 Capítulo 6 Uso de la herramienta y análisis de datos Figura 46. Ingresantes a la carrera 08 de la cohorte Comparación de alumnos que terminaron el secundario en 1998 vs. quienes lo hicieron en 1999, según último año de actividad en la carrera y si egresaron o no. Los casos que presentan último año con actividad en cero es porque nunca tuvieron actividad en la carrera. Egresado hay sólo un caso; se puede quitar ese nivel de detalle porque no aporta información significativa. También es interesante ver los porcentajes en lugar de los números (figura 47. Utilizar la opción desplegar porcentajes en columnas dentro del menú Explorar ). Figura 47. Consulta de la figura 46 quitando apertura por cantidad de carreras en que egresó y desplegando porcentajes en las columnas. Esta información puede visualizarse también de modo gráfico. Para lograr mayor legibilidad en la lectura es conveniente quitar las dimensiones que están mostrando un único valor 108

109 Capítulo 6 Uso de la herramienta y análisis de datos en el resultado (en este caso año de ingreso y carrera ) y también la fila totalizadora. En las figuras 48 y 49 se aprecian diferentes visualizaciones de la misma consulta. Figura 48. Comparación en modo gráfico de ingresantes a la carrera 08 en el año 2000 según si egresaron del secundario en 1998 o Apertura según último año con actividad. Vista de porcentajes sobre valores del eje. Figura 49. Diferentes visualizaciones gráficas sobre la consulta de la figura 48. En el caso de los gráficos de torta se observa sobre la parte inferior del lateral derecho la dimensión que en la tabla aparecía como columna. De las figuras anteriores se puede concluir que la hipótesis planteada para estos casos sobre la influencia del año de egreso del secundario en la perseverancia en la carrera no sería cierta, ya que en general quienes ingresaron en 1999 tienen actividad durante más tiempo. 109

110 Capítulo 6 Uso de la herramienta y análisis de datos De todas formas para realizar un análisis más profundo habría que evaluar la calidad de la actividad tenida. También hay que tener en cuenta que los datos mostrados son ejemplos no reales y es probable que muestren comportamientos que no sean ciertos. En la figura 50 se muestran cuadros de comparación entre los ingresantes del año 2000 a la carrera 08 que egresaron del secundario en los años 1998 y 1999 según algunas variables totalizadoras de rendimiento académico. En el ejemplo se observa que en general quienes egresaron del secundario en 1999 tienen mejor desempeño académico. Figura 50. Ingresantes a la carrera 08 de la cohorte Comparación de alumnos que egresaron del secundario en el año 1998 y 1999 según totalizadores de cantidad de finales aprobados, cantidad de cursados aprobados y cantidad de cursados promovidos. 6.3 Ejemplos de análisis de procedencia Otra temática que resulta interesante analizar es la procedencia de los alumnos. La procedencia se considera a partir del colegio secundario y presenta los niveles: localidad, provincia y país. En general interesa llegar al máximo detalle para encontrar la articulación entre los diferentes colegios secundarios y las carreras de la universidad. 110

111 Capítulo 6 Uso de la herramienta y análisis de datos En esta sección se muestran algunos ejemplos interesantes y otras consultas más generales, que se utilizan para explicar funcionalidades de la herramienta y como guía para la obtención de otras nuevas. Análisis a nivel de país y calidad de datos En la figura 51 se observa el análisis de procedencia a nivel de país, para las cohortes , evaluando cantidad de personas y cantidad de alumnos. Para obtener el gráfico, partiendo de la vista inicial del cubo, es necesario: pasar al modo grilla, arrastrar las medidas al gráfico reemplazando la dimensión Unidad Académica, seleccionar la medida Cant Alumnos (además de la ya elegida por defecto), seleccionar los años de ingresos deseados, arrojar la dimensión Procedencia como parte de las filas y agregar los totales por año. Figura 51. Análisis de procedencia a nivel país para las cohortes (considerando año de ingreso a la universidad, que es el nivel comparable por ambas medidas), comparando cantidad de personas con cantidad de alumnos. La evaluación de la procedencia se ve afectada por la mala calidad de los datos. El dato de colegio está sin completar en muchos casos y en otros no está asociado a la localidad que le corresponde. El porcentaje de datos sin completar, que puede apreciarse claramente en la figura 52, es mayor con el correr del tiempo. Esto es preocupante ya que en general la calidad de los datos debiera tender a mejorar. 111

112 Capítulo 6 Uso de la herramienta y análisis de datos Figura 52.Visualización diferente de la información de la figura 51 cambiando la ubicación de las dimensiones y usando porcentajes por fila para resaltar la falta de completitud de los datos. Exploración de los niveles de la dimensión procedencia Al seleccionar un valor de país (por ejemplo haciendo clic sobre Argentina ) se visualiza el nivel siguiente en la jerarquía. Los valores de la dimensión conforman un árbol con diferentes niveles. Se pueden consultar por ramas o por nivel, de a uno o más elementos. Figura 53. Análisis de procedencia para país Argentina de las cohortes Apertura de provincias y localidades. 112

113 Capítulo 6 Uso de la herramienta y análisis de datos En la figura 53 se observan los valores de los niveles provincia y localidad correspondientes al país Argentina. La forma utilizada ( Expandir todos los hijos sobre el nivel provincia ) permite ver los subtotales por provincia. Los datos utilizados en el caso práctico no tienen variaciones importantes en cuanto a provincia de procedencia. El análisis por colegio secundario también es posible, a través de la opción de visualizar todo ese nivel (se visualizan todos los colegios de todas las localidades de todas las provincias y países), o eligiendo una localidad. La figura 54 surge de seleccionar una localidad en la consulta anterior, pasar la dimensión Año Ingreso a las columnas y agregar totalizadores. Figura 54. Procedencia de personas y alumnos de las cohortes 2000 a Consulta a nivel de colegio secundario para la localidad de SAN JUAN. En la figura anterior se puede observar la existencia de comillas en la descripción de los colegios. Este es un problema menor de calidad de datos que habría que resolver, modificando las descripciones en el sistema SIUGuaraní. Articulación de colegios y carreras Es interesante conocer la relación entre los colegios de procedencia de los alumnos y las carreras que eligen. Para esto es necesario seleccionar la medida Cant Alumnos (ya que Cant Personas queda indefinida a nivel de carrera y utilizar la dimensión Carrera como parte de la consulta. Esto se muestra en la figura

114 Capítulo 6 Uso de la herramienta y análisis de datos Figura 55. Apertura por carrera de alumnos correspondientes a las cohortes procedentes de los diferentes colegios secundarios de la localidad de SAN JUAN. Este mismo análisis podría realizarse para todos los colegios de una provincia, por ejemplo, usando las diferentes opciones avanzadas de exploración de la dimensión Procedencia. También es posible tomar a la carrera como el punto de partida para el análisis, para investigar de donde provienen los alumnos de determinadas carreras. En la siguiente figura se muestra el ranking de colegios secundarios para los ingresantes del año 2005 a la carrera 10. Figura 56. Procedencia de ingresantes 2005 a la carrera 10. Ranking de colegios secundarios. 114

115 Capítulo 6 Uso de la herramienta y análisis de datos Para obtener el gráfico de la figura 56 se debe seleccionar la medida Cant Alumnos, la carrera y el año de ingreso. Respecto a la dimensión Procedencia se debe elegir la opción de Explorar nivel, seleccionar Colegio y luego Mostrar nivel y tildar todas las opciones que se deseen visualizar. Por último para mostrar ordenado en forma descendente se debe acceder a la opción Ranking dentro del menú Explorar y elegir de ordenar la dimensión Procedencia por criterio descendente según la medida corriente. Aperturas por las otras dimensiones también están permitidas. Sexo, Edad, Cant carreras inscriptoactivo y todas las dimensiones referentes al rendimiento académico de esos alumnos pueden resultar interesantes. La figura 57 muestra un cuadro que podría obtenerse combinando totales de cursados promovidos y finales aprobados. Se utiliza una regla para señalizar los valores diferentes a cero, para facilitar el análisis44. Figura 57. Posible análisis de rendimiento académico de los alumnos discriminado por colegio de procedencia. A partir de la figura 56 se incorporan las dimensiones Cursados Promovidos y Finales Aprobados en su nivel más alto. Se visualiza sólo el nivel Colegio en la dimensión Procedencia y se utiliza la opción de desplegar porcentajes por fila. Análisis similares pueden realizarse eligiendo algún colegio y consultando en qué carreras influye, comparando la procedencia en los diferentes años, etc. También es posible comparar el rendimiento académico de los alumnos, principalmente durante el primer año de la carrera y relacionarlo con el colegio del que provienen. Puede ser que determinados colegios con formación más afín respecto a la carrera tengan una influencia positiva en el rendimiento académico de los alumnos, o que no resulte lo esperado. 44 La definición de reglas con O3 queda fuera del alcance de esta tesis. Consultar la documentación de la herramienta. 115

116 Capítulo 6 Uso de la herramienta y análisis de datos 6.4 Un ejemplo de desgranamiento basado en la actividad académica y rendimiento El desgranamiento generalmente es evaluado por cohortes. Este análisis comienza a partir de los individuos, el año de ingreso a la universidad y se realiza un seguimiento de los años en que han tenido actividad. En este caso se inicia la exploración a nivel de personas y no a nivel de alumno. Luego se desgrana la información por alumno. Último año con actividad El cuadro de la figura 58 muestra el año de ingreso y el último año con actividad para la medida Cant Personas. Se puede observar que hay una cantidad importante de inscriptos que no tienen actividad académica en ningún año, reflejados por último año con actividad igual a cero. Figura 58. Cantidad de personas por año de ingreso, discriminados según el último año de actividad. Los subtotales muestran la cantidad de personas que ingresaron a la universidad en cada año. La misma información puede visualizarse de otra manera en la figura siguiente, en cantidades absolutas y también en porcentajes sobre el total de cada cohorte Se utiliza el término cohorte para referirse al año de ingreso, a la universidad, o a la carrera. Aunque en general el uso más común es el segundo ambos son aceptables. Además, la mayoría de las personas se inscriben sólo a una carrera, por lo tanto los valores suelen ser coincidentes. 116

117 Capítulo 6 Uso de la herramienta y análisis de datos Figura 59. Cantidad de personas por año de ingreso y año de última actividad, en cantidades absolutas y en porcentajes sobre el total de la cohorte. Personas y alumnos La relación entre Cant Personas y Cant Alumnos depende de la cantidad de carreras en que se haya inscripto cada individuo. Así quienes se anotan sólo en una cuentan una vez como persona y una vez como alumno. En estos casos, el año de ingreso a la universidad coincide con el año de ingreso a la carrera, y también coinciden los totalizadores de rendimiento académico. Mientras que quienes se hayan inscripto en más de una carrera presentan diferencias según el nivel en que se analice la información. En este trabajo la actividad anual se calcula sólo a nivel de alumno (medida Cant Alum Año c/activ ), por eso es necesario evaluar la relación entre personas y alumnos como paso intermedio al intentar evaluar el rendimiento anual. En la figura 60 se puede observar la relación entre personas y alumnos a partir de la cantidad de carreras en que se inscriben, y las diferencias al considerar el año de ingreso a la universidad y el año de ingreso a la carrera. 117

118 Capítulo 6 Uso de la herramienta y análisis de datos Figura 60. Comparación de Cant Personas y Cant Alumnos. Apertura por Cant carreras inscripto y Año de Ingreso, a la universidad y a la carrera. Cuadros similares a los de la sección podrían armarse eligiendo cantidad de alumnos por ultimo año de actividad en la universidad y también por último año de actividad en la carrera. En la figura 61 se muestra la apertura de ambas medidas según el año de ingreso a la universidad y el último año con actividad en esta. Figura 61. Cant Personas y Cant Alumnos según Año Ingreso a la universidad y 118

119 Capítulo 6 Uso de la herramienta y análisis de datos Último año con actividad en la universidad Actividad anual de las cohortes Además de la apertura por último año con actividad es interesante evaluar la actividad en cada año. Eso es posible consultando la cantidad de alumnos por año académico en que realizan alguna actividad y comparando el valor con la cantidad de alumnos. Para esto es necesario utilizar la medida Cant Alum Año c/activ que cuenta a cada alumno tantas veces como años en los cuales realiza alguna actividad académica, y realizar la apertura por la dimensión Año Informado. Los valores mostrados en la figura 62 deben ser analizados en función de la cantidad de alumnos mostrada en la figura 61, Por ejemplo: de los 12 alumnos (correspondientes a 10 personas) que ingresaron en 1994 y tuvieron actividad por última vez en el año 2001 (fila 9 de la figura 61), 10 de ellos tuvieron actividad académica en 1994, 1995, 1996 y 2001, equivalentes al primer, segundo, tercer y octavo año de las carreras, respectivamente. 9 de ellos tuvieron actividad durante los años 1997, 1998 y 1999, y sólo 7 tuvieron actividad en el año 2000 (filas 3 a 10 del cuadro de la derecha de la figura 62). Figura 62. Alumnos por año académico en que presentan actividad. Apertura por año de ingreso a la universidad y último año con actividad. Contrastar con la cantidad de alumnos de la figura 61. Resulta interesante calcular el porcentaje de alumnos de cada cohorte que tienen actividad en cada año académico. La figura 63 se logra a partir de la anterior, quitando la dimensión Último año con actividad y filtrando algunos valores de Año Informado para obtener un gráfico más simple. La medida Cant Alumnos está indefinida por Año Informado, por eso muestra siempre el total de alumnos de cada año de ingreso Es intencional y es la forma que presenta O3 para permitir la comparación de estas medidas por Año Informado. Hay otras formas de obtener el dato del porcentaje a partir de otras vistas que requieren fórmulas de cálculo o diseño del modelo más complejos. 119

120 Capítulo 6 Uso de la herramienta y análisis de datos Figura 63. Porcentaje de alumnos con actividad calculado sobre el total de ingresantes de la cohorte. Seguimiento de una cohorte Se puede seguir profundizando en conjunto o seleccionar una cohorte que resulte de interés, por ejemplo la cohorte 1997 que al año 2006 lleva 10 años dentro de la universidad y tiene un total de 380 ingresantes (observar en figura 60, total de Cant Alumnos con año de ingreso a la universidad 2007 o total de figura 65)47. Figura 64. Cantidad de alumnos de la cohorte 1997 que tienen actividad en cada año académico. 47 Se considera como cohorte al año de ingreso a la universidad para que los ejemplos sean más sencillos. También podría tomarse el año de ingreso a la carrera. Incluso si resultara complejo seleccionar los valores podría modelarse el año de ingreso a la carrera como una dimensión independiente. 120

121 Capítulo 6 Uso de la herramienta y análisis de datos La actividad anual de los 380 ingresantes puede verse en el gráfico de la figura 64. Es muy interesante observar como en este caso se va perdiendo la cantidad de alumnos a medida que pasan los años. Esto puede deberse a diferentes motivos: que abandonan sus estudios, que se cambian de carrera, o que egresan. Se puede discriminar a estos alumnos por otras variables para estudiar la cohorte en detalle. En la figura 65 se observa el total de alumnos de la cohorte 1997 según el último año en que realizan actividad académica en la carrera y en la universidad y su calidad de egresados. Sobre el total de 380 ingresantes 10 son egresados en alguna carrera y 129 nunca tuvieron actividad en la carrera (se obtiene sumando todos los casos con último año con actividad en la carrera igual a cero), de los cuales 116 no tuvieron actividad en ninguna carrera, los otros 13 sí. Figura 65. Cantidad de alumnos de la cohorte 1997 según último año con actividad (en la universidad y en la carrera) y su calidad de egresado (dado por el valor de cantidad de carreras egresado igual a uno) 121

122 Capítulo 6 Uso de la herramienta y análisis de datos Figura 66. Cantidad de alumnos y de personas que ingresaron en 1997 discriminadas por último año en que registran actividad (en la universidad solamente para simplicidad del gráfico), cantidad de carreras en que se encuentra activo / cantidad de carreras en que se inscribió y cantidad de carreras en que egresó. Para evaluar el movimiento a otras carreras se puede comparar la cantidad de alumnos con la cantidad de personas y discriminar ambas medidas por la cantidad de carreras en la que se encuentra activo el individuo. El cuadro de la figura 66 resulta complejo a simple vista. Si se lee por partes: Existen 8 personas que se inscribieron sólo a una carrera (corresponden a 8 alumnos) y no están activos, todos ellos son egresados (observar la primera columna para Cant Alumnos y para Cant Personas ). La mayoría de los casos están inscriptos, activos y no egresados en sólo una carrera. Se trata de 290 alumnos (que son 290 personas). Hay una persona que se inscribió a dos carreras y está activo en una y egresado en una (tercera columna en ambos casos. En la figura 67 se ven más detalles de este caso). Para los casos restantes, que están activos e inscriptos en más de una carrera (2/2 y 3/3), en la grilla sólo se muestran los años de ingreso a las carreras, sería interesante realizar la apertura por carrera y por último año de actividad en la carrera para continuar la evaluación. La misma apertura por cantidad de carreras activo y cantidad de carreras donde egresó se puede realizar sobre la figura 64, para evaluar la actividad anual de los alumnos teniendo en cuenta esos criterios. Figura 67. Cantidad de alumnos de la cohorte 1997 según año académico en que registran actividad discriminados por cantidad de carreras en que se encuentra activo/cantidad de carreras inscripto y cantidad de carreras en que egresó. Y se puede visualizar por carrera para ver donde se producen las simultaneidades. 122

123 Capítulo 6 Uso de la herramienta y análisis de datos Figura 68. Comparación de alumnos con actividad por año, alumnos y personas correspondientes al año de ingreso a la universidad 1997, según cantidad de carreras en que está activo/cantidad de carreras inscripto, cantidad de carreras en que es egresado y carrera en los casos correspondientes. Es válido comparar la cantidad de alumnos con actividad con la cantidad de alumnos total y la cantidad de personas, y sobre esa base realizar filtros para profundizar el análisis. Por ejemplo, si focalizamos sobre quienes egresaron en alguna carrera podemos obtener el cuadro de la figura 69 donde se observan más detalles sobre su condición de alumnos (año de ingreso a la carrera, último año de actividad en la carrera). Observar que totalizan 10 alumnos, pero egresados son 9, ya que existe una persona que se inscribió en dos carreras pero sólo egresó en una de ellas. Este individuo comienza la carrera 07 en 1997 y la deja ese mismo año, y en el 2000 comienza la carrera 08, en la que tuvo actividad por última vez en el año 2005, lo que indicaría que es la carrera en la que egresó. Los otros casos estarían egresando en 2005 y 2006 (que es cuando registran actividad por última vez) en sus respectivas carreras. Si se deseara hacer un análisis más profundo sobre los egresados habría que utilizar algunas otras variables no incluidas en el Data Mart. Respecto a los alumnos activos en más de una carrera, observando en detalle la parte derecha de figura 68 se puede concluir que, para esta cohorte, no es muy común el comienzo de dos carreras en paralelo: de las 40 personas en cuestión (total de inscriptos en 2 y 3 carreras en cuadro inferior derecho) sólo 4 comienzan dos carreras en simultáneo (20+21=41 alumnos filas 7 a 9 de la columna 4 en cuadro superior derecho que corresponden a 37 personas columna 4 en cuadro inferior derecho). En general comienzan la otra carrera después, sea de grado o postgrado (observar los valores de año de ingreso a carrera para estos casos). 123

124 Capítulo 6 Uso de la herramienta y análisis de datos Figura 69. Análisis de los alumnos que ingresaron a la universidad en 1997 y egresaron en alguna carrera. Seguimiento de subconjunto mayoritario de una cohorte. Análisis por carrera y rendimiento Los casos de egresados y simultaneidad de carreras vistos recientemente podrían ser descartados del análisis, ya que no representan a la mayoría de los casos. Se opta por elegir los alumnos que están inscriptos y activos sólo en una carrera y que aún no han egresado para continuar el desgranamiento según el rendimiento académico. Sobre esos casos pretende realizar un análisis comparativo por carrera. También se descarta a los alumnos de carreras de postgrado porque, además de ser pocos casos, son muy particulares y la evaluación de desgranamiento sería diferente. Figura 70. Alumnos de la cohorte 1997 activos en sólo una carrera y no egresados. Cantidad total (gráfico inferior derecho) y cantidad discriminada por año en que tienen actividad académica. Sólo se consideran las carreras de grado. El mismo análisis puede hacerse seleccionando más de una cohorte. En la figura siguiente se muestran, además de la cohorte 1997, la anterior y la siguiente para realizar la comparación. 124

125 Capítulo 6 Uso de la herramienta y análisis de datos Figura 71. Cuadro principal: actividad anual de las cohortes , considerando alumnos inscriptos y activos en una carrera y no egresados para carreras de grado. Derecha: total de alumnos de las cohortes con las mismas restricciones. A partir de estos cuadros se pueden hacer análisis más intensivos para profundizar en el desgranamiento, por ejemplo utilizando variables de rendimiento académico como la cantidad de cursados o finales aprobados. En la figura 72 se aprecia la apertura de estos alumnos según el total de cursados aprobados en la carrera. Figura 72. Alumnos de carreras de grado de las cohortes inscriptos y activos en una carrera y no egresados, según total de cursados aprobados en la carrera. 125

126 Capítulo 6 Uso de la herramienta y análisis de datos En la figura 73 se ve el detalle de cursados aprobados por año académico de un subconjunto de estos alumnos. Para el gráfico se selecciona la cohorte 1997 y la carrera 10, y se muestra el desglose del total de cursados aprobados acumulados en la carrera por cada año en que los alumnos tienen actividad. Figura 73. Detalle de cursados aprobados por año académico y total de cursados aprobados en la carrera de los alumnos de la cohorte 1997 activos sólo en carrera El análisis completo debiera contemplar varias de estas dimensiones y utilizarlas en forma combinada, calculando por ejemplo el total de cursados regularizados (cursados aprobados más cursados promovidos) o el total de materias aprobadas (finales aprobados más cursados promovidos). La intención de estos ejemplos es presentar la potencialidad de la solución. Se deja en manos del lector la exploración de las posibles consultas, y fórmulas que puedan obtenerse y agregarse según las propias necesidades. 48 Tener en cuenta que los cursados promovidos se cuentan como tales y no como aprobados. Ese es el motivo de que las cantidades sean números pequeños. 126

Sistema de análisis de información. Resumen de metodología técnica

Sistema de análisis de información. Resumen de metodología técnica Sistema de análisis de información Resumen de metodología técnica Tabla de Contenidos 1Arquitectura general de una solución de BI y DW...4 2Orígenes y extracción de datos...5 2.1Procesos de extracción...5

Más detalles

Definición. Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4

Definición. Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4 Definición Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4 Definición (cont.) Un Data Warehouse es una colección de

Más detalles

CAPÍTULO 2 DATA WAREHOUSES

CAPÍTULO 2 DATA WAREHOUSES CAPÍTULO 2 DATA WAREHOUSES Un Data Warehouse (DW) es un gran repositorio lógico de datos que permite el acceso y la manipulación flexible de grandes volúmenes de información provenientes tanto de transacciones

Más detalles

ARQUITECTURA DE UNA BODEGA DE DATOS

ARQUITECTURA DE UNA BODEGA DE DATOS ARQUITECTURA DE UNA BODEGA DE DATOS Estructura de contenidos INTRODUCCIÓN... 3 1. ARQUITECTURA DE UNA BODEGA DE DATOS... 3 1.1 PROPIEDADES... 3 1.2 ARQUITECTURA DE UNA CAPA... 4 1.3 ARQUITECTURA DE DOS

Más detalles

ANEXO A - Plan de Proyecto. 1. - EDT de la solución EDT GENERAL DEL PROYECTO1

ANEXO A - Plan de Proyecto. 1. - EDT de la solución EDT GENERAL DEL PROYECTO1 ANEXO A - Plan de Proyecto 1. - EDT de la solución EDT GENERAL DEL PROYECTO1 2.- Diagrama de Gantt de la Solución DIAGRAMA DE GANTT- FASE INICIAL DOCUMENTACION Y ANALISIS2 DIAGRAMA DE GANTT- FASE FINAL

Más detalles

APOYO PARA LA TOMA DE DECISIONES

APOYO PARA LA TOMA DE DECISIONES APOYO PARA LA TOMA DE DECISIONES Cátedra: Gestión de Datos Profesor: Santiago Pérez Año: 2006 Bibliografía: Introducción a las Bases de Datos. DATE - 1 - 1. INTRODUCCION APOYO PARA LA TOMA DE DECISIONES

Más detalles

SISTEMAS DE INFORMACION GERENCIAL LIC.PATRICIA PALACIOS ZULETA

SISTEMAS DE INFORMACION GERENCIAL LIC.PATRICIA PALACIOS ZULETA SISTEMAS DE INFORMACION GERENCIAL LIC.PATRICIA PALACIOS ZULETA Qué es inteligencia de negocios? (BI) Business Intelligence es la habilidad para transformar los datos en información, y la información en

Más detalles

Data Warehousing - Marco Conceptual

Data Warehousing - Marco Conceptual Data Warehousing - Marco Conceptual Carlos Espinoza C.* Introducción Los data warehouses se presentan como herramientas de alta tecnología que permiten a los usuarios de negocios entender las relaciones

Más detalles

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes Capítulo 4 Arquitectura para análisis de información propuesta 4.1 Arquitectura Zombi es una arquitectura que proporciona de manera integrada los componentes necesarios para el análisis de información

Más detalles

El diseño de la base de datos de un Data Warehouse. Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias

El diseño de la base de datos de un Data Warehouse. Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias El diseño de la base de datos de un Data Warehouse Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias El modelo Multidimensional Principios básicos Marta Millan millan@eisc.univalle.edu.co

Más detalles

Enfoques de desarrollo DW Kimball/Inmon.

Enfoques de desarrollo DW Kimball/Inmon. Enfoques de desarrollo DW Kimball/Inmon. 1 Antecedentes Sistemas de Información Los procesos a automatizar son repetibles y previsibles. Modelado Entidad Relación. Atención en una rápida modificación en

Más detalles

Inteligencia de negocios desde la perspectiva cubana: factores críticos de éxito.

Inteligencia de negocios desde la perspectiva cubana: factores críticos de éxito. Tomado de: La inteligencia de negocios desde la perspectiva cubana: retos y tendencias. Informe publicado en TodoBI. Autora: MSc. Ivette Marrero Antunez Consultora de inteligencia empresarial. E-mail:

Más detalles

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]:

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]: RESUMEN DE COBIT 4.1 COBIT es un marco de trabajo y un conjunto de herramientas de Gobierno de Tecnología de Información (TI) que permite a la Gerencia cerrar la brecha entre los requerimientos de control,

Más detalles

UNIVERSIDAD DE SANTIAGO DE CHILE INGENIERIA COMERCIAL APLICACIÓN COMPUTACIONAL I INTELIGENCIA DE NEGOCIOS

UNIVERSIDAD DE SANTIAGO DE CHILE INGENIERIA COMERCIAL APLICACIÓN COMPUTACIONAL I INTELIGENCIA DE NEGOCIOS UNIVERSIDAD DE SANTIAGO DE CHILE INGENIERIA COMERCIAL APLICACIÓN COMPUTACIONAL I INTELIGENCIA DE NEGOCIOS Integrante: Profesor: Maximiliano Heise Luis Ríos Fecha de entrega: miércoles 18 de abril de 2012

Más detalles

MOLAP REALIZADO POR: JOSE E. TABOADA RENNA

MOLAP REALIZADO POR: JOSE E. TABOADA RENNA MOLAP REALIZADO POR: JOSE E. TABOADA RENNA BASE DE DATOS Conjunto de datos estructurados, fiables y homogéneos organizados independientemente en máquina, m accesibles en tiempo real, compatible por usuarios

Más detalles

Licencia GNU FDL. Detalle del cambio. Ing. Bernabeu Ricardo Dario, Ing. García Mattío Mariano Alberto. Versión incial. 05/11/2009

Licencia GNU FDL. Detalle del cambio. Ing. Bernabeu Ricardo Dario, Ing. García Mattío Mariano Alberto. Versión incial. 05/11/2009 Licencia GNU FDL Copyright 2009 Ing. Bernabeu Ricardo Dario, Ing. García Mattío Mariano Alberto. Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia

Más detalles

DATA WAREHOUSE DATA WAREHOUSE

DATA WAREHOUSE DATA WAREHOUSE DATA WAREHOUSE DATA WAREHOUSE Autor: Roberto Abajo Alonso Asignatura: Sistemas Inteligentes, 5º Curso Profesor: José Carlos González Dep. Ing. Sistemas Telemáticos, E.T.S.I. Telecomunicación Universidad

Más detalles

Botón menú Objetivo de la Minería de datos.

Botón menú Objetivo de la Minería de datos. Titulo de Tutorial: Minería de Datos N2 Botón menú: Introducción. Las instituciones y empresas privadas coleccionan bastante información (ventas, clientes, cobros, pacientes, tratamientos, estudiantes,

Más detalles

SQL Server Business Intelligence parte 1

SQL Server Business Intelligence parte 1 SQL Server Business Intelligence parte 1 Business Intelligence es una de las tecnologías de base de datos más llamativas de los últimos años y un campo donde Microsoft ha formado su camino a través de

Más detalles

Tecnologías de Información y Comunicación II CLASE 10

Tecnologías de Información y Comunicación II CLASE 10 Tecnologías de Información y Comunicación II CLASE 10 Medidas Una medida es un tipo de dato cuya información es usada por los analistas (usuarios) en sus consultas para medir la perfomance del comportamiento

Más detalles

Alicia Iriberri Dirección de Tecnologías de Información. I.- Definición del foco estratégico

Alicia Iriberri Dirección de Tecnologías de Información. I.- Definición del foco estratégico Alicia Iriberri Dirección de Tecnologías de Información I.- Definición del foco estratégico II.- Establecimiento de mediciones a través del Balanced Scorecard (Tablero de Comando) III.- Despliegue del

Más detalles

Replicación de Datos en SQL Server... 3. Resumen... 3. 1. Introducción... 3. 2. Componentes del modelo de replicación... 3

Replicación de Datos en SQL Server... 3. Resumen... 3. 1. Introducción... 3. 2. Componentes del modelo de replicación... 3 REPLICACIÓN DE DATOS EN SQL SERVER CONTENIDO Replicación de Datos en SQL Server... 3 Resumen... 3 1. Introducción... 3 2. Componentes del modelo de replicación... 3 3. Escenarios típicos de la replicación...

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

Business Intelligence y Cuadro de Mando Integral: Herramientas para la Dirección Estratégica de las Organizaciones

Business Intelligence y Cuadro de Mando Integral: Herramientas para la Dirección Estratégica de las Organizaciones Business Intelligence y Cuadro de Mando Integral: Herramientas para la Dirección Estratégica de las Organizaciones Facultad de Ingeniería 2005 Cra. Isabel Rodríguez Ramos Ideasoft AGENDA: 1. Business Intelligence,

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

MINERÍA DE DATOS. Teleprocesos y Sistemas Distribuidos Licenciatura en Sistemas de Información FACENA - UNNE. Octubre - 2003

MINERÍA DE DATOS. Teleprocesos y Sistemas Distribuidos Licenciatura en Sistemas de Información FACENA - UNNE. Octubre - 2003 MINERÍA DE DATOS Teleprocesos y Sistemas Distribuidos Licenciatura en Sistemas de Información FACENA - UNNE Octubre - 2003 CONTENIDO Qué es Data Warehousing Data Warehouse Objetivos del Data Warehouse

Más detalles

Inteligencia de Negocios Introducción. Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS

Inteligencia de Negocios Introducción. Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS Inteligencia de Negocios Introducción Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS Agenda 1.Introducción 2.Definición 3.ETL 4.Bodega de Datos 5.Data Mart

Más detalles

INTELIGENCIA DE NEGOCIOS

INTELIGENCIA DE NEGOCIOS INTELIGENCIA DE NEGOCIOS En tiempos de incertidumbre financiera, la toma de decisiones basada en información es crucial para sobrevivir en el mundo de los negocios. Empresas de todas las industrias dependen

Más detalles

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Programa de Capacitación y Certificación. INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Contenido PERFIL DE UN ESPECIALISTA EN BASES DE DATOS.... 3 6231. MANTENIENDO UNA BASE DE DATOS DE SQL SERVER 2008

Más detalles

SISTEMA DE INFORMACION DE GESTION DE TARJETAS DE CREDITO USANDO DATA MART E INTELIGENCIA DE NEGOCIOS PARA EL AREA COMERCIAL DEL BANCO RIPLEY PERU

SISTEMA DE INFORMACION DE GESTION DE TARJETAS DE CREDITO USANDO DATA MART E INTELIGENCIA DE NEGOCIOS PARA EL AREA COMERCIAL DEL BANCO RIPLEY PERU SISTEMA DE INFORMACION DE GESTION DE TARJETAS DE CREDITO USANDO DATA MART E INTELIGENCIA DE NEGOCIOS PARA EL AREA COMERCIAL DEL BANCO RIPLEY PERU AGENDA INTRODUCCION PLANTEAMIENTO METODOLOGICO ANTECEDENTES

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

BUSINESS INTELLIGENCE. www.sbi-technology.com

BUSINESS INTELLIGENCE. www.sbi-technology.com BUSINESS INTELLIGENCE www.sbi-technology.com SBI Technology SRL Maipú 1492 Piso 2 S2000CGT - Rosario Rep. Argentina Tel: (54 341) 530 0815 www.sbi-technology.com Copyright - SBI Technology SRL - Todos

Más detalles

BPM: Articulando Estrategia, Procesos y Tecnología

BPM: Articulando Estrategia, Procesos y Tecnología BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores

Más detalles

Facultad de Ciencias Económicas. Departamento de Sistemas. Asignatura: INTELIGENCIA DE NEGOCIOS. Plan 1997

Facultad de Ciencias Económicas. Departamento de Sistemas. Asignatura: INTELIGENCIA DE NEGOCIOS. Plan 1997 UNIVERSIDAD DE BUENOS AIRES Facultad de Ciencias Económicas Departamento de Sistemas Asignatura: INTELIGENCIA DE NEGOCIOS Código: 715 Plan 1997 Cátedra: DEPARTAMENTO DE SISTEMAS Carrera: Licenciado en

Más detalles

I. OBJETIVOS INTRODUCCIÓN. Oscar Daniel Camuendo Vásquez e-mail: oscardny86@hotmail.com

I. OBJETIVOS INTRODUCCIÓN. Oscar Daniel Camuendo Vásquez e-mail: oscardny86@hotmail.com DISEÑO, IMPLEMENTACIÓN E IMPLANTACIÓN DE UNA APLICACIÓN WEB DE ADMINISTRACIÓN Y CONTROL DE CALIFICACIONES PARA LA UNIDAD EDUCATIVA PARTICULAR OVIEDO (SECCIÓN SECUNDARIA), UTILIZANDO SOFTWARE LIBRE. Oscar

Más detalles

Los tres obstáculos para la expansión del negocio y cómo puede evitarlos

Los tres obstáculos para la expansión del negocio y cómo puede evitarlos Los tres obstáculos para la expansión del negocio Por Phil Reney, analista de investigación de TEC Resumen ejecutivo Technology Evaluation Centers Los tres obstáculos para la expansión del negocio La expansión

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

Capítulo 2 Tecnología data warehouse

Capítulo 2 Tecnología data warehouse Capítulo 2 Tecnología data warehouse El objetivo de éste capítulo es mostrar la tecnología data warehouse (DW) como una herramienta para analizar la información. Este capítulo se encuentra organizado de

Más detalles

CONSTRUCCION DE INDICADORES DE GESTION Y HERRAMIENTAS OLAP PARA PEQUEÑAS Y MEDIANAS EMPRESAS

CONSTRUCCION DE INDICADORES DE GESTION Y HERRAMIENTAS OLAP PARA PEQUEÑAS Y MEDIANAS EMPRESAS CONSTRUCCION DE INDICADORES DE GESTION Y HERRAMIENTAS OLAP PARA PEQUEÑAS Y MEDIANAS EMPRESAS 1. RESEÑA HISTORICA Las exigencias competitivas del mercado hacen que las organizaciones busquen mecanismos

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA Estudio de las herramientas TOAD y DBArtisan para la administración e integración de bases de datos relacionales. PREVIA OPCION AL TÍTULO DE: INGENIERO

Más detalles

UNIVERSIDAD NACIONAL DE INGENIERÍA CENTRO DE EXTENSIÓN Y PROYECCIÓN SOCIAL

UNIVERSIDAD NACIONAL DE INGENIERÍA CENTRO DE EXTENSIÓN Y PROYECCIÓN SOCIAL UNIVERSIDAD NACIONAL DE INGENIERÍA CENTRO DE EXTENSIÓN Y PROYECCIÓN SOCIAL AREA DE CURSOS DE ESPECIALIZACIÓN EN TECNOLOGÍAS DE LA INFORMACIÓN TALLER DE INVESTIGACION EN INTELIGENCIA DE NEGOCIOS CON LA

Más detalles

VENTAJAS DEL USO DE HERRAMIENTAS DE ETL SOBRE ANSI SQL

VENTAJAS DEL USO DE HERRAMIENTAS DE ETL SOBRE ANSI SQL VENTAJAS DEL USO DE HERRAMIENTAS DE ETL SOBRE ANSI SQL LIC. DIEGO KRAUTHAMER PROFESO R ADJUNTO INTERINO UNIVERSIDAD ABIERTA INTERMERICANA (UAI) SEDE BUENOS AIRES COMISION DE INVESTIGACION Abstract El presente

Más detalles

Cómo funciona un sistema de Planificación y Consolidación

Cómo funciona un sistema de Planificación y Consolidación Cómo funciona un sistema de Planificación y Consolidación Business Planning and Consolidation es parte de la familia de productos Enterprise Performance Management (EPM), su objetivo es satisfacer las

Más detalles

Gestión de Información en Cuentas Nacionales de Chile

Gestión de Información en Cuentas Nacionales de Chile Gestión de Información en Cuentas Nacionales de Chile Gerencia de Estadísticas Macroeconómicas Departamento Cuentas Nacionales 1 B A N C O C E N T R A L D E C H I L E OCTUBRE 2009 Temario I. Antecedentes

Más detalles

Business Intelligence

Business Intelligence 2012 Business Intelligence Agenda Programas Diferencias de OLTP vs OLAP Arquitectura de una solución de BI Tecnologías Microsoft para BI Diferencias entre OLTP v/s OLAP Alineación de Datos OLTP Datos organizados

Más detalles

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA) SYLLABO

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA) SYLLABO UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA) FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA Escuela Académico Profesional de Ingeniería de Sistemas 1. ESPECIFICACIONES

Más detalles

Sistemas de Data Warehousing

Sistemas de Data Warehousing Federación Médica del Interior (FEMI) Sociedad Uruguaya de Informática en la Salud (SUIS) Información en Salud Edición 2009 Sistemas de Data Warehousing Dr. Ing. Adriana Marotta (In.Co - F.Ing - UDELAR)

Más detalles

Cuáles son algunos de los padecimientos que enfrentan las empresas hoy día?

Cuáles son algunos de los padecimientos que enfrentan las empresas hoy día? Qué es Inteligencia de Negocios? Una interesante definición para inteligencia de negocios o BI, por sus siglas en inglés, según el Data Warehouse Institute, lo define como la combinación de tecnología,

Más detalles

Sistemas de Información 12/13 La organización de datos e información

Sistemas de Información 12/13 La organización de datos e información 12/13 La organización de datos e información Departamento Informática e Ingeniería de Sistemas Universidad de Zaragoza (raqueltl@unizar.es) " Guión Introducción: Data Warehouses Características: entornos

Más detalles

CAPITULO V DISEÑO DEL CUADRO DE MANDO INTEGRAL

CAPITULO V DISEÑO DEL CUADRO DE MANDO INTEGRAL CAPITULO V DISEÑO DEL CUADRO DE MANDO INTEGRAL Al hablar del balance scorecard, no deberíamos referirnos al mismo como Proyecto, sino más bien como Programa. Esto solamente para dar al balanced scorecard

Más detalles

CA ERwin Data Profiler

CA ERwin Data Profiler RESUMEN DEL PRODUCTO: CA ERWIN DATA PROFILER CA ERwin Data Profiler CA ERWIN DATA PROFILER AYUDA A LAS ORGANIZACIONES A REDUCIR LOS COSTOS Y RIESGOS ASOCIADOS CON LA INTEGRACIÓN DE DATOS, AL BRINDAR CAPACIDADES

Más detalles

Estructura de Bases de datos. Leonardo Víquez Acuña

Estructura de Bases de datos. Leonardo Víquez Acuña Estructura de Bases de datos Leonardo Víquez Acuña Lenguajes de Bases de Datos Un sistema de bases de datos proporciona Un lenguaje de definición de datos para especificar el esquema de la base de datos

Más detalles

Data Warehousing. Introducción. Facultad de Ingeniería Escuela de Ingeniería de Sistemas y Computación

Data Warehousing. Introducción. Facultad de Ingeniería Escuela de Ingeniería de Sistemas y Computación Data Warehousing Introducción Introducción Indice (I) Propiedades de un dw Arquitectura de procesos en un sistema de data warehousing Puntos clave Diseño de la base de datos de un data warehouse Indice

Más detalles

Estos documentos estarán dirigidos a todas las personas que pertenezcan a equipos de implementación de Oracle BI, incluyendo a:

Estos documentos estarán dirigidos a todas las personas que pertenezcan a equipos de implementación de Oracle BI, incluyendo a: Oracle Business Intelligence Enterprise Edition 11g. A lo largo de los siguientes documentos trataré de brindar a los interesados un nivel de habilidades básicas requeridas para implementar efectivamente

Más detalles

SAP BusinessObjects Edge BI Standard Package La solución de BI preferida para. Empresas en Crecimiento

SAP BusinessObjects Edge BI Standard Package La solución de BI preferida para. Empresas en Crecimiento SAP BusinessObjects Edge BI Standard Package La solución de BI preferida para Empresas en Crecimiento Portfolio SAP BusinessObjects Soluciones SAP para Empresas en Crecimiento Resumen Ejecutivo Inteligencia

Más detalles

Microsoft Dynamics SL

Microsoft Dynamics SL Microsoft Dynamics SL Diseñada para organizaciones que se previenen, Microsoft Dynamics SL es una solución de administración de negocios integrada y adaptable cuya interfaz es tan amigable e intiutiva

Más detalles

TECNÓLOGO EN INFORMÁTICA PLAN DE ESTUDIOS

TECNÓLOGO EN INFORMÁTICA PLAN DE ESTUDIOS Administración Nacional de Universidad de la República Educación Pública Facultad de Ingenieria CF Res..0.07 Consejo Directivo Central Consejo Directivo Central Res..05.07 Res. 17.0.07 TECNÓLOGO EN INFORMÁTICA

Más detalles

Sistema de Información Gerencial de la Superintendencia de Servicios de Salud, soporte de decisión para el Seguro Nacional de Salud Argentino

Sistema de Información Gerencial de la Superintendencia de Servicios de Salud, soporte de decisión para el Seguro Nacional de Salud Argentino Sistema de Información Gerencial de la Superintendencia de Servicios de Salud, soporte de decisión para el Seguro Nacional de Salud Argentino El presente documento es una adaptación del trabajo Sistema

Más detalles

Requisitos de inteligencia comercial para TI:

Requisitos de inteligencia comercial para TI: Requisitos de inteligencia comercial para TI: Lo que cada administrador de TI debe saber sobre las necesidades reales de los usuarios comerciales para inteligencia comercial Enero de 2011 p2 Los usuarios

Más detalles

Comunicación para Tecnimap 2010. Contenido: 1. Itourbask como elemento de un Sistema de Gestión de Destino Turístico 2. El Data Mart de Itourbask

Comunicación para Tecnimap 2010. Contenido: 1. Itourbask como elemento de un Sistema de Gestión de Destino Turístico 2. El Data Mart de Itourbask Comunicación para Tecnimap 2010. EL BI APLICADO AL ANÁLISIS DE LAS VISITAS TURÍSTICAS Contenido: 1. Itourbask como elemento de un Sistema de Gestión de Destino Turístico 2. El Data Mart de Itourbask Autor:

Más detalles

DATA WAREHOUSING (ENERO DE 2003) Documento creado por Ing. Héctor H. Martínez Orpinel

DATA WAREHOUSING (ENERO DE 2003) Documento creado por Ing. Héctor H. Martínez Orpinel DATA WAREHOUSING (ENERO DE 2003) DEFINICIÓN UN DATA WAREHOUSING ES UN CONJUNTO DE DATOS INTEGRADOS ORIENTADOS A UNA MATERIA, QUE VARIA CON EL TIEMPO Y QUE NO SON TRANSITORIOS, LOS CUALES SOPORTAN EL PROCESO

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE CIENCIAS COORDINACIÓN DE EXTENSIÓN

UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE CIENCIAS COORDINACIÓN DE EXTENSIÓN UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE CIENCIAS COORDINACIÓN DE EXTENSIÓN PROPUESTA PARA INTRODUCIR CURSOS DE EXTENSIÓN, DIPLOMADOS, SERVICIOS Y ACTUALIZACIONES TÉCNICAS Y PROFESIONALES Nombre (s)

Más detalles

Agrupamiento Familia Puesto Alcance del puesto Requisitos excluyentes

Agrupamiento Familia Puesto Alcance del puesto Requisitos excluyentes TIC-1-1 Analista de monitoreo de redes Monitorear y controlar las redes del GCABA con el fin de detectar incidentes y reportarlos. Analizar las métricas utilizadas para el monitoreo de la red, la configuración

Más detalles

FUNDAMENTOS DE DATA WAREHOUSE

FUNDAMENTOS DE DATA WAREHOUSE FUNDAMENTOS DE DATA WAREHOUSE 1. Qué es Data Warehouse? El Data Warehouse es una tecnología para el manejo de la información construido sobre la base de optimizar el uso y análisis de la misma utilizado

Más detalles

Informática II Ing. Industrial. Data Warehouse. Data Mining

Informática II Ing. Industrial. Data Warehouse. Data Mining Data Warehouse Data Mining Definición de un Data Warehouses (DW) Fueron creados para dar apoyo a los niveles medios y altos de una empresa en la toma de decisiones a nivel estratégico en un corto o mediano

Más detalles

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberación

Más detalles

LOS CINCO GRADOS DE MADUREZ DE UN PROYECTO BI

LOS CINCO GRADOS DE MADUREZ DE UN PROYECTO BI LOS CINCO GRADOS DE MADUREZ DE UN PROYECTO BI INTRODUCCIÓN Se habla en multitud de ocasiones de Business Intelligence, pero qué es realmente? Estoy implementando en mi organización procesos de Business

Más detalles

Fundamentos de Data Warehouse

Fundamentos de Data Warehouse Mendez, A., Mártire, A., Britos, P. Y Garcia-Martínez, R. Centro de Actualización Permanente en Ingeniería del Software Escuela de Postgrado Instituto Tecnológico de Buenos Aires Av. Eduardo Madero 399

Más detalles

Tecnologías de la Información en la Gestión Empresarial

Tecnologías de la Información en la Gestión Empresarial Tecnologías de la Información en la Gestión Empresarial 1 Sesión No.8 Nombre: Procesos de Negocio y Gestión en Business Intelligence Objetivo: Al término de la sesión, el alumno ilustrará un proceso de

Más detalles

CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED

CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED En el presente capitulo se presenta una aplicación que aborda una herramienta de monitoreo de redes para soportar estudios de disponibilidad.

Más detalles

El uso de plataformas de Educación a Distancia como herramientas de capacitación en el uso de Tecnologías de la Información

El uso de plataformas de Educación a Distancia como herramientas de capacitación en el uso de Tecnologías de la Información El uso de plataformas de Educación a Distancia como herramientas de capacitación en el uso de Tecnologías de la Información Autor: MBA Luis Elissondo Correo electrónico: luiselissondo@gmail.com Institución:

Más detalles

SIU-Guaraní. Descripción de Mejoras. Documento Funcional. Versión 2.5.2 Junio 2007

SIU-Guaraní. Descripción de Mejoras. Documento Funcional. Versión 2.5.2 Junio 2007 "2007 - Año de la Seguridad Vial" SIU-Guaraní Descripción de Mejoras Documento Funcional Versión 2.5.2 Junio 2007 Santa Fe 1548 piso 11 Frente Ciudad Autónoma de Buenos Aires - República Argentina Telefax:

Más detalles

Sistemas de Información para la Gestión. UNIDAD 2: RECURSOS DE TI Información y Aplicaciones

Sistemas de Información para la Gestión. UNIDAD 2: RECURSOS DE TI Información y Aplicaciones UNIDAD 2: RECURSOS DE TI Información y Aplicaciones UNIDAD 2: RECURSOS DE TI Información y Aplicaciones 1. La Información: Propiedades de la Información. Sistemas de Información. Bases de Datos. 2. Administración

Más detalles

PROGRAMA FORMATIVO Administración de Business Intelligence y Datawarehousing

PROGRAMA FORMATIVO Administración de Business Intelligence y Datawarehousing PROGRAMA FORMATIVO Administración de Business Intelligence y Datawarehousing Julio 2014 DATOS GENERALES DE LA ESPECIALIDAD 1. Familia Profesional: INFORMÁTICA Y COMUNICACIONES Área Profesional: DESARROLLO

Más detalles

Cátedra: BI Business Intelligence. Asignatura BI Business Intelligence Ciclo Lectivo 2012 Vigencia del Ciclo lectivo 2012.

Cátedra: BI Business Intelligence. Asignatura BI Business Intelligence Ciclo Lectivo 2012 Vigencia del Ciclo lectivo 2012. Asignatura BI Business Intelligence Ciclo Lectivo 2012 Vigencia del Ciclo lectivo 2012 programa Plan 2008 Área Complementaria Carga horaria semanal Anual/ cuatrimestral Coordinador de Cátedra Objetivos

Más detalles

DESARROLLO E IMPLANTANCIÓN DE UN SISTEMA ACADEMICO PARA EL ICM

DESARROLLO E IMPLANTANCIÓN DE UN SISTEMA ACADEMICO PARA EL ICM DESARROLLO E IMPLANTANCIÓN DE UN SISTEMA ACADEMICO PARA EL ICM Sergio Bauz Olvera 1, Washington Jama 2 1 Ingeniero en Estadística e Informática 2003 2 Director de Tesis de Grado, Ing. Washington Jama.

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción El WWW es la mayor fuente de imágenes que día a día se va incrementando. Según una encuesta realizada por el Centro de Bibliotecas de Cómputo en Línea (OCLC) en Enero de 2005,

Más detalles

BUSINESS INTELLIGENCE

BUSINESS INTELLIGENCE BUSINESS INTELLIGENCE PRESENTACIÓN Ramón Díaz Hernández Gerente (1.990) Nuestro Perfil Inversión permanente en formación y nuevas tecnologías. Experiencia en plataforma tecnológica IBM (Sistema Operativo

Más detalles

Almacén de datos - concepto. Arquitectura de un sistema de almacén de datos

Almacén de datos - concepto. Arquitectura de un sistema de almacén de datos Almacén de datos - concepto Almacén de datos (Bodega de Datos, Data warehouse) es una integrada colección de datos que contiene datos procedentes de sistemas del planeamiento del recurso de la empresa

Más detalles

Cómo construir un caso de negocios para un ERP?

Cómo construir un caso de negocios para un ERP? Cómo construir un caso de negocios para un ERP? Una guía paso a paso para aquellas personas encargas de la toma de decisiones en la industria de los plásticos Cómo construir un caso de negocios para un

Más detalles

Tecnologías Aplicadas a Business Intelligence Proyecto Práctico

Tecnologías Aplicadas a Business Intelligence Proyecto Práctico Tecnologías Aplicadas a Business Intelligence Proyecto Práctico Empresa: La empresa en cuestión, es una Importadora y Distribuidora de Autopartes, con más de 30 años de vida. Nació como la distribuidora

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos 65 CAPITULO 3 DISEÑO 3.1. DISEÑO El diseño del software es el proceso que permite traducir los requisitos analizados de un sistema en una representación del software. 66 Diseño procedural Diseño de la

Más detalles

El modelo de ciclo de vida cascada, captura algunos principios básicos:

El modelo de ciclo de vida cascada, captura algunos principios básicos: Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada",

Más detalles

FACULTAD DE INGENIERÍA. Bases de Datos Avanzadas

FACULTAD DE INGENIERÍA. Bases de Datos Avanzadas FACULTAD DE INGENIERÍA Ingeniería en Computación Bases de Datos Avanzadas Datawarehouse Elaborado por: MARÍA DE LOURDES RIVAS ARZALUZ Septiembre 2015 Propósito Actualmente las empresas necesitan contar

Más detalles

Tecnología aplicada a la toma de decisiones o malas decisiones en tecnología?

Tecnología aplicada a la toma de decisiones o malas decisiones en tecnología? Tecnología aplicada a la toma de decisiones o malas decisiones en tecnología? DUTI 2007 LA PLATA AGOSTO 2007 Ernesto Chinkes Facultad de Ciencias Económicas Universidad de Buenos Aires Esquema del trabajo

Más detalles

S s i t s em a s de d Inf n o f r o m a ió i n TIPOS DE SISTEMAS

S s i t s em a s de d Inf n o f r o m a ió i n TIPOS DE SISTEMAS Sistemas de Información TIPOS DE SISTEMAS La Empresa en la Sociedad de la Información: Impacto en las Organizaciones TICS TICS - COMPONENTES el factor humano los contenidos de la información el equipamiento

Más detalles

Presentación Corporativa Viainfo Ltda. 2014

Presentación Corporativa Viainfo Ltda. 2014 Presentación Corporativa Viainfo Ltda. 2014 V i a i n f o L i m i t a d a C e r r o S a n t a L u c i a 9 8 0 1 Q u i l i c u r a w w w. v i a i n f o. c l QUIENES SOMOS: SOMOS UN GRUPO DE PROFESIONALES

Más detalles

Definición de PMO Características de una PMO

Definición de PMO Características de una PMO Definición de PMO Existen varios conceptos de una oficina de proyectos (PMO) una de ella la define como una unidad organizacional, física o virtual, especialmente diseñada para dirigir y controlar el desarrollo

Más detalles

Inteligencia de Negocios. Cecilia Ruz

Inteligencia de Negocios. Cecilia Ruz Inteligencia de Negocios Cecilia Ruz Inteligencia de Negocios Business Intelligence (BI) Es un paraguas bajo el que se incluye un conjunto de conceptos y metodologías cuya misión consiste en mejorar el

Más detalles

Cómo empezar? Fernando Quesada abcq Solutions fquesada@abcqsolutions.com

Cómo empezar? Fernando Quesada abcq Solutions fquesada@abcqsolutions.com Cómo empezar? Fernando Quesada abcq Solutions fquesada@abcqsolutions.com Retos Actuales BI: Una Analogía - Definición Que no es BI Requisitos Fundamentales para Aprovechar BI Algunos Conceptos de TI (Tecnología

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Sybase IQ Servidor analítico con arquitectura basada en columnas

Sybase IQ Servidor analítico con arquitectura basada en columnas Sybase IQ Servidor analítico con arquitectura basada en columnas www.sybase.es Sybase IQ Descripción Tener acceso a toda la información de que dispone su organización, con el fin de analizarla no es hoy

Más detalles