Tesis Dw Cecilia Domina

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

Transcript of Tesis Dw Cecilia Domina

Page 1: Tesis Dw Cecilia Domina

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

Page 2: Tesis Dw Cecilia Domina

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

Page 3: Tesis Dw Cecilia Domina

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

Page 4: Tesis Dw Cecilia Domina

Í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

Page 5: Tesis Dw Cecilia Domina

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

Page 6: Tesis Dw Cecilia Domina

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

Page 7: Tesis Dw Cecilia Domina

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

Page 8: Tesis Dw Cecilia Domina

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

Page 9: Tesis Dw Cecilia Domina

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

Page 10: Tesis Dw Cecilia Domina

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

Page 11: Tesis Dw Cecilia Domina

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

Page 12: Tesis Dw Cecilia Domina

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

Page 13: Tesis Dw Cecilia Domina

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

Page 14: Tesis Dw Cecilia Domina

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

Page 15: Tesis Dw Cecilia Domina

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

Page 16: Tesis Dw Cecilia Domina

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

Page 17: Tesis Dw Cecilia Domina

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

Page 18: Tesis Dw Cecilia Domina

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

Page 19: Tesis Dw Cecilia Domina

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

Page 20: Tesis Dw Cecilia Domina

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

Page 21: Tesis Dw Cecilia Domina

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

Page 22: Tesis Dw Cecilia Domina

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

Page 23: Tesis Dw Cecilia Domina

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

Page 24: Tesis Dw Cecilia Domina

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

Page 25: Tesis Dw Cecilia Domina

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

Page 26: Tesis Dw Cecilia Domina

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

Page 27: Tesis Dw Cecilia Domina

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

Page 28: Tesis Dw Cecilia Domina

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

Page 29: Tesis Dw Cecilia Domina

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

Page 30: Tesis Dw Cecilia Domina

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

Page 31: Tesis Dw Cecilia Domina

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

Page 32: Tesis Dw Cecilia Domina

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

Page 33: Tesis Dw Cecilia Domina

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

Page 34: Tesis Dw Cecilia Domina

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

Page 35: Tesis Dw Cecilia Domina

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

Page 36: Tesis Dw Cecilia Domina

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

Page 37: Tesis Dw Cecilia Domina

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

Page 38: Tesis Dw Cecilia Domina

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

Page 39: Tesis Dw Cecilia Domina

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

Page 40: Tesis Dw Cecilia Domina

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

Page 41: Tesis Dw Cecilia Domina

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

Page 42: Tesis Dw Cecilia Domina

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

Page 43: Tesis Dw Cecilia Domina

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

Page 44: Tesis Dw Cecilia Domina

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

Page 45: Tesis Dw Cecilia Domina

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

Page 46: Tesis Dw Cecilia Domina

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

Page 47: Tesis Dw Cecilia Domina

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

Page 48: Tesis Dw Cecilia Domina

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

Page 49: Tesis Dw Cecilia Domina

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

Page 50: Tesis Dw Cecilia Domina

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

Page 51: Tesis Dw Cecilia Domina

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

Page 52: Tesis Dw Cecilia Domina

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

Page 53: Tesis Dw Cecilia Domina

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

Page 54: Tesis Dw Cecilia Domina

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

Page 55: Tesis Dw Cecilia Domina

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

Page 56: Tesis Dw Cecilia Domina

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

Page 57: Tesis Dw Cecilia Domina

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

Page 58: Tesis Dw Cecilia Domina

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

Page 59: Tesis Dw Cecilia Domina

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

Page 60: Tesis Dw Cecilia Domina

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

Page 61: Tesis Dw Cecilia Domina

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

Page 62: Tesis Dw Cecilia Domina

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

Page 63: Tesis Dw Cecilia Domina

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

Page 64: Tesis Dw Cecilia Domina

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

Page 65: Tesis Dw Cecilia Domina

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

Page 66: Tesis Dw Cecilia Domina

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

Page 67: Tesis Dw Cecilia Domina

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

Page 68: Tesis Dw Cecilia Domina

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

Page 69: Tesis Dw Cecilia Domina

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

Page 70: Tesis Dw Cecilia Domina

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

Page 71: Tesis Dw Cecilia Domina

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

Page 72: Tesis Dw Cecilia Domina

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

Page 73: Tesis Dw Cecilia Domina

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

Page 74: Tesis Dw Cecilia Domina

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

Page 75: Tesis Dw Cecilia Domina

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

Page 76: Tesis Dw Cecilia Domina

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

Page 77: Tesis Dw Cecilia Domina

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

Page 78: Tesis Dw Cecilia Domina

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

Page 79: Tesis Dw Cecilia Domina

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

Page 80: Tesis Dw Cecilia Domina

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í

Page 81: Tesis Dw Cecilia Domina

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

Page 82: Tesis Dw Cecilia Domina

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

Page 83: Tesis Dw Cecilia Domina

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

Page 84: Tesis Dw Cecilia Domina

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

Page 85: Tesis Dw Cecilia Domina

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

Page 86: Tesis Dw Cecilia Domina

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

Page 87: Tesis Dw Cecilia Domina

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

Page 88: Tesis Dw Cecilia Domina

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

Page 89: Tesis Dw Cecilia Domina

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

Page 90: Tesis Dw Cecilia Domina

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

Page 91: Tesis Dw Cecilia Domina

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

Page 92: Tesis Dw Cecilia Domina

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

Page 93: Tesis Dw Cecilia Domina

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

Page 94: Tesis Dw Cecilia Domina

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

Page 95: Tesis Dw Cecilia Domina

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

Page 96: Tesis Dw Cecilia Domina

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

Page 97: Tesis Dw Cecilia Domina

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

Page 98: Tesis Dw Cecilia Domina

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

Page 99: Tesis Dw Cecilia Domina

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

Page 100: Tesis Dw Cecilia Domina

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

Page 101: Tesis Dw Cecilia Domina

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

Page 102: Tesis Dw Cecilia Domina

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

Page 103: Tesis Dw Cecilia Domina

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

Page 104: Tesis Dw Cecilia Domina

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

Page 105: Tesis Dw Cecilia Domina

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

Page 106: Tesis Dw Cecilia Domina

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

Page 107: Tesis Dw Cecilia Domina

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

Page 108: Tesis Dw Cecilia Domina

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

Page 109: Tesis Dw Cecilia Domina

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

Page 110: Tesis Dw Cecilia Domina

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

Page 111: Tesis Dw Cecilia Domina

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

Page 112: Tesis Dw Cecilia Domina

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

Page 113: Tesis Dw Cecilia Domina

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

Page 114: Tesis Dw Cecilia Domina

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

Page 115: Tesis Dw Cecilia Domina

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

Page 116: Tesis Dw Cecilia Domina

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

Page 117: Tesis Dw Cecilia Domina

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

Page 118: Tesis Dw Cecilia Domina

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

Page 119: Tesis Dw Cecilia Domina

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

Page 120: Tesis Dw Cecilia Domina

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

Page 121: Tesis Dw Cecilia Domina

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

Page 122: Tesis Dw Cecilia Domina

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

Page 123: Tesis Dw Cecilia Domina

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

Page 124: Tesis Dw Cecilia Domina

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

Page 125: Tesis Dw Cecilia Domina

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

Page 126: Tesis Dw Cecilia Domina

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

Page 127: Tesis Dw Cecilia Domina

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

Page 128: Tesis Dw Cecilia Domina

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

Page 129: Tesis Dw Cecilia Domina

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

Page 130: Tesis Dw Cecilia Domina

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

Page 131: Tesis Dw Cecilia Domina

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

Page 132: Tesis Dw Cecilia Domina

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

Page 133: Tesis Dw Cecilia Domina

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

Page 134: Tesis Dw Cecilia Domina

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

Page 135: Tesis Dw Cecilia Domina

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

Page 136: Tesis Dw Cecilia Domina

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

Page 137: Tesis Dw Cecilia Domina

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

Page 138: Tesis Dw Cecilia Domina

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

Page 139: Tesis Dw Cecilia Domina

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

Page 140: Tesis Dw Cecilia Domina

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