Universidad Nacional del Sur

Departamento de Ciencias e Ingeniera de la Computacin

Tesis de Licenciatura en Ciencias de la Computacin

Data Warehousing.
Relevamiento y aplicacin de tcnicas de modelado dimensional
Alumna: Mara Cecilia Dmina Directoras: Mg. Elsa Estvez y Lic. Mercedes Vitturini

Baha Blanca Diciembre 2008

Resumen
Este trabajo ha sido desarrollado por la alumna Mara Cecilia Dmina bajo la direccin de la Mg. Elsa Estvez y la Lic. Mercedes Vitturini. Se presenta como tesis de la carrera de grado Licenciatura en Ciencias de la Computacin de la Universidad Nacional del Sur. En este proyecto se estudia la utilizacin de herramientas de Data Warehousing para el anlisis de datos. Se destaca la importancia de la aplicacin de estas tecnologas para el conocimiento de la informacin de cualquier institucin 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 tericos desarrollados en esta rea de las ciencias de la computacin y se presentan las principales tcnicas de diseo de Data Warehouses actuales. En la segunda seccin se desarrolla un ejemplo de aplicacin de los conceptos y tcnicas estudiadas enfocados hacia una propuesta de anlisis de desgranamiento de alumnos universitarios. El diseo apunta a la identificacin de perfiles y patrones de los alumnos universitarios que abandonan la actividad acadmica. Para el caso de estudio se utiliza como modelo organizacional de partida al modelo de datos usado por el Sistema de Gestin de Acadmica de Alumnos SIU-Guaran. El sistema SIU-Guaran actualmente se utiliza como sistema de gestin acadmica en la mayora de las universidades nacionales argentinas y particularmente en la Universidad Nacional del Sur. El presente trabajo se realiz con la colaboracin del SIU1, que facilita el uso de la herramienta O3 de la empresa IdeaSoft para la implementacin del caso prctico y los desarrollos y documentacin que poseen sobre el tema de estudio y lo referente al SIU-Guaran. Todo lo desarrollado como parte de esta tesis queda a disposicin del SIU para su publicacin y futura aplicacin.

El SIU es un rea del Ministerio de Educacin que desarrolla sistemas informticos para las Universidades Nacionales.

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 predisposicin de siempre y su paciencia. A Daro por su enorme colaboracin. Al SIU en general por brindar las herramientas, el material, y el conocimiento para la construccin del caso prctico. Y a mi familia, amigos, compaeros y todo el equipo del SIU por su apoyo y empuje, por estar. Gracias!, sin ustedes todo hubiese sido ms difcil.

ndice
Resumen.................................................................................................................2 Agradecimientos....................................................................................................3 ndice.......................................................................................................................4 1 Introduccin.........................................................................................................7 2 Sistemas para Anlisis de Informacin...........................................................10
2.1 Evolucin de los Sistemas de Soporte de Decisiones............................................10 2.2 Qu es un Data Warehouse?...............................................................................14 2.3 Objetivos de un Data Warehouse ..........................................................................15 2.4 Entorno del Data Warehouse..................................................................................17
Fuentes de datos...................................................................................................................18 Limpieza y transformacin de los datos.................................................................................18 Almacenamiento y presentacin de los datos .......................................................................21 Anlisis de informacin..........................................................................................................22

2.5 Aplicaciones tradicionales versus aplicaciones para anlisis de informacin.........23

Caracterizacin de las diferencias ........................................................................................24 Nivel de datos fsico para anlisis de informacin.................................................................27

2.6 Tendencias en sistemas para anlisis de informacin............................................29 2.7 El mercado de Data Warehousing y Business Intelligence.....................................32

3 El proceso de creacin de modelos analticos .............................................34

3.1 Introduccin al modelado multidimensional............................................................34
Dimensiones, hechos y medidas...........................................................................................37 Navegacin del modelo multidimensional..............................................................................38 Tabla de hechos....................................................................................................................38 Tablas de dimensin..............................................................................................................39 Esquema estrella...................................................................................................................39

3.2 Ciclo de vida de un proyecto de Data Warehousing...............................................40

Hitos del mapa de ruta del BDL.............................................................................................40 Planificacin del proyecto......................................................................................................41 Definicin de requerimientos.................................................................................................42 Diseo de la arquitectura tcnica...........................................................................................42 4

Seleccin de Productos e Instalacin....................................................................................43 Modelado Dimensional lgico................................................................................................43 Diseo Fsico.........................................................................................................................44 Diseo de las Extracciones y Transformaciones de Datos ...................................................44 Especificacin de Aplicaciones para Usuarios Finales..........................................................45 Desarrollo de Aplicaciones para Usuarios Finales.................................................................47 Puesta en produccin............................................................................................................47 Mantenimiento y crecimiento.................................................................................................49 Gerenciamiento del Proyecto.................................................................................................50

3.3 Tcnicas para el modelado dimensional.................................................................50

Eleccin del Data Mart...........................................................................................................51 Tablas de Hechos y Granularidad.........................................................................................52 Diseo de las dimensiones....................................................................................................57 Definicin de las medidas......................................................................................................66 Diseo multidimensional avanzado........................................................................................69

4 Presentacin del caso de estudio....................................................................72

4.1 Qu es el SIU?.....................................................................................................72 4.2 El sistema de software SIU-Guaran.......................................................................73 4.3 Desercin y desgranamiento de alumnos...............................................................75

5 Presentacin de la solucin.............................................................................77
5.1 Requerimientos y especificacin del Data Mart......................................................77
Datos considerados...............................................................................................................77 Datos que quedaron excluidos y motivos .............................................................................78

5.2 Arquitectura del caso prctico.................................................................................79 5.3 Matriz y modelo lgico del Data Mart......................................................................80 5.4 Modelo fsico y consideraciones de diseo.............................................................83
Diseo fsico de las tablas del DW que se usan para el Data Mart.......................................84 Diseo fsico del Data Mart....................................................................................................86

5.5 Personalizacin del proceso ETL...........................................................................92 5.6 Problemas de calidad de datos...............................................................................93

Controles en la definicin del modelo y la generacin del cubo............................................93 Controles en los procesos de extraccin y transformacin de datos.....................................94 Problemas de calidad en el origen del dato...........................................................................94

6 Uso de la herramienta y anlisis de datos......................................................96

5

6.1 Acceso al cubo y operaciones bsicas...................................................................96

Acceso al cubo y vista inicial.................................................................................................96 Operaciones bsicas de consulta..........................................................................................97

6.2 Un ejemplo de anlisis sobre evolucin de la matrcula........................................101

Cantidad de alumnos por ao acadmico............................................................................101 Anlisis de ingresantes........................................................................................................103 Seguimiento de una cohorte................................................................................................107

6.3 Ejemplos de anlisis de procedencia....................................................................110

Anlisis a nivel de pas y calidad de datos...........................................................................111 Exploracin de los niveles de la dimensin procedencia.....................................................112 Articulacin de colegios y carreras......................................................................................113

6.4 Un ejemplo de desgranamiento basado en la actividad acadmica y rendimiento ........................................................................................................................116

ltimo ao con actividad......................................................................................................116 Personas y alumnos............................................................................................................117 Actividad anual de las cohortes...........................................................................................119 Seguimiento de una cohorte................................................................................................120 Seguimiento de subconjunto mayoritario de una cohorte. Anlisis por carrera y rendimiento .................................................................................................................................124

7 Conclusiones y trabajo futuro........................................................................127

7.1 Conclusiones........................................................................................................127 7.2 Trabajo futuro ......................................................................................................128

8 Apndice. Documentacin tcnica del caso de estudio.............................131

8.1 Descripcin tcnica de las variables del cubo.......................................................131 8.2 Consideraciones especiales.................................................................................134 8.3 Estructuras de los archivos de texto.....................................................................135 8.4 Generacin del cubo.............................................................................................137 8.5 Archivos adjuntos.................................................................................................138

Bibliografa.........................................................................................................139

Captulo 1 - Introduccin

Introduccin
Sin lugar a dudas, el Data Warehousing es parte integral de lo que algunos autores

definen como la era de la informacin ya que posibilita la construccin y mantenimiento de estructuras destinadas al anlisis de los datos, transformando los datos en informacin y la informacin en conocimiento [Mst2005]. El concepto de Data Warehouse (DW), cuya traduccin literal sera almacn o repositorio de datos, surge en los aos 90 con la necesidad y oportunidad de obtener informacin de los datos que haban sido recolectados durante los aos anteriores por los sistemas de gestin. As, el DW nace producto de la evolucin de los sistemas para soporte de decisiones. Hasta ese momento, la informacin que requeran las organizaciones se obtena 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 analticas. Los sistemas del ambiente de procesamiento de transacciones en lnea OLTP (on-line transaction processing) en general carecen de integracin y no mantienen en lnea la informacin histrica requerida para la toma de decisiones estratgicas en una organizacin. Adems las consultas de tipo gerencial, con informacin resumida y desde distintas vistas, demandan el procesamiento de importantes volmenes de datos, requiriendo recursos y deteriorando notablemente el rendimiento de los sistemas operacionales. Por esta razn generalmente deban ser disparados en horarios en que stos no se estuvieran utilizando en produccin. La prctica muestra que deben existir dos ambientes diferentes debido a que el procesamiento analtico en lnea OLAP (on-line analytical processing) tiene necesidades, usuarios, estructuras y ritmos profundamente diferentes a los sistemas operacionales. Los datos que se utilizan son diferentes, y la tecnologa que los soporta tambin. Se necesita del diseo de una nueva arquitectura para cubrir los requerimientos analticos 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, convirtindose en el repositorio central y la nica fuente de datos consolidados consultable para el anlisis de informacin de toda la organizacin. As, se puede organizar al sistema de informacin en dos grandes sectores: el de los sistemas operacionales, donde se registran los datos, y el del DW donde se procesan los volmenes de informacin para obtener conocimiento. Un DW es un tipo especial de base de datos orientado a la exploracin de la informacin histrica que contiene. El modelo que soporta la informacin se encuentra diseado, estructurado e implementado con la finalidad y propsito del anlisis y navegacin de los datos y recibe el nombre de modelo multidimensional. 7

Captulo 1 - Introduccin

El modelado multidimensional es una tcnica para disear modelos de datos simples y entendibles. Se busca visualizar el contenido de la base de datos como un cubo de tres, cuatro, cinco o ms dimensiones. Bajo este paradigma, los usuarios se pueden imaginar navegando la informacin y realizando cortes a ese cubo a travs de cada una de sus dimensiones. Se entiende por navegacin o drilling de los datos, a la capacidad de ver informacin correspondiente a diferentes contextos o entornos. Por ejemplo, analizar los egresados de un determinado ao y poder detallarlos por carrera. Luego analizar ms profundamente una carrera para ver cmo se discriminan los egresados por cada cohorte2, etc. El modelo dimensional organiza y presenta los datos definiendo dimensiones. Se define como dimensiones a las lneas o reas temticas del negocio, como por ejemplo producto, sucursal, tiempo. Son entidades independientes que sirven como punto de entrada para el anlisis de la informacin contenida en el modelo multidimensional. Llevado al mbito universitario y para el anlisis informacin acadmica de alumnos se podran considerar a las dimensiones: carreras, lugar de procedencia, ao de ingreso, entre otras. Dentro de las dimensiones pueden existir diferentes niveles de anlisis o jerarquas. Para el caso de procedencia se podran considerar los niveles pas, provincia, localidad y colegio, por ejemplo. Las dimensiones se relacionan a travs de hechos. Se consideran hechos a sucesos o eventos que ocurren, como por ejemplo alumnos que cursan carreras, o que rinden exmenes. Este ltimo ejemplo estara relacionando a las dimensiones: materia, alumno, y fecha, entre otras. Los hechos o eventos generalmente se asocian con una o ms medidas (el resultado o nota, en este caso). Las medidas, mtricas o indicadores, son variables numricas que ayudan a medir el rendimiento de un negocio o proceso. En esta tesis se presentan los principales conceptos y tcnicas de diseo y se resaltan la importancia y potencial de estas tecnologas para la toma de decisiones y el mejoramiento de los sistemas de gestin y la calidad de datos. La tesis se completa con un ejemplo prctico que muestra la aplicacin de los conceptos tericos. Dado que el desarrollo est basado en el modelo de datos de un sistema gestin transaccional de uso real, los resultados obtenidos podrn utilizarse para colaborar en el anlisis de la problemtica de desercin universitaria. El desarrollo de la tesis se organiz de la siguiente manera: en el captulo 2 se describe la evolucin 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 gestin (OLTP). Finalmente se presentan las principales herramientas del mercado. En el captulo 3 se especifican las caractersticas de los modelos dimensionales y las principales tcnicas para disearlos. Tambin se presenta una metodologa de produccin de DW o ciclo de vida de DW.

Entindase por cohorte al ao acadmico en que el alumno ingresa a la carrera.

Captulo 1 - Introduccin

La segunda parte de esta tesis consta de tres captulos destinados al caso de aplicacin. Se presenta la temtica a abordar, se desarrolla la solucin explicando las decisiones de diseo adoptadas y luego se muestra el uso a travs de ejemplos concretos. En este caso la temtica elegida es el desgranamiento de alumnos universitarios. La desercin universitaria es un tema que ha despertado mucho inters en el ltimo tiempo. El costo econmico 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 prctico de esta tesis, adems de mostrar un ejemplo de aplicacin de los conceptos desarrollados busca transmitir la experiencia adquirida mediante el anlisis de distintas alternativas para implementar y usar la solucin. Los ejemplos de anlisis de datos intentan mostrar como sera posible encontrar dentro de una institucin dnde se concentran los mayores problemas, e identificar las posibles causas. Como OLTP fuente de datos se usa el sistema SIU-Guaran. El SIU-Guaran es un sistema de gestin de alumnos universitarios que administra informacin de gestin acadmica: carreras, planes de estudio, ttulos, materias, egresados, inscripciones y resultados de exmenes, profesores asociados a las ctedras, asignacin 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 tambin en varias universidades nacionales argentinas3.

A mayo del 2008 se totalizan ms de 200 instalaciones

Captulo 2 - Sistemas para Anlisis de Informacin

Sistemas para Anlisis de Informacin

El trmino de Data Warehouse (DW) surge en los aos 90 con la necesidad y oportunidad

de obtener informacin a partir de los datos que haban sido recolectados durante los aos anteriores por los sistemas de gestin. En las ltimas dcadas el objetivo de los sistemas de informacin no es simplemente servir a las necesidades operacionales sino tambin cubrir necesidades analticas de la informacin. En principio se utilizaron los mismos repositorios de datos para los diferentes propsitos referentes al procesamiento de informacin: de transacciones, batch y analtico. 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 informacin. Las principales razones para separar el entorno operacional del analtico radican en los datos que se utilizan, las tecnologas que los soportan y la comunidad usuaria, entre otras. Este trabajo presenta el entorno analtico o sistema para soporte de decisiones (DSS). En l, el DW cumple el rol de ser la nica fuente de datos consultable.

2.1

Evolucin de los Sistemas de Soporte de Decisiones

La evolucin de los DSS esta bien detallada en [Inm2002]. El autor plantea cmo fue la

evolucin natural de los sistemas y los problemas que originaron el diseo de un ambiente especfico con una arquitectura estructurada en diferentes niveles de informacin, centrada en un DW. A continuacin se resumen los hechos ms importantes que dieron origen a esta evolucin. Una vez que los sistemas de gestin haban sido implementados y funcionaban correctamente surgi la necesidad de obtener informacin 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 requera diferentes extracciones de acuerdo a la informacin buscada. Tambin utilizaba y reutilizaba estos datos para producir informacin, basndose en sus propias reglas y definiciones. As, el procesamiento de extracciones de datos comenz a formar una red de informacin que se asemeja a la estructura de una tela araa 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 extraccin a travs de la organizacin es tan comn que se le ha dado un nombre propio: arquitectura naturalmente evolutiva o arquitectura de evolucin natural.

10

Captulo 2 - Sistemas para Anlisis de Informacin

IndicadorA=x

IndicadorA=y

Figura 1. Arquitectura naturalmente evolutiva y problema de credibilidad de la informacin.

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 informacin. Estos problemas se hacen ms notorios con el crecimiento de la organizacin. La carencia de credibilidad de datos se puede ejemplificar en que un mismo indicador o reporte tiene resultados diferentes en puntos distantes de la organizacin (figura 1). Entonces pueden obtenerse reportes en conflicto y la informacin pierde credibilidad. La causa de estas inconsistencias es no tener a la informacin sincronizada. Las diferencias ms importantes en la forma de obtener la informacin final en general se deben a: La referencia temporal de los datos. Los perodos considerados difieren y/o la informacin no est actualizada a la misma fecha. Los algoritmos de clculo. Algunos criterios considerados de formas diferentes en la definicin de datos. El nivel de extraccin. Cada nivel de extraccin exagera los otros problemas que ocurren en los niveles anteriores. Datos externos considerados. Pueden ser de diferentes fuentes y por lo tanto contener informacin diferente. Mltiples fuentes. No contar con una fuente de datos en comn desde el comienzo. La productividad de este esquema es tambin un gran problema, especialmente cuando hay necesidad de analizar datos a travs 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 acompaar 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 extraccin de datos, cada uno de ellos debe ser personalizado y tiene que 11

Captulo 2 - Sistemas para Anlisis de Informacin

cruzar la barrera tecnolgica que use la compaa. 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. Adems 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 informacin. En la mayora de los casos para obtener determinada informacin hay que consultar datos que se encuentran en aplicaciones heredadas y que no estn integradas. En las aplicaciones a veces se encuentran datos que slo existen en un lugar y no pueden relacionarse con otras aplicaciones, datos distintos con igual nombre y datos iguales nombrados de diferentes formas. La integracin de datos es un tema muy importante a la hora de querer obtener informacin. Otro obstculo para realizar esta tarea es la falta de datos histricos en las aplicaciones. Es frecuente que en las bases de datos transaccionales slo se guarden los datos para cumplir las necesidades operacionales, que suelen no ser suficientes para satisfacer las necesidades analticas4. Los requerimientos de evolucin propios de los sistemas de gestin los hacen inadecuados para soportar las necesidades de los DSS. Carecen de integracin y existe una discrepancia entre el horizonte de tiempo necesario para el procesamiento analtico y el existente en las aplicaciones. Adems esta arquitectura no es suficientemente robusta para alcanzar las necesidades futuras. Entonces se necesita un cambio estructural importante.

Nivel Operacional Informacin: Detallada Da a da Valores corrientes/actuales Alta probabilidad de acceso Orientado a aplicaciones

Nivel del Data Warehouse (datos atmicos) Informacin:

Mayormente detallada

(most granular) Asociada a perodo de tiempo (time variant) Integrada Orientada a una o ms temticas (subject oriented) Algo agregada o resumida (some summary).

Nivel Departamental (Data Marts) Informacin: Parcializada, correspondiente al rea en cuestin (parochial) Contiene algunos datos derivados y otros primitivos.

Nivel Individual Informacin: Temporaria

Ad hoc

Heurstica No repetitiva Basada en pc o estaciones de trabajo.

Figura 2. Arquitectura de los sistemas para la toma de decisiones diseada en funcin de los niveles de informacin.

El SIU-Guaran s mantiene la informacin histrica. Este sistema no tiene las caractersticas de un sistema transaccional tpico donde se cargan continuamente operaciones y se maneja un gran volumen de informacin diaria, como podra ser un sistema de ventas por menor o un sistema de registro de transacciones bancarias, o de reservas de vuelos. 5 Entindase ad hoc como un anlisis particular con un fin especfico.

12

Captulo 2 - Sistemas para Anlisis de Informacin

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 compaa. Los derivados son datos sumarizados o de algn modo calculados para cumplir con las necesidades de la gestin de la compaa. 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 histricos. Los datos primitivos son operados sobre procedimientos repetitivos mientras que los derivados son operados heursticamente, por programas y procedimientos analticos. 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 gestin acadmica, un dato primitivo sera: el alumno Juan Prez matrcula 6767 rindi la materia Anlisis matemtico I, cuyo cdigo es 7865, el da 20/10/2005; aprob con calificacin 8, y fue registrado en el acta X, folio Z. En contrapartida, el dato derivado sera: Juan Prez rindi 5 materias durante el 2005, aprob el 80% de los exmenes rendidos durante ese ao 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 histricos 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 anlisis heurstico. A este nivel, de anlisis gerencial, se utiliza informacin agregada. Como se puede observar en la figura el DW se constituye como el repositorio central y nica fuente de datos consolidados para anlisis de informacin. Cumple un rol fundamental y debe tener determinadas caractersticas para asegurar el correcto funcionamiento de esta arquitectura.

13

Captulo 2 -

2.2

Qu es un Data Warehouse?
En forma sencilla se puede decir que un DW es una coleccin de datos, obtenidos a partir

de los datos transaccionales y especficamente estructurados para realizar consultas y analizar la informacin [Kim1992]. Comnmente se dice que los DW son fuentes secundarias de informacin pues no generan datos por s mismos, sino que son alimentados desde sistemas existentes internamente en la organizacin o desde datos externos. Tpicamente los usuarios del DW tienen slo permisos de lectura sobre este repositorio de datos. Los DW o bases de datos para procesamiento analtico (OLAP) estn especficamente estructurados o diseados 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 diseo de DW donde las consultas son slo de lectura [Mst2005]. En contrapartida, las metas de un diseador de DW deben focalizarse en entregar un anlisis multidimensional y capacidades de reportes ad hoc6 [Mst2005] y brindarlos de manera eficiente. Estos requerimientos necesitan un diseo especfico de la base de datos, que se presenta en el captulo siguiente como diseo o modelo multidimensional. La definicin ms tradicional del trmino DW fue especificada por Bill Inmon a principios de la dcada de los 90, quin lo defini como una coleccin de datos orientados al sujeto, integrados, variables en el tiempo y no voltiles para ayudar al proceso de toma de decisiones gerenciales [Inm2002] [Mst2005], donde: Orientados al Sujeto: datos que brindan informacin sobre un sujeto o asunto del negocio en particular, en lugar de concentrarse en la dinmica de las transacciones de la organizacin. Se dice que un DW est orientado a los sujetos de una organizacin 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 exmenes, gestin de ttulos, etc. Integrados: los datos con los que se nutre el DW provienen de diferentes fuentes y son integrados para dar una visin global coherente. Cuando se integran datos de diferentes fuentes hay que contemplar cuestiones como la estandarizacin 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 estn asociados con un perodo de tiempo especfico. En los sistemas operacionales se lleva tanto informacin asociada a algn perodo de tiempo, por ejemplo el ao acadmico en que el alumno ingresa a la carrera, o fecha en que rinde un examen; as como tambin se lleva informacin corriente, ligada al momento actual, por ejemplo condicin de regularidad de los alumnos. Cuando
6

Reportes ad hoc refiere a la generacin de reportes personalizados por parte de usuarios expertos basados en el conocimiento del negocio. Ms adelante en este trabajo se explica en detalle las caractersticas de anlisis multidimensional y ad hoc.

14

Captulo 2 -

se extraen datos de los sistemas fuentes para pasar al DW estos quedan asociados siempre a un perodo de tiempo en el que esa informacin es vlida. 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 algn 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 prctico. No voltiles: los datos son estables en el DW. Se pueden agregar ms datos, pero los datos existentes no son removidos. Cuando un dato ingresa al DW se carga como una foto, esttica. Si ocurren cambios se cargan fotos nuevas y se mantiene la historia. Obviamente que esta definicin, ya clsica, se debe tomar como la definicin pura sobre DW. Sin embargo, con los aos, algunos trminos han sido modificados segn las necesidades y capacidades del mercado, dando origen a otros conceptos como el de Data Marts (para referirse a DW sobre reas especficas en lugar del warehouse corporativo) y otras variantes de DW donde por ejemplo es vlido actualizar datos ya existentes.

2.3

Objetivos de un Data Warehouse

Una de la las cosas ms valiosas de una organizacin es su informacin. 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 anlisis y se extrae informacin. El DW vendra 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 organizacin. En [Kim1998] se establecen como requerimientos las siguientes consideraciones de calidad: El DW debe proveer acceso fcil a la informacin de una organizacin. Informacin accesible significa que administradores y analistas de una organizacin deben poder conectarse al DW desde sus computadoras personales. La conexin debe ser inmediata, a demanda y de alta velocidad. No es aceptable que el acceso sea a travs de otra persona, sea inseguro o lento. El DW no es slo los datos, sino tambin un conjunto de herramientas para consultar, analizar y presentar la informacin. Las herramientas de acceso deben ser simples y fciles 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

Captulo 2 -

Los datos del DW deben ser consistentes y de buena calidad. La informacin del DW debe ser creble. Consistencia implica resolver las correspondencias entre la informacin de diferentes partes de la organizacin. Si dos medidas de una organizacin tienen el mismo nombre deben tener el mismo significado. Inversamente si dos medidas difieren en significado deben etiquetarse de manera distinta. Informacin consistente y de alta calidad significa que toda la informacin debiera ser tenida en cuenta y que es completa. Tambin 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 informacin, 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 reingeniera del negocio. El DW no puede arreglar la pobre calidad de los datos. Si los datos son opcionales y no estn 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 sera contar con datos de mejor calidad. De esta forma el DW puede jugar un rol clave en los esfuerzos de reingeniera del negocio de una organizacin.

Debe ser una fuente de informacin adaptable y flexible a los cambios. El DW debe estar diseado para manejar los cambios continuos de las necesidades de los usuarios, las condiciones del negocio, los datos y las tecnologas. 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 informacin se encuentre protegida. El DW contiene informacin muy valiosa para la organizacin. Es necesario que existan controles de acceso efectivo a los datos. Tambin se debe permitir a sus dueos 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 slo una verdadera salida del DW: las decisiones que son tomadas a partir de l. El DW tendr ms valor cuanto ms 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 solucin construida es elegante y usa los mejores productos y plataformas si el DW no se utiliza para el propsito que fue concebido. Su uso muchas veces es opcional, a diferencia de los sistemas operacionales donde los usuarios estn obligados a

16

Captulo 2 -

utilizarlos. La aceptacin 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 usndolo activamente seis meses despus del entrenamiento, entonces habr fallado el test de aceptacin. De esta lista es fcil ver que para poder implementar exitosamente un DW se requiere mucho ms que un buen equipo tcnico. 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 ncleo de toda la arquitectura de un DSS.

Fuentes de datos (Sistemas operacionales y datos externos) rea de limpieza y transformacin de datos (Data Staging Area) rea de almacenamiento y presentacin de datos (DW y Data Marts) rea de anlisis de informacin (Herramientas de acceso a los datos, aplicaciones de usuario final)
Reportes

C A R G A

DW

E Data Mining

Proceso ETL

DATOS

INFORMACIN

Figura 3. Arquitectura tcnica de un sistema para la toma de decisiones basado en un DW.

A continuacin se dan las definiciones para cada componente del entorno, tomando como base bibliogrfica [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 informacin. Antes de describir a cada elemento se aclara que el grfico de la figura 3 es una adaptacin propia de los vistos en la bibliografa y dems referencias consultadas y est basado principalmente en la propuesta de [Kim2002] [Kim1998]. Se puede observar la correspondencia con los niveles de informacin planteados en la figura 1. Esta arquitectura tambin concuerda la arquitectura La Fbrica de Informacin Corporativa (CIF)7. La propuesta de Kimball no coincide
7

Ver grficos en referencias [10] y [11] de la seccin de bibliografa.

A C C E S O

Servicios: limpieza, combinacin y estandarizacin. Ajustar dimensiones comunes. No hay servicios de consultas de usuarios. Almacenamiento de datos: archivos planos y tablas relacionales. Procesamiento: ordenamiento y procesamiento secuencial

Alertas

OLAP (interfaces)

Scorecards & Dashboards

CONOCIMIENTO

17

Captulo 2 -

en la forma de plantear la existencia fsica 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 unin de estos, que deben basarse en hechos (facts) y dimensiones acordadas. La visin de Inmon es ms integradora, considera al DW como la fuente central de informacin 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 construccin de un DW como unin de estos (desarrollo bottom-up). Ambas propuestas son vlidas y depender del problema particular cul puede resultar ms apropiada. Si el diseo 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 definicin de dimensiones y hechos conformados es esencial para el xito a largo plazo de esta metodologa de trabajo. Se observa que el grfico de la figura 3 no considera un aspecto importante como es la retroalimentacin en lo que respecta a la calidad de datos. El anlisis de determinada informacin generalmente genera nuevas necesidades. Cuando se profundiza en la informacin 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 evolucin del sistema. Esta retroalimentacin y evolucin es un proceso cclico.

Fuentes de datos
Los sistemas operacionales son las fuentes de datos principales donde se registra toda la gestin de la organizacin. Son los sistemas centrales que soportan las operaciones diarias del negocio. Se acceden a travs de las interfaces de las aplicaciones (APIs). Los datos que recopilan estos sistemas son la principal fuente de informacin del DW. Tambin se los conoce como sistemas transaccionales o sistemas heredados. El xito o fracaso de toda la solucin de DW depende fuertemente de que los sistemas operacionales provean los datos necesarios para entender el negocio y la historia necesaria para evaluar su evolucin. La calidad de los datos de estos sistemas es fundamental. Otras fuentes pueden ser datos externos a la organizacin (informacin demogrfica, crediticia, financiera, etc. por ejemplo la cotizacin de alguna moneda), planillas de clculos, etc.

Limpieza y transformacin de los datos

Se utiliza el trmino 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 transformacin de datos. Las tareas principales de esta rea son el ordenamiento y procesamiento secuencial de datos.

18

Captulo 2 -

Este componente no provee ningn servicio de consulta ni presentacin de informacin, simplemente porque esta rea no est pensada ni preparada para brindar la seguridad y tiempo de respuesta propios del rea de almacenamiento o presentacin 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 creacin de ndices es otra tarea que tambin puede considerarse parte de esta etapa de gestin de datos. El proceso de Extraccin, Transformacin y Carga de datos El trmino popular ETL corresponde a la sigla en ingls de Extract-Transform-Load 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 organizacin y el rea de almacenamiento y presentacin de datos. Aporta los mtodos y herramientas necesarias para mover datos desde mltiples 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 gestin de los datos, adquisicin de datos y en ingls data staging o data cleansing. Cabe destacar que la integracin y transformacin de datos es uno de los procesos ms importantes de todo el entorno del DW. Tiene la tarea crtica de convertir el caos de datos del mundo operacional en un mundo ordenado de informacin. Este proceso asimila datos procedentes de tecnologas heterogneas dentro de un entorno integrado y consistente, apto para ser consumido por los procesos de soporte de decisiones. Uno de los mayores desafos se produce cuando los datos recibidos provienen de fuentes que los han organizado alrededor de claves diferentes. Por ejemplo en el SIU-Guaran una persona se identifica por el nmero de inscripcin dentro de una unidad acadmica. En el SIUPampa8 la identificacin de la persona se hace por su nmero de legajo. Estas fuentes necesitan ser integradas para dar una visin nica de persona. Este proceso puede involucrar sofisticadas reglas de mapeo de elementos, normalizaciones y estandarizacin de nombres, direcciones y otros datos comunes a las fuentes para determinar cuales son los datos vlidos. El nivel de esfuerzo necesario para integrar y transformar datos est fundamentalmente afectado por el nivel de conocimiento que se tenga sobre estos. Cuanto ms familiar resulten los datos operacionales y los procesos que los producen ms fcil resultarn 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 continuacin se detallan las tareas que incluye:
8

El SIU-Pampa es el sistema utilizado en las universidades para la gestin de recursos humanos y la liquidacin de sueldos.

19

Captulo 2 -

Limpieza de datos. Consiste en la correccin de errores de tipeo, resolucin de dominios conflictivos (por ejemplo una ciudad que es incompatible con el cdigo postal), manejo de datos perdidos (nulos o vacos, referencias a datos que no existen), conversin a formatos estandarizados, y resolucin de inconsistencias.

Seleccin de atributos que son tiles para el DW. Por ejemplo, si lo que se quiere analizar es el rendimiento acadmico de los alumnos interesar saber, entre otras cosas, cuntas materias aprueba por ao. Puede resultar til saber cules son esas materias y las notas obtenidas; pero no interesar saber el nmero de acta y folio donde se registr esta informacin ni el da en que el dato fue ingresado al sistema.

Combinacin 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 SIU-Guaran de diferentes unidades acadmicas de una universidad9. La informacin de colegios secundarios era mantenida en forma independiente y no sincronizada en las diferentes implementaciones. Cada unidad acadmica generaba sus propios cdigos y nombres. Al integrar los datos se hallaron casos como los mostrados en la figura siguiente.
Unidad acadmica Facu1 Facu2 Facu2 Facu1 Cdigo de colegio Cod1 Cod1 Cod2 Cod3 Colegio correspondiente Cole1 Cole2 Cole1 Cole1 Descripcin utilizada Desc1Cole1 Desc1Cole2 Desc2Cole1 Desc3Cole1 Ejemplo Escuela Normal Superior N1 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 dimensin y evitar la dependencia de las claves definidas en las fuentes. El proceso de generacin 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 dimensin es que sean numricas 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 lnea conductora en todo el proceso de anlisis de informacin 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 tambin el nombre de carga en masa. La creacin de agregados, esto es informacin agrupada que se guarda en el DW, as como tambin la creacin 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 mayora de las universidades la implementacin del SIU-Guaran se realiza por unidad acadmica, 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 estn en el captulo siguiente dentro de la seccin de modelado multidimensional.

20

Captulo 2 -

Almacenamiento y presentacin de los datos

El rea de almacenamiento y presentacin de datos, tambin denominada servidor de presentacin 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 definicin de DW se present en la seccin 2.2. Como se anticip la definicin clsica ha dado origen a otros conceptos para adaptarse a las diferentes realidades. El trmino ms resonante es el de Data Mart. Un Data Mart es un subconjunto lgico del DW. Contiene datos personalizados y/o sumarizados derivados del DW, confeccionados para soportar los requerimientos analticos de un determinado sector o funcin del negocio. Cada Data Mart utiliza una visin empresarial comn de los datos estratgicos y provee sectorizaciones ms flexibles. Entre las caractersticas de los Data Marts se destacan: Los Data Marts pueden o no localizarse fsicamente en la misma mquina que el DW. Esto permite a los consumidores de la informacin elegir la mejor tecnologa que soporte el estilo de anlisis que necesiten. Los Data Marts deben ser implementados como una extensin 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 construccin de Data Marts para soporte de decisiones es ideal. Sin embargo hay que tener en cuenta que la simplicidad de su diseo puede conducir a tener mucha cantidad de ellos implicando as un alto costo para administrarlos. Kimball define a un Data Mart como una porcin de la torta completa que representara el DW. As mismo este autor presenta una metodologa bottom-up comenzando por el desarrollo de Data Marts para construir luego un DW como unin de estos. Argumenta que un Data Mart representa un proyecto que puede llegar a ser terminado comparado con la imposible responsabilidad galctica de desarrollar un DW. Generalmente se ve al Data Mart como una restriccin 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 especficos de diseo. 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 adhesin a esta arquitectura un Data Mart se convierte en una solucin especfica y aislada que no puede ser compartida con otras reas del negocio en lugar de pertenecer a una solucin en conjunto. Si los Data Marts se disean con dimensiones y hechos conformados es posible combinarlos y usarlos juntos [Kim1998]. Se dice que las dimensiones estn conformadas o
11

Kimball utiliza el trmino fact (hecho) como sinnimo de medida o mtrica. Debe interpretarse as cuando se hace referencia a hechos conformados o pactados. En general en este trabajo se utiliza el trmino hecho para referirse ms bien al evento que tiene asociadas medidas, que a las medidas en s.

21

Captulo 2 -

pactadas cuando son exactamente iguales (incluyendo las claves) o una es un perfecto subconjunto de la otra. Si dos dimensiones estn conformadas pueden ser combinadas perfectamente. Hechos o medidas de mltiples tablas estn conformados cuando las definiciones semnticas de estos son equivalentes. Si tienen esta caracterstica pueden tener el mismo nombre en tablas separadas y pueden ser combinados y comparados matemticamente. Si los hechos no concuerdan entonces cada interpretacin debe recibir un nombre diferente. No se cree que los dos puntos de vista sobre la construccin top-down y bottom-up de un DW sean contradictorios. La perspectiva extrema top-down es completamente centralizada, la base de datos principal se debe disear totalmente antes de que sus partes sean sumarizadas y publicadas en Data Marts individuales. La perspectiva extremadamente bottom-up es que el DW de toda la organizacin puede ser ensamblado a partir de Data Marts dispares y no relacionados. Ninguno de estos extremos es prcticamente posible. La idea es entonces combinar ambas propuestas, teniendo una arquitectura que gue el diseo de todas las piezas separadas [Kim1998].

Anlisis de informacin
En la figura 3 se ejemplifican diferentes estilos de anlisis de informacin. Estos estilos se implementan con diferentes herramientas y aplicaciones. Todo esto forma parte del rea de anlisis de informacin. Listados en texto plano y planillas de clculo usadas para la toma de decisiones tambin pueden incluirse dentro de esta rea. A continuacin se proveen las definiciones de las herramientas ms usadas para el anlisis de informacin: Aplicaciones de usuario final. Se refiere as a la coleccin de herramientas que consultan, analizan y presentan informacin buscada para soportar una necesidad del negocio. El conjunto mnimo de estas aplicaciones de usuario consiste de herramientas de acceso a datos, planillas de clculo, paquetes grficos, 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 grfico. 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 deteccin de patrones y pronsticos. Herramientas de consultas ad hoc. Son un tipo especial de herramientas de acceso a datos que invitan a los usuarios a disear sus propias consultas en el momento. Es difcil tener un patrn de consultas cuando se utiliza anlisis ad hoc. Por este motivo es conveniente que el modelo de la base de datos sea lo ms simtrico posible para que todas las consultas luzcan igual. Esta es una fortaleza del modelado multidimensional de un DW. 22

Captulo 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 analticas. Se trata de aplicaciones de acceso a datos preconstruidas previstas para usuarios que consultan el DW no muy frecuentemente. Tpicamente parametrizadas con flexibilidad para analizar innumerables combinaciones. Tales aplicaciones representan una oportunidad de encapsular las mejores prcticas de anlisis de una organizacin. Aplicaciones para anlisis de riegos, o anlisis de mercados son algunos ejemplos. Aplicaciones estadsticas. Son aplicaciones establecidas para realizar anlisis estadsticos difciles y complejos como anlisis de excepciones, medias, promedios y patrones. El DW es la fuente de datos para estos anlisis. 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 analticas que transforman o resumen la salida del DW. Dentro de estas aplicaciones se encuentran, entre otras: Modelos de pronstico (forecasting) que buscan hacer predicciones analizando comportamientos pasados. Modelos de clasificacin de comportamientos (clustering) que agrupan y clasifican perfiles. Por ejemplo, en el mbito universitario se podra agrupar alumnos segn caractersticas personales, demogrficas o socio econmicas. Minera de datos. Son un tipo de consultas indirectas que buscan encontrar patrones ocultos en los datos. Los resultados ms valiosos son agrupamientos, clasificaciones, estimaciones, predicciones, y asociaciones de cosas que ocurren juntas12. Hay muchos tipos de herramientas para minera de datos. Las principales incluyen rboles de decisin, redes neuronales, razonamiento basado en casos o reglas de asociacin, herramientas de visualizacin, algoritmos genticos, lgica difusa, y estadstica clsica. Esta rea tambin recibe el nombre de descubrir conocimiento en bases de datos KDD (Knowledge Discovery in Databases).

2.5

Aplicaciones tradicionales versus aplicaciones para anlisis de informacin

Para finalizar la descripcin del entorno del DW y antes de desarrollar las perspectivas y

tcnicas necesarias para disearlo, hay que resaltar una caracterstica importante: el DW es muy diferente a los sistemas transaccionales u OLTP. Las diferencias radican en: los objetivos principales de construccin, el perfil de los usuarios y sus necesidades, los datos que contienen
12

Un ejemplo tpico en el anlisis de compras en supermercados es el patrn que indica que las personas que compran paales compran cerveza. Este tipo de resultados sirve para decidir la distribucin de las gndolas.

23

Captulo 2 -

(resaltando diferentes aspectos de estos: orientacin o alineacin de su estructura, integracin e historicidad), el acceso y manipulacin de datos (patrones de uso, ritmos de carga de datos, administracin de datos, etc.). Tambin difiere el hardware, el software, la administracin y la gestin del sistema. Todo esto hace que las tcnicas e instintos de diseo 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].

Caracterizacin de las diferencias

Sobre los objetivos principales Los OLTP tienen como objetivos asistir a aplicaciones especficas, y mantener la integridad de los datos. Mientras que los OLAP apuntan a asistir en el anlisis del negocio, identificando tendencias, comparando perodos, gestiones, mercados, ndices, etc. mediante el almacenamiento de datos histricos. Sobre el perfil de usuarios El perfil del usuario que interacta con los sistemas OLTP se encuadra dentro de los empleados operativos de una organizacin. Los usuarios de un OLTP hacen que la compaa funcione. Tienen como funcin principal la entrada de datos. Tambin 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 estratgico y el nivel de informacin 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 organizacin y definen el rumbo a seguir. Miran qu datos son nuevos, piden que los datos errneos 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 pequeo 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 vara en ir a buscar de cientos a millones de registros para ser resumidos en el pequeo conjunto de respuesta. Sobre los datos Los datos existentes en el ambiente transaccional difieren de los del entorno analtico en las siguientes caractersticas: Alineacin de los datos: los OLTP estn alineados por aplicacin. Diferentes sistemas tienen distintos tipos de datos, los cuales son estructurados por aplicacin. Se focaliza en el cumplimiento de requerimientos de una aplicacin o una tarea especfica.

24

Captulo 2 -

En cambio, los sistemas OLAP estn alineados por dimensin. Todos los tipos de datos estn integrados en un solo sistema. Los datos son organizados definiendo dimensiones del negocio (reas temticas o sujetos). Se focaliza en el cumplimiento de requerimientos del anlisis del negocio. Integracin de datos: los datos tpicamente no estn 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 temticas, necesita integrar datos operacionales estandarizando estructuras y convenciones de nombres. Historia: Los OLTP usualmente retienen datos por un perodo de tiempo determinado, despus son resguardados en almacenamientos secundarios fuera de lnea. Tambin es comn que contengan slo valores corrientes, referentes a la situacin actual, y no valores histricos. Puede no incluir el tiempo como un componente de la clave. En cambio los OLAP almacenan tanta historia como sea necesario para el anlisis del negocio. Retienen los valores de cada perodo. Es decir, almacenan una serie de fotos instantneas de datos operacionales. La frecuencia con la cual se define el nivel de detalle es la que se indica como nivel ms bajo de la dimensin tiempo. Toda esta cantidad y tipo de historia apunta a ayudar a la generacin de reportes de comparacin de tendencias y perodos de tiempo. Por otro lado, las bases de datos orientadas al anlisis siempre contienen el tiempo como clave dado que una de las principales razones para la construccin del DW es el almacenamiento de datos histricos y el anlisis a lo largo del tiempo. Sobre el acceso y manipulacin de los datos Las diferencias de ambos ambientes en los objetivos, usuarios y datos implican naturalmente que tanto el uso como la administracin de los datos sean diferentes. Se pueden destacar los siguientes puntos:

25

Captulo 2 -

Ritmos de actualizacin Un sistema OLTP tpico, como puede ser un sistema de venta por menor en un supermercado, un sistema de reserva de vuelos, o un sistema para cajeros automticos, etc. procesa miles o incluso millones de transacciones por da. Cada transaccin contiene una pequea pieza de datos. Un sistema OLAP procesa una nica transaccin diaria que contiene miles o incluso millones de registros. En lugar de llamarse transaccin se la denomina carga de datos de produccin o copia masiva.

Patrones de uso Los sistemas transaccionales normalmente mantienen un patrn de uso constante requiriendo grandes cantidades de recursos y consumiendo slo el tiempo referido a la transaccin. En contraposicin, los DW tienen un patrn de uso liviano con picos de usos eventuales en el tiempo. Los picos de uso suceden cuando los datos nuevos estn por primera vez disponibles y los das en que el negocio necesita determinados reportes.

Manipulacin de datos Los sistemas operacionales realizan una manipulacin de datos registro por registro con funcionalidades de actualizacin de datos. Adems necesitan de rutinas de validacin y operaciones a nivel de registro. Generalmente involucran pocos datos en un proceso o transaccin. Para el procesamiento de transacciones la base de datos dispara mecanismos de bloqueos y asignacin 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 validacin de datos se realiza antes o despus de la carga. Principalmente se realizan consultas sobre varios registros y tablas, teniendo grandes volmenes de datos involucrados en un nico proceso o anlisis. Es por ello que generalmente no se respetan las formas normales tan necesarias en los sistemas operacionales clsicos. Las anomalas que tienden a subsanar estas reglas de normalizacin no se presentan en los sistemas OLAP donde la carga de la informacin 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 100.000 registros (al menos no se permiten mientras el sistema transaccional est siendo accedido por usuarios). La mayora de los reportes de un OLTP son listados de tablas enteras. La administracin de estos sistemas se basa en el aseguramiento de la performance y la confiabilidad. Los procesos de extraccin de datos para anlisis suelen ejecutarse en horarios en que el sistema operacional no est en produccin.

26

Captulo 2 -

La performance en un DW es tan importante como en un sistema OLTP, pero de una forma diferente. Se esperan tiempos de respuesta rpidos a consultas agrupadoras de datos que requeriran 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 estn altamente involucrados con la consistencia de los datos. Sin embargo en los sistemas OLTP la consistencia es microscpica. 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 microscpica se tiene una perspectiva de aseguracin de calidad. En lugar de un clculo tcnico de consistencia existe una visin o juicio gerencial de esta. Se tiene cuidado sobre los estados consistentes del sistema antes de comenzar la carga de datos de produccin y al finalizarla con xito. Si forzadamente hubiera que detener una carga de datos de produccin antes de que est completa, no se podr volver atrs 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 fsico para anlisis de informacin

En sus orgenes el trmino OLAP estuvo asociado exclusivamente a bases de datos propietarias multidimensionales, tambin denominadas cubos13, que fue la arquitectura predominante para DW durante la dcada del 80. Con la evolucin de las bases de datos en cuanto a funcionalidad y rendimiento a principio de los 90s comienzan a desarrollarse DW en motores de base de datos relacionales, dando origen a los conceptos OLAP multidimensional (MOLAP), OLAP relacional (ROLAP) y OLAP Hbrido (HOLAP). En la seccin anterior se explic en detalle los sistemas OLAP. Brevemente se puede decir que se refiere a la actividad general de consulta y presentacin de datos numricos y de texto desde el DW as como tambin el estilo dimensional de la consulta y presentacin de la informacin. El procesamiento analtico es el uso de los datos para tomar decisiones del negocio. Frecuentemente involucra anlisis de tendencias, comparaciones de perodos, y navegacin de datos. El modelo lgico de los datos para OLAP debe seguir el diseo multidimensional. Sin embargo la tecnologa de la base de datos donde se implementa puede ser multidimensional o relacional, dando origen a tres categoras de productos OLAP: MOLAP, ROLAP y HOLAP.

13

El concepto de cubo ser presentado en el captulo siguiente.

27

Captulo 2 -

OLAP Multidimensional (MOLAP) Refiere a una tecnologa de bases de datos multidimensional y propietaria, tambin denominada cubo de datos. La performance es la caracterstica 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 ms espacio de disco y diferente software. OLAP Relacional (ROLAP) Es una tecnologa 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 informacin a agrupar es muy grande. OLAP Hbrido (HOLAP) Es una combinacin de los anteriores. La palabra que describe a esta tecnologa 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 anlisis para identificar cada tipo de dato. Comparacin de las distintas implementaciones ROLAP es una arquitectura flexible y general, que crece para dar soporte a amplios requerimientos OLAP. MOLAP es una solucin particular, adecuada para soluciones departamentales con volmenes de informacin y nmero de dimensiones ms modestos. Al momento de optar por una de estas tecnologas debern 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 organizacin. La tendencia del mercado de estas herramientas es hacia los sistemas HOLAP. Tanto los proveedores clsicos de MOLAP como los ROLAP estn incluyendo el otro estilo dentro de su solucin para abarcar las ventajas de ambos: gran capacidad de anlisis 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 mayora de los Data Marts como cubos multidimensionales, que pueden estar conectados al DW mediante consultas prediseadas para mostrar informacin ms detallada.

28

Captulo 2 -

2.6

Tendencias en sistemas para anlisis de informacin

El DW es el corazn de un DSS. El trmino DSS se suele usar como sinnimo de Data

Warehousing y de Business Intelligence. En un sentido estricto, las definiciones de estos conceptos presentan algunas diferencias. El trmino Data Warehousing se utiliza para referir al conjunto de herramientas, tecnologas y metodologas que permiten la construccin, 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 anlisis de muchas unidades de datos de una manera heurstica. Un DSS da soporte a los tomadores de decisiones en cualquier nivel gerencial, tanto en situaciones semi-estructuradas y no estructuradas, a travs de la combinacin del juicio humano e informacin objetiva. De alguna manera es el nombre precedente a Data Warehousing, y el hecho de usar los datos para tomar decisiones en una organizacin es el fundamento de la existencia del DW. Como regla general, el procesamiento DSS no involucra la actualizacin de datos, sino que slo provee los mecanismos de acceso a los datos que estn en el DW y el anlisis de estos. Un DSS debiera estar basado en tcnicas de Data Warehousing, pero ambos conceptos tienen existencia propia. Durante mucho tiempo las organizaciones trabajaron con DSS pero no tenan el volumen ni la calidad de informacin que brinda el DW. Por otro lado, los DW pueden ser utilizados en sistemas expertos que guardan informacin histrica. Las tareas de aprendizaje, como las de anlisis predictivos, escapan el alcance del concepto clsico de DSS y dan origen al trmino Business Intelligence (BI). La inteligencia de negocio o inteligencia empresarial, hace referencia al conjunto de estrategias y herramientas enfocadas a la administracin y creacin de conocimiento mediante el anlisis de los datos de la organizacin o empresa. Este conjunto de herramientas y metodologas tienen en comn las caractersticas de garantizar el acceso a la informacin 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 tcnicos. El desafo principal de BI es reunir y presentar de manera organizada la informacin referente a todos los factores relevantes que conducen el negocio y habilitar el acceso al conocimiento a los usuarios finales de manera fcil y eficiente, con el efecto de maximizar el xito de una organizacin. Existen cinco estilos diferentes y complementarios de BI, a saber: [3] [4] Anlisis OLAP. Es el BI ms clsico y universal. Esta funcionalidad provee la forma ms sencilla de anlisis, 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 histricas.

29

Captulo 2 -

Tableros de comandos y paneles de control (scorecards y dashboards). Proveen facilidades de anlisis sumariado y altamente repetitivo, en lnea, focalizado en determinados tpicos. Se basa en una serie de indicadores. Es apropiado para gerentes y ejecutivos que requieren una visin integral del rendimiento del negocio y hacer seguimientos exhaustivos a travs del tiempo de temas especiales.

Notificaciones de alertas y excepciones (broadcasting). Transmiten informacin a diferentes puntos de la organizacin cuando determinados hechos suceden. Un anlisis que no es en lnea.

Reporte empresarial (enterprise reporting). Generacin de informacin con alto nivel de detalle para un nivel gerencial que se utiliza para tomar decisiones. Es el estilo de BI ms utilizado. El nfasis est en la parte grfica. No es en lnea ni como tableros. Lo que importa es la presentacin.

Anlisis avanzados y predictivos (data mining). Anlisis estadstico de datos para generar patrones predictivos, pudindose 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 tcnico las reas ms importantes incluidas dentro de BI son [14]:

DW arquitectura, diseo, administracin, procesamiento y carga. Limpieza de datos y aseguramiento de la calidad (incluye el proceso ETL). Data mining, anlisis estadsticos y pronsticos. OLAP procesamiento analtico en lnea y anlisis multidimensional. DSS, Sistemas de Informacin Ejecutiva (EIS), y otros sistemas expertos, agrupados en el trmino de Gestin de Sistemas de Informacin (Management Information Systems o MIS). Sistemas para analizar la informacin de otros sistemas y que sirve para la toma de decisiones.

Elaboracin de reportes, visualizacin de informacin y paneles de control (dashboards). Gestin en relacin con los clientes (Customer Relationship Management o CRM). Otras definiciones utilizadas en sistemas de anlisis de informacin:

Sistemas de Informacin Ejecutiva (EIS: Executive Information Systems). Son sistemas diseados para los ejecutivos ms altos de una organizacin. Entre las caractersticas ms importantes permiten anlisis 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 informacin 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 compaa tenga acceso, de manera instantnea, al estado de los indicadores de negocio que le afectan, con la posibilidad de estudiar con 30

Captulo 2 -

detalle aquellos aspectos que no estn cumpliendo con los objetivos establecidos en su plan estratgico u operativo, y as determinar las medidas de contingencia ms adecuadas. Una de las caractersticas ms importantes de un EIS es que permite a usuarios con perfil no tcnico construir nuevos informes y navegar por los datos de la compaa, con el objetivo de descubrir informacin que les resulte relevante. Esto se debe, entre otras cosas, a que la interfaz grfica de estas aplicaciones suele ser muy atractiva e intuitiva. El EIS suele incluir tambin alertas de negocio, informes histricos comparativos y anlisis de tendencias. Un EIS suele necesitar de un DW o Data Mart que acte como fuente central de informacin, unificando, depurando e integrando las distintas bases de datos operacionales de la compaa [15]. Fbrica de informacin corporativa (CIF: Corporate Information Factory). Es un modelo de arquitectura propuesto por Inmon que contiene un DW, Data Marts, un almacn de datos operativos (ODS), sistemas operativos, aplicaciones para soporte de decisiones, distintas interfaces para usuarios, herramientas de data mining y dems componentes. Amplia la arquitectura de la figura 3. Para obtener ms detalles consultar referencias [10] y [11]. Almacn de datos operativos (ODS: operacional data store). Un ODS es una coleccin de datos orientada a temticas (subject-oriented), integrada, con valores actuales y voltiles, usada para soportar el proceso de toma de decisiones tcticas para una organizacin o la administracin del negocio. Este concepto difiere del de DW por contener datos actuales en lugar de histricos y voltiles en lugar de permanentes. Los DW y Data Marts estn orientados principalmente a soportar procesos de decisiones estratgicas. El ODS es el ncleo de la administracin del negocio (business management). Ambos conceptos se complementan. No siempre es necesario implementar un ODS, slo 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 informacin. La razn 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 slo prever reportes y soporte de decisiones hay que evaluar su implementacin y ver si estas necesidades no debieran ser cubiertas directamente por el DW. Como un ODS es necesariamente una extraccin de datos transaccionales, este puede tambin jugar el rol de fuente del DW.

31

Captulo 2 -

2.7

El mercado de Data Warehousing y Business Intelligence

En los ltimos aos la utilizacin de este tipo de soluciones ha crecido muchsimo dando

origen a una expansin del mercado y desarrollo de diferentes herramientas. No es objetivo de esta tesis realizar un anlisis del mercado. Se presenta slo un panorama muy general. Para interiorizarse en las caractersticas de cada solucin, 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 pequeas y especficas como otras abarcativas y ambiciosas, todas en continuo crecimiento e intentando cubrir mejor y ms aspectos dentro del rea de BI. Existen empresas de mediana escala que slo desarrollan soluciones de BI (denominadas pure-play), vendedores de mega-aplicaciones de software, y tambin soluciones pequeas, innovadoras y especializadas (denominadas niche players). El mercado actual est dominado por las soluciones pure-play, 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 ms 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 adems 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, segn 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 ms antiguos, operan desde los 80 MicroStrategy, SAS y SPSS. Cognos es muy fuerte en los Estados Unidos en empresas medianas y pequeas, mientras que Business Objects es lder en Europa. MicroStrategy es fuerte en sectores como venta por menor (retail) y en grandes empresas. SAS y SPSS son tradicionales lderes en data mining. Y el segmento en Argentina lo lidera MicroStrategy, seguido por Cognos, SAP, Oracle y Microsoft, en este orden. La razn principal es el tiempo que llevan instalados en el pas [3]. Otros proveedores importantes son: IBM, Pentaho, QlikView y Stratebi. La mayora de los proveedores (denominados players o vendors) de estas soluciones se han comenzado con uno de los estilos de BI, y luego fueron extendindose a los dems. Cuantos ms estilos abarca cada proveedor, obviamente brinda una solucin ms completa. La tendencia es tener una solucin 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 aos comenz la carrera por sumar los estilos faltantes. Algunos de los movimientos ms resonantes fueron la compra de Crystal 32

Captulo 2 -

Decisions (lder en enterprise reporting) que concret Business Objects. Oracle compr Siebel, Hyperion compr Brio, y Cognos a Adaytum y tambin a Applix. Y las ms 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. Tambin hubo cantidad de operaciones ms pequeas. 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 lderes en tecnologa de informacin se consoliden tambin como lderes del mercado de BI. Tambin se espera un importante crecimiento de Pentaho, que es el ms completo de los productos de software libre. El fuerte de esta herramienta est en la interfaz para manipular y limpiar datos. Tiene diferentes mdulos para desarrollo de cubos, reportes, tableros de control, y data mining integrados. La solucin es an un poco dura en lo que respecta a funcionalidad e interfaz con el usuario, pero es uno de los casos ms prometedores por contar con licenciamiento gratuito. Para la implementacin del caso prctico 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 pas. Una de las ventajas de la herramienta es que permite una metodologa de desarrollo prctica y sencilla de implementar, adems de tener un costo de licenciamiento accesible.

33

Captulo 3 - El proceso de creacin de modelos analticos

El proceso de creacin de modelos analticos

En el captulo anterior se detallan las diferencias de ambientes y objetivos entre los

sistemas OLAP y OLTP. Estas diferencias hacen que las tcnicas de diseo y el modelo del ciclo de vida clsico utilizados para desarrollar un sistema operacional no resulten apropiados para el entorno analtico. En este captulo se presentan las tcnicas y metodologas principales para garantizar el xito de un proyecto de Data Warehousing.

3.1

Introduccin al modelado multidimensional

El modelado multidimensional es una tcnica para disear bases de datos simples y

entendibles. Se busca visualizar a la base de datos como si fuera un cubo de tres, cuatro, cinco o ms dimensiones. Cuando esto sucede, los usuarios finales pueden imaginarse navegando la informacin contenida, realizando cortes (slicing and dicing14) a ese cubo a travs 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 comprensin de estos. En un ejemplo simple aplicado al mbito acadmico universitario: los alumnos rinden exmenes de diferentes materias en alguna fecha, registrndose 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 exmenes rendidos.

Cualquier punto dentro del cubo es la interseccin 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 combinacin 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 accin de partir un cubo de informacin en cubos ms pequeos para focalizar el anlisis.

34

Captulo 3 - El proceso de creacin de modelos analticos

Dim_Alumno Alumno_cod Alumno_desc

Dim_Fecha Fecha Mes Ao

Examenes Dim_Materia Materia_cod Materia_desc Alumno_cod Materia_cod Fecha Nota

Figura 6. Ejemplo de modelo dimensional sencillo sobre exmenes rendidos.

En la figura 6 se muestra el modelo dimensional que refleja la situacin planteada, mientras que en las figuras 7 y 8 se puede apreciar parte del modelo tpico de dependencias entre datos15, permitiendo la comparacin entre ambos diseos.

Figura 7. Ejemplo de modelo de dependencias de datos del SIU-Guaran referente a exmenes rendidos.

Las figuras 7 y 8 ciertamente revelan con ms detalle las relaciones entre los datos que la figura del modelo dimensional, pero no contribuyen al entendimiento la situacin que describen 16. Desafortunadamente la mayora de las personas no pueden retener en la mente un diagrama como este y no pueden entender como navegarlo tilmente. Para el problema de anlisis de informacin, las relaciones existentes entre los datos se ven mejor dinmicamente en una pantalla que en diagramas estticos 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 tambin es llamado a veces diagrama entidad relacin (DER). Aunque no sean lo mismo. De hecho, tambin es posible usar un DER para representar un modelo dimensional. 16 Se muestran slo algunas tablas relacionadas con el ejemplo de todo el modelo de datos del SIU-Guaran. El modelo de datos real es ms complejo.

35

Captulo 3 - El proceso de creacin de modelos analticos

el mismo anlisis final. Es slo que se elige presentar los datos de una manera diferente, en un formato simtrico. En el ejemplo, el modelo dimensional provee un sentido natural para descomponerlo en los componentes alumno, materia y fecha. Los usuarios usarn la palabra dimensin en una conversacin estn o no visualizando un cubo de datos. La atraccin 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 SIU-Guaran. Detalle de tablas principales sobre informacin de exmenes rendidos.

La distincin entre los modelos dimensionales y de dependencias de datos est centrada en el diseo 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 propsito17. Un modelo dimensional se basa conceptualmente en uno o ms hechos. Cada hecho est asociado a una o ms 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 bsqueda o de catlogo). 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, tambin dimensionales, que se corresponden con los diferentes Data Marts. Cada Data Mart debe tener al
17

El DW debe responder a un modelo lgico multidimensional, ms 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 trminos hecho y medida, utilizndose el trmino fact para referirse a ambos. Aqu en general se utiliza el trmino hecho para referirse ms bien al evento o suceso a medir que a la medida, o mtrica en s.

36

Captulo 3 - El proceso de creacin de modelos analticos

menos una tabla de hechos, y en general tiene muchas tablas de dimensiones. Tambin 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 lneas o reas temticas 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 anlisis de la informacin. En el mbito universitario y sobre el anlisis de comportamiento acadmico de alumnos se podran considerar a las dimensiones: carrera, lugar de procedencia, ao de ingreso, entre otras. Cada elemento de una dimensin tiene una clave, que lo identifica en el mayor nivel de detalle y un conjunto de atributos. Los atributos representan categoras o agrupaciones de elementos y tienen la finalidad de mostrar a la informacin de cada dimensin en diferentes niveles de detalle y agrupar los elementos para ser analizados. Las relaciones entre los atributos de cada dimensin determinan jerarquas. Las jerarquas son ordenamientos lgicos y puede que exista ms de una jerarqua dentro de la misma dimensin, pero siempre podr identificarse una jerarqua principal. Por ejemplo para la dimensin lugar de procedencia, la clave est dada por la identificacin del colegio. El colegio determina a la localidad, la localidad a la provincia y esta ltima al pas, presentando cuatro niveles de granularidad para analizar a la informacin. La jerarqua principal (y nica de esta dimensin) est dada por los atributos pas, provincia, localidad y colegio, en ese orden. En este caso la relacin entre los atributos, vindola del nivel ms detallado al ms agrupado es siempre de muchos a uno. Este tipo de relacin padre-hijos en las jerarquas de atributos de una dimensin es el caso ms general, pero no el nico. Algunas de las soluciones, como es el caso de O3, tienen la limitacin de permitir modelar una jerarqua nica por dimensin y donde los niveles deben estar determinados por relaciones de tipo padre-hijos. En caso de necesitar representar diferentes jerarquas estas debern modelarse como dimensiones separadas19. Los atributos de diferentes dimensiones se relacionan a travs de hechos. Se consideran hechos a sucesos o eventos que ocurren, como por ejemplo alumnos que cursan carreras, o que rinden exmenes. Estos eventos generalmente estn asociados a una o mas medidas. Las medidas, mtricas o indicadores son variables numricas que ayudan a medir el rendimiento de un negocio. Estas medidas pueden ser de dos tipos: bsicas y derivadas. Las medidas bsicas 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 dimensin producto, donde la jerarqua principal estara dada por el cdigo de producto, la lnea, la categora y el rubro, y adems pueden existir jerarquas secundarias como el color o la marca.

37

Captulo 3 - El proceso de creacin de modelos analticos

hechos o eventos. Por ejemplo la variable unidades vendidas puede definirse a nivel de da para la dimensin tiempo mientras que la variable unidades en stock puede ser llevada semanal o mensualmente. Las medidas derivadas se calculan a partir de las bsicas y pueden o no estar almacenadas fsicamente en el DW. Un ejemplo de medida derivada podra ser el clculo de las ganancias a partir de las ventas menos los costos.

Navegacin del modelo multidimensional

Se entiende por navegacin o drilling a la accin de consultar datos dentro de un modelo multidimensional. Estas facilidades estn determinadas por las dimensiones y sus jerarquas, que definen el mapa de caminos para la navegacin de los datos. Existen distintos modos de buscar informacin. Se utilizan trminos especficos segn el tipo de consulta que se realice: Navegar (drilling o slice and dice20) es la habilidad de acceder al DW o Data Mart a travs de sus diferentes dimensiones. Es el proceso de separar y combinar datos de una misma manera. Agregar (drill-up o roll-up) es la accin de moverse hacia un atributo superior dentro de la jerarqua de una dimensin (navegacin ascendente, tambin denominada agregacin dinmica). Desagregar (drill-down o roll-down) es cuando se analiza informacin a mayor nivel de detalle dentro de una dimensin (navegacin descendente). Trasversar (drill-across) para analizar informacin de dimensiones acordadas sobre diferentes hechos (navegacin entre diferentes tablas de hechos, modelos o cubos). Tambin se utiliza este trmino para referirse a la navegacin inter-dimensional. Atravesar (drill-through). Esto es cuando los Data Marts de tipo MOLAP se conectan al DW a travs de consultas predeterminadas para visualizar informacin con un grado de detalle que no est incluido en el cubo. La operacin ms comn en anlisis de tipo OLAP es el drill-down. La mayora de las herramientas brindan esta operacin como la accin por defecto al seleccionar o hacer clic sobre algn 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 interseccin de todas las dimensiones que la definen. Toda tabla de hechos representa una relacin muchos a muchos entre las dimensiones y contiene un conjunto de dos o ms claves forneas que la vinculan a sus respectivas tablas de dimensin. Las tablas de hechos representan los sucesos ocurridos. No se debiera intentar llenarlas con ceros representando que nada ha sucedido.

20

El trmino slice and dice refiere a la accin de rebanar y cortar en cuadraditos un cubo de informacin.

38

Captulo 3 - El proceso de creacin de modelos analticos

El nivel de detalle de cada dimensin que se utiliza en la tabla de hechos define la granularidad de las medidas. Las medidas ms tiles son numricas y aditivas. Pero no todas las medidas son aditivas, existen medidas semi-aditivas y no aditivas. Tambin es posible que la tabla de hechos no contenga medidas y slo represente las relaciones entre dimensiones.

Tablas de dimensin
Las tablas de dimensin son un conjunto de tablas compaeras o guas para una tabla de hechos. Cada dimensin 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 mayora de las tablas de dimensin contienen muchos atributos o campos de texto que sirven para restringir y agrupar las consultas del DW y determinan los niveles de anlisis. 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 ao discriminados por carreras, la dimensin ao se est usando como restriccin, para filtrar un valor, y la dimensin carreras como encabezamiento del reporte. Algunas veces un atributo numrico puede confundirse con una medida. En estos casos hay que preguntarse si se usa para describir una dimensin o para medir algo del negocio. El tamao de un producto y la edad de un alumno son ejemplos de atributos numricos. Hay tablas de dimensin que son ntegramente descriptivas. Otras, llamadas tablas de catlogo o de bsqueda, adems 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 dimensin depende del valor de otra (a estos casos se los denomina subdimensiones). Por ejemplo, si en la tabla de hechos se representa la actividad acadmica 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 catlogo 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 tamao 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 caracterstica la estructura de los modelos dimensionales es llamada esquema estrella . Lo primero que se observa en el esquema dimensional resultante es su simplicidad y simetra. Se ha demostrado que los modelos dimensionales son entendibles, predecibles, extendibles y altamente resistentes para el anlisis de informacin del negocio que se busca. La

21

Cabe aclarar que la estructura interna final de una solucin MOLAP estar totalmente desnormalizada, sin embargo pueden considerarse algunas normalizaciones en las etapas intermedias de construccin.

39

Captulo 3 - El proceso de creacin de modelos analticos

naturaleza simtrica de este modelo soporta especialmente las consultas ad-hoc 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 metodologas para construir un DW difieren claramente del clsico 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 explotacin y finalmente se atiende a los requerimientos de consultas de los usuarios. Ms especficamente, la construccin de un DW est guiada por las necesidades de los usuarios y por los datos existentes para saciarlas. La metodologa para construccin de un DW ms 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 estn temporalmente organizadas, es decir no se determinan tiempos, plazos, ni duracin de las tareas.

Diseo de la arquitectura tcnica

Seleccin de productos e instalacin

Planificacin del proyecto Diseo de Requerimientos

Modelado dimensional

Diseo fisico

Diseo de las Extracciones y Transformaciones de Datos

Puesta en produccin

Mantenimiento y crecimiento

Especificacin de aplicaciones para usuarios finales

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 planificacin del proyecto. Es en este momento donde se evala la buena disposicin de la organizacin para una iniciativa de Data Warehousing, se establece el alcance preliminar, los recursos, y se lanza el proyecto. Luego, la gestin continua del proyecto servir para mantener el resto del ciclo de vida dentro de la planificacin realizada. La tarea siguiente se focaliza en la definicin de los requerimientos del negocio. Observar que existe una flecha con doble direccin entre la planificacin del proyecto y esta etapa debido a que hay mucha interrelacin entre ambas actividades. La alineacin del DW con los requerimientos del negocio es absolutamente crucial. La mejor tecnologa no salvar a un DW que 40

Captulo 3 - El proceso de creacin de modelos analticos

falla en focalizar en ellos. Los diseadores del DW deben entender las necesidades de los usuarios y trasladarlas en consideraciones de diseo. Los usuarios del negocio y sus requerimientos tienen impacto en casi todas las decisiones de diseo e implementacin a realizarse durante el transcurso del proyecto de Data Warehousing. En la figura se observa que siguiendo a la definicin de los requerimientos se desprenden tres lneas de trabajo paralelas. La lnea superior tiene que ver con la tecnologa. El diseo de la arquitectura tcnica establece el entorno general para soportar la integracin de mltiples tecnologas. Luego, en funcin de esta arquitectura se pueden evaluar y seleccionar los productos especficos. Observar que la seleccin 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 lnea 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 fsica. Durante las actividades de diseo fsico se presta especial atencin a las estrategias de puesta a punto para lograr buenos tiempos de respuesta (performance tuning). Esta actividad incluye la creacin de agregaciones, ndices y particiones. La ltima parte es la etapa donde se disean y desarrollan los procesos ETL. El tercer conjunto de tareas que siguen a la definicin de requerimientos es el diseo y desarrollo de aplicaciones analticas. Estas aplicaciones son necesarias para completar el proyecto de Data Warehousing y deben satisfacer un gran porcentaje de los requerimientos analticos de los usuarios del negocio. Luego se unen la tecnologa, los datos y las aplicaciones, junto con una buena dosis de conocimiento y soporte, para realizar una implementacin armoniosa. De ah en ms 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 ms detalle cada una de las actividades de las etapas del BDL.

Planificacin del proyecto

La planificacin busca identificar la definicin 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

Captulo 3 - El proceso de creacin de modelos analticos

Antes de comenzar un proyecto de DW o Data Mart hay que evaluar la buena predisposicin para su realizacin. Debe existir la demanda. Se debe contar con al menos un usuario sponsor slido y con el entusiasmo de otros. El usuario sponsor debiera tener una visin del impacto potencial del DW dentro de la organizacin. Otro factor crtico es la viabilidad: tcnica, 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 conformacin del equipo de trabajo. Los perfiles del personal afectado a la construccin de un DW son amplios y variados. Se requieren: usuarios del negocio, sponsors, lderes, gerentes del proyecto, analistas, arquitectos, administradores de bases de datos, diseadores, responsables de extraccin, desarrolladores, instructores, soporte tcnico, seguridad informtica, programadores, analistas de aseguramiento de calidad, entre otros.

Definicin de requerimientos
Otro factor determinante en el xito de un proceso de Data Warehousing es la interpretacin correcta de los diferentes niveles de requerimientos expresados por los distintos niveles de usuarios. Los diseadores de los DW deben entender los factores claves que guan al negocio para determinar efectivamente los requerimientos y traducirlos en consideraciones de diseo apropiadas. Los requerimientos del negocio deben determinar el alcance del DW (qu datos debe contener, cmo debe estar organizado, cada cunto debe actualizarse, quines y desde dnde accedern, 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 diseadores descubren las necesidades y expectativas de la comunidad usuaria. El proceso de entrevistas debe intercalarse entre grupos de usuarios del DW y grupo de tcnicos de los sistemas fuentes. A medida que se van planteando las necesidades de anlisis se precisa conocer si esas necesidades pueden satisfacerse con los datos y estructuras existentes. Las entrevistas deben ser preparadas en funcin del perfil del usuario a entrevistar y no debieran durar ms de una hora. Una vez obtenidos los requerimientos, estos debern ser priorizados y consensuados con los usuarios.

Diseo de la arquitectura tcnica

La arquitectura tcnica es el anteproyecto para los servicios y elementos tcnicos del DW. Sirve para integrar las numerosas tecnologas. En el captulo anterior se present la estructura general de esta arquitectura. Dicha estructura debe ser adaptada al caso a desarrollar, basndose principalmente en las necesidades del negocio. Para establecer el diseo de la arquitectura tcnica del ambiente de Data Warehousing se deben tener en cuenta tres factores: los requerimientos del negocio, los ambientes tcnicos actuales y las directrices tcnicas estratgicas planificadas a futuro. 42

Captulo 3 - El proceso de creacin de modelos analticos

Se puede hacer una analoga entre los planos arquitectnicos 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 informacin. Al igual que en una construccin, los planos sirven para comunicar los deseos entre los clientes y el arquitecto, como as tambin para medir esfuerzos y materiales necesarios para la obra (comunicacin, planificacin, flexibilidad y mantenimiento, documentacin, productividad y reutilizacin), y tambin sern de ayuda cuando haya que remodelar o incorporar modificaciones. La arquitectura tcnica se divide en dos partes, la parte interna del DW (back room) y la cara pblica (front room), que interactan constantemente. Mientras los requerimientos del negocio indican qu se necesita hacer, la arquitectura tcnica responde el interrogante de cmo se har [Mst2005].

Seleccin de Productos e Instalacin

Utilizando el diseo de la arquitectura tcnica como marco, es necesario evaluar y seleccionar los componentes especficos 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 instalacin y prueba de los estos dentro de un ambiente integrado [Mst2005].

Modelado Dimensional lgico

Una vez recolectados los requerimientos del negocio y habiendo auditado los datos existentes en los sistemas operacionales estn dadas las condiciones para comenzar con el diseo del DW. Disear los modelos de datos para soportar los requerimientos analticos de los usuarios requiere un enfoque diferente al usado en los sistemas operacionales. Bsicamente 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 (dimensin), como as tambin la granularidad de cada indicador (variable o mtrica) y las diferentes jerarquas que dan forma al modelo dimensional del negocio, BDM (Business Dimensional Model) o mapa dimensional. En [Kim1998] se propone una metodologa para construir modelos dimensionales que comienza identificando los correspondientes Data Marts (como conjunto de indicadores) y las dimensiones de estos. Luego sigue con la construccin 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 metodologa contina con el diseo multidimensional de cada Data Mart. Se definen cuatro pasos: primero la eleccin del Data Mart, segundo la declaracin de la granularidad, tercero la eleccin de las dimensiones y cuarto la eleccin de las medidas o 43

Captulo 3 - El proceso de creacin de modelos analticos

indicadores. Adems, recomienda un conjunto de diagramas que sern 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. Tambin el anlisis 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 comunicacin y la validacin del diseo entre el equipo de desarrollo del DW y la comunidad usuaria.

Diseo Fsico
El diseo fsico de las base de datos se focaliza en la seleccin de las estructuras necesarias para soportar el diseo lgico. En el modelado dimensional el diseo lgico y el fsico se asemejan mucho. Algunos de los componentes de esta etapa son la definicin de convenciones y estndares de nombres y seteos especficos del ambiente de la base de datos. El diseo fsico se enfrenta a las actividades de puesta a punto de la performance del DW que consisten principalmente en la creacin de ndices y tablas agregadas. Las estrategias de particionamiento son tambin determinadas en esta etapa. Las agregaciones son la tcnica de puesta a punto de mejor impacto sobre el tiempo de respuesta de las consultas que efectuarn los usuarios. Este tema es abordado al final de la prxima seccin. Otros puntos a resaltar de esta etapa son: planes de desarrollo del modelo fsico, convenciones de nombres y estndares, uso de sinnimos, uso de herramientas de modelado para la generacin y mantenimiento del modelo fsico, estimaciones de volmenes, planes y estrategias de indexacin, consideraciones sobre memoria y tamao de bloque, parametrizacin, 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 documentacin particular del motor de base de datos que se decida utilizar.

Diseo de las Extracciones y Transformaciones de Datos

Esta etapa consiste del diseo y desarrollo del proceso ETL, descripto en el captulo 2, y es tpicamente la ms subestimada de las tareas en un proyecto de DW. Todas las actividades de esta etapa son altamente crticas 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 anlisis de informacin. Es en esta etapa donde deben sanearse todos los inconvenientes relacionados con la calidad de los datos fuente. La desconfianza y prdida de credibilidad del DW sern resultados inevitables si el usuario encuentra informacin inconsistente.

44

Captulo 3 - El proceso de creacin de modelos analticos

Son muchos los desafos que deben enfrentarse para lograr datos de alta calidad de los sistemas fuentes. Esta etapa siempre termina abarcando ms tiempo del previsto, sobre todo lo que refiere a la transformacin de datos. Algunos tems que ayudarn a guiar esta etapa del BDL [Kim1998]. Plan: Crear un diagrama de flujo fuente-destino esquemtico 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 documentacin que sea til para futuras modificaciones22. Profundizar en detalle por tabla destino. Describir grficamente las reestructuraciones o transformaciones complejas. Ilustrar la generacin 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 esttica. 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 actualizacin de una dimensin. Construir y probar las cargas de las restantes dimensiones. Tablas de Hechos y automatizaciones: Construir y probar la carga histrica de las tablas de hechos (carga masiva de datos de nivel atmico, slo de tablas base). Esta tarea incluye la bsqueda y sustitucin de claves. Construir y probar los procesos de cargas incrementales. Construir y probar la generacin de agregaciones y/o de cubos MOLAP Disear, construir y probar la automatizacin de los procesos. En [Kim2004] se encuentra un detalle de las tcnicas y consideraciones a tener en cuenta en la extraccin, transformacin y carga de los datos que formarn parte de las tablas de dimensiones y de las tablas de hechos.

Especificacin de Aplicaciones para Usuarios Finales

Las aplicaciones proveen el mecanismo clave para fortalecer la relacin 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 23

Existen herramientas de ETL en software libre, por ejemplo Pentaho. Este concepto se describe ms adelante. Refiere a nuevas claves, diferentes a las de los sistemas operacionales, otorgadas a los elementos de las dimensiones.

45

Captulo 3 - El proceso de creacin de modelos analticos

mostrar el valor del DW rpidamente, a facilitar el acceso de la mayora de la comunidad usuaria y, a travs de los ejemplos, colaboran con los usuarios avanzados a construir reportes ms complejos. No todos los usuarios del DW necesitan el mismo nivel de anlisis. 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 ms estratgico, menos predecibles (power users), usuarios netamente operacionales que consumen una serie de reportes estndares (final users), usuarios gerenciales con uso de interfaces bsicas (EIS users), entre otros. Mientras que algunos usuarios aprovecharn al mximo las facilidades de anlisis ad hoc, otros necesitarn aplicaciones analticas parametrizadas, ms limitadas. En general se requiere de la creacin de aplicaciones estndar parametrizables. Estas aplicaciones tipo plantilla para usuarios finales proveen el marco y la estructura de un reporte para ser especializado por un conjunto de parmetros. El usuario selecciona los parmetros 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 anlisis y filtros de la informacin (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 intervencin del departamento sistemas y maximizando el tiempo de anlisis por sobre el tiempo de construccin e integracin de la informacin. Este enfoque orientado a parmetros permite a los usuarios generar docenas o potencialmente cientos de reportes de estructura similar. Todo esto de forma amigable y con interfaces grficas. Es recomendable comenzar con la especificacin de las aplicaciones tan pronto como se finalice el relevamiento de requerimientos, cuando se tienen bien presentes las necesidades de los usuarios, y documentar explcitamente . Algunas consideraciones para llevar adelante esta tarea [Kim1998]: Determinacin del conjunto de patrones iniciales (identificar reportes candidatos, clasificarlos y priorizarlos) Diseo de la estrategia de navegacin dentro de la aplicacin (esquema de pantallas, esquema de carpetas o directorios, criterios de agrupamiento -por datos, por dueo, por regla del negocio-, etc.) Determinacin de estndares (nombre y ubicacin de los objetos, formato de las salidas) Detalle de las especificaciones (definicin del nombre, descripcin o propsito, frecuencia, parmetros, restricciones, diseo, etc.)

46

Captulo 3 - El proceso de creacin de modelos analticos

Desarrollo de Aplicaciones para Usuarios Finales

Esta etapa sigue a la especificacin de las aplicaciones para usuarios finales El proceso de desarrollo es bastante estndar 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 estndares de las aplicaciones (convenciones de nombre, clculos, libreras y codificacin). Esta etapa debiera comenzar una vez que existen datos en el DW (aunque no sean ms que datos de prueba), es decir pronto a finalizados el diseo lgico y el fsico. El motivo es que al desarrollar las aplicaciones pueden descubrirse problemas en la calidad de datos que no haban surgido en la primera etapa del ETL y que obliguen a realizar modificaciones. Tambin es el momento de revisar las estrategias de optimizacin 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: Seleccin de un enfoque de implementacin. 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 aplicacin. Definicin de la herramienta de acceso a la meta data, desarrollo de moldes y esquema de navegacin de la aplicacin, seleccin de reportes que sern pre-ejecutados, etc. Prueba y verificacin de datos. Testeo y verificacin de descripciones, informacin duplicada, relaciones entre atributos, consistencia e integridad de datos con sistemas fuentes. Documentacin y salida a produccin. Retroalimentacin con los resultados de la puesta en produccin Mantenimiento y monitoreo de performance.

Puesta en produccin
La tecnologa, los datos y las aplicaciones de usuarios finales convergen en esta etapa de implementacin. Desafortunadamente esta convergencia no sucede naturalmente y requiere ser planificada. Es muy importante que no se realice la implementacin del DW hasta que los datos no estn listos para ser mostrados. De todas formas no se necesitan slo datos de buena calidad, sino que hay varios factores extras que aseguran una correcta implementacin del proyecto. Entre estos factores se encuentran: la capacitacin a los usuarios, el soporte tcnico, la comunicacin y las estrategias de feedback. Todas estas tareas deben ser tenidas en cuenta antes de que cualquier usuario pueda tener acceso al DW.

47

Captulo 3 - El proceso de creacin de modelos analticos

La educacin 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 capacitacin contemple tres aspectos claves: el contenido del DW (los datos), las aplicaciones y las herramientas de acceso. No debe realizarse slo sobre las herramientas de acceso. La educacin sobre las herramientas es intil al menos que se complemente con conocimientos sobre el contenido del DW (cules datos estn disponibles, qu significan, cmo se usan y para qu usarlos). Tambin es importante la metodologa de presentacin. Para los usuarios finales no es fcil entender los lmites entre las aplicaciones, los contenidos y las herramientas. Para ellos el DW es un todo, por lo tanto la educacin tambin debe reflejar la misma perspectiva. Otro factor clave es la correcta capacitacin por niveles segn el perfil del usuario (usuario final, power user, etc.). El armado de un ambiente de capacitacin es siempre recomendable. Dos buenas premisas para el xito del proyecto en esta etapa final del ciclo de vida: capacitar a los usuarios finales slo si el DW est listo y establecer la poltica de que si el usuario no recibi capacitacin no puede acceder a l. El soporte tcnico es la otra columna que ayudar a implementar con xito el proyecto. Se deber definir claramente los niveles de soporte (a nivel aplicacin, modelo, calidad de datos) de forma transparente para el usuario. La documentacin juega un papel importantsimo en la ayuda a usuarios finales.. Respecto a la metodologa de implementacin es bueno seguir un esquema de versionado. Primero se pasa por la versin Alpha, donde el grupo de trabajo conduce por primera vez una prueba completa del sistema. Todos los componentes del sistema deben ser testeados (infraestructura tcnica, extraccin, transformacin, carga, procedimientos de calidad, performance, moldes, etc.). Tpicamente es de naturaleza iterativa y slo puede decirse que se termina esta versin cuando el grupo de trabajo confa 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 versin Beta. El objetivo de esta versin 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 accedern al DW en esta instancia debe ser suficiente para asegurar que la aplicacin se probar adecuadamente. Una vez superadas estas dos versiones se llega a un estado de disponibilidad general. Toda modificacin posterior debiera pasar internamente por un estado Alpha y Beta aunque externamente sea una nueva versin. Finalmente, la tecnologa que reside en el escritorio del usuario es la ltima pieza que debe ser ubicada antes de la salida a produccin. Para asegurar que la infraestructura
24

Los power users son los usuarios que explotarn al mximo las capacidades del DW, haciendo uso de anlisis ad hoc.

48

Captulo 3 - El proceso de creacin de modelos analticos

correspondiente al ambiente del usuario est correcta y el producto entregado sea de calidad debieran realizarse una serie de tareas antes de la implementacin. Estas tareas incluyen: configuracin del hardware, conexin a las bases, acceso a intranet o internet, asignacin de direcciones de red, auditorias de tecnologa sobre las configuraciones de las computadoras de los puestos de trabajo, previsin de actualizaciones de hardware y software (determinacin 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 instalacin en una variedad de mquinas, planificacin de instalacin, 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 acompaa a la evolucin de la organizacin durante toda su historia. Se necesita continuar con los relevamientos de forma constante para poder seguir la evolucin 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 anlisis. Una vez que se ha construido e implementado el DW, rpidamente 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 estn ahora accediendo al DW. Algunas consideraciones a tener en cuenta para mantener exitosamente al DW: el continuo soporte y la constante capacitacin a usuarios del negocio, el manejo de la infraestructura (monitoreo de base de datos, trfico, 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 medicin del xito del proyecto que se haban fijado en la etapa de relevamiento), relevamiento de casos de estudio (situaciones reales donde una decisin basada en informacin del DW tuvo impacto sobre el negocio), constante publicidad interna del uso (permitiendo acceso siempre y cuando se tenga la capacitacin correspondiente) y constante comunicacin con los sectores del negocio y de sistemas para asegurar la buena salud del DW [Mst2005]. En cuanto al crecimiento del DW, un buen diseo 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 creacin 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 segn el impacto en el DW). Como mejoras menores incluye la incorporacin de datos sencillos, nuevas agregaciones, cambios en niveles superiores del modelo (atributos de alto nivel, lejanos a las tablas base).

49

Captulo 3 - El proceso de creacin de modelos analticos

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 acompaa todo el ciclo de vida. Entre sus actividades principales se encuentran: la conduccin del equipo de trabajo, el monitoreo del estado del proyecto, el mantenimiento del plan y documentacin, el manejo del alcance, y la comunicacin entre los requerimientos del negocio y las restricciones de los datos para poder manejar correctamente las expectativas.

3.3

Tcnicas para el modelado dimensional.

En [Kim1992] [Kim2002] se presentan temticas de anlisis tpicas mediante las cuales se

ejemplifican cuestiones de diseo, algunas comunes y sencillas, otras ms especficas y complejas. No es intencin de esta tesis abordar estas cuestiones detalladamente, sino presentar las lneas generales ms importantes. Varias de las tcnicas se ejemplifican luego durante el desarrollo del caso de estudio, donde tambin se resaltan las particularidades de la temtica elegida. Tal como se mencion previamente, el diseo de un esquema multidimensional consiste bsicamente de cuatro pasos: Seleccionar el proceso del negocio o asunto a modelar o Data Mart. Un proceso es una actividad realizada en la organizacin 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 segn la perspectiva de anlisis de los diferentes departamentos de una organizacin. Al presentar esta etapa de modelado dimensional dentro del BDL, se dijo que el diseo de un DW comienza con la construccin de una matriz (DW Bus Architecture Matrix) donde se establecen las relaciones entre indicadores (pertenecientes a algn Data Mart) y dimensiones. Este primer paso consiste en elegir qu rengln 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 organizacin grande vara entre 10 y 30. Menos de 10 podra significar que qued muy amplia la definicin de cada uno de ellos. Ms de 30 o 40 es difcil de mantener, por eso es recomendable juntar los que puedan unirse.

50

Captulo 3 - El proceso de creacin de modelos analticos

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 crtico. Declarar la granularidad inapropiadamente puede atormentar la implementacin de un DW y limitar el nivel de anlisis. Cargar las tablas de hechos con datos atmicos (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 informacin agregada algunas sumarizaciones pueden no ser vlidas (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 sern fcilmente identificadas si la granularidad est clara. Al elegir cada dimensin se listan todos los atributos que proveern el detalle de cada tabla de dimensin. Ejemplos de uso comn son fecha, producto, cliente, tipo de transaccin, etc.

Identificar las medidas para cada tabla de hechos. Las medidas se determinan a partir de las mtricas 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 dimensin, o lo est pero a otro nivel de detalle) esa mtrica debe ser modelada en una tabla de hechos separada. Las medidas tpicas son numricas 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 tcnica 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 ms (de los requerimientos y de los datos). A medida que se avanza en el diseo, pueden identificarse dimensiones nuevas, o descubrir que dos de ellas son slo una. Tambin es comn realizar cambios en la granularidad.

Eleccin del Data Mart

La metodologa BDL propone comenzar por la construccin de un Data Mart.. La eleccin del Data Mart a modelar en el ms simple de los casos es elegir la fuente de donde se tomarn los datos. Es recomendable elegir al principio uno que tenga una nica fuente de datos en lugar de mltiples para evitar los riesgos de afrontar tareas de extraccin ms complejas. Se recomienda implementar los Data Marts en forma separada slo 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

Captulo 3 - El proceso de creacin de modelos analticos

responsabilidades mayores del equipo de diseo central del DW es establecer, publicar, mantener e imponer las dimensiones acordadas. Las dimensiones acordadas naturalmente sern definidas en el mayor nivel de granularidad posible. Tambin se recomienda que tengan una clave annima (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 podran sufrir los valores de los atributos de las dimensiones. La creacin de las dimensiones acordadas es ms una decisin poltica que tcnica, 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 terminologa a travs de los Data Marts y cuando se construyen reportes con informacin proveniente de ms de uno de ellos. Si dos medidas reciben el mismo nombre deben significar lo mismo. En el caso de las medidas calculadas la ecuacin de clculo debe ser equivalente. Las medidas acordadas necesitan estar definidas en el mismo contexto dimensional y con la misma unidad de medicin para todos los Data Marts. A veces la unidad de medicin de una mtrica 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 envos. En algunos casos se utiliza un factor de conversin, pero en este ejemplo no sera apropiado, y es conveniente modelarlas como medidas diferentes. Si es difcil o imposible acordar una medida entonces hay que asegurarse de darle nombres diferentes a cada interpretacin. Luego de haber implementado varios Data Marts de una sola fuente es razonable combinarlos en uno de mltiples fuentes. El ejemplo clsico es el Data Mart para anlisis 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 diseo. Se recomienda elegir el nivel ms bajo de granularidad posible para lograr un diseo ms robusto. Esto significa construir las tablas de hechos bsicas al nivel naturalmente ms 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. Tambin el nivel ms bajo de granularidad es el que tiene el dato de la forma dimensional ms natural (por ejemplo del ticket de un cajero automtico pueden identificarse las dimensiones tiempo, localidad, cuenta y tipo de transaccin). Es en el nivel ms bajo donde la mayora de los atributos de las dimensiones tienen un nico valor por registro. Por otro lado, trabajar con el nivel de datos ms desagregado en el DW servir para hacer anlisis de data mining y de comportamientos de clientes. Los tres tipos de granularidad de tablas de hechos ms tiles son: transacciones individuales, fotografas (snapshots) peridicas (diarias, mensuales, etc.) y fotografas 52

Captulo 3 - El proceso de creacin de modelos analticos

acumulativas (accumulating snapshop). Cada uno de estos tipos de tablas tiene caractersticas particulares que se desarrollan a continuacin. Granularidad a nivel de transaccin La visin operacional del negocio ms importante es a nivel de transacciones individuales. El caso ms sencillo de este esquema consiste en crear un registro en la tabla de hechos por cada transaccin individual (por ejemplo por cada operacin de un cajero automtico). Frecuentemente cada registro contiene una nica medida, que es el valor de la transaccin. En muchos casos se la llama importe (monto, o cantidad). El diseo de un esquema de transacciones es ms acotado en cuanto al crecimiento que el de un esquema de fotografas. Se representan eventos que ocurren en un determinado momento de tiempo, y una vez ocurrida la transaccin se incorpora al DW y no se vuelve a visitar a ese registro (no se lo modifica). Casi nunca se agregan medidas numricas porque el sistema de captura de transacciones usualmente slo retorna un importe. Se pueden agregar nuevos tipos de transacciones a la dimensin pero esto significa agregar datos no cambiar el esquema de la tabla. El nivel de granularidad no necesariamente es el nivel de la transaccin en s, en algunos casos se puede llegar a nivel de lnea de tem. Por ejemplo, para representar ventas mucha informacin est en el encabezado de la factura (fecha, cliente, sucursal, etc.) que sera la transaccin, pero hay un nivel ms detallado, el de lnea 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 estn agregados. Este nivel de informacin permite realizar conteos de comportamiento (como por ejemplo cantidad de transacciones por cliente), anlisis de rangos horarios, encolamientos, tiempos entre transacciones, etc. El detalle de las transacciones permite ver el comportamiento secuencial que se aplica para deteccin de fraudes y advertencia de cancelaciones. Finalmente permite realizar anlisis de canasta que consiste en identificar asociaciones de elementos, por ejemplo productos que se venden junto con uno determinado. Muchos de estos ejemplos son anlisis tpicos de data mining, que requieren tener los datos en su mximo nivel de detalle. La granularidad de nivel de transaccin sin embargo no es la ms apropiada para otro tipo de anlisis, 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 clculo. Esquema de fotografas Fotografas peridicas 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 da, o del mes, y se captura la actividad que 53

Captulo 3 - El proceso de creacin de modelos analticos

ocurri durante ese perodo. Se dice que se toma una foto de lo ocurrido. Las fotografas tomadas en cada perodo se van guardando en la tabla de hechos. Este esquema de fotografas es ms complejo que la perspectiva de transacciones individuales. Pueden existir varias medidas de la actividad ocurrida durante el perodo capturado, por ejemplo importe total de ventas, cantidad total de transacciones, cantidad de clientes que realizaron alguna compra en el perodo, etc. Es importante que todas las medidas se refieran al perodo corriente. Algunas medidas sern completamente aditivas y otras sern semi-aditivas, como el balance de cuentas al momento que se toma la fotografa. Estos casos podrn ser promediados a travs del tiempo o tener algn otro mtodo especial de agregacin. 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 da.. Otras veces el patrn de transacciones es muy complejo y la construccin de fotografas no es una simple agregacin. Por ejemplo en una contabilidad mensual el clculo de las ganancias depende de cmo contabiliza cada tipo de transaccin (depsitos, pagos por adelantado, etc.). Las fotos mensuales son requeridas en estos casos para obtener la informacin a ese nivel en forma rpida. La granularidad a nivel de transacciones posibilita la vista total del comportamiento detallado y a nivel de fotografas permite medir rpidamente el estado de la empresa u organizacin. En muchos casos se necesitan ambas para lograr una vista completa e inmediata del negocio. Fotografas acumulativas Las fotografas acumulativas (o acumuladas) representan un lapso de tiempo indeterminado para cubrir la vida entera de una transaccin 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 diseo 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 produccin, de ventas y entregas, etc.). La granularidad de estas tablas de hechos suele ser de un registro por cada lnea de tem de un documento de control. Cada registro puede ser pensado como fotografas evolutivas de esa lnea de tem que se van actualizando. Estas tablas de hechos tienen tpicamente mltiples fechas representando hitos en las fases por las que atraviesa la lnea de tem (por ejemplo fecha de la orden de pedido, fecha de entrada a fabricacin, fecha de fin de fabricacin, fecha de envo a sucursal, fecha de facturacin, fecha de recepcin del cliente, entre otras). Tambin pueden existir diferentes medidas asociadas a cada etapa. Generalmente se necesita una dimensin de estado para guardar el valor actual de cada tem. En estas tablas cada registro se actualizar frecuentemente cuando se tenga nueva 54

Captulo 3 - El proceso de creacin de modelos analticos

informacin disponible, para reflejar el estado y las mtricas acumuladas. Esta es la diferencia fundamental con los otros tipos de tablas. A veces las fotos acumulativas se usan en conjunto con las fotos peridicas. Se puede pensar en un DW que guarde fotos peridicas por mes y que lleve una fotografa acumulativa para la informacin del mes en curso. En estos casos cuando finaliza el ltimo da del mes la fotografa acumulada pasa a ser una ms de las fotos peridicas y se crea una nueva foto acumulativa para registrar la actividad del nuevo mes a partir del da siguiente. La fotografa mensual se construye de forma incremental, agregando el efecto de las transacciones diarias a una fotografa acumulativa. Comparacin de los esquemas En la siguiente figura se presenta un cuadro comparativo [Kim2002] respecto a estos tres tipos de granularidad donde destaca las caractersticas ms distintivas.
Caracterstica Perodo de tiempo representado Granularidad Tipo de cargas en tablas de hechos Actualizaciones en tablas de hechos Dimensin fecha Mtricas Granularidad transaccional Punto en el tiempo Una fila por evento transaccional Inserciones No Fecha de la transaccin Actividad transaccional Granularidad de fotografas peridicas Intervalos regulares y predecibles Una fila por perodo Inserciones No Fecha del fin del perodo Rendimiento para intervalos de tiempo predefinidos Granularidad de fotografas acumulativas. Lapso de tiempo indeterminado, tpicamente 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. Mltiples fechas para hitos estndares Rendimiento sobre el tiempo de vida finito

Figura 10. Comparacin de tipos de tablas de hechos.

Los tres tipos de granularidades vistos son tiles para diferentes propsitos. La administracin 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 compartirn dimensiones acordadas, para poder ser usadas en conjunto. Familias de tablas de hechos Para modelar muchos de los procesos del negocio es necesario considerar ms 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

Captulo 3 - El proceso de creacin de modelos analticos

Los casos ya mencionados de contar con tablas de diferente granularidad; por ejemplo transaccional y de fotografas para poder realizar anlisis detallado y a la vez tener una vista del negocio rpida.

La construccin de tablas con informacin agregada para resolver problemas de performance.

Modelar cadenas y crculos. 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 fotografas peridicas, y estarn relacionadas por las dimensiones y medidas comunes. Se habla de cadenas cuando los subprocesos o etapas estn naturalmente ordenados. El caso de los crculos es cuando varias entidades estn realizando o midiendo el mismo tipo de transacciones. Un buen ejemplo es la gran organizacin de cuidado de la salud, donde hospitales, farmacias, laboratorios, clnicas, compaas de seguro y otras entidades rondan alrededor de los tratamientos de los pacientes.

Esquemas de productos heterogneos. Este es el caso de negocios que manejan productos lo suficientemente diferentes que dadas las caractersticas propias del tipo de producto deban ser modeladas en forma separada, porque existan muchas dimensiones que no son comunes. Seguramente tambin se incluya en el modelo una tabla base ncleo que cruce todas las lneas del negocio para tener un anlisis global por las dimensiones comunes. Un ejemplo puede ser una empresa que ofrezca productos y tambin servicios. Tablas de hechos sin medidas Hay un tipo especial de tablas de hechos denominada factless fact tables por tener la

caracterstica de no incluir medidas entre sus campos. Hay dos situaciones donde las tablas con esta caracterstica son muy tiles: para seguimiento de eventos y de cobertura. Para el primer caso en la tabla de hechos se registra un evento por lnea. Ejemplos tpicos de uso son el registro de asistencias y las inscripciones a cursos. Si se piensa en alumnos universitarios inscribindose a materias la granularidad de la tabla ser de una fila por cada inscripcin de un alumno a una materia en un perodo acadmico. El perodo ser el nivel ms bajo disponible para la registracin de eventos. Esta dimensin debe estar de acuerdo con la dimensin de fechas. Este tipo de tablas, compuestas slo 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. Ntese la referencia a fact table como tabla de hechos, considerando hecho como suceso o evento en lugar de utilizarlo como sinnimo de medida o mtrica al hacer mencin a la tabla.

56

Captulo 3 - El proceso de creacin de modelos analticos

inscripciones, cul es la cantidad de inscripciones promedio por alumno y perodo, qu docentes tendrn mayor cantidad de alumnos, cul es el medio de inscripcin ms utilizado, etc. Al analizar esta informacin pueden contarse dos cosas diferentes: por un lado la cantidad de inscripciones y por otro la cantidad de valores diferentes de una dimensin en alguna consulta. Por ejemplo: para un perodo determinado, se puede contar el total de inscripciones por carrera (asumiendo que cada materia pertenece slo a una carrera), como tambin 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 estn a la venta. Sera deseable saber qu productos estaban en promocin y no se vendieron. Agregar la informacin necesaria para este anlisis en la tabla de ventas significara la incorporacin de muchsimos registros con ceros representando los eventos que no sucedieron (todos los productos que no se vendieron), lo que hara crecer enormemente el tamao 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 estn durante la vigencia de la promocin. Otro ejemplo de cobertura puede ser el anlisis de uso y disponibilidad de las instalaciones de una institucin. Para cada instalacin se podra considerar datos como el edificio, el tipo de instalacin (aula, laboratorio, oficina), la capacidad, los servicios (pizarrn, proyector, computadoras) y registrar para cada bloque horario si la habitacin se encuentra disponible o no.

Diseo de las dimensiones

Una vez seleccionado el Data Mart a modelar y habiendo establecido las granularidades correspondientes, el tercer paso del diseo multidimensional consiste en elegir las dimensiones que aplican a cada tabla de hechos. Diferentes caractersticas de las dimensiones debern tenerse en cuenta al momento de disear el modelo del negocio. Descripcin de los atributos Es vital que las descripciones de los atributos de las dimensiones sean de alta calidad: significativas, entendibles y prolijas. Estas sern 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

Captulo 3 - El proceso de creacin de modelos analticos

Claves de las dimensiones Otra caracterstica de diseo importante es que todas las dimensiones deben tener una clave. Las claves de las dimensiones deben ser un slo campo, numrico 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 ms importantes a definir al modelar las dimensiones est relacionado en gran parte con la implementacin fsica. Se trata de la normalizacin o no de las tablas de dimensin. Algunas dimensiones constan de un nico atributo, pero otras constan de varios atributos que forman una jerarqua. Tal es el caso de la dimensin producto, donde se puede identificar la jerarqua: producto, lnea, categora y rubro, por ejemplo, y de la dimensin ubicacin geogrfica donde se identifican localidades, provincias y pases, entre otros atributos. En estos casos la dimensin se puede representar en una nica tabla, donde reside toda la informacin al nivel ms 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 montn de tablas de dimensiones satlites). Al normalizar las dimensiones se dice que se transforma al modelo estrella en un copo de nieve (tambin debido al grfico de su estructura), y por eso a veces se hace referencia a esta accin como snowflaking. En la figura 11 se observa como podra ser la tabla de la dimensin Ubicacin, con localidad_id como nica clave modelada en ambas formas.
Pais_id Pais_desc

Localidad_id Localidad_desc Provincia_id Provincia_desc Pais_id Pais_desc

Provincia_id Provincia_desc Pais_id

Localidad_id Localidad_desc Provincia_id

Figura 11. Dimensin Ubicacin desnormalizada vs normalizada.

27

La tercera forma normal es una forma de normalizacin de bases de datos, definida por E.F.Codd.

58

Captulo 3 - El proceso de creacin de modelos analticos

Es claro que la tabla desnormalizada contiene mucha redundancia de datos. Tambin es claro que en el esquema normalizado se necesitar realizar varias uniones entre tablas para obtener la informacin del DW agrupada a niveles altos de la jerarqua. Entre un esquema y otro existe una solucin intermedia, denominada moderadamente normalizada que es igual al normalizado a excepcin 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 jerarqua consultado. El esquema totalmente desnormalizado presenta algunas variantes. Puede contener: Una clave y una descripcin genricas para toda la dimensin, y las claves de los diferentes niveles. Esta opcin es rara. Podra usarse para algn caso donde la descripcin sea la misma, cualquiera sea el nivel de anlisis que se consulte, o si el dato a mostrar se calcula a partir de esa descripcin comn. Una clave genrica para toda la dimensin y las descripciones de los diferentes niveles. Es vlido si no existen tablas de hechos con nivel de granularidad diferente al nivel base de la dimensin. Una clave genrica para toda la dimensin y las claves y descripciones de los diferentes niveles. Este es el caso ms comn y el mostrado en la figura, slo que para el ejemplo se toma como clave de la dimensin a la clave del nivel ms bajo. Con este esquema totalmente desnormalizado hay que utilizar algn mtodo de indexacin eficiente para obtener el listado de valores de los diferentes niveles de la jerarqua, particularmente para resolver rpidamente los cruces con las tablas de hechos donde el nivel de granularidad no sea el base. Caso contrario sera necesario crear tablas adicionales para los distintos niveles y esto generar an ms redundancia de datos, como se puede observar en la figura 12. La discusin entre ambos esquemas surge de considerar el tamao 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 informacin de diferentes tablas, agregar o agrupar datos, ordenar datos y recorrer grandes volmenes de datos. El desarrollo tecnolgico a travs de los aos ha quitado presin al problema del tamao del DW. Con respecto a las operaciones costosas en la base de datos pueden usarse tcnicas 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 diseador conozca las consultas que sern realizadas frecuentemente para personalizar la base de datos focalizando en la performance de esos casos. 59

Captulo 3 - El proceso de creacin de modelos analticos

Algunos argumentos a favor de la desnormalizacin, con una nica tabla por dimensin y el uso de ndices: Las tablas normalizadas hacen ms compleja la presentacin de los datos; y el modelo dimensional debe ser simple. Cuantas menos tablas haya ms fcil ser de entender. Muchas tablas y cruces normalmente perjudican los tiempos de respuestas y dificultan la generacin (en SQL) de las consultas. El espacio en disco que se ahorra es mnimo respecto al tamao de las tablas de hechos y no justifican el esfuerzo. La normalizacin perjudica la habilidad de navegar los datos dentro de una dimensin, particularmente cuando se consultan al mismo tiempo varios atributos. La normalizacin rechaza el uso de ndices que es una tcnica 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 mnimo. En el modelo desnormalizado las tablas de dimensin son muy grandes. Es flexible y escalable en cuanto a cantidad de atributos dentro de cada dimensin, 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 dimensin es ms sencillo al no haber redundancia de datos. Soporta mejor los posibles cambios en los valores de los atributos de las dimensiones. Si una descripcin cambia debe ser modificada slo en un lugar en vez de en todos los registros de una tabla de dimensin desnormalizada. Es interesante observar como las diferencias entre las estructuras se hacen ms visibles cuando la dimensin tiene muchos niveles, y tambin cuando hay tablas de hechos con diferentes granularidades (que podran existir o no, y podran corresponder a agregaciones28 o a otros hechos). A partir el ejemplo de la figura 11 se podran obtener las variantes mostradas en las figuras 12, 13 y 14.

28

Consultar sobre la tcnica de agregacin al final de este captulo. Las agregaciones tienen sentido cuando existen dimensiones con jerarqua. La razn principal de su creacin 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

Captulo 3 - El proceso de creacin de modelos analticos

Dim Ubicacin 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 Localidad_id Tabla de hechos nivel pcia Pcia_id Tabla de hechos nivel pais Pais_id

(Dim Ubicacin agreg 1) Provincia_id Provincia_desc Pais_id Pais_desc Region_id Region_desc (Dim Ubicacin agreg 2) Pais_id Pais_desc Region_id Region_desc

Figura 12. Esquema altamente desnormalizado para la dimensin Ubicacin.

Region_id Region_desc Pais_id Pais_desc Region_id Provincia_id Provincia_desc Pais_id Depto_id Depto_desc Pcia_id Localidad_id Localidad_desc Depto_id

Tabla de hechos nivel pais Pais_id

Tabla de hechos nivel pcia Pcia_id

Tabla de hechos base Localidad_id

Figura 13. Esquema altamente normalizado para la dimensin Ubicacin.

Region_id Region_desc Pais_id Pais_desc Region_id

Provincia_id Provincia_desc Pais_id Region_id Depto_id Depto_desc Pcia_id Pais_id Region_id Localidad_id Localidad_desc Depto_id Provincia_id Pais_id Region_id

Tabla de hechos nivel pcia Pcia_id

Tabla de hechos base Localidad_id

Tabla de hechos nivel pais base Pais_id

Figura 14. Esquema moderadamente normalizado para la dimensin Ubicacin.

61

Captulo 3 - El proceso de creacin de modelos analticos

En el esquema altamente desnormalizado de la figura 12 las tablas adicionales para la dimensin (punteadas en el grfico) podran crearse pero esto producira ms redundancia an; es preferible optar por una buena tcnica de creacin 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 dimensin, realizando el agrupamiento de registros correspondiente al nivel de la jerarqua 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 agregacin, resolver una consulta sobre la tabla base requiere muchos joins, a nivel de pas por ejemplo seran cuatro. Respecto al esquema de la figura 14, las consultas a cualquier nivel de la dimensin se resuelven haciendo a lo sumo dos joins, existan o no tablas de agregacin. La eleccin 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 informacin de todas las localidades del mundo que si contiene informacin de 100 localidades correspondientes a 20 departamentos, de 2 provincias y del mismo pas. En este caso los dos niveles superiores de la dimensin no se consultarn (probablemente ni siquiera se incluyan en el modelo) y las diferencias en los tiempos de respuesta no se notarn, cualquiera sean el esquema y la agregacin que se utilicen. S es probable que se note la diferencia en la complejidad de la elaboracin de consultas. Por ltimo existe una opcin totalmente extremista, en la que podra caerse por error al realizar los primeros diseos, que sera desnormalizar a nivel de la tabla de hechos, ingresando como campos de esta tabla a los atributos de la dimensin. Este caso sera un error de diseo porque se pierde el concepto de dimensin en s. Adems habra mucha redundancia de datos, ocupara mucho espacio y exigira alto grado de mantenimiento. En las figuras 15 y 16 se muestran dos posibilidades de cmo podra quedar el diseo en caso de implementar esta decisin. En la propuesta de la figura 15 se tratan los diferentes niveles de una dimensin 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 ms destacable es la diferencia conceptual, debido a que se generan dimensiones separadas para representar una misma entidad. Esto dificulta el anlisis.

62

Captulo 3 - El proceso de creacin de modelos analticos

Tabla de hechos nivel pais Region_id Region_desc Pais_id Pais_desc Provincia_id Provincia_desc Depto_id Depto_desc Localidad_id Localidad_desc Pais_id Region_id Tabla de hechos nivel pcia Pcia_id Pais_id Region_id Tabla de hechos base Localidad_id Depto_id Pcia_id Pais_id Region_id

Figura 15. Desnormalizacin de la dimensin Ubicacin dentro de las tablas de hechos, considerando los niveles de la dimensin como dimensiones independientes.

La variante de la figura 16 mantiene el concepto de dimensin y permite modelar a todos los atributos como parte de una jerarqua y hacer drill down. A la vez resolvera todas las consultas con un nico join. Pero esta redundancia extrema deforma el modelo y dificulta la elaboracin de las consultas. Si el volumen de informacin fuese grande ocupara espacios enormes y con volumen chico no se necesita porque la supuesta mejora en la performance no sera evidente. Esta opcin complica el entendimiento y mantenimiento del modelo y de los datos.
Tabla de hechos base Region_id Region_desc Pais_id Pais_desc Region_id Provincia_id Provincia_desc Pais_id Depto_id Depto_desc Pcia_id Localidad_id Localidad_desc Depto_id Localidad_id Depto_id Pcia_id Pais_id Region_id Tabla de hechos nivel pcia Pcia_id Pais_id Region_id Tabla de hechos nivel pais Pais_id Region_id

Figura 16. Desnormalizacin de la dimensin Ubicacin dentro de las tablas de hechos, manteniendo la jerarqua de la dimensin.

En general cada dimensin debe estar relacionada por una nica clave a cada tabla de hechos, en el nivel de granularidad que corresponda.

63

Captulo 3 - El proceso de creacin de modelos analticos

Subdimensiones y jerarquas mltiples dentro de una dimensin Hay casos que requieren especial atencin respecto a la decisin a tomar sobre normalizacin. Se trata de las dimensiones que presentan subdimensiones y/o tienen mltiples jerarquas. Se dice que existe una subdimensin cuando dentro de una dimensin se puede identificar una entidad independiente que se relaciona con la principal. Por ejemplo, la ubicacin del cliente. Si el cliente est asociado a una localidad, la ubicacin geogrfica del cliente puede verse como una subdimensin dependiente. No tendra sentido incluir todos los datos de la dimensin ubicacin por cada registro que exista en la tabla de cliente. Cualquiera sea el esquema elegido para modelar la dimensin ubicacin, dentro de la tabla de cliente slo deber incluirse la clave de la ubicacin (localidad_id). Tener otros datos de ubicacin a nivel de cliente ocupara muchsimo espacio y dificultara el mantenimiento de las localidades. Adems la independencia de la tabla ubicacin permite su reuso en otras dimensiones (como por ejemplo la ubicacin 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 dimensin de la cual depende a travs de atributos de una jerarqua principal. Por ejemplo la dimensin cliente podra consistir de los niveles: tipo de cliente y cliente, y la subdimensin ubicacin del cliente podra modelarse en forma separada bajo el nombre de destinos o mercados. Dependiendo de las facilidades de la herramienta que se elija para explotar la informacin, y en particular si soporta o no modelar ms de una jerarqua dentro de las dimensiones, las subdimensiones se podrn visualizar como una jerarqua ms o como una dimensin separada. Una situacin similar ocurre cuando atributos de una dimensin se modelan como dimensiones separadas. Esto puede suceder cuando una dimensin tiene mltiples jerarquas. Por ejemplo para el caso de la dimensin producto se identifica la jerarqua principal: tem, lnea, categora y rubro, y tambin los atributos marca y color. Si la herramienta elegida no permite manejo de mltiples jerarquas, ser la principal la que se muestre dentro de la dimensin y las secundarias debern modelarse como dimensiones separadas. En los cubos MOLAP cuando las subdimensiones y/o las jerarquas 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 definicin del cubo29.

29

Observar en el caso prctico los ejemplos de subdimensiones, especialmente de procedencia del alumno, y otros atributos como sexo, edad, nacionalidad. Estos se modelan como dimensiones separadas a travs de la definicin de campos virtuales en lugar de incluir estos campos en las fuentes de datos.

64

Captulo 3 - El proceso de creacin de modelos analticos

Dimensiones con valores variables Existen dimensiones completamente estticas, con valores bien determinados. Tal vez nuevos valores sean agregados, pero los existentes en el DW jams sufren modificaciones. Tambin hay casos donde el elemento de la dimensin en s no cambia (la clave en el sistema operacional es la misma) porque se refiere a la misma cosa, pero s cambia la descripcin o alguno de los atributos. Esto puede ocurrir por correccin de errores, o porque el dato sufre alguna modificacin 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 dimensin con el valor nuevo. Esta opcin se usa para correcciones de errores, y pierde la historia del elemento. Crear un nuevo registro en la dimensin para el nuevo valor. Es la solucin 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 dimensin para guardar el valor previo inmediato del atributo. Es para cambios no muy importantes, que no determinan una particin histrica. Aunque el valor cambi se puede hacer de cuenta que no se modific. Tambin 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 trmino 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 tcnicas a utilizar son las mismas, slo que es probable que en estos casos sea ms importante guardar la historia de los valores. Otros tipos de dimensiones que merecen especial atencin, son los casos de las dimensiones grandes y las dimensiones degeneradas. Se dice que una dimensin 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 tcnicas para mantenerlas controladas, sobre todo cuando cambian rpidamente. Las dimensiones degeneradas son dimensiones donde la descripcin es la clave en el sistema operacional, por ejemplo un nmero de factura, o el nmero de inscripcin. En estos casos los cdigos no se regeneran sino que se toman los originales y se ponen en la tabla de hechos. La dimensin consiste slo del cdigo y por eso se dice que est degenerada (no tendr tabla asociada).

65

Captulo 3 - El proceso de creacin de modelos analticos

Definicin de las medidas

Una vez diseado el Data Mart, la granularidad de las tablas de hechos y habiendo diseado las dimensiones resta el ltimo paso en la definicin de cada modelo dimensional, que consiste en la definicin de las medidas. A continuacin se presentan los diferentes tipos de mtricas que existen y algunas tcnicas para manejarlas. Medidas aditivas, semi-aditivas y no aditivas Una medida es aditiva si tiene sentido sumar sus valores a travs de todas las posibles dimensiones. Siempre que sea posible deben incorporarse a las tablas de hechos medidas que sean perfectamente aditivas. Mtricas de actividad, numricas y discretas, como unidades o importe correspondientes a una venta, generalmente cumplen con esta caracterstica. Sin embargo las medidas de intensidad, tambin numricas, como balances de cuentas y niveles de inventario, no son perfectamente aditivas. En estos casos generalmente es posible sumar los valores a travs de todas las dimensiones menos en el tiempo. Medidas de este tipo se pueden combinar a travs del tiempo calculando lo que denomina time-average o promedio en el tiempo. Esta frmula de clculo est basada en el promedio de los hijos. En caso que existan tres niveles: ao, mes y da, el valor en el mes ser la suma de los valores en cada da del mes dividido la cantidad de das del mes, y el valor en el ao ser la suma de los valores en los meses dividido doce (o la cantidad de meses correspondiente al ao 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 algn mtodo de agregacin que sea vlido para todas las dimensiones. Otra alternativa es limitar el alcance de las consultas al nivel de granularidad en que est definido el dato. La mayora de estos casos pueden surgir de no haber elegido bien la granularidad de la tabla de hechos. Los datos en el nivel de granularidad ms bajo suelen ser aditivos. En raras ocasiones es posible que una medida sea textual en lugar de numrica. El diseador deber intentar modelar estos casos como dimensiones, y de llevar los textos libres a una lista de alternativas. Medidas con mltiples unidades Diferentes medidas de un negocio pueden ser la misma expresada en diferentes unidades de medicin. Como ejemplos sencillos podran considerarse: expresar distancia en metros, kilmetros, millas, leguas, o importe de una venta en pesos, en miles de pesos, en dlares, etc. En los negocios que involucran varios procesos encadenados en etapas y en los cuales se monitorea el flujo de los productos a travs del sistema suelen presentarse casos un poco ms complejos de conflictos con las medidas de cantidades. Esto es porque existen mltiples medidas en los diferentes puntos de la cadena, debido a que los nmeros son expresados en diferentes 66

Captulo 3 - El proceso de creacin de modelos analticos

unidades de medicin. Por ejemplo, en los distintos sectores pueden contarse: unidades de envo (paquetes y cajas que se trasladan del depsito 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 econmicas posibles, en trminos de valor de inventario, precio de lista, precio de venta original, precio de venta final. Esta situacin puede ser agravada si adems se tienen muchas mtricas diferentes. En estos casos no es correcto incluir en la tabla de hechos slo a las medidas fundamentales, porque se perdera parte del anlisis. Tampoco es correcto incluir a todas las posibles combinaciones de medidas fundamentales expresadas en las diferentes unidades de medida y por cada factor de valuacin posible (porque la tabla sera gigante). La solucin consiste en identificar a las medidas fundamentales, los factores de conversin y los factores de valuacin, 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 combinacin correspondiente. A veces se cae en la tentacin de incluir los factores de conversin en alguna tabla de dimensin (por ejemplo: contenido individual, cantidad de unidades por paquete de venta, y cantidad de paquetes por caja de envos, podran incluirse en la tabla de productos). En general esto no se recomienda porque los factores de conversin suelen variar, lo que obligara a generar nuevos registros en la tabla de dimensin para mantener los cambios. Estos factores, especialmente los asociados a costos y precios, suelen evolucionar en el tiempo y se asemejan mucho ms a medidas que a atributos de dimensin. Empaquetar todas las medidas y todos los factores de conversin juntos en el mismo registro de la tabla de hechos es la manera ms segura de garantizar que esos factores sern usados correctamente. Medidas bsicas y derivadas Existe una clasificacin importante entre las medidas bsicas, que existen naturalmente a partir de un evento, y las que se calculan en funcin de una o ms de ellas, denominadas medidas derivadas. Se dice que una medida es bsica 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 ao actual con respecto al mismo valor el ao anterior, la tasa de egresados sobre ingresantes, etc. Hay dos tipos de medidas derivadas:

67

Captulo 3 - El proceso de creacin de modelos analticos

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 mltiples unidades de una medida presentado anteriormente, el clculo de ganancia (como diferencia entre ventas y costos), etc. Estos casos suelen resolverse mediante vistas que se presentarn a los usuarios.

Los clculos 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 clculos y los tiempos de respuestas. Las herramientas del mercado suelen proveer diferentes formas de definicin de medidas

derivadas en funcin de las bsicas. Incluyen frmulas de clculo complejas y muchas veces evitan tener que realizar clculos en el DW. Estas frmulas pueden utilizarse en la etapa de diseo, quedando as las medidas derivadas incorporadas al Data Mart o cubo. Tambin pueden usarse en la interfaz de consulta, permitiendo a los usuarios avanzados definir sus propias medidas y compartirlas. Un error frecuente es finalizar el diseo bsico de la base de datos ignorando las medidas derivadas y recin tenerlas en cuenta cuando comienza el desarrollo de las aplicaciones de usuarios. Generalmente sern necesarios muchos clculos del negocio que habr que concensuar y es preferible anticiparse a estas tareas, sobre todo para asegurarse que todas las medidas bsicas necesarias son tenidas en cuenta. Normalizacin de tabla de hechos Hay otro tipo de normalizacin que no se explic en la seccin 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 ms comn es modelar estas medidas como columnas separadas dentro de la tabla de hechos. Tambin es vlido usar una sola columna denominada monto junto con una dimensin adicional que represente el tipo de monto (en este caso los valores: bruto, descuento, etc.). Esta solucin 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 tamao de esta. Adems, tener las medidas como columnas de un mismo registro es en general mucho ms til para operar con ellas y realizar clculos (por ejemplo porcentaje del descuento sobre el monto bruto). Estas operaciones se dificultan si los valores estn en registros separados.

30

Entindase que la medida derivada es perfectamente aditiva por las dimensiones del modelo. No quiere decir que sea calculada como una suma de medidas bsicas, sino que la medida resultante puede sumarse.

68

Captulo 3 - El proceso de creacin de modelos analticos

Diseo multidimensional avanzado.

Existen situaciones particulares del modelado dimensional donde la eleccin de una estructura puede ser muy efectiva, o por el contrario donde se corre el riesgo de elegir un diseo ineficiente. En esta seccin se plantean algunas consideraciones a tener en cuenta. Para obtener mayor detalle de los casos planteados, ejemplos y grficos, consultar bibliografa ([Kim1998] y [Kim2002]). Dimensiones muchos a muchos En la mayora de las situaciones clsicas de diseo la existencia y granularidad de la tabla de hechos es bsica y bien entendida, y las dimensiones adjuntas son obvias y no polmicas. Pero existen casos donde una dimensin puede tener legtimamente ms de un valor o ninguno para un mismo registro. A estos casos se los suele denominar dimensiones muchos a muchos. Analizando por ejemplo la temtica del cuidado de la salud, se puede crear una tabla de hechos por cada registro de tratamiento realizado a algn paciente. La dimensin diagnstico es muchos a muchos, dado que el tratamiento aplicado a un paciente puede tener ms de un diagnstico (y tambin puede no tener ninguno). Para resolver este problema y proveer un nmero arbitrario de valores (o diagnsticos) se inserta una tabla de relaciones (o tabla puente) entre la tabla de hechos y la dimensin en cuestin. En el ejemplo se creara una tabla denominada grupo de diagnsticos, con una nueva clave, que es la que se utilizar en la tabla de hechos. La tabla de grupo de diagnsticos tendr una clave compuesta, consistente de la clave del grupo y la clave del diagnstico y un campo adicional que es el factor de peso asociado a ese diagnstico dentro de ese grupo. El factor de peso asociado cumple el rol de poder analizar al total de tratamientos agrupados y correctamente sumarizados segn el peso de los diferentes diagnsticos. Alternativamente este factor de peso podra no usarse y contar a cada tratamiento por cada diagnstico, multiplicando la cantidad de tratamientos, pero permitiendo evaluar el impacto de cada diagnstico, en trminos de la cantidad total de tratamientos asociados. Esta estructura permite ambos anlisis. El usuario decidir cul consultar. Roles de las dimensiones Un rol en un DW es una situacin en la que una misma dimensin 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 travs de una cadena de procesos. All la dimensin fecha aparece repetidas veces representando la fecha de recepcin de la orden de pedido, la fecha de facturacin, de envo, 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

Captulo 3 - El proceso de creacin de modelos analticos

Como la entidad en cuestin es la misma (los valores son iguales) no tiene sentido mantener ms de una tabla con la misma informacin. Se crea entonces una nica tabla de dimensin, y las diferentes dimensiones del modelo hacen referencia a la misma tabla fsica, 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 dimensin estn embebidos dentro de otra, como el caso presentado de la subdimensin ubicacin del cliente, requieren ser normalizados para poder ser representados por una nica tabla. Pocas o muchas dimensiones Como regla general se dice que la mayora 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 nmero muy grande de dimensiones es usualmente un signo de que muchas de ellas no son totalmente independientes y podran ser combinadas en una sola dimensin. Distribucin de medidas de distinta granularidad Una vez vistos aspectos particulares del modelado de dimensiones, resulta tambin interesante considerar algunas caractersticas de diseo avanzado de las tablas de hechos referentes al manejo de la granularidad y agregaciones. El modelo dimensional es ms poderoso cuanto ms atmicas son las tablas de hechos. Cuando en un diseo surgen hechos de granularidad diferente lo primero que se debiera hacer es tratar de forzar a todas las medidas al nivel ms bajo. Este proceso se conoce como asignacin o distribucin de medidas de niveles altos hacia niveles inferiores. Existen varios casos donde es necesario aplicar esta tcnica en DWs. El ms dominante es tal vez la alocacin de costos. Por ejemplo en una factura de transporte de mercadera 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 distribucin de algunas de estas medidas puede tener una lgica muy compleja. Sera 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 distribucin de medidas hacia el nivel de granularidad ms bajo no resultara posible, el diseador no tendr otra alternativa que representar los niveles ms 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 afn de mejorar los tiempos de respuesta o simplificar las consultas, se comete el error de guardar informacin agregada que debiera ser calculada dentro de los registros de una tabla de hecho. Por 70

Captulo 3 - El proceso de creacin de modelos analticos

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 ms de un da se correra el riesgo de contar ms de una vez el mismo valor. Agregaciones Luego de haber determinado el diseo global es necesario considerar la estrategia que se usar para agregar tablas de hechos y de dimensiones. Cada nivel de agregacin que se decida incorporar debe tener su propia tabla de hechos. Las tablas de dimensin adjuntas a estas nuevas tablas de hechos deben ser, cuando sea posible, versiones encogidas de las tablas de dimensin originales. Las agregaciones, tambin conocidas como tablas de redundancia, tienen el objetivo de mejorar los tiempos de performance y estn ligados a la implementacin fsica del modelo dimensional. La creacin 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. Tambin ser necesario monitorearlas a travs del tiempo y hacer los ajustes necesarios cuando haga falta, en funcin del crecimiento del DW. Hay dos puntos a considerar al construir las agregaciones: las peticiones comunes del negocio y la distribucin estadstica de los datos. Primero habr que determinar qu podra ser til revisando en la documentacin del relevamiento cules son las necesidades para reportes de alto nivel. Luego, revisar cada dimensin para determinar los atributos usados comnmente en reportes, y las combinaciones de estos atributos para ver cuales se utilizan juntos. Cuantas ms dimensiones haya ms cuidadoso hay que ser porque mayor ser la cantidad de combinaciones para las cuales se podran crear agregaciones. En segundo trmino se necesita evaluar la distribucin estadsticas de los datos. Para esto referirse al prototipo de exploracin de datos, la informacin de diseo de las tablas, y a los datos en s mismos, buscando contabilizar la cantidad de valores de cada nivel de la jerarqua de cada dimensin. Existen tcnicas de diseo ms avanzadas sobre agregaciones que incluyen modelado de dimensiones estructuradas con jerarquas parciales, jerarquas con profundidades impredecibles, formas de resolver los casos donde los atributos de las dimensiones cambian de valor, dimensiones de auditoria, cmo manejar la dimensin tiempo (dentro del da) para representar rangos horarios, etc..

31

Si la tabla de hechos contiene pocos miles de registros probablemente responda rpido y no necesite agregaciones. Diferente es si tiene cientos de miles o millones de registros.

71

Captulo 4 Presentacin del caso de estudio

Presentacin del caso de estudio

El ejemplo de aplicacin elegido se basa en la temtica de desercin de alumnos

universitarios. Esto es, contar con informacin que colabore con la identificacin de perfiles y patrones de los alumnos que dejan de tener actividad acadmica en la universidad. El abordaje del tema se circunscribe a la definicin de un modelo dimensional que permita identificar caractersticas y comportamientos generales de los alumnos universitarios y realizar un desgranamiento de estos. El tema se encara desde el diseo, no se pretende involucrar cuestiones sociolgicas que quedan fuera del alcance computacional. Para el caso de estudio se usa como sistema operativo de partida el sistema de gestin acadmica de alumnos SIU-Guaran y especficamente su modelo de datos. El SIU-Guaran es un sistema de desarrollo evolutivo diseado e implementado por el SIU. Actualmente es utilizado con sus personalizaciones particulares como sistema de gestin acadmica en muchas de las universidades nacionales argentinas. La herramienta sobre la que se desarrolla el ejemplo es O3, de la empresa IdeaSoft. La eleccin de la herramienta tuvo en consideracin que la misma ya est siendo utilizada muchas de las universidades del pas, promovida por el SIU mediante los modelos de anlisis de informacin que desarrolla.

4.1

Qu es el SIU?
El SIU es un rea dependiente de la Secretara de Polticas Universitarias, perteneciente

al Ministerio de Educacin, Ciencia y Tecnologa32, que desarrolla sistemas de gestin y tambin sistemas para la toma de decisiones y el anlisis institucional en el mbito de las Universidades Nacionales Argentinas. Adems de desarrollar soluciones informticas, el SIU ayuda en la implementacin de las mismas. Dentro de este mbito tambin se realizan desarrollos para diferentes reas de la Secretara de Polticas Universitarias, donde se recibe y consolida informacin 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 informacin, contribuyendo de esta forma a mejorar la gestin de las instituciones, permitindoles optimizar sus recursos y lograr que el software sea aprovechado en toda su potencialidad. La filosofa consiste en utilizar la tecnologa al servicio de la institucin colaborando as en el mejoramiento de la gestin, agilizando las operaciones diarias de la comunidad universitaria. Tambin se hace hincapi en la calidad de la informacin que se lleva en los sistemas para su anlisis y utilizacin en la toma de decisiones estratgicas.
32

Informacin a septiembre del 2007. En 2008 el SIU cambia de autoridades pasando a depender de un consorcio de universidades y adoptando el nombre de Consorcio SIU.

72

Captulo 4 Presentacin del caso de estudio

El SIU tiene una modalidad de trabajo colaborativo en red, involucrando a distintos actores de las universidades. La metodologa de trabajo se basa principalmente en la transferencia de conocimiento, el intercambio de productos y la promocin de encuentros [6] [7]. Los sistemas desarrollados abarcan la gestin operativa de las distintas reas de una universidad: acadmica, econmica-financiera, recursos humanos, bibliotecas, etc., y su correspondiente visin gerencial. Entre los sistemas desarrollados: SIU-Pampa/SIU-Mapuche: Sistema de recursos humanos. Gestin del personal y liquidacin de sueldos. SIU-Comechingones/SIU-Pilag: Sistema presupuestario-contable. SIU-Guaran: Sistema de gestin de alumnos (carreras, graduados, aulas, etc.) SIU-Kolla: Encuestas para seguimiento de graduados SIU-Araucano: Sistema estadstico de alumnos. Datos que se informan al Ministerio de Educacin. SIU-Tehuelche: Sistema de gestin de becas universitarias. SIU-Quilmes: Sistema de gestin de cobranzas. En la actualidad, el nmero 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 estn utilizando al menos dos de los sistemas del SIU. En los ltimos aos el SIU ha logrado satisfacer la necesidad de contar con informacin confiable y oportuna en diferentes niveles de la gestin de las Universidades Nacionales, colaborar en la cultura de la transparencia, acompaar la mejora de los procesos administrativos, incentivar la integracin de reas que tradicionalmente se encuentran atomizadas, estandarizar datos y procesos, arraigar la concepcin de la capacitacin del personal administrativo como una inversin, e incorporar nuevas tecnologas [7]. Actualmente el SIU se percibe como un importante capital y una avanzada en lo que hace al desarrollo, distribucin de sistemas y trabajo cooperativo, sobre todo por pertenecer a la administracin pblica.

4.2

El sistema de software SIU-Guaran

El SIU-Guaran es un sistema de gestin acadmica desarrollado por el SIU para todas las

Universidades Nacionales. Fue concebido con el propsito de proveer a las universidades de una herramienta que les permita administrar la gestin de alumnos en forma segura, con la finalidad de obtener informacin consistente para los niveles operativos y directivos. El sistema registra y acompaa la actividad formativa del alumno desde que ingresa a la universidad hasta que egresa, llevando registro de toda la actividad acadmica intermedia, El SIU-Guaran administra toda la 73

Captulo 4 Presentacin del caso de estudio

informacin de gestin acadmica: carreras, planes de estudio, ttulos, materias, egresados, inscripciones y resultados de trabajos prcticos y exmenes, profesores asociados a las ctedras, asignacin 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 metodologa de trabajo colaborativa en red que permite su autosustentabilidad. Hasta el momento cuenta con ms de 200 implementaciones en unidades acadmicas 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 travs de distintas interfaces, cada una con su funcionalidad: de gestin administrativa, terminales de autogestin, Internet, o por telfono (utilizando tecnologas sms y wap) [6] [7]. Ms all de las caractersticas del sistema informtico como producto (aspectos tecnolgicos, prestaciones, mdulos, usuarios, etc.) es interesante resaltar la visin del Guaran como proyecto. El SIU-Guaran integra componentes sociales, tecnolgicos, polticos, culturales y econmicos que interactan entre s. El objetivo del proyecto es desarrollar un nico sistema informtico para todas las Universidades Nacionales con una arquitectura tcnica que permita que cada institucin pueda extenderlo o personalizarlo, manteniendo la compatibilidad. Esto permite al sistema reflejar la realidad particular de las instituciones. El proyecto SIU-Guaran surge hacia fin de ao del 1996, luego de un importante trabajo de relevamiento de la situacin del sistema universitario argentino. Se decide desarrollar un sistema informtico de gestin de alumnos que contemplara la complejidad y heterogeneidad del sistema universitario argentino. Que se adaptara a las realidades de las diferentes unidades acadmicas, que permitiera acompaarlas en la mejora de sus procesos [6] [7]. El desarrollo del sistema comenz en agosto del 1997 con la conformacin de un comit de desarrollo, integrado por un equipo del SIU y tcnicos de las universidades para relevar las necesidades funcionales. Como metodologa 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 tcnicos de las universidades, quienes son responsables de la implementacin, y se establecen como socios del proyecto. Desde el SIU se asesora y colabora. La filosofa de trabajo se puede sintetizar en los siguientes lineamientos: trabajo colaborativo, transparencia, integracin y conocimiento compartido. Una evaluacin del proyecto permite observar el impacto que ha producido el desarrollo del SIU-Guaran hasta el momento. Se han automatizado reas de gestin de alumnos, haciendo ms eficientes los procesos y brindando integridad, seguridad, completitud y confiabilidad a los datos. Entre otros aspectos, se destacan: el aumento creciente de unidades acadmicas que han implementado el SIU-Guaran, la extensin del proyecto a otras reas del sistema educativo, la ampliacin del grupo de tcnicos y de usuarios operativos capacitados en el sistema, el inters por 74

Captulo 4 Presentacin del caso de estudio

parte de distintos organismos en incorporar la metodologa de trabajo y la consolidacin de una filosofa de trabajo en red al interior de las universidades [7].

4.3

Desercin y desgranamiento de alumnos

La desercin universitaria es un tema que ha despertado mucho inters en el ltimo

tiempo. El costo econmico 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 fenmeno de la desercin, y tambin el de repitencia, tiene importantes implicancias personales, institucionales, sociales y econmicas. En lo personal, implica una condicin de fracaso que afecta emocionalmente a los individuos, especialmente en su insercin laboral. En lo institucional implica una disminucin del rendimiento acadmico de la universidad y un incremento innecesario del nmero de alumnos y el costo de mantenimiento de estos. En lo social, la desercin contribuye a generar inequidad y desequilibrios sociales y desvirta los objetivos que la sociedad le ha entregado a la educacin superior. Tambin produce un aumento del subempleo y falta de aporte intelectual. En lo econmico, el costo que esto implica para los sistemas es enorme. En un estudio de UNESCO realizado en febrero de 2004 en 15 pases que cubren un 90% de Latinoamrica el costo de la desercin se estimaba en U$ 11,1 billones de dlares al ao, lo que, segn se indic, en pases como Brasil equivale al costo de 2 millones de estudiantes universitarios [8] [9]. El problema de la repitencia y la desercin es de una magnitud considerable en todos los pases de la regin. En Argentina se estima que slo el 12% de los estudiantes que ingresan a las universidades nacionales se gradan, y si bien no hay datos oficiales para las instituciones privadas se estima que es del orden de un 30%. Un 50% de la desercin ocurre durante los dos primeros aos 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 tipologa 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 exmenes cuando se quiere, por lo que las permanencias tienden a ser muy largas. Al respecto existen dos problemas: la desercin y la exclusin. Los factores de la desercin se atribuyen a causas externas como el lugar de residencia, las caractersticas socioeconmicas y la educacin de los padres y tambin a causas internas tales como las polticas de administracin, la falta de orientacin vocacional y el exceso de programas. Entre las posibles acciones para mejorar la situacin actual se indicaron la deteccin 75

Captulo 4 Presentacin del caso de estudio

temprana de posibles desertores, la prevencin, el apoyo, la determinacin de momentos problemticos y la articulacin con la escuela media. Como propuestas para superar la desercin se sealaron los programas de becas, los programas de articulacin con la educacin media, la orientacin vocacional, y el establecimiento de ciclos generales de conocimientos bsicos. Con ellos se pretende dar respuesta a problemas de desercin, retraso en los estudios, eleccin de carrera y movilidad institucional [9]. El caso prctico de esta tesis busca plantear un modelo dimensional que ayude a encontrar dnde se concentran los mayores problemas dentro de una institucin e identificar posibles causas. Este conocimiento permitir que desde la universidad puedan tomarse acciones que ayuden a resolver los problemas existentes basndose en datos concretos. El tema seleccionado es complejo y desde el punto de vista de la tesis, slo se pretende aplicar y explicar los conceptos tericos presentados previamente en un caso prctico. Como segundo objetivo se espera que los resultados obtenidos sirvan como disparador para su implementacin en las universidades que actualmente estn utilizando el SIU-Guaran y que esta primera aproximacin hacia obtener conocimiento desde la informacin incentive desarrollos en esta rea. En los prximos captulos se explica paso a paso el diseo dimensional siguiendo las etapas del ciclo de vida BDL. Sin lugar a dudas las implementaciones concretas y la retroalimentacin de usuarios finales reales permitirn que este proyecto siga creciendo.

76

Captulo 5 Presentacin de la solucin

Presentacin de la solucin
Este captulo consiste en el desarrollo del modelo para el caso prctico que sigue la

aplicacin personalizada de la metodologa BDL presentada en el captulo 3. Algunas etapas del BDL no tienen sentido dadas las particularidades del ejemplo elegido.

5.1

Requerimientos y especificacin del Data Mart

Al presentar la etapa de definicin de requerimientos como parte del ciclo de vida de un

proyecto de Data Warehousing se recalc la necesidad de contar con usuarios que estn 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 especificacin de requerimientos. Tampoco se cuenta con usuarios a los cuales realizar las entrevistas planteadas por la metodologa para esta etapa. Por lo tanto el anlisis de requerimientos para la solucin presentada surge de quien escribe y la observacin de algunas de las necesidades de informacin de la comunidad universitaria, por trabajar desde hace unos aos ese mbito. Cmo se plante anteriormente, mediante este trabajo se busca aplicar en un caso prctico los conceptos tericos presentados. Adicionalmente se espera que las posibilidades de anlisis sirvan como puntapi inicial para incentivar una propuesta que realmente pueda usarse para tomar decisiones. Cabe aclarar que la complejidad de la temtica abordada requiere que los datos sean analizados por un grupo interdisciplinario, donde podran participar socilogos, psiclogos, estadsticos y otros profesionales capaces de realizar interpretaciones correctas sobre la informacin, definir variables, agrupadores, y tambin de esta forma colaborar al crecimiento de la esta solucin.

Datos considerados
La idea principal de este trabajo consiste en la identificacin de perfiles de alumnos que dejan de tener actividad acadmica en la universidad. Para esto se consideran datos en tres niveles diferentes de anlisis: el alumno en cada uno de los aos acadmicos 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 ms de una carrera es interesante evaluarlo tambin como individuo en toda la universidad, independientemente de la o las carreras en que registre actividad.

77

Captulo 5 Presentacin de la solucin

Estos niveles determinan las medidas del cubo: cantidad de personas, cantidad de alumnos y cantidad de alumnos por cada ao con actividad. Las dimensiones que se utilizan son variables de evaluacin de la actividad acadmica (por ejemplo el total de materias aprobadas en un ao, el total de cursados pendientes de exmenes, 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 SIU-Guaran 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 situacin socio-econmica 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 interpretacin 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 situacin 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 algn tipo de asesoramiento. Problema para asociar los datos censales con un perodo acadmico. Los datos censales pueden completarse y actualizarse en diferentes momentos del ao, pudiendo existir ms de un registro por persona por ao. En las universidades y facultades se toman criterios propios sobre la actualizacin de estos datos. No se tiene buena calidad en estos datos en la mayora de las implementaciones. Las universidades no suelen darles importancia porque no son necesarios para las tareas imprescindibles de un sistema acadmico de alumnos, entonces muchos datos estn sin completar o presentan inconsistencias. Por ltimo, en cada instalacin de SIU-Guaran se puede personalizar el formulario de datos pedidos, pudiendo diferir no slo en el significado y contenido sino tambin en el conjunto de datos existentes y los perodos de relevamiento. De hecho, la UNS cuenta con personalizaciones respecto a esta informacin. Tener en cuenta estos datos hubiese requerido desarrollar procesos de extraccin de datos personalizados. Inicialmente se pens adems en definir categoras de actividad de los alumnos (por ejemplo clasificar la actividad anual en: nula, baja, suficiente, alta y muy alta, en funcin de la
33

Observar que si el anlisis que se pretendiera hacer fuese otro, las medidas y dimensiones podran considerarse totalmente diferentes. Por ejemplo el alumno podra ser una dimensin y la cantidad de cursados aprobados, cursados desaprobados, finales aprobados, etc. podran ser medidas.

78

Captulo 5 Presentacin de la solucin

cantidad de finales y cursados), intensin de actividad (en cuntas materias se inscribe o se presenta a rendir) y categoras de rendimiento (en funcin de los resultados obtenidos). Finalmente se desech la propuesta. Resulta complicado en una aplicacin real definir estos parmetros que en gran medida dependen del plan de estudio, lugar geogrfico, situaciones sociales, etc. Para realizar una clasificacin justa habra 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 mayora de los alumnos trabaja, provienen de otro lugar, viven lejos de la universidad, etc. Todo esto terminaba oscureciendo las frmulas y alejndonos de los objetivos del caso de estudio. Otras variables que resultan de inters para el anlisis de desercin y desgranamiento refieren a la lentificacin en la carrera (respecto al plan de estudio o al promedio histrico de tiempo desde el ingreso hasta la graduacin en la carrera), la repitencia (si el alumno debe recursar materias, o rendir muchas veces algn final) y la movilidad (si se producen cambios de carrera). Es muy difcil definir este tipo variables. Al intentarlo surgen preguntas como por ejemplo: Qu alumnos deben ser considerados para calcular el promedio histrico? A partir de qu cohorte se considera? Existen todos los datos necesarios en la base de datos OLTP SIU-Guaran? Cmo calcular lentificacin?, es la cantidad de materias cursadas sobre la cantidad total del plan actual del alumno? Y si el alumno se cambi de plan, cmo debieran contarse las materias del plan anterior? Qu sucede si el plan est compuesto de materias y crditos? Cundo se considera que un alumno se movi de carrera?: porque qued de baja?, porque ya no se inscribe a materias? Qu sucede cuando slo 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 prctico

La arquitectura de la solucin propuesta se presenta en la figura 17 y es una adaptacin

de la presentada en la figura 3. En este caso, la base de datos del sistema SIU-Guaran es la nica fuente de datos. La seccin de transformacin de datos no existe explcitamente34. La extraccin de datos se realiza mediante la ejecucin de procesos que se incorporan en la base de
34

Debido a diversos motivos del sistema universitario, pero principalmente a la falta de maduracin en estas temticas, resulta difcil crear y administrar tanto un DW como un rea de transformacin de datos. Estas tareas, junto con la implementacin de una herramienta de ETL y la conexin de los cubos al DW (planteado en la figura) se dejan para trabajo futuro.

79

Captulo 5 Presentacin de la solucin

datos del SIU-Guaran. 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 diseo 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 mdulos de la herramienta O3. Estos se pueden clasificar en tres grandes categoras: los componentes de la interfaz de usuario (que sern las nicas herramientas para anlisis de informacin que se utilizarn en este trabajo), los de diseo y construccin de cubos y los de administracin de cubos en un servidor (O3 Server y O3 Administration Server, para configurar usuarios y permisos de acceso por perfiles).

O3 Builder
t x t t x t t x t

Load

O3 Browser (escritorio) O3 Report Modelo del cubo (.mdl) META DATA O3 Portal (web) O3 Designer O3 Server rea de usuario O3 Dashboard O3 Scorecard O3 Rules O3 Process O3 Query

BD SIUGuaran

E.T.

(sp)

Idealmente sera un DW

(O3 Query) O3 Adm Server

DW

Figura 17. Arquitectura de la solucin propuesta.

5.3

Matriz y modelo lgico del Data Mart

La matriz que resulta del anlisis de requerimientos planteados en la seccin 5.1.1 se

muestra en la figura 18. Se pueden ver claramente los tres niveles de anlisis contenidos en el Data Mart (persona, alumno y alumno por ao con actividad) y las dimensiones planteadas, junto con los cruces vlidos. El grfico presenta los ejes intercambiados respecto a la propuesta original slo para obtener una mejor visualizacin La mayora de las dimensiones (unidad acadmica, edad, ttulo secundario, cantidad de carreras activo, etc.) estn 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 ms de una y es la razn por la cual se distingue entre personas y alumnos. La dimensin Ao informado corresponde slo para la medida que cuenta alumnos en cada ao que tienen actividad. 80

Captulo 5 Presentacin de la solucin

Dimensiones

Niveles

Unidad Acadmica Ao de Ingreso Ao Informado ltimo Ao de Actividad Edad Sexo Nacionalidad Procedencia

Ttulo Secundario Ao de Egreso del secundario Orientacin Vocacional Cantidad de carreras inscripto activo Cantidad de carreras egresado Carrera Cursados Aprobados

Unidad Acadmica Ao de Ingreso a la Universidad Ao de Ingreso a la Carrera Ao Informado ltimo Ao de Actividad en la Universidad ltimo Ao de Actividad en la Carrera Edad al Ingreso a la Universidad Edad al Ingreso a la Carrera Edad al ao Informado Sexo Nacionalidad Pas Provincia Localidad Colegio Ttulo Secundario Ao de Egreso del secundario Orientacin 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 Ao Informado

X X X X X X X X X X X X X X X X X

X X X X X X X X X X X X X X X X X X X X X X

Cantidad de alumnos por ao con actividad X X X X X X X X X X X X X X X X X X X X X X X X X

Cantidad de personas

Cantidad de alumnos

81

Captulo 5 Presentacin de la solucin

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 Ao Informado Cursados Promovidos Totales por Persona Cursados Promovidos Totales en la Carrera Cursados Promovidos en la Carrera y Ao Informado Finales Aprobados Totales por Persona Finales Aprobados Totales en la Carrera Finales Aprobados en la Carrera y Ao Informado Finales Desaprobados Totales por Persona Finales Desaprobados Totales en la Carrera Finales Desaprobados en la Carrera y Ao Informado Equivalencias Externas Totales por Persona Equivalencias Externas Totales en la Carrera Equivalencias Externas en la Carrera y Ao Informado Figura 18. Matriz correspondiente al Data Mart del caso prctico.

X X X X X

X X X X X X X X X X

X X X X X X X X X X X X X X X

Varias de las dimensiones (las referentes a cantidades de materias y Edad) presentan tres niveles de anlisis, uno correspondiente a cada medida. Debe seleccionarse la combinacin de nivel y medida adecuada a la consulta deseada. Por ejemplo, si se quiere ver lo ocurrido dentro de una carrera y un ao en particular (utilizando la dimensin Ao Informado) se debe utilizar la medida Cantidad de alumnos por ao con actividad y consultar estas dimensiones en el nivel ms bajo (por ejemplo: Cursados Aprobados en la Carrera y Ao Informado). Si se desea evaluar lo realizado dentro de la carrera, sin discriminar por ao acadmico 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). Tambin es posible comparar lo ocurrido dentro de un ao acadmico con el total acumulado en la carrera, por ejemplo. Esto se logra consultando la medida Cantidad de alumnos por ao con actividad y la dimensin Cursados Aprobados en sus niveles en la carrera y ao informado y totales en la carrera en forma simultnea. La dimensin Ao de Ingreso tambin presenta dos niveles de anlisis: ingreso a la universidad (o unidad acadmica) 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 ms de un nivel o jerarqua se indican en color amarillo en el diagrama, por ejemplo procedencia y cursados aprobados.

82

Captulo 5 Presentacin de la solucin

Figura 19. Modelo de datos lgico del caso prctico. Tablas de hechos y dimensiones.

Observar que como un alumno es una persona, tambin podr consultarse la cantidad de alumnos por edad, o nacionalidad, y las dems 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 podra consultar Cantidad de alumnos por ao con actividad segn cursados aprobados para una carrera en un determinado ao acadmico (Cursados Aprobados en la Carrera y Ao Informado y Ao Informado) segn 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 segn Edad al Ao Informado o Edad al Ingreso Carrera, porque esa medida no est definida en esos niveles de granularidad.

5.4

Modelo fsico y consideraciones de diseo

El modelo fsico 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 visualizacin del mismo, y mapea la estructura de los archivos de texto en el cubo MOLAP (archivo con extensin mdl).

83

Captulo 5 Presentacin de la solucin

Diseo fsico 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 ms bajo es la de Alumnos por Ao Acadmico en que presenta actividad. Esta tabla puede considerarse del tipo fotografas peridicas con una foto por alumno y ao acadmico. Las otras dos tablas pueden considerarse de tipo fotografas acumulativas, pero donde se guarda slo el ltimo estado, reflejando la informacin acumulada a la fecha del alumno o la persona. Estas tablas cumplen una doble funcin como tablas de dimensin con atributos (y se definen como tablas locales en O3 dentro del archivo con extensin mdl). Tambin representan una agregacin 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 normalizacin 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 SIU-Guaran. Se intenta minimizar las transformaciones necesarias en los datos para lograr la arquitectura de la solucin definitiva. y para que el tamao de los archivos sea menor. La correspondiente desnormalizacin necesaria para el diseo final del Data Mart se logra dentro de la definicin propia del cubo de O3 y se realiza al momento de la construccin de este. Esto produce un incremento en el tiempo de generacin 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 desnormalizacin podra realizarse en l, o en las consultas SQL que surjan de modificar la definicin del cubo para consumir los datos. Las tablas diseadas para formar parte del DW son mostradas en la figura 20.

84

Captulo 5 Presentacin de la solucin

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 cdigo de la dimensin es la descripcin 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 definicin del cubo (archivo mdl). Tal es el caso de los aos (ao informado, ao 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 anlisis de una misma dimensin slo para simplificar el modelo final y no tener muchas dimensiones similares que dificulten el anlisis. 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 anlisis se decidiera usar estas cantidades como medidas no ser necesario calcularlas, se hara solo, definiendo la medida en el nivel ms bajo (de alumno en ao acadmico) y utilizando el mtodo de agregacin 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 anlisis ms especficos.

85

Captulo 5 Presentacin de la solucin

Diseo fsico del Data Mart

Respecto al diseo 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 estn se definen especialmente mediante la utilizacin de tablas locales y campos virtuales. Si las tablas estuvieran en una base de datos, en lugar de ser archivos de texto, el aplanamiento podra realizarse mediante uniones de tablas en las consultas en SQL y la creacin de tablas locales y campos virtuales no sera necesaria en la mayora de los casos. Definicin de fuentes de datos Especficamente dentro de la herramienta O3 el diseo de un cubo comienza con la definicin 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 parmetro, como en este caso (raiz).

Figura 21. Definicin de fuentes de datos en O3. Tabla de hechos correspondiente al archivo de texto con informacin de personas (int_de_personas.txt)

En la definicin de los campos y tipos de datos (figuras 22_1 y 22_2) puede utilizarse la funcin 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

Captulo 5 Presentacin de la solucin

Figura 22_1. Definicin de campos que componen el archivo de la fuente int_dw_desercion_alumnos_anio.

Figura 22_2. Definicin de campos que componen el archivo de la fuente int_dw_personas, que adems se utiliza como tabla local

La informacin entre tablas se vincula automticamente 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

Captulo 5 Presentacin de la solucin

Figura 23. Definicin de tabla de dimensin en O3.

Definicin de dimensiones La definicin de las dimensiones se realiza identificando los cdigos nicos de los valores para cada nivel de estas y las descripciones correspondientes. En la figura 24 se muestra la definicin de la dimensin Nacionalidad, compuesta por un nico nivel.

Figura 24. Definicin de una dimensin con solamente un nivel.

88

Captulo 5 Presentacin de la solucin

Las dimensiones deben tener al menos un nivel, pero pueden tener ms 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 dimensin se indica si el nivel ms bajo identifica unvocamente al resto de los niveles o no. Observar en la figura 25 la indicacin de Colegio como nivel nico de la dimensin. En estos casos slo es necesario incluir en las tablas de hechos la clave de ese nivel, el ms bajo.

Figura 25. Definicin de dimensin con varios niveles: Procedencia.

Definicin de medidas Por ltimo se definen las medidas, que pueden ser bsicas (corresponden a un campo de la fuente), o derivadas (se calculan a partir de medidas bsicas y/o datos adicionales).

Figura 26. Definicin de medida Cant Personas como medida bsica.

89

Captulo 5 Presentacin de la solucin

Para las medidas bsicas se indica el campo de la fuente al que corresponde, el mtodo 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. Mtodo de agregacin para la medida Cant Personas. Suma indica que por ejemplo en el nivel Localidad de la dimensin Procedencia se contar la suma de las personas de los colegios correspondientes.

Figura 28_1. Parte de la definicin del alcance de la medida Cant Personas.

Figura 28_2. Parte de la definicin del alcance de la medida Cant Personas.

La definicin del alcance de cada medida es una tarea importante y debe estar acorde a la lgica de los datos. En las figuras 28_1 y 28_2 se observa parte de lo realizado para Cant Personas. El nivel de cada dimensin 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 smbolo del diskette. De ese nivel para arriba en la jerarqua se utiliza en general la agregacin (smbolo de suma). En algunos casos podra optarse por dejarlo indefinido (signo de interrogacin) para obligar a que las 90

Captulo 5 Presentacin de la solucin

consultas se hagan seleccionando uno o ms 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 agregacin en la dimensin Procedencia, la indefinicin completa de la dimensin Carrera, la diferencia en la visualizacin final (al consultar el cubo) respecto a Ao Informado y la definicin del alcance slo 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 ao acadmico. Como no fueron incluidos explcitamente en los archivos de texto fuente de las medidas correspondientes esto debe indicarse al disear el modelo en O3, mediante la utilizacin de tablas locales y campos virtuales. En la figura 29 se puede apreciar la definicin 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 podrn obtenerse a partir de la combinacin de unidad acadmica y nmero de inscripcin.

En la figura 30 se muestra la definicin del campo NACIONALIDAD como campo virtual. Esto se utiliza para incorporar ese dato en los niveles de granularidad alumno y alumno en ao acadmico correspondientes a las otras tablas de hechos.
35

El detalle de las posibles combinaciones del alcance de las medidas es especfico de la herramienta y queda fuera de este trabajo.

91

Captulo 5 Presentacin de la solucin

Figura 30. Recuperacin del valor correspondiente a NACIONALIDAD mediante de la definicin 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 tambin se puede observar que los campos virtuales pueden ser utilizados con otros propsitos: 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 definicin de medidas, definicin de descripciones a partir de ms de un campo, etc.

5.5

Personalizacin del proceso ETL

El ejemplo elegido consta de tres niveles diferentes de definicin de tablas de hechos. El

proceso de extraccin consiste principalmente en la creacin de esas tres tablas, las cuales se construyen de la siguiente manera: En la tabla de alumno por ao, se crea un registro para cada ao por cada individuo que tiene actividad acadmica en cada carrera, comenzando por el ao de ingreso de esa persona a la universidad hasta el ao acadmico 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 ao acadmico y se agrega el registro a la tabla si alguna de esas cuentas es diferente a cero. La tabla de hechos de alumnos, recopila informacin del alumno dentro de la carrera: ao 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 travs de los distintos aos. La tabla de hechos de personas tambin 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. Adems en esta tabla se definen otros atributos de las personas que se representan
36

Tener en cuenta que las materias comunes se contarn dos veces, dependiendo de cmo se estn registrando en el SIU-Guaran, seguramente se cuente como materia aprobada en una carrera y como equivalencia en la otra.

92

Captulo 5 Presentacin de la solucin

como dimensiones (sexo, edad, procedencia, etc.). Los procesos de creacin de las tablas y llenado de las mismas se adjuntan en el apndice. Para este caso prctico la transformacin de datos es casi nula y se incluye como parte del proceso de extraccin. 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 bsicas es la creacin 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 transformacin de datos, dejando esta tarea para desarrollo futuro. Utilizar los cdigos originales facilita el control de datos extrados y sirve para mejorar la calidad de los datos del sistema de gestin. En este caso prctico tampoco es posible ejemplificar algunas consideraciones respecto a la integracin de datos, porque estos son extrados 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 sern

evidenciados cuando el cubo est generado. Ser necesario testear adecuadamente: el estado de los datos en la fuente, el proceso ETL y la definicin del modelo del cubo para asegurarse que la solucin 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 extraccin, transformacin y carga de datos podrn tomarse algunas decisiones que resuelvan los problemas de calidad de diferentes formas. Por ejemplo se puede decidir descartar un registro que contenga algn campo nulo, o rellenarlo con algn valor por defecto. Lamentablemente la mayora de los problemas se hacen evidentes al generar el cubo con informacin real, ya que es difcil contemplar todas las posibles anomalas que podran presentar los datos. Lo ms 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 podran existir, trabajar sobre las pocas o muchas que realmente surjan.

Controles en la definicin del modelo y la generacin del cubo

De los controles a realizar el ms sencillo es sobre la definicin del modelo del cubo. Una vez generado el cubo hay que controlar que todo el contenido de los archivos de texto haya sido 93

Captulo 5 Presentacin de la solucin

incorporado para la visualizacin final del usuario. El log de la generacin registrar errores y advertencias que sern 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 algn motivo se hayan excluido. Posiblemente el motivo de exclusin sea algn campo nulo, o no existente en otra tabla (falta de integridad referencial entre los datos). Si hubiese otras medidas adems de cantidades, debieran controlarse al menos que los totales de los valores coincidan. Cada dimensin. Puede ocurrir que falten valores en las tablas de dimensiones o existan cdigos no adecuados en las tablas de hechos. Estos casos podrn visualizarse al desplegar los valores de las dimensiones utilizando la interfaz de acceso al cubo. Tambin debe controlarse que las dimensiones contengan los valores adecuados, y descartar as posibles errores en la definicin del modelo: al asociar los campos, las claves, las descripciones, definir niveles nicos, etc. Suele ocurrir que valores diferentes coinciden en la descripcin y entonces es necesario utilizar tambin el cdigo para diferenciar estos casos.

Controles en los procesos de extraccin y transformacin 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 intencin explcita de hacerlo y testear cuidadosamente la lgica utilizada para la extraccin. De todas formas es conveniente chequear las cantidades del cubo con reportes y otras consultas provenientes del/los sistemas de gestin correspondiente. Si existiese un rea de transformacin de datos sera 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 transformacin 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 gestin. En este caso si el SIU-Guaran se usa correctamente y con los controles necesarios activados no existirn estos problemas en la base de datos. Sin embargo en muchas ocasiones se descubren datos inconsistentes y/o falta de informacin en el sistema de gestin. 94

Captulo 5 Presentacin de la solucin

Estas situaciones se deben generalmente a procesos de migracin de informacin de otro sistema que se incorpora al SIU-Guaran con controles desactivados o en forma incompleta. Tambin existe informacin 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 ms tarde a partir de la observacin 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 podra ocurrir es alumnos que tuviesen actividad acadmica anterior al ao de ingreso37. Todos estos casos son ejemplos de la retroalimentacin que generan las soluciones para anlisis de datos en los sistemas operacionales. Debieran ser corregidos en el sistema operativo de origen y luego regenerar el cubo con la informacin correcta.

37

En este trabajo estos casos se descartan antes, directamente no se los extrae de la fuente de datos.

95

Captulo 6 Uso de la herramienta y anlisis de datos

Uso de la herramienta y anlisis 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 ubicacin correspondiente) o publicarse en el servidor de O3 y accederse a travs de las interfaces que se hayan instalado (escritorio o web) y con los permisos que pudiesen haberse configurado39. Este captulo tiene el propsito de mostrar la funcionalidad bsica de la herramienta y algunos ejemplos de las amplias posibilidades de anlisis brindadas por el cubo diseado. 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 SIU-Guaran.

6.1

Acceso al cubo y operaciones bsicas

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 Acadmica y Ao Ingreso (en el nivel Ao 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.
38 39

En la seccin 8.4 del apndice se explica cmo generar el cubo. En los ejemplos de este trabajo se accede con la interfaz de escritorio de forma local.

96

Captulo 6 Uso de la herramienta y anlisis de datos

Existen datos con problemas de calidad, no debieran existir casos con ao 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 ningn 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 botn de acceso rpido. 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 grfico, frmulas calculadas, muchas dimensiones y medidas. A partir de ellas tambin es posible navegar el cubo, pudiendo retornar al punto de partida con la opcin de vista inicial.

Operaciones bsicas de consulta

Las operaciones ms comunes y sencillas sobre los datos consisten en: reemplazar o agregar dimensiones a una consulta, seleccionar diferentes medidas, realizar filtros y desagregar informacin. Seleccin de dimensiones La seleccin se realiza arrastrando la dimensin deseada al grfico, superponindola con la que se quiere reemplazar. Cuando esta operacin se realiza en el modo grfico la dimensin a ser reemplazada se colorea de amarillo en el momento en que se debe soltar el arrastre del ratn.

Figura 32. Ejemplo de reemplazar la dimensin Unidad Acadmica por Sexo en la consulta, para obtener Cant Personas por Ao de Ingreso (a la Universidad) y Sexo.

97

Captulo 6 Uso de la herramienta y anlisis de datos

Al trabajar en el modo grilla la dimensin a reemplazar se colorea de gris. En este caso es posible no slo reemplazar dimensiones existentes en una consulta sino tambin agregar, creando as tablas con ms de una variable en las filas y/o en las columnas. El lugar donde se insertar la dimensin que se incorpora a la consulta es sealado con una barra amarilla. Es posible cambiar el orden de presentacin arrastrando las dimensiones dentro de la tabla. Para pasar del modo grfico a grilla usar la opcin Desplegar tabla del men Ver, o el botn de acceso directo.

Figura 33. Ejemplo de consulta en formato de tabla utilizando muchas dimensiones.

Seleccin de medidas Es posible cambiar cualquier medida simplemente desplegando el listado correspondiente y eligiendo la deseada. Tambin pueden utilizarse las medidas dentro de la visualizacin de la consulta, como si fuesen los valores de una dimensin. Esta opcin generalmente se utiliza para comparar medidas. En las figuras 34 y 35 pueden apreciarse ejemplos en modo grfico y grilla respectivamente.

98

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 34. Comparacin de Cant Personas vs. Cant Alumnos abierto por Sexo.

Figura 35. Comparacin de medidas Cant Personas y Cant Alumnos, discriminadas por Ao de Ingreso (a la universidad) y Sexo. Visualizacin en formato de grilla.

Desagregar informacin y filtrar Se puede acceder a un nivel de informacin desagregado haciendo clic sobre el valor deseado, o seleccionndolo de la lista desplegable de la dimensin (siempre que forme parte de la consulta y se utilice la opcin por defecto Explorar hijos).

99

Captulo 6 Uso de la herramienta y anlisis de datos

Si el nivel consultado es el ltimo, el ms detallado, dentro de la jerarqua de la dimensin, la operacin de desagregacin no muestra nuevos valores, sino que acta como un filtro sobre la consulta anterior, dejando visible slo el valor elegido.

Figura 36. Izquierda: filtro a partir de figura 35, seleccionando el valor Mujeres en Sexo. Grficos restantes: drill down sobre valores de la dimensin Procedencia, eligiendo pas Argentina y luego provincia San Juan.

Los filtros tambin pueden realizarse sobre valores de dimensiones que no estn siendo visualizadas en la consulta corriente. Los filtros que se efecten modificarn los resultados actuales. No hay que perderlos de vista al momento de interpretar los valores mostrados en las consultas para evitar confusiones. Tambin es posible seleccionar ms de un valor de las dimensiones eligiendo la opcin de lista de elementos. Y se puede consultar el desgranamiento de ms de un valor al mismo tiempo, lo que significara un mltiple 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 aos de ingreso 2000 a 2007. Derecha: Drill down de ms de un elemento utilizando la exploracin por niveles (opcin: expandir hijos)

100

Captulo 6 Uso de la herramienta y anlisis de datos

Para volver al nivel anterior (drill up) hay que seleccionar el valor correspondiente en la dimensin (el padre, un nivel ms arriba), asegurndose de tener la opcin de visualizacin por defecto (explorar hijos, no lista de elementos). La opcin atrs es tambin til muchas veces para retornar a consultas anteriores.

6.2

Un ejemplo de anlisis sobre evolucin de la matrcula

Una de las temticas a abordar con la informacin contenida en el caso prctico es la

evolucin de la matrcula. En esta seccin se muestra como analizar las variaciones sobre la cantidad de alumnos en los ltimos diez aos. Se comienza con una consulta general y se va profundizando en sub-consultas sobre los casos ms llamativos. El ejemplo es a modo de gua, pudindose retomar consultas intermedias y seguir analizando sobre otras alternativas. En toda la seccin 6.2 se consideran slo las personas inscriptas en una nica carrera para simplificar la interpretacin de los grficos 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 ao acadmico

Para comenzar se evala la cantidad de alumnos por cada ao acadmico41. Partiendo de la vista inicial del cubo seleccionar la medida de cantidad de alumnos por ao acadmico (Cant Alum X Ao c/Activ) y arrastrarla al grfico en el eje X, en lugar de Unidad Acadmica. Luego reemplazar la dimensin Ao de Ingreso por Ao Informado y seleccionar los aos acadmicos que resulten de inters, por ejemplo los ltimos diez.

40

Al filtrar a las personas inscriptas slo en una carrera coinciden la cantidad de alumnos con la cantidad de personas, el ao de ingreso a la carrera con el ao de ingreso a la universidad y todos los datos agregados de totales de materias y dems. 41 Se cuentan slo a los alumnos que presentan algn tipo de actividad, considerando como actividad el hecho de realizar una inscripcin (sea a cursado, examen o carrera).

101

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 38. Cantidad de alumnos por ao acadmico en que presentan actividad, para los aos 1997-2006.

En el grfico de la figura 38 se puede observar que el crecimiento ms importante en la matrcula ocurre en el ao 2000. Tambin se ve claramente un descenso importante en el ao 2006, el ltimo ao considerado para este cubo. Es muy importante que el analista de informacin tenga en cuenta el contexto de los datos. En este caso ocurre que la informacin correspondiente al ltimo ao no est completa, y ese es el motivo que explica la diferencia. Posiblemente lo ms conveniente sea descartar este ao al hacer anlisis comparativos. Tambin al generar el cubo habr que considerar si el ltimo ao acadmico ya est cerrado o no. Otra caracterstica importante a tener en cuenta refiere a la migracin de datos. Puede ser que la poltica de migracin de datos al SIU-Guaran 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 informacin y en el rendimiento de los alumnos. Retomando el ejemplo del grfico, se podra sospechar que la matrcula del ao 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 hiptesis en la figura siguiente se muestra la apertura de los alumnos segn el ao de ingreso a la carrera y se calcula el porcentaje que representan los ingresantes sobre la totalidad de alumnos de cada ao acadmico.

Figura 39. Apertura de cantidad de alumnos por ao con actividad segn ao de ingreso a la carrera.

102

Captulo 6 Uso de la herramienta y anlisis de datos

Porcentaje correspondiente a los ingresantes sobre el total de alumnos de cada ao acadmico. En la grfica se observan dos ventanas con la misma vista para mostrar parte de los aos 1997-2000.

En la figura 39 para cada ao acadmico de la dimensin Ao 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 ao 2000, mientras que en el resto de los aos se mantiene alrededor de un 20%. La frmula utilizada para el clculo del porcentaje42 respeta la sintaxis requerida por la herramienta y consiste en sumar los valores de ao de ingreso a la carrera coincidentes con el ao informado y calcular el porcentaje sobre el total, para cada ao acadmico. Por lo tanto en este caso se valida la hiptesis de que el incremento en la cantidad de alumnos en el ao 2000 se debe a un aumento en la cantidad de ingresantes (y no de reinscriptos). Otra forma de visualizar esta informacin puede ser mediante la consulta de la figura siguiente, donde se permite ver el cruce de todos los aos de forma ms compacta, facilitando la comparacin.

Figura 40. Porcentaje de cada cohorte sobre el total de alumnos de cada ao acadmico. El grfico se obtiene colocando la dimensin ao de ingreso como columna y utilizando la opcin desplegar porcentajes por fila en lugar de utilizar una funcin 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 aos siguientes, en comparacin con las restantes.

Anlisis de ingresantes
Ahora se podra continuar el anlisis haciendo hincapi en los ingresantes y prestando especial atencin a la cohorte 2000.

42

@Sum_i((Etiqueta([this.leaf(i)],"Ao Informado") == Etiqueta([this.leaf(i)],"Ao Ingreso"))? [this.leaf(i)] : 0)*100 /["Total"]

103

Captulo 6 Uso de la herramienta y anlisis de datos

Sobre la vista inicial del cubo elegir la medida Cant Alumnos, y seleccionar para la dimensin Ao Ingreso los valores que interese evaluar, por ejemplo de 1996 a 2006. Si hubiese ms de una facultad se podra seleccionar una. Siempre es importante seleccionar la medida adecuada para evitar confusiones posibles y cruces de variables no vlidos. En las grficas siguientes se utiliza la medida Cant Alumnos, que es diferente a la de las figuras anteriores, Cant Alum x Ao c/Activ, donde se reflejaba la relacin muchos a muchos entre alumnos y aos acadmicos en que tienen actividad. En la grfica de la figura 41 se observa que hubo un pico de ingresantes en el ao 2000 superando por ms del doble a los aos precedentes. La cantidad de alumnos que ingresaron a las diferentes carreras cay notoriamente en los aos siguientes. Se observa que del ao 2000 en adelante fue disminuyendo, presentando un descenso importante en el ao 2005.

Figura 41. Evolucin de ingresantes en los ltimos 11 aos para la facultad 1. Para el grfico se usaron las opciones de lista de elementos para filtrar los valores de la dimensin Ao Ingreso, intercambiar ejes y mostrar valores43.

Se puede hacer la apertura por carrera dentro de esa facultad intentando explicar las subas y bajas. Es necesario reemplazar la dimensin Unidad Acadmica por Carrera. La grfica se muestra en modo tabla en la figura siguiente.

43

Los aos se muestran en el orden en que se los tilda, que se puede cambiar.

104

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 42. Comparacin 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. Tambin se observa que en el ao 2000 se abri la inscripcin a la carrera 08 (anteriormente no tiene ingresantes) lo que en principio justifica el pico de ingresos en ese ao. En la figura 43 se muestra el grfico de barras comparativo de las tres carreras con mayor cantidad de ingresantes en cada ao.

Figura 43. Evolucin de ingresantes de las carreras 07, 08 y 09.

105

Captulo 6 Uso de la herramienta y anlisis de datos

Se podra corroborar que el incremento de ingresantes en el ao 2000 se debe al comienzo de la carrera 08 seleccionando dicha carrera y consultando tambin el ao de egreso del secundario de los ingresantes. Luego, calcular el porcentaje de alumnos correspondiente a cada ao de egreso del secundario sobre el total de la cohorte, definiendo una frmula como la mostrada en la figura 44.

Figura 44. Ingresantes a la carrera 08 segn ao de egreso del secundario, y frmula de porcentaje sobre total de alumnos de la cohorte.

Observando los diferentes aos (figura 45) se puede ver que en general alrededor del 40% de los ingresantes de cada cohorte finalizan el secundario el ao anterior al que comienzan la carrera universitaria. En el ao 2000 los porcentajes son muy diferentes, la cantidad de alumnos que terminaron el secundario en el ao 1998 es equivalente a aquellos que lo hicieron en 1999, mientras que para los dems aos la relacin suele ser equivalente a la mitad.

106

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 45. Anlisis de ingresantes por cohorte y ao de egreso del secundario para la carrera 08 y los aos 2005, 2004, 2001 y 2000.

Seguimiento de una cohorte

Puede resultar interesante seleccionar esa cohorte (ao de ingreso = 2000) y analizar qu sucedi con esos ingresantes, particularmente evaluar y comparar a quienes egresaron del secundario en 1998 y 1999. Se podra tener por ejemplo la sospecha que quienes esperaron un ao para poder ingresar a la carrera estaran ms seguros y entusiasmados en su decisin de estudiar; su rendimiento acadmico y su perseverancia podra superar a los ingresantes recin salidos del secundario. Una posible consulta a realizar es la apertura de estos alumnos segn el ltimo ao en que registran actividad (inscripcin a cursado o examen en alguna materia de la carrera) y segn si han egresado o no (usando la dimensin cantidad de carreras egresado). El grfico de la figura 46 se obtiene seleccionando el valor 2000 en ao de ingreso, 1998 y 1999 en ao de egreso del secundario (usando la opcin de listas de elementos), cambiando la ubicacin de la dimensin ao de egreso del secundario, para facilitar la comparacin, y arrojando al grfico las dimensiones ltimo ao con actividad y cant carreras egresado.

107

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 46. Ingresantes a la carrera 08 de la cohorte 2000. Comparacin de alumnos que terminaron el secundario en 1998 vs. quienes lo hicieron en 1999, segn ltimo ao de actividad en la carrera y si egresaron o no.

Los casos que presentan ltimo ao con actividad en cero es porque nunca tuvieron actividad en la carrera. Egresado hay slo un caso; se puede quitar ese nivel de detalle porque no aporta informacin significativa. Tambin es interesante ver los porcentajes en lugar de los nmeros (figura 47. Utilizar la opcin 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 informacin puede visualizarse tambin de modo grfico. Para lograr mayor legibilidad en la lectura es conveniente quitar las dimensiones que estn mostrando un nico valor

108

Captulo 6 Uso de la herramienta y anlisis de datos

en el resultado (en este caso ao de ingreso y carrera) y tambin la fila totalizadora. En las figuras 48 y 49 se aprecian diferentes visualizaciones de la misma consulta.

Figura 48. Comparacin en modo grfico de ingresantes a la carrera 08 en el ao 2000 segn si egresaron del secundario en 1998 o 1999. Apertura segn ltimo ao con actividad. Vista de porcentajes sobre valores del eje X.

Figura 49. Diferentes visualizaciones grficas sobre la consulta de la figura 48. En el caso de los grficos de torta se observa sobre la parte inferior del lateral derecho la dimensin que en la tabla apareca como columna.

De las figuras anteriores se puede concluir que la hiptesis planteada para estos casos sobre la influencia del ao de egreso del secundario en la perseverancia en la carrera no sera cierta, ya que en general quienes ingresaron en 1999 tienen actividad durante ms tiempo. 109

Captulo 6 Uso de la herramienta y anlisis de datos

De todas formas para realizar un anlisis ms profundo habra que evaluar la calidad de la actividad tenida. Tambin 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 comparacin entre los ingresantes del ao 2000 a la carrera 08 que egresaron del secundario en los aos 1998 y 1999 segn algunas variables totalizadoras de rendimiento acadmico. En el ejemplo se observa que en general quienes egresaron del secundario en 1999 tienen mejor desempeo acadmico.

Figura 50. Ingresantes a la carrera 08 de la cohorte 2000. Comparacin de alumnos que egresaron del secundario en el ao 1998 y 1999 segn totalizadores de cantidad de finales aprobados, cantidad de cursados aprobados y cantidad de cursados promovidos.

6.3

Ejemplos de anlisis de procedencia

Otra temtica 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 pas. En general interesa llegar al mximo detalle para encontrar la articulacin entre los diferentes colegios secundarios y las carreras de la universidad.

110

Captulo 6 Uso de la herramienta y anlisis de datos

En esta seccin se muestran algunos ejemplos interesantes y otras consultas ms generales, que se utilizan para explicar funcionalidades de la herramienta y como gua para la obtencin de otras nuevas.

Anlisis a nivel de pas y calidad de datos

En la figura 51 se observa el anlisis de procedencia a nivel de pas, para las cohortes 2000-2005, evaluando cantidad de personas y cantidad de alumnos. Para obtener el grfico, partiendo de la vista inicial del cubo, es necesario: pasar al modo grilla, arrastrar las medidas al grfico reemplazando la dimensin Unidad Acadmica, seleccionar la medida Cant Alumnos (adems de la ya elegida por defecto), seleccionar los aos de ingresos deseados, arrojar la dimensin Procedencia como parte de las filas y agregar los totales por ao.

Figura 51. Anlisis de procedencia a nivel pas para las cohortes 2000-2005 (considerando ao de ingreso a la universidad, que es el nivel comparable por ambas medidas), comparando cantidad de personas con cantidad de alumnos.

La evaluacin 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

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 52.Visualizacin diferente de la informacin de la figura 51 cambiando la ubicacin de las dimensiones y usando porcentajes por fila para resaltar la falta de completitud de los datos.

Exploracin de los niveles de la dimensin procedencia

Al seleccionar un valor de pas (por ejemplo haciendo clic sobre Argentina) se visualiza el nivel siguiente en la jerarqua. Los valores de la dimensin conforman un rbol con diferentes niveles. Se pueden consultar por ramas o por nivel, de a uno o ms elementos.

Figura 53. Anlisis de procedencia para pas Argentina de las cohortes 2000-2005. Apertura de provincias y localidades.

112

Captulo 6 Uso de la herramienta y anlisis de datos

En la figura 53 se observan los valores de los niveles provincia y localidad correspondientes al pas Argentina. La forma utilizada (Expandir todos los hijos sobre el nivel provincia) permite ver los subtotales por provincia. Los datos utilizados en el caso prctico no tienen variaciones importantes en cuanto a provincia de procedencia. El anlisis por colegio secundario tambin es posible, a travs de la opcin de visualizar todo ese nivel (se visualizan todos los colegios de todas las localidades de todas las provincias y pases), o eligiendo una localidad. La figura 54 surge de seleccionar una localidad en la consulta anterior, pasar la dimensin Ao Ingreso a las columnas y agregar totalizadores.

Figura 54. Procedencia de personas y alumnos de las cohortes 2000 a 2005. 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 descripcin de los colegios. Este es un problema menor de calidad de datos que habra que resolver, modificando las descripciones en el sistema SIU-Guaran.

Articulacin de colegios y carreras

Es interesante conocer la relacin 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 dimensin Carrera como parte de la consulta. Esto se muestra en la figura 55.

113

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 55. Apertura por carrera de alumnos correspondientes a las cohortes 2000-2005 procedentes de los diferentes colegios secundarios de la localidad de SAN JUAN.

Este mismo anlisis podra realizarse para todos los colegios de una provincia, por ejemplo, usando las diferentes opciones avanzadas de exploracin de la dimensin Procedencia. Tambin es posible tomar a la carrera como el punto de partida para el anlisis, 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 ao 2005 a la carrera 10.

Figura 56. Procedencia de ingresantes 2005 a la carrera 10. Ranking de colegios secundarios.

114

Captulo 6 Uso de la herramienta y anlisis de datos

Para obtener el grfico de la figura 56 se debe seleccionar la medida Cant Alumnos, la carrera y el ao de ingreso. Respecto a la dimensin Procedencia se debe elegir la opcin 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 opcin Ranking dentro del men Explorar y elegir de ordenar la dimensin Procedencia por criterio descendente segn la medida corriente. Aperturas por las otras dimensiones tambin estn permitidas. Sexo, Edad, Cant carreras inscripto-activo y todas las dimensiones referentes al rendimiento acadmico de esos alumnos pueden resultar interesantes. La figura 57 muestra un cuadro que podra obtenerse combinando totales de cursados promovidos y finales aprobados. Se utiliza una regla para sealizar los valores diferentes a cero, para facilitar el anlisis44.

Figura 57. Posible anlisis de rendimiento acadmico 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 ms alto. Se visualiza slo el nivel Colegio en la dimensin Procedencia y se utiliza la opcin de desplegar porcentajes por fila.

Anlisis similares pueden realizarse eligiendo algn colegio y consultando en qu carreras influye, comparando la procedencia en los diferentes aos, etc. Tambin es posible comparar el rendimiento acadmico de los alumnos, principalmente durante el primer ao de la carrera y relacionarlo con el colegio del que provienen. Puede ser que determinados colegios con formacin ms afn respecto a la carrera tengan una influencia positiva en el rendimiento acadmico de los alumnos, o que no resulte lo esperado.

44

La definicin de reglas con O3 queda fuera del alcance de esta tesis. Consultar la documentacin de la herramienta.

115

Captulo 6 Uso de la herramienta y anlisis de datos

6.4

Un ejemplo de desgranamiento basado en la actividad acadmica y rendimiento

El desgranamiento generalmente es evaluado por cohortes. Este anlisis comienza a partir

de los individuos, el ao de ingreso a la universidad y se realiza un seguimiento de los aos en que han tenido actividad. En este caso se inicia la exploracin a nivel de personas y no a nivel de alumno. Luego se desgrana la informacin por alumno.

ltimo ao con actividad

El cuadro de la figura 58 muestra el ao de ingreso y el ltimo ao con actividad para la medida Cant Personas. Se puede observar que hay una cantidad importante de inscriptos que no tienen actividad acadmica en ningn ao, reflejados por ltimo ao con actividad igual a cero.

Figura 58. Cantidad de personas por ao de ingreso, discriminados segn el ltimo ao de actividad. Los subtotales muestran la cantidad de personas que ingresaron a la universidad en cada ao.

La misma informacin puede visualizarse de otra manera en la figura siguiente, en cantidades absolutas y tambin en porcentajes sobre el total de cada cohorte45.

45

Se utiliza el trmino cohorte para referirse al ao de ingreso, a la universidad, o a la carrera. Aunque en general el uso ms comn es el segundo ambos son aceptables. Adems, la mayora de las personas se inscriben slo a una carrera, por lo tanto los valores suelen ser coincidentes.

116

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 59. Cantidad de personas por ao de ingreso y ao de ltima actividad, en cantidades absolutas y en porcentajes sobre el total de la cohorte.

Personas y alumnos
La relacin entre Cant Personas y Cant Alumnos depende de la cantidad de carreras en que se haya inscripto cada individuo. As quienes se anotan slo en una cuentan una vez como persona y una vez como alumno. En estos casos, el ao de ingreso a la universidad coincide con el ao de ingreso a la carrera, y tambin coinciden los totalizadores de rendimiento acadmico. Mientras que quienes se hayan inscripto en ms de una carrera presentan diferencias segn el nivel en que se analice la informacin. En este trabajo la actividad anual se calcula slo a nivel de alumno (medida Cant Alum X Ao c/Activ), por eso es necesario evaluar la relacin entre personas y alumnos como paso intermedio al intentar evaluar el rendimiento anual. En la figura 60 se puede observar la relacin entre personas y alumnos a partir de la cantidad de carreras en que se inscriben, y las diferencias al considerar el ao de ingreso a la universidad y el ao de ingreso a la carrera.

117

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 60. Comparacin de Cant Personas y Cant Alumnos. Apertura por Cant carreras inscripto y Ao de Ingreso, a la universidad y a la carrera.

Cuadros similares a los de la seccin 6.4.1 podran armarse eligiendo cantidad de alumnos por ultimo ao de actividad en la universidad y tambin por ltimo ao de actividad en la carrera. En la figura 61 se muestra la apertura de ambas medidas segn el ao de ingreso a la universidad y el ltimo ao con actividad en esta.

Figura 61. Cant Personas y Cant Alumnos segn Ao Ingreso a la universidad y

118

Captulo 6 Uso de la herramienta y anlisis de datos

ltimo ao con actividad en la universidad

Actividad anual de las cohortes

Adems de la apertura por ltimo ao con actividad es interesante evaluar la actividad en cada ao. Eso es posible consultando la cantidad de alumnos por ao acadmico en que realizan alguna actividad y comparando el valor con la cantidad de alumnos. Para esto es necesario utilizar la medida Cant Alum X Ao c/Activ que cuenta a cada alumno tantas veces como aos en los cuales realiza alguna actividad acadmica, y realizar la apertura por la dimensin Ao Informado. Los valores mostrados en la figura 62 deben ser analizados en funcin 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 ao 2001 (fila 9 de la figura 61), 10 de ellos tuvieron actividad acadmica en 1994, 1995, 1996 y 2001, equivalentes al primer, segundo, tercer y octavo ao de las carreras, respectivamente. 9 de ellos tuvieron actividad durante los aos 1997, 1998 y 1999, y slo 7 tuvieron actividad en el ao 2000 (filas 3 a 10 del cuadro de la derecha de la figura 62).

Figura 62. Alumnos por ao acadmico en que presentan actividad. Apertura por ao de ingreso a la universidad y ltimo ao 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 ao acadmico. La figura 63 se logra a partir de la anterior, quitando la dimensin ltimo ao con actividad y filtrando algunos valores de Ao Informado para obtener un grfico ms simple. La medida Cant Alumnos est indefinida por Ao Informado, por eso muestra siempre el total de alumnos de cada ao de ingreso46.
46

Es intencional y es la forma que presenta O3 para permitir la comparacin de estas medidas por Ao Informado. Hay otras formas de obtener el dato del porcentaje a partir de otras vistas que requieren frmulas de clculo o diseo del modelo ms complejos.

119

Captulo 6 Uso de la herramienta y anlisis 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 inters, por ejemplo la cohorte 1997 que al ao 2006 lleva 10 aos dentro de la universidad y tiene un total de 380 ingresantes (observar en figura 60, total de Cant Alumnos con ao 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 ao acadmico.
47

Se considera como cohorte al ao de ingreso a la universidad para que los ejemplos sean ms sencillos. Tambin podra tomarse el ao de ingreso a la carrera. Incluso si resultara complejo seleccionar los valores podra modelarse el ao de ingreso a la carrera como una dimensin independiente.

120

Captulo 6 Uso de la herramienta y anlisis de datos

La actividad anual de los 380 ingresantes puede verse en el grfico de la figura 64. Es muy interesante observar como en este caso se va perdiendo la cantidad de alumnos a medida que pasan los aos. 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 segn el ltimo ao en que realizan actividad acadmica 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 ao 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 segn ltimo ao 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

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 66. Cantidad de alumnos y de personas que ingresaron en 1997 discriminadas por ltimo ao en que registran actividad (en la universidad solamente para simplicidad del grfico), 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 slo a una carrera (corresponden a 8 alumnos) y no estn activos, todos ellos son egresados (observar la primera columna para Cant Alumnos y para Cant Personas). La mayora de los casos estn inscriptos, activos y no egresados en slo 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 ms detalles de este caso). Para los casos restantes, que estn activos e inscriptos en ms de una carrera (2/2 y 3/3), en la grilla slo se muestran los aos de ingreso a las carreras, sera interesante realizar la apertura por carrera y por ltimo ao de actividad en la carrera para continuar la evaluacin. 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 segn ao acadmico 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

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 68. Comparacin de alumnos con actividad por ao, alumnos y personas correspondientes al ao de ingreso a la universidad 1997, segn 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 vlido 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 anlisis. Por ejemplo, si focalizamos sobre quienes egresaron en alguna carrera podemos obtener el cuadro de la figura 69 donde se observan ms detalles sobre su condicin de alumnos (ao de ingreso a la carrera, ltimo ao 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 slo egres en una de ellas. Este individuo comienza la carrera 07 en 1997 y la deja ese mismo ao, y en el 2000 comienza la carrera 08, en la que tuvo actividad por ltima vez en el ao 2005, lo que indicara que es la carrera en la que egres. Los otros casos estaran egresando en 2005 y 2006 (que es cuando registran actividad por ltima vez) en sus respectivas carreras. Si se deseara hacer un anlisis ms profundo sobre los egresados habra que utilizar algunas otras variables no incluidas en el Data Mart. Respecto a los alumnos activos en ms de una carrera, observando en detalle la parte derecha de figura 68 se puede concluir que, para esta cohorte, no es muy comn el comienzo de dos carreras en paralelo: de las 40 personas en cuestin (total de inscriptos en 2 y 3 carreras 1+37+2 en cuadro inferior derecho-) slo 4 comienzan dos carreras en simultneo (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 despus, sea de grado o postgrado (observar los valores de ao de ingreso a carrera para estos casos). 123

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 69. Anlisis de los alumnos que ingresaron a la universidad en 1997 y egresaron en alguna carrera.

Seguimiento de subconjunto mayoritario de una cohorte. Anlisis por carrera y rendimiento

Los casos de egresados y simultaneidad de carreras vistos recientemente podran ser descartados del anlisis, ya que no representan a la mayora de los casos. Se opta por elegir los alumnos que estn inscriptos y activos slo en una carrera y que an no han egresado para continuar el desgranamiento segn el rendimiento acadmico. Sobre esos casos pretende realizar un anlisis comparativo por carrera. Tambin se descarta a los alumnos de carreras de postgrado porque, adems de ser pocos casos, son muy particulares y la evaluacin de desgranamiento sera diferente.

Figura 70. Alumnos de la cohorte 1997 activos en slo una carrera y no egresados. Cantidad total (grfico inferior derecho) y cantidad discriminada por ao en que tienen actividad acadmica. Slo se consideran las carreras de grado.

El mismo anlisis puede hacerse seleccionando ms de una cohorte. En la figura siguiente se muestran, adems de la cohorte 1997, la anterior y la siguiente para realizar la comparacin.

124

Captulo 6 Uso de la herramienta y anlisis de datos

Figura 71. Cuadro principal: actividad anual de las cohortes 1996-1998, considerando alumnos inscriptos y activos en una carrera y no egresados para carreras de grado. Derecha: total de alumnos de las cohortes 1996-1998 con las mismas restricciones.

A partir de estos cuadros se pueden hacer anlisis ms intensivos para profundizar en el desgranamiento, por ejemplo utilizando variables de rendimiento acadmico como la cantidad de cursados o finales aprobados. En la figura 72 se aprecia la apertura de estos alumnos segn el total de cursados aprobados en la carrera.

Figura 72. Alumnos de carreras de grado de las cohortes 1996-1998 inscriptos y activos en una carrera y no egresados, segn total de cursados aprobados en la carrera.

125

Captulo 6 Uso de la herramienta y anlisis de datos

En la figura 73 se ve el detalle de cursados aprobados por ao acadmico de un subconjunto de estos alumnos. Para el grfico 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 ao en que los alumnos tienen actividad.

Figura 73. Detalle de cursados aprobados por ao acadmico y total de cursados aprobados en la carrera de los alumnos de la cohorte 1997 activos slo en carrera 1048.

El anlisis completo debiera contemplar varias de estas dimensiones y utilizarlas en forma combinada, calculando por ejemplo el total de cursados regularizados (cursados aprobados ms cursados promovidos) o el total de materias aprobadas (finales aprobados ms cursados promovidos). La intencin de estos ejemplos es presentar la potencialidad de la solucin. Se deja en manos del lector la exploracin de las posibles consultas, y frmulas que puedan obtenerse y agregarse segn 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 nmeros pequeos.

126

Captulo 7 - Conclusiones y trabajo futuro

7
7.1

Conclusiones y trabajo futuro

Conclusiones
La implementacin de soluciones para analizar informacin como la presentada en este

trabajo genera muchos beneficios. Entre los ms importantes se destacan los siguientes: El acceso a los datos es fcil y rpido y permite a los usuarios hacer sus propias consultas. Tambin se logra independencia del personal tcnico para la obtencin de nuevos reportes. La informacin se obtiene de manera sencilla y a travs de imgenes integradas de los datos. Facilita el proceso de comparacin, proyeccin a futuro, relacin con otros datos, muestra de indicadores, informacin consolidada, etc. Ayuda a mejorar el buen funcionamiento de los sistemas de gestin retroalimentando demandas para estos. Lograr la implementacin y el uso real de los sistemas para el soporte de decisiones no es una tarea sencilla y generalmente requiere enfrentar varios problemas. La mayora de los problemas surgen en cualquier proyecto de Data Warehousing, otros son propios de la realidad del mbito universitario o de la administracin pblica. Algunos de los ms frecuentes son: Infravaloracin del esfuerzo necesario para el diseo y la creacin de un DW. Infravaloracin de los recursos necesarios para la extraccin, transformacin, carga y almacenamiento de los datos. Incremento continuo de los requisitos de los usuarios una vez que las soluciones son implementadas exitosamente. Privacidad de los datos. Calidad de los datos. Los datos deben ser confiables, y estar disponibles y completos, para que puedan ser utilizados. Carencia de RRHH involucrados en el proyecto que colaboren en la puesta en marcha. Se requiere: Una autoridad o usuario sponsor que empuje internamente el proyecto de DW y designe un equipo de trabajo. Usuarios capacitados en las herramientas que utilicen las soluciones y demanden nuevas consultas promoviendo su uso y evolucin. Recursos humanos que puedan mantener y hacer evolucionar todo el sistema para anlisis de informacin. 127

Captulo 7 - Conclusiones y trabajo futuro

Apoyo tcnico del rea de sistemas.

Existencia o adquisicin del hardware necesario. La incorporacin de este tipo de soluciones dentro del mbito universitario ha permitido:

Mostrar el potencial de estas herramientas y de los datos producidos por los sistemas de gestin.

Impulsar el uso de la informacin como una herramienta para la toma de decisiones y la planificacin.

Profundizar el trabajo sobre la calidad de los datos en su origen, que es la clave del xito de un proyecto de DW.

Construir los cimientos de un profundo cambio cultural. En sntesis y como conclusin del presente trabajo se puede decir que estas herramientas

convierten datos crudos en informacin valiosa y ayudan a los directivos a tomar decisiones. Permiten lograr una visin ms completa e integral de la organizacin, entender los eventos en forma sistemtica, para as redefinir estrategias. El resultado de su implementacin es conocimiento acerca del funcionamiento de la organizacin.

7.2

Trabajo futuro
Son muchas las cosas por hacer an, desde lo tcnico hasta la promocin y motivacin

para lograr el uso real en la toma de decisiones, pasando por la definicin de criterios sobre consideraciones de los datos. Desde el punto de vista tcnico y funcional, se podran incorporar modificaciones a las soluciones actuales o desarrollar nuevos componentes dentro de la totalidad del sistema para anlisis de informacin. Las siguientes son algunas de las posibles modificaciones a considerar: Modelar algunos datos de forma diferente en el cubo propuesto para permitir la obtencin de otros reportes. Ejemplos: Se podran incorporar como medidas a las actuales dimensiones de rendimiento acadmico (cursados aprobados, cursados desaprobados, etc.). De esta forma se permitira fcilmente totalizar las materias regularizadas (cursados aprobados ms cursados promovidos) y las materias aprobadas (cursados promovidos ms finales aprobados). Definir niveles de actividad para combinar los valores de las dimensiones finales aprobados, finales desaprobados, cursados aprobados, etc. en una o ms dimensiones sintetizadoras. Esta es una tarea compleja en algunos casos porque puede depender mucho de la carrera que se analice y su plan de estudio. 128

Captulo 7 - Conclusiones y trabajo futuro

Separar alguna de las dimensiones actuales (por ejemplo cohorte) si es conveniente para los usuarios.

Incorporar nuevos datos o niveles ms detallados de datos existentes. Ejemplos: Agregar al modelo algunas de las dimensiones que forman parte de los archivos de texto, por ejemplo: duracin del plan, calidad del alumno, promedio, etc. Incluir el dato de materia en relacin con el alumno para poder detectar en que materias se presentan los mayores problemas de desaprobacin de determinado conjunto de alumnos. Incorporar mayor cantidad de datos sobre egresados. Incluir informacin del contexto socio econmico de los alumnos. Esto requiere que los datos respectivos (condicin laboral del alumno, estudios de los padres, composicin del grupo familiar, situacin econmica del grupo familiar, etc.) estn completos y sean de buena calidad. Por otro lado se requiere definir la forma de unirlos con la informacin acadmica (establecer una correspondencia entre las diferentes fechas en que los datos censales son relevados y los perodos del ao acadmico donde debieran ser considerados). Incorporacin de datos derivados como movilidad, simultaneidad de carreras y lentificacin, previa definicin de estos. La informacin existente en los cubos actuales podra ser de utilidad para definir alguno de estos indicadores.

Desarrollar modelos de anlisis sobre nuevas temticas. Por ejemplo incorporacin de materias por crditos o puntos que aportan, y posicionamiento de los alumnos en el plan de estudio.

Crear un DW en la universidad con la informacin proveniente del SIU-Guaran. El DW debera contener la informacin explotada en los cubos actuales y datos adicionales, de mayor nivel de detalle, para cubrir actuales y futuras necesidades. La estructura de las tablas del DW debe pensarse de forma que responda eficientemente a estos requerimientos. A dicho DW podran incorporarse tambin datos provenientes de otros sistemas de gestin, incluyendo temticas tales como becas, presupuesto o recursos humanos. De esta forma sera posible obtener indicadores que relacionen por ejemplo el rendimiento acadmico de los alumnos que obtienen becas, o de los alumnos que trabajan como ayudantes de ctedra en la universidad, entre otras cosas.

Toda la solucin podra implementarse con herramientas de software libre. Al momento de comenzar el trabajo en esta tesis no haba herramientas de software libre con la madurez de desarrollo ni la difusin actual. Adems en la UNS y en aproximadamente en otras quince Universidades Nacionales ya se estaba utilizando O3.

129

Captulo 7 - Conclusiones y trabajo futuro

Se espera que este trabajo sea un aporte para el anlisis de la problemtica universitaria en cuestin y que la base terica y el aporte de la experiencia personal contribuyan al crecimiento de las soluciones actuales y al desarrollo de nuevas propuestas.

130

Captulo 8 Apndice. Documentacin tcnica del caso de estudio

8
8.1

Apndice. Documentacin tcnica del caso de estudio

Descripcin tcnica de las variables del cubo

Dimensiones Nombre Unidad acadmica Descripcin Unidad acadmica a la que corresponde el alumno o persona. Forma de clculo Este dato corresponde a los campos sga_personas.unidad_academica y sga_alumnos.unidad_academica. Tambin forma parte de la clave primaria de muchas de las tablas y se utiliza para realizar las uniones. En el primer nivel se Para cada alumno se recupera el ao de muestra el ao en que ingreso mediante el proceso cada persona ingresa a sp_int_arau_dating (que se utiliza para la universidad, a la informar a araucano). El dato corresponde al primera carrera de la ao acadmico en que se inscribe a la carrera cual se tiene registro y resulta ingresante o alumno condicional: como alumno en la base sga_periodo_insc.anio_academico tomando de datos del SIUcomo nexo el periodo de inscripcin de Guaran. sga_carrera_aspira.periodo_inscripcio. (donde A nivel de alumno se se busca el registro como aspirante muestra el ao de correspondiente a cada alumno) ingreso a cada carrera. En caso que este registro no exista se completa con el ao de la fecha en que se gener el legajo del alumno (sga_alumnos.fecha_ingreso). A nivel de persona se considera el mnimo valor de los aos de ingreso a las diferentes carreras. Ao acadmico en que Se toma de cada una de las tablas de actividad se efecta la actividad consideradas, segn lo que se est contando. de los alumnos. Para cursados y promociones: sga_comisiones.anio_academico Para finales: sga_actas_examen.anio_academico Y para las equivalencias, se toma el ao acadmico correspondiente a sga_equiv_otorgada.fecha (se verifica que esa fecha est entre sga_anio_academico.fecha_inicio y sga_anio_academico.fecha_fin) Indica el ltimo ao en Se calcula a partir de los aos acadmicos en que las personas o que los alumnos registran actividad (valores de alumnos tienen la dimensin Ao Informado). A nivel de actividad, a nivel de alumno se toma el mximo valor encontrado toda la universidad o de por carrera, y a nivel de persona se calcula el cada carrera. mximo de estos. Edad de los individuos en cada ao considerado, al ltimo da del ao calendario (31/12) Se calculan a partir de la fecha de nacimiento de las personas (sga_personas.fecha_nacimiento) Para la edad al ao de ingreso a la universidad, se le resta al ao de ingreso a la universidad el ao de nacimiento de la persona. Lo mismo se realiza para los aos de ingreso a carrera y los diferentes aos 131

Ao Ingreso (Ao Ingreso a la Universidad Ao Ingreso a la Carrera)

Ao Informado

ltimo ao con actividad (ltimo ao con actividad en la Universidad ltimo ao con actividad en la Carrera) Edad (Edad al Ingreso Universidad Edad al Ingreso Carrera Edad al Ao Informado)

Captulo 8 Apndice. Documentacin tcnica del caso de estudio

Sexo

Gnero de los individuos. Nacionalidad Nacionalidad de los individuos Procedencia Colegio secundario del (Pas que egres el Provincia estudiante. Localidad Localidad asociada al Colegio) colegio. Provincia a la que corresponde dicha localidad. Pas al que corresponde la provincia. Ttulo Secundario Ttulo del colegio secundario obtenido por cada individuo Ao Egreso Sec Ao de egreso del secundario Orient vocacional Indica si la persona recibi o no orientacin vocacional. Cant carreras inscripto Cantidad de carreras activo diferentes en que se (Cant carreras inscripto inscribi cada persona y Cant carreras la cantidad en que est activo/inscripto) activa. Se muestran dos niveles: el superior indica la cantidad de inscripciones y el otro en cuntas est activo sobre el total de inscripciones Cant carreras Cantidad de carreras en egresado que la persona registra calidad de egresado.

informados. Corresponde al campo sga_personas.sexo. Corresponde al campo sga_personas.nacionalidad. Colegio secundario del que egres la persona (sga_personas.colegio_secundario). Se considera la Localidad asociada al colegio secundario (sga_coleg_sec.localidad). Luego se toman la provincia y el pas que correspondan a la localidad utilizando las tablas mug_localidades, mug_dptos_partidos, mug_provincias y mug_paises. Corresponde al campo sga_personas.titulo_secundario Corresponde al campo sga_personas.anio_egreso_sec Corresponde al campo sga_personas.orient_voc_rec Las carreras activas se calculan contando la cantidad de registros en sga_alumnos con calidad activa (sga_alumnos.calidad=A) agrupando por persona (unidad acadmica y nmero de inscripcin). La cantidad de carreras en que se inscribi, o aspir a ser alumno, se toman de la tabla sga_carrera_aspira, contando los distintos valores de sga_carrera_aspira.carrera La cantidad de carreras en que egres se calcula contando la cantidad de registros en sga_alumnos con calidad egresado (sga_alumnos.calidad=E) agrupando por persona (unidad acadmica y nmero de inscripcin). Corresponde al campo sga_alumnos.carrera. Este campo tambin se utiliza al calcular la actividad, formando parte de la unin entre la tabla de alumnos y las de cursados, exmenes y equivalencias. Se cuentan los registros en actas de cursado cerradas con resultado aprobado (A) para cada ao acadmico y alumno (mediante la unin de las tablas: sga_det_acta_curs, sga_actas_cursado, sga_comisiones y sga_periodos_lect). Luego se sumarizan por alumno, para el nivel carrera, y por persona. Se cuentan los registros en actas de cursado cerradas con resultado desaprobado (R) para cada ao acadmico y alumno (mediante la unin de las tablas: sga_det_acta_curs, sga_actas_cursado, sga_comisiones y sga_periodos_lect). Luego se sumarizan por alumno, para el nivel carrera, y por persona. 132

Carrera

Carrera asociada al alumno.

Cursados Aprobados (Cursados Aprobados Totales por Persona Cursados Aprobados Totales en la Carrera Cursados Aprobados en la Carrera y Ao Informado) Cursados Desaprobados (Cursados Desaprobados Totales por Persona Cursados Desaprobados Totales en la Carrera

Cantidad de cursados aprobados registrados en actas cerradas, para cada ao acadmico, totales por carrera, y sumatoria de todas las carreras. Cantidad de cursados desaprobados registrados en actas cerradas, para cada ao acadmico, totales por carrera, y sumatoria de todas las carreras.

Captulo 8 Apndice. Documentacin tcnica del caso de estudio

Cursados Desaprobados en la Carrera y Ao Informado) Cursados Promovidos (Cursados Promovidos Totales por Persona Cursados Promovidos Totales en la Carrera Cursados Promovidos en la Carrera y Ao Informado) Finales Aprobados (Finales Aprobados Totales por Persona Finales Aprobados Totales en la Carrera Finales Aprobados en la Carrera y Ao Informado) Finales Desaprobados (Finales Desaprobados Totales por Persona Finales Desaprobados Totales en la Carrera Finales Desaprobados en la Carrera y Ao Informado) Equivalencias Externas (Equivalencias Externas Totales por Persona Equivalencias Externas Totales en la Carrera Equivalencias Externas en la Carrera y Ao Informado)

Cantidad de cursados promovidos registrados en actas de cursado cerradas, para cada ao acadmico, totales por carrera, y sumatoria de todas las carreras. Cantidad de exmenes finales aprobados registrados en actas cerradas, para cada ao acadmico, totales por carrera, y sumatoria de todas las carreras. Cantidad de exmenes finales desaprobados registrados en actas cerradas, para cada ao acadmico, totales por carrera, y sumatoria de todas las carreras. Cantidad de equivalencias totales otorgadas (con origen externo o de pase), para cada ao acadmico, totales por carrera, y sumatoria de todas las carreras.

Se cuentan los registros en actas de cursado cerradas con resultado promovido (P) para cada ao acadmico y alumno (mediante la unin de las tablas: sga_det_acta_curs, sga_actas_cursado, sga_comisiones y sga_periodos_lect). Luego se sumarizan por alumno, para el nivel carrera, y por persona. Se cuentan los registros, no rectificados, en actas de examen cerradas con resultado aprobado (A) para cada ao acadmico y alumno (mediante la unin de las tablas: sga_detalle_acta y sga_actas_examen). Luego se sumarizan por alumno, para el nivel carrera, y por persona. Se cuentan los registros, no rectificados, en actas de examen cerradas con resultado desaprobado (R) para cada ao acadmico y alumno (mediante la unin de las tablas: sga_detalle_acta y sga_actas_examen). Luego se sumarizan por alumno, para el nivel carrera, y por persona. Se cuentan los registros, no rectificados y activos, en actas de equivalencia con resultado aprobado (A) con alcance total (T) y de origen externo o pase (E y P) para cada ao acadmico y alumno (mediante la unin de las tablas: sga_equiv_otorgada y sga_equiv_operac). El ao acadmico se determina a partir de la fecha de la equivalencia (sga_equiv_otorgada.fecha), controlando que esta se encuentre entre sga_anio_academico.fecha_inicio y sga_anio_academico.fecha_fin. Luego se sumarizan por alumno, para el nivel carrera, y por persona.

Medidas Nombre Cant Personas Cant Alumnos Cant Alum X Ao c/Activ Descripcin Cantidad de personas registradas en la base de datos del SIU-Guaran. Cantidad de alumnos registrados en la base de datos del SIU-Guaran. Cantidad de registros resultante de contar a cada alumno en cada ao acadmico en que registra actividad. Se consideran como actividad: registros en actas de cursado, actas de examen y actas de equivalencias otorgadas totales o parciales (con origen E o P). Slo se Forma de clculo Se cuentan todos los registros existentes en la tabla sga_personas. Se cuentan todos los registros existentes en la tabla sga_alumnos. Para cada alumno y cada ao acadmico a partir del ao de ingreso a la carrera (calculado con sp_int_arau_dating) se recorren las tablas: - de cursado (sga_det_acta_curs, sga_actas_cursado, sga_comisiones, sga_periodos_lect), contando aprobados, 133

Captulo 8 Apndice. Documentacin tcnica del caso de estudio

consideran actas cerradas y registros que no estn rectificados (cualquiera sea el resultado: aprobado, desaprobado, promovido y ausente, porque el hecho de inscribirse se lo considera actividad, o al menos intencin de tenerla). Se busca actividad a partir del ao de ingreso a la carrera hasta la fecha corriente.

desaprobados, promocionados y ausentes - de exmenes (sga_detalle_acta, sga_actas_examen), contando aprobados, desaprobados y ausentes - y de equivalencias otorgadas (sga_equiv_otorgada, sga_equiv_operac) contando equivalencias totales y parciales con origen E o P. Si alguna de estas cuentas es diferente a cero se cuenta al alumno dentro del ao acadmico correspondiente.

Para mayor detalle consultar las consultas SQL de los procesos de extraccin de datos y las definiciones de campos virtuales dentro del modelo de O3 que se adjuntan. Los cruces entre las medidas y los niveles de las dimensiones no permitidos no se especifican aqu porque se encuentran en la figura 18 de la seccin 5.3.

8.2

Consideraciones especiales
Algunas particularidades del caso de estudio deben ser tenidas en cuenta. Entre ellas: El siguiente trabajo est basado en informacin contenida en tablas generales de la versin 2.3 o posterior del sistema SIU-Guaran. No contiene informacin proveniente de las personalizaciones del SIU-Guaran que ha realizado la UNS con el objeto de que los desarrollos puedan utilizarse en el resto de las UUNN. Las definiciones y criterios asumidos (detallados en la seccin 8.1) podran modificarse o personalizarse para contemplar los cambios que sean de utilidad. La construccin del cubo debe ser de tipo FULL. Esto significa que no se incorporan datos a un cubo existente sino que se debe generar un cubo nuevo. Debe determinarse una poltica de actualizacin del cubo acorde a los momentos en que se necesita informacin y en que se dispone de datos estables. Tener en cuenta que si los datos que se incorporan al Data Mart no son estables podrn surgir variaciones luego. Por ejemplo, en la cantidad de ingresantes, (si no finaliz el perodo de inscripcin a carreras en el momento en que se genera el cubo) y en las variables totalizadoras de actividad (si no estn ingresadas y cerradas todas las actas al sistema). Algunas de estas variaciones pueden parecer inconsistentes, como podra ser el caso de los alumnos condicionales que son contados como ingresantes; si en algn momento estos fueran rechazados en el sistema de gestin al regenerarse el cubo la cantidad de ingresantes ser menor.

134

Captulo 8 Apndice. Documentacin tcnica del caso de estudio

8.3

Estructuras de los archivos de texto

Tabla: int_dw_personas.txt Campos Cdigo de unidad acadmica Nmero de Inscripcin Tipo de documento Nmero de documento Cdigo de sexo Fecha de Nacimiento Cdigo de nacionalidad Cdigo de colegio secundario Cdigo de Ttulo del secundario Ao de egreso del secundario Cdigo de si recibi orientacin vocacional o no Cantidad de carreras en que se encuentra activa la persona Cantidad de carreras en que egres la persona Cantidad de carreras en que se inscribi la persona Cantidad total de readmisiones de la persona Ao de Ingreso a la Universidad ltimo ao en que tiene actividad en la universidad Total de cursados aprobados de la persona Total de cursados desaprobados de la persona Total de cursados promovidos de la persona Total de cursados ausentes de la persona Total de finales aprobados de la persona Total de finales desaprobados de la persona Total de finales ausentes de la persona Total de equivalencias externas de la persona Total de equivalencias parciales de la persona Cantidad de Personas Tabla: int_dw_alumnos.txt Campos Cdigo de unidad acadmica Cdigo de carrera Nmero de Legajo Cdigo del plan de estudio actual del alumno Nmero de Inscripcin Cdigo de condicin de regularidad del alumno en la carrera Cantidad de readmisiones en la carrera Cdigo de calidad del alumno (activo, pasivo, egresado, de baja) Ao de Ingreso a la carrera Cantidad de veces que realiz cambios de plan en la carrera Cantidad de veces que intent ingresar a la carrera Promedio del alumno en la carrera Duracin terica del plan en aos Cantidad de materias del plan Cantidad de materias optativas del plan Estado del plan (vigente, activo, etc.) ltimo ao en que tiene actividad en la carrera Total de cursados aprobados en la carrera Total de cursados desaprobados en la carrera Total de cursados promovidos en la carrera Total de cursados ausentes en la carrera Tipo de dato Texto Texto Texto Texto Texto Texto (S/N) Numrico Texto (A/P/E/N) Numrico Numrico Numrico Numrico con decimales Numrico Numrico Numrico Texto Numrico Numrico Numrico Numrico Numrico 135 Tipo de dato Texto Texto Texto Texto Texto Fecha. MM/DD/AAAA Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico. Es siempre 1.

Captulo 8 Apndice. Documentacin tcnica del caso de estudio

Total de finales aprobados en la carrera Total de finales desaprobados en la carrera Total de finales ausentes en la carrera Total de equivalencias externas en la carrera Total de equivalencias parciales en la carrera Cantidad de Alumnos Tabla: int_dw_desercion_alumnos_anio.txt Campos Cdigo de unidad acadmica Cdigo de carrera Nmero de Legajo Nmero de Inscripcin Ao de Ingreso a la carrera Ao informado, correspondiente a cada ao acadmico en que el alumno tiene actividad en la carrera Total de cursados aprobados en la carrera y en el ao informado Total de cursados desaprobados en la carrera y en el ao informado Total de cursados promovidos en la carrera y en el ao informado Total de cursados ausentes en la carrera y en el ao informado Total de finales aprobados en la carrera y en el ao informado Total de finales desaprobados en la carrera y en el ao informado Total de finales ausentes en la carrera y en el ao informado Total de equivalencias externas en la carrera y en el ao informado Total de equivalencias parciales en la carrera y en el ao informado Cantidad de Registros (Alumnos X Ao con actividad) Tabla: LT_Carreras.txt Campos Cdigo de unidad acadmica Cdigo de carrera Nombre de carrera Tabla: LT_Colegios.txt Campos Cdigo de colegio secundario Nombre de colegio Cdigo de localidad Tabla: LT_Localidades_ColSec.txt Campos Cdigo de localidad Nombre de localidad Cdigo de Provincia Tabla: LT_Provincias.txt Campos Cdigo de Provincia Nombre de Provincia Cdigo de Pas Tabla: LT_Paises.txt Campos Tipo de dato Tipo de dato Numrico Texto Numrico Tipo de dato Numrico Texto Numrico Tipo de dato Numrico Texto Numrico Tipo de dato Texto Texto Texto

Numrico Numrico Numrico Numrico Numrico Numrico. Es siempre 1.

Tipo de dato Texto Texto Texto Texto Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico Numrico. Es siempre 1.

136

Captulo 8 Apndice. Documentacin tcnica del caso de estudio

Cdigo de pas Nombre de pas Tabla: LT_Sexos.txt Campos Cdigo de sexo Descripcin de sexo Tabla: LT_Nacionalidades.txt Campos Cdigo de nacionalidad Descripcin de nacionalidad Tabla: LT_TitulosSecundario.txt Campos Cdigo de Ttulo del secundario Nombre de Ttulo del secundario Tabla: LT_UnidadesAcademicas.txt Campos Cdigo de unidad acadmica Nombre de unidad acadmica

Numrico Texto

Tipo de dato Texto Texto

Tipo de dato Numrico Texto

Tipo de dato Numrico Texto

Tipo de dato Texto Texto

8.4

Generacin del cubo

Para utilizar la solucin propuesta se requiere: Tener instalada la herramienta O3 Se utiliza la versin 4.3 de este software49. Si no estuviese instalada en la universidad se puede bajar una versin de evaluacin por treinta das de www.ideasoft.com.uy en la seccin descargas. Para utilizar el cubo ser necesario tener instalado el componente O3 Browser, o utilizar la interfaz web. Para generar el cubo se requiere el componente O3 Builder. Generar los datos desde el SIU-Guaran. Se requiere que se est utilizando la versin 2.3 o posteriores de SIU-Guaran. Se prob sobre versin 2.5.2. Los procesos a correr no han sido an incorporados al cdigo ncleo del SIU-Guaran. Se adjuntan a este trabajo y deben ejecutarse manualmente sobre la base de datos, en el orden indicado. Es necesario tener actualizada la corrida de los procesos que generan datos para el SIUAraucano ya que se utilizan tablas de interfaz entre ambos sistemas que es necesario tener completadas. Como parte de lo entregado, en 0_ejecucion de procesos_act_datos_ araucano.sql se listan los procesos de la interfaz con SIU-Araucano que sera necesario

49

Al momento de presentar la tesis ya ha sido lanzada la versin 5 de O3. Esta solucin es perfectamente compatible.

137

Captulo 8 Apndice. Documentacin tcnica del caso de estudio

ejecutar para generar un cubo con informacin de 1994 a 2007. Puede utilizarse de ejemplo tomando slo lo que necesite. Luego deben ejecutarse los otros archivos en el orden en que estn numerados. En el ltimo de ellos 7_generacion_txt.sql puede modificarse el directorio destino para los archivos de texto. Observacin: es interesante comentar que cualquier conjunto de datos que respete las estructuras de las tablas detalla en la seccin 8.3 podr ser usado como fuente para generar un cubo, no es necesario que la informacin sea proveniente del SIU-Guaran para poder utilizar el modelo. Generar el cubo50 Finalmente, para generar el cubo es necesario copiar el modelo (dm_desgranamiento_ alumnos.mdl) y el ejecutable (dm_desgranamiento_alumnos.bat) en C:\IdeaSoft\O3\siu\ guarani\51. Ubicar los archivos de datos en C:\IdeaSoft\O3\siu\guarani\txt\. Si deseara instalar O3 en un directorio diferente a C:\IdeaSoft\O3 consulte cmo realizar los cambios necesarios. Ejecutar dm_desgranamiento_alumnos.bat para generar dm_desgranamiento_alumnos. cube en C:\IdeaSoft\O3\siu\guarani\. Se toman los datos de los archivos de texto al momento de la corrida. Si existiera un cubo con el mismo nombre lo reemplaza.

8.5

Archivos adjuntos
Junto a este documento se entrega un CD que contiene: los procesos para generar los datos desde el SIU-Guaran, el modelo y el ejecutable para poder generar el cubo, el cubo con datos de ejemplo usado para los ejemplos en este documento, los archivos de texto con datos de ejemplo para generar el cubo utilizado, y la versin digital de este documento.

50

La generacin explicada aqu es para ser utilizada en sistemas operativos Windows. Es posible trabajar en Linux, slo hay que realizar pequeas adaptaciones respecto a los ejecutables y los directorios. 51 Se respeta la estructura de archivos utilizada para los cubos que distribuye el SIU, que ser quien asuma el mantenimiento de este trabajo.

138

Captulo - Bibliografa

Bibliografa
[Inm2002] William H. Inmon, 2002. Building the Data Warehouse, Third Edition. Wiley Computer Publishing, John Wiley & Sons, Inc. [Kim1992] Ralph Kimball, 1992. The Data Warehouse Toolkit, Wiley Computer Publishing [Kim1998] Ralph Kimball, Laura Reeves, Margy Ross, Warren Thornthwaite, 1998. The Data Warehouse Lifecycle Toolkit, Wiley Computer Publishing. [Kim2002] Ralph Kimball, Margy Ross, 2002. The Data Warehouse Toolkit Second Edition. Wiley Computer Publishing, John Wiley & Sons, Inc. [Kim2004] Ralph Kimball, Joe Caserta, 2004. The Data Warehouse ETL Toolkit, Wiley Publishing, Inc. [Mst2005] MicroStrategy, 2005. Teora sobre Business Intelligence Concurso MicroStrategy Experiencia Business Intelligence 2da. Edicin [1] http://inmoncif.com/home/ [2] http://en.wikipedia.org/wiki/Bill_Inmon [3] http://www.soluciones-ar.com.ar/es/comunicaciones/cm010705.asp [4] http://www.microstrategy.com.ar/Solutions/5Styles/index.asp [5] http://www.olapreport.com/market.htm o http://www.olapreport.com/ [6] http://www.siu.edu.ar [7] http://www.siu.edu.ar/soluciones/guarani/publicaciones/libro/ o http://www.siu.edu.ar/documentos/SIU-Guarani-Williams-Gurmendi.pdf [8] CONVOCATORIA-20SEMINARIO-2002.pdf en http://www.iesalc.unesco.org.ve/ [9] http://www.iesalc.unesco.org.ve/PROGRAMAS/EVENTOS/EVENTOS2005/DOCUMENTOS/ (47)CHILE.INF-FINAL.PDF [10] http://www.inmoncif.com/library/cif/ [11] Claudia Imhoff, http://www.dmreview.com/issues/19991201/1667-1.html [12] http://etl-tools.info/es/bi/proceso_etl.htm [13] http://www.inmoncif.com/library/glossary/ [14] http://etl-tools.info/ [15] http://es.wikipedia.org/wiki/EIS [16] http://www.ideasoft.com.uy/lportal/web/site/support o ftp://ftp.ideasoft.biz/o3docs/spanish/O3DesignerSpanish.pdf [17] http://www.ralphkimball.com/html/about.html o http://www.kimballgroup.com/html/about.html [18] http://en.wikipedia.org/wiki/Ralph_Kimball [19] http://www.businessobjects.com/ [20] http://www.cognos.com/ [21] http://www.microstrategy.com [22] http://www.pentaho.com/ [23] http://www.oracle.com/hyperion/index.html 139

Captulo - Bibliografa

[24] http://www.oracle.com/solutions/business_intelligence/DW_home.html [25] http://www.qlikviewspain.com/ [26] http://www.stratebi.com/ [27] http://pentaho.almacen-datos.com/ [28] http://todobi.blogspot.com/2005/06/empresas-business-intelligence.html [29] http://www.microstrategy.com.ar/Software/comparison/index.asp?CID=2518g [30] http://www.is-portal.com/bi/index.php?cnid=165 [31] http://www.bi-spain.com/ [32] http://www.barc.es/ [33] http://www.telefonica.net/web2/todobi/Pixfolder/HandsON1.pdf [34] http://www.telefonica.net/web2/todobi/Pixfolder/HandsON2.pdf [35] Gartner 2006: http://www.telefonica.net/web2/todobi/Pixfolder/magic_quadrant_for _businesslligence_int__Q106.pdf [36] Gartner: 2007: http://mediaproducts.gartner.com/reprints/hyperion/145507.html [37] http://businessintelligence-ar.blogspot.com/2007/11/tendencias-y-carencias-enbusiness_16.html [38] http://www.cognos.com/news/releases/2008/0131-2.html?mc=-web_hp [39] http://www.oracle.com/corporate/press/2007_mar/hyperion.html [40] http://businessintelligence-ar.blogspot.com/2007/11/tendencias-y-carencias-enbusiness_16.html

140