tesis dw cecilia domina
Post on 15-Feb-2015
84 Views
Preview:
TRANSCRIPT
Universidad Nacional del Sur
Departamento de Ciencias e Ingeniería de la Computación
Tesis de Licenciatura en Ciencias de la Computación
“Data Warehousing.Relevamiento y aplicación de
técnicas de modelado dimensional”
Alumna: María Cecilia DóminaDirectoras: Mg. Elsa Estévez
y Lic. Mercedes Vitturini
Bahía BlancaDiciembre 2008
1
Resumen
Este trabajo ha sido desarrollado por la alumna María Cecilia Dómina bajo la dirección de
la Mg. Elsa Estévez y la Lic. Mercedes Vitturini. Se presenta como tesis de la carrera de grado
Licenciatura en Ciencias de la Computación de la Universidad Nacional del Sur.
En este proyecto se estudia la utilización de herramientas de Data Warehousing para el
análisis de datos. Se destaca la importancia de la aplicación de estas tecnologías para el
conocimiento de la información de cualquier institución y la toma de decisiones basada en datos
ciertos y concretos. La tesis se organiza en dos secciones. En la primera parte, se presentan y
ejemplifican los principales conceptos teóricos desarrollados en esta área de las ciencias de la
computación y se presentan las principales técnicas de diseño de Data Warehouses actuales.
En la segunda sección se desarrolla un ejemplo de aplicación de los conceptos y técnicas
estudiadas enfocados hacia una propuesta de análisis de desgranamiento de alumnos
universitarios. El diseño apunta a la identificación de perfiles y patrones de los alumnos
universitarios que abandonan la actividad académica. Para el caso de estudio se utiliza como
modelo organizacional de partida al modelo de datos usado por el Sistema de Gestión de
Académica de Alumnos SIU-Guaraní. El sistema SIU-Guaraní actualmente se utiliza como sistema
de gestión académica en la mayoría de las universidades nacionales argentinas y particularmente
en la Universidad Nacional del Sur.
El presente trabajo se realizó con la colaboración del SIU1, que facilita el uso de la
herramienta O3 de la empresa IdeaSoft para la implementación del caso práctico y los desarrollos
y documentación que poseen sobre el tema de estudio y lo referente al SIU-Guaraní. Todo lo
desarrollado como parte de esta tesis queda a disposición del SIU para su publicación y futura
aplicación.
1 El SIU es un área del Ministerio de Educación que desarrolla sistemas informáticos para las Universidades Nacionales.2
Agradecimientos
Quiero darles las gracias a todas las personitas que de alguna manera colaboraron
conmigo para que este trabajo esté hoy realizado. A Mercedes por la buena predisposición de
siempre y su paciencia. A Darío por su enorme colaboración. Al SIU en general por brindar las
herramientas, el material, y el conocimiento para la construcción del caso práctico. Y a mi familia,
amigos, compañeros y todo el equipo del SIU por su apoyo y empuje, por estar. Gracias!, sin
ustedes todo hubiese sido más difícil.
3
Índice
Resumen.................................................................................................................2
Agradecimientos....................................................................................................3
Índice.......................................................................................................................4
1 Introducción ......................................................................................................... 7
2 Sistemas para Análisis de Información ........................................................... 10
2.1 Evolución 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 transformación de los datos.................................................................................18
Almacenamiento y presentación de los datos .......................................................................21
Análisis de información..........................................................................................................22
2.5 Aplicaciones tradicionales versus aplicaciones para análisis de información ......... 23
Caracterización de las diferencias ........................................................................................24
Nivel de datos físico para análisis de información.................................................................27
2.6 Tendencias en sistemas para análisis de información ............................................ 29
2.7 El mercado de Data Warehousing y Business Intelligence ..................................... 32
3 El proceso de creación de modelos analíticos ............................................. 34
3.1 Introducción al modelado multidimensional ............................................................ 34
Dimensiones, hechos y medidas...........................................................................................37
Navegación del modelo multidimensional..............................................................................38
Tabla de hechos....................................................................................................................38
Tablas de dimensión..............................................................................................................39
Esquema estrella...................................................................................................................39
3.2 Ciclo de vida de un proyecto de Data Warehousing ............................................... 40
Hitos del mapa de ruta del BDL.............................................................................................40
Planificación del proyecto......................................................................................................41
Definición de requerimientos.................................................................................................42
Diseño de la arquitectura técnica...........................................................................................42
4
Selección de Productos e Instalación....................................................................................43
Modelado Dimensional lógico................................................................................................43
Diseño Físico.........................................................................................................................44
Diseño de las Extracciones y Transformaciones de Datos ...................................................44
Especificación de Aplicaciones para Usuarios Finales..........................................................45
Desarrollo de Aplicaciones para Usuarios Finales.................................................................47
Puesta en producción............................................................................................................47
Mantenimiento y crecimiento.................................................................................................49
Gerenciamiento del Proyecto.................................................................................................50
3.3 Técnicas para el modelado dimensional. ................................................................ 50
Elección del Data Mart...........................................................................................................51
Tablas de Hechos y Granularidad.........................................................................................52
Diseño de las dimensiones....................................................................................................57
Definición de las medidas......................................................................................................66
Diseño multidimensional avanzado........................................................................................69
4 Presentación del caso de estudio .................................................................... 72
4.1 ¿Qué es el SIU? ..................................................................................................... 72
4.2 El sistema de software SIU-Guaraní ....................................................................... 73
4.3 Deserción y desgranamiento de alumnos ............................................................... 75
5 Presentación de la solución ............................................................................. 77
5.1 Requerimientos y especificación del Data Mart ...................................................... 77
Datos considerados...............................................................................................................77
Datos que quedaron excluidos y motivos .............................................................................78
5.2 Arquitectura del caso práctico ................................................................................. 79
5.3 Matriz y modelo lógico del Data Mart ...................................................................... 80
5.4 Modelo físico y consideraciones de diseño ............................................................. 83
Diseño físico de las tablas del DW que se usan para el Data Mart.......................................84
Diseño físico del Data Mart....................................................................................................86
5.5 Personalización del proceso ETL ........................................................................... 92
5.6 Problemas de calidad de datos ............................................................................... 93
Controles en la definición del modelo y la generación del cubo............................................93
Controles en los procesos de extracción y transformación de datos.....................................94
Problemas de calidad en el origen del dato...........................................................................94
6 Uso de la herramienta y análisis de datos ...................................................... 96
5
6.1 Acceso al cubo y operaciones básicas ................................................................... 96
Acceso al cubo y vista inicial.................................................................................................96
Operaciones básicas de consulta..........................................................................................97
6.2 Un ejemplo de análisis sobre evolución de la matrícula ........................................ 101
Cantidad de alumnos por año académico............................................................................101
Análisis de ingresantes........................................................................................................103
Seguimiento de una cohorte................................................................................................107
6.3 Ejemplos de análisis de procedencia .................................................................... 110
Análisis a nivel de país y calidad de datos...........................................................................111
Exploración de los niveles de la dimensión procedencia.....................................................112
Articulación de colegios y carreras......................................................................................113
6.4 Un ejemplo de desgranamiento basado en la actividad académica y rendimiento
........................................................................................................................ 116
Último año 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. Análisis por carrera y rendimiento
.................................................................................................................................124
7 Conclusiones y trabajo futuro ........................................................................ 127
7.1 Conclusiones ........................................................................................................ 127
7.2 Trabajo futuro ...................................................................................................... 128
8 Apéndice. Documentación técnica del caso de estudio ............................. 131
8.1 Descripción técnica de las variables del cubo ....................................................... 131
8.2 Consideraciones especiales ................................................................................. 134
8.3 Estructuras de los archivos de texto ..................................................................... 135
8.4 Generación del cubo ............................................................................................. 137
8.5 Archivos adjuntos ................................................................................................. 138
Bibliografía ......................................................................................................... 139
6
Capítulo 1 - Introducción
1 Introducción
Sin lugar a dudas, el Data Warehousing es parte integral de lo que algunos autores
definen como la “era de la información” ya que posibilita la construcción y mantenimiento de
estructuras destinadas al análisis de los datos, transformando los datos en información y la
información en conocimiento [Mst2005].
El concepto de Data Warehouse (DW), cuya traducción literal sería almacén o repositorio
de datos, surge en los años 90 con la necesidad y oportunidad de obtener información de los
datos que habían sido recolectados durante los años anteriores por los sistemas de gestión. Así, el
DW nace producto de la evolución de los sistemas para soporte de decisiones. Hasta ese
momento, la información que requerían las organizaciones se obtenía a partir de consultas y
procesamientos sobre las bases de datos de los sistemas operacionales. Con el transcurso del
tiempo se comenzó a evidenciar que ese entorno no era suficiente para resolver las necesidades
analíticas.
Los sistemas del ambiente de procesamiento de transacciones en línea OLTP (on-line
transaction processing) en general carecen de integración y no mantienen en línea la información
histórica requerida para la toma de decisiones estratégicas en una organización. Además las
consultas de tipo gerencial, con información resumida y desde distintas vistas, demandan el
procesamiento de importantes volúmenes de datos, requiriendo recursos y deteriorando
notablemente el rendimiento de los sistemas operacionales. Por esta razón generalmente debían
ser disparados en horarios en que éstos no se estuvieran utilizando en producción. La práctica
muestra que deben existir dos ambientes diferentes debido a que el procesamiento analítico en
línea OLAP (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 tecnología que los soporta también.
Se necesita del diseño de una nueva arquitectura para cubrir los requerimientos analíticos
de los usuarios que sea lo suficientemente robusta para alcanzar las necesidades futuras. En este
nuevo esquema para el sistema de soporte de decisiones DSS (decision support systems) el DW
cumple un rol fundamental, convirtiéndose en el repositorio central y la única fuente de datos
consolidados consultable para el análisis de información de toda la organización. Así, se puede
organizar al sistema de información en dos grandes sectores: el de los sistemas operacionales,
donde se registran los datos, y el del DW donde se procesan los volúmenes de información para
obtener conocimiento.
Un DW es un tipo especial de base de datos orientado a la exploración de la información
histórica que contiene. El modelo que soporta la información se encuentra diseñado, estructurado
e implementado con la finalidad y propósito del análisis y navegación de los datos y recibe el
nombre de modelo multidimensional.
7
Capítulo 1 - Introducción
El modelado multidimensional es una técnica para diseñar modelos de datos simples y
entendibles. Se busca visualizar el contenido de la base de datos como un cubo de tres, cuatro,
cinco o más dimensiones. Bajo este paradigma, los usuarios se pueden imaginar “navegando” la
información y realizando cortes a ese cubo a través de cada una de sus dimensiones. Se entiende
por navegación o “drilling” de los datos, a la capacidad de ver información correspondiente a
diferentes contextos o entornos. Por ejemplo, analizar los egresados de un determinado año y
poder detallarlos por carrera. Luego analizar más profundamente una carrera para ver cómo se
discriminan los egresados por cada cohorte2, etc.
El modelo dimensional organiza y presenta los datos definiendo dimensiones. Se define
como dimensiones a las líneas o áreas temáticas del negocio, como por ejemplo producto,
sucursal, tiempo. Son entidades independientes que sirven como punto de entrada para el análisis
de la información contenida en el modelo multidimensional. Llevado al ámbito universitario y para
el análisis información académica de alumnos se podrían considerar a las dimensiones: carreras,
lugar de procedencia, año de ingreso, entre otras. Dentro de las dimensiones pueden existir
diferentes niveles de análisis o jerarquías. Para el caso de procedencia se podrían considerar los
niveles país, provincia, localidad y colegio, por ejemplo. Las dimensiones se relacionan a través de
hechos. Se consideran hechos a sucesos o eventos que ocurren, como por ejemplo alumnos que
cursan carreras, o que rinden exámenes. Este último ejemplo estaría relacionando a las
dimensiones: materia, alumno, y fecha, entre otras. Los hechos o eventos generalmente se
asocian con una o más medidas (el resultado o nota, en este caso). Las medidas, métricas o
indicadores, son variables numéricas que ayudan a medir el rendimiento de un negocio o proceso.
En esta tesis se presentan los principales conceptos y técnicas de diseño y se resaltan la
importancia y potencial de estas tecnologías para la toma de decisiones y el mejoramiento de los
sistemas de gestión y la calidad de datos. La tesis se completa con un ejemplo práctico que
muestra la aplicación de los conceptos teóricos. Dado que el desarrollo está basado en el modelo
de datos de un sistema gestión transaccional de uso real, los resultados obtenidos podrán
utilizarse para colaborar en el análisis de la problemática de deserción universitaria.
El desarrollo de la tesis se organizó de la siguiente manera: en el capítulo 2 se describe la
evolución de los DSS que dio origen al DW; se define y conceptualiza el área de DW y sus
objetivos y se lo ubica dentro de la arquitectura de un DSS. Luego se detallan los principales
componentes del entorno, destacando las diferencias de este ambiente (OLAP) respecto al de los
sistemas operacionales o de gestión (OLTP). Finalmente se presentan las principales
herramientas del mercado.
En el capítulo 3 se especifican las características de los modelos dimensionales y las
principales técnicas para diseñarlos. También se presenta una metodología de producción de DW
o ciclo de vida de DW.
2 Entiéndase por cohorte al año académico en que el alumno ingresa a la carrera.
8
Capítulo 1 - Introducción
La segunda parte de esta tesis consta de tres capítulos destinados al caso de aplicación.
Se presenta la temática a abordar, se desarrolla la solución explicando las decisiones de diseño
adoptadas y luego se muestra el uso a través de ejemplos concretos. En este caso la temática
elegida es el desgranamiento de alumnos universitarios. La deserción universitaria es un tema que
ha despertado mucho interés en el último tiempo. El costo económico para el estado nacional de
un alumno en la universidad, la creciente necesidad de profesionales en algunas áreas y otras
causas sociales son algunos de los motivos que conducen a la pregunta de por qué una persona
comienza sus estudios universitarios y luego los abandona.
El caso práctico de esta tesis, además de mostrar un ejemplo de aplicación de los
conceptos desarrollados busca transmitir la experiencia adquirida mediante el análisis de distintas
alternativas para implementar y usar la solución. Los ejemplos de análisis de datos intentan
mostrar como sería posible encontrar dentro de una institución dónde se concentran los mayores
problemas, e identificar las posibles causas.
Como OLTP fuente de datos se usa el sistema SIU-Guaraní. El SIU-Guaraní es un
sistema de gestión de alumnos universitarios que administra información de gestión académica:
carreras, planes de estudio, títulos, materias, egresados, inscripciones y resultados de exámenes,
profesores asociados a las cátedras, asignación de aulas, asistencias, cursos de ingreso,
actividades extracurriculares, equivalencias, certificados, encuestas, etc. Este sistema está
desarrollado por el SIU y actualmente está implementado en la Universidad Nacional del Sur
desde agosto del 2004 y también en varias universidades nacionales argentinas3.
3 A mayo del 2008 se totalizan más de 200 instalaciones
9
Capítulo 2 - Sistemas para Análisis de Información
2 Sistemas para Análisis de Información
El término de Data Warehouse (DW) surge en los años 90 con la necesidad y oportunidad
de obtener información a partir de los datos que habían sido recolectados durante los años
anteriores por los sistemas de gestión.
En las últimas décadas el objetivo de los sistemas de información no es simplemente
servir a las necesidades operacionales sino también cubrir necesidades analíticas de la
información. En principio se utilizaron los mismos repositorios de datos para los diferentes
propósitos referentes al procesamiento de información: de transacciones, batch y analítico. Con el
transcurso del tiempo surgieron problemas que dejaron en evidencia que no es apropiado utilizar
el entorno donde se opera con los datos para analizar información. Las principales razones para
separar el entorno operacional del analítico radican en los datos que se utilizan, las tecnologías
que los soportan y la comunidad usuaria, entre otras. Este trabajo presenta el entorno analítico o
sistema para soporte de decisiones (DSS). En él, el DW cumple el rol de ser la única fuente de
datos consultable.
2.1 Evolución de los Sistemas de Soporte de Decisiones
La evolución de los DSS esta bien detallada en [Inm2002]. El autor plantea cómo fue la
evolución natural de los sistemas y los problemas que originaron el diseño de un ambiente
específico con una arquitectura estructurada en diferentes niveles de información, centrada en un
DW. A continuación se resumen los hechos más importantes que dieron origen a esta evolución.
Una vez que los sistemas de gestión habían sido implementados y funcionaban
correctamente surgió la necesidad de obtener información a partir de los datos recolectados.
Naturalmente en las organizaciones estas necesidades comenzaron a resolverse realizando
consultas a sus bases de datos operacionales, dentro de lo que se conoce como ambiente OLTP.
Cada sector requería diferentes extracciones de acuerdo a la información buscada. También
utilizaba y reutilizaba estos datos para producir información, basándose en sus propias reglas y
definiciones.
Así, el procesamiento de extracciones de datos comenzó a formar una red de información
que se asemeja a la estructura de una tela araña como se ilustra en la figura 1. Primero hubo
extracciones, luego extracciones de extracciones, y luego extracciones de extracciones de
extracciones, y así sucesivamente. Este comportamiento “fuera de control” en el proceso de
extracción a través de la organización es tan común que se le ha dado un nombre propio:
arquitectura naturalmente evolutiva o arquitectura de evolución natural.
10
Capítulo 2 - Sistemas para Análisis de Información
Figura 1. Arquitectura naturalmente evolutiva y problema de credibilidad de la información.
Esta arquitectura presenta algunos problemas importantes, entre los cuales se pueden
destacar la falta de credibilidad de los datos, la baja productividad, y la inhabilidad para
transformar datos en información. Estos problemas se hacen más notorios con el crecimiento de la
organización.
La carencia de credibilidad de datos se puede ejemplificar en que un “mismo” indicador o
reporte tiene resultados diferentes en puntos distantes de la organización (figura 1). Entonces
pueden obtenerse reportes en conflicto y la información pierde credibilidad. La causa de estas
inconsistencias es no tener a la información sincronizada. Las diferencias más importantes en la
forma de obtener la información final en general se deben a:
- La referencia temporal de los datos. Los períodos considerados difieren y/o la información
no está actualizada a la misma fecha.
- Los algoritmos de cálculo. Algunos criterios considerados de formas diferentes en la
definición de datos.
- El nivel de extracción. Cada nivel de extracción exagera los otros problemas que ocurren
en los niveles anteriores.
- Datos externos considerados. Pueden ser de diferentes fuentes y por lo tanto contener
información diferente.
- Múltiples fuentes. No contar con una fuente de datos en común desde el comienzo.
La productividad de este esquema es también un gran problema, especialmente cuando
hay necesidad de analizar datos a través de diferentes áreas para obtener reportes corporativos.
Generalmente esto requiere localizar y analizar los datos para el reporte, compilarlos, y asignar
recursos al programador o analista para acompañar estas tareas. Localizar los datos requiere
entre otras cosas: revisar muchos archivos, acceder a datos de lugares diferentes, para los cuales
tal vez se requiera diferentes perfiles de acceso y permisos; definir qué datos tomar cuando un
dato o indicador se repite y no es exactamente igual. Para compilar los datos es necesario escribir
muchos programas de extracción de datos, cada uno de ellos debe ser personalizado y tiene que
11
IndicadorA=y
IndicadorA=x
Capítulo 2 - Sistemas para Análisis de Información
cruzar la barrera tecnológica que use la compañía. A estos dos inconvenientes de tener que
localizar los datos y compilarlos hay que agregar que en general cuando el primer reporte se
obtiene no se conocen los requerimientos para reportes futuros y a no ser en circunstancias muy
inusuales el trabajo realizado para el primer reporte no allana el camino para los reportes
siguientes, por lo que resultan costosos todos los informes.
Además de los problemas de productividad y credibilidad, hay una carencia mayor de la
arquitectura evolutiva naturalmente y es la inhabilidad de ir desde los datos a la información. En la
mayoría de los casos para obtener determinada información hay que consultar datos que se
encuentran en aplicaciones heredadas y que no están integradas. En las aplicaciones a veces se
encuentran datos que sólo existen en un lugar y no pueden relacionarse con otras aplicaciones,
datos distintos con igual nombre y datos iguales nombrados de diferentes formas. La integración
de datos es un tema muy importante a la hora de querer obtener información.
Otro obstáculo para realizar esta tarea es la falta de datos históricos en las aplicaciones.
Es frecuente que en las bases de datos transaccionales sólo se guarden los datos para cumplir las
necesidades operacionales, que suelen no ser suficientes para satisfacer las necesidades
analíticas4.
Los requerimientos de evolución propios de los sistemas de gestión los hacen
inadecuados para soportar las necesidades de los DSS. Carecen de integración y existe una
discrepancia entre el horizonte de tiempo necesario para el procesamiento analítico y el existente
en las aplicaciones. Además esta arquitectura no es suficientemente robusta para alcanzar las
necesidades futuras. Entonces se necesita un cambio estructural importante.
Nivel Operacional Nivel del Data Warehouse (datos atómicos)
Nivel Departamental(Data Marts)
Nivel Individual
Información:• Detallada• Día a día• Valores
corrientes/actuales• Alta probabilidad de
acceso• Orientado a aplicaciones
Información:
• Mayormente detallada (most granular)
• Asociada a período de tiempo (time variant)
• Integrada• Orientada a una o más
temáticas (subject oriented)
• Algo agregada o resumida (some summary).
Información:• Parcializada,
correspondiente al área en cuestión (parochial)
• Contiene algunos datos derivados y otros primitivos.
Información:• Temporaria
• Ad hoc5
• Heurística• No repetitiva• Basada en pc o
estaciones de trabajo.
Figura 2. Arquitectura de los sistemas para la toma de decisiones diseñada en función de los niveles de información.
4 El SIU-Guaraní sí mantiene la información histórica. Este sistema no tiene las características de un sistema transaccional típico donde se cargan continuamente operaciones y se maneja un gran volumen de información diaria, como podría ser un sistema de ventas por menor o un sistema de registro de transacciones bancarias, o de reservas de vuelos.5 Entiéndase ad hoc como un análisis particular con un fin específico.
12
Capítulo 2 - Sistemas para Análisis de Información
Todo ello plantea la necesidad de una nueva arquitectura [Inm2002], basada
principalmente en los tipos de datos que se utilizan, si se trata de datos primitivos y datos
derivados. Esta arquitectura consta de cuatro niveles, y se muestra en la figura 2
Las principales diferencias entre los datos primitivos u operacionales y los datos derivados
o datos DDS son:
- Los datos primitivos son datos a nivel de detalle y son usados para realizar las
operaciones diarias de una compañía. Los derivados son datos sumarizados o de algún
modo calculados para cumplir con las necesidades de la gestión de la compañía.
- Los datos primitivos se actualizan mientras que los datos derivados se recalculan, pero no
se pueden actualizar.
- Los datos primitivos son principalmente valores actuales. Los derivados frecuentemente
se corresponden con datos históricos.
- Los datos primitivos son operados sobre procedimientos repetitivos mientras que los
derivados son operados heurísticamente, por programas y procedimientos analíticos.
- Los datos operacionales, que soportan las funciones del trabajo diario de oficina, son
primitivos. Los datos DDS, para toma de decisiones, que soportan las funciones
gerenciales, son derivados.
Ejemplo:
En un sistema de gestión académica, un dato primitivo sería: el alumno Juan Pérez
matrícula 6767 rindió la materia “Análisis matemático I”, cuyo código es 7865, el día 20/10/2005;
aprobó con calificación 8, y fue registrado en el acta X, folio Z. En contrapartida, el dato derivado
sería: Juan Pérez rindió 5 materias durante el 2005, aprobó el 80% de los exámenes rendidos
durante ese año y promedia 7,25 en la carrera.
En la figura 2 se observa que el nivel operacional de datos mantiene aplicaciones
orientadas a datos primitivos solamente y se basa en el procesamiento de transacciones. El nivel
de DW mantiene datos integrados, datos primitivos históricos que no pueden ser actualizados y
datos derivados. El nivel de Data Marts contiene casi exclusivamente datos derivados, aunque el
nivel de datos depende de los requerimientos de los usuarios finales y las necesidades de cada
departamento. Y el nivel individual de datos es donde se hace mucho análisis heurístico. A este
nivel, de análisis gerencial, se utiliza información agregada.
Como se puede observar en la figura el DW se constituye como el repositorio central y
única fuente de datos consolidados para análisis de información. Cumple un rol fundamental y
debe tener determinadas características para asegurar el correcto funcionamiento de esta
arquitectura.
13
Capítulo 2 -
2.2 ¿Qué es un Data Warehouse?
En forma sencilla se puede decir que un DW es una colección de datos, obtenidos a partir
de los datos transaccionales y específicamente estructurados para realizar consultas y analizar la
información [Kim1992]. Comúnmente se dice que los DW son fuentes secundarias de información
pues no generan datos por sí mismos, sino que son alimentados desde sistemas existentes
internamente en la organización o desde datos externos. Típicamente los usuarios del DW tienen
sólo permisos de lectura sobre este repositorio de datos. Los DW o bases de datos para
procesamiento analítico (OLAP) están específicamente estructurados o diseñados para cumplir
con un conjunto de metas bien diferentes a los objetivos de un sistema operacional OLTP. Por
ejemplo, una meta de los OLTP es maximizar la concurrencia de actualizaciones; dicho objetivo no
es pertinente en el diseño de DW donde las consultas son sólo de lectura [Mst2005]. En
contrapartida, las metas de un diseñador de DW deben focalizarse en entregar un análisis
multidimensional y capacidades de reportes ad hoc6 [Mst2005] y brindarlos de manera eficiente.
Estos requerimientos necesitan un diseño específico de la base de datos, que se presenta en el
capítulo siguiente como diseño o modelo multidimensional.
La definición más tradicional del término DW fue especificada por Bill Inmon a principios
de la década de los ‘90, quién lo definió como una colección de datos “orientados al sujeto”,
“integrados”, “variables en el tiempo” y “no volátiles” para ayudar al proceso de toma de decisiones
gerenciales [Inm2002] [Mst2005], donde:
- Orientados al Sujeto: datos que brindan información sobre un “sujeto” o asunto del
negocio en particular, en lugar de concentrarse en la dinámica de las transacciones de la
organización. Se dice que un DW está orientado a los sujetos de una organización y no a
sus operaciones o procesos. En el ambiente universitario se puede pensar en alumnos,
carreras, egresados, en lugar de inscripciones, registro de actas de exámenes, gestión de
títulos, etc.
- Integrados: los datos con los que se nutre el DW provienen de diferentes fuentes y son
integrados para dar una visión global coherente. Cuando se integran datos de diferentes
fuentes hay que contemplar cuestiones como la estandarización de codificaciones
(ejemplo: sexo como F y M, o 1 y 2, o V y M), formatos de campos (por ejemplo de
fechas), nomenclaturas (datos que significan lo mismo con nombres distintos, y datos
diferentes con el mismo nombre) y diferentes formas de medir algunos atributos.
- Variables en el Tiempo: todos los datos en el DW están asociados con un período de
tiempo específico. En los sistemas operacionales se lleva tanto información asociada a
algún período de tiempo, por ejemplo el año académico en que el alumno ingresa a la
carrera, o fecha en que rinde un examen; así como también se lleva información corriente,
ligada al momento actual, por ejemplo condición de regularidad de los alumnos. Cuando 6 Reportes ad hoc refiere a la generación de reportes personalizados por parte de usuarios expertos basados en el conocimiento del negocio. Más adelante en este trabajo se explica en detalle las características de análisis multidimensional y ad hoc.
14
Capítulo 2 -
se extraen datos de los sistemas fuentes para pasar al DW estos quedan asociados
siempre a un período de tiempo en el que esa información es válida. Se puede decir que
es el tiempo que corresponde al momento en que se toma la “foto” del sistema.
El DW puede concebirse entonces como una serie de fotos tomadas en algún momento de
tiempo. El elemento de tiempo puede tomar diferentes formas, desde una estampilla de
tiempo en cada registro del DW hasta una estampilla de tiempo de la base de datos
completa. Este último es el caso del trabajo práctico.
- No volátiles: los datos son estables en el DW. Se pueden agregar más datos, pero los
datos existentes no son removidos. Cuando un dato ingresa al DW se carga como una
foto, estática. Si ocurren cambios se cargan fotos nuevas y se mantiene la historia.
Obviamente que esta definición, ya clásica, se debe tomar como la definición pura sobre
DW. Sin embargo, con los años, algunos términos han sido modificados según las necesidades y
capacidades del mercado, dando origen a otros conceptos como el de Data Marts (para referirse a
DW sobre áreas específicas en lugar del warehouse corporativo) y otras variantes de DW donde
por ejemplo es válido actualizar datos ya existentes.
2.3 Objetivos de un Data Warehouse
Una de la las cosas más valiosas de una organización es su información. Esta es
generalmente mantenida en dos formas: el sistema operacional de registros y el DW. En forma
simplificada, el sistema operacional es donde los datos ingresan y el DW es donde se realiza
análisis y se extrae información.
El DW vendría a cumplir el rol de ser la fuente donde los usuarios pueden acceder a sus
datos. Los objetivos fundamentales de un DW particular se van a desprender de las inquietudes
que tengan los directivos de una organización. En [Kim1998] se establecen como requerimientos
las siguientes consideraciones de calidad:
- El DW debe proveer acceso fácil a la información de una organización.
Información accesible significa que administradores y analistas de una organización deben
poder conectarse al DW desde sus computadoras personales. La conexión debe ser
inmediata, a demanda y de alta velocidad. No es aceptable que el acceso sea a través de
otra persona, sea inseguro o lento.
El DW no es sólo los datos, sino también un conjunto de herramientas para consultar,
analizar y presentar la información. Las herramientas de acceso deben ser simples y
fáciles de usar.
Los contenidos del DW deben ser entendibles y navegables. Esto quiere decir que deben
estar correctamente etiquetados y que los datos pueden ser separados y combinados por
el significado de toda posible medida del negocio.
15
Capítulo 2 -
- Los datos del DW deben ser consistentes y de buena calidad.
La información del DW debe ser creíble. Consistencia implica resolver las
correspondencias entre la información de diferentes partes de la organización. Si dos
medidas de una organización tienen el mismo nombre deben tener el mismo significado.
Inversamente si dos medidas difieren en significado deben etiquetarse de manera distinta.
Información consistente y de alta calidad significa que toda la información debiera ser
tenida en cuenta y que es completa. También implica que deben estar disponibles para los
usuarios las definiciones comunes (diccionario de datos) de los contenidos del DW.
Los datos que se publican en el DW deben ser útiles. Como los datos provienen de
diferentes fuentes de información, deben ser combinados cuidadosamente, atravesar una
etapa de limpieza que debe asegurar la calidad antes de pasar a ser parte del DW.
La calidad de los datos del DW debe ser una conductora para la reingeniería del negocio.
El DW no puede arreglar la pobre calidad de los datos. Si los datos son opcionales y no
están completos no hay nada que el DW pueda hacer. La única forma de mejorar la
calidad afecta a las personas que ingresan datos al sistema y a los administradores y
consiste en volver al origen del dato con mejores sistemas, mejores administraciones y
mejor visibilidad del valor de buen dato.
Muchas veces al publicar los datos incompletos la gente ve lo valioso que sería contar con
datos de mejor calidad. De esta forma el DW puede jugar un rol clave en los esfuerzos de
reingeniería del negocio de una organización.
- Debe ser una fuente de información adaptable y flexible a los cambios.
El DW debe estar diseñado para manejar los cambios continuos de las necesidades de los
usuarios, las condiciones del negocio, los datos y las tecnologías. Los datos y aplicaciones
existentes en el DW no deben sufrir modificaciones cuando se agregan nuevos datos y/o
nuevas preguntas a realizar.
- El DW debe ser un lugar seguro donde la información se encuentre protegida.
El DW contiene información muy valiosa para la organización. Es necesario que existan
controles de acceso efectivo a los datos. También se debe permitir a sus dueños visualizar
los usos y abusos de los datos, incluso luego de haber abandonado el DW.
- Debe ser la base para la toma de decisiones.
El DW debe contener los datos correctos para soportar la toma de decisiones. Hay sólo
una verdadera salida del DW: las decisiones que son tomadas a partir de él. El DW tendrá
más valor cuanto más impacte en las decisiones del negocio. Recordar que el DW surge
para constituirse como la parte central de un sistema para la toma de decisiones que es lo
que finalmente se está tratando de construir.
- Debe ser aceptado por la comunidad usuaria para considerarse exitoso.
No importa si la solución construida es elegante y usa los mejores productos y plataformas
si el DW no se utiliza para el propósito que fue concebido. Su uso muchas veces es
opcional, a diferencia de los sistemas operacionales donde los usuarios están obligados a
16
Capítulo 2 -
utilizarlos. La aceptación de los usuarios de estas herramientas pasa por la simplicidad
sobre todas las cosas.
Si la comunidad del negocio no adopta al DW y continua usándolo activamente seis meses
después del entrenamiento, entonces habrá fallado el test de aceptación.
De esta lista es fácil ver que para poder implementar exitosamente un DW se requiere
mucho más que un buen equipo técnico. Es necesario conocer las reglas del negocio, involucrar a
los usuarios y contar con datos de buena calidad. Se requiere conformar un equipo de trabajo con
diferentes perfiles para lograr éxito en el proyecto.
2.4 Entorno del Data Warehouse.
La figura 3 presenta un esquema con los principales componentes que definen el marco
para un DW . Como se mencionó anteriormente el DW es el núcleo de toda la arquitectura de un
DSS.
Fuentes de datos(Sistemas
operacionales y datos externos)
Área de limpieza y transformación de
datos (Data Staging Area)
Área de almacenamiento y presentación de datos
(DW y Data Marts)
Área de análisis de información(Herramientas de acceso a los datos, aplicaciones de usuario
final)
Figura 3. Arquitectura técnica de un sistema para la toma de decisiones basado en un DW.
A continuación se dan las definiciones para cada componente del entorno, tomando como
base bibliográfica [Kim1998], [Kim2002], [Inm2002], [10], [11], [12] y [13]. Los elementos se
presentan en el orden en que se desarrolla esta cadena que conduce al conocimiento, que
comienza con los productores de datos y finaliza en los consumidores de información.
Antes de describir a cada elemento se aclara que el gráfico de la figura 3 es una
adaptación propia de los vistos en la bibliografía y demás referencias consultadas y está basado
principalmente en la propuesta de [Kim2002] [Kim1998]. Se puede observar la correspondencia
con los niveles de información planteados en la figura 1. Esta arquitectura también concuerda la
arquitectura “La Fábrica de Información Corporativa” (CIF)7. La propuesta de Kimball no coincide 7 Ver gráficos en referencias [10] y [11] de la sección de bibliografía.
17
DATOS INFORMACIÓN CONOCIMIENTO
DW
E
E
E
E
Servicios: limpieza, combinación y estandarización. Ajustar dimensiones comunes.No hay servicios de consultas de usuarios.Almacenamiento de datos: archivos planos y tablas relacionales.Procesamiento: ordenamiento y procesamiento secuencial
CARGA
ACCESO
Reportes
Alertas
OLAP(interfaces)
Scorecards & Dashboards
Data Mining
Proceso ETL
Capítulo 2 -
en la forma de plantear la existencia física del DW y los Data Marts como subconjuntos de este,
sino que inversamente plantea la existencia de Data Marts y el concepto de DW como unión de
estos, que deben basarse en hechos (facts) y dimensiones acordadas.
La visión de Inmon es más integradora, considera al DW como la fuente central de
información y a partir de donde se construyen los Data Marts para los sectores. Por su parte
Kimball plantea que en principio el desarrollo de un DW puede tornarse una tarea de dimensiones
infinitas, y sugiere comenzar con el desarrollo de Data Marts teniendo en mente la construcción de
un DW como unión de estos (desarrollo bottom-up). Ambas propuestas son válidas y dependerá
del problema particular cuál puede resultar más apropiada. Si el diseño de los Data Marts está
bien pensado puede construirse un DW a partir del trabajo realizado, y se van obteniendo
resultados a corto plazo. La definición de dimensiones y hechos conformados es esencial para el
éxito a largo plazo de esta metodología de trabajo.
Se observa que el gráfico de la figura 3 no considera un aspecto importante como es la
retroalimentación en lo que respecta a la calidad de datos. El análisis de determinada información
generalmente genera nuevas necesidades. Cuando se profundiza en la información que se quiere
obtener se detectan gran parte de los problemas de calidad existentes, especialmente en los
datos. Esto debe trasladarse a los sistemas fuentes y realizar las correcciones necesarias para la
evolución del sistema. Esta retroalimentación y evolución es un proceso cíclico.
Fuentes de datos
Los sistemas operacionales son las fuentes de datos principales donde se registra toda la
gestión de la organización. Son los sistemas centrales que soportan las operaciones diarias del
negocio. Se acceden a través de las interfaces de las aplicaciones (APIs). Los datos que recopilan
estos sistemas son la principal fuente de información del DW. También se los conoce como
sistemas transaccionales o sistemas heredados.
El éxito o fracaso de toda la solución de DW depende fuertemente de que los sistemas
operacionales provean los datos necesarios para entender el negocio y la historia necesaria para
evaluar su evolución. La calidad de los datos de estos sistemas es fundamental.
Otras fuentes pueden ser datos externos a la organización (información demográfica,
crediticia, financiera, etc. por ejemplo la cotización de alguna moneda), planillas de cálculos, etc.
Limpieza y transformación de los datos
Se utiliza el término “data staging area” para referirse al área de almacenamiento y al
conjunto de procesos que limpian, transforman, combinan, estandarizan, archivan y preparan los
datos de origen para ser usados en el DW. Es donde se realiza el proceso de transformación de
datos. Las tareas principales de esta área son el ordenamiento y procesamiento secuencial de
datos.
18
Capítulo 2 -
Este componente no provee ningún servicio de consulta ni presentación de información,
simplemente porque esta área no está pensada ni preparada para brindar la seguridad y tiempo de
respuesta propios del área de almacenamiento o presentación de datos. La forma de
almacenamiento utilizada es en general la de archivos planos.
Una tarea dentro de esta área es el aseguramiento de la calidad de los datos. Es para ello
que se testea la consistencia, completitud e idoneidad de los datos a ser publicados a la
comunidad usuaria. La creación de índices es otra tarea que también puede considerarse parte de
esta etapa de gestión de datos.
El proceso de Extracción, Transformación y Carga de datos
El término popular ETL corresponde a la sigla en inglés de “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 organización y el área de almacenamiento y presentación de datos. Aporta los métodos y
herramientas necesarias para mover datos desde múltiples fuentes, limpiarlos, reformatearlos y
cargarlos en un DW o Data Mart. En ese momento los datos quedan disponibles para ser
analizados por los usuarios. Otros nombres que recibe este proceso son “gestión de los datos”,
“adquisición de datos” y en inglés “data staging” o “data cleansing”.
Cabe destacar que la integración y transformación de datos es uno de los procesos más
importantes de todo el entorno del DW. Tiene la tarea crítica de convertir el caos de datos del
mundo operacional en un mundo ordenado de información. Este proceso asimila datos
procedentes de tecnologías heterogéneas dentro de un entorno integrado y consistente, apto para
ser consumido por los procesos de soporte de decisiones.
Uno de los mayores desafíos se produce cuando los datos recibidos provienen de fuentes
que los han organizado alrededor de claves diferentes. Por ejemplo en el SIU-Guaraní una
persona se identifica por el número de inscripción dentro de una unidad académica. En el SIU-
Pampa8 la identificación de la persona se hace por su número de legajo. Estas fuentes necesitan
ser integradas para dar una visión única de persona. Este proceso puede involucrar sofisticadas
reglas de mapeo de elementos, normalizaciones y estandarización de nombres, direcciones y
otros datos comunes a las fuentes para determinar cuales son los datos válidos.
El nivel de esfuerzo necesario para integrar y transformar datos está fundamentalmente
afectado por el nivel de conocimiento que se tenga sobre estos. Cuanto más familiar resulten los
datos operacionales y los procesos que los producen más fácil resultarán estas tareas. El proceso
ETL en general tiende a ser subestimado, sin embargo es altamente demandante y puede abarcar
la mayor parte del tiempo de desarrollo de un DW, ocupando hasta el 80% del tiempo en un
proyecto de gran magnitud. A continuación se detallan las tareas que incluye:
8 El SIU-Pampa es el sistema utilizado en las universidades para la gestión de recursos humanos y la liquidación de sueldos.
19
Capítulo 2 -
- Limpieza de datos. Consiste en la corrección de errores de tipeo, resolución de dominios
conflictivos (por ejemplo una ciudad que es incompatible con el código postal), manejo de
datos perdidos (nulos o vacíos, referencias a datos que no existen), conversión a formatos
estandarizados, y resolución de inconsistencias.
- Selección de atributos que son útiles para el DW. Por ejemplo, si lo que se quiere analizar
es el rendimiento académico de los alumnos interesará saber, entre otras cosas, cuántas
materias aprueba por año. Puede resultar útil saber cuáles son esas materias y las notas
obtenidas; pero no interesará saber el número de acta y folio donde se registró esta
información ni el día en que el dato fue ingresado al sistema.
- Combinación de fuentes de datos. Las fuentes se pueden combinar por medio de los
valores claves o realizando mapeos difusos (“fuzzy matches”) sobre atributos que no son
claves.
Este ejemplo surgió en el ámbito del SIU al integrar bases de datos del SIU-Guaraní de
diferentes unidades académicas de una universidad9. La información de colegios
secundarios era mantenida en forma independiente y no sincronizada en las diferentes
implementaciones. Cada unidad académica generaba sus propios códigos y nombres. Al
integrar los datos se hallaron casos como los mostrados en la figura siguiente.Unidad
académicaCódigo de
colegioColegio
correspondienteDescripción
utilizadaEjemplo
Facu1 Cod1 Cole1 Desc1Cole1 Escuela Normal Superior N°1Facu2 Cod1 Cole2 Desc1Cole2 Esc Sup de ComercioFacu2 Cod2 Cole1 Desc2Cole1 Esc Normal Sup Nro 1Facu1 Cod3 Cole1 Desc3Cole1 Normal Nro 1
Figura 4. Ejemplo de problema de calidad de datos.
- Crear claves. Asociar un nuevo identificador a cada registro de dimensión y evitar la
dependencia de las claves definidas en las fuentes. El proceso de generación de nuevas
claves sustitutas (o subrogadas) impone la integridad referencial entre las tablas de
dimensiones y las tablas de hechos10. Lo recomendable para las claves de dimensión es
que sean numéricas y secuenciales y totalmente independientes de las claves de los
sistemas operacionales.
El costo de todas las tareas descriptas depende en gran medida de la calidad de los datos
en los sistemas fuentes y apuntan a garantizar la calidad de los datos en el DW. La calidad debe
ser una línea conductora en todo el proceso de análisis de información y toma de decisiones. El
DW será actualizado con cierta frecuencia sobre la base de una carga controlada de datos
correctos. La carga de datos al DW recibe también el nombre de “carga en masa”.
La creación de agregados, esto es información agrupada que se guarda en el DW, así
como también la creación de índices pueden considerarse como parte del proceso de carga de
datos al DW. Estas tareas apuntan exclusivamente a resolver posibles problemas de performance.
9 En la mayoría de las universidades la implementación del SIU-Guaraní se realiza por unidad académica, contando así a nivel global con diferentes bases de datos independientes.10 Las definiciones de los conceptos de tablas de hechos y tablas de dimensiones están en el capítulo siguiente dentro de la sección de modelado multidimensional.
20
Capítulo 2 -
Almacenamiento y presentación de los datos
El área de almacenamiento y presentación de datos, también denominada servidor de
presentación es el lugar donde se ubican el DW y los Data Marts. En esta área los datos se
organizan y guardan para ser consultados en forma directa por los usuarios, generadores de
reportes y otras aplicaciones. Los datos deben ser presentados y almacenados en un formato
dimensional.
La definición de DW se presentó en la sección 2.2. Como se anticipó la definición clásica
ha dado origen a otros conceptos para adaptarse a las diferentes realidades. El término más
resonante es el de Data Mart. Un Data Mart es un subconjunto lógico del DW. Contiene datos
personalizados y/o sumarizados derivados del DW, confeccionados para soportar los
requerimientos analíticos de un determinado sector o función del negocio. Cada Data Mart utiliza
una visión empresarial común de los datos estratégicos y provee sectorizaciones más flexibles.
Entre las características de los Data Marts se destacan:
- Los Data Marts pueden o no localizarse físicamente en la misma máquina que el DW. Esto
permite a los consumidores de la información elegir la mejor tecnología que soporte el
estilo de análisis que necesiten.
- Los Data Marts deben ser implementados como una extensión del DW, no como una
alternativa. La estrategia a largo plazo dicta que es necesario contar con la infraestructura
completa para tener un DSS saludable.
- La construcción de Data Marts para soporte de decisiones es ideal. Sin embargo hay que
tener en cuenta que la simplicidad de su diseño puede conducir a tener mucha cantidad de
ellos implicando así un alto costo para administrarlos.
Kimball define a un Data Mart como “una porción de la torta completa que representaría el
DW”. Así mismo este autor presenta una metodología bottom-up comenzando por el desarrollo de
Data Marts para construir luego un DW como unión de estos. Argumenta que un Data Mart
representa un proyecto que puede llegar a ser terminado comparado con la “imposible
responsabilidad galáctica” de desarrollar un DW. Generalmente se ve al Data Mart como una
restricción del DW a un simple proceso del negocio o a un grupo de procesos del negocio
relacionados dirigidos hacia un grupo particular de usuarios.
En todo Data Mart se imponen requerimientos específicos de diseño. Todo Data Mart se
representa por un modelo dimensional y se construye a partir de dimensiones y hechos pactados11
para luego poder ser combinado y usado en conjunto con otros Data Marts (DW Bus Architecture).
Sin la adhesión a esta arquitectura un Data Mart se convierte en una solución específica y aislada
que no puede ser compartida con otras áreas del negocio en lugar de pertenecer a una solución
en conjunto. Si los Data Marts se diseñan con dimensiones y hechos conformados es posible
combinarlos y usarlos juntos [Kim1998]. Se dice que las dimensiones están conformadas o 11 Kimball utiliza el término fact (hecho) como sinónimo de medida o métrica. Debe interpretarse así cuando se hace referencia a hechos conformados o pactados. En general en este trabajo se utiliza el término “hecho” para referirse más bien al evento que tiene asociadas medidas, que a las medidas en sí.
21
Capítulo 2 -
pactadas cuando son exactamente iguales (incluyendo las claves) o una es un perfecto
subconjunto de la otra. Si dos dimensiones están conformadas pueden ser combinadas
perfectamente. Hechos o medidas de múltiples tablas están conformados cuando las definiciones
semánticas de estos son equivalentes. Si tienen esta característica pueden tener el mismo nombre
en tablas separadas y pueden ser combinados y comparados matemáticamente. Si los hechos no
concuerdan entonces cada interpretación debe recibir un nombre diferente.
No se cree que los dos puntos de vista sobre la construcción 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 diseñar 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 organización puede ser ensamblado a partir de Data Marts dispares y no relacionados.
Ninguno de estos extremos es prácticamente posible. La idea es entonces combinar ambas
propuestas, teniendo una arquitectura que guíe el diseño de todas las piezas separadas
[Kim1998].
Análisis de información
En la figura 3 se ejemplifican diferentes estilos de análisis de información. Estos estilos se
implementan con diferentes herramientas y aplicaciones. Todo esto forma parte del área de
análisis de información. Listados en texto plano y planillas de cálculo usadas para la toma de
decisiones también pueden incluirse dentro de esta área. A continuación se proveen las
definiciones de las herramientas más usadas para el análisis de información:
- Aplicaciones de usuario final. Se refiere así a la colección de herramientas que consultan,
analizan y presentan información buscada para soportar una necesidad del negocio. El
conjunto mínimo de estas aplicaciones de usuario consiste de herramientas de acceso a
datos, planillas de cálculo, paquetes gráficos, y facilidades de interfaz de usuario para
obtener simples presentaciones de pantalla.
- Herramientas de acceso a datos de usuario final. Se trata de herramientas que corren en
clientes y que sirven para consultar, buscar, o administrar datos guardados en el DW o
Data Marts. Pueden tomar la forma de editores de consultas SQL, cuya salida es en un
listado de datos en pantalla o un reporte o un gráfico. Una herramienta de acceso a datos
puede ser algo tan simple como una herramienta de consultas ad hoc como una
sofisticada herramienta de data mining. Este último tipo de aplicaciones resulta interesante
para detección de patrones y pronósticos.
- Herramientas de consultas ad hoc. Son un tipo especial de herramientas de acceso a
datos que invitan a los usuarios a diseñar sus propias consultas en el momento.
Es difícil tener un patrón de consultas cuando se utiliza análisis ad hoc. Por este motivo es
conveniente que el modelo de la base de datos sea lo más simétrico posible para que
todas las consultas luzcan igual. Esta es una fortaleza del modelado multidimensional de
un DW.
22
Capítulo 2 -
Este tipo de consultas tan poderosas pueden ser efectivamente usadas y entendidas solo
por el 10% de los usuarios potenciales del DW. El 90% restante de los usuarios
potenciales debe disponer de aplicaciones preconstruidas que ofrezcan modelos de
consultas (templates) en lugar de que el usuario deba construirlas.
- Aplicaciones analíticas. Se trata de aplicaciones de acceso a datos preconstruidas
previstas para usuarios que consultan el DW no muy frecuentemente. Típicamente
parametrizadas con flexibilidad para analizar innumerables combinaciones. Tales
aplicaciones representan una oportunidad de encapsular las mejores prácticas de análisis
de una organización. Aplicaciones para análisis de riegos, o análisis de mercados son
algunos ejemplos.
- Aplicaciones estadísticas. Son aplicaciones establecidas para realizar análisis estadísticos
difíciles y complejos como análisis de excepciones, medias, promedios y patrones. El DW
es la fuente de datos para estos análisis. Estas aplicaciones analizan cantidades masivas
de datos detallados y requieren un entorno razonablemente eficiente.
- Aplicaciones de modelado. Incluye a una variedad de aplicaciones cliente sofisticadas, con
capacidades analíticas que transforman o resumen la salida del DW. Dentro de estas
aplicaciones se encuentran, entre otras:
Modelos de pronóstico (forecasting) que buscan hacer predicciones
analizando comportamientos pasados.
Modelos de clasificación de comportamientos (clustering) que agrupan y
clasifican perfiles. Por ejemplo, en el ámbito universitario se podría agrupar alumnos
según características personales, demográficas o socio económicas.
- Minería de datos. Son un tipo de consultas indirectas que buscan encontrar patrones
ocultos en los datos. Los resultados más valiosos son agrupamientos, clasificaciones,
estimaciones, predicciones, y asociaciones de cosas que ocurren juntas12. Hay muchos
tipos de herramientas para minería de datos. Las principales incluyen árboles de decisión,
redes neuronales, razonamiento basado en casos o reglas de asociación, herramientas de
visualización, algoritmos genéticos, lógica difusa, y estadística clásica.
Esta área también recibe el nombre de descubrir conocimiento en bases de datos KDD
(Knowledge Discovery in Databases).
2.5 Aplicaciones tradicionales versus aplicaciones para análisis de información
Para finalizar la descripción del entorno del DW y antes de desarrollar las perspectivas y
técnicas necesarias para diseñarlo, hay que resaltar una característica importante: el DW es muy
diferente a los sistemas transaccionales u OLTP. Las diferencias radican en: los objetivos
principales de construcción, el perfil de los usuarios y sus necesidades, los datos que contienen
12 Un ejemplo típico en el análisis de compras en supermercados es el patrón que indica que “las personas que compran pañales compran cerveza”. Este tipo de resultados sirve para decidir la distribución de las góndolas.
23
Capítulo 2 -
(resaltando diferentes aspectos de estos: orientación o alineación de su estructura, integración e
historicidad), el acceso y manipulación de datos (patrones de uso, ritmos de carga de datos,
administración de datos, etc.). También difiere el hardware, el software, la administración y la
gestión del sistema. Todo esto hace que las técnicas e instintos de diseño apropiados para el
procesamiento de transacciones sean inapropiados.
Es importante resaltar las diferencias entre ambos ambientes pues, la mejor manera de
entender OLAP, es entender las diferencias con los sistemas transaccionales tradicionales
[Mst2005].
Caracterización de las diferencias
Sobre los objetivos principales
Los OLTP tienen como objetivos asistir a aplicaciones específicas, y mantener la
integridad de los datos. Mientras que los OLAP apuntan a asistir en el análisis del negocio,
identificando tendencias, comparando períodos, gestiones, mercados, índices, etc. mediante el
almacenamiento de datos históricos.
Sobre el perfil de usuarios
El perfil del usuario que interactúa con los sistemas OLTP se encuadra dentro de los
empleados operativos de una organización. Los usuarios de un OLTP hacen que la compañía
funcione. Tienen como función principal la entrada de datos. También realizan consultas a nivel de
un registro por vez. Los usuarios OLTP realizan las mismas tareas una gran cantidad de veces.
Por el contrario, dado el objetivo estratégico y el nivel de información que manejan los DW,
el perfil del usuario sobre este tipo de sistemas corresponde a la comunidad gerencial, la cual está
a cargo de la toma de decisiones. Los usuarios de un DW miran como funciona la organización y
definen el rumbo a seguir. Miran qué datos son nuevos, piden que los datos erróneos sean
corregidos. Los usuarios de un DW casi nunca consultan por un registro en particular, usualmente
requieren que cientos o miles de registros sean buscados y sean comprimidos en un pequeño
conjunto de datos de respuesta. Estos usuarios cambian continuamente los tipos de preguntas.
Aunque la estructura de las consultas es similar el impacto en la base de datos varía en ir a buscar
de cientos a millones de registros para ser resumidos en el pequeño conjunto de respuesta.
Sobre los datos
Los datos existentes en el ambiente transaccional difieren de los del entorno analítico en
las siguientes características:
- Alineación de los datos: los OLTP están alineados por aplicación. Diferentes sistemas
tienen distintos tipos de datos, los cuales son estructurados por aplicación. Se focaliza en
el cumplimiento de requerimientos de una aplicación o una tarea específica.
24
Capítulo 2 -
En cambio, los sistemas OLAP están alineados por dimensión. Todos los tipos de datos
están integrados en un solo sistema. Los datos son organizados definiendo dimensiones
del negocio (áreas temáticas o sujetos). Se focaliza en el cumplimiento de requerimientos
del análisis del negocio.
- Integración de datos: los datos típicamente no están integrados entre los diferentes
sistemas OLTP. Son calificados como datos primitivos o datos operacionales. Son
estructurados independientemente uno de otros, pudiendo tener diferentes estructuras de
claves y convenciones de nombres.
En los ambientes OLAP, los datos deben estar integrados. El DW, con el objetivo de
alinear los datos por áreas temáticas, necesita integrar datos operacionales
estandarizando estructuras y convenciones de nombres.
- Historia: Los OLTP usualmente retienen datos por un período de tiempo determinado,
después son resguardados en almacenamientos secundarios fuera de línea. También es
común que contengan sólo valores corrientes, referentes a la situación actual, y no valores
históricos. Puede no incluir el tiempo como un componente de la clave.
En cambio los OLAP almacenan tanta historia como sea necesario para el análisis del
negocio. Retienen los valores de cada período. Es decir, almacenan una serie de fotos
instantáneas de datos operacionales. La frecuencia con la cual se define el nivel de detalle
es la que se indica como nivel más bajo de la dimensión tiempo. Toda esta cantidad y tipo
de historia apunta a ayudar a la generación de reportes de comparación de tendencias y
períodos de tiempo.
Por otro lado, las bases de datos orientadas al análisis siempre contienen el tiempo como
clave dado que una de las principales razones para la construcción del DW es el
almacenamiento de datos históricos y el análisis a lo largo del tiempo.
Sobre el acceso y manipulación de los datos
Las diferencias de ambos ambientes en los objetivos, usuarios y datos implican
naturalmente que tanto el uso como la administración de los datos sean diferentes. Se pueden
destacar los siguientes puntos:
25
Capítulo 2 -
- Ritmos de actualización
Un sistema OLTP típico, como puede ser un sistema de venta por menor en un
supermercado, un sistema de reserva de vuelos, o un sistema para cajeros automáticos,
etc. procesa miles o incluso millones de transacciones por día. Cada transacción contiene
una pequeña pieza de datos.
Un sistema OLAP procesa una única transacción diaria que contiene miles o incluso
millones de registros. En lugar de llamarse transacción se la denomina carga de datos de
producción o copia masiva.
- Patrones de uso
Los sistemas transaccionales normalmente mantienen un patrón de uso constante
requiriendo grandes cantidades de recursos y consumiendo sólo el tiempo referido a la
transacción.
En contraposición, los DW tienen un patrón de uso liviano con picos de usos eventuales
en el tiempo. Los picos de uso suceden cuando los datos nuevos están por primera vez
disponibles y los días en que el negocio necesita determinados reportes.
- Manipulación de datos
Los sistemas operacionales realizan una manipulación de datos registro por registro con
funcionalidades de actualización de datos. Además necesitan de rutinas de validación y
operaciones a nivel de registro. Generalmente involucran pocos datos en un proceso o
transacción. Para el procesamiento de transacciones la base de datos dispara
mecanismos de bloqueos y asignación de recursos.
En cambio, los DW tienen una carga y acceso masivo a los datos y no se realizan ABMs.
La carga y refresco es batch. La validación de datos se realiza antes o después de la
carga. Principalmente se realizan consultas sobre varios registros y tablas, teniendo
grandes volúmenes de datos involucrados en un único proceso o análisis. Es por ello que
generalmente no se respetan las formas normales tan necesarias en los sistemas
operacionales clásicos. Las anomalías que tienden a subsanar estas reglas de
normalización no se presentan en los sistemas OLAP donde la carga de la información
está automatizada y puede permitirse el manejo de redundancia controlada como punto
para la mejora de los tiempos de respuesta de las consultas a la base de datos.
- Performance
Se requiere que el sistema OLTP sea eficiente para realizar las tareas repetitivas de la
comunidad operativa. No se permiten actividades “opcionales” que lo lentifiquen, como por
ejemplo ejecutar una consulta que agrupe 100.000 registros (al menos no se permiten
mientras el sistema transaccional esté siendo accedido por usuarios). La mayoría de los
reportes de un OLTP son listados de tablas enteras.
La administración de estos sistemas se basa en el aseguramiento de la performance y la
confiabilidad. Los procesos de extracción de datos para análisis suelen ejecutarse en
horarios en que el sistema operacional no está en producción.
26
Capítulo 2 -
La performance en un DW es tan importante como en un sistema OLTP, pero de una
forma diferente. Se esperan tiempos de respuesta rápidos a consultas agrupadoras de
datos que requerirían mucho tiempo para ser resueltas en un sistema OLTP. Se requiere
disponibilidad del sistema especialmente en determinados momentos y/o situaciones.
- Consistencia
Tanto el OLTP como el DW están altamente involucrados con la consistencia de los datos.
Sin embargo en los sistemas OLTP la consistencia es microscópica. Lo que importa es
que se hayan procesado todas y cada una de las transacciones que se presentaron al
sistema.
En un DW la consistencia se mide globalmente. Se cuida que la carga actual de datos
nuevos sea un conjunto completo y consistente de datos. En vez de una perspectiva
microscópica se tiene una perspectiva de aseguración de calidad. En lugar de un cálculo
técnico de consistencia existe una visión o juicio gerencial de esta. Se tiene cuidado sobre
los estados consistentes del sistema antes de comenzar la carga de datos de producción y
al finalizarla con éxito. Si forzadamente hubiera que detener una carga de datos de
producción antes de que esté completa, no se podrá volver atrás registro por registro; en
cambio habrá que sobrescribir el sistema entero con una nueva foto del sistema tomada
antes de que comience la carga.
Nivel de datos físico para análisis de información
En sus orígenes el término OLAP estuvo asociado exclusivamente a bases de datos
propietarias multidimensionales, también denominadas cubos13, que fue la arquitectura
predominante para DW durante la década del 80. Con la evolución de las bases de datos en
cuanto a funcionalidad y rendimiento a principio de los 90’s comienzan a desarrollarse DW en
motores de base de datos relacionales, dando origen a los conceptos OLAP multidimensional
(MOLAP), OLAP relacional (ROLAP) y OLAP Híbrido (HOLAP).
En la sección anterior se explicó en detalle los sistemas OLAP. Brevemente se puede
decir que se refiere a la actividad general de consulta y presentación de datos numéricos y de
texto desde el DW así como también el estilo dimensional de la consulta y presentación de la
información. El procesamiento analítico es el uso de los datos para tomar decisiones del negocio.
Frecuentemente involucra análisis de tendencias, comparaciones de períodos, y navegación de
datos.
El modelo lógico de los datos para OLAP debe seguir el diseño multidimensional. Sin
embargo la tecnología de la base de datos donde se implementa puede ser multidimensional o
relacional, dando origen a tres categorías de productos OLAP: MOLAP, ROLAP y HOLAP.
13 El concepto de cubo será presentado en el capítulo siguiente.
27
Capítulo 2 -
OLAP Multidimensional (MOLAP)
Refiere a una tecnología de bases de datos multidimensional y propietaria, también
denominada cubo de datos. La performance es la característica principal. Tanto los datos
detallados (o fuente) como los datos agregados o precalculados residen en el mismo formato
multidimensional. Optimiza las consultas, pero suele requerir más espacio de disco y diferente
software.
OLAP Relacional (ROLAP)
Es una tecnología que proporciona la misma funcionalidad que MOLAP con la diferencia
de que los datos son guardados en una base de datos relacional. La palabra que mejor describe a
ROLAP es escalabilidad, dado que puede cubrir un amplio conjunto de datos.
Tanto los datos precalculados y agregados como los datos fuente residen en la misma
base de datos relacional. Puede presentar problemas en los tiempos de respuestas cuando el
volumen de la información a agrupar es muy grande.
OLAP Híbrido (HOLAP)
Es una combinación de los anteriores. La palabra que describe a esta tecnología es
compromiso. Los datos agregados y precalculados se almacenan en estructuras
multidimensionales y los de menor nivel de detalle en una base de datos relacional. Requiere un
buen trabajo de análisis para identificar cada tipo de dato.
Comparación de las distintas implementaciones
ROLAP es una arquitectura flexible y general, que crece para dar soporte a amplios
requerimientos OLAP. MOLAP es una solución particular, adecuada para soluciones
departamentales con volúmenes de información y número de dimensiones más modestos.
Al momento de optar por una de estas tecnologías deberán evaluarse: la performance que
se necesita, el volumen de datos que se maneja, la escalabilidad y como se adapta la arquitectura
propuesta por cada proveedor a la realidad de la organización.
La tendencia del mercado de estas herramientas es hacia los sistemas HOLAP. Tanto los
proveedores clásicos de MOLAP como los ROLAP están incluyendo el otro estilo dentro de su
solución para abarcar las ventajas de ambos: gran capacidad de análisis y alta performance.
HOLAP está bien representado en la arquitectura de la figura 3, implementando el DW en una
base de datos relacional y la gran mayoría de los Data Marts como cubos multidimensionales, que
pueden estar conectados al DW mediante consultas prediseñadas para mostrar información más
detallada.
28
Capítulo 2 -
2.6 Tendencias en sistemas para análisis de información
El DW es el corazón de un DSS. El término DSS se suele usar como sinónimo de Data
Warehousing y de Business Intelligence. En un sentido estricto, las definiciones de estos
conceptos presentan algunas diferencias.
El término Data Warehousing se utiliza para referir al conjunto de herramientas,
tecnologías y metodologías que permiten la construcción, uso, manejo y mantenimiento del
hardware y software tanto de un DW como de los datos en sí mismos.
Un DSS es un sistema que colabora en las toma de decisiones gerenciales. Usualmente
involucra el análisis de muchas unidades de datos de una manera heurística. Un DSS da soporte a
los tomadores de decisiones en cualquier nivel gerencial, tanto en situaciones semi-estructuradas
y no estructuradas, a través de la combinación del juicio humano e información objetiva. De alguna
manera es el nombre precedente a Data Warehousing, y el hecho de usar los datos para tomar
decisiones en una organización es el fundamento de la existencia del DW. Como regla general, el
procesamiento DSS no involucra la actualización de datos, sino que sólo provee los mecanismos
de acceso a los datos que están en el DW y el análisis de estos.
Un DSS debiera estar basado en técnicas de Data Warehousing, pero ambos conceptos
tienen existencia propia. Durante mucho tiempo las organizaciones trabajaron con DSS pero no
tenían el volumen ni la calidad de información que brinda el DW.
Por otro lado, los DW pueden ser utilizados en sistemas expertos que guardan información
histórica. Las tareas de aprendizaje, como las de análisis predictivos, escapan el alcance del
concepto clásico de DSS y dan origen al término Business Intelligence (BI).
La inteligencia de negocio o inteligencia empresarial, hace referencia al conjunto de
estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el
análisis de los datos de la organización o empresa. Este conjunto de herramientas y metodologías
tienen en común las características de garantizar el acceso a la información con independencia de
la procedencia de los datos, brindar apoyo en la toma de decisiones, y estar orientadas al usuario
final, logrando independencia de los conocimientos técnicos. El desafío principal de BI es reunir y
presentar de manera organizada la información referente a todos los factores relevantes que
conducen el negocio y habilitar el acceso al conocimiento a los usuarios finales de manera fácil y
eficiente, con el efecto de maximizar el éxito de una organización. Existen cinco estilos diferentes y
complementarios de BI, a saber: [3] [4]
- Análisis OLAP. Es el BI más clásico y universal. Esta funcionalidad provee la forma más
sencilla de análisis, permitiendo que cualquier usuario pueda ver de manera minuciosa
subconjuntos de datos interrelacionados o cubos. Sirve para descubrir relaciones entre los
datos, analizar tendencias y realizar comparaciones históricas.
29
Capítulo 2 -
- Tableros de comandos y paneles de control (scorecards y dashboards). Proveen
facilidades de análisis sumariado y altamente repetitivo, en línea, focalizado en
determinados tópicos. Se basa en una serie de indicadores. Es apropiado para gerentes y
ejecutivos que requieren una visión integral del rendimiento del negocio y hacer
seguimientos exhaustivos a través del tiempo de temas especiales.
- Notificaciones de alertas y excepciones (broadcasting). Transmiten información a
diferentes puntos de la organización cuando determinados hechos suceden. Un análisis
que no es en línea.
- Reporte empresarial (enterprise reporting). Generación de información con alto nivel de
detalle para un nivel gerencial que se utiliza para tomar decisiones. Es el estilo de BI más
utilizado. El énfasis está en la parte gráfica. No es en línea ni como tableros. Lo que
importa es la presentación.
- Análisis avanzados y predictivos (data mining). Análisis estadístico de datos para generar
patrones predictivos, pudiéndose delegar parte de las decisiones al sistema. Brinda
capacidades completas y muy poderosas para investigaciones profundas de cualquier
sector y para encontrar los detalles que se esconden tras los resultados.
Desde el punto de vista técnico las áreas más importantes incluidas dentro de BI son [14]:
- DW – arquitectura, diseño, administración, procesamiento y carga.
- Limpieza de datos y aseguramiento de la calidad (incluye el proceso ETL).
- Data mining, análisis estadísticos y pronósticos.
- OLAP – procesamiento analítico en línea y análisis multidimensional.
- DSS, Sistemas de Información Ejecutiva (EIS), y otros sistemas expertos, agrupados en el
término de Gestión de Sistemas de Información (Management Information Systems o
MIS). Sistemas para analizar la información de otros sistemas y que sirve para la toma de
decisiones.
- Elaboración de reportes, visualización de información y paneles de control (dashboards).
- Gestión en relación con los clientes (Customer Relationship Management o CRM).
Otras definiciones utilizadas en sistemas de análisis de información:
- Sistemas de Información Ejecutiva (EIS: Executive Information Systems). Son sistemas
diseñados para los ejecutivos más altos de una organización. Entre las características más
importantes permiten análisis de desgranamiento (drill down) y de tendencias.
Un EIS es una herramienta de BI que permite monitorear el estado de las variables de un
área o unidad de la empresa a partir de información interna y externa.
Se puede considerar que un EIS es un tipo de DSS cuya finalidad principal es que el
responsable de un departamento o compañía tenga acceso, de manera instantánea, al
estado de los indicadores de negocio que le afectan, con la posibilidad de estudiar con
30
Capítulo 2 -
detalle aquellos aspectos que no estén cumpliendo con los objetivos establecidos en su
plan estratégico u operativo, y así determinar las medidas de contingencia más
adecuadas.
Una de las características más importantes de un EIS es que permite a usuarios con perfil
no técnico construir nuevos informes y navegar por los datos de la compañía, con el
objetivo de descubrir información que les resulte relevante. Esto se debe, entre otras
cosas, a que la interfaz gráfica de estas aplicaciones suele ser muy atractiva e intuitiva. El
EIS suele incluir también alertas de negocio, informes históricos comparativos y análisis de
tendencias.
Un EIS suele necesitar de un DW o Data Mart que actúe como fuente central de
información, unificando, depurando e integrando las distintas bases de datos
operacionales de la compañía [15].
- Fábrica de información corporativa (CIF: Corporate Information Factory). Es un modelo de
arquitectura propuesto por Inmon que contiene un DW, Data Marts, un almacén de datos
operativos (ODS), sistemas operativos, aplicaciones para soporte de decisiones, distintas
interfaces para usuarios, herramientas de data mining y demás componentes. Amplia la
arquitectura de la figura 3. Para obtener más detalles consultar referencias [10] y [11].
- Almacén de datos operativos (ODS: operacional data store). Un ODS es una colección de
datos orientada a temáticas (subject-oriented), integrada, con valores actuales y volátiles,
usada para soportar el proceso de toma de decisiones tácticas para una organización o la
administración del negocio.
Este concepto difiere del de DW por contener datos actuales en lugar de históricos y
volátiles en lugar de permanentes. Los DW y Data Marts están orientados principalmente a
soportar procesos de decisiones estratégicas. El ODS es el núcleo de la administración del
negocio (business management). Ambos conceptos se complementan.
No siempre es necesario implementar un ODS, sólo cuando se requiera acceso a datos
actuales en forma integrada. Esto es especialmente útil cuando hay muchos sistemas
operacionales que crecen en forma independiente unos de otros y necesitan consultarse
en forma integrada para obtener información.
La razón principal de un ODS es proveer reportes inmediatos y consistentes de resultados
actuales. Requiere soportar accesos operacionales constantes y actualizaciones, por eso
debe mantenerse en forma separada al DW. Juega un rol operacional, de tiempo real. Si
los objetivos son sólo prever reportes y soporte de decisiones hay que evaluar su
implementación y ver si estas necesidades no debieran ser cubiertas directamente por el
DW.
Como un ODS es necesariamente una extracción de datos transaccionales, este puede
también jugar el rol de fuente del DW.
31
Capítulo 2 -
2.7 El mercado de Data Warehousing y Business Intelligence
En los últimos años la utilización de este tipo de soluciones ha crecido muchísimo dando
origen a una expansión del mercado y desarrollo de diferentes herramientas. No es objetivo de
esta tesis realizar un análisis del mercado. Se presenta sólo un panorama muy general. Para
interiorizarse en las características de cada solución, que difieren bastante en arquitectura,
funcionalidad, interfaz con el usuario y costo, entre otras cosas, se pueden consultar [19] al [40]..
Se trata de un mercado variado. Existen tanto soluciones pequeñas y específicas como
otras abarcativas y ambiciosas, todas en continuo crecimiento e intentando cubrir mejor y más
aspectos dentro del área de BI.
Existen empresas de mediana escala que sólo desarrollan soluciones de BI (denominadas
“pure-play”), vendedores de mega-aplicaciones de software, y también soluciones pequeñas,
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 más fuertes en esta área, en parte por contar con otros productos
propios ya implementados en las empresas y por los costos de las soluciones BI que proponen,
que suelen ser menores que algunas soluciones puras, y además porque han comprado
soluciones ya existentes para incorporarlas a su empresa.
Los principales proveedores del mercado mundial son: Microsoft, Hyperion, Cognos,
Business Objects, MicroStrategy y SAP, en ese orden, según destaca “The Olap Report”, la revista
mundial en Business Intelligence [5].
En Argentina quienes se destacan como referentes internacionales de BI son Cognos,
Business Objects —son los más antiguos, operan desde los 80’— MicroStrategy, SAS y SPSS.
Cognos es muy fuerte en los Estados Unidos en empresas medianas y pequeñas, mientras que
Business Objects es líder en Europa. MicroStrategy es fuerte en sectores como venta por menor
(retail) y en grandes empresas. SAS y SPSS son tradicionales líderes en data mining. Y el
segmento en Argentina lo lidera MicroStrategy, seguido por Cognos, SAP, Oracle y Microsoft, en
este orden. La razón principal es el tiempo que llevan instalados en el país [3]. Otros proveedores
importantes son: IBM, Pentaho, QlikView y Stratebi.
La mayoría de los proveedores (denominados players o vendors) de estas soluciones se
han comenzado con uno de los estilos de BI, y luego fueron extendiéndose a los demás. Cuantos
más estilos abarca cada proveedor, obviamente brinda una solución más completa. La tendencia
es tener una solución completamente integrada que cubra todos los aspectos de BI, lo que en el
mercado se denomina suite o plataforma. Cognos y MicroStrategy se especializaron originalmente
en OLAP y Business Objects en tableros. Y desde hace unos años comenzó la carrera por sumar
los estilos faltantes. Algunos de los movimientos más resonantes fueron la compra de Crystal
32
Capítulo 2 -
Decisions (líder en enterprise reporting) que concretó Business Objects. Oracle compró Siebel,
Hyperion compró Brio, y Cognos a Adaytum y también a Applix. Y las más recientes e importantes
son la compra de Hyperion por Oracle, y la de Cognos por IBM junto con el acuerdo realizado
entre SAP y Business Object. También hubo cantidad de operaciones más pequeñas. Así como
algunas empresas compraron otras e integraron las soluciones, otras, como es el caso de
MicroStrategy, han desarrollado sus propias herramientas.
Como se puede observar, es un mercado en continuo movimiento, y la tendencia es que
las grandes empresas líderes en tecnología de información se consoliden también como líderes
del mercado de BI.
También se espera un importante crecimiento de Pentaho, que es el más completo de los
productos de software libre. El fuerte de esta herramienta está en la interfaz para manipular y
limpiar datos. Tiene diferentes módulos para desarrollo de cubos, reportes, tableros de control, y
data mining integrados. La solución es aún un poco dura en lo que respecta a funcionalidad e
interfaz con el usuario, pero es uno de los casos más prometedores por contar con licenciamiento
gratuito.
Para la implementación del caso práctico su utilizó O3 de la empresa uruguaya, con sede
en Argentina, IdeaSoft. Esta herramienta está disponible en el SIU para el desarrollo de este tipo
de soluciones y actualmente se está utilizando en aproximadamente 15 universidades nacionales
del país. Una de las ventajas de la herramienta es que permite una metodología de desarrollo
práctica y sencilla de implementar, además de tener un costo de licenciamiento accesible.
33
Capítulo 3 - El proceso de creación de modelos analíticos
3 El proceso de creación de modelos analíticos
En el capítulo anterior se detallan las diferencias de ambientes y objetivos entre los
sistemas OLAP y OLTP. Estas diferencias hacen que las técnicas de diseño y el modelo del ciclo
de vida clásico utilizados para desarrollar un sistema operacional no resulten apropiados para el
entorno analítico. En este capítulo se presentan las técnicas y metodologías principales para
garantizar el éxito de un proyecto de Data Warehousing.
3.1 Introducción al modelado multidimensional
El modelado multidimensional es una técnica para diseñar bases de datos simples y
entendibles. Se busca visualizar a la base de datos como si fuera un cubo de tres, cuatro, cinco o
más dimensiones. Cuando esto sucede, los usuarios finales pueden imaginarse “navegando” la
información contenida, realizando cortes (slicing and dicing14) a ese cubo a través de cada una de
sus dimensiones [Kim1996]. Los modelos multidimensionales brindan la habilidad de visualizar
datos en una forma concreta y tangible que facilita la comprensión de estos.
En un ejemplo simple aplicado al ámbito académico universitario: “los alumnos rinden
exámenes de diferentes materias en alguna fecha, registrándose la nota o resultado obtenido”; es
sencillo pensar este hecho como un cubo de datos, con etiquetas en cada una de las aristas del
cubo como se muestra en la figura 5.
Figura 5. Ejemplo de cubo sobre exámenes rendidos.
Cualquier punto dentro del cubo es la intersección de las coordenadas definidas por los
lados. Para el ejemplo los lados del cubo son nombrados: alumno, materia y fecha. Es posible
imaginar que en los puntos interiores es donde se guardan las medidas asociadas a la
combinación de alumno, materia y fecha, en este caso el resultado o nota.
14 Slicing y dicing se traduce como rebanar y cortar en dados. Refleja la acción de partir un cubo de información en cubos más pequeños para focalizar el análisis.
34
Capítulo 3 - El proceso de creación de modelos analíticos
Figura 6. Ejemplo de modelo dimensional sencillo sobre exámenes rendidos.
En la figura 6 se muestra el modelo dimensional que refleja la situación planteada,
mientras que en las figuras 7 y 8 se puede apreciar parte del modelo típico de dependencias entre
datos15, permitiendo la comparación entre ambos diseños.
Figura 7. Ejemplo de modelo de dependencias de datos del SIU-Guaraní referente a exámenes rendidos.
Las figuras 7 y 8 ciertamente revelan con más detalle las relaciones entre los datos que la
figura del modelo dimensional, pero no contribuyen al entendimiento la situación que describen16.
Desafortunadamente la mayoría de las personas no pueden retener en la mente un diagrama
como este y no pueden entender como navegarlo útilmente.
Para el problema de análisis de información, las relaciones existentes entre los datos se
ven mejor dinámicamente en una pantalla que en diagramas estáticos que el usuario trata de
mantener en su mente. Ambos modelos (dimensional y de dependencias de datos) de un negocio
son capaces de guardar exactamente los mismos datos, y son capaces de soportar exactamente
15 El modelo de dependencias de datos también es llamado a veces diagrama entidad relación (DER). Aunque no sean lo mismo. De hecho, también es posible usar un DER para representar un modelo dimensional.16 Se muestran sólo algunas tablas relacionadas con el ejemplo de todo el modelo de datos del SIU-Guaraní. El modelo de datos real es más complejo.
35
Dim_Materia
Dim_Fecha
Examenes
Dim_Alumno
Alumno_codMateria_codFechaNota
Alumno_codAlumno_desc
Materia_codMateria_desc
FechaMesAño
Capítulo 3 - El proceso de creación de modelos analíticos
el mismo análisis final. Es sólo que se elige presentar los datos de una manera diferente, en un
formato simétrico. En el ejemplo, el modelo dimensional provee un sentido natural para
descomponerlo en los componentes alumno, materia y fecha. Los usuarios usarán la palabra
dimensión en una conversación estén o no visualizando un cubo de datos. La atracción central del
modelo dimensional es su simplicidad, que permite a los usuarios entender las bases de datos,
que el software las navegue eficientemente y tiene la capacidad de adecuarse a los cambios.
Figura 8. Ejemplo de modelo de dependencias de datos del SIU-Guaraní.
Detalle de tablas principales sobre información de exámenes rendidos.
La distinción entre los modelos dimensionales y de dependencias de datos está centrada
en el diseño de un DW. Un DW debe ser construido desde la simple perspectiva dimensional en
lugar que desde la compleja perspectiva de las dependencias de datos para servir a su
propósito17.
Un modelo dimensional se basa conceptualmente en uno o más hechos. Cada hecho está
asociado a una o más medidas y a un conjunto de dimensiones18. Se implementa mediante un
conjunto de tablas. Las tablas pueden contener hechos (tablas de hechos), o descripciones de las
dimensiones (tablas de dimensiones, de búsqueda o de catálogo). Las tablas de hechos
relacionan dimensiones en su nivel de granularidad respectivo y contienen las medidas asociadas
a los hechos que describen.
El modelo multidimensional de un DW se compone de diferentes submodelos, también
dimensionales, que se corresponden con los diferentes Data Marts. Cada Data Mart debe tener al 17 El DW debe responder a un modelo lógico multidimensional, más allá de que sea implementado en una base de datos multidimensional (MOLAP) o en una relacional (ROLAP).18 En muchos textos no se distingue entre los términos hecho y medida, utilizándose el término “fact” para referirse a ambos. Aquí en general se utiliza el término hecho para referirse más bien al evento o suceso a medir que a la medida, o métrica en sí.
36
Capítulo 3 - El proceso de creación de modelos analíticos
menos una tabla de hechos, y en general tiene muchas tablas de dimensiones. También cada
tabla de hechos define en sí misma un submodelo dimensional que es parte de otros que lo
contienen.
Dimensiones, hechos y medidas
El modelo dimensional organiza y presenta los datos definiendo dimensiones. Las
dimensiones son líneas o áreas temáticas del negocio. Por ejemplo en un sistema de ventas, son
dimensiones producto, sucursal, tiempo. Representan a las entidades independientes que sirven
como punto de entrada para el análisis de la información. En el ámbito universitario y sobre el
análisis de comportamiento académico de alumnos se podrían considerar a las dimensiones:
carrera, lugar de procedencia, año de ingreso, entre otras.
Cada elemento de una dimensión tiene una clave, que lo identifica en el mayor nivel de
detalle y un conjunto de atributos. Los atributos representan categorías o agrupaciones de
elementos y tienen la finalidad de mostrar a la información de cada dimensión en diferentes
niveles de detalle y agrupar los elementos para ser analizados.
Las relaciones entre los atributos de cada dimensión determinan jerarquías. Las jerarquías
son ordenamientos lógicos y puede que exista más de una jerarquía dentro de la misma
dimensión, pero siempre podrá identificarse una jerarquía principal. Por ejemplo para la dimensión
lugar de procedencia, la clave está dada por la identificación del colegio. El colegio determina a la
localidad, la localidad a la provincia y esta última al país, presentando cuatro niveles de
granularidad para analizar a la información. La jerarquía principal (y única de esta dimensión) está
dada por los atributos país, provincia, localidad y colegio, en ese orden. En este caso la relación
entre los atributos, viéndola del nivel más detallado al más agrupado es siempre de muchos a uno.
Este tipo de relación padre-hijos en las jerarquías de atributos de una dimensión es el caso más
general, pero no el único.
Algunas de las soluciones, como es el caso de O3, tienen la limitación de permitir modelar
una jerarquía única por dimensión y donde los niveles deben estar determinados por relaciones de
tipo padre-hijos. En caso de necesitar representar diferentes jerarquías estas deberán modelarse
como dimensiones separadas19.
Los atributos de diferentes dimensiones se relacionan a través de hechos. Se consideran
hechos a sucesos o eventos que ocurren, como por ejemplo alumnos que cursan carreras, o que
rinden exámenes. Estos eventos generalmente están asociados a una o mas medidas.
Las medidas, métricas o indicadores son variables numéricas que ayudan a medir el
rendimiento de un negocio. Estas medidas pueden ser de dos tipos: básicas y derivadas. Las
medidas básicas existen dentro del DW junto a los atributos que las caracterizan. Pueden provenir
de diferentes fuentes, tener diferentes niveles de granularidad y estar determinadas por diferentes
19 Un ejemplo puede ser la dimensión producto, donde la jerarquía principal estaría dada por el código de producto, la línea, la categoría y el rubro, y además pueden existir jerarquías secundarias como el color o la marca.
37
Capítulo 3 - El proceso de creación de modelos analíticos
hechos o eventos. Por ejemplo la variable unidades vendidas puede definirse a nivel de día para la
dimensión tiempo mientras que la variable unidades en stock puede ser llevada semanal o
mensualmente. Las medidas derivadas se calculan a partir de las básicas y pueden o no estar
almacenadas físicamente en el DW. Un ejemplo de medida derivada podría ser el cálculo de las
ganancias a partir de las ventas menos los costos.
Navegación del modelo multidimensional
Se entiende por navegación o drilling a la acción de consultar datos dentro de un modelo
multidimensional. Estas facilidades están determinadas por las dimensiones y sus jerarquías, que
definen el mapa de caminos para la navegación de los datos. Existen distintos modos de buscar
información. Se utilizan términos específicos según el tipo de consulta que se realice:
- Navegar (drilling o slice and dice20) es la habilidad de acceder al DW o Data Mart a través
de sus diferentes dimensiones. Es el proceso de separar y combinar datos de una misma
manera.
- Agregar (drill-up o roll-up) es la acción de moverse hacia un atributo superior dentro de la
jerarquía de una dimensión (navegación ascendente, también denominada agregación
dinámica).
- Desagregar (drill-down o roll-down) es cuando se analiza información a mayor nivel de
detalle dentro de una dimensión (navegación descendente).
- Trasversar (drill-across) para analizar información de dimensiones acordadas sobre
diferentes hechos (navegación entre diferentes tablas de hechos, modelos o cubos).
También se utiliza este término para referirse a la navegación inter-dimensional.
- Atravesar (drill-through). Esto es cuando los Data Marts de tipo MOLAP se conectan al
DW a través de consultas predeterminadas para visualizar información con un grado de
detalle que no está incluido en el cubo.
La operación más común en análisis de tipo OLAP es el drill-down. La mayoría de las
herramientas brindan esta operación como la acción por defecto al seleccionar o hacer clic sobre
algún valor.
Tabla de hechos
Una tabla de hechos es una tabla primaria en cada modelo (o submodelo) dimensional
que contiene medidas del negocio. Cada medida es interpretada como la intersección de todas las
dimensiones que la definen. Toda tabla de hechos representa una relación muchos a muchos
entre las dimensiones y contiene un conjunto de dos o más claves foráneas que la vinculan a sus
respectivas tablas de dimensión. Las tablas de hechos representan los sucesos ocurridos. No se
debiera intentar llenarlas con ceros representando que nada ha sucedido.
20 El término slice and dice refiere a la acción de rebanar y cortar en cuadraditos un cubo de información.38
Capítulo 3 - El proceso de creación de modelos analíticos
El nivel de detalle de cada dimensión que se utiliza en la tabla de hechos define la
granularidad de las medidas. Las medidas más útiles son numéricas y aditivas. Pero no todas las
medidas son aditivas, existen medidas semi-aditivas y no aditivas. También es posible que la tabla
de hechos no contenga medidas y sólo represente las relaciones entre dimensiones.
Tablas de dimensión
Las tablas de dimensión son un conjunto de tablas compañeras o guías para una tabla de
hechos. Cada dimensión es definida por su clave primaria que sirve como base para la integridad
referencial con cualquier tabla de hechos a la cual se une. La mayoría de las tablas de dimensión
contienen muchos atributos o campos de texto que sirven para restringir y agrupar las consultas
del DW y determinan los niveles de análisis.
El objetivo de los atributos de las estas tablas es servir como filtros o encabezamientos de
las consultas de usuarios. Por ejemplo al consultar cantidad de alumnos de un determinado año
discriminados por carreras, la dimensión año se está usando como restricción, para filtrar un valor,
y la dimensión carreras como encabezamiento del reporte. Algunas veces un atributo numérico
puede confundirse con una medida. En estos casos hay que preguntarse si se usa para describir
una dimensión o para medir algo del negocio. El tamaño de un producto y la edad de un alumno
son ejemplos de atributos numéricos.
Hay tablas de dimensión que son íntegramente descriptivas. Otras, llamadas tablas de
catálogo o de búsqueda, además de contener las descripciones asociadas a la clave primaria, se
utilizan para representar relaciones entre dimensiones relacionadas. De esta forma se evita la
redundancia del dato en la tabla de hechos cuando el valor de una dimensión depende del valor
de otra (a estos casos se los denomina subdimensiones). Por ejemplo, si en la tabla de hechos se
representa la actividad académica de los alumnos y el identificador de persona se utiliza en la
tabla de hechos, datos como el sexo, la localidad de procedencia y otros que dependen de la
persona, y no de cada examen rendido, pueden guardarse en una tabla de catálogo y obtenerse
de ahí en lugar de estar repetidos en cada registro de la tabla de hechos. Es una forma primaria
de normalizar algunos datos para evitar redundancia y reducir el tamaño de la tabla de hechos21.
Esquema estrella
Cada tabla de hechos está entonces rodeada por un conjunto de tablas de dimensiones
que describen precisamente el contexto de cada registro medido. Por esta característica la
estructura de los modelos dimensionales es llamada esquema estrella .
Lo primero que se observa en el esquema dimensional resultante es su simplicidad y
simetría. Se ha demostrado que los modelos dimensionales son entendibles, predecibles,
extendibles y altamente resistentes para el análisis de información del negocio que se busca. La
21 Cabe aclarar que la estructura interna final de una solución MOLAP estará totalmente desnormalizada, sin embargo pueden considerarse algunas normalizaciones en las etapas intermedias de construcción.
39
Capítulo 3 - El proceso de creación de modelos analíticos
naturaleza simétrica 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 metodologías para construir un DW difieren claramente del clásico ciclo de vida de
desarrollo de sistemas operacionales. Mientras que este último está guiado por los requerimientos
de los usuarios, el desarrollo de un DW es conducido por los datos. Una vez que se identifican los
datos existentes, se los integra, se desarrollan las herramientas de explotación y finalmente se
atiende a los requerimientos de consultas de los usuarios. Más específicamente, la construcción
de un DW está guiada por las necesidades de los usuarios y por los datos existentes para
saciarlas.
La metodología para construcción de un DW más utilizada es la propuesta por Kimball,
que recibe el nombre de ciclo de vida dimensional del negocio o BDL (Business Dimensional
Lifecycle). Las etapas del BDL se ilustran en la figura 9. En el diagrama se puede observar la
secuencialidad, dependencia y concurrencia de las tareas. Las etapas no están temporalmente
organizadas, es decir no se determinan tiempos, plazos, ni duración de las tareas.
Figura 9. Ciclo de vida dimensional del negocio (BDL).
Hitos del mapa de ruta del BDL
El ciclo de vida de un DW comienza con la planificación del proyecto. Es en este momento
donde se evalúa la buena disposición de la organización para una iniciativa de Data Warehousing,
se establece el alcance preliminar, los recursos, y se lanza el proyecto. Luego, la gestión continua
del proyecto servirá para mantener el resto del ciclo de vida dentro de la planificación realizada.
La tarea siguiente se focaliza en la definición de los requerimientos del negocio. Observar
que existe una flecha con doble dirección entre la planificación del proyecto y esta etapa debido a
que hay mucha interrelación entre ambas actividades. La alineación del DW con los
requerimientos del negocio es absolutamente crucial. La mejor tecnología no salvará a un DW que 40
Planificación del proyecto
Selección de productos e instalación
Diseño de la arquitectura
técnica
Diseño de Requeri-mientos
Modelado dimensional
Diseño fisico
Diseño de las Extracciones y Transformacio-nes de Datos
Especificación de aplicaciones para usuarios finales
Puesta en producción
Manteni-miento y
crecimiento
Desarrollo de aplicaciones
para usuarios finales
Gerenciamiento del proyecto
Capítulo 3 - El proceso de creación de modelos analíticos
falla en focalizar en ellos. Los diseñadores del DW deben entender las necesidades de los
usuarios y trasladarlas en consideraciones de diseño. Los usuarios del negocio y sus
requerimientos tienen impacto en casi todas las decisiones de diseño e implementación a
realizarse durante el transcurso del proyecto de Data Warehousing.
En la figura se observa que siguiendo a la definición de los requerimientos se desprenden
tres líneas de trabajo paralelas. La línea superior tiene que ver con la tecnología. El diseño de la
arquitectura técnica establece el entorno general para soportar la integración de múltiples
tecnologías. Luego, en función de esta arquitectura se pueden evaluar y seleccionar los productos
específicos. Observar que la selección de productos no es una de las primeras actividades del
ciclo de vida. Es un error frecuente seleccionar productos antes de entender bien que es lo que se
está tratando de lograr.
La línea de trabajo del centro se focaliza en los datos. Se comienza trasladando los
requerimientos en un modelo dimensional que luego es transformado en una estructura física.
Durante las actividades de diseño físico se presta especial atención a las estrategias de puesta a
punto para lograr buenos tiempos de respuesta (performance tuning). Esta actividad incluye la
creación de agregaciones, índices y particiones. La última parte es la etapa donde se diseñan y
desarrollan los procesos ETL.
El tercer conjunto de tareas que siguen a la definición de requerimientos es el diseño y
desarrollo de aplicaciones analíticas. Estas aplicaciones son necesarias para completar el
proyecto de Data Warehousing y deben satisfacer un gran porcentaje de los requerimientos
analíticos de los usuarios del negocio.
Luego se unen la tecnología, los datos y las aplicaciones, junto con una buena dosis de
conocimiento y soporte, para realizar una implementación armoniosa. De ahí en más el
mantenimiento constante es necesario para asegurar que el DW y su comunidad usuaria se
mantengan saludables.
Finalmente el crecimiento futuro del DW se realiza iniciando proyectos posteriores. Cada
uno de ellos lleva a retornar nuevamente al comienzo del ciclo de vida [Kim2002].
Presentado el mapa de ruta general se pasará a describir con más detalle cada una de las
actividades de las etapas del BDL.
Planificación del proyecto
La planificación busca identificar la definición y el alcance del proyecto de DW, incluyendo
justificaciones del negocio y evaluaciones de factibilidad. Se focaliza sobre recursos, perfiles,
tareas, duraciones y secuencialidad. El plan resultante identifica todas las tareas asociadas con el
BDL y las partes involucradas.
41
Capítulo 3 - El proceso de creación de modelos analíticos
Antes de comenzar un proyecto de DW o Data Mart hay que evaluar la buena
predisposición para su realización. Debe existir la demanda. Se debe contar con al menos un
usuario sponsor sólido y con el entusiasmo de otros. El usuario sponsor debiera tener una visión
del impacto potencial del DW dentro de la organización. Otro factor crítico es la viabilidad: técnica,
de recursos, pero especialmente de datos. Si no se cuenta con datos de buena calidad el proyecto
fracasará.
Otro punto importante de esta etapa es la conformación del equipo de trabajo. Los perfiles
del personal afectado a la construcción de un DW son amplios y variados. Se requieren: usuarios
del negocio, sponsors, líderes, gerentes del proyecto, analistas, arquitectos, administradores de
bases de datos, diseñadores, responsables de extracción, desarrolladores, instructores, soporte
técnico, seguridad informática, programadores, analistas de aseguramiento de calidad, entre otros.
Definición de requerimientos
Otro factor determinante en el éxito de un proceso de Data Warehousing es la
interpretación correcta de los diferentes niveles de requerimientos expresados por los distintos
niveles de usuarios. Los diseñadores de los DW deben entender los factores claves que guían al
negocio para determinar efectivamente los requerimientos y traducirlos en consideraciones de
diseño apropiadas.
Los requerimientos del negocio deben determinar el alcance del DW (qué datos debe
contener, cómo debe estar organizado, cada cuánto debe actualizarse, quiénes y desde dónde
accederán, etc.) e impactan en todos los aspectos del proyecto.
La forma de relevar los requerimientos es entrevistando a los usuarios finales. Durante
este proceso los diseñadores descubren las necesidades y expectativas de la comunidad usuaria.
El proceso de entrevistas debe intercalarse entre grupos de usuarios del DW y grupo de técnicos
de los sistemas fuentes. A medida que se van planteando las necesidades de análisis se precisa
conocer si esas necesidades pueden satisfacerse con los datos y estructuras existentes. Las
entrevistas deben ser preparadas en función del perfil del usuario a entrevistar y no debieran durar
más de una hora. Una vez obtenidos los requerimientos, estos deberán ser priorizados y
consensuados con los usuarios.
Diseño de la arquitectura técnica
La arquitectura técnica es el anteproyecto para los servicios y elementos técnicos del DW.
Sirve para integrar las numerosas tecnologías.
En el capítulo anterior se presentó la estructura general de esta arquitectura. Dicha
estructura debe ser adaptada al caso a desarrollar, basándose principalmente en las necesidades
del negocio. Para establecer el diseño de la arquitectura técnica del ambiente de Data
Warehousing se deben tener en cuenta tres factores: los requerimientos del negocio, los
ambientes técnicos actuales y las directrices técnicas estratégicas planificadas a futuro.42
Capítulo 3 - El proceso de creación de modelos analíticos
Se puede hacer una analogía entre los planos arquitectónicos de una casa y la
arquitectura de un DW. Es necesario tener un plano de lo que se desea antes de comenzar, no se
trata simplemente de reordenar y explotar la información. Al igual que en una construcción, los
planos sirven para comunicar los deseos entre los clientes y el arquitecto, como así también para
medir esfuerzos y materiales necesarios para la obra (comunicación, planificación, flexibilidad y
mantenimiento, documentación, productividad y reutilización), y también serán de ayuda cuando
haya que remodelar o incorporar modificaciones.
La arquitectura técnica se divide en dos partes, la parte interna del DW (back room) y la
cara pública (front room), que interactúan constantemente. Mientras los requerimientos del
negocio indican qué se necesita hacer, la arquitectura técnica responde el interrogante de cómo se
hará [Mst2005].
Selección de Productos e Instalación
Utilizando el diseño de la arquitectura técnica como marco, es necesario evaluar y
seleccionar los componentes específicos como ser la plataforma de hardware, el motor de base de
datos, la herramienta de ETL o el desarrollo pertinente, herramientas de acceso, etc.
Una vez evaluados y seleccionados los componentes se procede con la instalación y
prueba de los estos dentro de un ambiente integrado [Mst2005].
Modelado Dimensional lógico
Una vez recolectados los requerimientos del negocio y habiendo auditado los datos
existentes en los sistemas operacionales están dadas las condiciones para comenzar con el
diseño del DW.
Diseñar los modelos de datos para soportar los requerimientos analíticos de los usuarios
requiere un enfoque diferente al usado en los sistemas operacionales. Básicamente se comienza
con una matriz donde se determina la dimensionalidad de cada indicador y luego se especifican
los diferentes grados de detalle (atributos) dentro de cada concepto del negocio (dimensión), como
así también la granularidad de cada indicador (variable o métrica) y las diferentes jerarquías que
dan forma al modelo dimensional del negocio, BDM (Business Dimensional Model) o mapa
dimensional.
En [Kim1998] se propone una metodología para construir modelos dimensionales que
comienza identificando los correspondientes Data Marts (como conjunto de indicadores) y las
dimensiones de estos. Luego sigue con la construcción de una matriz dimensional de alto nivel
(DW Bus Architecture Matrix). En la matriz se ubican a los Data Marts como filas y a las
dimensiones como columnas y se marcan las intersecciones de aquellas dimensiones que
intervienen en cada Data Mart. La metodología continúa con el diseño multidimensional de cada
Data Mart. Se definen cuatro pasos: primero la elección del Data Mart, segundo la declaración de
la granularidad, tercero la elección de las dimensiones y cuarto la elección de las medidas o 43
Capítulo 3 - El proceso de creación de modelos analíticos
indicadores. Además, recomienda un conjunto de diagramas que serán de gran ayuda en esta
etapa del proyecto: DW Bus Architecture Matrix, diagrama de tabla de hechos, detalle de tablas de
hechos y diagrama de dimensiones.
También el análisis de alto nivel de los sistemas fuentes colabora en mejorar las
estimaciones y alcances del modelo realizado. Una de las pautas que se resalta es la
comunicación y la validación del diseño entre el equipo de desarrollo del DW y la comunidad
usuaria.
Diseño Físico
El diseño físico de las base de datos se focaliza en la selección de las estructuras
necesarias para soportar el diseño lógico. En el modelado dimensional el diseño lógico y el físico
se asemejan mucho. Algunos de los componentes de esta etapa son la definición de convenciones
y estándares de nombres y seteos específicos del ambiente de la base de datos.
El diseño físico se enfrenta a las actividades de puesta a punto de la performance del DW
que consisten principalmente en la creación de índices y tablas agregadas. Las estrategias de
particionamiento son también determinadas en esta etapa.
Las agregaciones son la técnica de puesta a punto de mejor impacto sobre el tiempo de
respuesta de las consultas que efectuarán los usuarios. Este tema es abordado al final de la
próxima sección.
Otros puntos a resaltar de esta etapa son: planes de desarrollo del modelo físico,
convenciones de nombres y estándares, uso de sinónimos, uso de herramientas de modelado
para la generación y mantenimiento del modelo físico, estimaciones de volúmenes, planes y
estrategias de indexación, consideraciones sobre memoria y tamaño de bloque, parametrización,
particionamiento de tablas con gran volumen de datos, sistemas de tolerancia a fallas, monitoreo,
etc. En este trabajo no se profundizan estos temas. Se recomienda leer [Kim1998] junto con la
documentación particular del motor de base de datos que se decida utilizar.
Diseño de las Extracciones y Transformaciones de Datos
Esta etapa consiste del diseño y desarrollo del proceso ETL, descripto en el capítulo 2, y
es típicamente la más subestimada de las tareas en un proyecto de DW.
Todas las actividades de esta etapa son altamente críticas pues tienen que ver con la
materia prima: los datos. La calidad de los datos es un factor determinante en el éxito de cualquier
proyecto de análisis de información. Es en esta etapa donde deben sanearse todos los
inconvenientes relacionados con la calidad de los datos fuente. La desconfianza y pérdida de
credibilidad del DW serán resultados inevitables si el usuario encuentra información inconsistente.
44
Capítulo 3 - El proceso de creación de modelos analíticos
Son muchos los desafíos que deben enfrentarse para lograr datos de alta calidad de los
sistemas fuentes. Esta etapa siempre termina abarcando más tiempo del previsto, sobre todo lo
que refiere a la transformación de datos. Algunos ítems que ayudarán a guiar esta etapa del BDL
[Kim1998].
Plan:
- Crear un diagrama de flujo fuente-destino esquemático de muy alto nivel.
- Probar, elegir e implementar una herramienta de limpieza de datos. Se pueden utilizar
algunas de las que existen en el mercado para facilitar estas tareas y lograr una mejor
documentación que sea útil para futuras modificaciones22.
- Profundizar en detalle por tabla destino. Describir gráficamente las reestructuraciones o
transformaciones complejas. Ilustrar la generación de las nuevas claves sustitutas23. Y
realizar un desarrollo preliminar de la secuencialidad de los trabajos.
Carga de dimensiones:
- Construir y probar la carga de una tabla dimensional estática. La principal meta de este
paso es resolver los problemas de infraestructura que pudieran surgir (conectividad,
transferencia, seguridad, etc.)
- Construir y probar los procesos de actualización de una dimensión.
- Construir y probar las cargas de las restantes dimensiones.
Tablas de Hechos y automatizaciones:
- Construir y probar la carga histórica de las tablas de hechos (carga masiva de datos de
nivel atómico, sólo de tablas base). Esta tarea incluye la búsqueda y sustitución de claves.
- Construir y probar los procesos de cargas incrementales.
- Construir y probar la generación de agregaciones y/o de cubos MOLAP
- Diseñar, construir y probar la automatización de los procesos.
En [Kim2004] se encuentra un detalle de las técnicas y consideraciones a tener en cuenta
en la extracción, transformación y carga de los datos que formarán parte de las tablas de
dimensiones y de las tablas de hechos.
Especificación de Aplicaciones para Usuarios Finales
Las aplicaciones proveen el mecanismo clave para fortalecer la relación entre el equipo
del proyecto y la comunidad usuaria. Sirven para presentar el DW a los usuarios y para acercar a
los desarrolladores de aplicaciones las necesidades del negocio. Estas aplicaciones ayudan a
22 Existen herramientas de ETL en software libre, por ejemplo Pentaho.23 Este concepto se describe más adelante. Refiere a nuevas claves, diferentes a las de los sistemas operacionales, otorgadas a los elementos de las dimensiones.
45
Capítulo 3 - El proceso de creación de modelos analíticos
mostrar el valor del DW rápidamente, a facilitar el acceso de la mayoría de la comunidad usuaria y,
a través de los ejemplos, colaboran con los usuarios avanzados a construir reportes más
complejos.
No todos los usuarios del DW necesitan el mismo nivel de análisis. En esta etapa se
identifican los diferentes roles o perfiles de usuarios. En base al alcance de los diferentes perfiles
(gerencial, analista del negocio, vendedor, etc.) se determinan los distintos tipos de aplicaciones
necesarias. Existen usuarios con un perfil más estratégico, menos predecibles (power users),
usuarios netamente operacionales que consumen una serie de reportes estándares (final users),
usuarios gerenciales con uso de interfaces básicas (EIS users), entre otros. Mientras que algunos
usuarios aprovecharán al máximo las facilidades de análisis ad hoc, otros necesitarán aplicaciones
analíticas parametrizadas, más limitadas.
En general se requiere de la creación de aplicaciones estándar parametrizables. Estas
aplicaciones tipo plantilla para usuarios finales proveen el marco y la estructura de un reporte para
ser especializado por un conjunto de parámetros. El usuario selecciona los parámetros de una lista
o acepta los valores por defecto cuando ejecuta el modelo para crear sus propias versiones
personalizadas de ese reporte, con diferentes niveles de análisis y filtros de la información (por
ejemplo visualizar por mes en lugar de por trimestre, o elegir una determinada sucursal). Las
variantes de los reportes las resuelven los propios usuarios sin la necesidad de la intervención del
departamento sistemas y maximizando el tiempo de análisis por sobre el tiempo de construcción e
integración de la información. Este enfoque orientado a parámetros permite a los usuarios generar
docenas o potencialmente cientos de reportes de estructura similar. Todo esto de forma amigable
y con interfaces gráficas.
Es recomendable comenzar con la especificación de las aplicaciones tan pronto como se
finalice el relevamiento de requerimientos, cuando se tienen bien presentes las necesidades de los
usuarios, y documentar explícitamente . Algunas consideraciones para llevar adelante esta tarea
[Kim1998]:
- Determinación del conjunto de patrones iniciales (identificar reportes candidatos,
clasificarlos y priorizarlos)
- Diseño de la estrategia de navegación dentro de la aplicación (esquema de pantallas,
esquema de carpetas o directorios, criterios de agrupamiento -por datos, por dueño, por
regla del negocio-, etc.)
- Determinación de estándares (nombre y ubicación de los objetos, formato de las salidas)
- Detalle de las especificaciones (definición del nombre, descripción o propósito, frecuencia,
parámetros, restricciones, diseño, etc.)
46
Capítulo 3 - El proceso de creación de modelos analíticos
Desarrollo de Aplicaciones para Usuarios Finales
Esta etapa sigue a la especificación de las aplicaciones para usuarios finales El proceso
de desarrollo es bastante estándar excepto que se basa en la herramienta de acceso a datos que
se haya elegido. A lo largo del desarrollo es importante focalizar en los estándares de las
aplicaciones (convenciones de nombre, cálculos, librerías y codificación).
Esta etapa debiera comenzar una vez que existen datos en el DW (aunque no sean más
que datos de prueba), es decir pronto a finalizados el diseño lógico y el físico. El motivo es que al
desarrollar las aplicaciones pueden descubrirse problemas en la calidad de datos que no habían
surgido en la primera etapa del ETL y que obliguen a realizar modificaciones. También es el
momento de revisar las estrategias de optimización de performance probando los tiempos de
respuestas de las consultas. En [Kim98] se establecen las siguientes tareas como parte del
proceso de desarrollo de las aplicaciones:
- Selección de un enfoque de implementación. Decidir si la interfaz será web, o el acceso
será basado en herramientas de acceso directo, en interfaces ejecutivas, en interfaces
personalizadas, etc.
- Desarrollo de la aplicación. Definición de la herramienta de acceso a la meta data,
desarrollo de moldes y esquema de navegación de la aplicación, selección de reportes
que serán pre-ejecutados, etc.
- Prueba y verificación de datos. Testeo y verificación de descripciones, información
duplicada, relaciones entre atributos, consistencia e integridad de datos con sistemas
fuentes.
- Documentación y salida a producción. Retroalimentación con los resultados de la puesta
en producción
- Mantenimiento y monitoreo de performance.
Puesta en producción
La tecnología, los datos y las aplicaciones de usuarios finales convergen en esta etapa de
implementación. Desafortunadamente esta convergencia no sucede naturalmente y requiere ser
planificada.
Es muy importante que no se realice la implementación del DW hasta que los datos no
estén listos para ser mostrados. De todas formas no se necesitan sólo datos de buena calidad,
sino que hay varios factores extras que aseguran una correcta implementación del proyecto. Entre
estos factores se encuentran: la capacitación a los usuarios, el soporte técnico, la comunicación y
las estrategias de feedback. Todas estas tareas deben ser tenidas en cuenta antes de que
cualquier usuario pueda tener acceso al DW.
47
Capítulo 3 - El proceso de creación de modelos analíticos
La educación de los usuarios es uno de los pilares fundamentales de esta etapa y es un
requisito para el éxito del proyecto. Para cumplir exitosamente con esta tarea se recomienda que
el alcance de la capacitación contemple tres aspectos claves: el contenido del DW (los datos), las
aplicaciones y las herramientas de acceso. No debe realizarse sólo sobre las herramientas de
acceso. La educación sobre las herramientas es inútil al menos que se complemente con
conocimientos sobre el contenido del DW (cuáles datos están disponibles, qué significan, cómo se
usan y para qué usarlos). También es importante la metodología de presentación. Para los
usuarios finales no es fácil entender los límites entre las aplicaciones, los contenidos y las
herramientas. Para ellos el DW es un todo, por lo tanto la educación también debe reflejar la
misma perspectiva. Otro factor clave es la correcta capacitación por niveles según el perfil del
usuario (usuario final, power user, etc.).
El armado de un ambiente de capacitación es siempre recomendable. Dos buenas
premisas para el éxito del proyecto en esta etapa final del ciclo de vida: capacitar a los usuarios
finales sólo si el DW está listo y establecer la política de que si el usuario no recibió capacitación
no puede acceder a él.
El soporte técnico es la otra columna que ayudará a implementar con éxito el proyecto. Se
deberá definir claramente los niveles de soporte (a nivel aplicación, modelo, calidad de datos) de
forma transparente para el usuario. La documentación juega un papel importantísimo en la ayuda
a usuarios finales..
Respecto a la metodología de implementación es bueno seguir un esquema de
versionado. Primero se pasa por la versión Alpha, donde el grupo de trabajo conduce por primera
vez una prueba completa del sistema. Todos los componentes del sistema deben ser testeados
(infraestructura técnica, extracción, transformación, carga, procedimientos de calidad,
performance, moldes, etc.). Típicamente es de naturaleza iterativa y sólo puede decirse que se
termina esta versión cuando el grupo de trabajo confía plenamente en la calidad del DW como un
todo. Durante la etapa Alpha solo se provee acceso a un conjunto limitado de usuarios finales,
aquellos que pertenecen al grupo de trabajo.
Luego viene la versión Beta. El objetivo de esta versión es conducir una prueba a nivel
usuario de principio a fin. El grupo Beta está formado por los power users24. La cantidad de
personas que accederán al DW en esta instancia debe ser suficiente para asegurar que la
aplicación se probará adecuadamente.
Una vez superadas estas dos versiones se llega a un estado de disponibilidad general.
Toda modificación posterior debiera pasar internamente por un estado Alpha y Beta aunque
externamente sea una nueva versión.
Finalmente, la tecnología que reside en el escritorio del usuario es la última pieza que
debe ser ubicada antes de la salida a producción. Para asegurar que la infraestructura
24 Los power users son los usuarios que explotarán al máximo las capacidades del DW, haciendo uso de análisis ad hoc.48
Capítulo 3 - El proceso de creación de modelos analíticos
correspondiente al ambiente del usuario esté correcta y el producto entregado sea de calidad
debieran realizarse una serie de tareas antes de la implementación. Estas tareas incluyen:
configuración del hardware, conexión a las bases, acceso a intranet o internet, asignación de
direcciones de red, auditorias de tecnología sobre las configuraciones de las computadoras de los
puestos de trabajo, previsión de actualizaciones de hardware y software (determinación de
responsables, proyecto o área de usuario), verificaciones de seguridad (para acceder a la red y a
la base de datos), pruebas de procedimientos de instalación en una variedad de máquinas,
planificación de instalación, etc.
Mantenimiento y crecimiento
El desarrollo de un DW es un proceso de etapas bien definidas, con comienzo y fin, pero
de naturaleza espiral, pues acompaña a la evolución de la organización durante toda su historia.
Se necesita continuar con los relevamientos de forma constante para poder seguir la evolución de
las metas por conseguir. Al contrario de los sistemas tradicionales, los cambios en el desarrollo
deben ser vistos como signos de éxito y no de falla, porque a medida que los usuarios del negocio
utilizan el DW van requiriendo nuevos análisis.
Una vez que se ha construido e implementado el DW, rápidamente se debe estar
preparado para administrar el mantenimiento y crecimiento del mismo. Si bien las tareas pueden
llegar a parecer similares a las tratadas en otras etapas del BDL, existe una diferencia clave: los
usuarios están ahora accediendo al DW. Algunas consideraciones a tener en cuenta para
mantener exitosamente al DW: el continuo soporte y la constante capacitación a usuarios del
negocio, el manejo de la infraestructura (monitoreo de base de datos, tráfico, etc.), ajustes de
performance de las consultas, mantenimiento del meta data y procesos ETLs. Otros aspectos
involucran el monitoreo regular del cumplimiento de las expectativas (variables de medición del
éxito del proyecto que se habían fijado en la etapa de relevamiento), relevamiento de casos de
estudio (situaciones reales donde una decisión basada en información del DW tuvo impacto sobre
el negocio), constante publicidad interna del uso (permitiendo acceso siempre y cuando se tenga
la capacitación correspondiente) y constante comunicación con los sectores del negocio y de
sistemas para asegurar la buena salud del DW [Mst2005].
En cuanto al crecimiento del DW, un buen diseño está preparado para evolucionar y
crecer controladamente. Iterar sobre el BDL pasando nuevamente por cada una de las etapas
para administrar correctamente los cambios a incorporar. Es importante establecer las prioridades
para poder manejar los nuevos requerimientos de los usuarios. Es recomendable la creación de un
comité conformado por analistas del negocio y personas del área de sistemas que establezca
prioridades y procedimientos. El manejo de prioridades discrimina errores (los cuales deben ser
resueltos inmediatamente), y mejoras menores o mayores (clasificadas según el impacto en el
DW). Como mejoras menores incluye la incorporación de datos sencillos, nuevas agregaciones,
cambios en niveles superiores del modelo (atributos de alto nivel, lejanos a las tablas base).
49
Capítulo 3 - El proceso de creación de modelos analíticos
Dentro de las mejoras de mayor impacto se encuentran las que modifican o crean tablas bases o
atributos asociados a estas [Mst2005].
Gerenciamiento del Proyecto
El gerenciamiento del proyecto es trasversal a todo el ciclo de vida y asegura que las
actividades del BDL se lleven en tiempo y forma y de manera sincronizada. Como se indica en el
diagrama, el gerenciamiento acompaña todo el ciclo de vida. Entre sus actividades principales se
encuentran: la conducción del equipo de trabajo, el monitoreo del estado del proyecto, el
mantenimiento del plan y documentación, el manejo del alcance, y la comunicación entre los
requerimientos del negocio y las restricciones de los datos para poder manejar correctamente las
expectativas.
3.3 Técnicas para el modelado dimensional.
En [Kim1992] [Kim2002] se presentan temáticas de análisis típicas mediante las cuales se
ejemplifican cuestiones de diseño, algunas comunes y sencillas, otras más específicas y
complejas. No es intención de esta tesis abordar estas cuestiones detalladamente, sino presentar
las líneas generales más importantes. Varias de las técnicas se ejemplifican luego durante el
desarrollo del caso de estudio, donde también se resaltan las particularidades de la temática
elegida.
Tal como se mencionó previamente, el diseño de un esquema multidimensional consiste
básicamente de cuatro pasos:
- Seleccionar el proceso del negocio o asunto a modelar o Data Mart.
Un proceso es una actividad realizada en la organización y generalmente soportada por un
sistema fuente. Los procesos del negocio deben modelarse una única vez. No se deben
duplicar datos modelando una misma actividad según la perspectiva de análisis de los
diferentes departamentos de una organización.
Al presentar esta etapa de modelado dimensional dentro del BDL, se dijo que el diseño de
un DW comienza con la construcción de una matriz (DW Bus Architecture Matrix) donde
se establecen las relaciones entre indicadores (pertenecientes a algún Data Mart) y
dimensiones. Este primer paso consiste en elegir qué renglón o renglones de esa matriz
van a modelarse.
Dentro de la matriz, los diferentes Data Marts pueden solaparse. La cantidad de Data
Marts para una organización grande varía entre 10 y 30. Menos de 10 podría significar que
quedó muy amplia la definición de cada uno de ellos. Más de 30 o 40 es difícil de
mantener, por eso es recomendable juntar los que puedan unirse.
50
Capítulo 3 - El proceso de creación de modelos analíticos
- Manifestar la granularidad del proceso del negocio.
Declarar la granularidad significa especificar exactamente qué representa cada fila de una
tabla de hechos, manifestando el nivel de detalle asociado con las medidas que contiene.
Este paso es crítico. Declarar la granularidad inapropiadamente puede atormentar la
implementación de un DW y limitará el nivel de análisis. Cargar las tablas de hechos con
datos atómicos (el mayor nivel de granularidad posible) brinda la mayor flexibilidad porque
permite sumarizar los datos de todas las maneras posibles. En cambio, si la tabla de
hechos contiene información agregada algunas sumarizaciones pueden no ser válidas (por
ejemplo datos promediados).
- Elegir las dimensiones que aplican a cada registro de la tabla de hechos.
Las dimensiones surgen de la forma en que se describe el proceso del negocio. Estas
serán fácilmente identificadas si la granularidad está clara. Al elegir cada dimensión se
listan todos los atributos que proveerán el detalle de cada tabla de dimensión.
Ejemplos de uso común son fecha, producto, cliente, tipo de transacción, etc.
- Identificar las medidas para cada tabla de hechos.
Las medidas se determinan a partir de las métricas de rendimiento del proceso del
negocio seleccionado. Todas las medidas de una tabla de hechos deben tener la misma
granularidad. Si la granularidad de alguna es diferente (porque no está definida para
alguna dimensión, o lo está pero a otro nivel de detalle) esa métrica debe ser modelada en
una tabla de hechos separada. Las medidas típicas son numéricas y aditivas, como
cantidades o importes.
El entendimiento del negocio será necesario para definir las dimensiones y medidas del
modelo dimensional. Claramente deben considerarse tanto los requerimientos de los usuarios
como la realidad de los datos fuentes al tomar decisiones sobre los cuatro pasos descriptos.
Como cualquier técnica de modelado de datos, el desarrollo del modelo dimensional es un
proceso iterativo. Se deberá estar dispuesto a cambiar el modelo a medida que se aprende más
(de los requerimientos y de los datos). A medida que se avanza en el diseño, pueden identificarse
dimensiones nuevas, o descubrir que dos de ellas son sólo una. También es común realizar
cambios en la granularidad.
Elección del Data Mart
La metodología BDL propone comenzar por la construcción de un Data Mart.. La elección
del Data Mart a modelar en el más simple de los casos es elegir la fuente de donde se tomarán los
datos. Es recomendable elegir al principio uno que tenga una única fuente de datos en lugar de
múltiples para evitar los riesgos de afrontar tareas de extracción más complejas.
Se recomienda implementar los Data Marts en forma separada sólo en el contexto de
dimensiones y hechos acordados (conforme al DW Bus). A medida que se obtienen los diferentes
Data Marts estos deben poder ser ensamblados perfectamente como parte de un todo. Una de las 51
Capítulo 3 - El proceso de creación de modelos analíticos
responsabilidades mayores del equipo de diseño central del DW es establecer, publicar, mantener
e imponer las dimensiones acordadas.
Las dimensiones acordadas naturalmente serán definidas en el mayor nivel de
granularidad posible. También se recomienda que tengan una clave anónima (subrogada) en el
DW, diferente a las claves de los sistemas operacionales. Una de las razones de tener una nueva
clave es para poder manejar los cambios que podrían sufrir los valores de los atributos de las
dimensiones. La creación de las dimensiones acordadas es más una decisión política que técnica,
por lo tanto los ejecutivos de alto nivel deben alimentar su uso.
Las definiciones de los hechos (medidas) deben ser acordadas cuando se usa la misma
terminología a través de los Data Marts y cuando se construyen reportes con información
proveniente de más de uno de ellos. Si dos medidas reciben el mismo nombre deben significar lo
mismo. En el caso de las medidas calculadas la ecuación de cálculo debe ser equivalente. Las
medidas acordadas necesitan estar definidas en el mismo contexto dimensional y con la misma
unidad de medición para todos los Data Marts. A veces la unidad de medición de una métrica
difiere naturalmente entre las diferentes tablas de hechos. Por ejemplo el flujo de productos en un
negocio puede medirse en cantidad de unidades vendidas en el sector de ventas, y en cantidad de
pedidos enviados en el sector de envíos. En algunos casos se utiliza un factor de conversión, pero
en este ejemplo no sería apropiado, y es conveniente modelarlas como medidas diferentes. Si es
difícil o imposible acordar una medida entonces hay que asegurarse de darle nombres diferentes a
cada interpretación.
Luego de haber implementado varios Data Marts de una sola fuente es razonable
combinarlos en uno de múltiples fuentes. El ejemplo clásico es el Data Mart para análisis de
rentabilidad que combina los componentes separados de ingresos y costos.
Tablas de Hechos y Granularidad
Declarar la granularidad es un paso crucial en el diseño. Se recomienda elegir el nivel más
bajo de granularidad posible para lograr un diseño más robusto. Esto significa construir las tablas
de hechos básicas al nivel naturalmente más bajo de todas las dimensiones que las constituyen.
Un nivel muy bajo de granularidad es poderoso y flexible, es mucho mejor para responder nuevas
consultas inesperadas y para introducir elementos de datos nuevos. También el nivel más bajo de
granularidad es el que tiene el dato de la forma dimensional más natural (por ejemplo del ticket de
un cajero automático pueden identificarse las dimensiones tiempo, localidad, cuenta y tipo de
transacción). Es en el nivel más bajo donde la mayoría de los atributos de las dimensiones tienen
un único valor por registro. Por otro lado, trabajar con el nivel de datos más desagregado en el DW
servirá para hacer análisis de data mining y de comportamientos de clientes.
Los tres tipos de granularidad de tablas de hechos más útiles son: transacciones
individuales, fotografías (snapshots) periódicas (diarias, mensuales, etc.) y fotografías
52
Capítulo 3 - El proceso de creación de modelos analíticos
acumulativas (accumulating snapshop). Cada uno de estos tipos de tablas tiene características
particulares que se desarrollan a continuación.
Granularidad a nivel de transacción
La visión operacional del negocio más importante es a nivel de transacciones individuales.
El caso más sencillo de este esquema consiste en crear un registro en la tabla de hechos por cada
transacción individual (por ejemplo por cada operación de un cajero automático). Frecuentemente
cada registro contiene una única medida, que es el valor de la transacción. En muchos casos se la
llama importe (monto, o cantidad).
El diseño de un esquema de transacciones es más acotado en cuanto al crecimiento que
el de un esquema de fotografías. Se representan eventos que ocurren en un determinado
momento de tiempo, y una vez ocurrida la transacción se incorpora al DW y no se vuelve a visitar
a ese registro (no se lo modifica). Casi nunca se agregan medidas numéricas porque el sistema de
captura de transacciones usualmente sólo retorna un importe. Se pueden agregar nuevos tipos de
transacciones a la dimensión pero esto significa agregar datos no cambiar el esquema de la tabla.
El nivel de granularidad no necesariamente es el nivel de la transacción en sí, en algunos
casos se puede llegar a nivel de línea de ítem. Por ejemplo, para representar ventas mucha
información está en el encabezado de la factura (fecha, cliente, sucursal, etc.) que sería la
transacción, pero hay un nivel más detallado, el de línea de factura, que contiene el dato del ítem.
Para cada ítem existen las medidas cantidad de unidades e importe.
Al tener granularidad transaccional en el DW se permite analizar comportamientos al nivel
de detalle extremo. Esto no es posible si lo datos están agregados. Este nivel de información
permite realizar conteos de comportamiento (como por ejemplo cantidad de transacciones por
cliente), análisis de rangos horarios, encolamientos, tiempos entre transacciones, etc. El detalle de
las transacciones permite ver el comportamiento secuencial que se aplica para detección de
fraudes y advertencia de cancelaciones. Finalmente permite realizar análisis de canasta que
consiste en identificar asociaciones de elementos, por ejemplo productos que se venden junto con
uno determinado. Muchos de estos ejemplos son análisis típicos de data mining, que requieren
tener los datos en su máximo nivel de detalle.
La granularidad de nivel de transacción sin embargo no es la más apropiada para otro tipo
de análisis, como tener una vista del estado actual del negocio. Por ejemplo si se quiere saber los
ingresos no siempre es posible hacerlo sumando las transacciones, porque diferentes tipos de
transacciones impactan de formas distintas en este cálculo.
Esquema de fotografías
Fotografías periódicas son necesarias para ver el rendimiento acumulado del negocio a
intervalos de tiempo regulares y predecibles. En lugar de cargar una fila en la tabla de hechos por
cada evento que ocurre, se espera hasta el final del día, o del mes, y se captura la actividad que 53
Capítulo 3 - El proceso de creación de modelos analíticos
ocurrió durante ese período. Se dice que se toma una foto de lo ocurrido. Las fotografías tomadas
en cada período se van guardando en la tabla de hechos.
Este esquema de fotografías es más complejo que la perspectiva de transacciones
individuales. Pueden existir varias medidas de la actividad ocurrida durante el período capturado,
por ejemplo importe total de ventas, cantidad total de transacciones, cantidad de clientes que
realizaron alguna compra en el período, etc. Es importante que todas las medidas se refieran al
período corriente. Algunas medidas serán completamente aditivas y otras serán semi-aditivas,
como el balance de cuentas al momento que se toma la fotografía. Estos casos podrán ser
promediados a través del tiempo o tener algún otro método especial de agregación.
En algunos casos, como el de ventas por menor, es sencillo pasar de la perspectiva de
transacciones individuales a la foto diaria agrupando las transacciones a nivel de día.. Otras veces
el patrón de transacciones es muy complejo y la construcción de fotografías no es una simple
agregación. Por ejemplo en una contabilidad mensual el cálculo de las ganancias depende de
cómo contabiliza cada tipo de transacción (depósitos, pagos por adelantado, etc.). Las fotos
mensuales son requeridas en estos casos para obtener la información a ese nivel en forma rápida.
La granularidad a nivel de transacciones posibilita la vista total del comportamiento
detallado y a nivel de fotografías permite medir rápidamente el estado de la empresa u
organización. En muchos casos se necesitan ambas para lograr una vista completa e inmediata
del negocio.
Fotografías acumulativas
Las fotografías acumulativas (o acumuladas) representan un lapso de tiempo
indeterminado para cubrir la vida entera de una transacción o de un producto completo. Este
esquema es generalmente usado para seguimiento del estado de un ítem cuando atraviesa un
proceso en cadena, por ejemplo seguimiento de una orden de pedido. Este diseño sirve para
saber el estado actual de una orden y la velocidad en que un producto va superando las diferentes
etapas del proceso y permite identificar cuellos de botella e ineficiencias en la cadena del proceso
(de producción, de ventas y entregas, etc.).
La granularidad de estas tablas de hechos suele ser de un registro por cada línea de ítem
de un documento de control. Cada registro puede ser pensado como fotografías evolutivas de esa
línea de ítem que se van actualizando. Estas tablas de hechos tienen típicamente múltiples fechas
representando hitos en las fases por las que atraviesa la línea de ítem (por ejemplo fecha de la
orden de pedido, fecha de entrada a fabricación, fecha de fin de fabricación, fecha de envío a
sucursal, fecha de facturación, fecha de recepción del cliente, entre otras). También pueden existir
diferentes medidas asociadas a cada etapa.
Generalmente se necesita una dimensión de estado para guardar el valor actual de cada
ítem. En estas tablas cada registro se actualizará frecuentemente cuando se tenga nueva
54
Capítulo 3 - El proceso de creación de modelos analíticos
información disponible, para reflejar el estado y las métricas acumuladas. Esta es la diferencia
fundamental con los otros tipos de tablas.
A veces las fotos acumulativas se usan en conjunto con las fotos periódicas. Se puede
pensar en un DW que guarde fotos periódicas por mes y que lleve una fotografía acumulativa para
la información del mes en curso. En estos casos cuando finaliza el último día del mes la fotografía
acumulada pasa a ser una más de las fotos periódicas y se crea una nueva foto acumulativa para
registrar la actividad del nuevo mes a partir del día siguiente. La fotografía mensual se construye
de forma incremental, agregando el efecto de las transacciones diarias a una fotografía
acumulativa.
Comparación de los esquemas
En la siguiente figura se presenta un cuadro comparativo [Kim2002] respecto a estos tres
tipos de granularidad donde destaca las características más distintivas.
Característica Granularidad transaccional
Granularidad de fotografías periódicas
Granularidad de fotografías acumulativas.
Período de tiempo representado
Punto en el tiempo Intervalos regulares y predecibles
Lapso de tiempo indeterminado, típicamente de corta vida
Granularidad Una fila por evento transaccional
Una fila por período Una fila por “vida” (al nivel de detalle que se haga el seguimiento)
Tipo de cargas en tablas de hechos
Inserciones Inserciones Inserciones y actualizaciones
Actualizaciones en tablas de hechos
No No Se actualiza el registro cuando hay actividad.
Dimensión fecha Fecha de la transacción Fecha del fin del período Múltiples fechas para hitos estándares
Métricas Actividad transaccional Rendimiento para intervalos de tiempo predefinidos
Rendimiento sobre el tiempo de vida finito
Figura 10. Comparación de tipos de tablas de hechos.
Los tres tipos de granularidades vistos son útiles para diferentes propósitos. La
administración y ritmos de carga difieren bastante entre los tres tipos de tablas. Generalmente
será necesario tener dos tipos de tablas de hechos complementarios para lograr una imagen
completa del negocio. Estas tablas compartirán dimensiones acordadas, para poder ser usadas en
conjunto.
Familias de tablas de hechos
Para modelar muchos de los procesos del negocio es necesario considerar más de una
tabla de hechos. Un Data Mart puede constituirse como un conjunto coordinado de tablas de
hechos, todas con estructuras similares, no necesariamente de tipos diferentes, y sí con
dimensiones y medidas acordadas.
Hay diferentes razones para crear estas familias de tablas de hechos [Kim1998]:
55
Capítulo 3 - El proceso de creación de modelos analíticos
- Los casos ya mencionados de contar con tablas de diferente granularidad; por ejemplo
transaccional y de fotografías para poder realizar análisis detallado y a la vez tener una
vista del negocio rápida.
- La construcción de tablas con información agregada para resolver problemas de
performance.
- Modelar cadenas y círculos.
El caso de cadenas es cuando dentro del negocio existe un flujo que involucra que una
orden, producto, o cliente atraviese diferentes pasos. En general tiene sentido construir
una tabla de hechos separada para cada uno de los procesos. Las tablas de cada paso
pueden ser transaccionales o de fotografías periódicas, y estarán relacionadas por las
dimensiones y medidas comunes. Se habla de cadenas cuando los subprocesos o etapas
están naturalmente ordenados.
El caso de los círculos es cuando varias entidades están realizando o midiendo el mismo
tipo de transacciones. Un buen ejemplo es la gran organización de cuidado de la salud,
donde hospitales, farmacias, laboratorios, clínicas, compañías de seguro y otras entidades
rondan alrededor de los tratamientos de los pacientes.
- Esquemas de productos heterogéneos.
Este es el caso de negocios que manejan productos lo suficientemente diferentes que
dadas las características propias del tipo de producto deban ser modeladas en forma
separada, porque existan muchas dimensiones que no son comunes. Seguramente
también se incluya en el modelo una tabla base núcleo que cruce todas las líneas del
negocio para tener un análisis global por las dimensiones comunes. Un ejemplo puede ser
una empresa que ofrezca productos y también servicios.
Tablas de hechos sin medidas
Hay un tipo especial de tablas de hechos denominada factless fact tables por tener la
característica de no incluir medidas entre sus campos. Hay dos situaciones donde las tablas con
esta característica son muy útiles: para seguimiento de eventos y de cobertura.
Para el primer caso en la tabla de hechos se registra un evento por línea. Ejemplos típicos
de uso son el registro de asistencias y las inscripciones a cursos. Si se piensa en alumnos
universitarios inscribiéndose a materias la granularidad de la tabla será de una fila por cada
inscripción de un alumno a una materia en un período académico. El período será el nivel más
bajo disponible para la registración de eventos. Esta dimensión debe estar de acuerdo con la
dimensión de fechas.
Este tipo de tablas, compuestas sólo por claves de dimensiones es perfectamente una
tabla de hechos25 y es útil para responder preguntas como qué materias tienen mayor cantidad de
25 La existencia de las factless fact tables ha motivado la nomenclatura utilizada en este texto. Nótese la referencia a fact table como tabla de hechos, considerando hecho como suceso o evento en lugar de utilizarlo como sinónimo de medida o métrica al hacer mención a la tabla.
56
Capítulo 3 - El proceso de creación de modelos analíticos
inscripciones, cuál es la cantidad de inscripciones promedio por alumno y período, qué docentes
tendrán mayor cantidad de alumnos, cuál es el medio de inscripción más utilizado, etc.
Al analizar esta información pueden contarse dos cosas diferentes: por un lado la cantidad
de inscripciones y por otro la cantidad de valores diferentes de una dimensión en alguna consulta.
Por ejemplo: para un período determinado, se puede contar el total de inscripciones por carrera
(asumiendo que cada materia pertenece sólo a una carrera), como también la cantidad de
alumnos diferentes por carrera, sin importar en cuantas materias de la carrera se inscribe.
El segundo tipo de tablas de hechos sin medidas se utiliza para garantizar cobertura. El
mejor ejemplo es el caso de querer analizar las promociones de productos que están a la venta.
Sería deseable saber qué productos estaban en promoción y no se vendieron. Agregar la
información necesaria para este análisis en la tabla de ventas significaría la incorporación de
muchísimos registros con ceros representando los eventos que no sucedieron (todos los productos
que no se vendieron), lo que haría crecer enormemente el tamaño de la tabla. Es por eso que en
estos casos, cuando la tabla de hechos primaria es rala26, suele utilizarse este esquema de
cobertura. Se crea entonces una tabla donde se registran todas las promociones. La respuesta a
los productos promocionados y no vendidos se resuelve en dos pasos, primero se consulta cuales
estaban promocionados, y con ese resultado se busca en la tabla de ventas cuales no están
durante la vigencia de la promoción.
Otro ejemplo de cobertura puede ser el análisis de uso y disponibilidad de las
instalaciones de una institución. Para cada instalación se podría considerar datos como el edificio,
el tipo de instalación (aula, laboratorio, oficina), la capacidad, los servicios (pizarrón, proyector,
computadoras) y registrar para cada bloque horario si la habitación se encuentra disponible o no.
Diseño de las dimensiones
Una vez seleccionado el Data Mart a modelar y habiendo establecido las granularidades
correspondientes, el tercer paso del diseño multidimensional consiste en elegir las dimensiones
que aplican a cada tabla de hechos.
Diferentes características de las dimensiones deberán tenerse en cuenta al momento de
diseñar el modelo del negocio.
Descripción de los atributos
Es vital que las descripciones de los atributos de las dimensiones sean de alta calidad:
significativas, entendibles y prolijas. Estas serán mostradas en la interfaz con el usuario y usadas
como filtros en las consultas.
26 Rala significa poco densa considerando las combinaciones de los valores de las dimensiones que contiene respecto a todas las posibles.
57
Capítulo 3 - El proceso de creación de modelos analíticos
Claves de las dimensiones
Otra característica de diseño importante es que todas las dimensiones deben tener una
clave. Las claves de las dimensiones deben ser un sólo campo, numérico y secuencial, y son el
nexo entre las tablas de hechos y las dimensiones.
Se destaca que no deben usarse las mismas claves que en los sistemas operacionales,
sino que es necesario generar claves nuevas o sustitutas.
Esquema estrella vs esquema copo de nieve
Uno de los puntos más importantes a definir al modelar las dimensiones está relacionado
en gran parte con la implementación física. Se trata de la normalización o no de las tablas de
dimensión.
Algunas dimensiones constan de un único atributo, pero otras constan de varios atributos
que forman una jerarquía. Tal es el caso de la dimensión producto, donde se puede identificar la
jerarquía: producto, línea, categoría y rubro, por ejemplo, y de la dimensión ubicación geográfica
donde se identifican localidades, provincias y países, entre otros atributos.
En estos casos la dimensión se puede representar en una única tabla, donde reside toda
la información al nivel más bajo, o mediante un conjunto de tablas (a partir de las dependencias
existentes entre los atributos) que respeten la tercera forma normal27. El primero de los casos
corresponde a un esquema estrella (que consta de una tabla de hechos central y un montón de
tablas de dimensiones satélites). Al normalizar las dimensiones se dice que se transforma al
modelo estrella en un copo de nieve (también debido al gráfico de su estructura), y por eso a
veces se hace referencia a esta acción como snowflaking.
En la figura 11 se observa como podría ser la tabla de la dimensión “Ubicación”, con
“localidad_id” como única clave modelada en ambas formas.
Figura 11. Dimensión “Ubicación” desnormalizada vs normalizada.
27 La tercera forma normal es una forma de normalización de bases de datos, definida por E.F.Codd.58
Localidad_idLocalidad_descProvincia_idProvincia_descPais_idPais_desc
Localidad_idLocalidad_descProvincia_id
Provincia_idProvincia_descPais_id
Pais_idPais_desc
Capítulo 3 - El proceso de creación de modelos analíticos
Es claro que la tabla desnormalizada contiene mucha redundancia de datos. También es
claro que en el esquema normalizado se necesitará realizar varias uniones entre tablas para
obtener la información del DW agrupada a niveles altos de la jerarquía.
Entre un esquema y otro existe una solución intermedia, denominada moderadamente
normalizada que es igual al normalizado a excepción que en todas las tablas se incluyen las
claves de todos los niveles superiores. De esta manera la cantidad de joins se reduce, siendo a los
sumo dos, para cualquier nivel de la jerarquía consultado.
El esquema totalmente desnormalizado presenta algunas variantes. Puede contener:
- Una clave y una descripción genéricas para toda la dimensión, y las claves de los
diferentes niveles. Esta opción es rara. Podría usarse para algún caso donde la
descripción sea la misma, cualquiera sea el nivel de análisis que se consulte, o si el dato a
mostrar se calcula a partir de esa descripción común.
- Una clave genérica para toda la dimensión y las descripciones de los diferentes niveles.
Es válido si no existen tablas de hechos con nivel de granularidad diferente al nivel base
de la dimensión.
- Una clave genérica para toda la dimensión y las claves y descripciones de los diferentes
niveles. Este es el caso más común y el mostrado en la figura, sólo que para el ejemplo se
toma como clave de la dimensión a la clave del nivel más bajo.
Con este esquema totalmente desnormalizado hay que utilizar algún método de
indexación eficiente para obtener el listado de valores de los diferentes niveles de la jerarquía,
particularmente para resolver rápidamente los cruces con las tablas de hechos donde el nivel de
granularidad no sea el base. Caso contrario sería necesario crear tablas adicionales para los
distintos niveles y esto generará aún más redundancia de datos, como se puede observar en la
figura 12.
La discusión entre ambos esquemas surge de considerar el tamaño total de la base de
datos (y el consecuente espacio necesario en disco, demoras para backups y otros procesos) y de
las limitaciones tradicionales de las bases de datos para resolver las operaciones requeridas en un
área de soporte de decisiones. Estas operaciones consisten en unir información de diferentes
tablas, agregar o agrupar datos, ordenar datos y recorrer grandes volúmenes de datos.
El desarrollo tecnológico a través de los años ha quitado presión al problema del tamaño
del DW. Con respecto a las operaciones costosas en la base de datos pueden usarse técnicas
para abordarlas: usar un modelo desnormalizado, usar tablas resumidas (evita tener que calcular
agregaciones sobre tablas bases), guardar los datos ordenados (para evitar ordenamiento) y crear
índices (para evitar recorrer tablas grandes). Todas estas opciones requieren que el diseñador
conozca las consultas que serán realizadas frecuentemente para personalizar la base de datos
focalizando en la performance de esos casos.
59
Capítulo 3 - El proceso de creación de modelos analíticos
Algunos argumentos a favor de la desnormalización, con una única tabla por dimensión y
el uso de índices:
- Las tablas normalizadas hacen más compleja la presentación de los datos; y el modelo
dimensional debe ser simple. Cuantas menos tablas haya más fácil será de entender.
- Muchas tablas y cruces normalmente perjudican los tiempos de respuestas y dificultan la
generación (en SQL) de las consultas.
- El espacio en disco que se ahorra es mínimo respecto al tamaño de las tablas de hechos y
no justifican el esfuerzo.
- La normalización perjudica la habilidad de navegar los datos dentro de una dimensión,
particularmente cuando se consultan al mismo tiempo varios atributos.
- La normalización rechaza el uso de índices que es una técnica para lograr buena
performance.
Por el contrario, a favor de un DW normalizado y esquemas estrellas para Data Marts se
exponen las siguientes razones:
- La cantidad de espacio es mínimo. En el modelo desnormalizado las tablas de dimensión
son muy grandes.
- Es flexible y escalable en cuanto a cantidad de atributos dentro de cada dimensión, y
cantidad de elementos (valores) dentro de cada atributo.
- Maneja naturalmente en forma óptima listas desplegables y tablas de hechos con diferente
granularidad.
- El mantenimiento de las tablas de dimensión es más sencillo al no haber redundancia de
datos. Soporta mejor los posibles cambios en los valores de los atributos de las
dimensiones. Si una descripción cambia debe ser modificada sólo en un lugar en vez de
en todos los registros de una tabla de dimensión desnormalizada.
Es interesante observar como las diferencias entre las estructuras se hacen más visibles
cuando la dimensión tiene muchos niveles, y también cuando hay tablas de hechos con diferentes
granularidades (que podrían existir o no, y podrían corresponder a agregaciones28 o a otros
hechos). A partir el ejemplo de la figura 11 se podrían obtener las variantes mostradas en las
figuras 12, 13 y 14.
28 Consultar sobre la técnica de agregación al final de este capítulo. Las agregaciones tienen sentido cuando existen dimensiones con jerarquía. La razón principal de su creación es reducir la cantidad de registros de una tabla de hechos que son consultados y agrupados para armar una respuesta cuando se pregunta por niveles superiores al nivel base. Se crean tablas adicionales con datos ya resumidos para las consultan frecuentes.
60
Capítulo 3 - El proceso de creación de modelos analíticos
Figura 12. Esquema altamente desnormalizado para la dimensión “Ubicación”.
Figura 13. Esquema altamente normalizado para la dimensión “Ubicación”.
Figura 14. Esquema moderadamente normalizado para la dimensión “Ubicación”.
61
(Dim Ubicación agreg 2)
Dim Ubicación base (Dim Ubicación agreg 1)Tabla de hechos base
Localidad_idLocalidad_descDepto_idDepto_descProvincia_idProvincia_descPais_idPais_descRegion_idRegion_desc
Localidad_id…
Tabla de hechos nivel pcia
Pcia_id…
Tabla de hechos nivel pais
Pais_id…
Provincia_idProvincia_descPais_idPais_descRegion_idRegion_desc
Pais_idPais_descRegion_idRegion_desc
Tabla de hechos base
Provincia_idProvincia_descPais_id
Pais_idPais_descRegion_id
Localidad_id…
Tabla de hechos nivel pcia
Pcia_id…
Tabla de hechos nivel pais
Pais_id…
Depto_idDepto_descPcia_id
Region_idRegion_desc
Localidad_idLocalidad_descDepto_id
Tabla de hechos base
Localidad_id…
Tabla de hechos nivel pcia
Pcia_id…
Tabla de hechos nivel pais base
Pais_id…
Provincia_idProvincia_descPais_idRegion_id
Pais_idPais_descRegion_id Depto_id
Depto_descPcia_idPais_idRegion_id
Region_idRegion_desc
Localidad_idLocalidad_descDepto_idProvincia_idPais_idRegion_id
Capítulo 3 - El proceso de creación de modelos analíticos
En el esquema altamente desnormalizado de la figura 12 las tablas adicionales para la
dimensión (punteadas en el gráfico) podrían crearse pero esto produciría más redundancia aún; es
preferible optar por una buena técnica de creación de índices en la tabla original para obtener en
tiempos aceptables los valores distintos del atributo correspondiente al nivel que se consulte. En
este esquema todas las consultas se resuelven mediante un join con la tabla de dimensión,
realizando el agrupamiento de registros correspondiente al nivel de la jerarquía que se elija.
En la figura 13 se puede observar como el esquema altamente normalizado soporta
naturalmente las diferentes granularidades de las tablas de hechos. Por otro lado, de no existir
tablas de agregación, resolver una consulta sobre la tabla base requiere muchos joins, a nivel de
país por ejemplo serían cuatro.
Respecto al esquema de la figura 14, las consultas a cualquier nivel de la dimensión se
resuelven haciendo a lo sumo dos joins, existan o no tablas de agregación.
La elección del esquema adecuado dependerá del caso, de algunos motivos ajenos como:
el alcance total del proyecto, los recursos disponibles, las facilidades del motor de base de datos
elegido; y de cuestiones propias del modelo como: la cantidad de niveles de las dimensiones, los
niveles que sean consultados frecuentemente, y particularmente de la cantidad de registros que
contengan la dimensiones. Por ejemplo: no es lo mismo si la tabla contiene la información de
todas las localidades del mundo que si contiene información de 100 localidades correspondientes
a 20 departamentos, de 2 provincias y del mismo país. En este caso los dos niveles superiores de
la dimensión no se consultarán (probablemente ni siquiera se incluyan en el modelo) y las
diferencias en los tiempos de respuesta no se notarán, cualquiera sean el esquema y la
agregación que se utilicen. Sí es probable que se note la diferencia en la complejidad de la
elaboración de consultas.
Por último existe una opción totalmente extremista, en la que podría caerse por error al
realizar los primeros diseños, que sería desnormalizar a nivel de la tabla de hechos, ingresando
como campos de esta tabla a los atributos de la dimensión. Este caso sería un error de diseño
porque se pierde el concepto de dimensión en sí. Además habría mucha redundancia de datos,
ocuparía mucho espacio y exigiría alto grado de mantenimiento.
En las figuras 15 y 16 se muestran dos posibilidades de cómo podría quedar el diseño en
caso de implementar esta decisión.
En la propuesta de la figura 15 se tratan los diferentes niveles de una dimensión como si
fuesen dimensiones diferentes. Todas las consultas se resuelven con un solo join, pero se pierde
la posibilidad de drill down que es la base de OLAP. Lo más destacable es la diferencia
conceptual, debido a que se generan dimensiones separadas para representar una misma
entidad. Esto dificulta el análisis.
62
Capítulo 3 - El proceso de creación de modelos analíticos
Figura 15. Desnormalización de la dimensión “Ubicación” dentro de las tablas de hechos, considerando los niveles de la dimensión como dimensiones independientes.
La variante de la figura 16 mantiene el concepto de dimensión y permite modelar a todos
los atributos como parte de una jerarquía y hacer drill down. A la vez resolvería todas las consultas
con un único join. Pero esta redundancia extrema deforma el modelo y dificulta la elaboración de
las consultas. Si el volumen de información fuese grande ocuparía espacios enormes y con
volumen chico no se necesita porque la supuesta mejora en la performance no sería evidente.
Esta opción complica el entendimiento y mantenimiento del modelo y de los datos.
Figura 16. Desnormalización de la dimensión “Ubicación” dentro de las tablas de hechos,
manteniendo la jerarquía de la dimensión.
En general cada dimensión debe estar relacionada por una única clave a cada tabla de
hechos, en el nivel de granularidad que corresponda.
63
Tabla de hechos base
Provincia_idProvincia_desc
Pais_idPais_desc
Localidad_idDepto_idPcia_idPais_idRegion_id…
Tabla de hechos nivel pcia
Pcia_idPais_idRegion_id…
Tabla de hechos nivel pais
Pais_idRegion_id…
Depto_idDepto_desc
Region_idRegion_desc
Localidad_idLocalidad_desc
Tabla de hechos base
Provincia_idProvincia_descPais_id
Pais_idPais_descRegion_id
Localidad_idDepto_idPcia_idPais_idRegion_id…
Tabla de hechos nivel pcia
Pcia_idPais_idRegion_id…
Tabla de hechos nivel pais
Pais_idRegion_id…
Depto_idDepto_descPcia_id
Region_idRegion_desc
Localidad_idLocalidad_descDepto_id
Capítulo 3 - El proceso de creación de modelos analíticos
Subdimensiones y jerarquías múltiples dentro de una dimensión
Hay casos que requieren especial atención respecto a la decisión a tomar sobre
normalización. Se trata de las dimensiones que presentan subdimensiones y/o tienen múltiples
jerarquías.
Se dice que existe una subdimensión cuando dentro de una dimensión se puede identificar
una entidad independiente que se relaciona con la principal. Por ejemplo, la ubicación del cliente.
Si el cliente está asociado a una localidad, la ubicación geográfica del cliente puede verse como
una subdimensión dependiente. No tendría sentido incluir todos los datos de la dimensión
ubicación por cada registro que exista en la tabla de cliente. Cualquiera sea el esquema elegido
para modelar la dimensión ubicación, dentro de la tabla de cliente sólo deberá incluirse la clave de
la ubicación (localidad_id). Tener otros datos de ubicación a nivel de cliente ocuparía muchísimo
espacio y dificultaría el mantenimiento de las localidades. Además la independencia de la tabla
ubicación permite su reuso en otras dimensiones (como por ejemplo la ubicación de los
proveedores).
Las subdimensiones muchas veces suelen modelarse de manera separada, generalmente
porque hay alguna otra forma de agrupar al nivel inferior de la dimensión de la cual depende a
través de atributos de una jerarquía principal. Por ejemplo la dimensión cliente podría consistir de
los niveles: tipo de cliente y cliente, y la subdimensión ubicación del cliente podría modelarse en
forma separada bajo el nombre de destinos o mercados. Dependiendo de las facilidades de la
herramienta que se elija para explotar la información, y en particular si soporta o no modelar más
de una jerarquía dentro de las dimensiones, las subdimensiones se podrán visualizar como una
jerarquía más o como una dimensión separada.
Una situación similar ocurre cuando atributos de una dimensión se modelan como
dimensiones separadas. Esto puede suceder cuando una dimensión tiene múltiples jerarquías. Por
ejemplo para el caso de la dimensión producto se identifica la jerarquía principal: ítem, línea,
categoría y rubro, y también los atributos marca y color. Si la herramienta elegida no permite
manejo de múltiples jerarquías, será la principal la que se muestre dentro de la dimensión y las
secundarias deberán modelarse como dimensiones separadas.
En los cubos MOLAP cuando las subdimensiones y/o las jerarquías secundarias se
modelan como dimensiones separadas es necesario incluir las claves de estas en la tabla de
hechos. Esto no significa que hay que desnormalizar la tabla de hechos en el DW, puede hacerse
directamente en la definición del cubo29.
29 Observar en el caso práctico los ejemplos de subdimensiones, especialmente de procedencia del alumno, y otros atributos como sexo, edad, nacionalidad. Estos se modelan como dimensiones separadas a través de la definición de campos virtuales en lugar de incluir estos campos en las fuentes de datos.
64
Capítulo 3 - El proceso de creación de modelos analíticos
Dimensiones con valores variables
Existen dimensiones completamente estáticas, con valores bien determinados. Tal vez
nuevos valores sean agregados, pero los existentes en el DW jamás sufren modificaciones.
También hay casos donde el elemento de la dimensión en sí no cambia (la clave en el sistema
operacional es la misma) porque se refiere a la misma cosa, pero sí cambia la descripción o
alguno de los atributos. Esto puede ocurrir por corrección de errores, o porque el dato sufre alguna
modificación en el sistema fuente. A estos casos se los conoce como “slowly changing dimension”
y hay tres opciones para manejarlos:
- Sobrescribir el registro de la dimensión con el valor nuevo. Esta opción se usa para
correcciones de errores, y pierde la historia del elemento.
- Crear un nuevo registro en la dimensión para el nuevo valor. Es la solución recomendada
para manejar los cambios en los atributos. Requiere el uso de claves sustitutas para el DW
porque no puede tomarse la misma clave que existe en el sistema operacional.
- Crear un campo “descripcion_anterior” en el registro de dimensión para guardar el valor
previo inmediato del atributo. Es para cambios no muy importantes, que no determinan
una partición histórica. Aunque el valor cambió se puede hacer de cuenta que no se
modificó.
También existe la posibilidad de no actualizar nunca el valor, bajo ninguna circunstancia.
En este caso el DW no reflejará los cambios que se realicen en los sistemas fuentes.
El término “slowly” se utiliza porque generalmente los cambios en las dimensiones no se
producen con mucha frecuencia. Sin embargo puede ocurrir que los cambios sean bastante
frecuentes. Las técnicas a utilizar son las mismas, sólo que es probable que en estos casos sea
más importante guardar la historia de los valores.
Otros tipos de dimensiones que merecen especial atención, son los casos de las
dimensiones grandes y las dimensiones degeneradas. Se dice que una dimensión es grande
cuando contiene gran cantidad de elementos, por ejemplo personas. En muchos casos pueden
soportarse bien, cuando se trabaja sobre bases de datos relacionales. Es apto para ambientes
ROLAP o HOLAP, no MOLAP. Es necesario aplicar técnicas para mantenerlas controladas, sobre
todo cuando cambian rápidamente.
Las dimensiones degeneradas son dimensiones donde la descripción es la clave en el
sistema operacional, por ejemplo un número de factura, o el número de inscripción. En estos
casos los códigos no se regeneran sino que se toman los originales y se ponen en la tabla de
hechos. La dimensión consiste sólo del código y por eso se dice que está degenerada (no tendrá
tabla asociada).
65
Capítulo 3 - El proceso de creación de modelos analíticos
Definición de las medidas
Una vez diseñado el Data Mart, la granularidad de las tablas de hechos y habiendo
diseñado las dimensiones resta el último paso en la definición de cada modelo dimensional, que
consiste en la definición de las medidas. A continuación se presentan los diferentes tipos de
métricas que existen y algunas técnicas para manejarlas.
Medidas aditivas, semi-aditivas y no aditivas
Una medida es aditiva si tiene sentido sumar sus valores a través de todas las posibles
dimensiones. Siempre que sea posible deben incorporarse a las tablas de hechos medidas que
sean perfectamente aditivas. Métricas de actividad, numéricas y discretas, como unidades o
importe correspondientes a una venta, generalmente cumplen con esta característica.
Sin embargo las medidas de intensidad, también numéricas, como balances de cuentas y
niveles de inventario, no son perfectamente aditivas. En estos casos generalmente es posible
sumar los valores a través de todas las dimensiones menos en el tiempo. Medidas de este tipo se
pueden combinar a través del tiempo calculando lo que denomina “time-average” o promedio en el
tiempo. Esta fórmula de cálculo está basada en el “promedio de los hijos”. En caso que existan
tres niveles: año, mes y día, el valor en el mes será la suma de los valores en cada día del mes
dividido la cantidad de días del mes, y el valor en el año será la suma de los valores en los meses
dividido doce (o la cantidad de meses correspondiente al año en curso).
Para el caso de las medidas no aditivas, como puede ser un valor promedio, o una
temperatura, habrá que ver si puede definirse algún método de agregación que sea válido para
todas las dimensiones. Otra alternativa es limitar el alcance de las consultas al nivel de
granularidad en que está definido el dato. La mayoría de estos casos pueden surgir de no haber
elegido bien la granularidad de la tabla de hechos. Los datos en el nivel de granularidad más bajo
suelen ser aditivos.
En raras ocasiones es posible que una medida sea textual en lugar de numérica. El
diseñador deberá intentar modelar estos casos como dimensiones, y de llevar los textos libres a
una lista de alternativas.
Medidas con múltiples unidades
Diferentes medidas de un negocio pueden ser la misma expresada en diferentes unidades
de medición. Como ejemplos sencillos podrían considerarse: expresar distancia en metros,
kilómetros, millas, leguas, o importe de una venta en pesos, en miles de pesos, en dólares, etc.
En los negocios que involucran varios procesos encadenados en etapas y en los cuales se
monitorea el flujo de los productos a través del sistema suelen presentarse casos un poco más
complejos de conflictos con las medidas de cantidades. Esto es porque existen múltiples medidas
en los diferentes puntos de la cadena, debido a que los números son expresados en diferentes
66
Capítulo 3 - El proceso de creación de modelos analíticos
unidades de medición. Por ejemplo, en los distintos sectores pueden contarse: unidades de envío
(paquetes y cajas que se trasladan del depósito a la sucursal), unidades vendidas, unidades
escaneadas (paquetes de venta), unidades consumibles (contenido individual de los paquetes),
etc.
De forma similar la cantidad de un producto puede tener varias valuaciones económicas
posibles, en términos de valor de inventario, precio de lista, precio de venta original, precio de
venta final.
Esta situación puede ser agravada si además se tienen muchas métricas diferentes. En
estos casos no es correcto incluir en la tabla de hechos sólo a las medidas fundamentales, porque
se perdería parte del análisis. Tampoco es correcto incluir a todas las posibles combinaciones de
medidas fundamentales expresadas en las diferentes unidades de medida y por cada factor de
valuación posible (porque la tabla sería gigante). La solución consiste en identificar a las medidas
fundamentales, los factores de conversión y los factores de valuación, e incorporar todos esos
valores a la tabla de hechos. De esta forma es posible obtener cualquier medida final que se
desee a partir de la combinación correspondiente.
A veces se cae en la tentación de incluir los factores de conversión en alguna tabla de
dimensión (por ejemplo: contenido individual, cantidad de unidades por paquete de venta, y
cantidad de paquetes por caja de envíos, podrían incluirse en la tabla de productos). En general
esto no se recomienda porque los factores de conversión suelen variar, lo que obligaría a generar
nuevos registros en la tabla de dimensión para mantener los cambios. Estos factores,
especialmente los asociados a costos y precios, suelen evolucionar en el tiempo y se asemejan
mucho más a medidas que a atributos de dimensión.
Empaquetar todas las medidas y todos los factores de conversión juntos en el mismo
registro de la tabla de hechos es la manera más segura de garantizar que esos factores serán
usados correctamente.
Medidas básicas y derivadas
Existe una clasificación importante entre las medidas básicas, que existen naturalmente a
partir de un evento, y las que se calculan en función de una o más de ellas, denominadas medidas
derivadas. Se dice que una medida es básica o base cuando corresponde a una columna de una
fuente de datos. Ejemplos suelen ser cantidades e importes.
Una medida es derivada si necesita ser calculada, como por ejemplo el importe de ventas
acumulado a la fecha, la rentabilidad, la diferencia entre la cantidad de ingresantes del año actual
con respecto al mismo valor el año anterior, la tasa de egresados sobre ingresantes, etc. Hay dos
tipos de medidas derivadas:
67
Capítulo 3 - El proceso de creación de modelos analíticos
- Las aditivas30. Estas pueden ser calculadas enteramente a partir de las otras medidas
existentes en el mismo registro de la tabla de hechos. Por ejemplo el caso de múltiples
unidades de una medida presentado anteriormente, el cálculo de ganancia (como
diferencia entre ventas y costos), etc. Estos casos suelen resolverse mediante vistas que
se presentarán a los usuarios.
- Los cálculos no aditivos, como porcentajes (ratios) o medidas acumulativas expresadas en
tablas agregadas. Estos casos muchas veces requieren ser calculados al momento que se
consultan por la herramienta de consultas o por quien escribe el reporte. A veces es
preferible incluir algunas de estas medidas en las tablas de hechos agregadas para
simplificar los cálculos y los tiempos de respuestas.
Las herramientas del mercado suelen proveer diferentes formas de definición de medidas
derivadas en función de las básicas. Incluyen fórmulas de cálculo complejas y muchas veces
evitan tener que realizar cálculos en el DW. Estas fórmulas pueden utilizarse en la etapa de
diseño, quedando así las medidas derivadas incorporadas al Data Mart o cubo. También pueden
usarse en la interfaz de consulta, permitiendo a los usuarios avanzados definir sus propias
medidas y compartirlas.
Un error frecuente es finalizar el diseño básico de la base de datos ignorando las medidas
derivadas y recién tenerlas en cuenta cuando comienza el desarrollo de las aplicaciones de
usuarios. Generalmente serán necesarios muchos cálculos del negocio que habrá que concensuar
y es preferible anticiparse a estas tareas, sobre todo para asegurarse que todas las medidas
básicas necesarias son tenidas en cuenta.
Normalización de tabla de hechos
Hay otro tipo de normalización que no se explicó en la sección anterior porque no refiere a
las dimensiones sino a las tablas de hechos y en particular a las medidas. Cuando se tienen
diferentes medidas asociadas a un evento, por ejemplo monto bruto, descuento, etc., lo más
común es modelar estas medidas como columnas separadas dentro de la tabla de hechos.
También es válido usar una sola columna denominada “monto” junto con una dimensión adicional
que represente el “tipo de monto” (en este caso los valores: bruto, descuento, etc.). Esta solución
es útil en algunos casos, particularmente cuando se tienen muchas medidas sin valor en muchos
de los registros. Caso contrario implica multiplicar la cantidad de registros de la tabla de hechos,
aumentando el tamaño de esta. Además, tener las medidas como columnas de un mismo registro
es en general mucho más útil para operar con ellas y realizar cálculos (por ejemplo porcentaje del
descuento sobre el monto bruto). Estas operaciones se dificultan si los valores están en registros
separados.
30 Entiéndase que la medida derivada es perfectamente aditiva por las dimensiones del modelo. No quiere decir que sea calculada como una suma de medidas básicas, sino que la medida resultante puede sumarse.
68
Capítulo 3 - El proceso de creación de modelos analíticos
Diseño multidimensional avanzado.
Existen situaciones particulares del modelado dimensional donde la elección de una
estructura puede ser muy efectiva, o por el contrario donde se corre el riesgo de elegir un diseño
ineficiente. En esta sección se plantean algunas consideraciones a tener en cuenta. Para obtener
mayor detalle de los casos planteados, ejemplos y gráficos, consultar bibliografía ([Kim1998] y
[Kim2002]).
Dimensiones muchos a muchos
En la mayoría de las situaciones clásicas de diseño la existencia y granularidad de la tabla
de hechos es básica y bien entendida, y las dimensiones adjuntas son obvias y no polémicas.
Pero existen casos donde una dimensión puede tener legítimamente más de un valor o ninguno
para un mismo registro. A estos casos se los suele denominar dimensiones muchos a muchos.
Analizando por ejemplo la temática del cuidado de la salud, se puede crear una tabla de
hechos por cada registro de tratamiento realizado a algún paciente. La dimensión diagnóstico es
muchos a muchos, dado que el tratamiento aplicado a un paciente puede tener más de un
diagnóstico (y también puede no tener ninguno).
Para resolver este problema y proveer un número arbitrario de valores (o diagnósticos) se
inserta una tabla de relaciones (o tabla puente) entre la tabla de hechos y la dimensión en
cuestión. En el ejemplo se crearía una tabla denominada “grupo de diagnósticos”, con una nueva
clave, que es la que se utilizará en la tabla de hechos. La tabla de “grupo de diagnósticos” tendrá
una clave compuesta, consistente de la clave del grupo y la clave del diagnóstico y un campo
adicional que es el factor de peso asociado a ese diagnóstico dentro de ese grupo.
El factor de peso asociado cumple el rol de poder analizar al total de tratamientos
agrupados y correctamente sumarizados según el peso de los diferentes diagnósticos.
Alternativamente este factor de peso podría no usarse y contar a cada tratamiento por cada
diagnóstico, multiplicando la cantidad de tratamientos, pero permitiendo evaluar el impacto de
cada diagnóstico, en términos de la cantidad total de tratamientos asociados.
Esta estructura permite ambos análisis. El usuario decidirá cuál consultar.
Roles de las dimensiones
Un rol en un DW es una situación en la que una misma dimensión aparece varias veces
en una misma tabla de hechos. Hay varias maneras en que esto puede ocurrir. Un ejemplo es el
caso de las fotos acumulativas que reflejan el seguimiento del flujo de un producto a través de una
cadena de procesos. Allí la dimensión fecha aparece repetidas veces representando la fecha de
recepción de la orden de pedido, la fecha de facturación, de envío, etc. Otros ejemplos pueden ser
aeropuertos de origen y de destino de un vuelo, cliente que realiza una llamada y cliente que la
recibe, etc.
69
Capítulo 3 - El proceso de creación de modelos analíticos
Como la entidad en cuestión es la misma (los valores son iguales) no tiene sentido
mantener más de una tabla con la misma información. Se crea entonces una única tabla de
dimensión, y las diferentes dimensiones del modelo hacen referencia a la misma tabla física,
utilizando vistas o alias en las consultas. Cada una de estas dimensiones puede ser usada en
forma independiente, cumpliendo roles diferentes en un reporte.
Cuando los roles de una dimensión están embebidos dentro de otra, como el caso
presentado de la subdimensión “ubicación del cliente”, requieren ser normalizados para poder ser
representados por una única tabla.
Pocas o muchas dimensiones
Como regla general se dice que la mayoría de los modelos dimensionales contienen entre
cinco y quince dimensiones por cada tabla de hechos. Menos de cinco hace sospechar que
algunas dimensiones no fueron tenidas en cuenta. Y un número muy grande de dimensiones es
usualmente un signo de que muchas de ellas no son totalmente independientes y podrían ser
combinadas en una sola dimensión.
Distribución de medidas de distinta granularidad
Una vez vistos aspectos particulares del modelado de dimensiones, resulta también
interesante considerar algunas características de diseño avanzado de las tablas de hechos
referentes al manejo de la granularidad y agregaciones.
El modelo dimensional es más poderoso cuanto más atómicas son las tablas de hechos.
Cuando en un diseño surgen hechos de granularidad diferente lo primero que se debiera hacer es
tratar de forzar a todas las medidas al nivel más bajo. Este proceso se conoce como asignación o
distribución de medidas de niveles altos hacia niveles inferiores. Existen varios casos donde es
necesario aplicar esta técnica en DWs. El más dominante es tal vez la alocación de costos. Por
ejemplo en una factura de transporte de mercadería puede ser que el costo esté asociado a la
factura completa y no esté inicialmente distribuido en los ítems individuales. De esta forma no
podrá calcularse la rentabilidad o ganancia por ítem.
La distribución de algunas de estas medidas puede tener una lógica muy compleja. Sería
deseable que sea el área del negocio entendida en el tema quien se encargue de realizar estas
distribuciones. Si este proceso resulta muy controversial o complicado puede distraer y demorar al
equipo de desarrollo del DW.
Si la distribución de medidas hacia el nivel de granularidad más bajo no resultara posible,
el diseñador no tendrá otra alternativa que representar los niveles más altos en tablas de hechos
separadas. Una vez que se ha elegido el nivel de granularidad de una tabla de hechos, es muy
importante que todas las medidas aditivas sean presentadas en ese nivel. A veces, con el afán de
mejorar los tiempos de respuesta o simplificar las consultas, se comete el error de guardar
información agregada que debiera ser calculada dentro de los registros de una tabla de hecho. Por 70
Capítulo 3 - El proceso de creación de modelos analíticos
ejemplo en una tabla con granularidad diaria guardar un dato como el total anual a la fecha. Estos
datos pueden resultar confusos porque no son completamente aditivos. Si al consultar los datos se
eligiera más de un día se correría el riesgo de contar más de una vez el mismo valor.
Agregaciones
Luego de haber determinado el diseño global es necesario considerar la estrategia que se
usará para agregar tablas de hechos y de dimensiones. Cada nivel de agregación que se decida
incorporar debe tener su propia tabla de hechos. Las tablas de dimensión adjuntas a estas nuevas
tablas de hechos deben ser, cuando sea posible, versiones encogidas de las tablas de dimensión
originales.
Las agregaciones, también conocidas como tablas de redundancia, tienen el objetivo de
mejorar los tiempos de performance y están ligados a la implementación física del modelo
dimensional. La creación de estas dependerá fuertemente del volumen de datos que se esté
manejando31.
Dado que las agregaciones son la forma de poner a punto la performance será necesario
construir algunas de estas tablas, probar los de tiempos de respuestas y revisarlas. También será
necesario monitorearlas a través del tiempo y hacer los ajustes necesarios cuando haga falta, en
función del crecimiento del DW.
Hay dos puntos a considerar al construir las agregaciones: las peticiones comunes del
negocio y la distribución estadística de los datos. Primero habrá que determinar qué podría ser útil
revisando en la documentación del relevamiento cuáles son las necesidades para reportes de alto
nivel. Luego, revisar cada dimensión para determinar los atributos usados comúnmente en
reportes, y las combinaciones de estos atributos para ver cuales se utilizan juntos. Cuantas más
dimensiones haya más cuidadoso hay que ser porque mayor será la cantidad de combinaciones
para las cuales se podrían crear agregaciones. En segundo término se necesita evaluar la
distribución estadísticas de los datos. Para esto referirse al prototipo de exploración de datos, la
información de diseño de las tablas, y a los datos en sí mismos, buscando contabilizar la cantidad
de valores de cada nivel de la jerarquía de cada dimensión. Existen técnicas de diseño más
avanzadas sobre agregaciones que incluyen modelado de dimensiones estructuradas con
jerarquías parciales, jerarquías con profundidades impredecibles, formas de resolver los casos
donde los atributos de las dimensiones cambian de valor, dimensiones de auditoria, cómo manejar
la dimensión tiempo (dentro del día) para representar rangos horarios, etc..
31 Si la tabla de hechos contiene pocos miles de registros probablemente responda rápido y no necesite agregaciones. Diferente es si tiene cientos de miles o millones de registros.
71
Capítulo 4 – Presentación del caso de estudio
4 Presentación del caso de estudio
El ejemplo de aplicación elegido se basa en la temática de deserción de alumnos
universitarios. Esto es, contar con información que colabore con la identificación de perfiles y
patrones de los alumnos que dejan de tener actividad académica en la universidad. El abordaje del
tema se circunscribe a la definición de un modelo dimensional que permita identificar
características y comportamientos generales de los alumnos universitarios y realizar un
desgranamiento de estos. El tema se encara desde el diseño, no se pretende involucrar
cuestiones sociológicas que quedan fuera del alcance computacional.
Para el caso de estudio se usa como sistema operativo de partida el sistema de gestión
académica de alumnos SIU-Guaraní y específicamente su modelo de datos. El SIU-Guaraní es un
sistema de desarrollo evolutivo diseñado e implementado por el SIU. Actualmente es utilizado con
sus personalizaciones particulares como sistema de gestión académica en muchas de las
universidades nacionales argentinas.
La herramienta sobre la que se desarrolla el ejemplo es O3, de la empresa IdeaSoft. La
elección de la herramienta tuvo en consideración que la misma ya está siendo utilizada muchas de
las universidades del país, promovida por el SIU mediante los modelos de análisis de información
que desarrolla.
4.1 ¿Qué es el SIU?
El SIU es un área dependiente de la Secretaría de Políticas Universitarias, perteneciente
al Ministerio de Educación, Ciencia y Tecnología32, que desarrolla sistemas de gestión y también
sistemas para la toma de decisiones y el análisis institucional en el ámbito de las Universidades
Nacionales Argentinas. Además de desarrollar soluciones informáticas, el SIU ayuda en la
implementación de las mismas. Dentro de este ámbito también se realizan desarrollos para
diferentes áreas de la Secretaría de Políticas Universitarias, donde se recibe y consolida
información de todo el sistema universitario nacional.
El objetivo del SIU es dotar al sistema universitario de elementos que permitan mejorar la
confiabilidad, completitud, disponibilidad e integridad de la información, contribuyendo de esta
forma a mejorar la gestión de las instituciones, permitiéndoles optimizar sus recursos y lograr que
el software sea aprovechado en toda su potencialidad.
La filosofía consiste en utilizar la tecnología al servicio de la institución colaborando así en
el mejoramiento de la gestión, agilizando las operaciones diarias de la comunidad universitaria.
También se hace hincapié en la calidad de la información que se lleva en los sistemas para su
análisis y utilización en la toma de decisiones estratégicas.32 Información a septiembre del 2007. En 2008 el SIU cambia de autoridades pasando a depender de un consorcio de universidades y adoptando el nombre de Consorcio SIU.
72
Capítulo 4 – Presentación del caso de estudio
El SIU tiene una modalidad de trabajo colaborativo en red, involucrando a distintos actores
de las universidades. La metodología de trabajo se basa principalmente en la transferencia de
conocimiento, el intercambio de productos y la promoción de encuentros [6] [7].
Los sistemas desarrollados abarcan la gestión operativa de las distintas áreas de una
universidad: académica, económica-financiera, recursos humanos, bibliotecas, etc., y su
correspondiente visión gerencial. Entre los sistemas desarrollados:
- SIU-Pampa/SIU-Mapuche: Sistema de recursos humanos. Gestión del personal y
liquidación de sueldos.
- SIU-Comechingones/SIU-Pilagá: Sistema presupuestario-contable.
- SIU-Guaraní: Sistema de gestión de alumnos (carreras, graduados, aulas, etc.)
- SIU-Kolla: Encuestas para seguimiento de graduados
- SIU-Araucano: Sistema estadístico de alumnos. Datos que se informan al Ministerio de
Educación.
- SIU-Tehuelche: Sistema de gestión de becas universitarias.
- SIU-Quilmes: Sistema de gestión de cobranzas.
En la actualidad, el número de implementaciones de los sistemas del SIU en las
universidades nacionales y otros organismos es de aproximadamente 800 y en cada una de las
universidades nacionales se están utilizando al menos dos de los sistemas del SIU.
En los últimos años el SIU ha logrado satisfacer la necesidad de contar con información
confiable y oportuna en diferentes niveles de la gestión de las Universidades Nacionales, colaborar
en la cultura de la transparencia, acompañar la mejora de los procesos administrativos, incentivar
la integración de áreas que tradicionalmente se encuentran atomizadas, estandarizar datos y
procesos, arraigar la concepción de la capacitación del personal administrativo como una
inversión, e incorporar nuevas tecnologías [7].
Actualmente el SIU se percibe como un importante capital y una avanzada en lo que hace
al desarrollo, distribución de sistemas y trabajo cooperativo, sobre todo por pertenecer a la
administración pública.
4.2 El sistema de software SIU-Guaraní
El SIU-Guaraní es un sistema de gestión académica desarrollado por el SIU para todas las
Universidades Nacionales. Fue concebido con el propósito de proveer a las universidades de una
herramienta que les permita administrar la gestión de alumnos en forma segura, con la finalidad de
obtener información consistente para los niveles operativos y directivos. El sistema registra y
acompaña la actividad formativa del alumno desde que ingresa a la universidad hasta que egresa,
llevando registro de toda la actividad académica intermedia, El SIU-Guaraní administra toda la
73
Capítulo 4 – Presentación del caso de estudio
información de gestión académica: carreras, planes de estudio, títulos, materias, egresados,
inscripciones y resultados de trabajos prácticos y exámenes, profesores asociados a las cátedras,
asignación de aulas, asistencias, cursos de ingreso, actividades extracurriculares, equivalencias,
certificados, encuestas, etc.
Este sistema se caracteriza por ser seguro, auditable y flexible. Se sustenta en una
metodología de trabajo colaborativa en red que permite su autosustentabilidad. Hasta el momento
cuenta con más de 200 implementaciones en unidades académicas correspondientes a 42
instituciones educativas argentinas, de las cuales 34 son universidades nacionales [6] [7].
Es utilizado por personal administrativo de la universidad, alumnos, docentes y directivos.
Los servicios brindados dependen del perfil de acceso. El acceso a usuarios se permite a través
de distintas interfaces, cada una con su funcionalidad: de gestión administrativa, terminales de
autogestión, Internet, o por teléfono (utilizando tecnologías sms y wap) [6] [7].
Más allá de las características del sistema informático como producto (aspectos
tecnológicos, prestaciones, módulos, usuarios, etc.) es interesante resaltar la visión del Guaraní
como proyecto. El SIU-Guaraní integra componentes sociales, tecnológicos, políticos, culturales y
económicos que interactúan entre sí. El objetivo del proyecto es desarrollar un único sistema
informático para todas las Universidades Nacionales con una arquitectura técnica que permita que
cada institución pueda extenderlo o personalizarlo, manteniendo la compatibilidad. Esto permite al
sistema reflejar la realidad particular de las instituciones.
El proyecto SIU-Guaraní surge hacia fin de año del 1996, luego de un importante trabajo
de relevamiento de la situación del sistema universitario argentino. Se decide desarrollar un
sistema informático de gestión de alumnos que contemplara la complejidad y heterogeneidad del
sistema universitario argentino. Que se adaptara a las realidades de las diferentes unidades
académicas, que permitiera acompañarlas en la mejora de sus procesos [6] [7]. El desarrollo del
sistema comenzó en agosto del 1997 con la conformación de un comité de desarrollo, integrado
por un equipo del SIU y técnicos de las universidades para relevar las necesidades funcionales.
Como metodología de trabajo se decidió que el SIU desarrolla todas las funcionalidades
transversales y las particularidades son adaptadas por cada universidad. Se entregan todos los
programas fuentes a los equipos técnicos de las universidades, quienes son responsables de la
implementación, y se establecen como socios del proyecto. Desde el SIU se asesora y colabora.
La filosofía de trabajo se puede sintetizar en los siguientes lineamientos: trabajo colaborativo,
transparencia, integración y conocimiento compartido.
Una evaluación del proyecto permite observar el impacto que ha producido el desarrollo
del SIU-Guaraní hasta el momento. Se han automatizado áreas de gestión de alumnos, haciendo
más eficientes los procesos y brindando integridad, seguridad, completitud y confiabilidad a los
datos. Entre otros aspectos, se destacan: el aumento creciente de unidades académicas que han
implementado el SIU-Guaraní, la extensión del proyecto a otras áreas del sistema educativo, la
ampliación del grupo de técnicos y de usuarios operativos capacitados en el sistema, el interés por 74
Capítulo 4 – Presentación del caso de estudio
parte de distintos organismos en incorporar la metodología de trabajo y la consolidación de una
filosofía de trabajo en red al interior de las universidades [7].
4.3 Deserción y desgranamiento de alumnos
La deserción universitaria es un tema que ha despertado mucho interés en el último
tiempo. El costo económico para el estado nacional de un alumno en la universidad, la creciente
necesidad de profesionales en algunas áreas y otras causas sociales son algunos de los
motivantes que conducen a preguntarse por qué una persona comienza sus estudios universitarios
y luego los abandona.
El fenómeno de la deserción, y también el de repitencia, tiene importantes implicancias
personales, institucionales, sociales y económicas. En lo personal, implica una condición de
fracaso que afecta emocionalmente a los individuos, especialmente en su inserción laboral. En lo
institucional implica una disminución del rendimiento académico de la universidad y un incremento
innecesario del número de alumnos y el costo de mantenimiento de estos. En lo social, la
deserción contribuye a generar inequidad y desequilibrios sociales y desvirtúa los objetivos que la
sociedad le ha entregado a la educación superior. También produce un aumento del subempleo y
falta de aporte intelectual. En lo económico, el costo que esto implica para los sistemas es
enorme. En un estudio de UNESCO realizado en febrero de 2004 en 15 países que cubren un
90% de Latinoamérica el costo de la deserción se estimaba en U$ 11,1 billones de dólares al año,
lo que, según se indicó, en países como Brasil equivale al costo de 2 millones de estudiantes
universitarios [8] [9].
El problema de la repitencia y la deserción es de una magnitud considerable en todos los
países de la región. En Argentina se estima que sólo el 12% de los estudiantes que ingresan a las
universidades nacionales se gradúan, y si bien no hay datos oficiales para las instituciones
privadas se estima que es del orden de un 30%. Un 50% de la deserción ocurre durante los dos
primeros años de la carrera [8].
De los estudios realizados por la UNESCO [9] se ha concluido que las tasas de abandono
y las causas difieren mucho entre carreras y centros educativos. Esto lleva a querer establecer
una tipología de las carreras universitarias a partir de las formas en las que se producen los
fracasos.
El sistema argentino tiene sus particularidades, es muy abierto y flexible, se puede ir y
volver cuando se desee. Se rinden exámenes cuando se quiere, por lo que las permanencias
tienden a ser muy largas. Al respecto existen dos problemas: la deserción y la exclusión.
Los factores de la deserción se atribuyen a causas externas como el lugar de residencia,
las características socioeconómicas y la educación de los padres y también a causas internas
tales como las políticas de administración, la falta de orientación vocacional y el exceso de
programas. Entre las posibles acciones para mejorar la situación actual se indicaron la detección 75
Capítulo 4 – Presentación del caso de estudio
temprana de posibles desertores, la prevención, el apoyo, la determinación de momentos
problemáticos y la articulación con la escuela media.
Como propuestas para superar la deserción se señalaron los programas de becas, los
programas de articulación con la educación media, la orientación vocacional, y el establecimiento
de ciclos generales de conocimientos básicos. Con ellos se pretende dar respuesta a problemas
de deserción, retraso en los estudios, elección de carrera y movilidad institucional [9].
El caso práctico de esta tesis busca plantear un modelo dimensional que ayude a
encontrar dónde se concentran los mayores problemas dentro de una institución e identificar
posibles causas. Este conocimiento permitirá que desde la universidad puedan tomarse acciones
que ayuden a resolver los problemas existentes basándose en datos concretos.
El tema seleccionado es complejo y desde el punto de vista de la tesis, sólo se pretende
aplicar y explicar los conceptos teóricos presentados previamente en un caso práctico. Como
segundo objetivo se espera que los resultados obtenidos sirvan como disparador para su
implementación en las universidades que actualmente estén utilizando el SIU-Guaraní y que esta
primera aproximación hacia obtener conocimiento desde la información incentive desarrollos en
esta área. En los próximos capítulos se explica paso a paso el diseño dimensional siguiendo las
etapas del ciclo de vida BDL. Sin lugar a dudas las implementaciones concretas y la
retroalimentación de usuarios finales reales permitirán que este proyecto siga creciendo.
76
Capítulo 5 – Presentación de la solución
5 Presentación de la solución
Este capítulo consiste en el desarrollo del modelo para el caso práctico que sigue la
aplicación personalizada de la metodología BDL presentada en el capítulo 3. Algunas etapas del
BDL no tienen sentido dadas las particularidades del ejemplo elegido.
5.1 Requerimientos y especificación del Data Mart
Al presentar la etapa de definición de requerimientos como parte del ciclo de vida de un
proyecto de Data Warehousing se recalcó la necesidad de contar con usuarios que estén ansiosos
por obtener soluciones para analizar datos para lograr el éxito del proyecto. Al momento de
desarrollar este trabajo y por tratarse de un trabajo experimental de tesis no se tiene un usuario
sponsor que colabore en la especificación de requerimientos. Tampoco se cuenta con usuarios a
los cuales realizar las entrevistas planteadas por la metodología para esta etapa. Por lo tanto el
análisis de requerimientos para la solución presentada surge de quien escribe y la observación de
algunas de las necesidades de información de la comunidad universitaria, por trabajar desde hace
unos años ese ámbito. Cómo se planteó anteriormente, mediante este trabajo se busca aplicar en
un caso práctico los conceptos teóricos presentados. Adicionalmente se espera que las
posibilidades de análisis sirvan como puntapié inicial para incentivar una propuesta que realmente
pueda usarse para tomar decisiones.
Cabe aclarar que la complejidad de la temática abordada requiere que los datos sean
analizados por un grupo interdisciplinario, donde podrían participar sociólogos, psicólogos,
estadísticos y otros profesionales capaces de realizar interpretaciones correctas sobre la
información, definir variables, agrupadores, y también de esta forma colaborar al crecimiento de la
esta solución.
Datos considerados
La idea principal de este trabajo consiste en la identificación de perfiles de alumnos que
dejan de tener actividad académica en la universidad. Para esto se consideran datos en tres
niveles diferentes de análisis:
- el alumno en cada uno de los años académicos en que ha tenido actividad dentro de la
carrera,
- el alumno, evaluado en todo el tiempo transcurrido desde que comenzó la carrera,
- y por último la persona. Dado que un mismo individuo puede ser alumno de más de una
carrera es interesante evaluarlo también como individuo en toda la universidad,
independientemente de la o las carreras en que registre actividad.
77
Capítulo 5 – Presentación de la solución
Estos niveles determinan las medidas del cubo: cantidad de personas, cantidad de
alumnos y cantidad de alumnos por cada año con actividad.
Las dimensiones que se utilizan son variables de evaluación de la actividad académica
(por ejemplo el total de materias aprobadas en un año, el total de cursados pendientes de
exámenes, etc.), datos de los alumnos (carreras y planes) y otros datos personales (edad, sexo,
procedencia, etc.) 33.
Datos que quedaron excluidos y motivos
En el 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 situación socio-económica de los alumnos (si trabaja, con quien
vive, como financia sus estudios, el nivel de estudio de sus padres, etc.). En este trabajo no fueron
incluidos por las siguientes razones:
- Definiciones poco claras que entorpecen la interpretación de los datos censales.
Algunos datos no tienen un significado del todo definido, como es el caso de si trabaja o
no. No se sabe si la situación es temporal respecto al momento que se relevó el dato o si
es duradera.
Muchos datos dependen del criterio de los alumnos si no fueron ingresados al sistema con
algún tipo de asesoramiento.
- Problema para asociar los datos censales con un período académico.
Los datos censales pueden completarse y actualizarse en diferentes momentos del año,
pudiendo existir más de un registro por persona por año.
En las universidades y facultades se toman criterios propios sobre la actualización de
estos datos.
- No se tiene buena calidad en estos datos en la mayoría de las implementaciones.
Las universidades no suelen darles importancia porque no son necesarios para las tareas
imprescindibles de un sistema académico de alumnos, entonces muchos datos están sin
completar o presentan inconsistencias.
- Por último, en cada instalación de SIU-Guaraní se puede personalizar el formulario de
datos pedidos, pudiendo diferir no sólo en el significado y contenido sino también en el
conjunto de datos existentes y los períodos de relevamiento. De hecho, la UNS cuenta con
personalizaciones respecto a esta información.
Tener en cuenta estos datos hubiese requerido desarrollar procesos de extracción de
datos personalizados.
Inicialmente se pensó además en definir categorías de actividad de los alumnos (por
ejemplo clasificar la actividad anual en: nula, baja, suficiente, alta y muy alta, en función de la
33 Observar que si el análisis que se pretendiera hacer fuese otro, las medidas y dimensiones podrían considerarse totalmente diferentes. Por ejemplo el alumno podría ser una dimensión y la cantidad de cursados aprobados, cursados desaprobados, finales aprobados, etc. podrían ser medidas.
78
Capítulo 5 – Presentación de la solución
cantidad de finales y cursados), intensión de actividad (en cuántas materias se inscribe o se
presenta a rendir) y categorías de rendimiento (en función de los resultados obtenidos).
Finalmente se desechó la propuesta. Resulta complicado en una aplicación real definir estos
parámetros que en gran medida dependen del plan de estudio, lugar geográfico, situaciones
sociales, etc. Para realizar una clasificación justa habría que tener en cuenta variables
dependientes de la carrera: la cantidad de materias del plan, las materias en sí, si el plan
contempla sistema de puntos, materias promocionables y la realidad de los alumnos de la
universidad o facultad: horarios de cursado disponibles, si la mayoría de los alumnos trabaja,
provienen de otro lugar, viven lejos de la universidad, etc. Todo esto terminaba oscureciendo las
fórmulas y alejándonos de los objetivos del caso de estudio.
Otras variables que resultan de interés para el análisis de deserción y desgranamiento
refieren a la lentificación en la carrera (respecto al plan de estudio o al promedio histórico de
tiempo desde el ingreso hasta la graduación en la carrera), la repitencia (si el alumno debe
recursar materias, o rendir muchas veces algún final) y la movilidad (si se producen cambios de
carrera). Es muy difícil definir este tipo variables. Al intentarlo surgen preguntas como por ejemplo:
- ¿Qué alumnos deben ser considerados para calcular el promedio histórico? ¿A partir de
qué cohorte se considera? ¿Existen todos los datos necesarios en la base de datos OLTP
SIU-Guaraní?
- ¿Cómo calcular lentificación?, ¿es la cantidad de materias cursadas sobre la cantidad total
del plan actual del alumno? Y si el alumno se cambió de plan, ¿cómo debieran contarse
las materias del plan anterior? ¿Qué sucede si el plan está compuesto de materias y
créditos?
- ¿Cuándo se considera que un alumno se movió de carrera?: ¿porque quedó de baja?,
¿porque ya no se inscribe a materias? ¿Qué sucede cuando sólo registra actividad en
materias comunes?
Para trabajar con este tipo de datos es necesario que exista un equipo que respalde las
definiciones y que vaya a utilizar los datos definidos. Por el momento no tiene sentido considerar
estas cuestiones porque implican una complejidad conceptual imposible de abordar en este
trabajo.
5.2 Arquitectura del caso práctico
La arquitectura de la solución propuesta se presenta en la figura 17 y es una adaptación
de la presentada en la figura 3. En este caso, la base de datos del sistema SIU-Guaraní es la
única fuente de datos. La sección de transformación de datos no existe explícitamente34. La
extracción de datos se realiza mediante la ejecución de procesos que se incorporan en la base de
34 Debido a diversos motivos del sistema universitario, pero principalmente a la falta de maduración en estas temáticas, resulta difícil crear y administrar tanto un DW como un área de transformación de datos. Estas tareas, junto con la implementación de una herramienta de ETL y la conexión de los cubos al DW (planteado en la figura) se dejan para trabajo futuro.
79
Capítulo 5 – Presentación de la solución
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 diseño consiste en crear un modelo multidimensional, propietario. Este modelo
o meta data se utiliza como dato de entrada del componente que genera el cubo (O3 Builder) en la
etapa de carga de datos.
En la figura 17 se observan los diferentes módulos de la herramienta O3. Estos se pueden
clasificar en tres grandes categorías: los componentes de la interfaz de usuario (que serán las
únicas herramientas para análisis de información que se utilizarán en este trabajo), los de diseño y
construcción de cubos y los de administración de cubos en un servidor (O3 Server y O3
Administration Server, para configurar usuarios y permisos de acceso por perfiles).
Figura 17. Arquitectura de la solución propuesta.
5.3 Matriz y modelo lógico del Data Mart
La matriz que resulta del análisis de requerimientos planteados en la sección 5.1.1 se
muestra en la figura 18. Se pueden ver claramente los tres niveles de análisis contenidos en el
Data Mart (persona, alumno y alumno por año con actividad) y las dimensiones planteadas, junto
con los cruces válidos. El gráfico presenta los ejes intercambiados respecto a la propuesta original
sólo para obtener una mejor visualización
La mayoría de las dimensiones (unidad académica, edad, título secundario, cantidad de
carreras activo, etc.) están asociadas a la persona y por lo tanto se heredan en las otras dos
medidas. “Carrera” no está definida a nivel de persona porque puede haber más de una y es la
razón por la cual se distingue entre personas y alumnos. La dimensión “Año informado”
corresponde sólo para la medida que cuenta alumnos en cada año que tienen actividad.
80
Load
Área de usuario
(sp)
(O3 Query)
E.T.
txt
txt
txt
Idealmente sería un DW
DW
O3 Builder
Modelo del cubo (.mdl)
META DATA
O3 Designer
O3 Adm Server
O3 Server
O3 Browser(escritorio)
O3 Portal (web)
O3 Report
O3 Dashboard
O3 Scorecard
O3 Rules
O3 Process
O3 Query
BD SIU-Guaraní
Capítulo 5 – Presentación de la solución
Dimensiones Niveles
Can
tidad
de
pers
onas
Can
tidad
de
alum
nos
Can
tidad
de
alum
nos
por a
ño
con
activ
idad
Unidad Académica Unidad Académica X X XAño de Ingreso Año de Ingreso a la Universidad
Año de Ingreso a la CarreraX X
XXX
Año Informado Año Informado XÚltimo Año de Actividad Último Año de Actividad en la Universidad
Último Año de Actividad en la CarreraX X
XXX
Edad Edad al Ingreso a la UniversidadEdad al Ingreso a la CarreraEdad al año Informado
X XX
XXX
Sexo Sexo X X XNacionalidad Nacionalidad X X XProcedencia País
ProvinciaLocalidadColegio
XXXX
XXXX
XXXX
Título Secundario Título Secundario X X XAño de Egreso del secundario Año de Egreso del secundario X X XOrientación Vocacional Orientación Vocacional X X XCantidad de carreras inscripto – activo
Cantidad de carreras inscriptoCantidad de carreras activo/inscripto
XX
XX
XX
Cantidad de carreras egresado Cantidad de carreras egresado X X XCarrera Carrera X XCursados Aprobados Cursados Aprobados Totales por Persona
Cursados Aprobados Totales en la CarreraCursados Aprobados en la Carrera y Año Informado
X XX
XXX
81
Capítulo 5 – Presentación de la solución
Cursados Desaprobados Cursados Desaprobados Totales por PersonaCursados Desaprobados Totales en la CarreraCursados Desaprobados en la Carrera y Año Informado
X XX
XXX
Cursados Promovidos Cursados Promovidos Totales por PersonaCursados Promovidos Totales en la CarreraCursados Promovidos en la Carrera y Año Informado
X XX
XXX
Finales Aprobados Finales Aprobados Totales por PersonaFinales Aprobados Totales en la CarreraFinales Aprobados en la Carrera y Año Informado
X XX
XXX
Finales Desaprobados Finales Desaprobados Totales por PersonaFinales Desaprobados Totales en la CarreraFinales Desaprobados en la Carrera y Año Informado
X XX
XXX
Equivalencias Externas Equivalencias Externas Totales por PersonaEquivalencias Externas Totales en la CarreraEquivalencias Externas en la Carrera y Año Informado
X XX
XXX
Figura 18. Matriz correspondiente al Data Mart del caso práctico.
Varias de las dimensiones (las referentes a cantidades de materias y “Edad”) presentan
tres niveles de análisis, uno correspondiente a cada medida. Debe seleccionarse la combinación
de nivel y medida adecuada a la consulta deseada. Por ejemplo, si se quiere ver lo ocurrido dentro
de una carrera y un año en particular (utilizando la dimensión “Año Informado”) se debe utilizar la
medida “Cantidad de alumnos por año con actividad” y consultar estas dimensiones en el nivel
más bajo (por ejemplo: “Cursados Aprobados en la Carrera y Año Informado”). Si se desea evaluar
lo realizado dentro de la carrera, sin discriminar por año académico será necesario elegir la
medida “Cantidad de Alumnos” y utilizar el nivel intermedio que refiere a la actividad dentro del
alcance de cada carrera (por ejemplo: “Cursados Aprobados Totales en la Carrera”). En el nivel
superior se resume la actividad a nivel de persona (“Cursados Aprobados Totales por Persona”).
También es posible comparar lo ocurrido dentro de un año académico con el total acumulado en la
carrera, por ejemplo. Esto se logra consultando la medida “Cantidad de alumnos por año con
actividad” y la dimensión “Cursados Aprobados” en sus niveles “… en la carrera y año informado”
y “… totales en la carrera” en forma simultánea.
La dimensión “Año de Ingreso” también presenta dos niveles de análisis: ingreso a la
universidad (o unidad académica) e ingreso a la carrera.
El modelo de datos resultante tal como se visualiza al realizar consultas en el cubo se
muestra en la figura 19. Las tablas de color gris son las tablas de hechos, que muestran las
relaciones con las dimensiones. El resto son dimensiones. Las dimensiones que tienen más de un
nivel o jerarquía se indican en color amarillo en el diagrama, por ejemplo procedencia y cursados
aprobados.
82
Capítulo 5 – Presentación de la solución
Figura 19. Modelo de datos lógico del caso práctico. Tablas de hechos y dimensiones.
Observar que como un alumno es una persona, también podrá consultarse la cantidad de
alumnos por edad, o nacionalidad, y las demás dimensiones y niveles que se muestran asociadas
a la persona. Todos los datos definidos en un determinado nivel son heredados en los inferiores,
es decir que, por ejemplo, se podría consultar “Cantidad de alumnos por año con actividad” según
cursados aprobados para una carrera en un determinado año académico (“Cursados Aprobados
en la Carrera y Año Informado” y “Año Informado”) según la edad de la persona al momento en
que comenzó sus estudios universitarios (sin importar la carrera, “Edad al Ingreso Universidad”),
pero no se podrá consultar “Cantidad de Personas” según “Edad al Año Informado” o “Edad al
Ingreso Carrera”, porque esa medida no está definida en esos niveles de granularidad.
5.4 Modelo físico y consideraciones de diseño
El modelo físico puede pensarse en dos partes: por un lado la estructura de los archivos
de texto plano que contienen los datos para el cubo, y por otro el modelo de datos que define la
forma de visualización del mismo, y mapea la estructura de los archivos de texto en el cubo
MOLAP (archivo con extensión mdl).
83
Capítulo 5 – Presentación de la solución
Diseño físico de las tablas del DW que se usan para el Data Mart
En este ejemplo, las tablas de hechos son tres, todas se utilizan dentro del mismo cubo.
La tabla con el nivel de granularidad más bajo es la de “Alumnos por Año Académico en que
presenta actividad”. Esta tabla puede considerarse del tipo fotografías periódicas con una foto por
alumno y año académico.
Las otras dos tablas pueden considerarse de tipo fotografías acumulativas, pero donde se
guarda sólo el último estado, reflejando la información acumulada a la fecha del alumno o la
persona. Estas tablas cumplen una doble función como tablas de dimensión con atributos (y se
definen como tablas locales en O3 dentro del archivo con extensión mdl). También representan
una agregación de la tabla cuyo nivel de detalle la precede.
En los tres casos se trata de tablas de hechos sin medidas, ya que la única medida
asociada a cada tabla es la cantidad de registros.
La estructura de los archivos de texto respetan cierto nivel de normalización por los
siguientes dos motivos:
- para que a futuro pasen a formar parte de un DW. Se consideran dimensiones acordadas
con otros cubos ya existentes sobre el SIU-Guaraní. Se intenta minimizar las
transformaciones necesarias en los datos para lograr la arquitectura de la solución
definitiva.
- y para que el tamaño de los archivos sea menor.
La correspondiente desnormalización necesaria para el diseño final del Data Mart se logra
dentro de la definición propia del cubo de O3 y se realiza al momento de la construcción de este.
Esto produce un incremento en el tiempo de generación del cubo y mayor complejidad en el
archivo .mdl; pero se prioriza normalizar las tablas por los motivos expuestos. Una vez
implementado el DW, la desnormalización podría realizarse en él, o en las consultas SQL que
surjan de modificar la definición del cubo para consumir los datos.
Las tablas diseñadas para formar parte del DW son mostradas en la figura 20.
84
Capítulo 5 – Presentación de la solución
Figura 20. Estructuras de los archivos de texto.
Notar que muchas de las dimensiones planteadas en el modelo de la figura 19 no
necesitan implementarse mediante una tabla porque el código de la dimensión es la descripción
de la misma y el nivel de agrupamiento que se utiliza se define dentro del modelo del cubo. Estos
casos se modelan como dimensiones directamente en la definición del cubo (archivo mdl). Tal es
el caso de los años (año informado, año de ingreso, etc.) y las cantidades de materias (cursados
aprobados, cursados desaprobados, finales aprobados, etc.).
Observar que las dimensiones que cuentan cantidades de materias se definen en las tres
tablas de hechos. Esto es así porque representan cosas diferentes, cada una cuenta en el nivel de
granularidad en que se define, y por eso tienen nombres diferentes. Luego se combinan como
diferentes niveles de análisis de una misma dimensión sólo para simplificar el modelo final y no
tener muchas dimensiones similares que dificulten el análisis. Es importante destacar que los
datos sumarizados se calculan en las tablas de alumnos y personas porque se decidió utilizarlos
como dimensiones. Si en otro modelo de análisis se decidiera usar estas cantidades como
medidas no será necesario calcularlas, se haría solo, definiendo la medida en el nivel más bajo (de
alumno en año académico) y utilizando el método de agregación suma.
Algunos datos contenidos en estas tablas no se usan en el modelo final. Se incluyeron
porque pueden utilizarse a futuro para armar diferentes cubos, focalizando en análisis más
específicos.
85
Capítulo 5 – Presentación de la solución
Diseño físico del Data Mart
Respecto al diseño final que verá el usuario, este respeta la forma de la figura 19. En el
cubo de O3 las estructuras internas deben aplanarse completamente, formando un esquema
estrella. Para esto las claves de todas las dimensiones deben estar en la tabla donde se encuentra
la medida (en el nivel correspondiente). Cuando no están se definen especialmente mediante la
utilización de tablas locales y campos virtuales.
Si las tablas estuvieran en una base de datos, en lugar de ser archivos de texto, el
aplanamiento podría realizarse mediante uniones de tablas en las consultas en SQL y la creación
de tablas locales y campos virtuales no sería necesaria en la mayoría de los casos.
Definición de fuentes de datos
Específicamente dentro de la herramienta O3 el diseño de un cubo comienza con la
definición de las fuentes de datos, que en este caso son los archivos de texto. Para tomar un
archivo de texto como fuente se establece la ruta de acceso (figura 21) y se definen los campos
con sus respectivos tipos (figura 22). Para la ruta de acceso puede utilizarse un parámetro, como
en este caso (“raiz”).
Figura 21. Definición de fuentes de datos en O3.
Tabla de hechos correspondiente al archivo de texto con información de personas (int_de_personas.txt)
En la definición de los campos y tipos de datos (figuras 22_1 y 22_2) puede utilizarse la
función de autollenado si el archivo de texto tiene como cabecera los nombres (e indicar
expresamente saltar ese primer registro como se puede observar en la figura 21).
86
Capítulo 5 – Presentación de la solución
Figura 22_1. Definición de campos que componen el archivo de la fuente int_dw_desercion_alumnos_anio.
Figura 22_2. Definición de campos que componen el archivo de la fuente int_dw_personas,
que además se utiliza como tabla local
La información entre tablas se vincula automáticamente por los nombres de los campos,
que deben coincidir exactamente para considerarse iguales. De esta forma por ejemplo el campo
“NACIONALIDAD” de la tabla “int_dw_personas” (figura 22_2), se considera igual al de la tabla
“LT_Nacionalidades” (figura 23).
87
Capítulo 5 – Presentación de la solución
Figura 23. Definición de tabla de dimensión en O3.
Definición de dimensiones
La definición de las dimensiones se realiza identificando los códigos únicos de los valores
para cada nivel de estas y las descripciones correspondientes. En la figura 24 se muestra la
definición de la dimensión “Nacionalidad”, compuesta por un único nivel.
Figura 24. Definición de una dimensión con solamente un nivel.
88
Capítulo 5 – Presentación de la solución
Las dimensiones deben tener al menos un nivel, pero pueden tener más de uno. Tal es el
caso de “Procedencia”. Para cada nivel se indica el campo que es la clave que identifica los
distintos valores y las descripciones correspondientes. Y en la dimensión se indica si el nivel más
bajo identifica unívocamente al resto de los niveles o no. Observar en la figura 25 la indicación de
“Colegio” como “nivel único” de la dimensión. En estos casos sólo es necesario incluir en las tablas
de hechos la clave de ese nivel, el más bajo.
Figura 25. Definición de dimensión con varios niveles: “Procedencia”.
Definición de medidas
Por último se definen las medidas, que pueden ser básicas (corresponden a un campo de
la fuente), o derivadas (se calculan a partir de medidas básicas y/o datos adicionales).
Figura 26. Definición de medida “Cant Personas” como medida básica.
89
Capítulo 5 – Presentación de la solución
Para las medidas básicas se indica el campo de la fuente al que corresponde, el método
que se utiliza cuando es agregada en los niveles superiores de las dimensiones y el alcance (cada
una de las dimensiones y niveles para los que está definida la medida). Esto se muestra en las
figuras 26, 27 y 28.
Figura 27. Método de agregación para la medida “Cant Personas”. “Suma” indica que por ejemplo en el nivel “Localidad” de
la dimensión “Procedencia” se contará la suma de las personas de los colegios correspondientes.
Figura 28_1. Parte de la definición del alcance de la medida “Cant Personas”.
Figura 28_2. Parte de la definición del alcance de la medida “Cant Personas”.
La definición del alcance de cada medida es una tarea importante y debe estar acorde a la
lógica de los datos. En las figuras 28_1 y 28_2 se observa parte de lo realizado para “Cant
Personas”. El nivel de cada dimensión que existe en la fuente de datos de la medida
(int_dw_personas) es el primero para el cual queda definida y se indica con el símbolo del diskette.
De ese nivel para arriba en la jerarquía se utiliza en general la agregación (símbolo de suma). En
algunos casos podría optarse por dejarlo indefinido (signo de interrogación) para obligar a que las
90
Capítulo 5 – Presentación de la solución
consultas se hagan seleccionando uno o más valores del primer nivel para el cual la medida queda
definida. Del nivel del diskette para abajo hay que indicar que la medida no está definida y no
puede consultarse. Observar, por ejemplo, como se utiliza la agregación en la dimensión
“Procedencia”, la indefinición completa de la dimensión “Carrera”, la diferencia en la visualización
final (al consultar el cubo) respecto a “Año Informado” y la definición del alcance sólo para el nivel
superior en las dimensiones que cuentan materias35.
Uso de tablas locales y campos virtuales
Anteriormente se dijo que ciertos datos de la persona pueden proyectarse a los niveles de
alumno y alumno por año académico. Como no fueron incluidos explícitamente en los archivos de
texto fuente de las medidas correspondientes esto debe indicarse al diseñar el modelo en O3,
mediante la utilización de tablas locales y campos virtuales. En la figura 29 se puede apreciar la
definición de la tabla local con los datos de las personas que se utilizan para desnormalizar las
otras tablas de hechos.
Figura 29. Tabla local “TPersonas”. Incluye datos como sexo, nacionalidad, colegio secundario, etc.
que podrán obtenerse a partir de la combinación de unidad académica y número de inscripción.
En la figura 30 se muestra la definición del campo “NACIONALIDAD” como campo virtual.
Esto se utiliza para incorporar ese dato en los niveles de granularidad “alumno” y “alumno en año
académico” correspondientes a las otras tablas de hechos.
35 El detalle de las posibles combinaciones del alcance de las medidas es específico de la herramienta y queda fuera de este trabajo.
91
Capítulo 5 – Presentación de la solución
Figura 30. Recuperación del valor correspondiente a “NACIONALIDAD” mediante de la definición de un campo virtual.
Esto se utiliza cuando el campo no está en la fuente de datos (caso de int_dw_alumnos e
int_dw_desercion_alumnos_anio)
En la figura 30 también se puede observar que los campos virtuales pueden ser utilizados
con otros propósitos: para calcular valores derivados a partir de los datos fuentes (ejemplo:
“EDAD_IngrUniv”), para indicar valores por defecto para el caso de nulos (“DV_COLEGIO” y
otros), entre otros posibles usos, como definición de medidas, definición de descripciones a partir
de más de un campo, etc.
5.5 Personalización del proceso ETL
El ejemplo elegido consta de tres niveles diferentes de definición de tablas de hechos. El
proceso de extracción consiste principalmente en la creación de esas tres tablas, las cuales se
construyen de la siguiente manera:
En la tabla de alumno por año, se crea un registro para cada año por cada individuo que
tiene actividad académica en cada carrera, comenzando por el año de ingreso de esa persona a la
universidad hasta el año académico corriente. Para cada alumno (persona en una determinada
carrera) se cuenta la cantidad de cursados aprobados, cantidad de cursados desaprobados,
cantidad de finales aprobados, entre otras cosas, durante cada año académico y se agrega el
registro a la tabla si alguna de esas cuentas es diferente a cero.
La tabla de hechos de alumnos, recopila información del alumno dentro de la carrera: año
de ingreso a la carrera, datos del plan y cantidades totales de cursados, finales y equivalencias,
desde el ingreso a la carrera hasta la fecha. Para calcular estas cantidades se realiza una suma
sobre los datos de la tabla anterior a través de los distintos años.
La tabla de hechos de personas también calcula las cantidades de materias como suma,
en este caso a partir de la tabla de alumnos. Se consideran todas las carreras en las que es
alumno36. Además en esta tabla se definen otros atributos de las personas que se representan
36 Tener en cuenta que las materias comunes se contarán dos veces, dependiendo de cómo se estén registrando en el SIU-Guaraní, seguramente se cuente como materia aprobada en una carrera y como equivalencia en la otra.
92
Capítulo 5 – Presentación de la solución
como dimensiones (sexo, edad, procedencia, etc.). Los procesos de creación de las tablas y
llenado de las mismas se adjuntan en el apéndice.
Para este caso práctico la transformación de datos es casi nula y se incluye como parte
del proceso de extracción. Esto es debido a que, por el momento, no se implementa la arquitectura
completa de un proyecto de DW y no se dispone de un espacio especial para esta tarea. Una de
las recomendaciones básicas es la creación de claves sustitutas. Esto no se realiza por los
siguientes motivos:
- La fuente de datos es única.
- No se implementa por ahora la etapa de limpieza y transformación de datos, dejando esta
tarea para desarrollo futuro.
- Utilizar los códigos originales facilita el control de datos extraídos y sirve para mejorar la
calidad de los datos del sistema de gestión.
En este caso práctico tampoco es posible ejemplificar algunas consideraciones respecto a
la integración de datos, porque estos son extraídos de un único sistema fuente donde ya se
encuentran integrados.
5.6 Problemas de calidad de datos
Los problemas de calidad pueden manifestarse en tres lugares diferentes y serán
evidenciados cuando el cubo esté generado. Será necesario testear adecuadamente: el estado de
los datos en la fuente, el proceso ETL y la definición del modelo del cubo para asegurarse que la
solución es correcta.
Si la calidad de datos en el origen no es buena no habrá mucho que se pueda hacer. De
todas formas durante los procesos de extracción, transformación y carga de datos podrán tomarse
algunas decisiones que resuelvan los problemas de calidad de diferentes formas. Por ejemplo se
puede decidir descartar un registro que contenga algún campo nulo, o rellenarlo con algún valor
por defecto.
Lamentablemente la mayoría de los problemas se hacen evidentes al generar el cubo con
información real, ya que es difícil contemplar todas las posibles anomalías que podrían presentar
los datos. Lo más sencillo y útil es examinar los datos reales y los problemas de calidad que
presentan y dedicarse a solucionarlos. En lugar de pensar todas las posibles inconsistencias que
podrían existir, trabajar sobre las pocas o muchas que realmente surjan.
Controles en la definición del modelo y la generación del cubo
De los controles a realizar el más sencillo es sobre la definición del modelo del cubo. Una
vez generado el cubo hay que controlar que todo el contenido de los archivos de texto haya sido
93
Capítulo 5 – Presentación de la solución
incorporado para la visualización final del usuario. El log de la generación registrará errores y
advertencias que serán de utilidad.
Debe controlarse:
- Cada medida.
En este caso la cantidad de registros de cada archivo de tabla de hechos debe ser igual a
la cantidad total de la medida correspondiente en el cubo. Si no coincide, puede ser que
haya registros que por algún motivo se hayan excluido. Posiblemente el motivo de
exclusión sea algún campo nulo, o no existente en otra tabla (falta de integridad referencial
entre los datos).
Si hubiese otras medidas además de cantidades, debieran controlarse al menos que los
totales de los valores coincidan.
- Cada dimensión.
Puede ocurrir que falten valores en las tablas de dimensiones o existan códigos no
adecuados en las tablas de hechos. Estos casos podrán visualizarse al desplegar los
valores de las dimensiones utilizando la interfaz de acceso al cubo.
También debe controlarse que las dimensiones contengan los valores adecuados, y
descartar así posibles errores en la definición del modelo: al asociar los campos, las
claves, las descripciones, definir niveles únicos, etc.
Suele ocurrir que valores diferentes coinciden en la descripción y entonces es necesario
utilizar también el código para diferenciar estos casos.
Controles en los procesos de extracción y transformación de datos
Respecto al proceso ETL se requiere un riguroso testeo sobre los datos aportados al DW.
Hay que tener cuidado de no descartar datos sin la intención explícita de hacerlo y testear
cuidadosamente la lógica utilizada para la extracción. De todas formas es conveniente chequear
las cantidades del cubo con reportes y otras consultas provenientes del/los sistemas de gestión
correspondiente.
Si existiese un área de transformación de datos sería necesario tomar algunos indicadores
generales (totales de registros, totales de campos nulos o con valores incorrectos, cantidades de
valores posibles, etc.) en las fuentes de datos y en diferentes niveles de los procesos de
transformación para asegurarse que los datos van evolucionando de forma adecuada y no se
pierden valores.
Problemas de calidad en el origen del dato
Por último, el cubo puede presentar inconsistencias o anormalidades provenientes del
sistema de gestión. En este caso si el SIU-Guaraní se usa correctamente y con los controles
necesarios activados no existirán estos problemas en la base de datos. Sin embargo en muchas
ocasiones se descubren datos inconsistentes y/o falta de información en el sistema de gestión.
94
Capítulo 5 – Presentación de la solución
Estas situaciones se deben generalmente a procesos de migración de información de otro sistema
que se incorpora al SIU-Guaraní con controles desactivados o en forma incompleta. También
existe información incompleta cuando se decide no ingresar al sistema datos “no imprescindibles”,
o datos no obligatorios o desconocidos que son dejados en blanco o completados con datos
incorrectos.
Estos casos suelen ser detectados más tarde a partir de la observación de los valores de
las dimensiones del cubo y los cruces de variables permitidos. Por ejemplo, edades fuera de
rangos razonables indican que la fecha de nacimiento de las personas que figura en la base de
datos no es correcta. Datos de procedencia desconocida surge del hecho que el colegio
secundario no esté cargado para muchas personas. Otro caso que podría ocurrir es alumnos que
tuviesen actividad académica anterior al año de ingreso37.
Todos estos casos son ejemplos de la retroalimentación que generan las soluciones para
análisis de datos en los sistemas operacionales. Debieran ser corregidos en el sistema operativo
de origen y luego regenerar el cubo con la información correcta.
37 En este trabajo estos casos se descartan antes, directamente no se los extrae de la fuente de datos.95
Capítulo 6 – Uso de la herramienta y análisis de datos
6 Uso de la herramienta y análisis de datos
Una vez generado, el cubo se encuentra en condiciones de ser consultado38. Podrá
accederse como archivo local directamente utilizando el O3 Browser (abrir el archivo
dm_desgranamiento_alumnos.cube desde la ubicación correspondiente) o publicarse en el
servidor de O3 y accederse a través de las interfaces que se hayan instalado (escritorio o web) y
con los permisos que pudiesen haberse configurado39.
Este capítulo tiene el propósito de mostrar la funcionalidad básica de la herramienta y
algunos ejemplos de las amplias posibilidades de análisis brindadas por el cubo diseñado. Los
datos sobre los cuales se trabaja son inventados, no son reales. Han sido generados para poder
ejemplificar algunas cuestiones y pueden presentar inconsistencias propias de no provenir de una
base de datos real de SIU-Guaraní.
6.1 Acceso al cubo y operaciones básicas
Acceso al cubo y vista inicial
Al abrir el cubo se obtiene la vista inicial, consistente de la medida “Cant Personas” y las
dimensiones “Unidad Académica” y “Año Ingreso” (en el nivel “Año Ingreso a la Universidad”).
Figura 31. Vista inicial predeterminada del cubo dm_desgranamiento_alumnos generado con datos de prueba.
Observaciones: en el ejemplo se consideraron datos de una facultad solamente.
38 En la sección 8.4 del apéndice se explica cómo generar el cubo.39 En los ejemplos de este trabajo se accede con la interfaz de escritorio de forma local.
96
Capítulo 6 – Uso de la herramienta y análisis de datos
Existen datos con problemas de calidad, no debieran existir casos con año de ingreso en 0.
Esta consulta es la forma de acceso al cubo predeterminada y queda definida por el cruce
de las dos primeras dimensiones del modelo y la primera medida, sin ningún filtro. A partir de esta
vista puede navegarse el cubo. Es posible regresar a la misma desde el menú “Explorar” “Vista
inicial” o con el botón de acceso rápido.
Los usuarios pueden confeccionar reportes o vistas propias para consultas frecuentes y
utilizarlas para acceder al cubo en lugar de hacerlo mediante la vista inicial predeterminada. Estas
vistas pueden contener filtros, otro tipo de gráfico, fórmulas calculadas, muchas dimensiones y
medidas. A partir de ellas también es posible navegar el cubo, pudiendo retornar al punto de
partida con la opción de “vista inicial”.
Operaciones básicas de consulta
Las operaciones más comunes y sencillas sobre los datos consisten en: reemplazar o
agregar dimensiones a una consulta, seleccionar diferentes medidas, realizar filtros y desagregar
información.
Selección de dimensiones
La selección se realiza arrastrando la dimensión deseada al gráfico, superponiéndola con
la que se quiere reemplazar. Cuando esta operación se realiza en el modo gráfico la dimensión a
ser reemplazada se colorea de amarillo en el momento en que se debe soltar el arrastre del ratón.
Figura 32. Ejemplo de reemplazar la dimensión “Unidad Académica” por “Sexo” en la consulta, para obtener “Cant
Personas” por “Año de Ingreso” (a la Universidad) y “Sexo”.
97
Capítulo 6 – Uso de la herramienta y análisis de datos
Al trabajar en el modo grilla la dimensión a reemplazar se colorea de gris. En este caso es
posible no sólo reemplazar dimensiones existentes en una consulta sino también agregar, creando
así tablas con más de una variable en las filas y/o en las columnas. El lugar donde se insertará la
dimensión que se incorpora a la consulta es señalado con una barra amarilla. Es posible cambiar
el orden de presentación arrastrando las dimensiones dentro de la tabla.
Para pasar del modo gráfico a grilla usar la opción “Desplegar tabla” del menú “Ver”, o el
botón de acceso directo.
Figura 33. Ejemplo de consulta en formato de tabla utilizando muchas dimensiones.
Selección de medidas
Es posible cambiar cualquier medida simplemente desplegando el listado correspondiente
y eligiendo la deseada. También pueden utilizarse las medidas dentro de la visualización de la
consulta, como si fuesen los valores de una dimensión. Esta opción generalmente se utiliza para
comparar medidas. En las figuras 34 y 35 pueden apreciarse ejemplos en modo gráfico y grilla
respectivamente.
98
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 34. Comparación de “Cant Personas” vs. “Cant Alumnos” abierto por “Sexo”.
Figura 35. Comparación de medidas “Cant Personas” y “Cant Alumnos”,
discriminadas por “Año de Ingreso” (a la universidad) y “Sexo”. Visualización en formato de grilla.
Desagregar información y filtrar
Se puede acceder a un nivel de información desagregado haciendo clic sobre el valor
deseado, o seleccionándolo de la lista desplegable de la dimensión (siempre que forme parte de la
consulta y se utilice la opción por defecto “Explorar hijos”).
99
Capítulo 6 – Uso de la herramienta y análisis de datos
Si el nivel consultado es el último, el más detallado, dentro de la jerarquía de la dimensión,
la operación de desagregación no muestra nuevos valores, sino que actúa como un filtro sobre la
consulta anterior, dejando visible sólo el valor elegido.
Figura 36. Izquierda: filtro a partir de figura 35, seleccionando el valor “Mujeres” en “Sexo”. Gráficos restantes: drill down
sobre valores de la dimensión “Procedencia”, eligiendo país “Argentina” y luego provincia “San Juan”.
Los filtros también pueden realizarse sobre valores de dimensiones que no estén siendo
visualizadas en la consulta corriente. Los filtros que se efectúen modificarán los resultados
actuales. No hay que perderlos de vista al momento de interpretar los valores mostrados en las
consultas para evitar confusiones.
También es posible seleccionar más de un valor de las dimensiones eligiendo la opción de
“lista de elementos”. Y se puede consultar el desgranamiento de más de un valor al mismo tiempo,
lo que significaría un múltiple drill down. Para esto la herramienta propone las opciones “expandir
todos los hijos”, “expandir todo el nivel”, “explorar nivel” y “mostrar nivel”.
Figura 37. Izquierda: filtro de lista de elementos para los años de ingreso 2000 a 2007.
Derecha: Drill down de más de un elemento utilizando la exploración por niveles (opción: expandir hijos)
100
Capítulo 6 – Uso de la herramienta y análisis de datos
Para volver al nivel anterior (drill up) hay que seleccionar el valor correspondiente en la
dimensión (el padre, un nivel más arriba), asegurándose de tener la opción de visualización por
defecto (“explorar hijos”, no “lista de elementos”). La opción “atrás” es también útil muchas veces
para retornar a consultas anteriores.
6.2 Un ejemplo de análisis sobre evolución de la matrícula
Una de las temáticas a abordar con la información contenida en el caso práctico es la
evolución de la matrícula. En esta sección se muestra como analizar las variaciones sobre la
cantidad de alumnos en los últimos diez años. Se comienza con una consulta general y se va
profundizando en sub-consultas sobre los casos más llamativos. El ejemplo es a modo de guía,
pudiéndose retomar consultas intermedias y seguir analizando sobre otras alternativas.
En toda la sección 6.2 se consideran sólo las personas inscriptas en una única carrera
para simplificar la interpretación de los gráficos y las consultas. Es decir que siempre se asume el
filtro de cantidad de carreras inscripto igual a uno en las consultas40.
Cantidad de alumnos por año académico
Para comenzar se evalúa la cantidad de alumnos por cada año académico41. Partiendo de
la vista inicial del cubo seleccionar la medida de cantidad de alumnos por año académico (“Cant
Alum X Año c/Activ”) y arrastrarla al gráfico en el eje X, en lugar de “Unidad Académica”. Luego
reemplazar la dimensión “Año de Ingreso” por “Año Informado” y seleccionar los años académicos
que resulten de interés, por ejemplo los últimos diez.
40 Al filtrar a las personas inscriptas sólo en una carrera coinciden la cantidad de alumnos con la cantidad de personas, el año de ingreso a la carrera con el año de ingreso a la universidad y todos los datos agregados de totales de materias y demás.41 Se cuentan sólo a los alumnos que presentan algún tipo de actividad, considerando como actividad el hecho de realizar una inscripción (sea a cursado, examen o carrera).
101
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 38. Cantidad de alumnos por año académico en que presentan actividad, para los años 1997-2006.
En el gráfico de la figura 38 se puede observar que el crecimiento más importante en la
matrícula ocurre en el año 2000. También se ve claramente un descenso importante en el año
2006, el último año considerado para este cubo. Es muy importante que el analista de información
tenga en cuenta el contexto de los datos. En este caso ocurre que la información correspondiente
al último año no está completa, y ese es el motivo que explica la diferencia. Posiblemente lo más
conveniente sea descartar este año al hacer análisis comparativos. También al generar el cubo
habrá que considerar si el último año académico ya está cerrado o no. Otra característica
importante a tener en cuenta refiere a la migración de datos. Puede ser que la política de
migración de datos al 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 información y en el rendimiento de los
alumnos.
Retomando el ejemplo del gráfico, se podría sospechar que la matrícula del año 2000
presente un pico justificado por un incremento en la cantidad de ingresantes (por ejemplo
provocado por el inicio de una nueva carrera). Siguiendo esta hipótesis en la figura siguiente se
muestra la apertura de los alumnos según el año de ingreso a la carrera y se calcula el porcentaje
que representan los ingresantes sobre la totalidad de alumnos de cada año académico.
Figura 39. Apertura de cantidad de alumnos por año con actividad según año de ingreso a la carrera.
102
Capítulo 6 – Uso de la herramienta y análisis de datos
Porcentaje correspondiente a los ingresantes sobre el total de alumnos de cada año académico.
En la gráfica se observan dos ventanas con la misma vista para mostrar parte de los años 1997-2000.
En la figura 39 para cada año académico de la dimensión “Año Informado” se calculó el
porcentaje correspondiente a los ingresantes. Se puede observar que este dato representa casi un
35% del total del alumnado en el año 2000, mientras que en el resto de los años se mantiene
alrededor de un 20%. La fórmula utilizada para el cálculo del porcentaje42 respeta la sintaxis
requerida por la herramienta y consiste en sumar los valores de año de ingreso a la carrera
coincidentes con el año informado y calcular el porcentaje sobre el total, para cada año
académico. Por lo tanto en este caso se valida la hipótesis de que el incremento en la cantidad de
alumnos en el año 2000 se debe a un aumento en la cantidad de ingresantes (y no de
reinscriptos).
Otra forma de visualizar esta información puede ser mediante la consulta de la figura
siguiente, donde se permite ver el cruce de todos los años de forma más compacta, facilitando la
comparación.
Figura 40. Porcentaje de cada cohorte sobre el total de alumnos de cada año académico.
El gráfico se obtiene colocando la dimensión año de ingreso como columna y utilizando la opción “desplegar porcentajes
por fila” en lugar de utilizar una función calculada como es el caso de la figura anterior.
En la figura 40 se puede detectar una influencia importante de la cohorte 2000 en los años
siguientes, en comparación con las restantes.
Análisis de ingresantes
Ahora se podría continuar el análisis haciendo hincapié en los ingresantes y prestando
especial atención a la cohorte 2000.
42 @Sum_i((Etiqueta([this.leaf(i)],"Año Informado") == Etiqueta([this.leaf(i)],"Año Ingreso"))? [this.leaf(i)] : 0)*100 /["Total"]103
Capítulo 6 – Uso de la herramienta y análisis de datos
Sobre la vista inicial del cubo elegir la medida “Cant Alumnos”, y seleccionar para la
dimensión “Año Ingreso” los valores que interese evaluar, por ejemplo de 1996 a 2006. Si hubiese
más de una facultad se podría seleccionar una.
Siempre es importante seleccionar la medida adecuada para evitar confusiones posibles y
cruces de variables no válidos. En las gráficas siguientes se utiliza la medida “Cant Alumnos”, que
es diferente a la de las figuras anteriores, “Cant Alum x Año c/Activ”, donde se reflejaba la relación
muchos a muchos entre alumnos y años académicos en que tienen actividad.
En la gráfica de la figura 41 se observa que hubo un pico de ingresantes en el año 2000
superando por más del doble a los años precedentes. La cantidad de alumnos que ingresaron a
las diferentes carreras cayó notoriamente en los años siguientes. Se observa que del año 2000 en
adelante fue disminuyendo, presentando un descenso importante en el año 2005.
Figura 41. Evolución de ingresantes en los últimos 11 años para la facultad 1. Para el gráfico se usaron las opciones de
“lista de elementos” para filtrar los valores de la dimensión “Año Ingreso”, “intercambiar ejes” y “mostrar valores”43.
Se puede hacer la apertura por carrera dentro de esa facultad intentando explicar las
subas y bajas. Es necesario reemplazar la dimensión “Unidad Académica” por “Carrera”. La
gráfica se muestra en modo tabla en la figura siguiente.
43 Los años se muestran en el orden en que se los tilda, que se puede cambiar.104
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 42. Comparación de Ingresantes por cohorte y carrera.
De la figura 42, se observa que muchas carreras son despreciables en cuanto a la
cantidad que aportan al total de ingresantes. También se observa que en el año 2000 se abrió la
inscripción a la “carrera 08” (anteriormente no tiene ingresantes) lo que en principio justifica el pico
de ingresos en ese año.
En la figura 43 se muestra el gráfico de barras comparativo de las tres carreras con mayor
cantidad de ingresantes en cada año.
Figura 43. Evolución de ingresantes de las carreras 07, 08 y 09.
105
Capítulo 6 – Uso de la herramienta y análisis de datos
Se podría corroborar que el incremento de ingresantes en el año 2000 se debe al
comienzo de la “carrera 08” seleccionando dicha carrera y consultando también el “año de egreso
del secundario” de los ingresantes. Luego, calcular el porcentaje de alumnos correspondiente a
cada año de egreso del secundario sobre el total de la cohorte, definiendo una fórmula como la
mostrada en la figura 44.
Figura 44. Ingresantes a la “carrera 08” según “año de egreso del secundario”, y fórmula de porcentaje sobre total de
alumnos de la cohorte.
Observando los diferentes años (figura 45) se puede ver que en general alrededor del 40%
de los ingresantes de cada cohorte finalizan el secundario el año anterior al que comienzan la
carrera universitaria. En el año 2000 los porcentajes son muy diferentes, la cantidad de alumnos
que terminaron el secundario en el año 1998 es equivalente a aquellos que lo hicieron en 1999,
mientras que para los demás años la relación suele ser equivalente a la mitad.
106
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 45. Análisis de ingresantes por cohorte y año de egreso del secundario
para la “carrera 08” y los años 2005, 2004, 2001 y 2000.
Seguimiento de una cohorte
Puede resultar interesante seleccionar esa cohorte (año de ingreso = 2000) y analizar qué
sucedió con esos ingresantes, particularmente evaluar y comparar a quienes egresaron del
secundario en 1998 y 1999. Se podría tener por ejemplo la sospecha que quienes esperaron un
año para poder ingresar a la carrera estarían más seguros y entusiasmados en su decisión de
estudiar; su rendimiento académico y su perseverancia podría superar a los ingresantes recién
salidos del secundario.
Una posible consulta a realizar es la apertura de estos alumnos según el último año en
que registran actividad (inscripción a cursado o examen en alguna materia de la carrera) y según
si han egresado o no (usando la dimensión “cantidad de carreras egresado”).
El gráfico de la figura 46 se obtiene seleccionando el valor 2000 en “año de ingreso”, 1998
y 1999 en “año de egreso del secundario” (usando la opción de “listas de elementos”), cambiando
la ubicación de la dimensión “año de egreso del secundario”, para facilitar la comparación, y
arrojando al gráfico las dimensiones “último año con actividad” y “cant carreras egresado”.
107
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 46. Ingresantes a la “carrera 08” de la cohorte 2000. Comparación de alumnos que terminaron el secundario en
1998 vs. quienes lo hicieron en 1999, según último año de actividad en la carrera y si egresaron o no.
Los casos que presentan último año con actividad en cero es porque nunca tuvieron
actividad en la carrera. Egresado hay sólo un caso; se puede quitar ese nivel de detalle porque no
aporta información significativa. También es interesante ver los porcentajes en lugar de los
números (figura 47. Utilizar la opción “desplegar porcentajes” en “columnas” dentro del menú
“Explorar”).
Figura 47. Consulta de la figura 46 quitando apertura por cantidad de carreras en que egresó y
desplegando porcentajes en las columnas.
Esta información puede visualizarse también de modo gráfico. Para lograr mayor
legibilidad en la lectura es conveniente quitar las dimensiones que están mostrando un único valor
108
Capítulo 6 – Uso de la herramienta y análisis de datos
en el resultado (en este caso “año de ingreso” y “carrera”) y también la fila totalizadora. En las
figuras 48 y 49 se aprecian diferentes visualizaciones de la misma consulta.
Figura 48. Comparación en modo gráfico de ingresantes a la “carrera 08” en el año 2000 según si egresaron del
secundario en 1998 o 1999. Apertura según “último año con actividad”. Vista de porcentajes sobre valores del eje X.
Figura 49. Diferentes visualizaciones gráficas sobre la consulta de la figura 48. En el caso de los gráficos de torta se
observa sobre la parte inferior del lateral derecho la dimensión que en la tabla aparecía como columna.
De las figuras anteriores se puede concluir que la hipótesis planteada para estos casos
sobre la influencia del año de egreso del secundario en la perseverancia en la carrera no sería
cierta, ya que en general quienes ingresaron en 1999 tienen actividad durante más tiempo.
109
Capítulo 6 – Uso de la herramienta y análisis de datos
De todas formas para realizar un análisis más profundo habría que evaluar la calidad de la
actividad tenida. También hay que tener en cuenta que los datos mostrados son ejemplos no
reales y es probable que muestren comportamientos que no sean ciertos.
En la figura 50 se muestran cuadros de comparación entre los ingresantes del año 2000 a
la “carrera 08” que egresaron del secundario en los años 1998 y 1999 según algunas variables
totalizadoras de rendimiento académico. En el ejemplo se observa que en general quienes
egresaron del secundario en 1999 tienen mejor desempeño académico.
Figura 50. Ingresantes a la “carrera 08” de la cohorte 2000. Comparación de alumnos que egresaron
del secundario en el año 1998 y 1999 según totalizadores de cantidad de finales aprobados,
cantidad de cursados aprobados y cantidad de cursados promovidos.
6.3 Ejemplos de análisis de procedencia
Otra temática que resulta interesante analizar es la procedencia de los alumnos. La
procedencia se considera a partir del colegio secundario y presenta los niveles: localidad,
provincia y país. En general interesa llegar al máximo detalle para encontrar la articulación entre
los diferentes colegios secundarios y las carreras de la universidad.
110
Capítulo 6 – Uso de la herramienta y análisis de datos
En esta sección se muestran algunos ejemplos interesantes y otras consultas más
generales, que se utilizan para explicar funcionalidades de la herramienta y como guía para la
obtención de otras nuevas.
Análisis a nivel de país y calidad de datos
En la figura 51 se observa el análisis de procedencia a nivel de país, para las cohortes
2000-2005, evaluando cantidad de personas y cantidad de alumnos. Para obtener el gráfico,
partiendo de la vista inicial del cubo, es necesario: pasar al modo grilla, arrastrar las medidas al
gráfico reemplazando la dimensión “Unidad Académica”, seleccionar la medida “Cant Alumnos”
(además de la ya elegida por defecto), seleccionar los años de ingresos deseados, arrojar la
dimensión “Procedencia” como parte de las filas y agregar los totales por año.
Figura 51. Análisis de procedencia a nivel país para las cohortes 2000-2005 (considerando año de ingreso a la universidad,
que es el nivel comparable por ambas medidas), comparando cantidad de personas con cantidad de alumnos.
La evaluación de la procedencia se ve afectada por la mala calidad de los datos. El dato
de colegio está sin completar en muchos casos y en otros no está asociado a la localidad que le
corresponde. El porcentaje de datos sin completar, que puede apreciarse claramente en la figura
52, es mayor con el correr del tiempo. Esto es preocupante ya que en general la calidad de los
datos debiera tender a mejorar.
111
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 52.Visualización diferente de la información de la figura 51 cambiando la ubicación
de las dimensiones y usando porcentajes por fila para resaltar la falta de completitud de los datos.
Exploración de los niveles de la dimensión procedencia
Al seleccionar un valor de país (por ejemplo haciendo clic sobre “Argentina”) se visualiza el
nivel siguiente en la jerarquía. Los valores de la dimensión conforman un árbol con diferentes
niveles. Se pueden consultar por ramas o por nivel, de a uno o más elementos.
Figura 53. Análisis de procedencia para país “Argentina” de las cohortes 2000-2005. Apertura de provincias y localidades.
112
Capítulo 6 – Uso de la herramienta y análisis de datos
En la figura 53 se observan los valores de los niveles “provincia” y “localidad”
correspondientes al país “Argentina”. La forma utilizada (“Expandir todos los hijos” sobre el nivel
“provincia”) permite ver los subtotales por provincia. Los datos utilizados en el caso práctico no
tienen variaciones importantes en cuanto a provincia de procedencia.
El análisis por colegio secundario también es posible, a través de la opción de visualizar
todo ese nivel (se visualizan todos los colegios de todas las localidades de todas las provincias y
países), o eligiendo una localidad.
La figura 54 surge de seleccionar una localidad en la consulta anterior, pasar la dimensión
“Año Ingreso” a las columnas y agregar totalizadores.
Figura 54. Procedencia de personas y alumnos de las cohortes 2000 a 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 descripción de los
colegios. Este es un problema menor de calidad de datos que habría que resolver, modificando las
descripciones en el sistema SIU-Guaraní.
Articulación de colegios y carreras
Es interesante conocer la relación entre los colegios de procedencia de los alumnos y las
carreras que eligen. Para esto es necesario seleccionar la medida “Cant Alumnos” (ya que “Cant
Personas” queda indefinida a nivel de carrera y utilizar la dimensión “Carrera” como parte de la
consulta. Esto se muestra en la figura 55.
113
Capítulo 6 – Uso de la herramienta y análisis 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 análisis podría realizarse para todos los colegios de una provincia, por
ejemplo, usando las diferentes opciones avanzadas de exploración de la dimensión “Procedencia”.
También es posible tomar a la carrera como el punto de partida para el análisis, para
investigar de donde provienen los alumnos de determinadas carreras. En la siguiente figura se
muestra el ranking de colegios secundarios para los ingresantes del año 2005 a la “carrera 10”.
Figura 56. Procedencia de ingresantes 2005 a la “carrera 10”. Ranking de colegios secundarios.
114
Capítulo 6 – Uso de la herramienta y análisis de datos
Para obtener el gráfico de la figura 56 se debe seleccionar la medida “Cant Alumnos”, la
carrera y el año de ingreso. Respecto a la dimensión “Procedencia” se debe elegir la opción de
“Explorar nivel”, seleccionar “Colegio” y luego “Mostrar nivel” y tildar todas las opciones que se
deseen visualizar. Por último para mostrar ordenado en forma descendente se debe acceder a la
opción “Ranking” dentro del menú “Explorar” y elegir de ordenar la dimensión “Procedencia” por
criterio descendente según la medida corriente.
Aperturas por las otras dimensiones también están permitidas. “Sexo”, “Edad”, “Cant
carreras inscripto-activo” y todas las dimensiones referentes al rendimiento académico de esos
alumnos pueden resultar interesantes. La figura 57 muestra un cuadro que podría obtenerse
combinando totales de cursados promovidos y finales aprobados. Se utiliza una regla para
señalizar los valores diferentes a cero, para facilitar el análisis44.
Figura 57. Posible análisis de rendimiento académico de los alumnos discriminado por colegio de procedencia.
A partir de la figura 56 se incorporan las dimensiones “Cursados Promovidos” y “Finales Aprobados” en su nivel más alto.
Se visualiza sólo el nivel “Colegio” en la dimensión “Procedencia” y se utiliza la opción de “desplegar porcentajes por fila”.
Análisis similares pueden realizarse eligiendo algún colegio y consultando en qué carreras
influye, comparando la procedencia en los diferentes años, etc. También es posible comparar el
rendimiento académico de los alumnos, principalmente durante el primer año de la carrera y
relacionarlo con el colegio del que provienen. Puede ser que determinados colegios con formación
más afín respecto a la carrera tengan una influencia positiva en el rendimiento académico de los
alumnos, o que no resulte lo esperado.
44 La definición de reglas con O3 queda fuera del alcance de esta tesis. Consultar la documentación de la herramienta.115
Capítulo 6 – Uso de la herramienta y análisis de datos
6.4 Un ejemplo de desgranamiento basado en la actividad académica y rendimiento
El desgranamiento generalmente es evaluado por cohortes. Este análisis comienza a partir
de los individuos, el año de ingreso a la universidad y se realiza un seguimiento de los años en
que han tenido actividad. En este caso se inicia la exploración a nivel de personas y no a nivel de
alumno. Luego se desgrana la información por alumno.
Último año con actividad
El cuadro de la figura 58 muestra el año de ingreso y el último año con actividad para la
medida “Cant Personas”. Se puede observar que hay una cantidad importante de inscriptos que no
tienen actividad académica en ningún año, reflejados por último año con actividad igual a cero.
Figura 58. Cantidad de personas por año de ingreso, discriminados según el último año de actividad.
Los subtotales muestran la cantidad de personas que ingresaron a la universidad en cada año.
La misma información puede visualizarse de otra manera en la figura siguiente, en
cantidades absolutas y también en porcentajes sobre el total de cada cohorte45.
45 Se utiliza el término cohorte para referirse al año de ingreso, a la universidad, o a la carrera. Aunque en general el uso más común es el segundo ambos son aceptables. Además, la mayoría de las personas se inscriben sólo a una carrera, por lo tanto los valores suelen ser coincidentes.
116
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 59. Cantidad de personas por año de ingreso y año de última actividad,
en cantidades absolutas y en porcentajes sobre el total de la cohorte.
Personas y alumnos
La relación entre “Cant Personas” y “Cant Alumnos” depende de la cantidad de carreras
en que se haya inscripto cada individuo. Así quienes se anotan sólo en una cuentan una vez como
persona y una vez como alumno. En estos casos, el año de ingreso a la universidad coincide con
el año de ingreso a la carrera, y también coinciden los totalizadores de rendimiento académico.
Mientras que quienes se hayan inscripto en más de una carrera presentan diferencias según el
nivel en que se analice la información.
En este trabajo la actividad anual se calcula sólo a nivel de alumno (medida “Cant Alum X
Año c/Activ””), por eso es necesario evaluar la relación entre personas y alumnos como paso
intermedio al intentar evaluar el rendimiento anual.
En la figura 60 se puede observar la relación entre personas y alumnos a partir de la
cantidad de carreras en que se inscriben, y las diferencias al considerar el año de ingreso a la
universidad y el año de ingreso a la carrera.
117
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 60. Comparación de “Cant Personas” y “Cant Alumnos”.
Apertura por “Cant carreras inscripto” y “Año de Ingreso”, a la universidad y a la carrera.
Cuadros similares a los de la sección 6.4.1 podrían armarse eligiendo cantidad de
alumnos por ultimo año de actividad en la universidad y también por último año de actividad en la
carrera. En la figura 61 se muestra la apertura de ambas medidas según el año de ingreso a la
universidad y el último año con actividad en esta.
Figura 61. “Cant Personas” y “Cant Alumnos” según “Año Ingreso a la universidad” y
118
Capítulo 6 – Uso de la herramienta y análisis de datos
“Último año con actividad en la universidad”
Actividad anual de las cohortes
Además de la apertura por último año con actividad es interesante evaluar la actividad en
cada año. Eso es posible consultando la cantidad de alumnos por año académico en que realizan
alguna actividad y comparando el valor con la cantidad de alumnos. Para esto es necesario utilizar
la medida “Cant Alum X Año c/Activ” que cuenta a cada alumno tantas veces como años en los
cuales realiza alguna actividad académica, y realizar la apertura por la dimensión “Año Informado”.
Los valores mostrados en la figura 62 deben ser analizados en función de la cantidad de alumnos
mostrada en la figura 61, Por ejemplo: de los 12 alumnos (correspondientes a 10 personas) que
ingresaron en 1994 y tuvieron actividad por última vez en el año 2001 (fila 9 de la figura 61), 10 de
ellos tuvieron actividad académica en 1994, 1995, 1996 y 2001, equivalentes al primer, segundo,
tercer y octavo año de las carreras, respectivamente. 9 de ellos tuvieron actividad durante los años
1997, 1998 y 1999, y sólo 7 tuvieron actividad en el año 2000 (filas 3 a 10 del cuadro de la
derecha de la figura 62).
Figura 62. Alumnos por año académico en que presentan actividad. Apertura por año de ingreso a la universidad
y último año con actividad. Contrastar con la cantidad de alumnos de la figura 61.
Resulta interesante calcular el porcentaje de alumnos de cada cohorte que tienen
actividad en cada año académico. La figura 63 se logra a partir de la anterior, quitando la
dimensión “Último año con actividad” y filtrando algunos valores de “Año Informado” para obtener
un gráfico más simple. La medida “Cant Alumnos” está indefinida por “Año Informado”, por eso
muestra siempre el total de alumnos de cada año de ingreso46.
46 Es intencional y es la forma que presenta O3 para permitir la comparación de estas medidas por “Año Informado”.Hay otras formas de obtener el dato del porcentaje a partir de otras vistas que requieren fórmulas de cálculo o diseño del modelo más complejos.
119
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 63. Porcentaje de alumnos con actividad calculado sobre el total de ingresantes de la cohorte.
Seguimiento de una cohorte
Se puede seguir profundizando en conjunto o seleccionar una cohorte que resulte de
interés, por ejemplo la cohorte 1997 que al año 2006 lleva 10 años dentro de la universidad y tiene
un total de 380 ingresantes (observar en figura 60, total de “Cant Alumnos” con año de ingreso a la
universidad 2007 o total de figura 65)47.
Figura 64. Cantidad de alumnos de la cohorte 1997 que tienen actividad en cada año académico.
47 Se considera como cohorte al año de ingreso a la universidad para que los ejemplos sean más sencillos. También podría tomarse el año de ingreso a la carrera. Incluso si resultara complejo seleccionar los valores podría modelarse el año de ingreso a la carrera como una dimensión independiente.
120
Capítulo 6 – Uso de la herramienta y análisis de datos
La actividad anual de los 380 ingresantes puede verse en el gráfico de la figura 64. Es
muy interesante observar como en este caso se va perdiendo la cantidad de alumnos a medida
que pasan los años. Esto puede deberse a diferentes motivos: que abandonan sus estudios, que
se cambian de carrera, o que egresan.
Se puede discriminar a estos alumnos por otras variables para estudiar la cohorte en
detalle. En la figura 65 se observa el total de alumnos de la cohorte 1997 según el último año en
que realizan actividad académica en la carrera y en la universidad y su calidad de egresados.
Sobre el total de 380 ingresantes 10 son egresados en alguna carrera y 129 nunca tuvieron
actividad en la carrera (se obtiene sumando todos los casos con último año con actividad en la
carrera igual a cero), de los cuales 116 no tuvieron actividad en ninguna carrera, los otros 13 sí.
Figura 65. Cantidad de alumnos de la cohorte 1997 según último año con actividad (en la universidad y en la carrera) y
su calidad de egresado (dado por el valor de cantidad de carreras egresado igual a uno)
121
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 66. Cantidad de alumnos y de personas que ingresaron en 1997 discriminadas por último año en que registran
actividad (en la universidad solamente para simplicidad del gráfico), cantidad de carreras en que se encuentra activo /
cantidad de carreras en que se inscribió y cantidad de carreras en que egresó.
Para evaluar el movimiento a otras carreras se puede comparar la cantidad de alumnos
con la cantidad de personas y discriminar ambas medidas por la cantidad de carreras en la que se
encuentra activo el individuo.
El cuadro de la figura 66 resulta complejo a simple vista. Si se lee por partes:
- Existen 8 personas que se inscribieron sólo a una carrera (corresponden a 8 alumnos) y
no están activos, todos ellos son egresados (observar la primera columna para “Cant
Alumnos” y para “Cant Personas”).
- La mayoría de los casos están inscriptos, activos y no egresados en sólo una carrera. Se
trata de 290 alumnos (que son 290 personas).
- Hay una persona que se inscribió a dos carreras y está activo en una y egresado en una
(tercera columna en ambos casos. En la figura 67 se ven más detalles de este caso).
- Para los casos restantes, que están activos e inscriptos en más de una carrera (2/2 y 3/3),
en la grilla sólo se muestran los años de ingreso a las carreras, sería interesante realizar la
apertura por carrera y por último año de actividad en la carrera para continuar la
evaluación.
La misma apertura por cantidad de carreras activo y cantidad de carreras donde egresó se
puede realizar sobre la figura 64, para evaluar la actividad anual de los alumnos teniendo en
cuenta esos criterios.
Figura 67. Cantidad de alumnos de la cohorte 1997 según año académico en que registran actividad discriminados por
cantidad de carreras en que se encuentra activo/cantidad de carreras inscripto y cantidad de carreras en que egresó.
Y se puede visualizar por carrera para ver donde se producen las simultaneidades.
122
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 68. Comparación de alumnos con actividad por año, alumnos y personas correspondientes al año de ingreso a la
universidad 1997, según cantidad de carreras en que está activo/cantidad de carreras inscripto, cantidad de carreras en
que es egresado y carrera en los casos correspondientes.
Es válido comparar la cantidad de alumnos con actividad con la cantidad de alumnos total
y la cantidad de personas, y sobre esa base realizar filtros para profundizar el análisis. Por
ejemplo, si focalizamos sobre quienes egresaron en alguna carrera podemos obtener el cuadro de
la figura 69 donde se observan más detalles sobre su condición de alumnos (año de ingreso a la
carrera, último año de actividad en la carrera). Observar que totalizan 10 alumnos, pero egresados
son 9, ya que existe una persona que se inscribió en dos carreras pero sólo egresó en una de
ellas. Este individuo comienza la carrera 07 en 1997 y la deja ese mismo año, y en el 2000
comienza la carrera 08, en la que tuvo actividad por última vez en el año 2005, lo que indicaría que
es la carrera en la que egresó. Los otros casos estarían egresando en 2005 y 2006 (que es
cuando registran actividad por última vez) en sus respectivas carreras. Si se deseara hacer un
análisis más profundo sobre los egresados habría que utilizar algunas otras variables no incluidas
en el Data Mart.
Respecto a los alumnos activos en más de una carrera, observando en detalle la parte
derecha de figura 68 se puede concluir que, para esta cohorte, no es muy común el comienzo de
dos carreras en paralelo: de las 40 personas en cuestión (total de inscriptos en 2 y 3 carreras -
1+37+2 en cuadro inferior derecho-) sólo 4 comienzan dos carreras en simultáneo (20+21=41
alumnos –filas 7 a 9 de la columna 4 en cuadro superior derecho- que corresponden a 37
personas – columna 4 en cuadro inferior derecho-). En general comienzan la otra carrera después,
sea de grado o postgrado (observar los valores de año de ingreso a carrera para estos casos). 123
Capítulo 6 – Uso de la herramienta y análisis de datos
Figura 69. Análisis de los alumnos que ingresaron a la universidad en 1997 y egresaron en alguna carrera.
Seguimiento de subconjunto mayoritario de una cohorte. Análisis por carrera y rendimiento
Los casos de egresados y simultaneidad de carreras vistos recientemente podrían ser
descartados del análisis, ya que no representan a la mayoría de los casos. Se opta por elegir los
alumnos que están inscriptos y activos sólo en una carrera y que aún no han egresado para
continuar el desgranamiento según el rendimiento académico. Sobre esos casos pretende realizar
un análisis comparativo por carrera. También se descarta a los alumnos de carreras de postgrado
porque, además de ser pocos casos, son muy particulares y la evaluación de desgranamiento
sería diferente.
Figura 70. Alumnos de la cohorte 1997 activos en sólo una carrera y no egresados. Cantidad total (gráfico inferior derecho)
y cantidad discriminada por año en que tienen actividad académica. Sólo se consideran las carreras de grado.
El mismo análisis puede hacerse seleccionando más de una cohorte. En la figura siguiente
se muestran, además de la cohorte 1997, la anterior y la siguiente para realizar la comparación.
124
Capítulo 6 – Uso de la herramienta y análisis 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 análisis más intensivos para profundizar en el
desgranamiento, por ejemplo utilizando variables de rendimiento académico como la cantidad de
cursados o finales aprobados. En la figura 72 se aprecia la apertura de estos alumnos según el
total de cursados aprobados en la carrera.
Figura 72. Alumnos de carreras de grado de las cohortes 1996-1998 inscriptos y activos en una carrera y no egresados,
según total de cursados aprobados en la carrera.
125
Capítulo 6 – Uso de la herramienta y análisis de datos
En la figura 73 se ve el detalle de cursados aprobados por año académico de un
subconjunto de estos alumnos. Para el gráfico se selecciona la cohorte 1997 y la carrera 10, y se
muestra el desglose del total de cursados aprobados acumulados en la carrera por cada año en
que los alumnos tienen actividad.
Figura 73. Detalle de cursados aprobados por año académico y total de cursados aprobados en la carrera
de los alumnos de la cohorte 1997 activos sólo en carrera 1048.
El análisis completo debiera contemplar varias de estas dimensiones y utilizarlas en forma
combinada, calculando por ejemplo el total de cursados regularizados (cursados aprobados más
cursados promovidos) o el total de materias aprobadas (finales aprobados más cursados
promovidos).
La intención de estos ejemplos es presentar la potencialidad de la solución. Se deja en
manos del lector la exploración de las posibles consultas, y fórmulas que puedan obtenerse y
agregarse según las propias necesidades.
48 Tener en cuenta que los cursados promovidos se cuentan como tales y no como aprobados. Ese es el motivo de que las cantidades sean números pequeños.
126
Capítulo 7 - Conclusiones y trabajo futuro
7 Conclusiones y trabajo futuro
7.1 Conclusiones
La implementación de soluciones para analizar información como la presentada en este
trabajo genera muchos beneficios. Entre los más importantes se destacan los siguientes:
- El acceso a los datos es fácil y rápido y permite a los usuarios hacer sus propias
consultas. También se logra independencia del personal técnico para la obtención de
nuevos reportes.
- La información se obtiene de manera sencilla y a través de imágenes integradas de los
datos.
- Facilita el proceso de comparación, proyección a futuro, relación con otros datos, muestra
de indicadores, información consolidada, etc.
- Ayuda a mejorar el buen funcionamiento de los sistemas de gestión retroalimentando
demandas para estos.
Lograr la implementación y el uso real de los sistemas para el soporte de decisiones no es
una tarea sencilla y generalmente requiere enfrentar varios problemas. La mayoría de los
problemas surgen en cualquier proyecto de Data Warehousing, otros son propios de la realidad del
ámbito universitario o de la administración pública. Algunos de los más frecuentes son:
- Infravaloración del esfuerzo necesario para el diseño y la creación de un DW.
- Infravaloración de los recursos necesarios para la extracción, transformación, 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 evolución.
Recursos humanos que puedan mantener y hacer evolucionar todo el
sistema para análisis de información.
127
Capítulo 7 - Conclusiones y trabajo futuro
Apoyo técnico del área de sistemas.
- Existencia o adquisición del hardware necesario.
La incorporación 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
gestión.
- Impulsar el uso de la información como una herramienta para la toma de decisiones y la
planificación.
- 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 síntesis y como conclusión del presente trabajo se puede decir que estas herramientas
convierten datos crudos en información valiosa y ayudan a los directivos a tomar decisiones.
Permiten lograr una visión más completa e integral de la organización, entender los eventos en
forma sistemática, para así redefinir estrategias. El resultado de su implementación es
conocimiento acerca del funcionamiento de la organización.
7.2 Trabajo futuro
Son muchas las cosas por hacer aún, desde lo técnico hasta la promoción y motivación
para lograr el uso real en la toma de decisiones, pasando por la definición de criterios sobre
consideraciones de los datos.
Desde el punto de vista técnico y funcional, se podrían incorporar modificaciones a las
soluciones actuales o desarrollar nuevos componentes dentro de la totalidad del sistema para
análisis de información. Las siguientes son algunas de las posibles modificaciones a considerar:
- Modelar algunos datos de forma diferente en el cubo propuesto para permitir la obtención
de otros reportes. Ejemplos:
Se podrían incorporar como medidas a las actuales dimensiones de
rendimiento académico (cursados aprobados, cursados desaprobados, etc.). De esta
forma se permitiría fácilmente totalizar las materias regularizadas (cursados
aprobados más cursados promovidos) y las materias aprobadas (cursados
promovidos más finales aprobados).
Definir niveles de actividad para combinar los valores de las dimensiones
finales aprobados, finales desaprobados, cursados aprobados, etc. en una o más
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
Capítulo 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 más detallados de datos existentes. Ejemplos:
Agregar al modelo algunas de las dimensiones que forman parte de los
archivos de texto, por ejemplo: duración del plan, calidad del alumno, promedio, etc.
Incluir el dato de materia en relación con el alumno para poder detectar en
que materias se presentan los mayores problemas de desaprobación de
determinado conjunto de alumnos.
Incorporar mayor cantidad de datos sobre egresados.
Incluir información del contexto socio económico de los alumnos.
Esto requiere que los datos respectivos (condición laboral del alumno, estudios de
los padres, composición del grupo familiar, situación económica del grupo familiar,
etc.) estén completos y sean de buena calidad. Por otro lado se requiere definir la
forma de unirlos con la información académica (establecer una correspondencia
entre las diferentes fechas en que los datos censales son relevados y los períodos
del año académico donde debieran ser considerados).
Incorporación de datos derivados como movilidad, simultaneidad de
carreras y lentificación, previa definición de estos.
La información existente en los cubos actuales podría ser de utilidad para definir
alguno de estos indicadores.
- Desarrollar modelos de análisis sobre nuevas temáticas. Por ejemplo incorporación de
materias por créditos o puntos que aportan, y posicionamiento de los alumnos en el plan
de estudio.
- Crear un DW en la universidad con la información proveniente del SIU-Guaraní.
El DW debería contener la información 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 podrían incorporarse también datos provenientes de otros sistemas de
gestión, incluyendo temáticas tales como becas, presupuesto o recursos humanos. De
esta forma sería posible obtener indicadores que relacionen por ejemplo el rendimiento
académico de los alumnos que obtienen becas, o de los alumnos que trabajan como
ayudantes de cátedra en la universidad, entre otras cosas.
- Toda la solución podría implementarse con herramientas de software libre.
Al momento de comenzar el trabajo en esta tesis no había herramientas de software libre
con la madurez de desarrollo ni la difusión actual. Además en la UNS y en
aproximadamente en otras quince Universidades Nacionales ya se estaba utilizando O3.
129
Capítulo 7 - Conclusiones y trabajo futuro
Se espera que este trabajo sea un aporte para el análisis de la problemática universitaria
en cuestión y que la base teórica y el aporte de la experiencia personal contribuyan al crecimiento
de las soluciones actuales y al desarrollo de nuevas propuestas.
130
Capítulo 8 – Apéndice. Documentación técnica del caso de estudio
8 Apéndice. Documentación técnica del caso de estudio
8.1 Descripción técnica de las variables del cubo
Dimensiones
Nombre Descripción Forma de cálculoUnidad académica Unidad académica a la
que corresponde el alumno o persona.
Este dato corresponde a los campos sga_personas.unidad_academica y sga_alumnos.unidad_academica. También forma parte de la clave primaria de muchas de las tablas y se utiliza para realizar las uniones.
Año Ingreso(Año Ingreso a la Universidad Año Ingreso a la Carrera)
En el primer nivel se muestra el año en que cada persona ingresa a la universidad, a la primera carrera de la cual se tiene registro como alumno en la base de datos del SIU-Guaraní.A nivel de alumno se muestra el año de ingreso a cada carrera.
Para cada alumno se recupera el año de ingreso mediante el proceso sp_int_arau_dating (que se utiliza para informar a araucano). El dato corresponde al año académico en que se inscribe a la carrera y resulta ingresante o alumno condicional: sga_periodo_insc.anio_academico tomando como nexo el periodo de inscripción de sga_carrera_aspira.periodo_inscripcio. (donde se busca el registro como aspirante correspondiente a cada alumno)En caso que este registro no exista se completa con el año de la fecha en que se generó el legajo del alumno (sga_alumnos.fecha_ingreso).A nivel de persona se considera el mínimo valor de los años de ingreso a las diferentes carreras.
Año Informado Año académico en que se efectúa la actividad de los alumnos.
Se toma de cada una de las tablas de actividad consideradas, según lo que se esté contando.Para cursados y promociones: sga_comisiones.anio_academicoPara finales: sga_actas_examen.anio_academicoY para las equivalencias, se toma el año académico correspondiente a sga_equiv_otorgada.fecha (se verifica que esa fecha esté entre sga_anio_academico.fecha_inicio y sga_anio_academico.fecha_fin)
Último año con actividad (Último año con actividad en la Universidad Último año con actividad en la Carrera)
Indica el último año en que las personas o alumnos tienen actividad, a nivel de toda la universidad o de cada carrera.
Se calcula a partir de los años académicos en que los alumnos registran actividad (valores de la dimensión Año Informado). A nivel de alumno se toma el máximo valor encontrado por carrera, y a nivel de persona se calcula el máximo de estos.
Edad (Edad al Ingreso Universidad Edad al Ingreso Carrera Edad al Año Informado)
Edad de los individuos en cada año considerado, al último día del año calendario (31/12)
Se calculan a partir de la fecha de nacimiento de las personas (sga_personas.fecha_nacimiento)Para la edad al año de ingreso a la universidad, se le resta al año de ingreso a la universidad el año de nacimiento de la persona. Lo mismo se realiza para los años de ingreso a carrera y los diferentes años
131
Capítulo 8 – Apéndice. Documentación técnica del caso de estudio
informados.Sexo Género de los
individuos.Corresponde al campo sga_personas.sexo.
Nacionalidad Nacionalidad de los individuos
Corresponde al campo sga_personas.nacionalidad.
Procedencia (País Provincia Localidad Colegio)
Colegio secundario del que egresó el estudiante.Localidad asociada al colegio. Provincia a la que corresponde dicha localidad.País al que corresponde la provincia.
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 país que correspondan a la localidad utilizando las tablas mug_localidades, mug_dptos_partidos, mug_provincias y mug_paises.
Título Secundario Título del colegio secundario obtenido por cada individuo
Corresponde al campo sga_personas.titulo_secundario
Año Egreso Sec Año de egreso del secundario
Corresponde al campo sga_personas.anio_egreso_sec
Orient vocacional Indica si la persona recibió o no orientación vocacional.
Corresponde al campo sga_personas.orient_voc_rec
Cant carreras inscripto – activo (Cant carreras inscripto Cant carreras activo/inscripto)
Cantidad de carreras diferentes en que se inscribió cada persona y la cantidad en que está activa. Se muestran dos niveles: el superior indica la cantidad de inscripciones y el otro en cuántas está activo sobre el total de inscripciones
Las carreras activas se calculan contando la cantidad de registros en sga_alumnos con calidad activa (sga_alumnos.calidad=’A’) agrupando por persona (unidad académica y número de inscripción).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
Cant carreras egresado
Cantidad de carreras en que la persona registra calidad de egresado.
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 académica y número de inscripción).
Carrera Carrera asociada al alumno.
Corresponde al campo sga_alumnos.carrera.Este campo también se utiliza al calcular la actividad, formando parte de la unión entre la tabla de alumnos y las de cursados, exámenes y equivalencias.
Cursados Aprobados (Cursados Aprobados Totales por Persona Cursados Aprobados Totales en la Carrera Cursados Aprobados en la Carrera y Año Informado)
Cantidad de cursados aprobados registrados en actas cerradas, para cada año académico, totales por carrera, y sumatoria de todas las carreras.
Se cuentan los registros en actas de cursado cerradas con resultado aprobado (‘A’) para cada año académico y alumno (mediante la unión 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.
Cursados Desaprobados (Cursados Desaprobados Totales por Persona Cursados Desaprobados Totales en la Carrera
Cantidad de cursados desaprobados registrados en actas cerradas, para cada año académico, totales por carrera, y sumatoria de todas las carreras.
Se cuentan los registros en actas de cursado cerradas con resultado desaprobado (‘R’) para cada año académico y alumno (mediante la unión 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
Capítulo 8 – Apéndice. Documentación técnica del caso de estudio
Cursados Desaprobados en la Carrera y Año Informado)Cursados Promovidos (Cursados Promovidos Totales por Persona Cursados Promovidos Totales en la Carrera Cursados Promovidos en la Carrera y Año Informado)
Cantidad de cursados promovidos registrados en actas de cursado cerradas, para cada año académico, totales por carrera, y sumatoria de todas las carreras.
Se cuentan los registros en actas de cursado cerradas con resultado promovido (‘P’) para cada año académico y alumno (mediante la unión 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.
Finales Aprobados (Finales Aprobados Totales por Persona Finales Aprobados Totales en la Carrera Finales Aprobados en la Carrera y Año Informado)
Cantidad de exámenes finales aprobados registrados en actas cerradas, para cada año académico, totales por carrera, y sumatoria de todas las carreras.
Se cuentan los registros, no rectificados, en actas de examen cerradas con resultado aprobado (‘A’) para cada año académico y alumno (mediante la unión de las tablas: sga_detalle_acta y sga_actas_examen).Luego se sumarizan por alumno, para el nivel carrera, y por persona.
Finales Desaprobados (Finales Desaprobados Totales por Persona Finales Desaprobados Totales en la Carrera Finales Desaprobados en la Carrera y Año Informado)
Cantidad de exámenes finales desaprobados registrados en actas cerradas, para cada año académico, totales por carrera, y sumatoria de todas las carreras.
Se cuentan los registros, no rectificados, en actas de examen cerradas con resultado desaprobado (‘R’) para cada año académico y alumno (mediante la unión de las tablas: sga_detalle_acta y sga_actas_examen).Luego se sumarizan por alumno, para el nivel carrera, y por persona.
Equivalencias Externas (Equivalencias Externas Totales por Persona Equivalencias Externas Totales en la Carrera Equivalencias Externas en la Carrera y Año Informado)
Cantidad de equivalencias totales otorgadas (con origen externo o de pase), para cada año académico, totales por carrera, y sumatoria de todas las carreras.
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 año académico y alumno (mediante la unión de las tablas: sga_equiv_otorgada y sga_equiv_operac).El año académico 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 Descripción Forma de cálculoCant Personas
Cantidad de personas registradas en la base de datos del SIU-Guaraní.
Se cuentan todos los registros existentes en la tabla sga_personas.
Cant Alumnos
Cantidad de alumnos registrados en la base de datos del SIU-Guaraní.
Se cuentan todos los registros existentes en la tabla sga_alumnos.
Cant Alum X Año c/Activ
Cantidad de registros resultante de contar a cada alumno en cada año académico 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). Sólo se
Para cada alumno y cada año académico a partir del año 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
Capítulo 8 – Apéndice. Documentación técnica del caso de estudio
consideran actas cerradas y registros que no estén rectificados (cualquiera sea el resultado: aprobado, desaprobado, promovido y ausente, porque el hecho de inscribirse se lo considera actividad, o al menos intención de tenerla).Se busca actividad a partir del año de ingreso a la carrera hasta la fecha corriente.
desaprobados, promocionados y ausentes- de exámenes (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 año académico correspondiente.
Para mayor detalle consultar las consultas SQL de los procesos de extracción 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 sección 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 información contenida en tablas generales de la
versión 2.3 o posterior del sistema SIU-Guaraní. No contiene información 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 sección 8.1) podrían modificarse o
personalizarse para contemplar los cambios que sean de utilidad.
- La construcción 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 política de actualización del cubo acorde a los momentos en que
se necesita información y en que se dispone de datos estables.
Tener en cuenta que si los datos que se incorporan al Data Mart no son estables podrán
surgir variaciones luego. Por ejemplo, en la cantidad de ingresantes, (si no finalizó el
período de inscripción a carreras en el momento en que se genera el cubo) y en las
variables totalizadoras de actividad (si no están ingresadas y cerradas todas las actas al
sistema).
Algunas de estas variaciones pueden parecer inconsistentes, como podría ser el caso de
los alumnos condicionales que son contados como ingresantes; si en algún momento
estos fueran rechazados en el sistema de gestión al regenerarse el cubo la cantidad de
ingresantes será menor.
134
Capítulo 8 – Apéndice. Documentación técnica del caso de estudio
8.3 Estructuras de los archivos de texto
Tabla: int_dw_personas.txt
Campos Tipo de datoCódigo de unidad académica TextoNúmero de Inscripción TextoTipo de documento TextoNúmero de documento TextoCódigo de sexo TextoFecha de Nacimiento Fecha. MM/DD/AAAACódigo de nacionalidad NuméricoCódigo de colegio secundario NuméricoCódigo de Título del secundario NuméricoAño de egreso del secundario NuméricoCódigo de si recibió orientación vocacional o no NuméricoCantidad de carreras en que se encuentra activa la persona NuméricoCantidad de carreras en que egresó la persona NuméricoCantidad de carreras en que se inscribió la persona NuméricoCantidad total de readmisiones de la persona NuméricoAño de Ingreso a la Universidad NuméricoÚltimo año en que tiene actividad en la universidad NuméricoTotal de cursados aprobados de la persona NuméricoTotal de cursados desaprobados de la persona NuméricoTotal de cursados promovidos de la persona NuméricoTotal de cursados ausentes de la persona NuméricoTotal de finales aprobados de la persona NuméricoTotal de finales desaprobados de la persona NuméricoTotal de finales ausentes de la persona NuméricoTotal de equivalencias externas de la persona NuméricoTotal de equivalencias parciales de la persona NuméricoCantidad de Personas Numérico. Es siempre 1.
Tabla: int_dw_alumnos.txt
Campos Tipo de datoCódigo de unidad académica TextoCódigo de carrera TextoNúmero de Legajo TextoCódigo del plan de estudio actual del alumno TextoNúmero de Inscripción TextoCódigo de condición de regularidad del alumno en la carrera Texto (S/N)Cantidad de readmisiones en la carrera NuméricoCódigo de calidad del alumno (activo, pasivo, egresado, de baja) Texto (A/P/E/N)Año de Ingreso a la carrera NuméricoCantidad de veces que realizó cambios de plan en la carrera NuméricoCantidad de veces que intentó ingresar a la carrera NuméricoPromedio del alumno en la carrera Numérico con decimalesDuración teórica del plan en años NuméricoCantidad de materias del plan NuméricoCantidad de materias optativas del plan NuméricoEstado del plan (vigente, activo, etc.) TextoÚltimo año en que tiene actividad en la carrera NuméricoTotal de cursados aprobados en la carrera NuméricoTotal de cursados desaprobados en la carrera NuméricoTotal de cursados promovidos en la carrera NuméricoTotal de cursados ausentes en la carrera Numérico
135
Capítulo 8 – Apéndice. Documentación técnica del caso de estudio
Total de finales aprobados en la carrera NuméricoTotal de finales desaprobados en la carrera NuméricoTotal de finales ausentes en la carrera NuméricoTotal de equivalencias externas en la carrera NuméricoTotal de equivalencias parciales en la carrera NuméricoCantidad de Alumnos Numérico. Es siempre 1.
Tabla: int_dw_desercion_alumnos_anio.txt
Campos Tipo de datoCódigo de unidad académica TextoCódigo de carrera TextoNúmero de Legajo TextoNúmero de Inscripción TextoAño de Ingreso a la carrera NuméricoAño informado, correspondiente a cada año académico en que el alumno tiene actividad en la carrera
Numérico
Total de cursados aprobados en la carrera y en el año informado NuméricoTotal de cursados desaprobados en la carrera y en el año informado NuméricoTotal de cursados promovidos en la carrera y en el año informado NuméricoTotal de cursados ausentes en la carrera y en el año informado NuméricoTotal de finales aprobados en la carrera y en el año informado NuméricoTotal de finales desaprobados en la carrera y en el año informado NuméricoTotal de finales ausentes en la carrera y en el año informado NuméricoTotal de equivalencias externas en la carrera y en el año informado NuméricoTotal de equivalencias parciales en la carrera y en el año informado NuméricoCantidad de Registros (Alumnos X Año con actividad) Numérico. Es siempre 1.
Tabla: LT_Carreras.txt
Campos Tipo de datoCódigo de unidad académica TextoCódigo de carrera TextoNombre de carrera Texto
Tabla: LT_Colegios.txt
Campos Tipo de datoCódigo de colegio secundario NuméricoNombre de colegio TextoCódigo de localidad Numérico
Tabla: LT_Localidades_ColSec.txt
Campos Tipo de datoCódigo de localidad NuméricoNombre de localidad TextoCódigo de Provincia Numérico
Tabla: LT_Provincias.txt
Campos Tipo de datoCódigo de Provincia NuméricoNombre de Provincia TextoCódigo de País Numérico
Tabla: LT_Paises.txt
Campos Tipo de dato136
Capítulo 8 – Apéndice. Documentación técnica del caso de estudio
Código de país NuméricoNombre de país Texto
Tabla: LT_Sexos.txt
Campos Tipo de datoCódigo de sexo TextoDescripción de sexo Texto
Tabla: LT_Nacionalidades.txt
Campos Tipo de datoCódigo de nacionalidad NuméricoDescripción de nacionalidad Texto
Tabla: LT_TitulosSecundario.txt
Campos Tipo de datoCódigo de Título del secundario NuméricoNombre de Título del secundario Texto
Tabla: LT_UnidadesAcademicas.txt
Campos Tipo de datoCódigo de unidad académica TextoNombre de unidad académica Texto
8.4 Generación del cubo
Para utilizar la solución propuesta se requiere:
- Tener instalada la herramienta O3
Se utiliza la versión 4.3 de este software49. Si no estuviese instalada en la universidad se
puede bajar una versión de evaluación por treinta días de www.ideasoft.com.uy en la
sección 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 versión 2.3 o posteriores de SIU-Guaraní. Se probó
sobre versión 2.5.2.
Los procesos a correr no han sido aún incorporados al código núcleo 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 SIU-
Araucano 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 sería necesario
49 Al momento de presentar la tesis ya ha sido lanzada la versión 5 de O3. Esta solución es perfectamente compatible.137
Capítulo 8 – Apéndice. Documentación técnica del caso de estudio
ejecutar para generar un cubo con información de 1994 a 2007. Puede utilizarse de
ejemplo tomando sólo lo que necesite.
Luego deben ejecutarse los otros archivos en el orden en que están numerados. En el
último de ellos “7_generacion_txt.sql” puede modificarse el directorio destino para los
archivos de texto.
Observación: es interesante comentar que cualquier conjunto de datos que respete las
estructuras de las tablas detalla en la sección 8.3 podrá ser usado como fuente para
generar un cubo, no es necesario que la información 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 cómo 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 versión digital de este documento.
50 La generación explicada aquí es para ser utilizada en sistemas operativos Windows. Es posible trabajar en Linux, sólo hay que realizar pequeñas 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
Capítulo - Bibliografía
Bibliografía
[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. “Teoría sobre Business Intelligence” Concurso MicroStrategy
Experiencia Business Intelligence 2da. Edición
[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
Capítulo - Bibliografía
[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-en-
business_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-en-
business_16.html
140
top related