Data Warehousing Relevamiento y Aplicacion de Tecnicas de Modelado Dimensional

Universidad Nacional del Sur
Departamento de Ciencias e Ingeniera

de la Computacin
Tesis de Licenciatura en Ciencias de la Computacin
Data Warehousing.
Relevamiento y aplicacin de
tcnicas de modelado dimensional
Alumna: Mara Cecilia Dmina
Directoras: Mg. Elsa Estvez
y Lic. Mercedes Vitturini
Baha Blanca
Diciembre 2008
Resumen
Este trabajo ha sido desarrollado por la alumna Mara Cecilia Dmina bajo la direccin de
la Mg. Elsa Estvez y la Lic. Mercedes Vitturini. Se presenta como tesis de la carrera de grado
Licenciatura en Ciencias de la Computacin de la Universidad Nacional del Sur.
En este proyecto se estudia la utilizacin de herramientas de Data Warehousing para el
anlisis de datos. Se destaca la importancia de la aplicacin de estas tecnologas para el
conocimiento de la informacin de cualquier institucin y la toma de decisiones basada en datos
ciertos y concretos. La tesis se organiza en dos secciones. En la primera parte, se presentan y
ejemplifican los principales conceptos tericos desarrollados en esta rea de las ciencias de la
computacin y se presentan las principales tcnicas de diseo de Data Warehouses actuales.
En la segunda seccin se desarrolla un ejemplo de aplicacin de los conceptos y tcnicas
estudiadas enfocados hacia una propuesta de anlisis de desgranamiento de alumnos
universitarios. El diseo apunta a la identificacin de perfiles y patrones de los alumnos
universitarios que abandonan la actividad acadmica. Para el caso de estudio se utiliza como
modelo organizacional de partida al modelo de datos usado por el Sistema de Gestin de
Acadmica de Alumnos SIU-Guaran. El sistema SIU-Guaran actualmente se utiliza como sistema
de gestin acadmica en la mayora de las universidades nacionales argentinas y particularmente
en la Universidad Nacional del Sur.
El presente trabajo se realiz con la colaboracin del SIU1, que facilita el uso de la
herramienta O3 de la empresa IdeaSoft para la implementacin del caso prctico y los desarrollos
y documentacin que poseen sobre el tema de estudio y lo referente al SIU-Guaran. Todo lo
desarrollado como parte de esta tesis queda a disposicin del SIU para su publicacin y futura
aplicacin.
El SIU es un rea del Ministerio de Educacin que desarrolla sistemas informticos para las Universidades Nacionales.
Agradecimientos
Quiero darles las gracias a todas las personitas que de alguna manera colaboraron
conmigo para que este trabajo est hoy realizado. A Mercedes por la buena predisposicin de
siempre y su paciencia. A Daro por su enorme colaboracin. Al SIU en general por brindar las
herramientas, el material, y el conocimiento para la construccin del caso prctico. Y a mi familia,
amigos, compaeros y todo el equipo del SIU por su apoyo y empuje, por estar. Gracias!, sin
ustedes todo hubiese sido ms difcil.
ndice
Resumen.................................................................................................................2
Agradecimientos....................................................................................................3
ndice.......................................................................................................................4
1 Introduccin.........................................................................................................7
2 Sistemas para Anlisis de Informacin...........................................................10
2.1 Evolucin de los Sistemas de Soporte de Decisiones............................................10
2.2 Qu es un Data Warehouse?...............................................................................14
2.3 Objetivos de un Data Warehouse ..........................................................................15
2.4 Entorno del Data Warehouse..................................................................................17
Fuentes de datos...................................................................................................................18
Limpieza y transformacin de los datos.................................................................................18
Almacenamiento y presentacin de los datos .......................................................................21
Anlisis de informacin..........................................................................................................22
2.5 Aplicaciones tradicionales versus aplicaciones para anlisis de informacin.........23

Caracterizacin de las diferencias ........................................................................................24
Nivel de datos fsico para anlisis de informacin.................................................................27
2.6 Tendencias en sistemas para anlisis de informacin............................................29

2.7 El mercado de Data Warehousing y Business Intelligence.....................................32
3 El proceso de creacin de modelos analticos .............................................34

3.1 Introduccin al modelado multidimensional............................................................34
Dimensiones, hechos y medidas...........................................................................................37
Navegacin del modelo multidimensional..............................................................................38
Tabla de hechos....................................................................................................................38
Tablas de dimensin..............................................................................................................39
Esquema estrella...................................................................................................................39
3.2 Ciclo de vida de un proyecto de Data Warehousing...............................................40

Hitos del mapa de ruta del BDL.............................................................................................40
Planificacin del proyecto......................................................................................................41
Definicin de requerimientos.................................................................................................42
Diseo de la arquitectura tcnica...........................................................................................42
4
Seleccin de Productos e Instalacin....................................................................................43

Modelado Dimensional lgico................................................................................................43
Diseo Fsico.........................................................................................................................44
Diseo de las Extracciones y Transformaciones de Datos ...................................................44
Especificacin de Aplicaciones para Usuarios Finales..........................................................45
Desarrollo de Aplicaciones para Usuarios Finales.................................................................47
Puesta en produccin............................................................................................................47
Mantenimiento y crecimiento.................................................................................................49
Gerenciamiento del Proyecto.................................................................................................50
3.3 Tcnicas para el modelado dimensional.................................................................50

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

4.1 Qu es el SIU?.....................................................................................................72
4.2 El sistema de software SIU-Guaran.......................................................................73
4.3 Desercin y desgranamiento de alumnos...............................................................75
5 Presentacin de la solucin.............................................................................77
5.1 Requerimientos y especificacin del Data Mart......................................................77
Datos considerados...............................................................................................................77
Datos que quedaron excluidos y motivos .............................................................................78
5.2 Arquitectura del caso prctico.................................................................................79

5.3 Matriz y modelo lgico del Data Mart......................................................................80
5.4 Modelo fsico y consideraciones de diseo.............................................................83
Diseo fsico de las tablas del DW que se usan para el Data Mart.......................................84
Diseo fsico del Data Mart....................................................................................................86
5.5 Personalizacin del proceso ETL...........................................................................92

5.6 Problemas de calidad de datos...............................................................................93
Controles en la definicin del modelo y la generacin del cubo............................................93
Controles en los procesos de extraccin y transformacin de datos.....................................94
Problemas de calidad en el origen del dato...........................................................................94
6 Uso de la herramienta y anlisis de datos......................................................96

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

Acceso al cubo y vista inicial.................................................................................................96
Operaciones bsicas de consulta..........................................................................................97
6.2 Un ejemplo de anlisis sobre evolucin de la matrcula........................................101

Cantidad de alumnos por ao acadmico............................................................................101
Anlisis de ingresantes........................................................................................................103
Seguimiento de una cohorte................................................................................................107
6.3 Ejemplos de anlisis de procedencia....................................................................110

Anlisis a nivel de pas y calidad de datos...........................................................................111
Exploracin de los niveles de la dimensin procedencia.....................................................112
Articulacin de colegios y carreras......................................................................................113
6.4 Un ejemplo de desgranamiento basado en la actividad acadmica y rendimiento

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

7.1 Conclusiones........................................................................................................127
7.2 Trabajo futuro ......................................................................................................128
8 Apndice. Documentacin tcnica del caso de estudio.............................131

8.1 Descripcin tcnica de las variables del cubo.......................................................131
8.2 Consideraciones especiales.................................................................................134
8.3 Estructuras de los archivos de texto.....................................................................135
8.4 Generacin del cubo.............................................................................................137
8.5 Archivos adjuntos.................................................................................................138
Bibliografa.........................................................................................................139
Captulo 1 - Introduccin
Introduccin
Sin lugar a dudas, el Data Warehousing es parte integral de lo que algunos autores
definen como la era de la informacin ya que posibilita la construccin y mantenimiento de

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

entendibles. Se busca visualizar el contenido de la base de datos como un cubo de tres, cuatro,
cinco o ms dimensiones. Bajo este paradigma, los usuarios se pueden imaginar navegando la
informacin y realizando cortes a ese cubo a travs de cada una de sus dimensiones. Se entiende
por navegacin o drilling de los datos, a la capacidad de ver informacin correspondiente a
diferentes contextos o entornos. Por ejemplo, analizar los egresados de un determinado ao y
poder detallarlos por carrera. Luego analizar ms profundamente una carrera para ver cmo se
discriminan los egresados por cada cohorte2, etc.
El modelo dimensional organiza y presenta los datos definiendo dimensiones. Se define
como dimensiones a las lneas o reas temticas del negocio, como por ejemplo producto,
sucursal, tiempo. Son entidades independientes que sirven como punto de entrada para el anlisis
de la informacin contenida en el modelo multidimensional. Llevado al mbito universitario y para
el anlisis informacin acadmica de alumnos se podran considerar a las dimensiones: carreras,
lugar de procedencia, ao de ingreso, entre otras. Dentro de las dimensiones pueden existir
diferentes niveles de anlisis o jerarquas. Para el caso de procedencia se podran considerar los
niveles pas, provincia, localidad y colegio, por ejemplo. Las dimensiones se relacionan a travs de
hechos. Se consideran hechos a sucesos o eventos que ocurren, como por ejemplo alumnos que
cursan carreras, o que rinden exmenes. Este ltimo ejemplo estara relacionando a las
dimensiones: materia, alumno, y fecha, entre otras. Los hechos o eventos generalmente se
asocian con una o ms medidas (el resultado o nota, en este caso). Las medidas, mtricas o
indicadores, son variables numricas que ayudan a medir el rendimiento de un negocio o proceso.
En esta tesis se presentan los principales conceptos y tcnicas de diseo y se resaltan la
importancia y potencial de estas tecnologas para la toma de decisiones y el mejoramiento de los
sistemas de gestin y la calidad de datos. La tesis se completa con un ejemplo prctico que
muestra la aplicacin de los conceptos tericos. Dado que el desarrollo est basado en el modelo
de datos de un sistema gestin transaccional de uso real, los resultados obtenidos podrn
utilizarse para colaborar en el anlisis de la problemtica de desercin universitaria.
El desarrollo de la tesis se organiz de la siguiente manera: en el captulo 2 se describe la
evolucin de los DSS que dio origen al DW; se define y conceptualiza el rea de DW y sus
objetivos y se lo ubica dentro de la arquitectura de un DSS. Luego se detallan los principales
componentes del entorno, destacando las diferencias de este ambiente (OLAP) respecto al de los
sistemas operacionales o de gestin (OLTP). Finalmente se presentan las principales
herramientas del mercado.
En el captulo 3 se especifican las caractersticas de los modelos dimensionales y las
principales tcnicas para disearlos. Tambin se presenta una metodologa de produccin de DW
o ciclo de vida de DW.
Entindase por cohorte al ao acadmico en que el alumno ingresa a la carrera.
La segunda parte de esta tesis consta de tres captulos destinados al caso de aplicacin.
Se presenta la temtica a abordar, se desarrolla la solucin explicando las decisiones de diseo
adoptadas y luego se muestra el uso a travs de ejemplos concretos. En este caso la temtica
elegida es el desgranamiento de alumnos universitarios. La desercin universitaria es un tema que
ha despertado mucho inters en el ltimo tiempo. El costo econmico para el estado nacional de
un alumno en la universidad, la creciente necesidad de profesionales en algunas reas y otras
causas sociales son algunos de los motivos que conducen a la pregunta de por qu una persona
comienza sus estudios universitarios y luego los abandona.
El caso prctico de esta tesis, adems de mostrar un ejemplo de aplicacin de los
conceptos desarrollados busca transmitir la experiencia adquirida mediante el anlisis de distintas
alternativas para implementar y usar la solucin. Los ejemplos de anlisis de datos intentan
mostrar como sera posible encontrar dentro de una institucin dnde se concentran los mayores
problemas, e identificar las posibles causas.
Como OLTP fuente de datos se usa el sistema SIU-Guaran. El SIU-Guaran es un
sistema de gestin de alumnos universitarios que administra informacin de gestin acadmica:
carreras, planes de estudio, ttulos, materias, egresados, inscripciones y resultados de exmenes,
profesores asociados a las ctedras, asignacin de aulas, asistencias, cursos de ingreso,
actividades extracurriculares, equivalencias, certificados, encuestas, etc. Este sistema est
desarrollado por el SIU y actualmente est implementado en la Universidad Nacional del Sur
desde agosto del 2004 y tambin en varias universidades nacionales argentinas3.
A mayo del 2008 se totalizan ms de 200 instalaciones
Captulo 2 - Sistemas para Anlisis de Informacin
Sistemas para Anlisis de Informacin

El trmino de Data Warehouse (DW) surge en los aos 90 con la necesidad y oportunidad
de obtener informacin a partir de los datos que haban sido recolectados durante los aos
anteriores por los sistemas de gestin.
En las ltimas dcadas el objetivo de los sistemas de informacin no es simplemente
servir a las necesidades operacionales sino tambin cubrir necesidades analticas de la
informacin. En principio se utilizaron los mismos repositorios de datos para los diferentes
propsitos referentes al procesamiento de informacin: de transacciones, batch y analtico. Con el
transcurso del tiempo surgieron problemas que dejaron en evidencia que no es apropiado utilizar
el entorno donde se opera con los datos para analizar informacin. Las principales razones para
separar el entorno operacional del analtico radican en los datos que se utilizan, las tecnologas
que los soportan y la comunidad usuaria, entre otras. Este trabajo presenta el entorno analtico o
sistema para soporte de decisiones (DSS). En l, el DW cumple el rol de ser la nica fuente de
datos consultable.
2.1
Evolucin de los Sistemas de Soporte de Decisiones

La evolucin de los DSS esta bien detallada en [Inm2002]. El autor plantea cmo fue la
evolucin natural de los sistemas y los problemas que originaron el diseo de un ambiente
especfico con una arquitectura estructurada en diferentes niveles de informacin, centrada en un
DW. A continuacin se resumen los hechos ms importantes que dieron origen a esta evolucin.
Una vez que los sistemas de gestin haban sido implementados y funcionaban
correctamente surgi la necesidad de obtener informacin a partir de los datos recolectados.
Naturalmente en las organizaciones estas necesidades comenzaron a resolverse realizando
consultas a sus bases de datos operacionales, dentro de lo que se conoce como ambiente OLTP.
Cada sector requera diferentes extracciones de acuerdo a la informacin buscada. Tambin
utilizaba y reutilizaba estos datos para producir informacin, basndose en sus propias reglas y
definiciones.
As, el procesamiento de extracciones de datos comenz a formar una red de informacin
que se asemeja a la estructura de una tela araa como se ilustra en la figura 1. Primero hubo
extracciones, luego extracciones de extracciones, y luego extracciones de extracciones de
extracciones, y as sucesivamente. Este comportamiento fuera de control en el proceso de
extraccin a travs de la organizacin es tan comn que se le ha dado un nombre propio:
arquitectura naturalmente evolutiva o arquitectura de evolucin natural.
10
IndicadorA=x
IndicadorA=y
Figura 1. Arquitectura naturalmente evolutiva y problema de credibilidad de la informacin.
Esta arquitectura presenta algunos problemas importantes, entre los cuales se pueden
destacar la falta de credibilidad de los datos, la baja productividad, y la inhabilidad para
transformar datos en informacin. Estos problemas se hacen ms notorios con el crecimiento de la
organizacin.
La carencia de credibilidad de datos se puede ejemplificar en que un mismo indicador o
reporte tiene resultados diferentes en puntos distantes de la organizacin (figura 1). Entonces
pueden obtenerse reportes en conflicto y la informacin pierde credibilidad. La causa de estas
inconsistencias es no tener a la informacin sincronizada. Las diferencias ms importantes en la
forma de obtener la informacin final en general se deben a:
-
La referencia temporal de los datos. Los perodos considerados difieren y/o la informacin
no est actualizada a la misma fecha.
Los algoritmos de clculo. Algunos criterios considerados de formas diferentes en la

definicin de datos.
El nivel de extraccin. Cada nivel de extraccin exagera los otros problemas que ocurren
en los niveles anteriores.
Datos externos considerados. Pueden ser de diferentes fuentes y por lo tanto contener
informacin diferente.
Mltiples fuentes. No contar con una fuente de datos en comn desde el comienzo.
La productividad de este esquema es tambin un gran problema, especialmente cuando
hay necesidad de analizar datos a travs de diferentes reas para obtener reportes corporativos.
Generalmente esto requiere localizar y analizar los datos para el reporte, compilarlos, y asignar
recursos al programador o analista para acompaar estas tareas. Localizar los datos requiere
entre otras cosas: revisar muchos archivos, acceder a datos de lugares diferentes, para los cuales
tal vez se requiera diferentes perfiles de acceso y permisos; definir qu datos tomar cuando un
dato o indicador se repite y no es exactamente igual. Para compilar los datos es necesario escribir
muchos programas de extraccin de datos, cada uno de ellos debe ser personalizado y tiene que
11
cruzar la barrera tecnolgica que use la compaa. A estos dos inconvenientes de tener que
localizar los datos y compilarlos hay que agregar que en general cuando el primer reporte se
obtiene no se conocen los requerimientos para reportes futuros y a no ser en circunstancias muy
inusuales el trabajo realizado para el primer reporte no allana el camino para los reportes
siguientes, por lo que resultan costosos todos los informes.
Adems de los problemas de productividad y credibilidad, hay una carencia mayor de la
arquitectura evolutiva naturalmente y es la inhabilidad de ir desde los datos a la informacin. En la
mayora de los casos para obtener determinada informacin hay que consultar datos que se
encuentran en aplicaciones heredadas y que no estn integradas. En las aplicaciones a veces se
encuentran datos que slo existen en un lugar y no pueden relacionarse con otras aplicaciones,
datos distintos con igual nombre y datos iguales nombrados de diferentes formas. La integracin
de datos es un tema muy importante a la hora de querer obtener informacin.
Otro obstculo para realizar esta tarea es la falta de datos histricos en las aplicaciones.
Es frecuente que en las bases de datos transaccionales slo se guarden los datos para cumplir las
necesidades operacionales, que suelen no ser suficientes para satisfacer las necesidades
analticas4.
Los requerimientos de evolucin propios de los sistemas de gestin los hacen
inadecuados para soportar las necesidades de los DSS. Carecen de integracin y existe una
discrepancia entre el horizonte de tiempo necesario para el procesamiento analtico y el existente
en las aplicaciones. Adems esta arquitectura no es suficientemente robusta para alcanzar las
necesidades futuras. Entonces se necesita un cambio estructural importante.
Nivel Operacional
Informacin:
Detallada
Da a da
Valores
corrientes/actuales
Alta probabilidad de
acceso
Orientado a aplicaciones
Nivel del Data Warehouse

(datos atmicos)
Informacin:
Mayormente detallada
(most granular)
Asociada a perodo de
tiempo (time variant)
Integrada
Orientada a una o ms
temticas (subject
oriented)
Algo agregada o
resumida (some
summary).
Nivel Departamental
(Data Marts)
Informacin:
Parcializada,
correspondiente al rea
en cuestin (parochial)
Contiene algunos datos
derivados y otros
primitivos.
Nivel Individual
Informacin:
Temporaria
Ad hoc
Heurstica
No repetitiva
Basada en pc o
estaciones de trabajo.
Figura 2. Arquitectura de los sistemas para la toma de decisiones diseada en funcin de los niveles de informacin.
El SIU-Guaran s mantiene la informacin histrica. Este sistema no tiene las caractersticas de un sistema transaccional
tpico donde se cargan continuamente operaciones y se maneja un gran volumen de informacin diaria, como podra ser un
sistema de ventas por menor o un sistema de registro de transacciones bancarias, o de reservas de vuelos.
5
Entindase ad hoc como un anlisis particular con un fin especfico.
12
Todo ello plantea la necesidad de una nueva arquitectura [Inm2002], basada

principalmente en los tipos de datos que se utilizan, si se trata de datos primitivos y datos
derivados. Esta arquitectura consta de cuatro niveles, y se muestra en la figura 2
Las principales diferencias entre los datos primitivos u operacionales y los datos derivados
o datos DDS son:
-
Los datos primitivos son datos a nivel de detalle y son usados para realizar las
operaciones diarias de una compaa. Los derivados son datos sumarizados o de algn
modo calculados para cumplir con las necesidades de la gestin de la compaa.
Los datos primitivos se actualizan mientras que los datos derivados se recalculan, pero no
se pueden actualizar.
Los datos primitivos son principalmente valores actuales. Los derivados frecuentemente
se corresponden con datos histricos.
Los datos primitivos son operados sobre procedimientos repetitivos mientras que los
derivados son operados heursticamente, por programas y procedimientos analticos.
Los datos operacionales, que soportan las funciones del trabajo diario de oficina, son
primitivos. Los datos DDS, para toma de decisiones, que soportan las funciones
gerenciales, son derivados.
Ejemplo:
En un sistema de gestin acadmica, un dato primitivo sera: el alumno Juan Prez
matrcula 6767 rindi la materia Anlisis matemtico I, cuyo cdigo es 7865, el da 20/10/2005;
aprob con calificacin 8, y fue registrado en el acta X, folio Z. En contrapartida, el dato derivado
sera: Juan Prez rindi 5 materias durante el 2005, aprob el 80% de los exmenes rendidos
durante ese ao y promedia 7,25 en la carrera.
En la figura 2 se observa que el nivel operacional de datos mantiene aplicaciones
orientadas a datos primitivos solamente y se basa en el procesamiento de transacciones. El nivel
de DW mantiene datos integrados, datos primitivos histricos que no pueden ser actualizados y
datos derivados. El nivel de Data Marts contiene casi exclusivamente datos derivados, aunque el
nivel de datos depende de los requerimientos de los usuarios finales y las necesidades de cada
departamento. Y el nivel individual de datos es donde se hace mucho anlisis heurstico. A este
nivel, de anlisis gerencial, se utiliza informacin agregada.
Como se puede observar en la figura el DW se constituye como el repositorio central y
nica fuente de datos consolidados para anlisis de informacin. Cumple un rol fundamental y
debe tener determinadas caractersticas para asegurar el correcto funcionamiento de esta
arquitectura.
13
Captulo 2 -
2.2
Qu es un Data Warehouse?
En forma sencilla se puede decir que un DW es una coleccin de datos, obtenidos a partir
de los datos transaccionales y especficamente estructurados para realizar consultas y analizar la

informacin [Kim1992]. Comnmente se dice que los DW son fuentes secundarias de informacin
pues no generan datos por s mismos, sino que son alimentados desde sistemas existentes
internamente en la organizacin o desde datos externos. Tpicamente los usuarios del DW tienen
slo permisos de lectura sobre este repositorio de datos. Los DW o bases de datos para
procesamiento analtico (OLAP) estn especficamente estructurados o diseados para cumplir
con un conjunto de metas bien diferentes a los objetivos de un sistema operacional OLTP. Por
ejemplo, una meta de los OLTP es maximizar la concurrencia de actualizaciones; dicho objetivo no
es pertinente en el diseo de DW donde las consultas son slo de lectura [Mst2005]. En
contrapartida, las metas de un diseador de DW deben focalizarse en entregar un anlisis
multidimensional y capacidades de reportes ad hoc6 [Mst2005] y brindarlos de manera eficiente.
Estos requerimientos necesitan un diseo especfico de la base de datos, que se presenta en el
captulo siguiente como diseo o modelo multidimensional.
La definicin ms tradicional del trmino DW fue especificada por Bill Inmon a principios
de la dcada de los 90, quin lo defini como una coleccin de datos orientados al sujeto,
integrados, variables en el tiempo y no voltiles para ayudar al proceso de toma de decisiones
gerenciales [Inm2002] [Mst2005], donde:
-
Orientados al Sujeto: datos que brindan informacin sobre un sujeto o asunto del
negocio en particular, en lugar de concentrarse en la dinmica de las transacciones de la
organizacin. Se dice que un DW est orientado a los sujetos de una organizacin y no a
sus operaciones o procesos. En el ambiente universitario se puede pensar en alumnos,
carreras, egresados, en lugar de inscripciones, registro de actas de exmenes, gestin de
ttulos, etc.
Integrados: los datos con los que se nutre el DW provienen de diferentes fuentes y son
integrados para dar una visin global coherente. Cuando se integran datos de diferentes
fuentes hay que contemplar cuestiones como la estandarizacin de codificaciones
(ejemplo: sexo como F y M, o 1 y 2, o V y M), formatos de campos (por ejemplo de
fechas), nomenclaturas (datos que significan lo mismo con nombres distintos, y datos
diferentes con el mismo nombre) y diferentes formas de medir algunos atributos.
Variables en el Tiempo: todos los datos en el DW estn asociados con un perodo de

tiempo especfico. En los sistemas operacionales se lleva tanto informacin asociada a
algn perodo de tiempo, por ejemplo el ao acadmico en que el alumno ingresa a la
carrera, o fecha en que rinde un examen; as como tambin se lleva informacin corriente,
ligada al momento actual, por ejemplo condicin de regularidad de los alumnos. Cuando
Reportes ad hoc refiere a la generacin de reportes personalizados por parte de usuarios expertos basados en el
conocimiento del negocio. Ms adelante en este trabajo se explica en detalle las caractersticas de anlisis
multidimensional y ad hoc.
14
Captulo 2 -
se extraen datos de los sistemas fuentes para pasar al DW estos quedan asociados
siempre a un perodo de tiempo en el que esa informacin es vlida. Se puede decir que
es el tiempo que corresponde al momento en que se toma la foto del sistema.
El DW puede concebirse entonces como una serie de fotos tomadas en algn momento de
tiempo. El elemento de tiempo puede tomar diferentes formas, desde una estampilla de
tiempo en cada registro del DW hasta una estampilla de tiempo de la base de datos
completa. Este ltimo es el caso del trabajo prctico.
-
No voltiles: los datos son estables en el DW. Se pueden agregar ms datos, pero los
datos existentes no son removidos. Cuando un dato ingresa al DW se carga como una
foto, esttica. Si ocurren cambios se cargan fotos nuevas y se mantiene la historia.
Obviamente que esta definicin, ya clsica, se debe tomar como la definicin pura sobre
DW. Sin embargo, con los aos, algunos trminos han sido modificados segn las necesidades y
capacidades del mercado, dando origen a otros conceptos como el de Data Marts (para referirse a
DW sobre reas especficas en lugar del warehouse corporativo) y otras variantes de DW donde
por ejemplo es vlido actualizar datos ya existentes.
2.3
Objetivos de un Data Warehouse

Una de la las cosas ms valiosas de una organizacin es su informacin. Esta es
generalmente mantenida en dos formas: el sistema operacional de registros y el DW. En forma

simplificada, el sistema operacional es donde los datos ingresan y el DW es donde se realiza
anlisis y se extrae informacin.
El DW vendra a cumplir el rol de ser la fuente donde los usuarios pueden acceder a sus
datos. Los objetivos fundamentales de un DW particular se van a desprender de las inquietudes
que tengan los directivos de una organizacin. En [Kim1998] se establecen como requerimientos
las siguientes consideraciones de calidad:
-
El DW debe proveer acceso fcil a la informacin de una organizacin.

Informacin accesible significa que administradores y analistas de una organizacin deben
poder conectarse al DW desde sus computadoras personales. La conexin debe ser
inmediata, a demanda y de alta velocidad. No es aceptable que el acceso sea a travs de
otra persona, sea inseguro o lento.
El DW no es slo los datos, sino tambin un conjunto de herramientas para consultar,
analizar y presentar la informacin. Las herramientas de acceso deben ser simples y
fciles de usar.
Los contenidos del DW deben ser entendibles y navegables. Esto quiere decir que deben
estar correctamente etiquetados y que los datos pueden ser separados y combinados por
el significado de toda posible medida del negocio.
15
Captulo 2 -
Los datos del DW deben ser consistentes y de buena calidad.

La
informacin
del
DW
debe
ser
creble.
Consistencia
implica
resolver
las
correspondencias entre la informacin de diferentes partes de la organizacin. Si dos

medidas de una organizacin tienen el mismo nombre deben tener el mismo significado.
Inversamente si dos medidas difieren en significado deben etiquetarse de manera distinta.
Informacin consistente y de alta calidad significa que toda la informacin debiera ser
tenida en cuenta y que es completa. Tambin implica que deben estar disponibles para los
usuarios las definiciones comunes (diccionario de datos) de los contenidos del DW.
Los datos que se publican en el DW deben ser tiles. Como los datos provienen de
diferentes fuentes de informacin, deben ser combinados cuidadosamente, atravesar una
etapa de limpieza que debe asegurar la calidad antes de pasar a ser parte del DW.
La calidad de los datos del DW debe ser una conductora para la reingeniera del negocio.
El DW no puede arreglar la pobre calidad de los datos. Si los datos son opcionales y no
estn completos no hay nada que el DW pueda hacer. La nica forma de mejorar la
calidad afecta a las personas que ingresan datos al sistema y a los administradores y
consiste en volver al origen del dato con mejores sistemas, mejores administraciones y
mejor visibilidad del valor de buen dato.
Muchas veces al publicar los datos incompletos la gente ve lo valioso que sera contar con
datos de mejor calidad. De esta forma el DW puede jugar un rol clave en los esfuerzos de
reingeniera del negocio de una organizacin.
-
Debe ser una fuente de informacin adaptable y flexible a los cambios.

El DW debe estar diseado para manejar los cambios continuos de las necesidades de los
usuarios, las condiciones del negocio, los datos y las tecnologas. Los datos y aplicaciones
existentes en el DW no deben sufrir modificaciones cuando se agregan nuevos datos y/o
nuevas preguntas a realizar.
El DW debe ser un lugar seguro donde la informacin se encuentre protegida.

El DW contiene informacin muy valiosa para la organizacin. Es necesario que existan
controles de acceso efectivo a los datos. Tambin se debe permitir a sus dueos visualizar
los usos y abusos de los datos, incluso luego de haber abandonado el DW.
Debe ser la base para la toma de decisiones.

El DW debe contener los datos correctos para soportar la toma de decisiones. Hay slo
una verdadera salida del DW: las decisiones que son tomadas a partir de l. El DW tendr
ms valor cuanto ms impacte en las decisiones del negocio. Recordar que el DW surge
para constituirse como la parte central de un sistema para la toma de decisiones que es lo
que finalmente se est tratando de construir.
Debe ser aceptado por la comunidad usuaria para considerarse exitoso.

No importa si la solucin construida es elegante y usa los mejores productos y plataformas
si el DW no se utiliza para el propsito que fue concebido. Su uso muchas veces es
opcional, a diferencia de los sistemas operacionales donde los usuarios estn obligados a
16
Captulo 2 -
utilizarlos. La aceptacin de los usuarios de estas herramientas pasa por la simplicidad

sobre todas las cosas.
Si la comunidad del negocio no adopta al DW y continua usndolo activamente seis meses
despus del entrenamiento, entonces habr fallado el test de aceptacin.
De esta lista es fcil ver que para poder implementar exitosamente un DW se requiere
mucho ms que un buen equipo tcnico. Es necesario conocer las reglas del negocio, involucrar a
los usuarios y contar con datos de buena calidad. Se requiere conformar un equipo de trabajo con
diferentes perfiles para lograr xito en el proyecto.
2.4
Entorno del Data Warehouse.

La figura 3 presenta un esquema con los principales componentes que definen el marco
para un DW . Como se mencion anteriormente el DW es el ncleo de toda la arquitectura de un

DSS.
rea de limpieza y
transformacin de
datos (Data
Staging Area)
Servicios:
limpieza,
combinacin y
estandarizacin.
Ajustar
dimensiones
comunes.
No hay servicios
de consultas de
usuarios.
Almacenamiento
de datos:
archivos planos y
tablas
relacionales.
Procesamiento:
ordenamiento y
procesamiento
secuencial
rea de almacenamiento y
presentacin de datos
(DW y Data Marts)
rea de anlisis de informacin

(Herramientas de acceso a los
datos, aplicaciones de usuario
final)
Reportes
C
A
R
G
A
DW
A
C
C
E
S
O
Fuentes de datos
(Sistemas
operacionales y
datos externos)
Alertas
OLAP
(interfaces)
Scorecards &
Dashboards
E
Data Mining
Proceso ETL
DATOS
INFORMACIN
CONOCIMIENTO
Figura 3. Arquitectura tcnica de un sistema para la toma de decisiones basado en un DW.
A continuacin se dan las definiciones para cada componente del entorno, tomando como
base bibliogrfica [Kim1998], [Kim2002], [Inm2002], [10], [11], [12] y [13]. Los elementos se
presentan en el orden en que se desarrolla esta cadena que conduce al conocimiento, que
comienza con los productores de datos y finaliza en los consumidores de informacin.
Antes de describir a cada elemento se aclara que el grfico de la figura 3 es una
adaptacin propia de los vistos en la bibliografa y dems referencias consultadas y est basado
principalmente en la propuesta de [Kim2002] [Kim1998]. Se puede observar la correspondencia
con los niveles de informacin planteados en la figura 1. Esta arquitectura tambin concuerda la
arquitectura La Fbrica de Informacin Corporativa (CIF)7. La propuesta de Kimball no coincide
7
Ver grficos en referencias [10] y [11] de la seccin de bibliografa.
17
Captulo 2 -
en la forma de plantear la existencia fsica del DW y los Data Marts como subconjuntos de este,
sino que inversamente plantea la existencia de Data Marts y el concepto de DW como unin de
estos, que deben basarse en hechos (facts) y dimensiones acordadas.
La visin de Inmon es ms integradora, considera al DW como la fuente central de
informacin y a partir de donde se construyen los Data Marts para los sectores. Por su parte
Kimball plantea que en principio el desarrollo de un DW puede tornarse una tarea de dimensiones
infinitas, y sugiere comenzar con el desarrollo de Data Marts teniendo en mente la construccin de
un DW como unin de estos (desarrollo bottom-up). Ambas propuestas son vlidas y depender
del problema particular cul puede resultar ms apropiada. Si el diseo de los Data Marts est
bien pensado puede construirse un DW a partir del trabajo realizado, y se van obteniendo
resultados a corto plazo. La definicin de dimensiones y hechos conformados es esencial para el
xito a largo plazo de esta metodologa de trabajo.
Se observa que el grfico de la figura 3 no considera un aspecto importante como es la
retroalimentacin en lo que respecta a la calidad de datos. El anlisis de determinada informacin
generalmente genera nuevas necesidades. Cuando se profundiza en la informacin que se quiere
obtener se detectan gran parte de los problemas de calidad existentes, especialmente en los
datos. Esto debe trasladarse a los sistemas fuentes y realizar las correcciones necesarias para la
evolucin del sistema. Esta retroalimentacin y evolucin es un proceso cclico.
Fuentes de datos
Los sistemas operacionales son las fuentes de datos principales donde se registra toda la
gestin de la organizacin. Son los sistemas centrales que soportan las operaciones diarias del
negocio. Se acceden a travs de las interfaces de las aplicaciones (APIs). Los datos que recopilan
estos sistemas son la principal fuente de informacin del DW. Tambin se los conoce como
sistemas transaccionales o sistemas heredados.
El xito o fracaso de toda la solucin de DW depende fuertemente de que los sistemas
operacionales provean los datos necesarios para entender el negocio y la historia necesaria para
evaluar su evolucin. La calidad de los datos de estos sistemas es fundamental.
Otras fuentes pueden ser datos externos a la organizacin (informacin demogrfica,
crediticia, financiera, etc. por ejemplo la cotizacin de alguna moneda), planillas de clculos, etc.
Limpieza y transformacin de los datos

Se utiliza el trmino data staging area para referirse al rea de almacenamiento y al
conjunto de procesos que limpian, transforman, combinan, estandarizan, archivan y preparan los
datos de origen para ser usados en el DW. Es donde se realiza el proceso de transformacin de
datos. Las tareas principales de esta rea son el ordenamiento y procesamiento secuencial de
datos.
18
Captulo 2 -
Este componente no provee ningn servicio de consulta ni presentacin de informacin,

simplemente porque esta rea no est pensada ni preparada para brindar la seguridad y tiempo de
respuesta propios del rea de almacenamiento o presentacin de datos. La forma de
almacenamiento utilizada es en general la de archivos planos.
Una tarea dentro de esta rea es el aseguramiento de la calidad de los datos. Es para ello
que se testea la consistencia, completitud e idoneidad de los datos a ser publicados a la
comunidad usuaria. La creacin de ndices es otra tarea que tambin puede considerarse parte de
esta etapa de gestin de datos.
El proceso de Extraccin, Transformacin y Carga de datos
El trmino popular ETL corresponde a la sigla en ingls de Extract-Transform-Load y
significa extraer, transformar y cargar. El proceso ETL implica las tareas de capturar, integrar,
transformar, limpiar, reestructurar, validar, filtrar, analizar la calidad y cargar datos en el DW. Este
proceso organiza el flujo de los datos entre los diferentes sistemas operacionales principales de
una organizacin y el rea de almacenamiento y presentacin de datos. Aporta los mtodos y
herramientas necesarias para mover datos desde mltiples fuentes, limpiarlos, reformatearlos y
cargarlos en un DW o Data Mart. En ese momento los datos quedan disponibles para ser
analizados por los usuarios. Otros nombres que recibe este proceso son gestin de los datos,
adquisicin de datos y en ingls data staging o data cleansing.
Cabe destacar que la integracin y transformacin de datos es uno de los procesos ms
importantes de todo el entorno del DW. Tiene la tarea crtica de convertir el caos de datos del
mundo operacional en un mundo ordenado de informacin. Este proceso asimila datos
procedentes de tecnologas heterogneas dentro de un entorno integrado y consistente, apto para
ser consumido por los procesos de soporte de decisiones.
Uno de los mayores desafos se produce cuando los datos recibidos provienen de fuentes
que los han organizado alrededor de claves diferentes. Por ejemplo en el SIU-Guaran una
persona se identifica por el nmero de inscripcin dentro de una unidad acadmica. En el SIUPampa8 la identificacin de la persona se hace por su nmero de legajo. Estas fuentes necesitan
ser integradas para dar una visin nica de persona. Este proceso puede involucrar sofisticadas
reglas de mapeo de elementos, normalizaciones y estandarizacin de nombres, direcciones y
otros datos comunes a las fuentes para determinar cuales son los datos vlidos.
El nivel de esfuerzo necesario para integrar y transformar datos est fundamentalmente
afectado por el nivel de conocimiento que se tenga sobre estos. Cuanto ms familiar resulten los
datos operacionales y los procesos que los producen ms fcil resultarn estas tareas. El proceso
ETL en general tiende a ser subestimado, sin embargo es altamente demandante y puede abarcar
la mayor parte del tiempo de desarrollo de un DW, ocupando hasta el 80% del tiempo en un
proyecto de gran magnitud. A continuacin se detallan las tareas que incluye:
8
El SIU-Pampa es el sistema utilizado en las universidades para la gestin de recursos humanos y la liquidacin de
sueldos.
19
Captulo 2 -
Limpieza de datos. Consiste en la correccin de errores de tipeo, resolucin de dominios

conflictivos (por ejemplo una ciudad que es incompatible con el cdigo postal), manejo de
datos perdidos (nulos o vacos, referencias a datos que no existen), conversin a formatos
estandarizados, y resolucin de inconsistencias.
Seleccin de atributos que son tiles para el DW. Por ejemplo, si lo que se quiere analizar
es el rendimiento acadmico de los alumnos interesar saber, entre otras cosas, cuntas
materias aprueba por ao. Puede resultar til saber cules son esas materias y las notas
obtenidas; pero no interesar saber el nmero de acta y folio donde se registr esta
informacin ni el da en que el dato fue ingresado al sistema.
Combinacin de fuentes de datos. Las fuentes se pueden combinar por medio de los
valores claves o realizando mapeos difusos (fuzzy matches) sobre atributos que no son
claves.
Este ejemplo surgi en el mbito del SIU al integrar bases de datos del SIU-Guaran de
diferentes unidades acadmicas de una universidad9. La informacin de colegios
secundarios era mantenida en forma independiente y no sincronizada en las diferentes
implementaciones. Cada unidad acadmica generaba sus propios cdigos y nombres. Al
integrar los datos se hallaron casos como los mostrados en la figura siguiente.
Unidad
acadmica
Facu1
Facu2
Facu2
Facu1
Cdigo de
colegio
Cod1
Cod1
Cod2
Cod3
Colegio
correspondiente
Cole1
Cole2
Cole1
Cole1
Descripcin
utilizada
Desc1Cole1
Desc1Cole2
Desc2Cole1
Desc3Cole1
Ejemplo
Escuela Normal Superior N1
Esc Sup de Comercio
Esc Normal Sup Nro 1
Normal Nro 1
Figura 4. Ejemplo de problema de calidad de datos.
Crear claves. Asociar un nuevo identificador a cada registro de dimensin y evitar la

dependencia de las claves definidas en las fuentes. El proceso de generacin de nuevas
claves sustitutas (o subrogadas) impone la integridad referencial entre las tablas de
dimensiones y las tablas de hechos10. Lo recomendable para las claves de dimensin es
que sean numricas y secuenciales y totalmente independientes de las claves de los
sistemas operacionales.
El costo de todas las tareas descriptas depende en gran medida de la calidad de los datos
en los sistemas fuentes y apuntan a garantizar la calidad de los datos en el DW. La calidad debe
ser una lnea conductora en todo el proceso de anlisis de informacin y toma de decisiones. El
DW ser actualizado con cierta frecuencia sobre la base de una carga controlada de datos
correctos. La carga de datos al DW recibe tambin el nombre de carga en masa.
La creacin de agregados, esto es informacin agrupada que se guarda en el DW, as
como tambin la creacin de ndices pueden considerarse como parte del proceso de carga de
datos al DW. Estas tareas apuntan exclusivamente a resolver posibles problemas de performance.
9
En la mayora de las universidades la implementacin del SIU-Guaran se realiza por unidad acadmica, contando as a
nivel global con diferentes bases de datos independientes.
10
Las definiciones de los conceptos de tablas de hechos y tablas de dimensiones estn en el captulo siguiente dentro de la
seccin de modelado multidimensional.
20
Captulo 2 -
Almacenamiento y presentacin de los datos

El rea de almacenamiento y presentacin de datos, tambin denominada servidor de
presentacin es el lugar donde se ubican el DW y los Data Marts. En esta rea los datos se
organizan y guardan para ser consultados en forma directa por los usuarios, generadores de
reportes y otras aplicaciones. Los datos deben ser presentados y almacenados en un formato
dimensional.
La definicin de DW se present en la seccin 2.2. Como se anticip la definicin clsica
ha dado origen a otros conceptos para adaptarse a las diferentes realidades. El trmino ms
resonante es el de Data Mart. Un Data Mart es un subconjunto lgico del DW. Contiene datos
personalizados y/o sumarizados derivados del DW, confeccionados para soportar los
requerimientos analticos de un determinado sector o funcin del negocio. Cada Data Mart utiliza
una visin empresarial comn de los datos estratgicos y provee sectorizaciones ms flexibles.
Entre las caractersticas de los Data Marts se destacan:
-
Los Data Marts pueden o no localizarse fsicamente en la misma mquina que el DW. Esto
permite a los consumidores de la informacin elegir la mejor tecnologa que soporte el
estilo de anlisis que necesiten.
Los Data Marts deben ser implementados como una extensin del DW, no como una
alternativa. La estrategia a largo plazo dicta que es necesario contar con la infraestructura
completa para tener un DSS saludable.
La construccin de Data Marts para soporte de decisiones es ideal. Sin embargo hay que
tener en cuenta que la simplicidad de su diseo puede conducir a tener mucha cantidad de
ellos implicando as un alto costo para administrarlos.
Kimball define a un Data Mart como una porcin de la torta completa que representara el
DW. As mismo este autor presenta una metodologa bottom-up comenzando por el desarrollo de
Data Marts para construir luego un DW como unin de estos. Argumenta que un Data Mart
representa un proyecto que puede llegar a ser terminado comparado con la imposible
responsabilidad galctica de desarrollar un DW. Generalmente se ve al Data Mart como una
restriccin del DW a un simple proceso del negocio o a un grupo de procesos del negocio
relacionados dirigidos hacia un grupo particular de usuarios.
En todo Data Mart se imponen requerimientos especficos de diseo. Todo Data Mart se
representa por un modelo dimensional y se construye a partir de dimensiones y hechos pactados11
para luego poder ser combinado y usado en conjunto con otros Data Marts (DW Bus Architecture).
Sin la adhesin a esta arquitectura un Data Mart se convierte en una solucin especfica y aislada
que no puede ser compartida con otras reas del negocio en lugar de pertenecer a una solucin
en conjunto. Si los Data Marts se disean con dimensiones y hechos conformados es posible
combinarlos y usarlos juntos [Kim1998]. Se dice que las dimensiones estn conformadas o
11
Kimball utiliza el trmino fact (hecho) como sinnimo de medida o mtrica. Debe interpretarse as cuando se hace
referencia a hechos conformados o pactados. En general en este trabajo se utiliza el trmino hecho para referirse ms
bien al evento que tiene asociadas medidas, que a las medidas en s.
21
Captulo 2 -
pactadas cuando son exactamente iguales (incluyendo las claves) o una es un perfecto
subconjunto de la otra. Si dos dimensiones estn conformadas pueden ser combinadas
perfectamente. Hechos o medidas de mltiples tablas estn conformados cuando las definiciones
semnticas de estos son equivalentes. Si tienen esta caracterstica pueden tener el mismo nombre
en tablas separadas y pueden ser combinados y comparados matemticamente. Si los hechos no
concuerdan entonces cada interpretacin debe recibir un nombre diferente.
No se cree que los dos puntos de vista sobre la construccin top-down y bottom-up de un
DW sean contradictorios. La perspectiva extrema top-down es completamente centralizada, la
base de datos principal se debe disear totalmente antes de que sus partes sean sumarizadas y
publicadas en Data Marts individuales. La perspectiva extremadamente bottom-up es que el DW
de toda la organizacin puede ser ensamblado a partir de Data Marts dispares y no relacionados.
Ninguno de estos extremos es prcticamente posible. La idea es entonces combinar ambas
propuestas, teniendo una arquitectura que gue el diseo de todas las piezas separadas
[Kim1998].
Anlisis de informacin
En la figura 3 se ejemplifican diferentes estilos de anlisis de informacin. Estos estilos se
implementan con diferentes herramientas y aplicaciones. Todo esto forma parte del rea de
anlisis de informacin. Listados en texto plano y planillas de clculo usadas para la toma de
decisiones tambin pueden incluirse dentro de esta rea. A continuacin se proveen las
definiciones de las herramientas ms usadas para el anlisis de informacin:
-
Aplicaciones de usuario final. Se refiere as a la coleccin de herramientas que consultan,

analizan y presentan informacin buscada para soportar una necesidad del negocio. El
conjunto mnimo de estas aplicaciones de usuario consiste de herramientas de acceso a
datos, planillas de clculo, paquetes grficos, y facilidades de interfaz de usuario para
obtener simples presentaciones de pantalla.
Herramientas de acceso a datos de usuario final. Se trata de herramientas que corren en

clientes y que sirven para consultar, buscar, o administrar datos guardados en el DW o
Data Marts. Pueden tomar la forma de editores de consultas SQL, cuya salida es en un
listado de datos en pantalla o un reporte o un grfico. Una herramienta de acceso a datos
puede ser algo tan simple como una herramienta de consultas ad hoc como una
sofisticada herramienta de data mining. Este ltimo tipo de aplicaciones resulta interesante
para deteccin de patrones y pronsticos.
Herramientas de consultas ad hoc. Son un tipo especial de herramientas de acceso a

datos que invitan a los usuarios a disear sus propias consultas en el momento.
Es difcil tener un patrn de consultas cuando se utiliza anlisis ad hoc. Por este motivo es
conveniente que el modelo de la base de datos sea lo ms simtrico posible para que
todas las consultas luzcan igual. Esta es una fortaleza del modelado multidimensional de
un DW.
22
Captulo 2 -
Este tipo de consultas tan poderosas pueden ser efectivamente usadas y entendidas solo
por el 10% de los usuarios potenciales del DW. El 90% restante de los usuarios
potenciales debe disponer de aplicaciones preconstruidas que ofrezcan modelos de
consultas (templates) en lugar de que el usuario deba construirlas.
-
Aplicaciones analticas. Se trata de aplicaciones de acceso a datos preconstruidas

previstas para usuarios que consultan el DW no muy frecuentemente. Tpicamente
parametrizadas con flexibilidad para analizar innumerables combinaciones. Tales
aplicaciones representan una oportunidad de encapsular las mejores prcticas de anlisis
de una organizacin. Aplicaciones para anlisis de riegos, o anlisis de mercados son
algunos ejemplos.
Aplicaciones estadsticas. Son aplicaciones establecidas para realizar anlisis estadsticos

difciles y complejos como anlisis de excepciones, medias, promedios y patrones. El DW
es la fuente de datos para estos anlisis. Estas aplicaciones analizan cantidades masivas
de datos detallados y requieren un entorno razonablemente eficiente.
Aplicaciones de modelado. Incluye a una variedad de aplicaciones cliente sofisticadas, con

capacidades analticas que transforman o resumen la salida del DW. Dentro de estas
aplicaciones se encuentran, entre otras:
Modelos de pronstico (forecasting) que buscan hacer predicciones

analizando comportamientos pasados.
Modelos de clasificacin de comportamientos (clustering) que agrupan y

clasifican perfiles. Por ejemplo, en el mbito universitario se podra agrupar alumnos
segn caractersticas personales, demogrficas o socio econmicas.
Minera de datos. Son un tipo de consultas indirectas que buscan encontrar patrones
ocultos en los datos. Los resultados ms valiosos son agrupamientos, clasificaciones,
estimaciones, predicciones, y asociaciones de cosas que ocurren juntas12. Hay muchos
tipos de herramientas para minera de datos. Las principales incluyen rboles de decisin,
redes neuronales, razonamiento basado en casos o reglas de asociacin, herramientas de
visualizacin, algoritmos genticos, lgica difusa, y estadstica clsica.
Esta rea tambin recibe el nombre de descubrir conocimiento en bases de datos KDD
(Knowledge Discovery in Databases).
2.5
Aplicaciones tradicionales versus aplicaciones para anlisis de

informacin
Para finalizar la descripcin del entorno del DW y antes de desarrollar las perspectivas y
tcnicas necesarias para disearlo, hay que resaltar una caracterstica importante: el DW es muy
diferente a los sistemas transaccionales u OLTP. Las diferencias radican en: los objetivos
principales de construccin, el perfil de los usuarios y sus necesidades, los datos que contienen
12
Un ejemplo tpico en el anlisis de compras en supermercados es el patrn que indica que las personas que compran
paales compran cerveza. Este tipo de resultados sirve para decidir la distribucin de las gndolas.
23
Captulo 2 -
(resaltando diferentes aspectos de estos: orientacin o alineacin de su estructura, integracin e

historicidad), el acceso y manipulacin de datos (patrones de uso, ritmos de carga de datos,
administracin de datos, etc.). Tambin difiere el hardware, el software, la administracin y la
gestin del sistema. Todo esto hace que las tcnicas e instintos de diseo apropiados para el
procesamiento de transacciones sean inapropiados.
Es importante resaltar las diferencias entre ambos ambientes pues, la mejor manera de
entender OLAP, es entender las diferencias con los sistemas transaccionales tradicionales
[Mst2005].
Caracterizacin de las diferencias

Sobre los objetivos principales
Los OLTP tienen como objetivos asistir a aplicaciones especficas, y mantener la
integridad de los datos. Mientras que los OLAP apuntan a asistir en el anlisis del negocio,
identificando tendencias, comparando perodos, gestiones, mercados, ndices, etc. mediante el
almacenamiento de datos histricos.
Sobre el perfil de usuarios
El perfil del usuario que interacta con los sistemas OLTP se encuadra dentro de los
empleados operativos de una organizacin. Los usuarios de un OLTP hacen que la compaa
funcione. Tienen como funcin principal la entrada de datos. Tambin realizan consultas a nivel de
un registro por vez. Los usuarios OLTP realizan las mismas tareas una gran cantidad de veces.
Por el contrario, dado el objetivo estratgico y el nivel de informacin que manejan los DW,
el perfil del usuario sobre este tipo de sistemas corresponde a la comunidad gerencial, la cual est
a cargo de la toma de decisiones. Los usuarios de un DW miran como funciona la organizacin y
definen el rumbo a seguir. Miran qu datos son nuevos, piden que los datos errneos sean
corregidos. Los usuarios de un DW casi nunca consultan por un registro en particular, usualmente
requieren que cientos o miles de registros sean buscados y sean comprimidos en un pequeo
conjunto de datos de respuesta. Estos usuarios cambian continuamente los tipos de preguntas.
Aunque la estructura de las consultas es similar el impacto en la base de datos vara en ir a buscar
de cientos a millones de registros para ser resumidos en el pequeo conjunto de respuesta.
Sobre los datos
Los datos existentes en el ambiente transaccional difieren de los del entorno analtico en
las siguientes caractersticas:
-
Alineacin de los datos: los OLTP estn alineados por aplicacin. Diferentes sistemas
tienen distintos tipos de datos, los cuales son estructurados por aplicacin. Se focaliza en
el cumplimiento de requerimientos de una aplicacin o una tarea especfica.
24
Captulo 2 -
En cambio, los sistemas OLAP estn alineados por dimensin. Todos los tipos de datos
estn integrados en un solo sistema. Los datos son organizados definiendo dimensiones
del negocio (reas temticas o sujetos). Se focaliza en el cumplimiento de requerimientos
del anlisis del negocio.
-
Integracin de datos: los datos tpicamente no estn integrados entre los diferentes
sistemas OLTP. Son calificados como datos primitivos o datos operacionales. Son
estructurados independientemente uno de otros, pudiendo tener diferentes estructuras de
claves y convenciones de nombres.
En los ambientes OLAP, los datos deben estar integrados. El DW, con el objetivo de
alinear
los
datos
por
reas
temticas,
necesita
integrar
datos
operacionales
estandarizando estructuras y convenciones de nombres.

-
Historia: Los OLTP usualmente retienen datos por un perodo de tiempo determinado,
despus son resguardados en almacenamientos secundarios fuera de lnea. Tambin es
comn que contengan slo valores corrientes, referentes a la situacin actual, y no valores
histricos. Puede no incluir el tiempo como un componente de la clave.
En cambio los OLAP almacenan tanta historia como sea necesario para el anlisis del
negocio. Retienen los valores de cada perodo. Es decir, almacenan una serie de fotos
instantneas de datos operacionales. La frecuencia con la cual se define el nivel de detalle
es la que se indica como nivel ms bajo de la dimensin tiempo. Toda esta cantidad y tipo
de historia apunta a ayudar a la generacin de reportes de comparacin de tendencias y
perodos de tiempo.
Por otro lado, las bases de datos orientadas al anlisis siempre contienen el tiempo como
clave dado que una de las principales razones para la construccin del DW es el
almacenamiento de datos histricos y el anlisis a lo largo del tiempo.
Sobre el acceso y manipulacin de los datos
Las diferencias de ambos ambientes en los objetivos, usuarios y datos implican
naturalmente que tanto el uso como la administracin de los datos sean diferentes. Se pueden
destacar los siguientes puntos:
25
Captulo 2 -
Ritmos de actualizacin
Un sistema OLTP tpico, como puede ser un sistema de venta por menor en un
supermercado, un sistema de reserva de vuelos, o un sistema para cajeros automticos,
etc. procesa miles o incluso millones de transacciones por da. Cada transaccin contiene
una pequea pieza de datos.
Un sistema OLAP procesa una nica transaccin diaria que contiene miles o incluso
millones de registros. En lugar de llamarse transaccin se la denomina carga de datos de
produccin o copia masiva.
Patrones de uso
Los sistemas transaccionales normalmente mantienen un patrn de uso constante
requiriendo grandes cantidades de recursos y consumiendo slo el tiempo referido a la
transaccin.
En contraposicin, los DW tienen un patrn de uso liviano con picos de usos eventuales
en el tiempo. Los picos de uso suceden cuando los datos nuevos estn por primera vez
disponibles y los das en que el negocio necesita determinados reportes.
Manipulacin de datos
Los sistemas operacionales realizan una manipulacin de datos registro por registro con
funcionalidades de actualizacin de datos. Adems necesitan de rutinas de validacin y
operaciones a nivel de registro. Generalmente involucran pocos datos en un proceso o
transaccin. Para el procesamiento de transacciones la base de datos dispara
mecanismos de bloqueos y asignacin de recursos.
En cambio, los DW tienen una carga y acceso masivo a los datos y no se realizan ABMs.
La carga y refresco es batch. La validacin de datos se realiza antes o despus de la
carga. Principalmente se realizan consultas sobre varios registros y tablas, teniendo
grandes volmenes de datos involucrados en un nico proceso o anlisis. Es por ello que
generalmente no se respetan las formas normales tan necesarias en los sistemas
operacionales clsicos. Las anomalas que tienden a subsanar estas reglas de
normalizacin no se presentan en los sistemas OLAP donde la carga de la informacin
est automatizada y puede permitirse el manejo de redundancia controlada como punto
para la mejora de los tiempos de respuesta de las consultas a la base de datos.
Performance
Se requiere que el sistema OLTP sea eficiente para realizar las tareas repetitivas de la
comunidad operativa. No se permiten actividades opcionales que lo lentifiquen, como por
ejemplo ejecutar una consulta que agrupe 100.000 registros (al menos no se permiten
mientras el sistema transaccional est siendo accedido por usuarios). La mayora de los
reportes de un OLTP son listados de tablas enteras.
La administracin de estos sistemas se basa en el aseguramiento de la performance y la
confiabilidad. Los procesos de extraccin de datos para anlisis suelen ejecutarse en
horarios en que el sistema operacional no est en produccin.
26
Captulo 2 -
La performance en un DW es tan importante como en un sistema OLTP, pero de una

forma diferente. Se esperan tiempos de respuesta rpidos a consultas agrupadoras de
datos que requeriran mucho tiempo para ser resueltas en un sistema OLTP. Se requiere
disponibilidad del sistema especialmente en determinados momentos y/o situaciones.
-
Consistencia
Tanto el OLTP como el DW estn altamente involucrados con la consistencia de los datos.
Sin embargo en los sistemas OLTP la consistencia es microscpica. Lo que importa es
que se hayan procesado todas y cada una de las transacciones que se presentaron al
sistema.
En un DW la consistencia se mide globalmente. Se cuida que la carga actual de datos
nuevos sea un conjunto completo y consistente de datos. En vez de una perspectiva
microscpica se tiene una perspectiva de aseguracin de calidad. En lugar de un clculo
tcnico de consistencia existe una visin o juicio gerencial de esta. Se tiene cuidado sobre
los estados consistentes del sistema antes de comenzar la carga de datos de produccin y
al finalizarla con xito. Si forzadamente hubiera que detener una carga de datos de
produccin antes de que est completa, no se podr volver atrs registro por registro; en
cambio habr que sobrescribir el sistema entero con una nueva foto del sistema tomada
antes de que comience la carga.
Nivel de datos fsico para anlisis de informacin

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

Refiere a una tecnologa de bases de datos multidimensional y propietaria, tambin
denominada cubo de datos. La performance es la caracterstica principal. Tanto los datos
detallados (o fuente) como los datos agregados o precalculados residen en el mismo formato
multidimensional. Optimiza las consultas, pero suele requerir ms espacio de disco y diferente
software.
OLAP Relacional (ROLAP)
Es una tecnologa que proporciona la misma funcionalidad que MOLAP con la diferencia
de que los datos son guardados en una base de datos relacional. La palabra que mejor describe a
ROLAP es escalabilidad, dado que puede cubrir un amplio conjunto de datos.
Tanto los datos precalculados y agregados como los datos fuente residen en la misma
base de datos relacional. Puede presentar problemas en los tiempos de respuestas cuando el
volumen de la informacin a agrupar es muy grande.
OLAP Hbrido (HOLAP)
Es una combinacin de los anteriores. La palabra que describe a esta tecnologa es
compromiso.
Los
datos
agregados
precalculados
se
almacenan
en
estructuras
multidimensionales y los de menor nivel de detalle en una base de datos relacional. Requiere un
buen trabajo de anlisis para identificar cada tipo de dato.
Comparacin de las distintas implementaciones
ROLAP es una arquitectura flexible y general, que crece para dar soporte a amplios
requerimientos OLAP.
MOLAP es
una solucin
particular, adecuada para
soluciones
departamentales con volmenes de informacin y nmero de dimensiones ms modestos.

Al momento de optar por una de estas tecnologas debern evaluarse: la performance que
se necesita, el volumen de datos que se maneja, la escalabilidad y como se adapta la arquitectura
propuesta por cada proveedor a la realidad de la organizacin.
La tendencia del mercado de estas herramientas es hacia los sistemas HOLAP. Tanto los
proveedores clsicos de MOLAP como los ROLAP estn incluyendo el otro estilo dentro de su
solucin para abarcar las ventajas de ambos: gran capacidad de anlisis y alta performance.
HOLAP est bien representado en la arquitectura de la figura 3, implementando el DW en una
base de datos relacional y la gran mayora de los Data Marts como cubos multidimensionales, que
pueden estar conectados al DW mediante consultas prediseadas para mostrar informacin ms
detallada.
28
Captulo 2 -
2.6
Tendencias en sistemas para anlisis de informacin

El DW es el corazn de un DSS. El trmino DSS se suele usar como sinnimo de Data
Warehousing y de Business Intelligence. En un sentido estricto, las definiciones de estos

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

sencilla de anlisis, permitiendo que cualquier usuario pueda ver de manera minuciosa
subconjuntos de datos interrelacionados o cubos. Sirve para descubrir relaciones entre los
datos, analizar tendencias y realizar comparaciones histricas.
29
Captulo 2 -
Tableros de comandos y paneles de control (scorecards y dashboards). Proveen

facilidades de anlisis sumariado y altamente repetitivo, en lnea, focalizado en
determinados tpicos. Se basa en una serie de indicadores. Es apropiado para gerentes y
ejecutivos que requieren una visin integral del rendimiento del negocio y hacer
seguimientos exhaustivos a travs del tiempo de temas especiales.
Notificaciones de alertas y excepciones (broadcasting). Transmiten informacin a

diferentes puntos de la organizacin cuando determinados hechos suceden. Un anlisis
que no es en lnea.
Reporte empresarial (enterprise reporting). Generacin de informacin con alto nivel de

detalle para un nivel gerencial que se utiliza para tomar decisiones. Es el estilo de BI ms
utilizado. El nfasis est en la parte grfica. No es en lnea ni como tableros. Lo que
importa es la presentacin.
Anlisis avanzados y predictivos (data mining). Anlisis estadstico de datos para generar
patrones predictivos, pudindose delegar parte de las decisiones al sistema. Brinda
capacidades completas y muy poderosas para investigaciones profundas de cualquier
sector y para encontrar los detalles que se esconden tras los resultados.
Desde el punto de vista tcnico las reas ms importantes incluidas dentro de BI son [14]:
DW arquitectura, diseo, administracin, procesamiento y carga.
Limpieza de datos y aseguramiento de la calidad (incluye el proceso ETL).
Data mining, anlisis estadsticos y pronsticos.
OLAP procesamiento analtico en lnea y anlisis multidimensional.
DSS, Sistemas de Informacin Ejecutiva (EIS), y otros sistemas expertos, agrupados en el

trmino de Gestin de Sistemas de Informacin (Management Information Systems o
MIS). Sistemas para analizar la informacin de otros sistemas y que sirve para la toma de
decisiones.
Elaboracin de reportes, visualizacin de informacin y paneles de control (dashboards).
Gestin en relacin con los clientes (Customer Relationship Management o CRM).

Otras definiciones utilizadas en sistemas de anlisis de informacin:
Sistemas de Informacin Ejecutiva (EIS: Executive Information Systems). Son sistemas

diseados para los ejecutivos ms altos de una organizacin. Entre las caractersticas ms
importantes permiten anlisis de desgranamiento (drill down) y de tendencias.
Un EIS es una herramienta de BI que permite monitorear el estado de las variables de un
rea o unidad de la empresa a partir de informacin interna y externa.
Se puede considerar que un EIS es un tipo de DSS cuya finalidad principal es que el
responsable de un departamento o compaa tenga acceso, de manera instantnea, al
estado de los indicadores de negocio que le afectan, con la posibilidad de estudiar con
30
Captulo 2 -
detalle aquellos aspectos que no estn cumpliendo con los objetivos establecidos en su
plan estratgico u operativo, y as determinar las medidas de contingencia ms
adecuadas.
Una de las caractersticas ms importantes de un EIS es que permite a usuarios con perfil
no tcnico construir nuevos informes y navegar por los datos de la compaa, con el
objetivo de descubrir informacin que les resulte relevante. Esto se debe, entre otras
cosas, a que la interfaz grfica de estas aplicaciones suele ser muy atractiva e intuitiva. El
EIS suele incluir tambin alertas de negocio, informes histricos comparativos y anlisis de
tendencias.
Un EIS suele necesitar de un DW o Data Mart que acte como fuente central de
informacin, unificando, depurando e integrando las distintas bases de datos
operacionales de la compaa [15].
-
Fbrica de informacin corporativa (CIF: Corporate Information Factory). Es un modelo de

arquitectura propuesto por Inmon que contiene un DW, Data Marts, un almacn de datos
operativos (ODS), sistemas operativos, aplicaciones para soporte de decisiones, distintas
interfaces para usuarios, herramientas de data mining y dems componentes. Amplia la
arquitectura de la figura 3. Para obtener ms detalles consultar referencias [10] y [11].
Almacn de datos operativos (ODS: operacional data store). Un ODS es una coleccin de
datos orientada a temticas (subject-oriented), integrada, con valores actuales y voltiles,
usada para soportar el proceso de toma de decisiones tcticas para una organizacin o la
administracin del negocio.
Este concepto difiere del de DW por contener datos actuales en lugar de histricos y
voltiles en lugar de permanentes. Los DW y Data Marts estn orientados principalmente a
soportar procesos de decisiones estratgicas. El ODS es el ncleo de la administracin del
negocio (business management). Ambos conceptos se complementan.
No siempre es necesario implementar un ODS, slo cuando se requiera acceso a datos
actuales en forma integrada. Esto es especialmente til cuando hay muchos sistemas
operacionales que crecen en forma independiente unos de otros y necesitan consultarse
en forma integrada para obtener informacin.
La razn principal de un ODS es proveer reportes inmediatos y consistentes de resultados
actuales. Requiere soportar accesos operacionales constantes y actualizaciones, por eso
debe mantenerse en forma separada al DW. Juega un rol operacional, de tiempo real. Si
los objetivos son slo prever reportes y soporte de decisiones hay que evaluar su
implementacin y ver si estas necesidades no debieran ser cubiertas directamente por el
DW.
Como un ODS es necesariamente una extraccin de datos transaccionales, este puede
tambin jugar el rol de fuente del DW.
31
Captulo 2 -
2.7
El mercado de Data Warehousing y Business Intelligence

En los ltimos aos la utilizacin de este tipo de soluciones ha crecido muchsimo dando
origen a una expansin del mercado y desarrollo de diferentes herramientas. No es objetivo de

esta tesis realizar un anlisis del mercado. Se presenta slo un panorama muy general. Para
interiorizarse en las caractersticas de cada solucin, que difieren bastante en arquitectura,
funcionalidad, interfaz con el usuario y costo, entre otras cosas, se pueden consultar [19] al [40]..
Se trata de un mercado variado. Existen tanto soluciones pequeas y especficas como
otras abarcativas y ambiciosas, todas en continuo crecimiento e intentando cubrir mejor y ms
aspectos dentro del rea de BI.
Existen empresas de mediana escala que slo desarrollan soluciones de BI (denominadas
pure-play), vendedores de mega-aplicaciones de software, y tambin soluciones pequeas,
innovadoras y especializadas (denominadas niche players). El mercado actual est dominado
por las soluciones pure-play, pero los tres tipos de proveedores tienen fuerte demanda. Varios
vendedores de grandes aplicaciones e infraestructura de software se han convertido en el ltimo
tiempo en competidores mucho ms fuertes en esta rea, en parte por contar con otros productos
propios ya implementados en las empresas y por los costos de las soluciones BI que proponen,
que suelen ser menores que algunas soluciones puras, y adems porque han comprado
soluciones ya existentes para incorporarlas a su empresa.
Los principales proveedores del mercado mundial son: Microsoft, Hyperion, Cognos,
Business Objects, MicroStrategy y SAP, en ese orden, segn destaca The Olap Report, la revista
mundial en Business Intelligence [5].
En Argentina quienes se destacan como referentes internacionales de BI son Cognos,
Business Objects son los ms antiguos, operan desde los 80 MicroStrategy, SAS y SPSS.
Cognos es muy fuerte en los Estados Unidos en empresas medianas y pequeas, mientras que
Business Objects es lder en Europa. MicroStrategy es fuerte en sectores como venta por menor
(retail) y en grandes empresas. SAS y SPSS son tradicionales lderes en data mining. Y el
segmento en Argentina lo lidera MicroStrategy, seguido por Cognos, SAP, Oracle y Microsoft, en
este orden. La razn principal es el tiempo que llevan instalados en el pas [3]. Otros proveedores
importantes son: IBM, Pentaho, QlikView y Stratebi.
La mayora de los proveedores (denominados players o vendors) de estas soluciones se
han comenzado con uno de los estilos de BI, y luego fueron extendindose a los dems. Cuantos
ms estilos abarca cada proveedor, obviamente brinda una solucin ms completa. La tendencia
es tener una solucin completamente integrada que cubra todos los aspectos de BI, lo que en el
mercado se denomina suite o plataforma. Cognos y MicroStrategy se especializaron originalmente
en OLAP y Business Objects en tableros. Y desde hace unos aos comenz la carrera por sumar
los estilos faltantes. Algunos de los movimientos ms resonantes fueron la compra de Crystal
32
Captulo 2 -
Decisions (lder en enterprise reporting) que concret Business Objects. Oracle compr Siebel,
Hyperion compr Brio, y Cognos a Adaytum y tambin a Applix. Y las ms recientes e importantes
son la compra de Hyperion por Oracle, y la de Cognos por IBM junto con el acuerdo realizado
entre SAP y Business Object. Tambin hubo cantidad de operaciones ms pequeas. As como
algunas empresas compraron otras e integraron las soluciones, otras, como es el caso de
MicroStrategy, han desarrollado sus propias herramientas.
Como se puede observar, es un mercado en continuo movimiento, y la tendencia es que
las grandes empresas lderes en tecnologa de informacin se consoliden tambin como lderes
del mercado de BI.
Tambin se espera un importante crecimiento de Pentaho, que es el ms completo de los
productos de software libre. El fuerte de esta herramienta est en la interfaz para manipular y
limpiar datos. Tiene diferentes mdulos para desarrollo de cubos, reportes, tableros de control, y
data mining integrados. La solucin es an un poco dura en lo que respecta a funcionalidad e
interfaz con el usuario, pero es uno de los casos ms prometedores por contar con licenciamiento
gratuito.
Para la implementacin del caso prctico su utiliz O3 de la empresa uruguaya, con sede
en Argentina, IdeaSoft. Esta herramienta est disponible en el SIU para el desarrollo de este tipo
de soluciones y actualmente se est utilizando en aproximadamente 15 universidades nacionales
del pas. Una de las ventajas de la herramienta es que permite una metodologa de desarrollo
prctica y sencilla de implementar, adems de tener un costo de licenciamiento accesible.
33
Captulo 3 - El proceso de creacin de modelos analticos
El proceso de creacin de modelos analticos

En el captulo anterior se detallan las diferencias de ambientes y objetivos entre los
sistemas OLAP y OLTP. Estas diferencias hacen que las tcnicas de diseo y el modelo del ciclo
de vida clsico utilizados para desarrollar un sistema operacional no resulten apropiados para el
entorno analtico. En este captulo se presentan las tcnicas y metodologas principales para
garantizar el xito de un proyecto de Data Warehousing.
3.1
Introduccin al modelado multidimensional

El modelado multidimensional es una tcnica para disear bases de datos simples y
entendibles. Se busca visualizar a la base de datos como si fuera un cubo de tres, cuatro, cinco o
ms dimensiones. Cuando esto sucede, los usuarios finales pueden imaginarse navegando la
informacin contenida, realizando cortes (slicing and dicing14) a ese cubo a travs de cada una de
sus dimensiones [Kim1996]. Los modelos multidimensionales brindan la habilidad de visualizar
datos en una forma concreta y tangible que facilita la comprensin de estos.
En un ejemplo simple aplicado al mbito acadmico universitario: los alumnos rinden
exmenes de diferentes materias en alguna fecha, registrndose la nota o resultado obtenido; es
sencillo pensar este hecho como un cubo de datos, con etiquetas en cada una de las aristas del
cubo como se muestra en la figura 5.
Figura 5. Ejemplo de cubo sobre exmenes rendidos.
Cualquier punto dentro del cubo es la interseccin de las coordenadas definidas por los
lados. Para el ejemplo los lados del cubo son nombrados: alumno, materia y fecha. Es posible
imaginar que en los puntos interiores es donde se guardan las medidas asociadas a la
combinacin de alumno, materia y fecha, en este caso el resultado o nota.
14
Slicing y dicing se traduce como rebanar y cortar en dados. Refleja la accin de partir un cubo de informacin en cubos
ms pequeos para focalizar el anlisis.
34
Dim_Alumno
Alumno_cod
Alumno_desc
Dim_Fecha
Fecha
Mes
Ao
Examenes
Dim_Materia
Materia_cod
Materia_desc
Alumno_cod
Materia_cod
Fecha
Nota
Figura 6. Ejemplo de modelo dimensional sencillo sobre exmenes rendidos.
En la figura 6 se muestra el modelo dimensional que refleja la situacin planteada,

mientras que en las figuras 7 y 8 se puede apreciar parte del modelo tpico de dependencias entre
datos15, permitiendo la comparacin entre ambos diseos.
Figura 7. Ejemplo de modelo de dependencias de datos del SIU-Guaran referente a exmenes rendidos.
Las figuras 7 y 8 ciertamente revelan con ms detalle las relaciones entre los datos que la
figura del modelo dimensional, pero no contribuyen al entendimiento la situacin que describen 16.
Desafortunadamente la mayora de las personas no pueden retener en la mente un diagrama
como este y no pueden entender como navegarlo tilmente.
Para el problema de anlisis de informacin, las relaciones existentes entre los datos se
ven mejor dinmicamente en una pantalla que en diagramas estticos que el usuario trata de
mantener en su mente. Ambos modelos (dimensional y de dependencias de datos) de un negocio
son capaces de guardar exactamente los mismos datos, y son capaces de soportar exactamente
15
El modelo de dependencias de datos tambin es llamado a veces diagrama entidad relacin (DER). Aunque no sean lo
mismo. De hecho, tambin es posible usar un DER para representar un modelo dimensional.
16
Se muestran slo algunas tablas relacionadas con el ejemplo de todo el modelo de datos del SIU-Guaran. El modelo de
datos real es ms complejo.
35
el mismo anlisis final. Es slo que se elige presentar los datos de una manera diferente, en un
formato simtrico. En el ejemplo, el modelo dimensional provee un sentido natural para
descomponerlo en los componentes alumno, materia y fecha. Los usuarios usarn la palabra
dimensin en una conversacin estn o no visualizando un cubo de datos. La atraccin central del
modelo dimensional es su simplicidad, que permite a los usuarios entender las bases de datos,
que el software las navegue eficientemente y tiene la capacidad de adecuarse a los cambios.
Figura 8. Ejemplo de modelo de dependencias de datos del SIU-Guaran.

Detalle de tablas principales sobre informacin de exmenes rendidos.
La distincin entre los modelos dimensionales y de dependencias de datos est centrada

en el diseo de un DW. Un DW debe ser construido desde la simple perspectiva dimensional en
lugar que desde la compleja perspectiva de las dependencias de datos para servir a su
propsito17.
Un modelo dimensional se basa conceptualmente en uno o ms hechos. Cada hecho est
asociado a una o ms medidas y a un conjunto de dimensiones18. Se implementa mediante un
conjunto de tablas. Las tablas pueden contener hechos (tablas de hechos), o descripciones de las
dimensiones (tablas de dimensiones, de bsqueda o de catlogo). Las tablas de hechos
relacionan dimensiones en su nivel de granularidad respectivo y contienen las medidas asociadas
a los hechos que describen.
El modelo multidimensional de un DW se compone de diferentes submodelos, tambin
dimensionales, que se corresponden con los diferentes Data Marts. Cada Data Mart debe tener al
17
El DW debe responder a un modelo lgico multidimensional, ms all de que sea implementado en una base de datos
multidimensional (MOLAP) o en una relacional (ROLAP).
18
En muchos textos no se distingue entre los trminos hecho y medida, utilizndose el trmino fact para referirse a
ambos. Aqu en general se utiliza el trmino hecho para referirse ms bien al evento o suceso a medir que a la medida, o
mtrica en s.
36
menos una tabla de hechos, y en general tiene muchas tablas de dimensiones. Tambin cada
tabla de hechos define en s misma un submodelo dimensional que es parte de otros que lo
contienen.
Dimensiones, hechos y medidas

El modelo dimensional organiza y presenta los datos definiendo dimensiones. Las
dimensiones son lneas o reas temticas del negocio. Por ejemplo en un sistema de ventas, son
dimensiones producto, sucursal, tiempo. Representan a las entidades independientes que sirven
como punto de entrada para el anlisis de la informacin. En el mbito universitario y sobre el
anlisis de comportamiento acadmico de alumnos se podran considerar a las dimensiones:
carrera, lugar de procedencia, ao de ingreso, entre otras.
Cada elemento de una dimensin tiene una clave, que lo identifica en el mayor nivel de
detalle y un conjunto de atributos. Los atributos representan categoras o agrupaciones de
elementos y tienen la finalidad de mostrar a la informacin de cada dimensin en diferentes
niveles de detalle y agrupar los elementos para ser analizados.
Las relaciones entre los atributos de cada dimensin determinan jerarquas. Las jerarquas
son ordenamientos lgicos y puede que exista ms de una jerarqua dentro de la misma
dimensin, pero siempre podr identificarse una jerarqua principal. Por ejemplo para la dimensin
lugar de procedencia, la clave est dada por la identificacin del colegio. El colegio determina a la
localidad, la localidad a la provincia y esta ltima al pas, presentando cuatro niveles de
granularidad para analizar a la informacin. La jerarqua principal (y nica de esta dimensin) est
dada por los atributos pas, provincia, localidad y colegio, en ese orden. En este caso la relacin
entre los atributos, vindola del nivel ms detallado al ms agrupado es siempre de muchos a uno.
Este tipo de relacin padre-hijos en las jerarquas de atributos de una dimensin es el caso ms
general, pero no el nico.
Algunas de las soluciones, como es el caso de O3, tienen la limitacin de permitir modelar
una jerarqua nica por dimensin y donde los niveles deben estar determinados por relaciones de
tipo padre-hijos. En caso de necesitar representar diferentes jerarquas estas debern modelarse
como dimensiones separadas19.
Los atributos de diferentes dimensiones se relacionan a travs de hechos. Se consideran
hechos a sucesos o eventos que ocurren, como por ejemplo alumnos que cursan carreras, o que
rinden exmenes. Estos eventos generalmente estn asociados a una o mas medidas.
Las medidas, mtricas o indicadores son variables numricas que ayudan a medir el
rendimiento de un negocio. Estas medidas pueden ser de dos tipos: bsicas y derivadas. Las
medidas bsicas existen dentro del DW junto a los atributos que las caracterizan. Pueden provenir
de diferentes fuentes, tener diferentes niveles de granularidad y estar determinadas por diferentes
19
Un ejemplo puede ser la dimensin producto, donde la jerarqua principal estara dada por el cdigo de producto, la lnea,
la categora y el rubro, y adems pueden existir jerarquas secundarias como el color o la marca.
37
hechos o eventos. Por ejemplo la variable unidades vendidas puede definirse a nivel de da para la
dimensin tiempo mientras que la variable unidades en stock puede ser llevada semanal o
mensualmente. Las medidas derivadas se calculan a partir de las bsicas y pueden o no estar
almacenadas fsicamente en el DW. Un ejemplo de medida derivada podra ser el clculo de las
ganancias a partir de las ventas menos los costos.
Navegacin del modelo multidimensional

Se entiende por navegacin o drilling a la accin de consultar datos dentro de un modelo
multidimensional. Estas facilidades estn determinadas por las dimensiones y sus jerarquas, que
definen el mapa de caminos para la navegacin de los datos. Existen distintos modos de buscar
informacin. Se utilizan trminos especficos segn el tipo de consulta que se realice:
-
Navegar (drilling o slice and dice20) es la habilidad de acceder al DW o Data Mart a travs
de sus diferentes dimensiones. Es el proceso de separar y combinar datos de una misma
manera.
Agregar (drill-up o roll-up) es la accin de moverse hacia un atributo superior dentro de la

jerarqua de una dimensin (navegacin ascendente, tambin denominada agregacin
dinmica).
Desagregar (drill-down o roll-down) es cuando se analiza informacin a mayor nivel de

detalle dentro de una dimensin (navegacin descendente).
Trasversar (drill-across) para analizar informacin de dimensiones acordadas sobre

diferentes hechos (navegacin entre diferentes tablas de hechos, modelos o cubos).
Tambin se utiliza este trmino para referirse a la navegacin inter-dimensional.
Atravesar (drill-through). Esto es cuando los Data Marts de tipo MOLAP se conectan al
DW a travs de consultas predeterminadas para visualizar informacin con un grado de
detalle que no est incluido en el cubo.
La operacin ms comn en anlisis de tipo OLAP es el drill-down. La mayora de las
herramientas brindan esta operacin como la accin por defecto al seleccionar o hacer clic sobre
algn valor.
Tabla de hechos
Una tabla de hechos es una tabla primaria en cada modelo (o submodelo) dimensional
que contiene medidas del negocio. Cada medida es interpretada como la interseccin de todas las
dimensiones que la definen. Toda tabla de hechos representa una relacin muchos a muchos
entre las dimensiones y contiene un conjunto de dos o ms claves forneas que la vinculan a sus
respectivas tablas de dimensin. Las tablas de hechos representan los sucesos ocurridos. No se
debiera intentar llenarlas con ceros representando que nada ha sucedido.
20
El trmino slice and dice refiere a la accin de rebanar y cortar en cuadraditos un cubo de informacin.
38
El nivel de detalle de cada dimensin que se utiliza en la tabla de hechos define la

granularidad de las medidas. Las medidas ms tiles son numricas y aditivas. Pero no todas las
medidas son aditivas, existen medidas semi-aditivas y no aditivas. Tambin es posible que la tabla
de hechos no contenga medidas y slo represente las relaciones entre dimensiones.
Tablas de dimensin
Las tablas de dimensin son un conjunto de tablas compaeras o guas para una tabla de
hechos. Cada dimensin es definida por su clave primaria que sirve como base para la integridad
referencial con cualquier tabla de hechos a la cual se une. La mayora de las tablas de dimensin
contienen muchos atributos o campos de texto que sirven para restringir y agrupar las consultas
del DW y determinan los niveles de anlisis.
El objetivo de los atributos de las estas tablas es servir como filtros o encabezamientos de
las consultas de usuarios. Por ejemplo al consultar cantidad de alumnos de un determinado ao
discriminados por carreras, la dimensin ao se est usando como restriccin, para filtrar un valor,
y la dimensin carreras como encabezamiento del reporte. Algunas veces un atributo numrico
puede confundirse con una medida. En estos casos hay que preguntarse si se usa para describir
una dimensin o para medir algo del negocio. El tamao de un producto y la edad de un alumno
son ejemplos de atributos numricos.
Hay tablas de dimensin que son ntegramente descriptivas. Otras, llamadas tablas de
catlogo o de bsqueda, adems de contener las descripciones asociadas a la clave primaria, se
utilizan para representar relaciones entre dimensiones relacionadas. De esta forma se evita la
redundancia del dato en la tabla de hechos cuando el valor de una dimensin depende del valor
de otra (a estos casos se los denomina subdimensiones). Por ejemplo, si en la tabla de hechos se
representa la actividad acadmica de los alumnos y el identificador de persona se utiliza en la
tabla de hechos, datos como el sexo, la localidad de procedencia y otros que dependen de la
persona, y no de cada examen rendido, pueden guardarse en una tabla de catlogo y obtenerse
de ah en lugar de estar repetidos en cada registro de la tabla de hechos. Es una forma primaria
de normalizar algunos datos para evitar redundancia y reducir el tamao de la tabla de hechos21.
Esquema estrella
Cada tabla de hechos est entonces rodeada por un conjunto de tablas de dimensiones
que describen precisamente el contexto de cada registro medido. Por esta caracterstica la
estructura de los modelos dimensionales es llamada esquema estrella .
Lo primero que se observa en el esquema dimensional resultante es su simplicidad y
simetra. Se ha demostrado que los modelos dimensionales son entendibles, predecibles,
extendibles y altamente resistentes para el anlisis de informacin del negocio que se busca. La
21
Cabe aclarar que la estructura interna final de una solucin MOLAP estar totalmente desnormalizada, sin embargo
pueden considerarse algunas normalizaciones en las etapas intermedias de construccin.
39
naturaleza simtrica de este modelo soporta especialmente las consultas ad-hoc de los usuarios
del negocio y resulta eficiente en los tiempos de respuesta.
3.2
Ciclo de vida de un proyecto de Data Warehousing

Las metodologas para construir un DW difieren claramente del clsico ciclo de vida de
desarrollo de sistemas operacionales. Mientras que este ltimo est guiado por los requerimientos
de los usuarios, el desarrollo de un DW es conducido por los datos. Una vez que se identifican los
datos existentes, se los integra, se desarrollan las herramientas de explotacin y finalmente se
atiende a los requerimientos de consultas de los usuarios. Ms especficamente, la construccin
de un DW est guiada por las necesidades de los usuarios y por los datos existentes para
saciarlas.
La metodologa para construccin de un DW ms utilizada es la propuesta por Kimball,
que recibe el nombre de ciclo de vida dimensional del negocio o BDL (Business Dimensional
Lifecycle). Las etapas del BDL se ilustran en la figura 9. En el diagrama se puede observar la
secuencialidad, dependencia y concurrencia de las tareas. Las etapas no estn temporalmente
organizadas, es decir no se determinan tiempos, plazos, ni duracin de las tareas.
Diseo de la
arquitectura
tcnica
Seleccin de
productos e
instalacin
Modelado
dimensional
Planificacin
del proyecto
Diseo
fisico
Diseo de
Requerimientos
Especificacin de
aplicaciones para
usuarios finales
Diseo de las
Extracciones y
Transformaciones de Datos
Puesta en
produccin
Mantenimiento y
crecimiento
Desarrollo de
aplicaciones
para usuarios
finales
Gerenciamiento del proyecto
Figura 9. Ciclo de vida dimensional del negocio (BDL).
Hitos del mapa de ruta del BDL

El ciclo de vida de un DW comienza con la planificacin del proyecto. Es en este momento
donde se evala la buena disposicin de la organizacin para una iniciativa de Data Warehousing,
se establece el alcance preliminar, los recursos, y se lanza el proyecto. Luego, la gestin continua
del proyecto servir para mantener el resto del ciclo de vida dentro de la planificacin realizada.
La tarea siguiente se focaliza en la definicin de los requerimientos del negocio. Observar
que existe una flecha con doble direccin entre la planificacin del proyecto y esta etapa debido a
que hay mucha interrelacin entre ambas actividades. La alineacin del DW con los
requerimientos del negocio es absolutamente crucial. La mejor tecnologa no salvar a un DW que
40
falla en focalizar en ellos. Los diseadores del DW deben entender las necesidades de los
usuarios y trasladarlas en consideraciones de diseo. Los usuarios del negocio y sus
requerimientos tienen impacto en casi todas las decisiones de diseo e implementacin a
realizarse durante el transcurso del proyecto de Data Warehousing.
En la figura se observa que siguiendo a la definicin de los requerimientos se desprenden
tres lneas de trabajo paralelas. La lnea superior tiene que ver con la tecnologa. El diseo de la
arquitectura tcnica establece el entorno general para soportar la integracin de mltiples
tecnologas. Luego, en funcin de esta arquitectura se pueden evaluar y seleccionar los productos
especficos. Observar que la seleccin de productos no es una de las primeras actividades del
ciclo de vida. Es un error frecuente seleccionar productos antes de entender bien que es lo que se
est tratando de lograr.
La lnea de trabajo del centro se focaliza en los datos. Se comienza trasladando los
requerimientos en un modelo dimensional que luego es transformado en una estructura fsica.
Durante las actividades de diseo fsico se presta especial atencin a las estrategias de puesta a
punto para lograr buenos tiempos de respuesta (performance tuning). Esta actividad incluye la
creacin de agregaciones, ndices y particiones. La ltima parte es la etapa donde se disean y
desarrollan los procesos ETL.
El tercer conjunto de tareas que siguen a la definicin de requerimientos es el diseo y
desarrollo de aplicaciones analticas. Estas aplicaciones son necesarias para completar el
proyecto de Data Warehousing y deben satisfacer un gran porcentaje de los requerimientos
analticos de los usuarios del negocio.
Luego se unen la tecnologa, los datos y las aplicaciones, junto con una buena dosis de
conocimiento y soporte, para realizar una implementacin armoniosa. De ah en ms el
mantenimiento constante es necesario para asegurar que el DW y su comunidad usuaria se
mantengan saludables.
Finalmente el crecimiento futuro del DW se realiza iniciando proyectos posteriores. Cada
uno de ellos lleva a retornar nuevamente al comienzo del ciclo de vida [Kim2002].
Presentado el mapa de ruta general se pasar a describir con ms detalle cada una de las
actividades de las etapas del BDL.
Planificacin del proyecto

La planificacin busca identificar la definicin y el alcance del proyecto de DW, incluyendo
justificaciones del negocio y evaluaciones de factibilidad. Se focaliza sobre recursos, perfiles,
tareas, duraciones y secuencialidad. El plan resultante identifica todas las tareas asociadas con el
BDL y las partes involucradas.
41
Antes de comenzar un proyecto de DW o Data Mart hay que evaluar la buena

predisposicin para su realizacin. Debe existir la demanda. Se debe contar con al menos un
usuario sponsor slido y con el entusiasmo de otros. El usuario sponsor debiera tener una visin
del impacto potencial del DW dentro de la organizacin. Otro factor crtico es la viabilidad: tcnica,
de recursos, pero especialmente de datos. Si no se cuenta con datos de buena calidad el proyecto
fracasar.
Otro punto importante de esta etapa es la conformacin del equipo de trabajo. Los perfiles
del personal afectado a la construccin de un DW son amplios y variados. Se requieren: usuarios
del negocio, sponsors, lderes, gerentes del proyecto, analistas, arquitectos, administradores de
bases de datos, diseadores, responsables de extraccin, desarrolladores, instructores, soporte
tcnico, seguridad informtica, programadores, analistas de aseguramiento de calidad, entre otros.
Definicin de requerimientos
Otro factor determinante en el xito de un proceso de Data Warehousing es la
interpretacin correcta de los diferentes niveles de requerimientos expresados por los distintos
niveles de usuarios. Los diseadores de los DW deben entender los factores claves que guan al
negocio para determinar efectivamente los requerimientos y traducirlos en consideraciones de
diseo apropiadas.
Los requerimientos del negocio deben determinar el alcance del DW (qu datos debe
contener, cmo debe estar organizado, cada cunto debe actualizarse, quines y desde dnde
accedern, etc.) e impactan en todos los aspectos del proyecto.
La forma de relevar los requerimientos es entrevistando a los usuarios finales. Durante
este proceso los diseadores descubren las necesidades y expectativas de la comunidad usuaria.
El proceso de entrevistas debe intercalarse entre grupos de usuarios del DW y grupo de tcnicos
de los sistemas fuentes. A medida que se van planteando las necesidades de anlisis se precisa
conocer si esas necesidades pueden satisfacerse con los datos y estructuras existentes. Las
entrevistas deben ser preparadas en funcin del perfil del usuario a entrevistar y no debieran durar
ms de una hora. Una vez obtenidos los requerimientos, estos debern ser priorizados y
consensuados con los usuarios.
Diseo de la arquitectura tcnica

La arquitectura tcnica es el anteproyecto para los servicios y elementos tcnicos del DW.
Sirve para integrar las numerosas tecnologas.
En el captulo anterior se present la estructura general de esta arquitectura. Dicha
estructura debe ser adaptada al caso a desarrollar, basndose principalmente en las necesidades
del negocio. Para establecer el diseo de la arquitectura tcnica del ambiente de Data
Warehousing se deben tener en cuenta tres factores: los requerimientos del negocio, los
ambientes tcnicos actuales y las directrices tcnicas estratgicas planificadas a futuro.
42
Se puede hacer una analoga entre los planos arquitectnicos de una casa y la
arquitectura de un DW. Es necesario tener un plano de lo que se desea antes de comenzar, no se
trata simplemente de reordenar y explotar la informacin. Al igual que en una construccin, los
planos sirven para comunicar los deseos entre los clientes y el arquitecto, como as tambin para
medir esfuerzos y materiales necesarios para la obra (comunicacin, planificacin, flexibilidad y
mantenimiento, documentacin, productividad y reutilizacin), y tambin sern de ayuda cuando
haya que remodelar o incorporar modificaciones.
La arquitectura tcnica se divide en dos partes, la parte interna del DW (back room) y la
cara pblica (front room), que interactan constantemente. Mientras los requerimientos del
negocio indican qu se necesita hacer, la arquitectura tcnica responde el interrogante de cmo se
har [Mst2005].
Seleccin de Productos e Instalacin

Utilizando el diseo de la arquitectura tcnica como marco, es necesario evaluar y
seleccionar los componentes especficos como ser la plataforma de hardware, el motor de base de
datos, la herramienta de ETL o el desarrollo pertinente, herramientas de acceso, etc.
Una vez evaluados y seleccionados los componentes se procede con la instalacin y
prueba de los estos dentro de un ambiente integrado [Mst2005].
Modelado Dimensional lgico

Una vez recolectados los requerimientos del negocio y habiendo auditado los datos
existentes en los sistemas operacionales estn dadas las condiciones para comenzar con el
diseo del DW.
Disear los modelos de datos para soportar los requerimientos analticos de los usuarios
requiere un enfoque diferente al usado en los sistemas operacionales. Bsicamente se comienza
con una matriz donde se determina la dimensionalidad de cada indicador y luego se especifican
los diferentes grados de detalle (atributos) dentro de cada concepto del negocio (dimensin), como
as tambin la granularidad de cada indicador (variable o mtrica) y las diferentes jerarquas que
dan forma al modelo dimensional del negocio, BDM (Business Dimensional Model) o mapa
dimensional.
En [Kim1998] se propone una metodologa para construir modelos dimensionales que
comienza identificando los correspondientes Data Marts (como conjunto de indicadores) y las
dimensiones de estos. Luego sigue con la construccin de una matriz dimensional de alto nivel
(DW Bus Architecture Matrix). En la matriz se ubican a los Data Marts como filas y a las
dimensiones como columnas y se marcan las intersecciones de aquellas dimensiones que
intervienen en cada Data Mart. La metodologa contina con el diseo multidimensional de cada
Data Mart. Se definen cuatro pasos: primero la eleccin del Data Mart, segundo la declaracin de
la granularidad, tercero la eleccin de las dimensiones y cuarto la eleccin de las medidas o
43
indicadores. Adems, recomienda un conjunto de diagramas que sern de gran ayuda en esta
etapa del proyecto: DW Bus Architecture Matrix, diagrama de tabla de hechos, detalle de tablas de
hechos y diagrama de dimensiones.
Tambin el anlisis de alto nivel de los sistemas fuentes colabora en mejorar las
estimaciones y alcances del modelo realizado. Una de las pautas que se resalta es la
comunicacin y la validacin del diseo entre el equipo de desarrollo del DW y la comunidad
usuaria.
Diseo Fsico
El diseo fsico de las base de datos se focaliza en la seleccin de las estructuras
necesarias para soportar el diseo lgico. En el modelado dimensional el diseo lgico y el fsico
se asemejan mucho. Algunos de los componentes de esta etapa son la definicin de convenciones
y estndares de nombres y seteos especficos del ambiente de la base de datos.
El diseo fsico se enfrenta a las actividades de puesta a punto de la performance del DW
que consisten principalmente en la creacin de ndices y tablas agregadas. Las estrategias de
particionamiento son tambin determinadas en esta etapa.
Las agregaciones son la tcnica de puesta a punto de mejor impacto sobre el tiempo de
respuesta de las consultas que efectuarn los usuarios. Este tema es abordado al final de la
prxima seccin.
Otros puntos a resaltar de esta etapa son: planes de desarrollo del modelo fsico,
convenciones de nombres y estndares, uso de sinnimos, uso de herramientas de modelado
para la generacin y mantenimiento del modelo fsico, estimaciones de volmenes, planes y
estrategias de indexacin, consideraciones sobre memoria y tamao de bloque, parametrizacin,
particionamiento de tablas con gran volumen de datos, sistemas de tolerancia a fallas, monitoreo,
etc. En este trabajo no se profundizan estos temas. Se recomienda leer [Kim1998] junto con la
documentacin particular del motor de base de datos que se decida utilizar.
Diseo de las Extracciones y Transformaciones de Datos

Esta etapa consiste del diseo y desarrollo del proceso ETL, descripto en el captulo 2, y
es tpicamente la ms subestimada de las tareas en un proyecto de DW.
Todas las actividades de esta etapa son altamente crticas pues tienen que ver con la
materia prima: los datos. La calidad de los datos es un factor determinante en el xito de cualquier
proyecto de anlisis de informacin. Es en esta etapa donde deben sanearse todos los
inconvenientes relacionados con la calidad de los datos fuente. La desconfianza y prdida de
credibilidad del DW sern resultados inevitables si el usuario encuentra informacin inconsistente.
44
Son muchos los desafos que deben enfrentarse para lograr datos de alta calidad de los
sistemas fuentes. Esta etapa siempre termina abarcando ms tiempo del previsto, sobre todo lo
que refiere a la transformacin de datos. Algunos tems que ayudarn a guiar esta etapa del BDL
[Kim1998].
Plan:
-
Crear un diagrama de flujo fuente-destino esquemtico de muy alto nivel.
Probar, elegir e implementar una herramienta de limpieza de datos. Se pueden utilizar

algunas de las que existen en el mercado para facilitar estas tareas y lograr una mejor
documentacin que sea til para futuras modificaciones22.
Profundizar en detalle por tabla destino. Describir grficamente las reestructuraciones o

transformaciones complejas. Ilustrar la generacin de las nuevas claves sustitutas23. Y
realizar un desarrollo preliminar de la secuencialidad de los trabajos.
Carga de dimensiones:
Construir y probar la carga de una tabla dimensional esttica. La principal meta de este
paso es resolver los problemas de infraestructura que pudieran surgir (conectividad,
transferencia, seguridad, etc.)
Construir y probar los procesos de actualizacin de una dimensin.
Construir y probar las cargas de las restantes dimensiones.

Tablas de Hechos y automatizaciones:
Construir y probar la carga histrica de las tablas de hechos (carga masiva de datos de
nivel atmico, slo de tablas base). Esta tarea incluye la bsqueda y sustitucin de claves.
Construir y probar los procesos de cargas incrementales.
Construir y probar la generacin de agregaciones y/o de cubos MOLAP
Disear, construir y probar la automatizacin de los procesos.

En [Kim2004] se encuentra un detalle de las tcnicas y consideraciones a tener en cuenta
en la extraccin, transformacin y carga de los datos que formarn parte de las tablas de
dimensiones y de las tablas de hechos.
Especificacin de Aplicaciones para Usuarios Finales

Las aplicaciones proveen el mecanismo clave para fortalecer la relacin entre el equipo
del proyecto y la comunidad usuaria. Sirven para presentar el DW a los usuarios y para acercar a
los desarrolladores de aplicaciones las necesidades del negocio. Estas aplicaciones ayudan a
22
Existen herramientas de ETL en software libre, por ejemplo Pentaho.

Este concepto se describe ms adelante. Refiere a nuevas claves, diferentes a las de los sistemas operacionales,
otorgadas a los elementos de las dimensiones.
23
45
mostrar el valor del DW rpidamente, a facilitar el acceso de la mayora de la comunidad usuaria y,

a travs de los ejemplos, colaboran con los usuarios avanzados a construir reportes ms
complejos.
No todos los usuarios del DW necesitan el mismo nivel de anlisis. En esta etapa se
identifican los diferentes roles o perfiles de usuarios. En base al alcance de los diferentes perfiles
(gerencial, analista del negocio, vendedor, etc.) se determinan los distintos tipos de aplicaciones
necesarias. Existen usuarios con un perfil ms estratgico, menos predecibles (power users),
usuarios netamente operacionales que consumen una serie de reportes estndares (final users),
usuarios gerenciales con uso de interfaces bsicas (EIS users), entre otros. Mientras que algunos
usuarios aprovecharn al mximo las facilidades de anlisis ad hoc, otros necesitarn aplicaciones
analticas parametrizadas, ms limitadas.
En general se requiere de la creacin de aplicaciones estndar parametrizables. Estas
aplicaciones tipo plantilla para usuarios finales proveen el marco y la estructura de un reporte para
ser especializado por un conjunto de parmetros. El usuario selecciona los parmetros de una lista
o acepta los valores por defecto cuando ejecuta el modelo para crear sus propias versiones
personalizadas de ese reporte, con diferentes niveles de anlisis y filtros de la informacin (por
ejemplo visualizar por mes en lugar de por trimestre, o elegir una determinada sucursal). Las
variantes de los reportes las resuelven los propios usuarios sin la necesidad de la intervencin del
departamento sistemas y maximizando el tiempo de anlisis por sobre el tiempo de construccin e
integracin de la informacin. Este enfoque orientado a parmetros permite a los usuarios generar
docenas o potencialmente cientos de reportes de estructura similar. Todo esto de forma amigable
y con interfaces grficas.
Es recomendable comenzar con la especificacin de las aplicaciones tan pronto como se
finalice el relevamiento de requerimientos, cuando se tienen bien presentes las necesidades de los
usuarios, y documentar explcitamente . Algunas consideraciones para llevar adelante esta tarea
[Kim1998]:
-
Determinacin del conjunto de patrones iniciales (identificar reportes candidatos,

clasificarlos y priorizarlos)
Diseo de la estrategia de navegacin dentro de la aplicacin (esquema de pantallas,

esquema de carpetas o directorios, criterios de agrupamiento -por datos, por dueo, por
regla del negocio-, etc.)
Determinacin de estndares (nombre y ubicacin de los objetos, formato de las salidas)
Detalle de las especificaciones (definicin del nombre, descripcin o propsito, frecuencia,

parmetros, restricciones, diseo, etc.)
46
Desarrollo de Aplicaciones para Usuarios Finales

Esta etapa sigue a la especificacin de las aplicaciones para usuarios finales El proceso
de desarrollo es bastante estndar excepto que se basa en la herramienta de acceso a datos que
se haya elegido. A lo largo del desarrollo es importante focalizar en los estndares de las
aplicaciones (convenciones de nombre, clculos, libreras y codificacin).
Esta etapa debiera comenzar una vez que existen datos en el DW (aunque no sean ms
que datos de prueba), es decir pronto a finalizados el diseo lgico y el fsico. El motivo es que al
desarrollar las aplicaciones pueden descubrirse problemas en la calidad de datos que no haban
surgido en la primera etapa del ETL y que obliguen a realizar modificaciones. Tambin es el
momento de revisar las estrategias de optimizacin de performance probando los tiempos de
respuestas de las consultas. En [Kim98] se establecen las siguientes tareas como parte del
proceso de desarrollo de las aplicaciones:
-
Seleccin de un enfoque de implementacin. Decidir si la interfaz ser web, o el acceso

ser basado en herramientas de acceso directo, en interfaces ejecutivas, en interfaces
personalizadas, etc.
Desarrollo de la aplicacin. Definicin de la herramienta de acceso a la meta data,

desarrollo de moldes y esquema de navegacin de la aplicacin, seleccin de reportes
que sern pre-ejecutados, etc.
Prueba y verificacin de datos. Testeo y verificacin de descripciones, informacin

duplicada, relaciones entre atributos, consistencia e integridad de datos con sistemas
fuentes.
Documentacin y salida a produccin. Retroalimentacin con los resultados de la puesta

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

requisito para el xito del proyecto. Para cumplir exitosamente con esta tarea se recomienda que
el alcance de la capacitacin contemple tres aspectos claves: el contenido del DW (los datos), las
aplicaciones y las herramientas de acceso. No debe realizarse slo sobre las herramientas de
acceso. La educacin sobre las herramientas es intil al menos que se complemente con
conocimientos sobre el contenido del DW (cules datos estn disponibles, qu significan, cmo se
usan y para qu usarlos). Tambin es importante la metodologa de presentacin. Para los
usuarios finales no es fcil entender los lmites entre las aplicaciones, los contenidos y las
herramientas. Para ellos el DW es un todo, por lo tanto la educacin tambin debe reflejar la
misma perspectiva. Otro factor clave es la correcta capacitacin por niveles segn el perfil del
usuario (usuario final, power user, etc.).
El armado de un ambiente de capacitacin es siempre recomendable. Dos buenas
premisas para el xito del proyecto en esta etapa final del ciclo de vida: capacitar a los usuarios
finales slo si el DW est listo y establecer la poltica de que si el usuario no recibi capacitacin
no puede acceder a l.
El soporte tcnico es la otra columna que ayudar a implementar con xito el proyecto. Se
deber definir claramente los niveles de soporte (a nivel aplicacin, modelo, calidad de datos) de
forma transparente para el usuario. La documentacin juega un papel importantsimo en la ayuda
a usuarios finales..
Respecto a la metodologa de implementacin es bueno seguir un esquema de
versionado. Primero se pasa por la versin Alpha, donde el grupo de trabajo conduce por primera
vez una prueba completa del sistema. Todos los componentes del sistema deben ser testeados
(infraestructura
tcnica,
extraccin,
transformacin,
carga,
procedimientos
de
calidad,
performance, moldes, etc.). Tpicamente es de naturaleza iterativa y slo puede decirse que se
termina esta versin cuando el grupo de trabajo confa plenamente en la calidad del DW como un
todo. Durante la etapa Alpha solo se provee acceso a un conjunto limitado de usuarios finales,
aquellos que pertenecen al grupo de trabajo.
Luego viene la versin Beta. El objetivo de esta versin es conducir una prueba a nivel
usuario de principio a fin. El grupo Beta est formado por los power users24. La cantidad de
personas que accedern al DW en esta instancia debe ser suficiente para asegurar que la
aplicacin se probar adecuadamente.
Una vez superadas estas dos versiones se llega a un estado de disponibilidad general.
Toda modificacin posterior debiera pasar internamente por un estado Alpha y Beta aunque
externamente sea una nueva versin.
Finalmente, la tecnologa que reside en el escritorio del usuario es la ltima pieza que
debe ser ubicada antes de la salida a produccin. Para asegurar que la infraestructura
24
Los power users son los usuarios que explotarn al mximo las capacidades del DW, haciendo uso de anlisis ad hoc.
48
correspondiente al ambiente del usuario est correcta y el producto entregado sea de calidad
debieran realizarse una serie de tareas antes de la implementacin. Estas tareas incluyen:
configuracin del hardware, conexin a las bases, acceso a intranet o internet, asignacin de
direcciones de red, auditorias de tecnologa sobre las configuraciones de las computadoras de los
puestos de trabajo, previsin de actualizaciones de hardware y software (determinacin de
responsables, proyecto o rea de usuario), verificaciones de seguridad (para acceder a la red y a
la base de datos), pruebas de procedimientos de instalacin en una variedad de mquinas,
planificacin de instalacin, etc.
Mantenimiento y crecimiento
El desarrollo de un DW es un proceso de etapas bien definidas, con comienzo y fin, pero
de naturaleza espiral, pues acompaa a la evolucin de la organizacin durante toda su historia.
Se necesita continuar con los relevamientos de forma constante para poder seguir la evolucin de
las metas por conseguir. Al contrario de los sistemas tradicionales, los cambios en el desarrollo
deben ser vistos como signos de xito y no de falla, porque a medida que los usuarios del negocio
utilizan el DW van requiriendo nuevos anlisis.
Una vez que se ha construido e implementado el DW, rpidamente se debe estar
preparado para administrar el mantenimiento y crecimiento del mismo. Si bien las tareas pueden
llegar a parecer similares a las tratadas en otras etapas del BDL, existe una diferencia clave: los
usuarios estn ahora accediendo al DW. Algunas consideraciones a tener en cuenta para
mantener exitosamente al DW: el continuo soporte y la constante capacitacin a usuarios del
negocio, el manejo de la infraestructura (monitoreo de base de datos, trfico, etc.), ajustes de
performance de las consultas, mantenimiento del meta data y procesos ETLs. Otros aspectos
involucran el monitoreo regular del cumplimiento de las expectativas (variables de medicin del
xito del proyecto que se haban fijado en la etapa de relevamiento), relevamiento de casos de
estudio (situaciones reales donde una decisin basada en informacin del DW tuvo impacto sobre
el negocio), constante publicidad interna del uso (permitiendo acceso siempre y cuando se tenga
la capacitacin correspondiente) y constante comunicacin con los sectores del negocio y de
sistemas para asegurar la buena salud del DW [Mst2005].
En cuanto al crecimiento del DW, un buen diseo est preparado para evolucionar y
crecer controladamente. Iterar sobre el BDL pasando nuevamente por cada una de las etapas
para administrar correctamente los cambios a incorporar. Es importante establecer las prioridades
para poder manejar los nuevos requerimientos de los usuarios. Es recomendable la creacin de un
comit conformado por analistas del negocio y personas del rea de sistemas que establezca
prioridades y procedimientos. El manejo de prioridades discrimina errores (los cuales deben ser
resueltos inmediatamente), y mejoras menores o mayores (clasificadas segn el impacto en el
DW). Como mejoras menores incluye la incorporacin de datos sencillos, nuevas agregaciones,
cambios en niveles superiores del modelo (atributos de alto nivel, lejanos a las tablas base).
49
Dentro de las mejoras de mayor impacto se encuentran las que modifican o crean tablas bases o
atributos asociados a estas [Mst2005].
Gerenciamiento del Proyecto

El gerenciamiento del proyecto es trasversal a todo el ciclo de vida y asegura que las
actividades del BDL se lleven en tiempo y forma y de manera sincronizada. Como se indica en el
diagrama, el gerenciamiento acompaa todo el ciclo de vida. Entre sus actividades principales se
encuentran: la conduccin del equipo de trabajo, el monitoreo del estado del proyecto, el
mantenimiento del plan y documentacin, el manejo del alcance, y la comunicacin entre los
requerimientos del negocio y las restricciones de los datos para poder manejar correctamente las
expectativas.
3.3
Tcnicas para el modelado dimensional.

En [Kim1992] [Kim2002] se presentan temticas de anlisis tpicas mediante las cuales se
ejemplifican cuestiones de diseo, algunas comunes y sencillas, otras ms especficas y

complejas. No es intencin de esta tesis abordar estas cuestiones detalladamente, sino presentar
las lneas generales ms importantes. Varias de las tcnicas se ejemplifican luego durante el
desarrollo del caso de estudio, donde tambin se resaltan las particularidades de la temtica
elegida.
Tal como se mencion previamente, el diseo de un esquema multidimensional consiste
bsicamente de cuatro pasos:
-
Seleccionar el proceso del negocio o asunto a modelar o Data Mart.

Un proceso es una actividad realizada en la organizacin y generalmente soportada por un
sistema fuente. Los procesos del negocio deben modelarse una nica vez. No se deben
duplicar datos modelando una misma actividad segn la perspectiva de anlisis de los
diferentes departamentos de una organizacin.
Al presentar esta etapa de modelado dimensional dentro del BDL, se dijo que el diseo de
un DW comienza con la construccin de una matriz (DW Bus Architecture Matrix) donde
se establecen las relaciones entre indicadores (pertenecientes a algn Data Mart) y
dimensiones. Este primer paso consiste en elegir qu rengln o renglones de esa matriz
van a modelarse.
Dentro de la matriz, los diferentes Data Marts pueden solaparse. La cantidad de Data
Marts para una organizacin grande vara entre 10 y 30. Menos de 10 podra significar que
qued muy amplia la definicin de cada uno de ellos. Ms de 30 o 40 es difcil de
mantener, por eso es recomendable juntar los que puedan unirse.
50
Manifestar la granularidad del proceso del negocio.

Declarar la granularidad significa especificar exactamente qu representa cada fila de una
tabla de hechos, manifestando el nivel de detalle asociado con las medidas que contiene.
Este paso es crtico. Declarar la granularidad inapropiadamente puede atormentar la
implementacin de un DW y limitar el nivel de anlisis. Cargar las tablas de hechos con
datos atmicos (el mayor nivel de granularidad posible) brinda la mayor flexibilidad porque
permite sumarizar los datos de todas las maneras posibles. En cambio, si la tabla de
hechos contiene informacin agregada algunas sumarizaciones pueden no ser vlidas (por
ejemplo datos promediados).
Elegir las dimensiones que aplican a cada registro de la tabla de hechos.

Las dimensiones surgen de la forma en que se describe el proceso del negocio. Estas
sern fcilmente identificadas si la granularidad est clara. Al elegir cada dimensin se
listan todos los atributos que proveern el detalle de cada tabla de dimensin.
Ejemplos de uso comn son fecha, producto, cliente, tipo de transaccin, etc.
Identificar las medidas para cada tabla de hechos.

Las medidas se determinan a partir de las mtricas de rendimiento del proceso del
negocio seleccionado. Todas las medidas de una tabla de hechos deben tener la misma
granularidad. Si la granularidad de alguna es diferente (porque no est definida para
alguna dimensin, o lo est pero a otro nivel de detalle) esa mtrica debe ser modelada en
una tabla de hechos separada. Las medidas tpicas son numricas y aditivas, como
cantidades o importes.
El entendimiento del negocio ser necesario para definir las dimensiones y medidas del
modelo dimensional. Claramente deben considerarse tanto los requerimientos de los usuarios
como la realidad de los datos fuentes al tomar decisiones sobre los cuatro pasos descriptos.
Como cualquier tcnica de modelado de datos, el desarrollo del modelo dimensional es un
proceso iterativo. Se deber estar dispuesto a cambiar el modelo a medida que se aprende ms
(de los requerimientos y de los datos). A medida que se avanza en el diseo, pueden identificarse
dimensiones nuevas, o descubrir que dos de ellas son slo una. Tambin es comn realizar
cambios en la granularidad.
Eleccin del Data Mart

La metodologa BDL propone comenzar por la construccin de un Data Mart.. La eleccin
del Data Mart a modelar en el ms simple de los casos es elegir la fuente de donde se tomarn los
datos. Es recomendable elegir al principio uno que tenga una nica fuente de datos en lugar de
mltiples para evitar los riesgos de afrontar tareas de extraccin ms complejas.
Se recomienda implementar los Data Marts en forma separada slo en el contexto de
dimensiones y hechos acordados (conforme al DW Bus). A medida que se obtienen los diferentes
Data Marts estos deben poder ser ensamblados perfectamente como parte de un todo. Una de las
51
responsabilidades mayores del equipo de diseo central del DW es establecer, publicar, mantener
e imponer las dimensiones acordadas.
Las dimensiones acordadas naturalmente sern definidas en el mayor nivel de
granularidad posible. Tambin se recomienda que tengan una clave annima (subrogada) en el
DW, diferente a las claves de los sistemas operacionales. Una de las razones de tener una nueva
clave es para poder manejar los cambios que podran sufrir los valores de los atributos de las
dimensiones. La creacin de las dimensiones acordadas es ms una decisin poltica que tcnica,
por lo tanto los ejecutivos de alto nivel deben alimentar su uso.
Las definiciones de los hechos (medidas) deben ser acordadas cuando se usa la misma
terminologa a travs de los Data Marts y cuando se construyen reportes con informacin
proveniente de ms de uno de ellos. Si dos medidas reciben el mismo nombre deben significar lo
mismo. En el caso de las medidas calculadas la ecuacin de clculo debe ser equivalente. Las
medidas acordadas necesitan estar definidas en el mismo contexto dimensional y con la misma
unidad de medicin para todos los Data Marts. A veces la unidad de medicin de una mtrica
difiere naturalmente entre las diferentes tablas de hechos. Por ejemplo el flujo de productos en un
negocio puede medirse en cantidad de unidades vendidas en el sector de ventas, y en cantidad de
pedidos enviados en el sector de envos. En algunos casos se utiliza un factor de conversin, pero
en este ejemplo no sera apropiado, y es conveniente modelarlas como medidas diferentes. Si es
difcil o imposible acordar una medida entonces hay que asegurarse de darle nombres diferentes a
cada interpretacin.
Luego de haber implementado varios Data Marts de una sola fuente es razonable
combinarlos en uno de mltiples fuentes. El ejemplo clsico es el Data Mart para anlisis de
rentabilidad que combina los componentes separados de ingresos y costos.
Tablas de Hechos y Granularidad

Declarar la granularidad es un paso crucial en el diseo. Se recomienda elegir el nivel ms
bajo de granularidad posible para lograr un diseo ms robusto. Esto significa construir las tablas
de hechos bsicas al nivel naturalmente ms bajo de todas las dimensiones que las constituyen.
Un nivel muy bajo de granularidad es poderoso y flexible, es mucho mejor para responder nuevas
consultas inesperadas y para introducir elementos de datos nuevos. Tambin el nivel ms bajo de
granularidad es el que tiene el dato de la forma dimensional ms natural (por ejemplo del ticket de
un cajero automtico pueden identificarse las dimensiones tiempo, localidad, cuenta y tipo de
transaccin). Es en el nivel ms bajo donde la mayora de los atributos de las dimensiones tienen
un nico valor por registro. Por otro lado, trabajar con el nivel de datos ms desagregado en el DW
servir para hacer anlisis de data mining y de comportamientos de clientes.
Los tres tipos de granularidad de tablas de hechos ms tiles son: transacciones
individuales,
fotografas
(snapshots)
peridicas
(diarias,
mensuales,
etc.)
fotografas
52
acumulativas (accumulating snapshop). Cada uno de estos tipos de tablas tiene caractersticas
particulares que se desarrollan a continuacin.
Granularidad a nivel de transaccin
La visin operacional del negocio ms importante es a nivel de transacciones individuales.
El caso ms sencillo de este esquema consiste en crear un registro en la tabla de hechos por cada
transaccin individual (por ejemplo por cada operacin de un cajero automtico). Frecuentemente
cada registro contiene una nica medida, que es el valor de la transaccin. En muchos casos se la
llama importe (monto, o cantidad).
El diseo de un esquema de transacciones es ms acotado en cuanto al crecimiento que
el de un esquema de fotografas. Se representan eventos que ocurren en un determinado
momento de tiempo, y una vez ocurrida la transaccin se incorpora al DW y no se vuelve a visitar
a ese registro (no se lo modifica). Casi nunca se agregan medidas numricas porque el sistema de
captura de transacciones usualmente slo retorna un importe. Se pueden agregar nuevos tipos de
transacciones a la dimensin pero esto significa agregar datos no cambiar el esquema de la tabla.
El nivel de granularidad no necesariamente es el nivel de la transaccin en s, en algunos
casos se puede llegar a nivel de lnea de tem. Por ejemplo, para representar ventas mucha
informacin est en el encabezado de la factura (fecha, cliente, sucursal, etc.) que sera la
transaccin, pero hay un nivel ms detallado, el de lnea de factura, que contiene el dato del tem.
Para cada tem existen las medidas cantidad de unidades e importe.
Al tener granularidad transaccional en el DW se permite analizar comportamientos al nivel
de detalle extremo. Esto no es posible si lo datos estn agregados. Este nivel de informacin
permite realizar conteos de comportamiento (como por ejemplo cantidad de transacciones por
cliente), anlisis de rangos horarios, encolamientos, tiempos entre transacciones, etc. El detalle de
las transacciones permite ver el comportamiento secuencial que se aplica para deteccin de
fraudes y advertencia de cancelaciones. Finalmente permite realizar anlisis de canasta que
consiste en identificar asociaciones de elementos, por ejemplo productos que se venden junto con
uno determinado. Muchos de estos ejemplos son anlisis tpicos de data mining, que requieren
tener los datos en su mximo nivel de detalle.
La granularidad de nivel de transaccin sin embargo no es la ms apropiada para otro tipo
de anlisis, como tener una vista del estado actual del negocio. Por ejemplo si se quiere saber los
ingresos no siempre es posible hacerlo sumando las transacciones, porque diferentes tipos de
transacciones impactan de formas distintas en este clculo.
Esquema de fotografas
Fotografas peridicas son necesarias para ver el rendimiento acumulado del negocio a
intervalos de tiempo regulares y predecibles. En lugar de cargar una fila en la tabla de hechos por
cada evento que ocurre, se espera hasta el final del da, o del mes, y se captura la actividad que
53
ocurri durante ese perodo. Se dice que se toma una foto de lo ocurrido. Las fotografas tomadas
en cada perodo se van guardando en la tabla de hechos.
Este esquema de fotografas es ms complejo que la perspectiva de transacciones
individuales. Pueden existir varias medidas de la actividad ocurrida durante el perodo capturado,
por ejemplo importe total de ventas, cantidad total de transacciones, cantidad de clientes que
realizaron alguna compra en el perodo, etc. Es importante que todas las medidas se refieran al
perodo corriente. Algunas medidas sern completamente aditivas y otras sern semi-aditivas,
como el balance de cuentas al momento que se toma la fotografa. Estos casos podrn ser
promediados a travs del tiempo o tener algn otro mtodo especial de agregacin.
En algunos casos, como el de ventas por menor, es sencillo pasar de la perspectiva de
transacciones individuales a la foto diaria agrupando las transacciones a nivel de da.. Otras veces
el patrn de transacciones es muy complejo y la construccin de fotografas no es una simple
agregacin. Por ejemplo en una contabilidad mensual el clculo de las ganancias depende de
cmo contabiliza cada tipo de transaccin (depsitos, pagos por adelantado, etc.). Las fotos
mensuales son requeridas en estos casos para obtener la informacin a ese nivel en forma rpida.
La granularidad a nivel de transacciones posibilita la vista total del comportamiento
detallado y a nivel de fotografas permite medir rpidamente el estado de la empresa u
organizacin. En muchos casos se necesitan ambas para lograr una vista completa e inmediata
del negocio.
Fotografas acumulativas
Las fotografas acumulativas (o acumuladas) representan un lapso de tiempo
indeterminado para cubrir la vida entera de una transaccin o de un producto completo. Este
esquema es generalmente usado para seguimiento del estado de un tem cuando atraviesa un
proceso en cadena, por ejemplo seguimiento de una orden de pedido. Este diseo sirve para
saber el estado actual de una orden y la velocidad en que un producto va superando las diferentes
etapas del proceso y permite identificar cuellos de botella e ineficiencias en la cadena del proceso
(de produccin, de ventas y entregas, etc.).
La granularidad de estas tablas de hechos suele ser de un registro por cada lnea de tem
de un documento de control. Cada registro puede ser pensado como fotografas evolutivas de esa
lnea de tem que se van actualizando. Estas tablas de hechos tienen tpicamente mltiples fechas
representando hitos en las fases por las que atraviesa la lnea de tem (por ejemplo fecha de la
orden de pedido, fecha de entrada a fabricacin, fecha de fin de fabricacin, fecha de envo a
sucursal, fecha de facturacin, fecha de recepcin del cliente, entre otras). Tambin pueden existir
diferentes medidas asociadas a cada etapa.
Generalmente se necesita una dimensin de estado para guardar el valor actual de cada
tem. En estas tablas cada registro se actualizar frecuentemente cuando se tenga nueva
54
informacin disponible, para reflejar el estado y las mtricas acumuladas. Esta es la diferencia
fundamental con los otros tipos de tablas.
A veces las fotos acumulativas se usan en conjunto con las fotos peridicas. Se puede
pensar en un DW que guarde fotos peridicas por mes y que lleve una fotografa acumulativa para
la informacin del mes en curso. En estos casos cuando finaliza el ltimo da del mes la fotografa
acumulada pasa a ser una ms de las fotos peridicas y se crea una nueva foto acumulativa para
registrar la actividad del nuevo mes a partir del da siguiente. La fotografa mensual se construye
de forma incremental, agregando el efecto de las transacciones diarias a una fotografa
acumulativa.
Comparacin de los esquemas
En la siguiente figura se presenta un cuadro comparativo [Kim2002] respecto a estos tres
tipos de granularidad donde destaca las caractersticas ms distintivas.
Caracterstica
Granularidad
transaccional
Punto en el tiempo
Granularidad de
fotografas peridicas
Intervalos regulares y
predecibles
Granularidad
Una fila por evento

transaccional
Una fila por perodo
Tipo de cargas en tablas

de hechos
Actualizaciones en tablas
de hechos
Dimensin fecha
Inserciones
Inserciones
No
No
Fecha de la transaccin
Fecha del fin del perodo
Mtricas
Actividad transaccional
Rendimiento para
intervalos de tiempo
predefinidos
Perodo de tiempo
representado
Granularidad de
fotografas acumulativas.
Lapso de tiempo
indeterminado, tpicamente
de corta vida
Una fila por vida
(al nivel de detalle que se
haga el seguimiento)
Inserciones y
actualizaciones
Se actualiza el registro
cuando hay actividad.
Mltiples fechas para hitos
estndares
Rendimiento sobre el
tiempo de vida finito
Figura 10. Comparacin de tipos de tablas de hechos.
Los tres tipos de granularidades vistos son tiles para diferentes propsitos. La
administracin y ritmos de carga difieren bastante entre los tres tipos de tablas. Generalmente
ser necesario tener dos tipos de tablas de hechos complementarios para lograr una imagen
completa del negocio. Estas tablas compartirn dimensiones acordadas, para poder ser usadas en
conjunto.
Familias de tablas de hechos
Para modelar muchos de los procesos del negocio es necesario considerar ms de una
tabla de hechos. Un Data Mart puede constituirse como un conjunto coordinado de tablas de
hechos, todas con estructuras similares, no necesariamente de tipos diferentes, y s con
dimensiones y medidas acordadas.
Hay diferentes razones para crear estas familias de tablas de hechos [Kim1998]:
55
Los casos ya mencionados de contar con tablas de diferente granularidad; por ejemplo
transaccional y de fotografas para poder realizar anlisis detallado y a la vez tener una
vista del negocio rpida.
La construccin de tablas con informacin agregada para resolver problemas de

performance.
Modelar cadenas y crculos.

El caso de cadenas es cuando dentro del negocio existe un flujo que involucra que una
orden, producto, o cliente atraviese diferentes pasos. En general tiene sentido construir
una tabla de hechos separada para cada uno de los procesos. Las tablas de cada paso
pueden ser transaccionales o de fotografas peridicas, y estarn relacionadas por las
dimensiones y medidas comunes. Se habla de cadenas cuando los subprocesos o etapas
estn naturalmente ordenados.
El caso de los crculos es cuando varias entidades estn realizando o midiendo el mismo
tipo de transacciones. Un buen ejemplo es la gran organizacin de cuidado de la salud,
donde hospitales, farmacias, laboratorios, clnicas, compaas de seguro y otras entidades
rondan alrededor de los tratamientos de los pacientes.
Esquemas de productos heterogneos.

Este es el caso de negocios que manejan productos lo suficientemente diferentes que
dadas las caractersticas propias del tipo de producto deban ser modeladas en forma
separada, porque existan muchas dimensiones que no son comunes. Seguramente
tambin se incluya en el modelo una tabla base ncleo que cruce todas las lneas del
negocio para tener un anlisis global por las dimensiones comunes. Un ejemplo puede ser
una empresa que ofrezca productos y tambin servicios.
Tablas de hechos sin medidas
Hay un tipo especial de tablas de hechos denominada factless fact tables por tener la
caracterstica de no incluir medidas entre sus campos. Hay dos situaciones donde las tablas con
esta caracterstica son muy tiles: para seguimiento de eventos y de cobertura.
Para el primer caso en la tabla de hechos se registra un evento por lnea. Ejemplos tpicos
de uso son el registro de asistencias y las inscripciones a cursos. Si se piensa en alumnos
universitarios inscribindose a materias la granularidad de la tabla ser de una fila por cada
inscripcin de un alumno a una materia en un perodo acadmico. El perodo ser el nivel ms
bajo disponible para la registracin de eventos. Esta dimensin debe estar de acuerdo con la
dimensin de fechas.
Este tipo de tablas, compuestas slo por claves de dimensiones es perfectamente una
tabla de hechos25 y es til para responder preguntas como qu materias tienen mayor cantidad de
25
La existencia de las factless fact tables ha motivado la nomenclatura utilizada en este texto. Ntese la referencia a fact
table como tabla de hechos, considerando hecho como suceso o evento en lugar de utilizarlo como sinnimo de medida o
mtrica al hacer mencin a la tabla.
56
inscripciones, cul es la cantidad de inscripciones promedio por alumno y perodo, qu docentes

tendrn mayor cantidad de alumnos, cul es el medio de inscripcin ms utilizado, etc.
Al analizar esta informacin pueden contarse dos cosas diferentes: por un lado la cantidad
de inscripciones y por otro la cantidad de valores diferentes de una dimensin en alguna consulta.
Por ejemplo: para un perodo determinado, se puede contar el total de inscripciones por carrera
(asumiendo que cada materia pertenece slo a una carrera), como tambin la cantidad de
alumnos diferentes por carrera, sin importar en cuantas materias de la carrera se inscribe.
El segundo tipo de tablas de hechos sin medidas se utiliza para garantizar cobertura. El
mejor ejemplo es el caso de querer analizar las promociones de productos que estn a la venta.
Sera deseable saber qu productos estaban en promocin y no se vendieron. Agregar la
informacin necesaria para este anlisis en la tabla de ventas significara la incorporacin de
muchsimos registros con ceros representando los eventos que no sucedieron (todos los productos
que no se vendieron), lo que hara crecer enormemente el tamao de la tabla. Es por eso que en
estos casos, cuando la tabla de hechos primaria es rala26, suele utilizarse este esquema de
cobertura. Se crea entonces una tabla donde se registran todas las promociones. La respuesta a
los productos promocionados y no vendidos se resuelve en dos pasos, primero se consulta cuales
estaban promocionados, y con ese resultado se busca en la tabla de ventas cuales no estn
durante la vigencia de la promocin.
Otro ejemplo de cobertura puede ser el anlisis de uso y disponibilidad de las
instalaciones de una institucin. Para cada instalacin se podra considerar datos como el edificio,
el tipo de instalacin (aula, laboratorio, oficina), la capacidad, los servicios (pizarrn, proyector,
computadoras) y registrar para cada bloque horario si la habitacin se encuentra disponible o no.
Diseo de las dimensiones

Una vez seleccionado el Data Mart a modelar y habiendo establecido las granularidades
correspondientes, el tercer paso del diseo multidimensional consiste en elegir las dimensiones
que aplican a cada tabla de hechos.
Diferentes caractersticas de las dimensiones debern tenerse en cuenta al momento de
disear el modelo del negocio.
Descripcin de los atributos
Es vital que las descripciones de los atributos de las dimensiones sean de alta calidad:
significativas, entendibles y prolijas. Estas sern mostradas en la interfaz con el usuario y usadas
como filtros en las consultas.
26
Rala significa poco densa considerando las combinaciones de los valores de las dimensiones que contiene respecto a
todas las posibles.
57
Claves de las dimensiones

Otra caracterstica de diseo importante es que todas las dimensiones deben tener una
clave. Las claves de las dimensiones deben ser un slo campo, numrico y secuencial, y son el
nexo entre las tablas de hechos y las dimensiones.
Se destaca que no deben usarse las mismas claves que en los sistemas operacionales,
sino que es necesario generar claves nuevas o sustitutas.
Esquema estrella vs esquema copo de nieve
Uno de los puntos ms importantes a definir al modelar las dimensiones est relacionado
en gran parte con la implementacin fsica. Se trata de la normalizacin o no de las tablas de
dimensin.
Algunas dimensiones constan de un nico atributo, pero otras constan de varios atributos
que forman una jerarqua. Tal es el caso de la dimensin producto, donde se puede identificar la
jerarqua: producto, lnea, categora y rubro, por ejemplo, y de la dimensin ubicacin geogrfica
donde se identifican localidades, provincias y pases, entre otros atributos.
En estos casos la dimensin se puede representar en una nica tabla, donde reside toda
la informacin al nivel ms bajo, o mediante un conjunto de tablas (a partir de las dependencias
existentes entre los atributos) que respeten la tercera forma normal27. El primero de los casos
corresponde a un esquema estrella (que consta de una tabla de hechos central y un montn de
tablas de dimensiones satlites). Al normalizar las dimensiones se dice que se transforma al
modelo estrella en un copo de nieve (tambin debido al grfico de su estructura), y por eso a
veces se hace referencia a esta accin como snowflaking.
En la figura 11 se observa como podra ser la tabla de la dimensin Ubicacin, con
localidad_id como nica clave modelada en ambas formas.
Localidad_id
Localidad_desc
Provincia_id
Provincia_desc
Pais_id
Pais_desc
Pais_id
Pais_desc
Provincia_id
Provincia_desc
Pais_id
Localidad_id
Localidad_desc
Provincia_id
Figura 11. Dimensin Ubicacin desnormalizada vs normalizada.
27
La tercera forma normal es una forma de normalizacin de bases de datos, definida por E.F.Codd.
58
Es claro que la tabla desnormalizada contiene mucha redundancia de datos. Tambin es

claro que en el esquema normalizado se necesitar realizar varias uniones entre tablas para
obtener la informacin del DW agrupada a niveles altos de la jerarqua.
Entre un esquema y otro existe una solucin intermedia, denominada moderadamente
normalizada que es igual al normalizado a excepcin que en todas las tablas se incluyen las
claves de todos los niveles superiores. De esta manera la cantidad de joins se reduce, siendo a los
sumo dos, para cualquier nivel de la jerarqua consultado.
El esquema totalmente desnormalizado presenta algunas variantes. Puede contener:
-
Una clave y una descripcin genricas para toda la dimensin, y las claves de los
diferentes niveles. Esta opcin es rara. Podra usarse para algn caso donde la
descripcin sea la misma, cualquiera sea el nivel de anlisis que se consulte, o si el dato a
mostrar se calcula a partir de esa descripcin comn.
Una clave genrica para toda la dimensin y las descripciones de los diferentes niveles.
Es vlido si no existen tablas de hechos con nivel de granularidad diferente al nivel base
de la dimensin.
Una clave genrica para toda la dimensin y las claves y descripciones de los diferentes
niveles. Este es el caso ms comn y el mostrado en la figura, slo que para el ejemplo se
toma como clave de la dimensin a la clave del nivel ms bajo.
Con este esquema totalmente desnormalizado hay que utilizar algn mtodo de
indexacin eficiente para obtener el listado de valores de los diferentes niveles de la jerarqua,
particularmente para resolver rpidamente los cruces con las tablas de hechos donde el nivel de
granularidad no sea el base. Caso contrario sera necesario crear tablas adicionales para los
distintos niveles y esto generar an ms redundancia de datos, como se puede observar en la
figura 12.
La discusin entre ambos esquemas surge de considerar el tamao total de la base de
datos (y el consecuente espacio necesario en disco, demoras para backups y otros procesos) y de
las limitaciones tradicionales de las bases de datos para resolver las operaciones requeridas en un
rea de soporte de decisiones. Estas operaciones consisten en unir informacin de diferentes
tablas, agregar o agrupar datos, ordenar datos y recorrer grandes volmenes de datos.
El desarrollo tecnolgico a travs de los aos ha quitado presin al problema del tamao
del DW. Con respecto a las operaciones costosas en la base de datos pueden usarse tcnicas
para abordarlas: usar un modelo desnormalizado, usar tablas resumidas (evita tener que calcular
agregaciones sobre tablas bases), guardar los datos ordenados (para evitar ordenamiento) y crear
ndices (para evitar recorrer tablas grandes). Todas estas opciones requieren que el diseador
conozca las consultas que sern realizadas frecuentemente para personalizar la base de datos
focalizando en la performance de esos casos.
59
Algunos argumentos a favor de la desnormalizacin, con una nica tabla por dimensin y
el uso de ndices:
-
Las tablas normalizadas hacen ms compleja la presentacin de los datos; y el modelo

dimensional debe ser simple. Cuantas menos tablas haya ms fcil ser de entender.
Muchas tablas y cruces normalmente perjudican los tiempos de respuestas y dificultan la

generacin (en SQL) de las consultas.
El espacio en disco que se ahorra es mnimo respecto al tamao de las tablas de hechos y
no justifican el esfuerzo.
La normalizacin perjudica la habilidad de navegar los datos dentro de una dimensin,

particularmente cuando se consultan al mismo tiempo varios atributos.
La normalizacin rechaza el uso de ndices que es una tcnica para lograr buena
performance.
Por el contrario, a favor de un DW normalizado y esquemas estrellas para Data Marts se
exponen las siguientes razones:

-
La cantidad de espacio es mnimo. En el modelo desnormalizado las tablas de dimensin

son muy grandes.
Es flexible y escalable en cuanto a cantidad de atributos dentro de cada dimensin, y

cantidad de elementos (valores) dentro de cada atributo.
Maneja naturalmente en forma ptima listas desplegables y tablas de hechos con diferente
granularidad.
El mantenimiento de las tablas de dimensin es ms sencillo al no haber redundancia de

datos. Soporta mejor los posibles cambios en los valores de los atributos de las
dimensiones. Si una descripcin cambia debe ser modificada slo en un lugar en vez de
en todos los registros de una tabla de dimensin desnormalizada.
Es interesante observar como las diferencias entre las estructuras se hacen ms visibles
cuando la dimensin tiene muchos niveles, y tambin cuando hay tablas de hechos con diferentes
granularidades (que podran existir o no, y podran corresponder a agregaciones28 o a otros
hechos). A partir el ejemplo de la figura 11 se podran obtener las variantes mostradas en las
figuras 12, 13 y 14.
28
Consultar sobre la tcnica de agregacin al final de este captulo. Las agregaciones tienen sentido cuando existen
dimensiones con jerarqua. La razn principal de su creacin es reducir la cantidad de registros de una tabla de hechos que
son consultados y agrupados para armar una respuesta cuando se pregunta por niveles superiores al nivel base. Se crean
tablas adicionales con datos ya resumidos para las consultan frecuentes.
60
Dim Ubicacin base

Localidad_id
Localidad_desc
Depto_id
Depto_desc
Provincia_id
Provincia_desc
Pais_id
Pais_desc
Region_id
Region_desc
Tabla de hechos base
(Dim Ubicacin agreg 1)
Localidad_id
Provincia_id
Provincia_desc
Pais_id
Pais_desc
Region_id
Region_desc
Tabla de hechos nivel pcia

Pcia_id
(Dim Ubicacin agreg 2)

Pais_id
Pais_desc
Region_id
Region_desc
Tabla de hechos nivel pais

Pais_id
Figura 12. Esquema altamente desnormalizado para la dimensin Ubicacin.
Region_id
Region_desc

Pais_id
Pais_id
Pais_desc
Region_id
Provincia_id
Provincia_desc
Pais_id
Pcia_id
Depto_id
Depto_desc
Pcia_id

Localidad_id
Localidad_id
Localidad_desc
Depto_id
Figura 13. Esquema altamente normalizado para la dimensin Ubicacin.
Region_id
Region_desc
Pais_id
Pais_desc
Region_id

base
Pais_id
Provincia_id
Provincia_desc
Pais_id
Region_id
Depto_id
Depto_desc
Pcia_id
Pais_id
Region_id

Pcia_id

Localidad_id
Localidad_id
Localidad_desc
Depto_id
Provincia_id
Pais_id
Region_id
Figura 14. Esquema moderadamente normalizado para la dimensin Ubicacin.
61
En el esquema altamente desnormalizado de la figura 12 las tablas adicionales para la

dimensin (punteadas en el grfico) podran crearse pero esto producira ms redundancia an; es
preferible optar por una buena tcnica de creacin de ndices en la tabla original para obtener en
tiempos aceptables los valores distintos del atributo correspondiente al nivel que se consulte. En
este esquema todas las consultas se resuelven mediante un join con la tabla de dimensin,
realizando el agrupamiento de registros correspondiente al nivel de la jerarqua que se elija.
En la figura 13 se puede observar como el esquema altamente normalizado soporta
naturalmente las diferentes granularidades de las tablas de hechos. Por otro lado, de no existir
tablas de agregacin, resolver una consulta sobre la tabla base requiere muchos joins, a nivel de
pas por ejemplo seran cuatro.
Respecto al esquema de la figura 14, las consultas a cualquier nivel de la dimensin se
resuelven haciendo a lo sumo dos joins, existan o no tablas de agregacin.
La eleccin del esquema adecuado depender del caso, de algunos motivos ajenos como:
el alcance total del proyecto, los recursos disponibles, las facilidades del motor de base de datos
elegido; y de cuestiones propias del modelo como: la cantidad de niveles de las dimensiones, los
niveles que sean consultados frecuentemente, y particularmente de la cantidad de registros que
contengan la dimensiones. Por ejemplo: no es lo mismo si la tabla contiene la informacin de
todas las localidades del mundo que si contiene informacin de 100 localidades correspondientes
a 20 departamentos, de 2 provincias y del mismo pas. En este caso los dos niveles superiores de
la dimensin no se consultarn (probablemente ni siquiera se incluyan en el modelo) y las
diferencias en los tiempos de respuesta no se notarn, cualquiera sean el esquema y la
agregacin que se utilicen. S es probable que se note la diferencia en la complejidad de la
elaboracin de consultas.
Por ltimo existe una opcin totalmente extremista, en la que podra caerse por error al
realizar los primeros diseos, que sera desnormalizar a nivel de la tabla de hechos, ingresando
como campos de esta tabla a los atributos de la dimensin. Este caso sera un error de diseo
porque se pierde el concepto de dimensin en s. Adems habra mucha redundancia de datos,
ocupara mucho espacio y exigira alto grado de mantenimiento.
En las figuras 15 y 16 se muestran dos posibilidades de cmo podra quedar el diseo en
caso de implementar esta decisin.
En la propuesta de la figura 15 se tratan los diferentes niveles de una dimensin como si
fuesen dimensiones diferentes. Todas las consultas se resuelven con un solo join, pero se pierde
la posibilidad de drill down que es la base de OLAP. Lo ms destacable es la diferencia
conceptual, debido a que se generan dimensiones separadas para representar una misma
entidad. Esto dificulta el anlisis.
62

Region_id
Region_desc
Pais_id
Region_id
Pais_id
Pais_desc

Pcia_id
Pais_id
Region_id
Provincia_id
Provincia_desc

Depto_id
Depto_desc
Localidad_id
Depto_id
Pcia_id
Pais_id
Region_id
Localidad_id
Localidad_desc
Figura 15. Desnormalizacin de la dimensin Ubicacin dentro de las tablas de hechos,

considerando los niveles de la dimensin como dimensiones independientes.
La variante de la figura 16 mantiene el concepto de dimensin y permite modelar a todos

los atributos como parte de una jerarqua y hacer drill down. A la vez resolvera todas las consultas
con un nico join. Pero esta redundancia extrema deforma el modelo y dificulta la elaboracin de
las consultas. Si el volumen de informacin fuese grande ocupara espacios enormes y con
volumen chico no se necesita porque la supuesta mejora en la performance no sera evidente.
Esta opcin complica el entendimiento y mantenimiento del modelo y de los datos.
Region_id
Region_desc
Localidad_id
Depto_id
Pcia_id
Pais_id
Region_id
Pais_id
Pais_desc
Region_id
Provincia_id
Provincia_desc
Pais_id

Pcia_id
Pais_id
Region_id
Depto_id
Depto_desc
Pcia_id

Localidad_id
Localidad_desc
Depto_id
Pais_id
Region_id
Figura 16. Desnormalizacin de la dimensin Ubicacin dentro de las tablas de hechos,

manteniendo la jerarqua de la dimensin.
En general cada dimensin debe estar relacionada por una nica clave a cada tabla de
hechos, en el nivel de granularidad que corresponda.
63
Subdimensiones y jerarquas mltiples dentro de una dimensin

Hay casos que requieren especial atencin respecto a la decisin a tomar sobre
normalizacin. Se trata de las dimensiones que presentan subdimensiones y/o tienen mltiples
jerarquas.
Se dice que existe una subdimensin cuando dentro de una dimensin se puede identificar
una entidad independiente que se relaciona con la principal. Por ejemplo, la ubicacin del cliente.
Si el cliente est asociado a una localidad, la ubicacin geogrfica del cliente puede verse como
una subdimensin dependiente. No tendra sentido incluir todos los datos de la dimensin
ubicacin por cada registro que exista en la tabla de cliente. Cualquiera sea el esquema elegido
para modelar la dimensin ubicacin, dentro de la tabla de cliente slo deber incluirse la clave de
la ubicacin (localidad_id). Tener otros datos de ubicacin a nivel de cliente ocupara muchsimo
espacio y dificultara el mantenimiento de las localidades. Adems la independencia de la tabla
ubicacin permite su reuso en otras dimensiones (como por ejemplo la ubicacin de los
proveedores).
Las subdimensiones muchas veces suelen modelarse de manera separada, generalmente
porque hay alguna otra forma de agrupar al nivel inferior de la dimensin de la cual depende a
travs de atributos de una jerarqua principal. Por ejemplo la dimensin cliente podra consistir de
los niveles: tipo de cliente y cliente, y la subdimensin ubicacin del cliente podra modelarse en
forma separada bajo el nombre de destinos o mercados. Dependiendo de las facilidades de la
herramienta que se elija para explotar la informacin, y en particular si soporta o no modelar ms
de una jerarqua dentro de las dimensiones, las subdimensiones se podrn visualizar como una
jerarqua ms o como una dimensin separada.
Una situacin similar ocurre cuando atributos de una dimensin se modelan como
dimensiones separadas. Esto puede suceder cuando una dimensin tiene mltiples jerarquas. Por
ejemplo para el caso de la dimensin producto se identifica la jerarqua principal: tem, lnea,
categora y rubro, y tambin los atributos marca y color. Si la herramienta elegida no permite
manejo de mltiples jerarquas, ser la principal la que se muestre dentro de la dimensin y las
secundarias debern modelarse como dimensiones separadas.
En los cubos MOLAP cuando las subdimensiones y/o las jerarquas secundarias se
modelan como dimensiones separadas es necesario incluir las claves de estas en la tabla de
hechos. Esto no significa que hay que desnormalizar la tabla de hechos en el DW, puede hacerse
directamente en la definicin del cubo29.
29
Observar en el caso prctico los ejemplos de subdimensiones, especialmente de procedencia del alumno, y otros
atributos como sexo, edad, nacionalidad. Estos se modelan como dimensiones separadas a travs de la definicin de
campos virtuales en lugar de incluir estos campos en las fuentes de datos.
64
Dimensiones con valores variables

Existen dimensiones completamente estticas, con valores bien determinados. Tal vez
nuevos valores sean agregados, pero los existentes en el DW jams sufren modificaciones.
Tambin hay casos donde el elemento de la dimensin en s no cambia (la clave en el sistema
operacional es la misma) porque se refiere a la misma cosa, pero s cambia la descripcin o
alguno de los atributos. Esto puede ocurrir por correccin de errores, o porque el dato sufre alguna
modificacin en el sistema fuente. A estos casos se los conoce como slowly changing dimension
y hay tres opciones para manejarlos:
-
Sobrescribir el registro de la dimensin con el valor nuevo. Esta opcin se usa para
correcciones de errores, y pierde la historia del elemento.
Crear un nuevo registro en la dimensin para el nuevo valor. Es la solucin recomendada

para manejar los cambios en los atributos. Requiere el uso de claves sustitutas para el DW
porque no puede tomarse la misma clave que existe en el sistema operacional.
Crear un campo descripcion_anterior en el registro de dimensin para guardar el valor

previo inmediato del atributo. Es para cambios no muy importantes, que no determinan
una particin histrica. Aunque el valor cambi se puede hacer de cuenta que no se
modific.
Tambin existe la posibilidad de no actualizar nunca el valor, bajo ninguna circunstancia.
En este caso el DW no reflejar los cambios que se realicen en los sistemas fuentes.
El trmino slowly se utiliza porque generalmente los cambios en las dimensiones no se
producen con mucha frecuencia. Sin embargo puede ocurrir que los cambios sean bastante
frecuentes. Las tcnicas a utilizar son las mismas, slo que es probable que en estos casos sea
ms importante guardar la historia de los valores.
Otros tipos de dimensiones que merecen especial atencin, son los casos de las
dimensiones grandes y las dimensiones degeneradas. Se dice que una dimensin es grande
cuando contiene gran cantidad de elementos, por ejemplo personas. En muchos casos pueden
soportarse bien, cuando se trabaja sobre bases de datos relacionales. Es apto para ambientes
ROLAP o HOLAP, no MOLAP. Es necesario aplicar tcnicas para mantenerlas controladas, sobre
todo cuando cambian rpidamente.
Las dimensiones degeneradas son dimensiones donde la descripcin es la clave en el
sistema operacional, por ejemplo un nmero de factura, o el nmero de inscripcin. En estos
casos los cdigos no se regeneran sino que se toman los originales y se ponen en la tabla de
hechos. La dimensin consiste slo del cdigo y por eso se dice que est degenerada (no tendr
tabla asociada).
65
Definicin de las medidas

Una vez diseado el Data Mart, la granularidad de las tablas de hechos y habiendo
diseado las dimensiones resta el ltimo paso en la definicin de cada modelo dimensional, que
consiste en la definicin de las medidas. A continuacin se presentan los diferentes tipos de
mtricas que existen y algunas tcnicas para manejarlas.
Medidas aditivas, semi-aditivas y no aditivas
Una medida es aditiva si tiene sentido sumar sus valores a travs de todas las posibles
dimensiones. Siempre que sea posible deben incorporarse a las tablas de hechos medidas que
sean perfectamente aditivas. Mtricas de actividad, numricas y discretas, como unidades o
importe correspondientes a una venta, generalmente cumplen con esta caracterstica.
Sin embargo las medidas de intensidad, tambin numricas, como balances de cuentas y
niveles de inventario, no son perfectamente aditivas. En estos casos generalmente es posible
sumar los valores a travs de todas las dimensiones menos en el tiempo. Medidas de este tipo se
pueden combinar a travs del tiempo calculando lo que denomina time-average o promedio en el
tiempo. Esta frmula de clculo est basada en el promedio de los hijos. En caso que existan
tres niveles: ao, mes y da, el valor en el mes ser la suma de los valores en cada da del mes
dividido la cantidad de das del mes, y el valor en el ao ser la suma de los valores en los meses
dividido doce (o la cantidad de meses correspondiente al ao en curso).
Para el caso de las medidas no aditivas, como puede ser un valor promedio, o una
temperatura, habr que ver si puede definirse algn mtodo de agregacin que sea vlido para
todas las dimensiones. Otra alternativa es limitar el alcance de las consultas al nivel de
granularidad en que est definido el dato. La mayora de estos casos pueden surgir de no haber
elegido bien la granularidad de la tabla de hechos. Los datos en el nivel de granularidad ms bajo
suelen ser aditivos.
En raras ocasiones es posible que una medida sea textual en lugar de numrica. El
diseador deber intentar modelar estos casos como dimensiones, y de llevar los textos libres a
una lista de alternativas.
Medidas con mltiples unidades
Diferentes medidas de un negocio pueden ser la misma expresada en diferentes unidades
de medicin. Como ejemplos sencillos podran considerarse: expresar distancia en metros,
kilmetros, millas, leguas, o importe de una venta en pesos, en miles de pesos, en dlares, etc.
En los negocios que involucran varios procesos encadenados en etapas y en los cuales se
monitorea el flujo de los productos a travs del sistema suelen presentarse casos un poco ms
complejos de conflictos con las medidas de cantidades. Esto es porque existen mltiples medidas
en los diferentes puntos de la cadena, debido a que los nmeros son expresados en diferentes
66
unidades de medicin. Por ejemplo, en los distintos sectores pueden contarse: unidades de envo
(paquetes y cajas que se trasladan del depsito a la sucursal), unidades vendidas, unidades
escaneadas (paquetes de venta), unidades consumibles (contenido individual de los paquetes),
etc.
De forma similar la cantidad de un producto puede tener varias valuaciones econmicas
posibles, en trminos de valor de inventario, precio de lista, precio de venta original, precio de
venta final.
Esta situacin puede ser agravada si adems se tienen muchas mtricas diferentes. En
estos casos no es correcto incluir en la tabla de hechos slo a las medidas fundamentales, porque
se perdera parte del anlisis. Tampoco es correcto incluir a todas las posibles combinaciones de
medidas fundamentales expresadas en las diferentes unidades de medida y por cada factor de
valuacin posible (porque la tabla sera gigante). La solucin consiste en identificar a las medidas
fundamentales, los factores de conversin y los factores de valuacin, e incorporar todos esos
valores a la tabla de hechos. De esta forma es posible obtener cualquier medida final que se
desee a partir de la combinacin correspondiente.
A veces se cae en la tentacin de incluir los factores de conversin en alguna tabla de
dimensin (por ejemplo: contenido individual, cantidad de unidades por paquete de venta, y
cantidad de paquetes por caja de envos, podran incluirse en la tabla de productos). En general
esto no se recomienda porque los factores de conversin suelen variar, lo que obligara a generar
nuevos registros en la tabla de dimensin para mantener los cambios. Estos factores,
especialmente los asociados a costos y precios, suelen evolucionar en el tiempo y se asemejan
mucho ms a medidas que a atributos de dimensin.
Empaquetar todas las medidas y todos los factores de conversin juntos en el mismo
registro de la tabla de hechos es la manera ms segura de garantizar que esos factores sern
usados correctamente.
Medidas bsicas y derivadas
Existe una clasificacin importante entre las medidas bsicas, que existen naturalmente a
partir de un evento, y las que se calculan en funcin de una o ms de ellas, denominadas medidas
derivadas. Se dice que una medida es bsica o base cuando corresponde a una columna de una
fuente de datos. Ejemplos suelen ser cantidades e importes.
Una medida es derivada si necesita ser calculada, como por ejemplo el importe de ventas
acumulado a la fecha, la rentabilidad, la diferencia entre la cantidad de ingresantes del ao actual
con respecto al mismo valor el ao anterior, la tasa de egresados sobre ingresantes, etc. Hay dos
tipos de medidas derivadas:
67
Las aditivas30. Estas pueden ser calculadas enteramente a partir de las otras medidas
existentes en el mismo registro de la tabla de hechos. Por ejemplo el caso de mltiples
unidades de una medida presentado anteriormente, el clculo de ganancia (como
diferencia entre ventas y costos), etc. Estos casos suelen resolverse mediante vistas que
se presentarn a los usuarios.
Los clculos no aditivos, como porcentajes (ratios) o medidas acumulativas expresadas en

tablas agregadas. Estos casos muchas veces requieren ser calculados al momento que se
consultan por la herramienta de consultas o por quien escribe el reporte. A veces es
preferible incluir algunas de estas medidas en las tablas de hechos agregadas para
simplificar los clculos y los tiempos de respuestas.
Las herramientas del mercado suelen proveer diferentes formas de definicin de medidas
derivadas en funcin de las bsicas. Incluyen frmulas de clculo complejas y muchas veces
evitan tener que realizar clculos en el DW. Estas frmulas pueden utilizarse en la etapa de
diseo, quedando as las medidas derivadas incorporadas al Data Mart o cubo. Tambin pueden
usarse en la interfaz de consulta, permitiendo a los usuarios avanzados definir sus propias
medidas y compartirlas.
Un error frecuente es finalizar el diseo bsico de la base de datos ignorando las medidas
derivadas y recin tenerlas en cuenta cuando comienza el desarrollo de las aplicaciones de
usuarios. Generalmente sern necesarios muchos clculos del negocio que habr que concensuar
y es preferible anticiparse a estas tareas, sobre todo para asegurarse que todas las medidas
bsicas necesarias son tenidas en cuenta.
Normalizacin de tabla de hechos
Hay otro tipo de normalizacin que no se explic en la seccin anterior porque no refiere a
las dimensiones sino a las tablas de hechos y en particular a las medidas. Cuando se tienen
diferentes medidas asociadas a un evento, por ejemplo monto bruto, descuento, etc., lo ms
comn es modelar estas medidas como columnas separadas dentro de la tabla de hechos.
Tambin es vlido usar una sola columna denominada monto junto con una dimensin adicional
que represente el tipo de monto (en este caso los valores: bruto, descuento, etc.). Esta solucin
es til en algunos casos, particularmente cuando se tienen muchas medidas sin valor en muchos
de los registros. Caso contrario implica multiplicar la cantidad de registros de la tabla de hechos,
aumentando el tamao de esta. Adems, tener las medidas como columnas de un mismo registro
es en general mucho ms til para operar con ellas y realizar clculos (por ejemplo porcentaje del
descuento sobre el monto bruto). Estas operaciones se dificultan si los valores estn en registros
separados.
30
Entindase que la medida derivada es perfectamente aditiva por las dimensiones del modelo. No quiere decir que sea
calculada como una suma de medidas bsicas, sino que la medida resultante puede sumarse.
68
Diseo multidimensional avanzado.

Existen situaciones particulares del modelado dimensional donde la eleccin de una
estructura puede ser muy efectiva, o por el contrario donde se corre el riesgo de elegir un diseo
ineficiente. En esta seccin se plantean algunas consideraciones a tener en cuenta. Para obtener
mayor detalle de los casos planteados, ejemplos y grficos, consultar bibliografa ([Kim1998] y
[Kim2002]).
Dimensiones muchos a muchos
En la mayora de las situaciones clsicas de diseo la existencia y granularidad de la tabla
de hechos es bsica y bien entendida, y las dimensiones adjuntas son obvias y no polmicas.
Pero existen casos donde una dimensin puede tener legtimamente ms de un valor o ninguno
para un mismo registro. A estos casos se los suele denominar dimensiones muchos a muchos.
Analizando por ejemplo la temtica del cuidado de la salud, se puede crear una tabla de
hechos por cada registro de tratamiento realizado a algn paciente. La dimensin diagnstico es
muchos a muchos, dado que el tratamiento aplicado a un paciente puede tener ms de un
diagnstico (y tambin puede no tener ninguno).
Para resolver este problema y proveer un nmero arbitrario de valores (o diagnsticos) se
inserta una tabla de relaciones (o tabla puente) entre la tabla de hechos y la dimensin en
cuestin. En el ejemplo se creara una tabla denominada grupo de diagnsticos, con una nueva
clave, que es la que se utilizar en la tabla de hechos. La tabla de grupo de diagnsticos tendr
una clave compuesta, consistente de la clave del grupo y la clave del diagnstico y un campo
adicional que es el factor de peso asociado a ese diagnstico dentro de ese grupo.
El factor de peso asociado cumple el rol de poder analizar al total de tratamientos
agrupados y correctamente sumarizados segn el peso de los diferentes diagnsticos.
Alternativamente este factor de peso podra no usarse y contar a cada tratamiento por cada
diagnstico, multiplicando la cantidad de tratamientos, pero permitiendo evaluar el impacto de
cada diagnstico, en trminos de la cantidad total de tratamientos asociados.
Esta estructura permite ambos anlisis. El usuario decidir cul consultar.
Roles de las dimensiones
Un rol en un DW es una situacin en la que una misma dimensin aparece varias veces
en una misma tabla de hechos. Hay varias maneras en que esto puede ocurrir. Un ejemplo es el
caso de las fotos acumulativas que reflejan el seguimiento del flujo de un producto a travs de una
cadena de procesos. All la dimensin fecha aparece repetidas veces representando la fecha de
recepcin de la orden de pedido, la fecha de facturacin, de envo, etc. Otros ejemplos pueden ser
aeropuertos de origen y de destino de un vuelo, cliente que realiza una llamada y cliente que la
recibe, etc.
69
Como la entidad en cuestin es la misma (los valores son iguales) no tiene sentido
mantener ms de una tabla con la misma informacin. Se crea entonces una nica tabla de
dimensin, y las diferentes dimensiones del modelo hacen referencia a la misma tabla fsica,
utilizando vistas o alias en las consultas. Cada una de estas dimensiones puede ser usada en
forma independiente, cumpliendo roles diferentes en un reporte.
Cuando los roles de una dimensin estn embebidos dentro de otra, como el caso
presentado de la subdimensin ubicacin del cliente, requieren ser normalizados para poder ser
representados por una nica tabla.
Pocas o muchas dimensiones
Como regla general se dice que la mayora de los modelos dimensionales contienen entre
cinco y quince dimensiones por cada tabla de hechos. Menos de cinco hace sospechar que
algunas dimensiones no fueron tenidas en cuenta. Y un nmero muy grande de dimensiones es
usualmente un signo de que muchas de ellas no son totalmente independientes y podran ser
combinadas en una sola dimensin.
Distribucin de medidas de distinta granularidad
Una vez vistos aspectos particulares del modelado de dimensiones, resulta tambin
interesante considerar algunas caractersticas de diseo avanzado de las tablas de hechos
referentes al manejo de la granularidad y agregaciones.
El modelo dimensional es ms poderoso cuanto ms atmicas son las tablas de hechos.
Cuando en un diseo surgen hechos de granularidad diferente lo primero que se debiera hacer es
tratar de forzar a todas las medidas al nivel ms bajo. Este proceso se conoce como asignacin o
distribucin de medidas de niveles altos hacia niveles inferiores. Existen varios casos donde es
necesario aplicar esta tcnica en DWs. El ms dominante es tal vez la alocacin de costos. Por
ejemplo en una factura de transporte de mercadera puede ser que el costo est asociado a la
factura completa y no est inicialmente distribuido en los tems individuales. De esta forma no
podr calcularse la rentabilidad o ganancia por tem.
La distribucin de algunas de estas medidas puede tener una lgica muy compleja. Sera
deseable que sea el rea del negocio entendida en el tema quien se encargue de realizar estas
distribuciones. Si este proceso resulta muy controversial o complicado puede distraer y demorar al
equipo de desarrollo del DW.
Si la distribucin de medidas hacia el nivel de granularidad ms bajo no resultara posible,
el diseador no tendr otra alternativa que representar los niveles ms altos en tablas de hechos
separadas. Una vez que se ha elegido el nivel de granularidad de una tabla de hechos, es muy
importante que todas las medidas aditivas sean presentadas en ese nivel. A veces, con el afn de
mejorar los tiempos de respuesta o simplificar las consultas, se comete el error de guardar
informacin agregada que debiera ser calculada dentro de los registros de una tabla de hecho. Por
70
ejemplo en una tabla con granularidad diaria guardar un dato como el total anual a la fecha. Estos
datos pueden resultar confusos porque no son completamente aditivos. Si al consultar los datos se
eligiera ms de un da se correra el riesgo de contar ms de una vez el mismo valor.
Agregaciones
Luego de haber determinado el diseo global es necesario considerar la estrategia que se
usar para agregar tablas de hechos y de dimensiones. Cada nivel de agregacin que se decida
incorporar debe tener su propia tabla de hechos. Las tablas de dimensin adjuntas a estas nuevas
tablas de hechos deben ser, cuando sea posible, versiones encogidas de las tablas de dimensin
originales.
Las agregaciones, tambin conocidas como tablas de redundancia, tienen el objetivo de
mejorar los tiempos de performance y estn ligados a la implementacin fsica del modelo
dimensional. La creacin de estas depender fuertemente del volumen de datos que se est
manejando31.
Dado que las agregaciones son la forma de poner a punto la performance ser necesario
construir algunas de estas tablas, probar los de tiempos de respuestas y revisarlas. Tambin ser
necesario monitorearlas a travs del tiempo y hacer los ajustes necesarios cuando haga falta, en
funcin del crecimiento del DW.
Hay dos puntos a considerar al construir las agregaciones: las peticiones comunes del
negocio y la distribucin estadstica de los datos. Primero habr que determinar qu podra ser til
revisando en la documentacin del relevamiento cules son las necesidades para reportes de alto
nivel. Luego, revisar cada dimensin para determinar los atributos usados comnmente en
reportes, y las combinaciones de estos atributos para ver cuales se utilizan juntos. Cuantas ms
dimensiones haya ms cuidadoso hay que ser porque mayor ser la cantidad de combinaciones
para las cuales se podran crear agregaciones. En segundo trmino se necesita evaluar la
distribucin estadsticas de los datos. Para esto referirse al prototipo de exploracin de datos, la
informacin de diseo de las tablas, y a los datos en s mismos, buscando contabilizar la cantidad
de valores de cada nivel de la jerarqua de cada dimensin. Existen tcnicas de diseo ms
avanzadas sobre agregaciones que incluyen modelado de dimensiones estructuradas con
jerarquas parciales, jerarquas con profundidades impredecibles, formas de resolver los casos
donde los atributos de las dimensiones cambian de valor, dimensiones de auditoria, cmo manejar
la dimensin tiempo (dentro del da) para representar rangos horarios, etc..
31
Si la tabla de hechos contiene pocos miles de registros probablemente responda rpido y no necesite agregaciones.
Diferente es si tiene cientos de miles o millones de registros.
71
Captulo 4 Presentacin del caso de estudio
Presentacin del caso de estudio

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

sistemas para la toma de decisiones y el anlisis institucional en el mbito de las Universidades
Nacionales Argentinas. Adems de desarrollar soluciones informticas, el SIU ayuda en la
implementacin de las mismas. Dentro de este mbito tambin se realizan desarrollos para
diferentes reas de la Secretara de Polticas Universitarias, donde se recibe y consolida
informacin de todo el sistema universitario nacional.
El objetivo del SIU es dotar al sistema universitario de elementos que permitan mejorar la
confiabilidad, completitud, disponibilidad e integridad de la informacin, contribuyendo de esta
forma a mejorar la gestin de las instituciones, permitindoles optimizar sus recursos y lograr que
el software sea aprovechado en toda su potencialidad.
La filosofa consiste en utilizar la tecnologa al servicio de la institucin colaborando as en
el mejoramiento de la gestin, agilizando las operaciones diarias de la comunidad universitaria.
Tambin se hace hincapi en la calidad de la informacin que se lleva en los sistemas para su
anlisis y utilizacin en la toma de decisiones estratgicas.
32
Informacin a septiembre del 2007. En 2008 el SIU cambia de autoridades pasando a depender de un consorcio de
universidades y adoptando el nombre de Consorcio SIU.
72
El SIU tiene una modalidad de trabajo colaborativo en red, involucrando a distintos actores
de las universidades. La metodologa de trabajo se basa principalmente en la transferencia de
conocimiento, el intercambio de productos y la promocin de encuentros [6] [7].
Los sistemas desarrollados abarcan la gestin operativa de las distintas reas de una
universidad: acadmica, econmica-financiera, recursos humanos, bibliotecas, etc., y su
correspondiente visin gerencial. Entre los sistemas desarrollados:
-
SIU-Pampa/SIU-Mapuche: Sistema de recursos humanos. Gestin del personal y

liquidacin de sueldos.
SIU-Comechingones/SIU-Pilag: Sistema presupuestario-contable.
SIU-Guaran: Sistema de gestin de alumnos (carreras, graduados, aulas, etc.)
SIU-Kolla: Encuestas para seguimiento de graduados
SIU-Araucano: Sistema estadstico de alumnos. Datos que se informan al Ministerio de

Educacin.
SIU-Tehuelche: Sistema de gestin de becas universitarias.
SIU-Quilmes: Sistema de gestin de cobranzas.

En la actualidad, el nmero de implementaciones de los sistemas del SIU en las
universidades nacionales y otros organismos es de aproximadamente 800 y en cada una de las

universidades nacionales se estn utilizando al menos dos de los sistemas del SIU.
En los ltimos aos el SIU ha logrado satisfacer la necesidad de contar con informacin
confiable y oportuna en diferentes niveles de la gestin de las Universidades Nacionales, colaborar
en la cultura de la transparencia, acompaar la mejora de los procesos administrativos, incentivar
la integracin de reas que tradicionalmente se encuentran atomizadas, estandarizar datos y
procesos, arraigar la concepcin de la capacitacin del personal administrativo como una
inversin, e incorporar nuevas tecnologas [7].
Actualmente el SIU se percibe como un importante capital y una avanzada en lo que hace
al desarrollo, distribucin de sistemas y trabajo cooperativo, sobre todo por pertenecer a la
administracin pblica.
4.2
El sistema de software SIU-Guaran

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

inscripciones y resultados de trabajos prcticos y exmenes, profesores asociados a las ctedras,
asignacin de aulas, asistencias, cursos de ingreso, actividades extracurriculares, equivalencias,
certificados, encuestas, etc.
Este sistema se caracteriza por ser seguro, auditable y flexible. Se sustenta en una
metodologa de trabajo colaborativa en red que permite su autosustentabilidad. Hasta el momento
cuenta con ms de 200 implementaciones en unidades acadmicas correspondientes a 42
instituciones educativas argentinas, de las cuales 34 son universidades nacionales [6] [7].
Es utilizado por personal administrativo de la universidad, alumnos, docentes y directivos.
Los servicios brindados dependen del perfil de acceso. El acceso a usuarios se permite a travs
de distintas interfaces, cada una con su funcionalidad: de gestin administrativa, terminales de
autogestin, Internet, o por telfono (utilizando tecnologas sms y wap) [6] [7].
Ms all de las caractersticas del sistema informtico como producto (aspectos
tecnolgicos, prestaciones, mdulos, usuarios, etc.) es interesante resaltar la visin del Guaran
como proyecto. El SIU-Guaran integra componentes sociales, tecnolgicos, polticos, culturales y
econmicos que interactan entre s. El objetivo del proyecto es desarrollar un nico sistema
informtico para todas las Universidades Nacionales con una arquitectura tcnica que permita que
cada institucin pueda extenderlo o personalizarlo, manteniendo la compatibilidad. Esto permite al
sistema reflejar la realidad particular de las instituciones.
El proyecto SIU-Guaran surge hacia fin de ao del 1996, luego de un importante trabajo
de relevamiento de la situacin del sistema universitario argentino. Se decide desarrollar un
sistema informtico de gestin de alumnos que contemplara la complejidad y heterogeneidad del
sistema universitario argentino. Que se adaptara a las realidades de las diferentes unidades
acadmicas, que permitiera acompaarlas en la mejora de sus procesos [6] [7]. El desarrollo del
sistema comenz en agosto del 1997 con la conformacin de un comit de desarrollo, integrado
por un equipo del SIU y tcnicos de las universidades para relevar las necesidades funcionales.
Como metodologa de trabajo se decidi que el SIU desarrolla todas las funcionalidades
transversales y las particularidades son adaptadas por cada universidad. Se entregan todos los
programas fuentes a los equipos tcnicos de las universidades, quienes son responsables de la
implementacin, y se establecen como socios del proyecto. Desde el SIU se asesora y colabora.
La filosofa de trabajo se puede sintetizar en los siguientes lineamientos: trabajo colaborativo,
transparencia, integracin y conocimiento compartido.
Una evaluacin del proyecto permite observar el impacto que ha producido el desarrollo
del SIU-Guaran hasta el momento. Se han automatizado reas de gestin de alumnos, haciendo
ms eficientes los procesos y brindando integridad, seguridad, completitud y confiabilidad a los
datos. Entre otros aspectos, se destacan: el aumento creciente de unidades acadmicas que han
implementado el SIU-Guaran, la extensin del proyecto a otras reas del sistema educativo, la
ampliacin del grupo de tcnicos y de usuarios operativos capacitados en el sistema, el inters por
74
parte de distintos organismos en incorporar la metodologa de trabajo y la consolidacin de una

filosofa de trabajo en red al interior de las universidades [7].
4.3
Desercin y desgranamiento de alumnos

La desercin universitaria es un tema que ha despertado mucho inters en el ltimo
tiempo. El costo econmico para el estado nacional de un alumno en la universidad, la creciente

necesidad de profesionales en algunas reas y otras causas sociales son algunos de los
motivantes que conducen a preguntarse por qu una persona comienza sus estudios universitarios
y luego los abandona.
El fenmeno de la desercin, y tambin el de repitencia, tiene importantes implicancias
personales, institucionales, sociales y econmicas. En lo personal, implica una condicin de
fracaso que afecta emocionalmente a los individuos, especialmente en su insercin laboral. En lo
institucional implica una disminucin del rendimiento acadmico de la universidad y un incremento
innecesario del nmero de alumnos y el costo de mantenimiento de estos. En lo social, la
desercin contribuye a generar inequidad y desequilibrios sociales y desvirta los objetivos que la
sociedad le ha entregado a la educacin superior. Tambin produce un aumento del subempleo y
falta de aporte intelectual. En lo econmico, el costo que esto implica para los sistemas es
enorme. En un estudio de UNESCO realizado en febrero de 2004 en 15 pases que cubren un
90% de Latinoamrica el costo de la desercin se estimaba en U$ 11,1 billones de dlares al ao,
lo que, segn se indic, en pases como Brasil equivale al costo de 2 millones de estudiantes
universitarios [8] [9].
El problema de la repitencia y la desercin es de una magnitud considerable en todos los
pases de la regin. En Argentina se estima que slo el 12% de los estudiantes que ingresan a las
universidades nacionales se gradan, y si bien no hay datos oficiales para las instituciones
privadas se estima que es del orden de un 30%. Un 50% de la desercin ocurre durante los dos
primeros aos de la carrera [8].
De los estudios realizados por la UNESCO [9] se ha concluido que las tasas de abandono
y las causas difieren mucho entre carreras y centros educativos. Esto lleva a querer establecer
una tipologa de las carreras universitarias a partir de las formas en las que se producen los
fracasos.
El sistema argentino tiene sus particularidades, es muy abierto y flexible, se puede ir y
volver cuando se desee. Se rinden exmenes cuando se quiere, por lo que las permanencias
tienden a ser muy largas. Al respecto existen dos problemas: la desercin y la exclusin.
Los factores de la desercin se atribuyen a causas externas como el lugar de residencia,
las caractersticas socioeconmicas y la educacin de los padres y tambin a causas internas
tales como las polticas de administracin, la falta de orientacin vocacional y el exceso de
programas. Entre las posibles acciones para mejorar la situacin actual se indicaron la deteccin
75
temprana de posibles desertores, la prevencin, el apoyo, la determinacin de momentos

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

BDL no tienen sentido dadas las particularidades del ejemplo elegido.
5.1
Requerimientos y especificacin del Data Mart

Al presentar la etapa de definicin de requerimientos como parte del ciclo de vida de un
proyecto de Data Warehousing se recalc la necesidad de contar con usuarios que estn ansiosos
por obtener soluciones para analizar datos para lograr el xito del proyecto. Al momento de
desarrollar este trabajo y por tratarse de un trabajo experimental de tesis no se tiene un usuario
sponsor que colabore en la especificacin de requerimientos. Tampoco se cuenta con usuarios a
los cuales realizar las entrevistas planteadas por la metodologa para esta etapa. Por lo tanto el
anlisis de requerimientos para la solucin presentada surge de quien escribe y la observacin de
algunas de las necesidades de informacin de la comunidad universitaria, por trabajar desde hace
unos aos ese mbito. Cmo se plante anteriormente, mediante este trabajo se busca aplicar en
un caso prctico los conceptos tericos presentados. Adicionalmente se espera que las
posibilidades de anlisis sirvan como puntapi inicial para incentivar una propuesta que realmente
pueda usarse para tomar decisiones.
Cabe aclarar que la complejidad de la temtica abordada requiere que los datos sean
analizados por un grupo interdisciplinario, donde podran participar socilogos, psiclogos,
estadsticos y otros profesionales capaces de realizar interpretaciones correctas sobre la
informacin, definir variables, agrupadores, y tambin de esta forma colaborar al crecimiento de la
esta solucin.
Datos considerados
La idea principal de este trabajo consiste en la identificacin de perfiles de alumnos que
dejan de tener actividad acadmica en la universidad. Para esto se consideran datos en tres
niveles diferentes de anlisis:
-
el alumno en cada uno de los aos acadmicos en que ha tenido actividad dentro de la
carrera,
el alumno, evaluado en todo el tiempo transcurrido desde que comenz la carrera,
y por ltimo la persona. Dado que un mismo individuo puede ser alumno de ms de una
carrera es interesante evaluarlo tambin como individuo en toda la universidad,
independientemente de la o las carreras en que registre actividad.
77
Estos niveles determinan las medidas del cubo: cantidad de personas, cantidad de
alumnos y cantidad de alumnos por cada ao con actividad.
Las dimensiones que se utilizan son variables de evaluacin de la actividad acadmica
(por ejemplo el total de materias aprobadas en un ao, el total de cursados pendientes de
exmenes, etc.), datos de los alumnos (carreras y planes) y otros datos personales (edad, sexo,
procedencia, etc.) 33.
Datos que quedaron excluidos y motivos

En el SIU-Guaran existen datos de los alumnos que hubiese sido interesante tener en
cuenta para estudiar el desgranamiento y que quedaron excluidos en este trabajo. Se trata de los
datos censales, que reflejan la situacin socio-econmica de los alumnos (si trabaja, con quien
vive, como financia sus estudios, el nivel de estudio de sus padres, etc.). En este trabajo no fueron
incluidos por las siguientes razones:
-
Definiciones poco claras que entorpecen la interpretacin de los datos censales.

Algunos datos no tienen un significado del todo definido, como es el caso de si trabaja o
no. No se sabe si la situacin es temporal respecto al momento que se relev el dato o si
es duradera.
Muchos datos dependen del criterio de los alumnos si no fueron ingresados al sistema con
algn tipo de asesoramiento.
Problema para asociar los datos censales con un perodo acadmico.

Los datos censales pueden completarse y actualizarse en diferentes momentos del ao,
pudiendo existir ms de un registro por persona por ao.
En las universidades y facultades se toman criterios propios sobre la actualizacin de
estos datos.
No se tiene buena calidad en estos datos en la mayora de las implementaciones.

Las universidades no suelen darles importancia porque no son necesarios para las tareas
imprescindibles de un sistema acadmico de alumnos, entonces muchos datos estn sin
completar o presentan inconsistencias.
Por ltimo, en cada instalacin de SIU-Guaran se puede personalizar el formulario de

datos pedidos, pudiendo diferir no slo en el significado y contenido sino tambin en el
conjunto de datos existentes y los perodos de relevamiento. De hecho, la UNS cuenta con
personalizaciones respecto a esta informacin.
Tener en cuenta estos datos hubiese requerido desarrollar procesos de extraccin de
datos personalizados.
Inicialmente se pens adems en definir categoras de actividad de los alumnos (por
ejemplo clasificar la actividad anual en: nula, baja, suficiente, alta y muy alta, en funcin de la
33
Observar que si el anlisis que se pretendiera hacer fuese otro, las medidas y dimensiones podran considerarse
totalmente diferentes. Por ejemplo el alumno podra ser una dimensin y la cantidad de cursados aprobados, cursados
desaprobados, finales aprobados, etc. podran ser medidas.
78
cantidad de finales y cursados), intensin de actividad (en cuntas materias se inscribe o se

presenta a rendir) y categoras de rendimiento (en funcin de los resultados obtenidos).
Finalmente se desech la propuesta. Resulta complicado en una aplicacin real definir estos
parmetros que en gran medida dependen del plan de estudio, lugar geogrfico, situaciones
sociales, etc. Para realizar una clasificacin justa habra que tener en cuenta variables
dependientes de la carrera: la cantidad de materias del plan, las materias en s, si el plan
contempla sistema de puntos, materias promocionables y la realidad de los alumnos de la
universidad o facultad: horarios de cursado disponibles, si la mayora de los alumnos trabaja,
provienen de otro lugar, viven lejos de la universidad, etc. Todo esto terminaba oscureciendo las
frmulas y alejndonos de los objetivos del caso de estudio.
Otras variables que resultan de inters para el anlisis de desercin y desgranamiento
refieren a la lentificacin en la carrera (respecto al plan de estudio o al promedio histrico de
tiempo desde el ingreso hasta la graduacin en la carrera), la repitencia (si el alumno debe
recursar materias, o rendir muchas veces algn final) y la movilidad (si se producen cambios de
carrera). Es muy difcil definir este tipo variables. Al intentarlo surgen preguntas como por ejemplo:
-
Qu alumnos deben ser considerados para calcular el promedio histrico? A partir de

qu cohorte se considera? Existen todos los datos necesarios en la base de datos OLTP
SIU-Guaran?
Cmo calcular lentificacin?, es la cantidad de materias cursadas sobre la cantidad total

del plan actual del alumno? Y si el alumno se cambi de plan, cmo debieran contarse
las materias del plan anterior? Qu sucede si el plan est compuesto de materias y
crditos?
Cundo se considera que un alumno se movi de carrera?: porque qued de baja?,

porque ya no se inscribe a materias? Qu sucede cuando slo registra actividad en
materias comunes?
Para trabajar con este tipo de datos es necesario que exista un equipo que respalde las
definiciones y que vaya a utilizar los datos definidos. Por el momento no tiene sentido considerar
estas cuestiones porque implican una complejidad conceptual imposible de abordar en este
trabajo.
5.2
Arquitectura del caso prctico

La arquitectura de la solucin propuesta se presenta en la figura 17 y es una adaptacin
de la presentada en la figura 3. En este caso, la base de datos del sistema SIU-Guaran es la

nica fuente de datos. La seccin de transformacin de datos no existe explcitamente34. La
extraccin de datos se realiza mediante la ejecucin de procesos que se incorporan en la base de
34
Debido a diversos motivos del sistema universitario, pero principalmente a la falta de maduracin en estas temticas,
resulta difcil crear y administrar tanto un DW como un rea de transformacin de datos. Estas tareas, junto con la
implementacin de una herramienta de ETL y la conexin de los cubos al DW (planteado en la figura) se dejan para trabajo
futuro.
79
datos del SIU-Guaran. Estos procesos generan archivos de texto plano que se utilizan para
generar el Data Mart o cubo. Las escasas transformaciones de datos que se realizan se incluyen
dentro de dichos procesos.
La tarea de diseo consiste en crear un modelo multidimensional, propietario. Este modelo
o meta data se utiliza como dato de entrada del componente que genera el cubo (O3 Builder) en la
etapa de carga de datos.
En la figura 17 se observan los diferentes mdulos de la herramienta O3. Estos se pueden
clasificar en tres grandes categoras: los componentes de la interfaz de usuario (que sern las
nicas herramientas para anlisis de informacin que se utilizarn en este trabajo), los de diseo y
construccin de cubos y los de administracin de cubos en un servidor (O3 Server y O3
Administration Server, para configurar usuarios y permisos de acceso por perfiles).
O3 Builder
Load
O3 Browser
(escritorio)
t
x
t
BD SIUGuaran
E.T.
(sp)
O3 Report
t
x
t
t
x
t
O3 Dashboard
Modelo del
cubo (.mdl)
META DATA
O3 Scorecard
O3 Rules
O3 Process
O3 Portal
(web)
O3 Designer
O3 Query
O3 Server
rea de usuario
Idealmente
sera un DW
(O3 Query)
DW
O3 Adm
Server
Figura 17. Arquitectura de la solucin propuesta.
5.3
Matriz y modelo lgico del Data Mart

La matriz que resulta del anlisis de requerimientos planteados en la seccin 5.1.1 se
muestra en la figura 18. Se pueden ver claramente los tres niveles de anlisis contenidos en el
Data Mart (persona, alumno y alumno por ao con actividad) y las dimensiones planteadas, junto
con los cruces vlidos. El grfico presenta los ejes intercambiados respecto a la propuesta original
slo para obtener una mejor visualizacin
La mayora de las dimensiones (unidad acadmica, edad, ttulo secundario, cantidad de
carreras activo, etc.) estn asociadas a la persona y por lo tanto se heredan en las otras dos
medidas. Carrera no est definida a nivel de persona porque puede haber ms de una y es la
razn por la cual se distingue entre personas y alumnos. La dimensin Ao informado
corresponde slo para la medida que cuenta alumnos en cada ao que tienen actividad.
80
Unidad Acadmica
Ao de Ingreso
Unidad Acadmica
Ao de Ingreso a la Universidad
Ao de Ingreso a la Carrera
Ao Informado
ltimo Ao de Actividad en la Universidad
ltimo Ao de Actividad en la Carrera
Edad al Ingreso a la Universidad
Edad al Ingreso a la Carrera
Edad al ao Informado
Sexo
Nacionalidad
Pas
Provincia
Localidad
Colegio
Ttulo Secundario
Ao de Egreso del secundario
Orientacin Vocacional
Cantidad de carreras inscripto
Cantidad de carreras activo/inscripto
Cantidad de carreras egresado
Carrera
Cursados Aprobados Totales por Persona
Cursados Aprobados Totales en la Carrera
Cursados Aprobados en la Carrera y Ao Informado
Ao Informado
ltimo Ao de Actividad
Edad
Sexo
Nacionalidad
Procedencia
Ttulo Secundario
Ao de Egreso del secundario
Orientacin Vocacional
Cantidad de carreras inscripto
activo
Cantidad de carreras egresado
Carrera
Cursados Aprobados
Cantidad de alumnos por ao

con actividad
Niveles
Cantidad de alumnos
Dimensiones
Cantidad de personas
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
81
Cursados Desaprobados
Cursados Promovidos
Finales Aprobados
Finales Desaprobados
Equivalencias Externas
Cursados Desaprobados Totales por Persona

Cursados Desaprobados Totales en la Carrera
Cursados Desaprobados en la Carrera y Ao Informado
Cursados Promovidos Totales por Persona
Cursados Promovidos Totales en la Carrera
Cursados Promovidos en la Carrera y Ao Informado
Finales Aprobados Totales por Persona
Finales Aprobados Totales en la Carrera
Finales Aprobados en la Carrera y Ao Informado
Finales Desaprobados Totales por Persona
Finales Desaprobados Totales en la Carrera
Finales Desaprobados en la Carrera y Ao Informado
Equivalencias Externas Totales por Persona
Equivalencias Externas Totales en la Carrera
Equivalencias Externas en la Carrera y Ao Informado
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Figura 18. Matriz correspondiente al Data Mart del caso prctico.
Varias de las dimensiones (las referentes a cantidades de materias y Edad) presentan

tres niveles de anlisis, uno correspondiente a cada medida. Debe seleccionarse la combinacin
de nivel y medida adecuada a la consulta deseada. Por ejemplo, si se quiere ver lo ocurrido dentro
de una carrera y un ao en particular (utilizando la dimensin Ao Informado) se debe utilizar la
medida Cantidad de alumnos por ao con actividad y consultar estas dimensiones en el nivel
ms bajo (por ejemplo: Cursados Aprobados en la Carrera y Ao Informado). Si se desea evaluar
lo realizado dentro de la carrera, sin discriminar por ao acadmico ser necesario elegir la
medida Cantidad de Alumnos y utilizar el nivel intermedio que refiere a la actividad dentro del
alcance de cada carrera (por ejemplo: Cursados Aprobados Totales en la Carrera). En el nivel
superior se resume la actividad a nivel de persona (Cursados Aprobados Totales por Persona).
Tambin es posible comparar lo ocurrido dentro de un ao acadmico con el total acumulado en la
carrera, por ejemplo. Esto se logra consultando la medida Cantidad de alumnos por ao con
actividad y la dimensin Cursados Aprobados en sus niveles en la carrera y ao informado
y totales en la carrera en forma simultnea.
La dimensin Ao de Ingreso tambin presenta dos niveles de anlisis: ingreso a la
universidad (o unidad acadmica) e ingreso a la carrera.
El modelo de datos resultante tal como se visualiza al realizar consultas en el cubo se
muestra en la figura 19. Las tablas de color gris son las tablas de hechos, que muestran las
relaciones con las dimensiones. El resto son dimensiones. Las dimensiones que tienen ms de un
nivel o jerarqua se indican en color amarillo en el diagrama, por ejemplo procedencia y cursados
aprobados.
82
Figura 19. Modelo de datos lgico del caso prctico. Tablas de hechos y dimensiones.
Observar que como un alumno es una persona, tambin podr consultarse la cantidad de
alumnos por edad, o nacionalidad, y las dems dimensiones y niveles que se muestran asociadas
a la persona. Todos los datos definidos en un determinado nivel son heredados en los inferiores,
es decir que, por ejemplo, se podra consultar Cantidad de alumnos por ao con actividad segn
cursados aprobados para una carrera en un determinado ao acadmico (Cursados Aprobados
en la Carrera y Ao Informado y Ao Informado) segn la edad de la persona al momento en
que comenz sus estudios universitarios (sin importar la carrera, Edad al Ingreso Universidad),
pero no se podr consultar Cantidad de Personas segn Edad al Ao Informado o Edad al
Ingreso Carrera, porque esa medida no est definida en esos niveles de granularidad.
5.4
Modelo fsico y consideraciones de diseo

El modelo fsico puede pensarse en dos partes: por un lado la estructura de los archivos
de texto plano que contienen los datos para el cubo, y por otro el modelo de datos que define la
forma de visualizacin del mismo, y mapea la estructura de los archivos de texto en el cubo
MOLAP (archivo con extensin mdl).
83
Diseo fsico de las tablas del DW que se usan para el Data Mart
En este ejemplo, las tablas de hechos son tres, todas se utilizan dentro del mismo cubo.
La tabla con el nivel de granularidad ms bajo es la de Alumnos por Ao Acadmico en que
presenta actividad. Esta tabla puede considerarse del tipo fotografas peridicas con una foto por
alumno y ao acadmico.
Las otras dos tablas pueden considerarse de tipo fotografas acumulativas, pero donde se
guarda slo el ltimo estado, reflejando la informacin acumulada a la fecha del alumno o la
persona. Estas tablas cumplen una doble funcin como tablas de dimensin con atributos (y se
definen como tablas locales en O3 dentro del archivo con extensin mdl). Tambin representan
una agregacin de la tabla cuyo nivel de detalle la precede.
En los tres casos se trata de tablas de hechos sin medidas, ya que la nica medida
asociada a cada tabla es la cantidad de registros.
La estructura de los archivos de texto respetan cierto nivel de normalizacin por los
siguientes dos motivos:
-
para que a futuro pasen a formar parte de un DW. Se consideran dimensiones acordadas
con otros cubos ya existentes sobre el SIU-Guaran. Se intenta minimizar las
transformaciones necesarias en los datos para lograr la arquitectura de la solucin
definitiva.
y para que el tamao de los archivos sea menor.

La correspondiente desnormalizacin necesaria para el diseo final del Data Mart se logra
dentro de la definicin propia del cubo de O3 y se realiza al momento de la construccin de este.

Esto produce un incremento en el tiempo de generacin del cubo y mayor complejidad en el
archivo .mdl; pero se prioriza normalizar las tablas por los motivos expuestos. Una vez
implementado el DW, la desnormalizacin podra realizarse en l, o en las consultas SQL que
surjan de modificar la definicin del cubo para consumir los datos.
Las tablas diseadas para formar parte del DW son mostradas en la figura 20.
84
Figura 20. Estructuras de los archivos de texto.
Notar que muchas de las dimensiones planteadas en el modelo de la figura 19 no

necesitan implementarse mediante una tabla porque el cdigo de la dimensin es la descripcin
de la misma y el nivel de agrupamiento que se utiliza se define dentro del modelo del cubo. Estos
casos se modelan como dimensiones directamente en la definicin del cubo (archivo mdl). Tal es
el caso de los aos (ao informado, ao de ingreso, etc.) y las cantidades de materias (cursados
aprobados, cursados desaprobados, finales aprobados, etc.).
Observar que las dimensiones que cuentan cantidades de materias se definen en las tres
tablas de hechos. Esto es as porque representan cosas diferentes, cada una cuenta en el nivel de
granularidad en que se define, y por eso tienen nombres diferentes. Luego se combinan como
diferentes niveles de anlisis de una misma dimensin slo para simplificar el modelo final y no
tener muchas dimensiones similares que dificulten el anlisis. Es importante destacar que los
datos sumarizados se calculan en las tablas de alumnos y personas porque se decidi utilizarlos
como dimensiones. Si en otro modelo de anlisis se decidiera usar estas cantidades como
medidas no ser necesario calcularlas, se hara solo, definiendo la medida en el nivel ms bajo (de
alumno en ao acadmico) y utilizando el mtodo de agregacin suma.
Algunos datos contenidos en estas tablas no se usan en el modelo final. Se incluyeron
porque pueden utilizarse a futuro para armar diferentes cubos, focalizando en anlisis ms
especficos.
85
Diseo fsico del Data Mart

Respecto al diseo final que ver el usuario, este respeta la forma de la figura 19. En el
cubo de O3 las estructuras internas deben aplanarse completamente, formando un esquema
estrella. Para esto las claves de todas las dimensiones deben estar en la tabla donde se encuentra
la medida (en el nivel correspondiente). Cuando no estn se definen especialmente mediante la
utilizacin de tablas locales y campos virtuales.
Si las tablas estuvieran en una base de datos, en lugar de ser archivos de texto, el
aplanamiento podra realizarse mediante uniones de tablas en las consultas en SQL y la creacin
de tablas locales y campos virtuales no sera necesaria en la mayora de los casos.
Definicin de fuentes de datos
Especficamente dentro de la herramienta O3 el diseo de un cubo comienza con la
definicin de las fuentes de datos, que en este caso son los archivos de texto. Para tomar un
archivo de texto como fuente se establece la ruta de acceso (figura 21) y se definen los campos
con sus respectivos tipos (figura 22). Para la ruta de acceso puede utilizarse un parmetro, como
en este caso (raiz).
Figura 21. Definicin de fuentes de datos en O3.

Tabla de hechos correspondiente al archivo de texto con informacin de personas (int_de_personas.txt)
En la definicin de los campos y tipos de datos (figuras 22_1 y 22_2) puede utilizarse la
funcin de autollenado si el archivo de texto tiene como cabecera los nombres (e indicar
expresamente saltar ese primer registro como se puede observar en la figura 21).
86
Figura 22_1. Definicin de campos que componen el archivo de la fuente int_dw_desercion_alumnos_anio.
Figura 22_2. Definicin de campos que componen el archivo de la fuente int_dw_personas,

que adems se utiliza como tabla local
La informacin entre tablas se vincula automticamente por los nombres de los campos,
que deben coincidir exactamente para considerarse iguales. De esta forma por ejemplo el campo
NACIONALIDAD de la tabla int_dw_personas (figura 22_2), se considera igual al de la tabla
LT_Nacionalidades (figura 23).
87
Figura 23. Definicin de tabla de dimensin en O3.
Definicin de dimensiones
La definicin de las dimensiones se realiza identificando los cdigos nicos de los valores
para cada nivel de estas y las descripciones correspondientes. En la figura 24 se muestra la
definicin de la dimensin Nacionalidad, compuesta por un nico nivel.
Figura 24. Definicin de una dimensin con solamente un nivel.
88
Las dimensiones deben tener al menos un nivel, pero pueden tener ms de uno. Tal es el
caso de Procedencia. Para cada nivel se indica el campo que es la clave que identifica los
distintos valores y las descripciones correspondientes. Y en la dimensin se indica si el nivel ms
bajo identifica unvocamente al resto de los niveles o no. Observar en la figura 25 la indicacin de
Colegio como nivel nico de la dimensin. En estos casos slo es necesario incluir en las tablas
de hechos la clave de ese nivel, el ms bajo.
Figura 25. Definicin de dimensin con varios niveles: Procedencia.
Definicin de medidas
Por ltimo se definen las medidas, que pueden ser bsicas (corresponden a un campo de
la fuente), o derivadas (se calculan a partir de medidas bsicas y/o datos adicionales).
Figura 26. Definicin de medida Cant Personas como medida bsica.
89
Para las medidas bsicas se indica el campo de la fuente al que corresponde, el mtodo
que se utiliza cuando es agregada en los niveles superiores de las dimensiones y el alcance (cada
una de las dimensiones y niveles para los que est definida la medida). Esto se muestra en las
figuras 26, 27 y 28.
Figura 27. Mtodo de agregacin para la medida Cant Personas. Suma indica que por ejemplo en el nivel Localidad de
la dimensin Procedencia se contar la suma de las personas de los colegios correspondientes.
Figura 28_1. Parte de la definicin del alcance de la medida Cant Personas.
Figura 28_2. Parte de la definicin del alcance de la medida Cant Personas.
La definicin del alcance de cada medida es una tarea importante y debe estar acorde a la
lgica de los datos. En las figuras 28_1 y 28_2 se observa parte de lo realizado para Cant
Personas. El nivel de cada dimensin que existe en la fuente de datos de la medida
(int_dw_personas) es el primero para el cual queda definida y se indica con el smbolo del diskette.
De ese nivel para arriba en la jerarqua se utiliza en general la agregacin (smbolo de suma). En
algunos casos podra optarse por dejarlo indefinido (signo de interrogacin) para obligar a que las
90
consultas se hagan seleccionando uno o ms valores del primer nivel para el cual la medida queda
definida. Del nivel del diskette para abajo hay que indicar que la medida no est definida y no
puede consultarse. Observar, por ejemplo, como se utiliza la agregacin en la dimensin
Procedencia, la indefinicin completa de la dimensin Carrera, la diferencia en la visualizacin
final (al consultar el cubo) respecto a Ao Informado y la definicin del alcance slo para el nivel
superior en las dimensiones que cuentan materias35.
Uso de tablas locales y campos virtuales
Anteriormente se dijo que ciertos datos de la persona pueden proyectarse a los niveles de
alumno y alumno por ao acadmico. Como no fueron incluidos explcitamente en los archivos de
texto fuente de las medidas correspondientes esto debe indicarse al disear el modelo en O3,
mediante la utilizacin de tablas locales y campos virtuales. En la figura 29 se puede apreciar la
definicin de la tabla local con los datos de las personas que se utilizan para desnormalizar las
otras tablas de hechos.
Figura 29. Tabla local TPersonas. Incluye datos como sexo, nacionalidad, colegio secundario, etc.
que podrn obtenerse a partir de la combinacin de unidad acadmica y nmero de inscripcin.
En la figura 30 se muestra la definicin del campo NACIONALIDAD como campo virtual.

Esto se utiliza para incorporar ese dato en los niveles de granularidad alumno y alumno en ao
acadmico correspondientes a las otras tablas de hechos.
35
El detalle de las posibles combinaciones del alcance de las medidas es especfico de la herramienta y queda fuera de
este trabajo.
91
Figura 30. Recuperacin del valor correspondiente a NACIONALIDAD mediante de la definicin de un campo virtual.
Esto se utiliza cuando el campo no est en la fuente de datos (caso de int_dw_alumnos e
int_dw_desercion_alumnos_anio)
En la figura 30 tambin se puede observar que los campos virtuales pueden ser utilizados
con otros propsitos: para calcular valores derivados a partir de los datos fuentes (ejemplo:
EDAD_IngrUniv), para indicar valores por defecto para el caso de nulos (DV_COLEGIO y
otros), entre otros posibles usos, como definicin de medidas, definicin de descripciones a partir
de ms de un campo, etc.
5.5
Personalizacin del proceso ETL

El ejemplo elegido consta de tres niveles diferentes de definicin de tablas de hechos. El
proceso de extraccin consiste principalmente en la creacin de esas tres tablas, las cuales se
construyen de la siguiente manera:
En la tabla de alumno por ao, se crea un registro para cada ao por cada individuo que
tiene actividad acadmica en cada carrera, comenzando por el ao de ingreso de esa persona a la
universidad hasta el ao acadmico corriente. Para cada alumno (persona en una determinada
carrera) se cuenta la cantidad de cursados aprobados, cantidad de cursados desaprobados,
cantidad de finales aprobados, entre otras cosas, durante cada ao acadmico y se agrega el
registro a la tabla si alguna de esas cuentas es diferente a cero.
La tabla de hechos de alumnos, recopila informacin del alumno dentro de la carrera: ao
de ingreso a la carrera, datos del plan y cantidades totales de cursados, finales y equivalencias,
desde el ingreso a la carrera hasta la fecha. Para calcular estas cantidades se realiza una suma
sobre los datos de la tabla anterior a travs de los distintos aos.
La tabla de hechos de personas tambin calcula las cantidades de materias como suma,
en este caso a partir de la tabla de alumnos. Se consideran todas las carreras en las que es
alumno36. Adems en esta tabla se definen otros atributos de las personas que se representan
36
Tener en cuenta que las materias comunes se contarn dos veces, dependiendo de cmo se estn registrando en el
SIU-Guaran, seguramente se cuente como materia aprobada en una carrera y como equivalencia en la otra.
92
como dimensiones (sexo, edad, procedencia, etc.). Los procesos de creacin de las tablas y
llenado de las mismas se adjuntan en el apndice.
Para este caso prctico la transformacin de datos es casi nula y se incluye como parte
del proceso de extraccin. Esto es debido a que, por el momento, no se implementa la arquitectura
completa de un proyecto de DW y no se dispone de un espacio especial para esta tarea. Una de
las recomendaciones bsicas es la creacin de claves sustitutas. Esto no se realiza por los
siguientes motivos:
-
La fuente de datos es nica.
No se implementa por ahora la etapa de limpieza y transformacin de datos, dejando esta

tarea para desarrollo futuro.
Utilizar los cdigos originales facilita el control de datos extrados y sirve para mejorar la
calidad de los datos del sistema de gestin.
En este caso prctico tampoco es posible ejemplificar algunas consideraciones respecto a
la integracin de datos, porque estos son extrados de un nico sistema fuente donde ya se
encuentran integrados.
5.6
Problemas de calidad de datos

Los problemas de calidad pueden manifestarse en tres lugares diferentes y sern
evidenciados cuando el cubo est generado. Ser necesario testear adecuadamente: el estado de
los datos en la fuente, el proceso ETL y la definicin del modelo del cubo para asegurarse que la
solucin es correcta.
Si la calidad de datos en el origen no es buena no habr mucho que se pueda hacer. De
todas formas durante los procesos de extraccin, transformacin y carga de datos podrn tomarse
algunas decisiones que resuelvan los problemas de calidad de diferentes formas. Por ejemplo se
puede decidir descartar un registro que contenga algn campo nulo, o rellenarlo con algn valor
por defecto.
Lamentablemente la mayora de los problemas se hacen evidentes al generar el cubo con
informacin real, ya que es difcil contemplar todas las posibles anomalas que podran presentar
los datos. Lo ms sencillo y til es examinar los datos reales y los problemas de calidad que
presentan y dedicarse a solucionarlos. En lugar de pensar todas las posibles inconsistencias que
podran existir, trabajar sobre las pocas o muchas que realmente surjan.
Controles en la definicin del modelo y la generacin del cubo

De los controles a realizar el ms sencillo es sobre la definicin del modelo del cubo. Una
vez generado el cubo hay que controlar que todo el contenido de los archivos de texto haya sido
93
incorporado para la visualizacin final del usuario. El log de la generacin registrar errores y
advertencias que sern de utilidad.
Debe controlarse:
-
Cada medida.
En este caso la cantidad de registros de cada archivo de tabla de hechos debe ser igual a
la cantidad total de la medida correspondiente en el cubo. Si no coincide, puede ser que
haya registros que por algn motivo se hayan excluido. Posiblemente el motivo de
exclusin sea algn campo nulo, o no existente en otra tabla (falta de integridad referencial
entre los datos).
Si hubiese otras medidas adems de cantidades, debieran controlarse al menos que los
totales de los valores coincidan.
Cada dimensin.
Puede ocurrir que falten valores en las tablas de dimensiones o existan cdigos no
adecuados en las tablas de hechos. Estos casos podrn visualizarse al desplegar los
valores de las dimensiones utilizando la interfaz de acceso al cubo.
Tambin debe controlarse que las dimensiones contengan los valores adecuados, y
descartar as posibles errores en la definicin del modelo: al asociar los campos, las
claves, las descripciones, definir niveles nicos, etc.
Suele ocurrir que valores diferentes coinciden en la descripcin y entonces es necesario
utilizar tambin el cdigo para diferenciar estos casos.
Controles en los procesos de extraccin y transformacin de datos

Respecto al proceso ETL se requiere un riguroso testeo sobre los datos aportados al DW.
Hay que tener cuidado de no descartar datos sin la intencin explcita de hacerlo y testear
cuidadosamente la lgica utilizada para la extraccin. De todas formas es conveniente chequear
las cantidades del cubo con reportes y otras consultas provenientes del/los sistemas de gestin
correspondiente.
Si existiese un rea de transformacin de datos sera necesario tomar algunos indicadores
generales (totales de registros, totales de campos nulos o con valores incorrectos, cantidades de
valores posibles, etc.) en las fuentes de datos y en diferentes niveles de los procesos de
transformacin para asegurarse que los datos van evolucionando de forma adecuada y no se
pierden valores.
Problemas de calidad en el origen del dato

Por ltimo, el cubo puede presentar inconsistencias o anormalidades provenientes del
sistema de gestin. En este caso si el SIU-Guaran se usa correctamente y con los controles
necesarios activados no existirn estos problemas en la base de datos. Sin embargo en muchas
ocasiones se descubren datos inconsistentes y/o falta de informacin en el sistema de gestin.
94
Estas situaciones se deben generalmente a procesos de migracin de informacin de otro sistema

que se incorpora al SIU-Guaran con controles desactivados o en forma incompleta. Tambin
existe informacin incompleta cuando se decide no ingresar al sistema datos no imprescindibles,
o datos no obligatorios o desconocidos que son dejados en blanco o completados con datos
incorrectos.
Estos casos suelen ser detectados ms tarde a partir de la observacin de los valores de
las dimensiones del cubo y los cruces de variables permitidos. Por ejemplo, edades fuera de
rangos razonables indican que la fecha de nacimiento de las personas que figura en la base de
datos no es correcta. Datos de procedencia desconocida surge del hecho que el colegio
secundario no est cargado para muchas personas. Otro caso que podra ocurrir es alumnos que
tuviesen actividad acadmica anterior al ao de ingreso37.
Todos estos casos son ejemplos de la retroalimentacin que generan las soluciones para
anlisis de datos en los sistemas operacionales. Debieran ser corregidos en el sistema operativo
de origen y luego regenerar el cubo con la informacin correcta.
37
En este trabajo estos casos se descartan antes, directamente no se los extrae de la fuente de datos.
95
Captulo 6 Uso de la herramienta y anlisis de datos
Uso de la herramienta y anlisis de datos

Una vez generado, el cubo se encuentra en condiciones de ser consultado 38. Podr
accederse como archivo local directamente utilizando el O3 Browser (abrir el archivo

dm_desgranamiento_alumnos.cube desde la ubicacin correspondiente) o publicarse en el
servidor de O3 y accederse a travs de las interfaces que se hayan instalado (escritorio o web) y
con los permisos que pudiesen haberse configurado39.
Este captulo tiene el propsito de mostrar la funcionalidad bsica de la herramienta y
algunos ejemplos de las amplias posibilidades de anlisis brindadas por el cubo diseado. Los
datos sobre los cuales se trabaja son inventados, no son reales. Han sido generados para poder
ejemplificar algunas cuestiones y pueden presentar inconsistencias propias de no provenir de una
base de datos real de SIU-Guaran.
6.1
Acceso al cubo y operaciones bsicas
Acceso al cubo y vista inicial

Al abrir el cubo se obtiene la vista inicial, consistente de la medida Cant Personas y las
dimensiones Unidad Acadmica y Ao Ingreso (en el nivel Ao Ingreso a la Universidad).
Figura 31. Vista inicial predeterminada del cubo dm_desgranamiento_alumnos generado con datos de prueba.
Observaciones: en el ejemplo se consideraron datos de una facultad solamente.
38
39
En la seccin 8.4 del apndice se explica cmo generar el cubo.

En los ejemplos de este trabajo se accede con la interfaz de escritorio de forma local.
96
Existen datos con problemas de calidad, no debieran existir casos con ao de ingreso en 0.
Esta consulta es la forma de acceso al cubo predeterminada y queda definida por el cruce
de las dos primeras dimensiones del modelo y la primera medida, sin ningn filtro. A partir de esta
vista puede navegarse el cubo. Es posible regresar a la misma desde el men Explorar Vista
inicial o con el botn de acceso rpido.
Los usuarios pueden confeccionar reportes o vistas propias para consultas frecuentes y
utilizarlas para acceder al cubo en lugar de hacerlo mediante la vista inicial predeterminada. Estas
vistas pueden contener filtros, otro tipo de grfico, frmulas calculadas, muchas dimensiones y
medidas. A partir de ellas tambin es posible navegar el cubo, pudiendo retornar al punto de
partida con la opcin de vista inicial.
Operaciones bsicas de consulta

Las operaciones ms comunes y sencillas sobre los datos consisten en: reemplazar o
agregar dimensiones a una consulta, seleccionar diferentes medidas, realizar filtros y desagregar
informacin.
Seleccin de dimensiones
La seleccin se realiza arrastrando la dimensin deseada al grfico, superponindola con
la que se quiere reemplazar. Cuando esta operacin se realiza en el modo grfico la dimensin a
ser reemplazada se colorea de amarillo en el momento en que se debe soltar el arrastre del ratn.
Figura 32. Ejemplo de reemplazar la dimensin Unidad Acadmica por Sexo en la consulta, para obtener Cant
Personas por Ao de Ingreso (a la Universidad) y Sexo.
97
Al trabajar en el modo grilla la dimensin a reemplazar se colorea de gris. En este caso es

posible no slo reemplazar dimensiones existentes en una consulta sino tambin agregar, creando
as tablas con ms de una variable en las filas y/o en las columnas. El lugar donde se insertar la
dimensin que se incorpora a la consulta es sealado con una barra amarilla. Es posible cambiar
el orden de presentacin arrastrando las dimensiones dentro de la tabla.
Para pasar del modo grfico a grilla usar la opcin Desplegar tabla del men Ver, o el
botn de acceso directo.
Figura 33. Ejemplo de consulta en formato de tabla utilizando muchas dimensiones.
Seleccin de medidas
Es posible cambiar cualquier medida simplemente desplegando el listado correspondiente
y eligiendo la deseada. Tambin pueden utilizarse las medidas dentro de la visualizacin de la
consulta, como si fuesen los valores de una dimensin. Esta opcin generalmente se utiliza para
comparar medidas. En las figuras 34 y 35 pueden apreciarse ejemplos en modo grfico y grilla
respectivamente.
98
Figura 34. Comparacin de Cant Personas vs. Cant Alumnos abierto por Sexo.
Figura 35. Comparacin de medidas Cant Personas y Cant Alumnos,

discriminadas por Ao de Ingreso (a la universidad) y Sexo. Visualizacin en formato de grilla.
Desagregar informacin y filtrar

Se puede acceder a un nivel de informacin desagregado haciendo clic sobre el valor
deseado, o seleccionndolo de la lista desplegable de la dimensin (siempre que forme parte de la
consulta y se utilice la opcin por defecto Explorar hijos).
99
Si el nivel consultado es el ltimo, el ms detallado, dentro de la jerarqua de la dimensin,

la operacin de desagregacin no muestra nuevos valores, sino que acta como un filtro sobre la
consulta anterior, dejando visible slo el valor elegido.
Figura 36. Izquierda: filtro a partir de figura 35, seleccionando el valor Mujeres en Sexo. Grficos restantes: drill down
sobre valores de la dimensin Procedencia, eligiendo pas Argentina y luego provincia San Juan.
Los filtros tambin pueden realizarse sobre valores de dimensiones que no estn siendo
visualizadas en la consulta corriente. Los filtros que se efecten modificarn los resultados
actuales. No hay que perderlos de vista al momento de interpretar los valores mostrados en las
consultas para evitar confusiones.
Tambin es posible seleccionar ms de un valor de las dimensiones eligiendo la opcin de
lista de elementos. Y se puede consultar el desgranamiento de ms de un valor al mismo tiempo,
lo que significara un mltiple drill down. Para esto la herramienta propone las opciones expandir
todos los hijos, expandir todo el nivel, explorar nivel y mostrar nivel.
Figura 37. Izquierda: filtro de lista de elementos para los aos de ingreso 2000 a 2007.
Derecha: Drill down de ms de un elemento utilizando la exploracin por niveles (opcin: expandir hijos)
100
Para volver al nivel anterior (drill up) hay que seleccionar el valor correspondiente en la
dimensin (el padre, un nivel ms arriba), asegurndose de tener la opcin de visualizacin por
defecto (explorar hijos, no lista de elementos). La opcin atrs es tambin til muchas veces
para retornar a consultas anteriores.
6.2
Un ejemplo de anlisis sobre evolucin de la matrcula

Una de las temticas a abordar con la informacin contenida en el caso prctico es la
evolucin de la matrcula. En esta seccin se muestra como analizar las variaciones sobre la
cantidad de alumnos en los ltimos diez aos. Se comienza con una consulta general y se va
profundizando en sub-consultas sobre los casos ms llamativos. El ejemplo es a modo de gua,
pudindose retomar consultas intermedias y seguir analizando sobre otras alternativas.
En toda la seccin 6.2 se consideran slo las personas inscriptas en una nica carrera
para simplificar la interpretacin de los grficos y las consultas. Es decir que siempre se asume el
filtro de cantidad de carreras inscripto igual a uno en las consultas40.
Cantidad de alumnos por ao acadmico

Para comenzar se evala la cantidad de alumnos por cada ao acadmico41. Partiendo de
la vista inicial del cubo seleccionar la medida de cantidad de alumnos por ao acadmico (Cant
Alum X Ao c/Activ) y arrastrarla al grfico en el eje X, en lugar de Unidad Acadmica. Luego
reemplazar la dimensin Ao de Ingreso por Ao Informado y seleccionar los aos acadmicos
que resulten de inters, por ejemplo los ltimos diez.
40
Al filtrar a las personas inscriptas slo en una carrera coinciden la cantidad de alumnos con la cantidad de personas, el
ao de ingreso a la carrera con el ao de ingreso a la universidad y todos los datos agregados de totales de materias y
dems.
41
Se cuentan slo a los alumnos que presentan algn tipo de actividad, considerando como actividad el hecho de realizar
una inscripcin (sea a cursado, examen o carrera).
101
Figura 38. Cantidad de alumnos por ao acadmico en que presentan actividad, para los aos 1997-2006.
En el grfico de la figura 38 se puede observar que el crecimiento ms importante en la

matrcula ocurre en el ao 2000. Tambin se ve claramente un descenso importante en el ao
2006, el ltimo ao considerado para este cubo. Es muy importante que el analista de informacin
tenga en cuenta el contexto de los datos. En este caso ocurre que la informacin correspondiente
al ltimo ao no est completa, y ese es el motivo que explica la diferencia. Posiblemente lo ms
conveniente sea descartar este ao al hacer anlisis comparativos. Tambin al generar el cubo
habr que considerar si el ltimo ao acadmico ya est cerrado o no. Otra caracterstica
importante a tener en cuenta refiere a la migracin de datos. Puede ser que la poltica de
migracin de datos al SIU-Guaran no incluya la totalidad de datos antiguos, y por ejemplo quienes
ya hubiesen egresado al momento de implementar este sistema no se hayan migrado,
presentando as grandes diferencias en el volumen de la informacin y en el rendimiento de los
alumnos.
Retomando el ejemplo del grfico, se podra sospechar que la matrcula del ao 2000
presente un pico justificado por un incremento en la cantidad de ingresantes (por ejemplo
provocado por el inicio de una nueva carrera). Siguiendo esta hiptesis en la figura siguiente se
muestra la apertura de los alumnos segn el ao de ingreso a la carrera y se calcula el porcentaje
que representan los ingresantes sobre la totalidad de alumnos de cada ao acadmico.
Figura 39. Apertura de cantidad de alumnos por ao con actividad segn ao de ingreso a la carrera.
102
Porcentaje correspondiente a los ingresantes sobre el total de alumnos de cada ao acadmico.

En la grfica se observan dos ventanas con la misma vista para mostrar parte de los aos 1997-2000.
En la figura 39 para cada ao acadmico de la dimensin Ao Informado se calcul el

porcentaje correspondiente a los ingresantes. Se puede observar que este dato representa casi un
35% del total del alumnado en el ao 2000, mientras que en el resto de los aos se mantiene
alrededor de un 20%. La frmula utilizada para el clculo del porcentaje42 respeta la sintaxis
requerida por la herramienta y consiste en sumar los valores de ao de ingreso a la carrera
coincidentes con el ao informado y calcular el porcentaje sobre el total, para cada ao
acadmico. Por lo tanto en este caso se valida la hiptesis de que el incremento en la cantidad de
alumnos en el ao 2000 se debe a un aumento en la cantidad de ingresantes (y no de
reinscriptos).
Otra forma de visualizar esta informacin puede ser mediante la consulta de la figura
siguiente, donde se permite ver el cruce de todos los aos de forma ms compacta, facilitando la
comparacin.
Figura 40. Porcentaje de cada cohorte sobre el total de alumnos de cada ao acadmico.
El grfico se obtiene colocando la dimensin ao de ingreso como columna y utilizando la opcin desplegar porcentajes
por fila en lugar de utilizar una funcin calculada como es el caso de la figura anterior.
En la figura 40 se puede detectar una influencia importante de la cohorte 2000 en los aos
siguientes, en comparacin con las restantes.
Anlisis de ingresantes
Ahora se podra continuar el anlisis haciendo hincapi en los ingresantes y prestando
especial atencin a la cohorte 2000.
42
@Sum_i((Etiqueta([this.leaf(i)],"Ao Informado") == Etiqueta([this.leaf(i)],"Ao Ingreso"))? [this.leaf(i)] : 0)*100 /["Total"]
103
Sobre la vista inicial del cubo elegir la medida Cant Alumnos, y seleccionar para la
dimensin Ao Ingreso los valores que interese evaluar, por ejemplo de 1996 a 2006. Si hubiese
ms de una facultad se podra seleccionar una.
Siempre es importante seleccionar la medida adecuada para evitar confusiones posibles y
cruces de variables no vlidos. En las grficas siguientes se utiliza la medida Cant Alumnos, que
es diferente a la de las figuras anteriores, Cant Alum x Ao c/Activ, donde se reflejaba la relacin
muchos a muchos entre alumnos y aos acadmicos en que tienen actividad.
En la grfica de la figura 41 se observa que hubo un pico de ingresantes en el ao 2000
superando por ms del doble a los aos precedentes. La cantidad de alumnos que ingresaron a
las diferentes carreras cay notoriamente en los aos siguientes. Se observa que del ao 2000 en
adelante fue disminuyendo, presentando un descenso importante en el ao 2005.
Figura 41. Evolucin de ingresantes en los ltimos 11 aos para la facultad 1. Para el grfico se usaron las opciones de
lista de elementos para filtrar los valores de la dimensin Ao Ingreso, intercambiar ejes y mostrar valores43.
Se puede hacer la apertura por carrera dentro de esa facultad intentando explicar las
subas y bajas. Es necesario reemplazar la dimensin Unidad Acadmica por Carrera. La
grfica se muestra en modo tabla en la figura siguiente.
43
Los aos se muestran en el orden en que se los tilda, que se puede cambiar.
104
Figura 42. Comparacin de Ingresantes por cohorte y carrera.
De la figura 42, se observa que muchas carreras son despreciables en cuanto a la

cantidad que aportan al total de ingresantes. Tambin se observa que en el ao 2000 se abri la
inscripcin a la carrera 08 (anteriormente no tiene ingresantes) lo que en principio justifica el pico
de ingresos en ese ao.
En la figura 43 se muestra el grfico de barras comparativo de las tres carreras con mayor
cantidad de ingresantes en cada ao.
Figura 43. Evolucin de ingresantes de las carreras 07, 08 y 09.
105
Se podra corroborar que el incremento de ingresantes en el ao 2000 se debe al

comienzo de la carrera 08 seleccionando dicha carrera y consultando tambin el ao de egreso
del secundario de los ingresantes. Luego, calcular el porcentaje de alumnos correspondiente a
cada ao de egreso del secundario sobre el total de la cohorte, definiendo una frmula como la
mostrada en la figura 44.
Figura 44. Ingresantes a la carrera 08 segn ao de egreso del secundario, y frmula de porcentaje sobre total de
alumnos de la cohorte.
Observando los diferentes aos (figura 45) se puede ver que en general alrededor del 40%
de los ingresantes de cada cohorte finalizan el secundario el ao anterior al que comienzan la
carrera universitaria. En el ao 2000 los porcentajes son muy diferentes, la cantidad de alumnos
que terminaron el secundario en el ao 1998 es equivalente a aquellos que lo hicieron en 1999,
mientras que para los dems aos la relacin suele ser equivalente a la mitad.
106
Figura 45. Anlisis de ingresantes por cohorte y ao de egreso del secundario

para la carrera 08 y los aos 2005, 2004, 2001 y 2000.
Seguimiento de una cohorte

Puede resultar interesante seleccionar esa cohorte (ao de ingreso = 2000) y analizar qu
sucedi con esos ingresantes, particularmente evaluar y comparar a quienes egresaron del
secundario en 1998 y 1999. Se podra tener por ejemplo la sospecha que quienes esperaron un
ao para poder ingresar a la carrera estaran ms seguros y entusiasmados en su decisin de
estudiar; su rendimiento acadmico y su perseverancia podra superar a los ingresantes recin
salidos del secundario.
Una posible consulta a realizar es la apertura de estos alumnos segn el ltimo ao en
que registran actividad (inscripcin a cursado o examen en alguna materia de la carrera) y segn
si han egresado o no (usando la dimensin cantidad de carreras egresado).
El grfico de la figura 46 se obtiene seleccionando el valor 2000 en ao de ingreso, 1998
y 1999 en ao de egreso del secundario (usando la opcin de listas de elementos), cambiando
la ubicacin de la dimensin ao de egreso del secundario, para facilitar la comparacin, y
arrojando al grfico las dimensiones ltimo ao con actividad y cant carreras egresado.
107
Figura 46. Ingresantes a la carrera 08 de la cohorte 2000. Comparacin de alumnos que terminaron el secundario en
1998 vs. quienes lo hicieron en 1999, segn ltimo ao de actividad en la carrera y si egresaron o no.
Los casos que presentan ltimo ao con actividad en cero es porque nunca tuvieron
actividad en la carrera. Egresado hay slo un caso; se puede quitar ese nivel de detalle porque no
aporta informacin significativa. Tambin es interesante ver los porcentajes en lugar de los
nmeros (figura 47. Utilizar la opcin desplegar porcentajes en columnas dentro del men
Explorar).
Figura 47. Consulta de la figura 46 quitando apertura por cantidad de carreras en que egres y
desplegando porcentajes en las columnas.
Esta informacin puede visualizarse tambin de modo grfico. Para lograr mayor
legibilidad en la lectura es conveniente quitar las dimensiones que estn mostrando un nico valor
108
en el resultado (en este caso ao de ingreso y carrera) y tambin la fila totalizadora. En las
figuras 48 y 49 se aprecian diferentes visualizaciones de la misma consulta.
Figura 48. Comparacin en modo grfico de ingresantes a la carrera 08 en el ao 2000 segn si egresaron del
secundario en 1998 o 1999. Apertura segn ltimo ao con actividad. Vista de porcentajes sobre valores del eje X.
Figura 49. Diferentes visualizaciones grficas sobre la consulta de la figura 48. En el caso de los grficos de torta se
observa sobre la parte inferior del lateral derecho la dimensin que en la tabla apareca como columna.
De las figuras anteriores se puede concluir que la hiptesis planteada para estos casos
sobre la influencia del ao de egreso del secundario en la perseverancia en la carrera no sera
cierta, ya que en general quienes ingresaron en 1999 tienen actividad durante ms tiempo.
109
De todas formas para realizar un anlisis ms profundo habra que evaluar la calidad de la
actividad tenida. Tambin hay que tener en cuenta que los datos mostrados son ejemplos no
reales y es probable que muestren comportamientos que no sean ciertos.
En la figura 50 se muestran cuadros de comparacin entre los ingresantes del ao 2000 a
la carrera 08 que egresaron del secundario en los aos 1998 y 1999 segn algunas variables
totalizadoras de rendimiento acadmico. En el ejemplo se observa que en general quienes
egresaron del secundario en 1999 tienen mejor desempeo acadmico.
Figura 50. Ingresantes a la carrera 08 de la cohorte 2000. Comparacin de alumnos que egresaron
del secundario en el ao 1998 y 1999 segn totalizadores de cantidad de finales aprobados,
cantidad de cursados aprobados y cantidad de cursados promovidos.
6.3
Ejemplos de anlisis de procedencia

Otra temtica que resulta interesante analizar es la procedencia de los alumnos. La
procedencia se considera a partir del colegio secundario y presenta los niveles: localidad,
provincia y pas. En general interesa llegar al mximo detalle para encontrar la articulacin entre
los diferentes colegios secundarios y las carreras de la universidad.
110
En esta seccin se muestran algunos ejemplos interesantes y otras consultas ms

generales, que se utilizan para explicar funcionalidades de la herramienta y como gua para la
obtencin de otras nuevas.
Anlisis a nivel de pas y calidad de datos

En la figura 51 se observa el anlisis de procedencia a nivel de pas, para las cohortes
2000-2005, evaluando cantidad de personas y cantidad de alumnos. Para obtener el grfico,
partiendo de la vista inicial del cubo, es necesario: pasar al modo grilla, arrastrar las medidas al
grfico reemplazando la dimensin Unidad Acadmica, seleccionar la medida Cant Alumnos
(adems de la ya elegida por defecto), seleccionar los aos de ingresos deseados, arrojar la
dimensin Procedencia como parte de las filas y agregar los totales por ao.
Figura 51. Anlisis de procedencia a nivel pas para las cohortes 2000-2005 (considerando ao de ingreso a la universidad,
que es el nivel comparable por ambas medidas), comparando cantidad de personas con cantidad de alumnos.
La evaluacin de la procedencia se ve afectada por la mala calidad de los datos. El dato

de colegio est sin completar en muchos casos y en otros no est asociado a la localidad que le
corresponde. El porcentaje de datos sin completar, que puede apreciarse claramente en la figura
52, es mayor con el correr del tiempo. Esto es preocupante ya que en general la calidad de los
datos debiera tender a mejorar.
111
Figura 52.Visualizacin diferente de la informacin de la figura 51 cambiando la ubicacin

de las dimensiones y usando porcentajes por fila para resaltar la falta de completitud de los datos.
Exploracin de los niveles de la dimensin procedencia

Al seleccionar un valor de pas (por ejemplo haciendo clic sobre Argentina) se visualiza el
nivel siguiente en la jerarqua. Los valores de la dimensin conforman un rbol con diferentes
niveles. Se pueden consultar por ramas o por nivel, de a uno o ms elementos.
Figura 53. Anlisis de procedencia para pas Argentina de las cohortes 2000-2005. Apertura de provincias y localidades.
112
En la figura 53 se observan los valores de los niveles provincia y localidad

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

Consulta a nivel de colegio secundario para la localidad de SAN JUAN.
En la figura anterior se puede observar la existencia de comillas en la descripcin de los

colegios. Este es un problema menor de calidad de datos que habra que resolver, modificando las
descripciones en el sistema SIU-Guaran.
Articulacin de colegios y carreras

Es interesante conocer la relacin entre los colegios de procedencia de los alumnos y las
carreras que eligen. Para esto es necesario seleccionar la medida Cant Alumnos (ya que Cant
Personas queda indefinida a nivel de carrera y utilizar la dimensin Carrera como parte de la
consulta. Esto se muestra en la figura 55.
113
Figura 55. Apertura por carrera de alumnos correspondientes a las cohortes 2000-2005
procedentes de los diferentes colegios secundarios de la localidad de SAN JUAN.
Este mismo anlisis podra realizarse para todos los colegios de una provincia, por
ejemplo, usando las diferentes opciones avanzadas de exploracin de la dimensin Procedencia.
Tambin es posible tomar a la carrera como el punto de partida para el anlisis, para
investigar de donde provienen los alumnos de determinadas carreras. En la siguiente figura se
muestra el ranking de colegios secundarios para los ingresantes del ao 2005 a la carrera 10.
Figura 56. Procedencia de ingresantes 2005 a la carrera 10. Ranking de colegios secundarios.
114
Para obtener el grfico de la figura 56 se debe seleccionar la medida Cant Alumnos, la

carrera y el ao de ingreso. Respecto a la dimensin Procedencia se debe elegir la opcin de
Explorar nivel, seleccionar Colegio y luego Mostrar nivel y tildar todas las opciones que se
deseen visualizar. Por ltimo para mostrar ordenado en forma descendente se debe acceder a la
opcin Ranking dentro del men Explorar y elegir de ordenar la dimensin Procedencia por
criterio descendente segn la medida corriente.
Aperturas por las otras dimensiones tambin estn permitidas. Sexo, Edad, Cant
carreras inscripto-activo y todas las dimensiones referentes al rendimiento acadmico de esos
alumnos pueden resultar interesantes. La figura 57 muestra un cuadro que podra obtenerse
combinando totales de cursados promovidos y finales aprobados. Se utiliza una regla para
sealizar los valores diferentes a cero, para facilitar el anlisis44.
Figura 57. Posible anlisis de rendimiento acadmico de los alumnos discriminado por colegio de procedencia.
A partir de la figura 56 se incorporan las dimensiones Cursados Promovidos y Finales Aprobados en su nivel ms alto.
Se visualiza slo el nivel Colegio en la dimensin Procedencia y se utiliza la opcin de desplegar porcentajes por fila.
Anlisis similares pueden realizarse eligiendo algn colegio y consultando en qu carreras

influye, comparando la procedencia en los diferentes aos, etc. Tambin es posible comparar el
rendimiento acadmico de los alumnos, principalmente durante el primer ao de la carrera y
relacionarlo con el colegio del que provienen. Puede ser que determinados colegios con formacin
ms afn respecto a la carrera tengan una influencia positiva en el rendimiento acadmico de los
alumnos, o que no resulte lo esperado.
44
La definicin de reglas con O3 queda fuera del alcance de esta tesis. Consultar la documentacin de la herramienta.
115
6.4
Un ejemplo de desgranamiento basado en la actividad acadmica y

rendimiento
El desgranamiento generalmente es evaluado por cohortes. Este anlisis comienza a partir
de los individuos, el ao de ingreso a la universidad y se realiza un seguimiento de los aos en

que han tenido actividad. En este caso se inicia la exploracin a nivel de personas y no a nivel de
alumno. Luego se desgrana la informacin por alumno.
ltimo ao con actividad

El cuadro de la figura 58 muestra el ao de ingreso y el ltimo ao con actividad para la
medida Cant Personas. Se puede observar que hay una cantidad importante de inscriptos que no
tienen actividad acadmica en ningn ao, reflejados por ltimo ao con actividad igual a cero.
Figura 58. Cantidad de personas por ao de ingreso, discriminados segn el ltimo ao de actividad.
Los subtotales muestran la cantidad de personas que ingresaron a la universidad en cada ao.
La misma informacin puede visualizarse de otra manera en la figura siguiente, en

cantidades absolutas y tambin en porcentajes sobre el total de cada cohorte45.
45
Se utiliza el trmino cohorte para referirse al ao de ingreso, a la universidad, o a la carrera. Aunque en general el uso
ms comn es el segundo ambos son aceptables. Adems, la mayora de las personas se inscriben slo a una carrera, por
lo tanto los valores suelen ser coincidentes.
116
Figura 59. Cantidad de personas por ao de ingreso y ao de ltima actividad,

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

Apertura por Cant carreras inscripto y Ao de Ingreso, a la universidad y a la carrera.
Cuadros similares a los de la seccin 6.4.1 podran armarse eligiendo cantidad de

alumnos por ultimo ao de actividad en la universidad y tambin por ltimo ao de actividad en la
carrera. En la figura 61 se muestra la apertura de ambas medidas segn el ao de ingreso a la
universidad y el ltimo ao con actividad en esta.
Figura 61. Cant Personas y Cant Alumnos segn Ao Ingreso a la universidad y
118
ltimo ao con actividad en la universidad
Actividad anual de las cohortes

Adems de la apertura por ltimo ao con actividad es interesante evaluar la actividad en
cada ao. Eso es posible consultando la cantidad de alumnos por ao acadmico en que realizan
alguna actividad y comparando el valor con la cantidad de alumnos. Para esto es necesario utilizar
la medida Cant Alum X Ao c/Activ que cuenta a cada alumno tantas veces como aos en los
cuales realiza alguna actividad acadmica, y realizar la apertura por la dimensin Ao Informado.
Los valores mostrados en la figura 62 deben ser analizados en funcin de la cantidad de alumnos
mostrada en la figura 61, Por ejemplo: de los 12 alumnos (correspondientes a 10 personas) que
ingresaron en 1994 y tuvieron actividad por ltima vez en el ao 2001 (fila 9 de la figura 61), 10 de
ellos tuvieron actividad acadmica en 1994, 1995, 1996 y 2001, equivalentes al primer, segundo,
tercer y octavo ao de las carreras, respectivamente. 9 de ellos tuvieron actividad durante los aos
1997, 1998 y 1999, y slo 7 tuvieron actividad en el ao 2000 (filas 3 a 10 del cuadro de la
derecha de la figura 62).
Figura 62. Alumnos por ao acadmico en que presentan actividad. Apertura por ao de ingreso a la universidad
y ltimo ao con actividad. Contrastar con la cantidad de alumnos de la figura 61.
Resulta interesante calcular el porcentaje de alumnos de cada cohorte que tienen

actividad en cada ao acadmico. La figura 63 se logra a partir de la anterior, quitando la
dimensin ltimo ao con actividad y filtrando algunos valores de Ao Informado para obtener
un grfico ms simple. La medida Cant Alumnos est indefinida por Ao Informado, por eso
muestra siempre el total de alumnos de cada ao de ingreso46.
46
Es intencional y es la forma que presenta O3 para permitir la comparacin de estas medidas por Ao Informado.
Hay otras formas de obtener el dato del porcentaje a partir de otras vistas que requieren frmulas de clculo o diseo del
modelo ms complejos.
119
Figura 63. Porcentaje de alumnos con actividad calculado sobre el total de ingresantes de la cohorte.
Seguimiento de una cohorte

Se puede seguir profundizando en conjunto o seleccionar una cohorte que resulte de
inters, por ejemplo la cohorte 1997 que al ao 2006 lleva 10 aos dentro de la universidad y tiene
un total de 380 ingresantes (observar en figura 60, total de Cant Alumnos con ao de ingreso a la
universidad 2007 o total de figura 65)47.
Figura 64. Cantidad de alumnos de la cohorte 1997 que tienen actividad en cada ao acadmico.
47
Se considera como cohorte al ao de ingreso a la universidad para que los ejemplos sean ms sencillos. Tambin podra
tomarse el ao de ingreso a la carrera. Incluso si resultara complejo seleccionar los valores podra modelarse el ao de
ingreso a la carrera como una dimensin independiente.
120
La actividad anual de los 380 ingresantes puede verse en el grfico de la figura 64. Es
muy interesante observar como en este caso se va perdiendo la cantidad de alumnos a medida
que pasan los aos. Esto puede deberse a diferentes motivos: que abandonan sus estudios, que
se cambian de carrera, o que egresan.
Se puede discriminar a estos alumnos por otras variables para estudiar la cohorte en
detalle. En la figura 65 se observa el total de alumnos de la cohorte 1997 segn el ltimo ao en
que realizan actividad acadmica en la carrera y en la universidad y su calidad de egresados.
Sobre el total de 380 ingresantes 10 son egresados en alguna carrera y 129 nunca tuvieron
actividad en la carrera (se obtiene sumando todos los casos con ltimo ao con actividad en la
carrera igual a cero), de los cuales 116 no tuvieron actividad en ninguna carrera, los otros 13 s.
Figura 65. Cantidad de alumnos de la cohorte 1997 segn ltimo ao con actividad (en la universidad y en la carrera) y
su calidad de egresado (dado por el valor de cantidad de carreras egresado igual a uno)
121
Figura 66. Cantidad de alumnos y de personas que ingresaron en 1997 discriminadas por ltimo ao en que registran
actividad (en la universidad solamente para simplicidad del grfico), cantidad de carreras en que se encuentra activo /
cantidad de carreras en que se inscribi y cantidad de carreras en que egres.
Para evaluar el movimiento a otras carreras se puede comparar la cantidad de alumnos

con la cantidad de personas y discriminar ambas medidas por la cantidad de carreras en la que se
encuentra activo el individuo.
El cuadro de la figura 66 resulta complejo a simple vista. Si se lee por partes:
-
Existen 8 personas que se inscribieron slo a una carrera (corresponden a 8 alumnos) y

no estn activos, todos ellos son egresados (observar la primera columna para Cant
Alumnos y para Cant Personas).
La mayora de los casos estn inscriptos, activos y no egresados en slo una carrera. Se
trata de 290 alumnos (que son 290 personas).
Hay una persona que se inscribi a dos carreras y est activo en una y egresado en una
(tercera columna en ambos casos. En la figura 67 se ven ms detalles de este caso).
Para los casos restantes, que estn activos e inscriptos en ms de una carrera (2/2 y 3/3),
en la grilla slo se muestran los aos de ingreso a las carreras, sera interesante realizar la
apertura por carrera y por ltimo ao de actividad en la carrera para continuar la
evaluacin.
La misma apertura por cantidad de carreras activo y cantidad de carreras donde egres se
puede realizar sobre la figura 64, para evaluar la actividad anual de los alumnos teniendo en
cuenta esos criterios.
Figura 67. Cantidad de alumnos de la cohorte 1997 segn ao acadmico en que registran actividad discriminados por
cantidad de carreras en que se encuentra activo/cantidad de carreras inscripto y cantidad de carreras en que egres.
Y se puede visualizar por carrera para ver donde se producen las simultaneidades.
122
Figura 68. Comparacin de alumnos con actividad por ao, alumnos y personas correspondientes al ao de ingreso a la
universidad 1997, segn cantidad de carreras en que est activo/cantidad de carreras inscripto, cantidad de carreras en
que es egresado y carrera en los casos correspondientes.
Es vlido comparar la cantidad de alumnos con actividad con la cantidad de alumnos total
y la cantidad de personas, y sobre esa base realizar filtros para profundizar el anlisis. Por
ejemplo, si focalizamos sobre quienes egresaron en alguna carrera podemos obtener el cuadro de
la figura 69 donde se observan ms detalles sobre su condicin de alumnos (ao de ingreso a la
carrera, ltimo ao de actividad en la carrera). Observar que totalizan 10 alumnos, pero egresados
son 9, ya que existe una persona que se inscribi en dos carreras pero slo egres en una de
ellas. Este individuo comienza la carrera 07 en 1997 y la deja ese mismo ao, y en el 2000
comienza la carrera 08, en la que tuvo actividad por ltima vez en el ao 2005, lo que indicara que
es la carrera en la que egres. Los otros casos estaran egresando en 2005 y 2006 (que es
cuando registran actividad por ltima vez) en sus respectivas carreras. Si se deseara hacer un
anlisis ms profundo sobre los egresados habra que utilizar algunas otras variables no incluidas
en el Data Mart.
Respecto a los alumnos activos en ms de una carrera, observando en detalle la parte
derecha de figura 68 se puede concluir que, para esta cohorte, no es muy comn el comienzo de
dos carreras en paralelo: de las 40 personas en cuestin (total de inscriptos en 2 y 3 carreras 1+37+2 en cuadro inferior derecho-) slo 4 comienzan dos carreras en simultneo (20+21=41
alumnos filas 7 a 9 de la columna 4 en cuadro superior derecho- que corresponden a 37
personas columna 4 en cuadro inferior derecho-). En general comienzan la otra carrera despus,
sea de grado o postgrado (observar los valores de ao de ingreso a carrera para estos casos).
123
Figura 69. Anlisis de los alumnos que ingresaron a la universidad en 1997 y egresaron en alguna carrera.
Seguimiento de subconjunto mayoritario de una cohorte. Anlisis por carrera y

rendimiento
Los casos de egresados y simultaneidad de carreras vistos recientemente podran ser
descartados del anlisis, ya que no representan a la mayora de los casos. Se opta por elegir los
alumnos que estn inscriptos y activos slo en una carrera y que an no han egresado para
continuar el desgranamiento segn el rendimiento acadmico. Sobre esos casos pretende realizar
un anlisis comparativo por carrera. Tambin se descarta a los alumnos de carreras de postgrado
porque, adems de ser pocos casos, son muy particulares y la evaluacin de desgranamiento
sera diferente.
Figura 70. Alumnos de la cohorte 1997 activos en slo una carrera y no egresados. Cantidad total (grfico inferior derecho)
y cantidad discriminada por ao en que tienen actividad acadmica. Slo se consideran las carreras de grado.
El mismo anlisis puede hacerse seleccionando ms de una cohorte. En la figura siguiente

se muestran, adems de la cohorte 1997, la anterior y la siguiente para realizar la comparacin.
124
Figura 71. Cuadro principal: actividad anual de las cohortes 1996-1998,

considerando alumnos inscriptos y activos en una carrera y no egresados para carreras de grado.
Derecha: total de alumnos de las cohortes 1996-1998 con las mismas restricciones.
A partir de estos cuadros se pueden hacer anlisis ms intensivos para profundizar en el

desgranamiento, por ejemplo utilizando variables de rendimiento acadmico como la cantidad de
cursados o finales aprobados. En la figura 72 se aprecia la apertura de estos alumnos segn el
total de cursados aprobados en la carrera.
Figura 72. Alumnos de carreras de grado de las cohortes 1996-1998 inscriptos y activos en una carrera y no egresados,
segn total de cursados aprobados en la carrera.
125
En la figura 73 se ve el detalle de cursados aprobados por ao acadmico de un

subconjunto de estos alumnos. Para el grfico se selecciona la cohorte 1997 y la carrera 10, y se
muestra el desglose del total de cursados aprobados acumulados en la carrera por cada ao en
que los alumnos tienen actividad.
Figura 73. Detalle de cursados aprobados por ao acadmico y total de cursados aprobados en la carrera
de los alumnos de la cohorte 1997 activos slo en carrera 1048.
El anlisis completo debiera contemplar varias de estas dimensiones y utilizarlas en forma

combinada, calculando por ejemplo el total de cursados regularizados (cursados aprobados ms
cursados promovidos) o el total de materias aprobadas (finales aprobados ms cursados
promovidos).
La intencin de estos ejemplos es presentar la potencialidad de la solucin. Se deja en
manos del lector la exploracin de las posibles consultas, y frmulas que puedan obtenerse y
agregarse segn las propias necesidades.
48
Tener en cuenta que los cursados promovidos se cuentan como tales y no como aprobados. Ese es el motivo de que las
cantidades sean nmeros pequeos.
126
Captulo 7 - Conclusiones y trabajo futuro
Conclusiones y trabajo futuro
7.1
Conclusiones
La implementacin de soluciones para analizar informacin como la presentada en este
trabajo genera muchos beneficios. Entre los ms importantes se destacan los siguientes:
-
El acceso a los datos es fcil y rpido y permite a los usuarios hacer sus propias
consultas. Tambin se logra independencia del personal tcnico para la obtencin de
nuevos reportes.
La informacin se obtiene de manera sencilla y a travs de imgenes integradas de los

datos.
Facilita el proceso de comparacin, proyeccin a futuro, relacin con otros datos, muestra
de indicadores, informacin consolidada, etc.
Ayuda a mejorar el buen funcionamiento de los sistemas de gestin retroalimentando

demandas para estos.
Lograr la implementacin y el uso real de los sistemas para el soporte de decisiones no es
una tarea sencilla y generalmente requiere enfrentar varios problemas. La mayora de los
problemas surgen en cualquier proyecto de Data Warehousing, otros son propios de la realidad del
mbito universitario o de la administracin pblica. Algunos de los ms frecuentes son:
-
Infravaloracin del esfuerzo necesario para el diseo y la creacin de un DW.
Infravaloracin de los recursos necesarios para la extraccin, transformacin, carga y

almacenamiento de los datos.
Incremento continuo de los requisitos de los usuarios una vez que las soluciones son
implementadas exitosamente.
Privacidad de los datos.
Calidad de los datos. Los datos deben ser confiables, y estar disponibles y completos,
para que puedan ser utilizados.
Carencia de RRHH involucrados en el proyecto que colaboren en la puesta en marcha. Se

requiere:
Una autoridad o usuario sponsor que empuje internamente el proyecto de

DW y designe un equipo de trabajo.
Usuarios capacitados en las herramientas que utilicen las soluciones y

demanden nuevas consultas promoviendo su uso y evolucin.
Recursos humanos que puedan mantener y hacer evolucionar todo el

sistema para anlisis de informacin.
127
Apoyo tcnico del rea de sistemas.
Existencia o adquisicin del hardware necesario.

La incorporacin de este tipo de soluciones dentro del mbito universitario ha permitido:
Mostrar el potencial de estas herramientas y de los datos producidos por los sistemas de
gestin.
Impulsar el uso de la informacin como una herramienta para la toma de decisiones y la

planificacin.
Profundizar el trabajo sobre la calidad de los datos en su origen, que es la clave del xito
de un proyecto de DW.
Construir los cimientos de un profundo cambio cultural.

En sntesis y como conclusin del presente trabajo se puede decir que estas herramientas
convierten datos crudos en informacin valiosa y ayudan a los directivos a tomar decisiones.
Permiten lograr una visin ms completa e integral de la organizacin, entender los eventos en
forma sistemtica, para as redefinir estrategias. El resultado de su implementacin es
conocimiento acerca del funcionamiento de la organizacin.
7.2
Trabajo futuro
Son muchas las cosas por hacer an, desde lo tcnico hasta la promocin y motivacin
para lograr el uso real en la toma de decisiones, pasando por la definicin de criterios sobre
consideraciones de los datos.
Desde el punto de vista tcnico y funcional, se podran incorporar modificaciones a las
soluciones actuales o desarrollar nuevos componentes dentro de la totalidad del sistema para
anlisis de informacin. Las siguientes son algunas de las posibles modificaciones a considerar:
-
Modelar algunos datos de forma diferente en el cubo propuesto para permitir la obtencin
de otros reportes. Ejemplos:
Se podran incorporar como medidas a las actuales dimensiones de

rendimiento acadmico (cursados aprobados, cursados desaprobados, etc.). De esta
forma se permitira fcilmente totalizar las materias regularizadas (cursados
aprobados ms cursados promovidos) y las materias aprobadas (cursados
promovidos ms finales aprobados).
Definir niveles de actividad para combinar los valores de las dimensiones

finales aprobados, finales desaprobados, cursados aprobados, etc. en una o ms
dimensiones sintetizadoras.
Esta es una tarea compleja en algunos casos porque puede depender mucho de la
carrera que se analice y su plan de estudio.
128
Separar alguna de las dimensiones actuales (por ejemplo cohorte) si es
conveniente para los usuarios.

-
Incorporar nuevos datos o niveles ms detallados de datos existentes. Ejemplos:

Agregar al modelo algunas de las dimensiones que forman parte de los
archivos de texto, por ejemplo: duracin del plan, calidad del alumno, promedio, etc.
Incluir el dato de materia en relacin con el alumno para poder detectar en
que materias se presentan los mayores problemas de desaprobacin de

determinado conjunto de alumnos.
Incorporar mayor cantidad de datos sobre egresados.
Incluir informacin del contexto socio econmico de los alumnos.

Esto requiere que los datos respectivos (condicin laboral del alumno, estudios de
los padres, composicin del grupo familiar, situacin econmica del grupo familiar,
etc.) estn completos y sean de buena calidad. Por otro lado se requiere definir la
forma de unirlos con la informacin acadmica (establecer una correspondencia
entre las diferentes fechas en que los datos censales son relevados y los perodos
del ao acadmico donde debieran ser considerados).
Incorporacin de datos derivados como movilidad, simultaneidad de
carreras y lentificacin, previa definicin de estos.

La informacin existente en los cubos actuales podra ser de utilidad para definir
alguno de estos indicadores.
-
Desarrollar modelos de anlisis sobre nuevas temticas. Por ejemplo incorporacin de

materias por crditos o puntos que aportan, y posicionamiento de los alumnos en el plan
de estudio.
Crear un DW en la universidad con la informacin proveniente del SIU-Guaran.

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

Al momento de comenzar el trabajo en esta tesis no haba herramientas de software libre
con la madurez de desarrollo ni la difusin actual. Adems en la UNS y en
aproximadamente en otras quince Universidades Nacionales ya se estaba utilizando O3.
129
Se espera que este trabajo sea un aporte para el anlisis de la problemtica universitaria
en cuestin y que la base terica y el aporte de la experiencia personal contribuyan al crecimiento
de las soluciones actuales y al desarrollo de nuevas propuestas.
130
Captulo 8 Apndice. Documentacin tcnica del caso de estudio
Apndice. Documentacin tcnica del caso de estudio
8.1
Descripcin tcnica de las variables del cubo
Dimensiones
Nombre
Unidad acadmica
Ao Ingreso
(Ao Ingreso a la
Universidad
Ao Ingreso a la
Carrera)
Ao Informado
ltimo ao con
actividad
(ltimo ao con
actividad en la
Universidad
ltimo ao con
actividad en la Carrera)
Edad
(Edad al Ingreso
Universidad
Edad al Ingreso
Carrera
Edad al Ao
Informado)
Descripcin
Unidad acadmica a la
que corresponde el
alumno o persona.
Forma de clculo
Este dato corresponde a los campos
sga_personas.unidad_academica y
sga_alumnos.unidad_academica. Tambin
forma parte de la clave primaria de muchas de
las tablas y se utiliza para realizar las uniones.
En el primer nivel se
Para cada alumno se recupera el ao de
muestra el ao en que
ingreso mediante el proceso
cada persona ingresa a sp_int_arau_dating (que se utiliza para
la universidad, a la
informar a araucano). El dato corresponde al
primera carrera de la
ao acadmico en que se inscribe a la carrera
cual se tiene registro
y resulta ingresante o alumno condicional:
como alumno en la base sga_periodo_insc.anio_academico tomando
de datos del SIUcomo nexo el periodo de inscripcin de
Guaran.
sga_carrera_aspira.periodo_inscripcio. (donde
A nivel de alumno se
se busca el registro como aspirante
muestra el ao de
correspondiente a cada alumno)
ingreso a cada carrera. En caso que este registro no exista se
completa con el ao de la fecha en que se
gener el legajo del alumno
(sga_alumnos.fecha_ingreso).
A nivel de persona se considera el mnimo
valor de los aos de ingreso a las diferentes
carreras.
Ao acadmico en que Se toma de cada una de las tablas de actividad
se efecta la actividad
consideradas, segn lo que se est contando.
de los alumnos.
Para cursados y promociones:
sga_comisiones.anio_academico
Para finales:
sga_actas_examen.anio_academico
Y para las equivalencias, se toma el ao
acadmico correspondiente a
sga_equiv_otorgada.fecha (se verifica que esa
fecha est entre
sga_anio_academico.fecha_inicio y
sga_anio_academico.fecha_fin)
Indica el ltimo ao en
Se calcula a partir de los aos acadmicos en
que las personas o
que los alumnos registran actividad (valores de
alumnos tienen
la dimensin Ao Informado). A nivel de
actividad, a nivel de
alumno se toma el mximo valor encontrado
toda la universidad o de por carrera, y a nivel de persona se calcula el
cada carrera.
mximo de estos.
Edad de los individuos
en cada ao
considerado, al ltimo
da del ao calendario
(31/12)
Se calculan a partir de la fecha de nacimiento

de las personas
(sga_personas.fecha_nacimiento)
Para la edad al ao de ingreso a la
universidad, se le resta al ao de ingreso a la
universidad el ao de nacimiento de la
persona. Lo mismo se realiza para los aos de
ingreso a carrera y los diferentes aos
131
Sexo
Gnero de los
individuos.
Nacionalidad
Nacionalidad de los
individuos
Procedencia
Colegio secundario del
(Pas
que egres el
Provincia
estudiante.
Localidad
Localidad asociada al
Colegio)
colegio. Provincia a la
que corresponde dicha
localidad.
Pas al que corresponde
la provincia.
Ttulo Secundario
Ttulo del colegio
secundario obtenido por
cada individuo
Ao Egreso Sec
Ao de egreso del
secundario
Orient vocacional
Indica si la persona
recibi o no orientacin
vocacional.
Cant carreras inscripto Cantidad de carreras
activo
diferentes en que se
(Cant carreras inscripto inscribi cada persona y
Cant carreras
la cantidad en que est
activo/inscripto)
activa. Se muestran dos
niveles: el superior
indica la cantidad de
inscripciones y el otro
en cuntas est activo
sobre el total de
inscripciones
Cant carreras
Cantidad de carreras en
egresado
que la persona registra
calidad de egresado.
Carrera
Carrera asociada al
alumno.
Cursados Aprobados
(Cursados Aprobados
Totales por Persona
Cursados Aprobados
Totales en la Carrera
Cursados
Aprobados en la
Carrera y Ao
Informado)
Cursados
Desaprobados
(Cursados
Desaprobados Totales
por Persona
Cursados
Desaprobados Totales
en la Carrera
Cantidad de cursados
aprobados registrados
en actas cerradas, para
cada ao acadmico,
totales por carrera, y
sumatoria de todas las
carreras.
desaprobados
registrados en actas
cerradas, para cada ao
acadmico, totales por
carrera, y sumatoria de
todas las carreras.
informados.
Corresponde al campo sga_personas.sexo.
Corresponde al campo
sga_personas.nacionalidad.
Colegio secundario del que egres la persona
(sga_personas.colegio_secundario). Se
considera la Localidad asociada al colegio
secundario (sga_coleg_sec.localidad).
Luego se toman la provincia y el pas que
correspondan a la localidad utilizando las
tablas mug_localidades, mug_dptos_partidos,
mug_provincias y mug_paises.
sga_personas.titulo_secundario
sga_personas.anio_egreso_sec
sga_personas.orient_voc_rec
Las carreras activas se calculan contando la
cantidad de registros en sga_alumnos con
calidad activa (sga_alumnos.calidad=A)
agrupando por persona (unidad acadmica y
nmero de inscripcin).
La cantidad de carreras en que se inscribi, o
aspir a ser alumno, se toman de la tabla
sga_carrera_aspira, contando los distintos
valores de sga_carrera_aspira.carrera
La cantidad de carreras en que egres se
calcula contando la cantidad de registros en
sga_alumnos con calidad egresado
(sga_alumnos.calidad=E) agrupando por
persona (unidad acadmica y nmero de
inscripcin).
Corresponde al campo sga_alumnos.carrera.
Este campo tambin se utiliza al calcular la
actividad, formando parte de la unin entre la
tabla de alumnos y las de cursados, exmenes
y equivalencias.
Se cuentan los registros en actas de cursado
cerradas con resultado aprobado (A) para
cada ao acadmico y alumno (mediante la
unin de las tablas: sga_det_acta_curs,
sga_actas_cursado, sga_comisiones y
sga_periodos_lect).
Luego se sumarizan por alumno, para el nivel
carrera, y por persona.
cerradas con resultado desaprobado (R) para
sga_periodos_lect).
132
Cursados
Desaprobados en la
Carrera y Ao
Informado)
Cursados Promovidos
(Cursados Promovidos
Totales por Persona
Cursados Promovidos
Cursados
Promovidos en la
Carrera y Ao
Informado)
Finales Aprobados
(Finales Aprobados
Totales por Persona
Finales Aprobados
Finales Aprobados
en la Carrera y Ao
Informado)
(Finales Desaprobados
Totales por Persona
Finales
Desaprobados en la
Carrera y Ao
Informado)
(Equivalencias
Externas Totales por
Persona
Equivalencias
Externas en la Carrera
y Ao Informado)
promovidos registrados
en actas de cursado
todas las carreras.

cerradas con resultado promovido (P) para
sga_periodos_lect).
Cantidad de exmenes
finales aprobados
todas las carreras.
Se cuentan los registros, no rectificados, en

actas de examen cerradas con resultado
aprobado (A) para cada ao acadmico y
alumno (mediante la unin de las tablas:
sga_detalle_acta y sga_actas_examen).
Cantidad de exmenes
finales desaprobados
todas las carreras.
Se cuentan los registros, no rectificados, en

actas de examen cerradas con resultado
desaprobado (R) para cada ao acadmico y
alumno (mediante la unin de las tablas:
sga_detalle_acta y sga_actas_examen).
Cantidad de
equivalencias totales
otorgadas (con origen
externo o de pase), para
cada ao acadmico,
totales por carrera, y
sumatoria de todas las
carreras.
Se cuentan los registros, no rectificados y

activos, en actas de equivalencia con resultado
aprobado (A) con alcance total (T) y de
origen externo o pase (E y P) para cada ao
acadmico y alumno (mediante la unin de las
tablas: sga_equiv_otorgada y
sga_equiv_operac).
El ao acadmico se determina a partir de la
fecha de la equivalencia
(sga_equiv_otorgada.fecha), controlando que
esta se encuentre entre
sga_anio_academico.fecha_inicio y
sga_anio_academico.fecha_fin.
Medidas
Nombre
Cant
Personas
Cant
Alumnos
Cant Alum X
Ao c/Activ
Descripcin
Cantidad de personas registradas en la
base de datos del SIU-Guaran.
Cantidad de alumnos registrados en la
base de datos del SIU-Guaran.
Cantidad de registros resultante de
contar a cada alumno en cada ao
acadmico en que registra actividad.
Se consideran como actividad: registros
en actas de cursado, actas de examen y
actas de equivalencias otorgadas totales
o parciales (con origen E o P). Slo se
Forma de clculo
Se cuentan todos los registros existentes
en la tabla sga_personas.
Se cuentan todos los registros existentes
en la tabla sga_alumnos.
Para cada alumno y cada ao acadmico
a partir del ao de ingreso a la carrera
(calculado con sp_int_arau_dating) se
recorren las tablas:
- de cursado (sga_det_acta_curs,
sga_actas_cursado, sga_comisiones,
sga_periodos_lect), contando aprobados,
133
consideran actas cerradas y registros

que no estn rectificados (cualquiera sea
el resultado: aprobado, desaprobado,
promovido y ausente, porque el hecho de
inscribirse se lo considera actividad, o al
menos intencin de tenerla).
Se busca actividad a partir del ao de
ingreso a la carrera hasta la fecha
corriente.
desaprobados, promocionados y
ausentes
- de exmenes (sga_detalle_acta,
sga_actas_examen), contando
aprobados, desaprobados y ausentes
- y de equivalencias otorgadas
(sga_equiv_otorgada, sga_equiv_operac)
contando equivalencias totales y
parciales con origen E o P.
Si alguna de estas cuentas es diferente a
cero se cuenta al alumno dentro del ao
acadmico correspondiente.
Para mayor detalle consultar las consultas SQL de los procesos de extraccin de datos y
las definiciones de campos virtuales dentro del modelo de O3 que se adjuntan.
Los cruces entre las medidas y los niveles de las dimensiones no permitidos no se
especifican aqu porque se encuentran en la figura 18 de la seccin 5.3.
8.2
Consideraciones especiales
Algunas particularidades del caso de estudio deben ser tenidas en cuenta. Entre ellas:
-
El siguiente trabajo est basado en informacin contenida en tablas generales de la

versin 2.3 o posterior del sistema SIU-Guaran. No contiene informacin proveniente de
las personalizaciones del SIU-Guaran que ha realizado la UNS con el objeto de que los
desarrollos puedan utilizarse en el resto de las UUNN.
Las definiciones y criterios asumidos (detallados en la seccin 8.1) podran modificarse o

personalizarse para contemplar los cambios que sean de utilidad.
La construccin del cubo debe ser de tipo FULL. Esto significa que no se incorporan datos
a un cubo existente sino que se debe generar un cubo nuevo.
Debe determinarse una poltica de actualizacin del cubo acorde a los momentos en que
se necesita informacin y en que se dispone de datos estables.
Tener en cuenta que si los datos que se incorporan al Data Mart no son estables podrn
surgir variaciones luego. Por ejemplo, en la cantidad de ingresantes, (si no finaliz el
perodo de inscripcin a carreras en el momento en que se genera el cubo) y en las
variables totalizadoras de actividad (si no estn ingresadas y cerradas todas las actas al
sistema).
Algunas de estas variaciones pueden parecer inconsistentes, como podra ser el caso de
los alumnos condicionales que son contados como ingresantes; si en algn momento
estos fueran rechazados en el sistema de gestin al regenerarse el cubo la cantidad de
ingresantes ser menor.
134
8.3
Estructuras de los archivos de texto
Tabla: int_dw_personas.txt
Campos
Cdigo de unidad acadmica
Nmero de Inscripcin
Tipo de documento
Nmero de documento
Cdigo de sexo
Fecha de Nacimiento
Cdigo de nacionalidad
Cdigo de colegio secundario
Cdigo de Ttulo del secundario
Ao de egreso del secundario
Cdigo de si recibi orientacin vocacional o no
Cantidad de carreras en que se encuentra activa la persona
Cantidad de carreras en que egres la persona
Cantidad de carreras en que se inscribi la persona
Cantidad total de readmisiones de la persona
Ao de Ingreso a la Universidad
ltimo ao en que tiene actividad en la universidad
Total de cursados aprobados de la persona
Total de cursados desaprobados de la persona
Total de cursados promovidos de la persona
Total de cursados ausentes de la persona
Total de finales aprobados de la persona
Total de finales desaprobados de la persona
Total de finales ausentes de la persona
Total de equivalencias externas de la persona
Total de equivalencias parciales de la persona
Cantidad de Personas
Tipo de dato
Texto
Texto
Texto
Texto
Texto
Fecha. MM/DD/AAAA
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico. Es siempre 1.
Tabla: int_dw_alumnos.txt
Campos
Cdigo de carrera
Nmero de Legajo
Cdigo del plan de estudio actual del alumno
Nmero de Inscripcin
Cdigo de condicin de regularidad del alumno en la carrera
Cantidad de readmisiones en la carrera
Cdigo de calidad del alumno (activo, pasivo, egresado, de baja)
Ao de Ingreso a la carrera
Cantidad de veces que realiz cambios de plan en la carrera
Cantidad de veces que intent ingresar a la carrera
Promedio del alumno en la carrera
Duracin terica del plan en aos
Cantidad de materias del plan
Cantidad de materias optativas del plan
Estado del plan (vigente, activo, etc.)
ltimo ao en que tiene actividad en la carrera
Total de cursados aprobados en la carrera
Total de cursados desaprobados en la carrera
Total de cursados promovidos en la carrera
Total de cursados ausentes en la carrera
Tipo de dato
Texto
Texto
Texto
Texto
Texto
Texto (S/N)
Numrico
Texto (A/P/E/N)
Numrico
Numrico
Numrico
Numrico con decimales
Numrico
Numrico
Numrico
Texto
Numrico
Numrico
Numrico
Numrico
Numrico
135
Total de finales aprobados en la carrera

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

Para utilizar la solucin propuesta se requiere:
-
Tener instalada la herramienta O3

Se utiliza la versin 4.3 de este software49. Si no estuviese instalada en la universidad se
puede bajar una versin de evaluacin por treinta das de www.ideasoft.com.uy en la
seccin descargas.
Para utilizar el cubo ser necesario tener instalado el componente O3 Browser, o utilizar la
interfaz web. Para generar el cubo se requiere el componente O3 Builder.
Generar los datos desde el SIU-Guaran.

Se requiere que se est utilizando la versin 2.3 o posteriores de SIU-Guaran. Se prob
sobre versin 2.5.2.
Los procesos a correr no han sido an incorporados al cdigo ncleo del SIU-Guaran. Se
adjuntan a este trabajo y deben ejecutarse manualmente sobre la base de datos, en el
orden indicado.
Es necesario tener actualizada la corrida de los procesos que generan datos para el SIUAraucano ya que se utilizan tablas de interfaz entre ambos sistemas que es necesario
tener completadas. Como parte de lo entregado, en 0_ejecucion de procesos_act_datos_
araucano.sql se listan los procesos de la interfaz con SIU-Araucano que sera necesario
49
Al momento de presentar la tesis ya ha sido lanzada la versin 5 de O3. Esta solucin es perfectamente compatible.
137
ejecutar para generar un cubo con informacin de 1994 a 2007. Puede utilizarse de
ejemplo tomando slo lo que necesite.
Luego deben ejecutarse los otros archivos en el orden en que estn numerados. En el
ltimo de ellos 7_generacion_txt.sql puede modificarse el directorio destino para los
archivos de texto.
Observacin: es interesante comentar que cualquier conjunto de datos que respete las
estructuras de las tablas detalla en la seccin 8.3 podr ser usado como fuente para
generar un cubo, no es necesario que la informacin sea proveniente del SIU-Guaran
para poder utilizar el modelo.
-
Generar el cubo50
Finalmente, para generar el cubo es necesario copiar el modelo (dm_desgranamiento_
alumnos.mdl) y el ejecutable (dm_desgranamiento_alumnos.bat) en C:\IdeaSoft\O3\siu\
guarani\51.
Ubicar los archivos de datos en C:\IdeaSoft\O3\siu\guarani\txt\.
Si deseara instalar O3 en un directorio diferente a C:\IdeaSoft\O3 consulte cmo realizar
los cambios necesarios.
Ejecutar dm_desgranamiento_alumnos.bat para generar dm_desgranamiento_alumnos.
cube en C:\IdeaSoft\O3\siu\guarani\. Se toman los datos de los archivos de texto al
momento de la corrida. Si existiera un cubo con el mismo nombre lo reemplaza.
8.5
Archivos adjuntos
Junto a este documento se entrega un CD que contiene:
-
los procesos para generar los datos desde el SIU-Guaran,
el modelo y el ejecutable para poder generar el cubo,
el cubo con datos de ejemplo usado para los ejemplos en este documento,
los archivos de texto con datos de ejemplo para generar el cubo utilizado,
y la versin digital de este documento.
50
La generacin explicada aqu es para ser utilizada en sistemas operativos Windows. Es posible trabajar en Linux, slo
hay que realizar pequeas adaptaciones respecto a los ejecutables y los directorios.
51
Se respeta la estructura de archivos utilizada para los cubos que distribuye el SIU, que ser quien asuma el
mantenimiento de este trabajo.
138
Captulo - Bibliografa
Bibliografa
[Inm2002] William H. Inmon, 2002. Building the Data Warehouse, Third Edition. Wiley Computer
Publishing, John Wiley & Sons, Inc.
[Kim1992] Ralph Kimball, 1992. The Data Warehouse Toolkit, Wiley Computer Publishing
[Kim1998] Ralph Kimball, Laura Reeves, Margy Ross, Warren Thornthwaite, 1998. The Data
Warehouse Lifecycle Toolkit, Wiley Computer Publishing.
[Kim2002] Ralph Kimball, Margy Ross, 2002. The Data Warehouse Toolkit Second Edition. Wiley
Computer Publishing, John Wiley & Sons, Inc.
[Kim2004] Ralph Kimball, Joe Caserta, 2004. The Data Warehouse ETL Toolkit, Wiley Publishing,
Inc.
[Mst2005] MicroStrategy, 2005. Teora sobre Business Intelligence Concurso MicroStrategy
Experiencia Business Intelligence 2da. Edicin
[1] http://inmoncif.com/home/
[2] http://en.wikipedia.org/wiki/Bill_Inmon
[3] http://www.soluciones-ar.com.ar/es/comunicaciones/cm010705.asp
[4] http://www.microstrategy.com.ar/Solutions/5Styles/index.asp
[5] http://www.olapreport.com/market.htm o http://www.olapreport.com/
[6] http://www.siu.edu.ar
[7] http://www.siu.edu.ar/soluciones/guarani/publicaciones/libro/ o
http://www.siu.edu.ar/documentos/SIU-Guarani-Williams-Gurmendi.pdf
[8] CONVOCATORIA-20SEMINARIO-2002.pdf en http://www.iesalc.unesco.org.ve/
[9]
http://www.iesalc.unesco.org.ve/PROGRAMAS/EVENTOS/EVENTOS2005/DOCUMENTOS/
(47)CHILE.INF-FINAL.PDF
[10] http://www.inmoncif.com/library/cif/
[11] Claudia Imhoff, http://www.dmreview.com/issues/19991201/1667-1.html
[12] http://etl-tools.info/es/bi/proceso_etl.htm
[13] http://www.inmoncif.com/library/glossary/
[14] http://etl-tools.info/
[15] http://es.wikipedia.org/wiki/EIS
[16] http://www.ideasoft.com.uy/lportal/web/site/support o
ftp://ftp.ideasoft.biz/o3docs/spanish/O3DesignerSpanish.pdf
[17] http://www.ralphkimball.com/html/about.html o http://www.kimballgroup.com/html/about.html
[18] http://en.wikipedia.org/wiki/Ralph_Kimball
[19] http://www.businessobjects.com/
[20] http://www.cognos.com/
[21] http://www.microstrategy.com
[22] http://www.pentaho.com/
[23] http://www.oracle.com/hyperion/index.html
139
Captulo - Bibliografa
[24] http://www.oracle.com/solutions/business_intelligence/DW_home.html
[25] http://www.qlikviewspain.com/
[26] http://www.stratebi.com/
[27] http://pentaho.almacen-datos.com/
[28] http://todobi.blogspot.com/2005/06/empresas-business-intelligence.html
[29] http://www.microstrategy.com.ar/Software/comparison/index.asp?CID=2518g
[30] http://www.is-portal.com/bi/index.php?cnid=165
[31] http://www.bi-spain.com/
[32] http://www.barc.es/
[33] http://www.telefonica.net/web2/todobi/Pixfolder/HandsON1.pdf
[34] http://www.telefonica.net/web2/todobi/Pixfolder/HandsON2.pdf
[35] Gartner 2006: http://www.telefonica.net/web2/todobi/Pixfolder/magic_quadrant_for
_businesslligence_int__Q106.pdf
[36] Gartner: 2007: http://mediaproducts.gartner.com/reprints/hyperion/145507.html
[37] http://businessintelligence-ar.blogspot.com/2007/11/tendencias-y-carencias-enbusiness_16.html
[38] http://www.cognos.com/news/releases/2008/0131-2.html?mc=-web_hp
[39] http://www.oracle.com/corporate/press/2007_mar/hyperion.html
[40] http://businessintelligence-ar.blogspot.com/2007/11/tendencias-y-carencias-enbusiness_16.html
140

Data Warehousing Relevamiento y Aplicacion de Tecnicas de Modelado Dimensional

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Data Warehousing Relevamiento y Aplicacion de Tecnicas de Modelado Dimensional

Caricato da

Copyright:

Formati disponibili

Universidad Nacional del Sur

Departamento de Ciencias e Ingeniera

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

2.6 Tendencias en sistemas para anlisis de informacin............................................29

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

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

Seleccin de Productos e Instalacin....................................................................................43

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

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

5.2 Arquitectura del caso prctico.................................................................................79

5.5 Personalizacin del proceso ETL...........................................................................92

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

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

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

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

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

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

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

definen como la era de la informacin ya que posibilita la construccin y mantenimiento de

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

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

A mayo del 2008 se totalizan ms de 200 instalaciones

Captulo 2 - Sistemas para Anlisis de Informacin

Sistemas para Anlisis de Informacin

Evolucin de los Sistemas de Soporte de Decisiones

Captulo 2 - Sistemas para Anlisis de Informacin

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

Los algoritmos de clculo. Algunos criterios considerados de formas diferentes en la

Captulo 2 - Sistemas para Anlisis de Informacin

Nivel del Data Warehouse

Captulo 2 - Sistemas para Anlisis de Informacin

Todo ello plantea la necesidad de una nueva arquitectura [Inm2002], basada

de los datos transaccionales y especficamente estructurados para realizar consultas y analizar la

Variables en el Tiempo: todos los datos en el DW estn asociados con un perodo de

Objetivos de un Data Warehouse

generalmente mantenida en dos formas: el sistema operacional de registros y el DW. En forma

El DW debe proveer acceso fcil a la informacin de una organizacin.

Los datos del DW deben ser consistentes y de buena calidad.

correspondencias entre la informacin de diferentes partes de la organizacin. Si dos

Debe ser una fuente de informacin adaptable y flexible a los cambios.

El DW debe ser un lugar seguro donde la informacin se encuentre protegida.

Debe ser la base para la toma de decisiones.

Debe ser aceptado por la comunidad usuaria para considerarse exitoso.

utilizarlos. La aceptacin de los usuarios de estas herramientas pasa por la simplicidad

Entorno del Data Warehouse.

para un DW . Como se mencion anteriormente el DW es el ncleo de toda la arquitectura de un

rea de anlisis de informacin

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

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

Limpieza y transformacin de los datos

Este componente no provee ningn servicio de consulta ni presentacin de informacin,

Limpieza de datos. Consiste en la correccin de errores de tipeo, resolucin de dominios

Figura 4. Ejemplo de problema de calidad de datos.

Crear claves. Asociar un nuevo identificador a cada registro de dimensin y evitar la

Almacenamiento y presentacin de los datos

Aplicaciones de usuario final. Se refiere as a la coleccin de herramientas que consultan,

Herramientas de acceso a datos de usuario final. Se trata de herramientas que corren en

Herramientas de consultas ad hoc. Son un tipo especial de herramientas de acceso a

Aplicaciones analticas. Se trata de aplicaciones de acceso a datos preconstruidas

Aplicaciones estadsticas. Son aplicaciones establecidas para realizar anlisis estadsticos

Aplicaciones de modelado. Incluye a una variedad de aplicaciones cliente sofisticadas, con

Modelos de pronstico (forecasting) que buscan hacer predicciones

Modelos de clasificacin de comportamientos (clustering) que agrupan y

Aplicaciones tradicionales versus aplicaciones para anlisis de