Sistema de soporte de decisiones para la gestión académica de la ULADECH

UNIVERSIDAD NACIONAL DE TRUJILLO

ESCUELA DE POSTGRADO

SECCION DE POSGRADO EN INGENIERIA

DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE SOPORTE DE DECISIONES

PARA LA GESTIÓN ACADÉMICA DE LA ULADECH

TESIS PARA OPTAR EL GRADO DE MAESTRO EN INGENIERÍA DE SISTEMAS

MENCIÓN ADMINISTRACIÓN Y DIRECCIÓN DE TECNOLOGÍAS DE INFORMACIÓN

AUTOR: ING. JULIO CÉSAR ALVAREZ REYES

ASESOR: DR. FRANCISCO RODRIGUEZ NOVOA

TRUJILLO - PERU

2012

DEDICATORIA

A mis pequeñas hijas Alejandra Rubí y Alejandra Nadine, fuente de mi
inspiración.

A mi esposa Mery, quien siempre me acompaña en esta complicada vida.

iii

AGRADECIMIENTOS

Al Jefe de la Oficina de Registros Académicos: Ing. Christian Silva Matzunaga y
al Ing. Luis Hurtado Burga por haberme brindado todas las facilidades para
realizar este trabajo de investigación.

A mi Asesor Francisco Rodríguez Novoa por brindarme su ayuda para superarme
intelectualmente y estimularme a seguir adelante.

A mis colaboradores Juan Carlos Horna Santa Cruz y Carlos Eduardo Torres
Quito, quienes nunca desfallecieron en la dura tarea de testeo.

iv

INDICE

INDICE .............................................................................................................................. V
INDICE DE IMAGENES .............................................................................................. VIII
INDICE DE TABLAS ....................................................................................................... X
RESUMEN ....................................................................................................................... XI
ABSTRACT..................................................................................................................... XII
INTRODUCCION ............................................................................................................ 14
1.1 Realidad problemática........................................................................................... 15
1.2 Formulación del Problema .................................................................................... 16
1.3 Hipótesis ............................................................................................................... 16
1.4 Justificación .......................................................................................................... 16
1.5 Objetivo................................................................................................................. 17
MATERIAL Y MÉTODOS .............................................................................................. 19
2.1 Material ................................................................................................................. 19
2.1.1 Población........................................................................................................... 19
2.1.2 Muestra ............................................................................................................. 19
2.1.3 Unidad de Análisis ............................................................................................ 19
2.2 Método .................................................................................................................. 19
2.2.1 Tipo de estudio .................................................................................................. 19
2.2.2 Diseño de investigación .................................................................................... 20
2.2.3 Variables y operativización de variables........................................................... 20
2.2.4 Instrumentos de recolección de datos ............................................................... 20
2.2.5 Análisis e interpretación de resultados.............................................................. 21
MARCO TEORICO.......................................................................................................... 23
3.1 Gestión Académica. .............................................................................................. 23
3.2 Inteligencia de Negocios. ...................................................................................... 26
3.3 Sistema de Soporte de Decisiones. ....................................................................... 28
3.4 Data Warehouse(DWH) ........................................................................................ 31
3.4.1 Definiciones ......................................................................................................... 31
3.4.2 Data Mart ............................................................................................................. 34
3.4.3 Diseño de un DWH .............................................................................................. 36
3.4.3.1 Modelo dimensional ...................................................................................... 36
3.4.3.1.1 Modelo estrella....................................................................................... 38
3.4.3.1.2 Modelo copo de nieve ............................................................................ 39

3.4.4. Extraer, transformar y cargar (ETL) ................................................................... 40
3.4.4.1 Extracción. .................................................................................................... 41
3.4.4.2 Limpieza. ...................................................................................................... 41
3.4.4.3 Transformación. ............................................................................................ 43
3.4.4.4 Integración. ................................................................................................... 43
3.4.4.5 Actualización. ............................................................................................... 43
3.4.5. Proceso analítico en línea (OLAP)...................................................................... 43
3.4.6 Metodologías para la construcción de un DWH. ................................................. 45
3.4.6.1 Metodología propuesta por Bill Inmon ......................................................... 45
3.4.6.2 Metodología Kimball .................................................................................... 47
3.4.6.2.1 Planificación del Proyecto ..................................................................... 48
3.4.6.2.2 Modelo Dimensional ............................................................................. 49
3.4.6.2.2 Diseño Físico......................................................................................... 49
3.4.6.2.3 Diseño y Desarrollo de la Presentación de Datos ................................. 51
3.4.6.2.4 Diseño de la Arquitectura Técnica ......................................................... 52
3.4.6.2.5 Selección de Productos e Instalación ..................................................... 54
3.4.6.2.6 Especificación de Aplicaciones para Usuarios Finales .......................... 56
3.4.6.2.7 Desarrollo de Aplicaciones para Usuarios Finales................................. 56
3.4.6.2.8 Implementación...................................................................................... 56
3.4.6.2.9 Mantenimiento y crecimiento ................................................................ 57
3.4.6.2.10 Gestión del Proyecto ............................................................................ 57
3.4.6.3 Rapid Warehousing Methodology ................................................................ 57
3.4.6.3.1 Definición de objetivos .......................................................................... 58
3.4.6.3.2 Definición de los requerimientos de información. ................................. 58
3.4.6.3.3 Diseño y modelización. .......................................................................... 59
3.4.6.3.4 Implementación...................................................................................... 59
3.4.6.3.5 Revisión. ................................................................................................ 60
3.4.6.3.6 Gestión del Proyecto. ............................................................................. 60
RESULTADOS................................................................................................................. 62
4.1 Metodología empleada .......................................................................................... 62
4.1.1 ¿Porque utilizar la metodología de KIMBAL? .................................................... 62
4.1.3 Metodología seleccionada .................................................................................... 63
4.2 CONSTRUCCION DEL DATAWAREHOUSE....................................................... 64
4.2.1 Planificación del Proyecto ................................................................................... 64
4.2.2 Definición de Requerimientos ............................................................................. 67
4.2.3 Modelo Dimensional ............................................................................................ 74

4.2.3.1 Definición del proceso de negocio. ............................................................... 74
4.2.3.2 Definición del grano...................................................................................... 76
4.2.3.3 Elección de las dimensiones ......................................................................... 77
4.2.3.4 Identificación de los hechos .......................................................................... 88
4.2.3.5 Detalle de las tablas dimensión ..................................................................... 90
4.2.3.5.1 Dimensión Periodo ................................................................................. 90
4.2.3.5.2 Dimensión Curso.................................................................................... 91
4.2.3.5.3 Dimensión ModalidadIngreso ................................................................ 93
4.2.3.5.4 Dimensión ModalidadEstudio................................................................ 93
4.2.3.5.5 Dimensión CondicionIngreso ................................................................ 94
4.2.3.5.6 Dimensión CarreraProfesional ............................................................... 94
4.2.3.5.7 Dimensión Alumno ................................................................................ 95
4.2.3.5.8 Dimensión Postulante ............................................................................ 97
4.2.3.5.9 Dimensión Docente ................................................................................ 98
4.2.4 Diseño Físico del DWH ..................................................................................... 100
4.2.5 Diseño y presentación de datos .......................................................................... 102
4.2.6 Diseño de la arquitectura técnica ....................................................................... 110
4.2.7 Selección de productos e instalación ................................................................. 111
4.2.8 Especificación de aplicaciones para usuarios finales ......................................... 113
4.2.9 Desarrollo de aplicaciones para usuarios finales ............................................... 114
4.2.10 Despliegue........................................................................................................ 117
4.2.11 Mantenimiento y crecimiento .......................................................................... 117
4.2.12 Gestión del Proyecto ........................................................................................ 118
DISCUSION ................................................................................................................... 120
5.1 Diseño de contrastación ............................................................................................ 120
CONCLUSIONES .......................................................................................................... 124
RECOMENDACIONES ................................................................................................. 126
BIBLIOGRAFÍA ............................................................................................................ 128
ANEXOS ........................................................................................................................ 129

INDICE DE IMAGENES

FIG. 1 PROCESO DE FORMACIÓN PROFESIONAL. FUENTE: DEAC-CONEAU, 2008. ......................... 25
FIG. 2 MODELO DE CALIDAD PARA LA ACREDITACIÓN DE CARRERAS
PROFESIONALES UNIVERSITARIAS. ............................................................................. 26
FIG. 3 TIPOS DE SISTEMAS DE INFORMACIÓN. ............................................................................... 31
FIG. 4 ESTRUCTURA BÁSICA DE UN DWH. ....................................................................................... 33
FIG. 5 DEL DWH AL DATA MART...................................................................................................... 35
FIG. 6 DEL DWH AL DATA MART...................................................................................................... 36
FIG. 7 COMPONENTES MODELO DIMENSIONAL ............................................................................. 37
FIG. 8 MODELO ESTRELLA ............................................................................................................... 39
FIG. 9 MODELO COPO DE NIEVE...................................................................................................... 40
FIG. 10 DESARROLLO DEL DWH SEGÚN LA METODOLOGÍA DE BILL INMON .................................. 46
FIG. 11 CICLO DE VIDA DE LA METODOLOGÍA DE RALPH KIMBALL ................................................. 48
FIG. 12 METODOLOGÍA RAPID WAREHOUSING .............................................................................. 58
FIG. 13 STAKEHOLDERS ............................................................................................................ 65
FIG. 14 CALENDARIO DE ACTIVIDADES............................................................................................ 65
FIG. 15 GANTT DEL PROYECTO ........................................................................................................ 66
FIG. 16 MODELO DE INDICADOR DE GESTIÓN. ............................................................................... 68
FIG. 17 MODELO ERP-UNIVERSITY 1.0 ................................................................................... 71
FIG. 18 INTERACCIÓN ERP-UNIVERSITY - MOODLE ........................................................... 73
FIG. 19 MODELO ERP-UNIVERSITY 2.0 ................................................................................... 74
FIG. 20 ANÁLISIS DIMENSIONAL ADMISIÓN .................................................................................... 78
FIG. 21 HOJA DE ANÁLISIS ADMISIÓN ............................................................................................. 79
FIG. 22 ANÁLISIS DIMENSIONAL CARGA LECTIVA ........................................................................... 79
FIG. 23 HOJA DE ANÁLISIS CARGA ACADÉMICA .............................................................................. 80
FIG. 24 ANÁLISIS DIMENSIONAL EGRESADOS ................................................................................. 81
FIG. 25 HOJA DE ANÁLISIS EGRESADO ............................................................................................ 82
FIG. 26 ANÁLISIS DIMENSIONAL RENDIMIENTO ACADÉMICO ........................................................ 83
FIG. 27 HOJA DE ANÁLISIS RENDIMIENTO ACADÉMICO.................................................................. 85
FIG. 28 DIMENSIONES Y SUS JERARQUÍAS. ..................................................................................... 86
FIG. 29 DIMENSIONES Y MEDIDAS. ................................................................................................. 87
FIG. 30 HECHO DE ADMISIÓN ......................................................................................................... 88
FIG. 31 HECHO DE CARGA LECTIVA ................................................................................................. 89
FIG. 32 HECHO DE EGRESADOS ....................................................................................................... 89
FIG. 33 HECHO DE RENDIMIENTO ................................................................................................... 90
FIG. 34 ESTRUCTURA DIMENSIÓN PERIODO ................................................................................... 90
FIG. 38 ESTRUCTURA DIMENSIÓN CONDICIONINGRESO ................................................................ 94
FIG. 39 ESTRUCTURA DIMENSIÓN CARRERAPROFESIONAL ............................................................ 95
FIG. 40 ESTRUCTURA DIMENSIÓN ALUMNO ................................................................................... 96
FIG. 41 ESTRUCTURA DIMENSIÓN POSTULANTE............................................................................ 97
FIG. 42 ESTRUCTURA DIMENSIÓN DOCENTE .................................................................................. 99
FIG. 43 DISEÑO FÍSICO DEL DWH .......................................................................................... 101

FIG. 44 ESQUEMA GENERAL DE POBLAMIENTO ........................................................................... 102
FIG. 45 ETL - ADMISIÓN ................................................................................................................. 103
FIG. 46 MODELO TRANSACCIONAL PROCESO DE ADMISIÓN ........................................................ 104
FIG. 47 GENERACIÓN DEL STAGING ÁREA PROCESO DE ADMISIÓN ............................................. 105
FIG. 48 LLENADO DE DIMENSIONES PROCESO DE ADMISIÓN ...................................................... 105
FIG. 49 LLENADO DE LA TABLA HECHO PROCESO DE ADMISIÓN .................................................. 106
FIG. 50 ETL - CARGA ACADÉMICA .................................................................................................. 106
FIG. 51 MODELO TRANSACCIONAL CARGA ACADÉMICA .............................................................. 107
FIG. 52 GENERACIÓN DEL STAGING ÁREA PROCESO DE CARGA ACADÉMICA .............................. 108
FIG. 53 LLENADO DE DIMENSIONES PROCESO DE CARGA LECTIVA .............................................. 109
FIG. 54 LLENADO DE LA TABLA HECHO PROCESO DE ADMISIÓN .................................................. 110
FIG. 55 ARQUITECTURA TÉCNICA DWH ......................................................................................... 111
FIG. 56 ESPECIFICACIONES DE APLICACIONES PARA LOS USUARIOS ............................................ 114
FIG. 57 TABLAS DM ADMISIÓN EN EL QLIKVIEW........................................................................... 115
FIG. 58 TABLAS DM CARGALECTIVA EN EL QLIKVIEW ................................................................... 115
FIG. 59 REPORTE DE CONSULTA .................................................................................................... 116
FIG. 60 REPORTE DE INDICADORES ............................................................................................... 116
FIG. 63 NÚMERO DE ALUMNOS POR AÑO ACADÉMICO ............................................................... 129
FIG. 64 NÚMERO DE ALUMNOS POR MODALIDAD, SEMESTRE 2011-2 ........................................ 129
FIG. 65 SEDES ACADÉMICAS ULADECH ......................................................................................... 130

INDICE DE TABLAS

TABLA 1 INDICADORES REFERIDOS A LOS ESTUDIANTES Y A SU RENDIMIENTO ACADÉMICO. ...... 69
TABLA 2 INDICADORES REFERIDOS A LA CALIDAD DE LA DOCENCIA .............................................. 70
TABLA 3 INDICADORES REFERIDOS A LA CALIDAD DE LA INVESTIGACIÓN ..................................... 70
TABLA 4 INDICADORES REFERIDOS AL NIVEL DE LOS RECURSOS DESTINADOS .............................. 71
TABLA 5 EJEMPLO DIMENSIÓN PERIODO........................................................................................ 91
TABLA 6 EJEMPLO DIMENSIÓN CURSO. .......................................................................................... 92
TABLA 7 EJEMPLO DIMENSIÓN MODALIDADINGRESO. .................................................................. 93
TABLA 10 EJEMPLO DIMENSIÓN MODALIDADINGRESO. ................................................................ 95
TABLA 11EJEMPLO DIMENSIÓN ALUMNO ...................................................................................... 96
TABLA 12 EJEMPLO DIMENSIÓN POSTULANTE ............................................................................... 98
TABLA 13 EJEMPLO DIMENSIÓN DOCENTE ................................................................................... 100
TABLA 14 ESTADÍSTICOS ................................................................................................................ 120
TABLA 15 PRUEBA DE LOS RANGOS CON SINGO DE WILCOXON .................................................. 121
TABLA 14 DECANATOS .................................................................................................................. 133
TABLA 15 ESCUELAS PROFESIONALES ........................................................................................... 133
TABLA 16 DEPARTAMENTOS ACADÉMICOSANEXO 06: INDICADORES GESTION ACADEMICA ..... 134

RESUMEN

El presente proyecto titulado “Diseño e Implementación de un Sistema de Soporte
de Decisiones para la Gestión Académica de la ULADECH”, tiene por objetivo
central, dar solución al problema de la necesidad de información para la toma de
decisiones de los directivos, para esto se brinda una poderosa solución de
inteligencia de negocios que permitirá mejorar la gestión académica de la
universidad. Este hecho se puede lograr con la aplicación de la tecnología
Datawarehouse cómo parte del sistema de información analítico para la gestión
académica, que permita obtener respuestas a las consultas requeridas de manera
rápida y haciendo uso óptimo de los recursos. Para este fin se utilizará la
metodología de Ralph Kimball que se ajusta más a lo que se quiere desarrollar al
permitir la creación del DWH partiendo de los Datamart, al estar involucradas
solamente las áreas académicas.

Se tomará como referencia los indicadores del CONEAU (Consejo de Evaluación,
Acreditación y Certificación de la Calidad de la Educación Superior Universitaria)
que ha diseñado un modelo que cuenta con 03 dimensiones, 09 factores, 16
criterios, 84 indicadores y 253 fuentes de verificación referenciales. Los
indicadores de gestión propuestos abarcan todos los requerimientos requeridos por
los responsables de la gestión académica de la Universidad.

ABSTRACT

This project entitled "Design and Implementation of a Decision Support System
for Academic Administration of ULADECH", is a central objective, to solve the
problem of information needs for decision making of managers, for this is
provides a powerful business intelligence solution that will improve the academic
management of the university. This can be achieved with the application of
technology Datawarehouse how part of the analytical information system for
academic management, to obtain answers to queries required quickly and making
optimum use of resources. For this purpose, the methodology used Ralph Kimball
that best fits what you want to develop by allowing the creation of the DWH
based on the Datamart, being involved only academic areas.

They shall refer CONEAU indicators (Evaluation Council, Accreditation and
Quality Assurance of Higher Education University) who has designed a model
that has 03 dimensions, 09 factors, 16 criteria, 84 indicators and 253 reference
sources of verification. The proposed performance indicators covering all the
requirements required by those responsible for the academic management of the
University.

CAPITULO I: INTRODUCCION Maestría en Ingeniería de Sistemas
Con mención en Administración y Dirección de TI

INTRODUCCION

Hoy en día, las bases de datos existentes en las empresas mantienen la
información necesaria para la actividad diaria de la organización, suministran
datos a los sistemas corporativos validando la información previamente. Éstas
representan una herramienta imprescindible en el mundo actual, sin embargo
es insuficiente para el correcto funcionamiento de los sistemas de
información de cualquier organización.

No sólo se requiere grandes volúmenes de datos debidamente almacenados en
las bases de datos, se requiere de un módulo analítico que pueda procesar y
analizar estos datos y transformarlos en información y pueda ser útil para la
que los directivos (rector, vicerrector, decanos, jefes de departamento y
directores de Escuela) puedan realizar la interpretación correcta y tomar las
mejores decisiones.

La gestión académica universitaria es un proceso que reviste múltiples
factores, que involucran el acceso de recursos diversos (tangibles e
intangibles), un procesamiento altamente complejo (dado que involucra
aspectos relacionados con el desarrollo de las capacidades intelectuales y
emotivas), y genera salidas bajo la forma de productos diversos, valorados
socialmente, en sus expresiones más variadas cómo: conocimientos,
profesionalidad, habilidades cognoscitivas, investigativas, etc.

La finalidad de un datawarehouse consiste en convertir los datos contenidos
en las bases de datos corporativas de las organizaciones, en información y
ésta, a su vez, en conocimiento útil en el proceso de toma de decisiones
estratégicas. El datawarehouse es una herramienta que va a permitir a los
directivos de las organizaciones formular preguntas, realizar consultas y
analizar los datos en el momento, forma y cantidad que precisen sin necesidad
de tener que acudir al personal informático de la empresa.

Lo que se pretende en el presente proyecto de investigación es aplicar los
conceptos de Datawarehouse y Business Intelligence orientado a la
14


integración de la información para lograr la mejor operatividad de la gestión
académica.

1.1 Realidad problemática

La ULADECH desde el año 2000, ha experimentado un crecimiento
exponencial en su número de estudiantes y centros académicos (Anexo 1 y 2),
actualmente cuenta con las Facultades de Derecho, Educación, Ingeniería,
Ciencias Contables, Ciencias de la Salud y con las siguientes escuelas
profesionales: Educación y Ciencias Religiosas, Ingeniería de Sistemas,
Ingeniería Civil, Contabilidad, Administración, Turismo Odontología,
Obstetricia, Enfermería y Farmacia.

Su régimen de estudios es b-learning, que se entiende cómo un sistema de
enseñanza presencial con alta incidencia en las tecnologías de la información,
sus modalidades de estudios son presencial y distancia, ambas tienen cómo
característica común la integración de las tic en sus procesos Estas
modalidades tienen diferentes espacios aulares para el desarrollo de las
sesiones de plan de aprendizaje. El estudiante puede optar por combinar los
espacios aulares para el desarrollo de sus asignaturas. (DOMINGUEZ, 2003)

Bajo este contexto su gestión académica se complica y debe ser evaluada,
para determinar su vulnerabilidad, para conocer su pertinencia, su eficacia y
su eficiencia, creando unidades de medición que permitan calificar sus
características, con la finalidad de medir su calidad. No existen indicadores
para conocer el cumplimiento de las metas, la implicancia de las decisiones
tomadas y su grado de influencia en el plan estratégico de la ULADECH al
2013.

Se realiza una gestión académica basada en la experiencia de sus autoridades
de la alta dirección, pero no se cuenta con un sistema de soporte de decisiones
que permita realizar una medición adecuada de la problemática de la gestión,
así como la incidencia y repercusión de las decisiones que se tome. No se
encuentran identificados los elementos para un sistema de soporte de

15


decisiones que la habilite para competir en un mercado cambiante y
sumamente competitivo.

En resumen la ULADECH, no cuenta con un sistema de soporte de
decisiones para la gestión académica que le permita gestionar de forma eficaz
y efectiva sus procesos académicos sustantivos.

1.2 Formulación del Problema

¿En qué medida influye la implementación de un sistema de soporte de
decisiones en la gestión académica en la ULADECH?

1.3 Hipótesis

La implementación de un sistema de soporte de decisiones mejora la Gestión
Académica en la ULADECH.

Variables

Independiente: Sistema Soporte de Decisiones

Dependiente: Gestión Académica

1.4 Justificación

La importancia de administrar la información en las universidades modernas,
deriva del soporte para la toma de decisiones. Hoy en día las organizaciones
buscan a través de su administración del conocimiento y las tecnologías de la
información, enfocar sus resultados de administración hacia procesos de
negocios.

No es extraño encontrarse con situaciones en las cuales lo que abundan son
estadísticas educacionales (desagregadas en un sinnúmero de niveles de
consolidación y de detalle) y que, sin embargo, poco o nada a quienes tienen
la responsabilidad de ejecutar, dirigir, controlar y sobre todo tomar
decisiones. Se podría concluir que para que exista una adecuada gestión
académica es indispensable contar con un sistema de soporte de decisiones

16


que habilite a la organización para inicialmente lleven a cabo actividades de
“data mining” y análisis estadístico. El diseño de dicho Datawarehouse
deberá soportar, en un futuro, la expansión a funcionalidades tales como la
implementación de “performance dashboards” o formar parte de una
arquitectura de “Analytical CRM”.

Todo lo anterior lleva a la necesidad de tener que definir con claridad cuáles
son los elementos que constituyen un sistema de soporte de decisiones, para
ello será necesario a su vez, tener que clarificar cuáles son los procesos de
toma de decisiones educacionales que se deseen apoyar en la ULADECH.

1.5 Objetivo

Mejorar la gestión académica de la ULADECH.

17

CAPITULO II: MATERIAL Y MÉTODOS

CAPITULO II: MATERIAL Y MÉTODOS Maestría en Ingeniería de Sistemas

MATERIAL Y MÉTODOS

2.1 Material

2.1.1 Población

La población de este estudio está compuesta por todas las
autoridades que toman decisiones respecto a la gestión académica
de la universidad.

Está compuesta por:

Rector (1)

Vicerrector (1)

Decanos (5)

Directores de Escuela (12)

Jefes de Departamento (17)

2.1.2 Muestra

Se ha seleccionado la totalidad de la población cómo muestra, por
tratarse de una población pequeña (36 directivos).

2.1.3 Unidad de Análisis

La unidad de análisis está determinada por el conjunto de directivos
que están encargados de la toma de decisiones de la Universidad.

2.2 Método

2.2.1 Tipo de estudio

De acuerdo al fin que persigue: Aplicada

19


2.2.2 Diseño de investigación

El diseño de la investigación es pre-experimental puesto que se
buscará medir el efecto existente entre la variable dependiente
cómo es el Sistema de Soporte de Decisiones y la variable
independiente cómo es la Gestión académica de la Universidad.
O1  O2
Donde:
O1= Sistema de Soporte de decisiones
O2= Gestión Académica

2.2.3 Variables y operativización de variables

Independiente: Sistema Soporte de Decisiones.

Nos referimos al datawarehouse desarrollado y puesto a disposición
de las autoridades de la Universidad para que puedan tomar las
decisiones más adecuadas y mejorar los indicadores académicos.

Dependiente: Gestión Académica.

Al referirnos a la gestión académica, pretendemos hacer una
descripción, focalizando las posibilidades y características de las
formas de gobierno y administración de la Universidad.

2.2.4 Instrumentos de recolección de datos

Las técnicas que se utilizaron están referidas a la aplicación de la
encuesta, siendo el cuestionario el instrumento seleccionado a
utilizar, lo cual nos permitió recoger información para determinar
la relación entre el uso de un sistema de soporte de decisiones y la
gestión académica de la Universidad.

20


2.2.5 Análisis e interpretación de resultados.

Para la contratación de la hipótesis se utilizará el método de diseño
en sucesión o en línea, llamado también método PRE- TEST,
POST - TEST con un solo grupo, el que consiste en:

Realizar una medición anticipada de la variable
dependiente. (pre-test).
La aplicación de la variable independiente a los sujetos del
grupo.
Realizar una medición nueva de la variable dependiente en
los sujetos (post-test).

Dónde:

O1: Gestión Académica de la ULADECH antes de la
implementación del sistema de soporte de decisiones.

X: Sistema de soporte de decisiones.

O2: Gestión Académica de la ULADECH después de la
implementación del sistema de soporte de decisiones.

21

CAPITULO III: MARCO TEÓRICO Maestría en Ingeniería de Sistemas

MARCO TEORICO

Para comprender el contexto en que se desarrollará el presente trabajo de tesis,
es importante comprender algunos conceptos, puesto que dichos conceptos
van de la mano con el trabajo a desarrollarse.

3.1 Gestión Académica.

La gestión académica es un proceso que reviste múltiples aspectos, que
involucran el acceso de recursos diversos (tangibles e intangibles), un
procesamiento de la complejidad (dado que involucra aspectos relacionados
con el desarrollo de las capacidades intelectuales y emotivas), y genera
salidas bajo la forma de productos expuestos y valorados socialmente, en sus
expresiones más variadas: nuevos conocimientos, profesionalidad,
habilidades cognoscitivas, investigativas, capacidades de solución en el
descubrimiento, formulación, planteamiento y resolución de problemas
profesionales, pretendiendo que se minimicen los errores y se maximicen los
aciertos en aras de garantizar el continuado progreso de la sociedad humana
en equilibrada armonía con la naturaleza a la que pertenece. (RED
IBEROAMERICANA PARA LA ACREDITACIÓN DE LA CALIDAD DE
LA EDUCACIÓN SUPERIOR RIACES, 2004)

Al referirnos a la gestión académica, pretendemos hacer una descripción,
focalizando las posibilidades y características de las formas de gobierno y los
estilos de administración de las instituciones de educación superior.

Documentos emanados de organismos internacionales como la CEPAL y
UNESCO, expresan la relevancia de la gestión en tanto organización y
administración de recursos para alcanzar los objetivos de determinada política
educacional, comprendiendo un proceso que va desde el diseño, la
formulación y desarrollo de dicha política hasta arribar al estadio que finaliza
con la evaluación de sus resultados (CEPAL/UNESCO, 2005). El estilo de
gestión que se aplique en lo institucional, ya sea en lo macro o en un sector de

23


la organización, debe fundamentarse en la profunda comprensión de la cultura
institucional universitaria, como totalidad de sentido, como anclaje de los
intereses de la comunidad universitaria, con sus costumbres y rasgos
distintivos, del colectivo compuesto por sus actores diferenciados, con lo que
se vive en la dinámica de trabajo con sus componentes explícitos e implícitos.

A nivel nacional el Consejo de Evaluación, Acreditación y Certificación de la
Calidad de la Educación Superior Universitaria (CONEAU), ha elaborado un
modelo de Calidad para la Acreditación de las Carreras Profesionales
Universitarias, a partir de un estudio comparativo de distintos modelos
nacionales e internacionales. El modelo se basa en el enfoque sistémico,
aplicando en cada uno de los procesos involucrados el ciclo “planificar-hacer-
verificar-actuar”. Está diseñado de tal modo que se convierte en un
instrumento para la mejora de la calidad de las carreras profesionales
universitarias y, a la vez, para un mejor control de los procesos. El enfoque
que hace el CONEAU, es de lo más interesante, presenta 84 indicadores de
gestión que se presentan como una herramienta para poder evaluar el
desempeño de una Universidad mediante parámetros establecidos en relación
con las metas. Con los resultados obtenidos se pueden tomar soluciones o
plantear herramientas que contribuyan al mejoramiento o correctivos que
conlleven a la consecución de la meta fijada.

Una ventaja adicional en la construcción de este modelo, es que los objetivos
planteados pueden alcanzarse más fácilmente ya que los recursos y las
actividades relacionadas están gestionadas como procesos, los cuales han sido
desarrollados bajo el principio de la mejor continua, aplicando el ciclo de
Deming: planificar, hacer, verificar y actuar (Figura 1).

24


Fig. 1 Proceso de Formación Profesional. Fuente: DEAC-CONEAU, 2008.

El CONEAU (Consejo de evaluación, acreditación y certificación de la
calidad de la educación superior universitaria) ha desarrollado El “Modelo de
calidad para la acreditación de las carreras profesionales universitarias”, es el
resultado de la suma del saber y la experiencia de quienes, en el contexto
universitario y como consecuencia de la búsqueda del eficiente
funcionamiento de la institución y el requerimiento de informar a la sociedad,
han logrado establecer, a través de la revisión y el análisis de información
relacionada al aseguramiento de la calidad de la educación superior, un
conjunto de factores, criterios e indicadores que constituyen el referido
Modelo. (CONSEJO DE EVALUACIÓN, ACREDITACIÓN Y
CERTIFICACIÓN DE LA CALIDAD DE LA EDUCACIÓN SUPERIOR
UNIVERSITARIA, 2008)

El modelo cuenta con 03 dimensiones, 09 factores, 16 criterios, 84
indicadores y 253 fuentes de verificación referenciales. Los indicadores de
gestión propuestos abarcan todos los requerimientos requeridos por los
responsables de la gestión académica.

25


Fig. 2 Modelo de calidad para la acreditación de carreras profesionales universitarias.

3.2 Inteligencia de Negocios.

El objetivo básico de la Business Intelligence es apoyar de forma sostenible y
continuada a las organizaciones para mejorar su competitividad, facilitando la
información necesaria para la toma de decisiones. El primero que acuñó el
término fue Howard Dresner que, cuando era consultor de Gartner,
popularizó Business Intelligence o BI como un término paraguas para
describir un conjunto de conceptos y métodos que mejoraran la toma de
decisiones, utilizando información sobre qué había sucedido (hechos).

Mediante el uso de tecnologías y las metodologías de Business Intelligence
pretendemos convertir datos en información y a partir de la información ser
capaces de descubrir conocimiento.

Para definir BI partiremos de la definición del glosario de términos de
Gartner.

“BI es un proceso interactivo para explorar y analizar información
estructurada sobre un área (normalmente almacenada en un datawarehouse),

26


para descubrir tendencias o patrones, a partir de los cuales derivar ideas y
extraer conclusiones.

El proceso de Business Intelligence incluye la comunicación de los
descubrimientos y efectuar los cambios. Las áreas incluyen clientes,
proveedores, productos, servicios y competidores.” (CHARLES K., 2003)

Pero descompongamos detalladamente esta definición:

Proceso interactivo: al hablar de BI estamos suponiendo que se trata
de un análisis de información continuado en el tiempo, no sólo en un
momento puntual. Aunque evidentemente este último tipo de análisis
nos puede aportar valor, es incomparable con lo que nos puede aportar
un proceso continuado de análisis de información, en el que por
ejemplo podemos ver tendencias, cambios, variabilidades, etc.
Explorar: En todo proyecto de BI hay un momento inicial en el que
por primera vez accedemos a información que nos facilita su
interpretación. En esta primera fase, lo que hacemos es “explorar”
para comprender qué sucede en nuestro negocio; es posible incluso
que descubramos nuevas relaciones que hasta el momento
desconocíamos.
Analizar: Pretendemos descubrir relaciones entre variables,
tendencias, es decir, cuál puede ser la evolución de la variable, o
patrones. Si un cliente tiene una serie de características, cuál es la
probabilidad que otro con similares características actué igual que el
anterior.
Información estructurada y datawarehouse: La información que
utilizamos en BI está almacenada en tablas relacionadas entre ellas.
Las tablas tienen registros y cada uno de los registros tiene distintos
valores para cada uno de los atributos. Estas tablas están almacenadas
en lo que conocemos como datawarehouse o almacén de datos. Más
adelante lo definiremos con mayor precisión, pero se trata de una base
de datos en las que se almacenan dichas tablas.

27


Área de análisis: Todo proyecto de BI debe tener un objeto de análisis
concreto. Nos podemos centrar en los clientes, los productos, los
resultados de una localización, etc. que pretendemos analizar con
detalle y con un objetivo concreto: por ejemplo, la reducción de
costos, el incremento de ventas, el aumento de la participación de
mercado, el ajuste de previsiones de venta, el cumplimiento los
objetivos de venta presupuestados, etc.
Comunicar los resultados y efectuar los cambios: Un objetivo
fundamental del BI es que, una vez descubierto algo, sea comunicado
a aquellas personas que tengan que realizar los cambios pertinentes en
la organización para mejorar nuestra competitividad.

El origen de la Business Intelligence va ligado a proveer acceso directo
a la información a los usuarios de negocio para ayudarles en la toma de
decisiones, sin intervención de los departamentos de Sistemas de
Información. (CANO LLUIS, 2007)

3.3 Sistema de Soporte de Decisiones.

Un sistema de soporte de decisiones es "un sistema de información basado en
un computador interactivo, flexible y adaptable, especialmente desarrollado
para apoyar la solución de un problema de gestión no estructurado para
mejorar la toma de decisiones. Utiliza datos, proporciona una interfaz
amigable y permite la toma de decisiones en el propio análisis de la
situación".

Función y características:

Los DSS son herramientas de mucha utilidad en Inteligencia empresarial
(Business Intelligence), permiten realizar el análisis de las diferentes
variables de negocio para apoyar el proceso de toma de decisiones de los
directivos:

Permite extraer y manipular información de una manera flexible.
Ayuda en decisiones no estructuradas.
28


Permite al usuario definir interactivamente qué información necesita y
cómo combinarla.
Suele incluir herramientas de simulación, modelización, etc.
Puede combinar información de los sistemas transaccionales internos
de la empresa con los de otra empresa externa.

Su principal característica es la capacidad de análisis multidimensional
(OLAP) que permite profundizar en la información hasta llegar a un alto nivel
de detalle, analizar datos desde diferentes perspectivas, realizar proyecciones
de información para pronosticar lo que puede ocurrir en el futuro, análisis de
tendencias, análisis prospectivo, etc.

Un DSS da soporte a las personas que tienen que tomar decisiones en
cualquier nivel de gestión, ya sean individuos o grupos, tanto en situaciones
semi estructuradas como en no estructuradas, a través de la combinación del
juicio humano e información objetiva:

Soporta varias decisiones interdependientes o secuenciales.
Ofrece ayuda en todas las fases del proceso de toma de decisiones -
inteligencia, diseño, selección, e implementación- así como también
en una variedad de procesos y estilos de toma de decisiones.
Es adaptable por el usuario en el tiempo para lidiar con condiciones
cambiantes.
Genera aprendizaje, dando como resultado nuevas demandas y
refinamiento de la aplicación, que a su vez da como resultado un
aprendizaje adicional.
Generalmente utiliza modelos cuantitativos (estándar o hechos a la
medida).
Los DSS avanzados están equipados con un componente de
administración del conocimiento que permite una solución eficaz y
eficiente de problemas muy complejos.
Puede ser implantado para su uso en Web, en entornos de escritorio o
en dispositivos móviles (PDA).

29


Permite la ejecución fácil de los análisis de sensibilidad.

El principal objetivo de los Sistemas de Soporte a Decisiones es, a diferencia
de otras herramientas como los Cuadros de Mando (Balance Scored Card) o
los Sistemas de Información Ejecutiva (EIS), explotar al máximo la
información residente en una base de datos corporativa (datawarehouse o
datamart), mostrando informes muy dinámicos y con gran potencial de
navegación, pero siempre con una interfaz gráfica amigable, vistosa y
sencilla.

Otra diferencia fundamental radica en los usuarios a los que están destinadas
las plataformas DSS: cualquier nivel gerencial dentro de una organización,
tanto para situaciones estructuradas como no estructuradas. (En este sentido,
por ejemplo, los sistemas de información gerencial están más orientados a la
alta dirección).

Tipo de Sistemas de Soporte de Decisiones

Balance Scored Card (BSC). Es una herramienta de administración de
empresas que muestra continuamente cuándo una compañía y sus
empleados alcanzan los resultados definidos por el plan estratégico.
También es una herramienta que ayuda a la compañía a expresar los
objetivos e iniciativas necesarias para cumplir con la estrategia.
Sistemas de información gerencial (MIS). Estos sistemas son el
resultado de interacción colaborativa entre personas, para prever
información que apoye las operaciones, la administración y las
funciones de toma de decisiones en una empresa. El sistema utiliza
equipos de computación y software especializado, procedimientos,
manuales, modelos para el análisis, la planificación, el control y la
toma de decisiones, además de bases de datos.
Sistemas de información ejecutiva (EIS). Es una herramienta de
Inteligencia empresarial orientada a usuarios de nivel gerencial, que
permite monitorizar el estado de las variables de un área o unidad de
la empresa a partir de información interna y externa a la misma. Se
30


puede considerar que un EIS es un tipo de Sistema de Soporte a la
Decisión cuya finalidad principal es que el responsable de un
departamento o compañía tenga acceso, de manera instantánea, al
estado de los indicadores de negocio que le afectan, con la posibilidad
de estudiar con detalle aquellos aspectos que no estén cumpliendo con
los objetivos establecidos en su plan estratégico u operativo.

Fig. 3 Tipos de Sistemas de Información.

3.4 Data Warehouse(DWH)

3.4.1 Definiciones

Se puede decir que un DWH es una gran base de datos que almacena datos
que provienen de las bases de datos transaccionales de la empresa y que se
encuentran estructurados para el análisis de la gestión en forma fácil y rápida.

“El DWH es una base de datos que almacena una gran cantidad de datos
transaccionales integrados que serán usados para análisis de gestión por
usuarios especializados (tomadores de decisión de la empresa). (KIMBALL,
1998)

31


También fue Kimball quien determinó que un datawarehouse no era más que:
"la unión de todos los Data marts de una entidad". Defiende por tanto una
metodología ascendente (bottom-up) a la hora de diseñar un almacén de
datos.

“El DWH es una colección de datos integrada en una Base de Datos,
orientada según un tema, diseñadas para soportar un Sistema de Soporte a las
Decisiones (DSS), donde cada unidad de dato es relevante en algún momento
del tiempo.” Inmon defiende una metodología descendente (top-down) a la
hora de diseñar un almacén de datos, ya que de esta forma se considerarán
mejor todos los datos corporativos. En esta metodología los Data marts se
crearán después de haber terminado el datawarehouse completo de la
organización. (INMON, 2000)

Se puede definir también cómo un almacén de datos consistente
semánticamente que sirve como implementación física de un modelo de datos
de apoyo a la toma de decisiones y que almacena la información que la
organización necesita para la toma de decisiones estratégicas. Un almacén de
datos presenta una vista multidimensional de los datos y es por eso que se
denominan bases de datos multidimensionales o cubos de datos.

El valor de un DWH queda descrito en tres dimensiones. (INMON, 2000)

Mejorar la entrega de información: información completa, correcta,
consistente, oportuna y accesible. Información que la gente necesita,
en el tiempo que la necesita y en el formato que la necesita.

Facilitar el proceso de toma de decisiones: con un mayor soporte de
información se obtienen decisiones más rápidas, así también, la gente
de negocios adquiere mayor confianza en sus propias decisiones y las
del resto, y logra un mayor entendimiento de los impactos de sus
decisiones.

Impacto positivo sobre los procesos empresaria: cuando la gente
accede a mejorar calidad de información, la empresa puede mejorar:
32


o Eliminar los retardos de los procesos empresariales que resultan de
información incorrecta, inconsistente y/o no existente.

o Integrar y optimizar procesos empresariales a través del uso
compartido e integrado de las fuentes de información.

o Eliminar la producción y el procesamiento de datos que no son
usados, ni necesarios, producto de aplicaciones mal diseñadas.

Características de un DWH.

Permite realizar un análisis rápido de los requerimientos estratégicos
establecidos a diferente nivel de detalle.

Utiliza data validada de los sistemas transaccionales.

Orientado al tema de sólo lectura e histórico.

Estructura la data para la optimización de las consultas y su
distribución en forma consolidada.

Fig. 4 Estructura básica de un DWH.

33


3.4.2 Data Mart

Un Data Mart, es un subconjunto de un DWH, con un alcance de contenido
limitado. Éste se usa para un solo departamento de una organización y/o un
problema particular de análisis dentro de la organización.

El Data Mart es un sistema orientado a la consulta, en el que se producen
procesos batch de carga de datos (altas) con una frecuencia baja y conocida.
Es consultado mediante herramientas OLAP (On line Analytical Processing -
Procesamiento Analítico en Línea) que ofrecen una visión multidimensional
de la información. Sobre estas bases de datos se pueden construir EIS
(Executive Information Systems, Sistemas de Información para Directivos) y
DSS (Decision Support Systems, Sistemas de Ayuda a la toma de
Decisiones).

Razones para crear un Data Mart

Fácil acceso a los datos que se necesitan frecuentemente.
Crea vista colectiva para grupo de usuarios.
Mejora el tiempo de respuesta del usuario final.
Facilidad de creación.
Costo inferior al de la aplicación de un completo almacén de datos.
Los usuarios potenciales son más claramente identificables que en un
almacén de datos completo.

Ventajas y desventajas de desarrollar un Data Mart o DWH

a. De un DWH a un Data Mart.

Las características planteadas por Bill Inmon se engloban en una metodología
top-down, según la cual, debemos ir desde una visión más general de las
distintas partes que componen nuestro almacén y posteriormente ir
concretando y refinando cada una de las partes por separado. Por ello, según
este autor, una vez que hemos desarrollado nuestro DWH, es cuando

34


podemos abordar el desarrollo de los Data Mart (DM). Los DM son
subconjuntos de datos de un DWH para áreas específicas.

Entre las pérdidas inherentes al uso de datamarts están la escalabilidad
limitada, la duplicación de datos, la inconsistencia de los datos con respecto a
otros almacenes de información y la incapacidad para aprovechar las fuentes
de datos de la empresa. (INMON, 2000)

Fig. 5 Del DWH al Data Mart

Ventajas

Campos compartidos (dimensiones comunes)
Origen común
Procesamiento distribuido

Desventajas

Tiempo largo de desarrollo

b. Del Data Mart a un Data Warehouse

La metodología del Bill Inmon, top-down, se contrapone con la metodología
bottom-up que defienden otros autores como Ralph Kimball, el cual define un
DWH como: “Una copia de las transacciones de datos específicamente
estructurada para la consulta y el análisis".

35


Un DWH no es más que: "la unión de todos los Data Marts de una entidad"
(KIMBALL, 1998). Ahora bien, una vez almacenados los datos de la
empresa, se pueden emplear aplicaciones para la obtención estructurada de lo
que se quiera consultar en cada momento. Sin embargo y como afirman los
dos autores, los DWH se diferencian en muchos factores con respecto a los
entornos operacionales, lo que les hace tener una mayor potencia a la hora de
realizar búsquedas sobre los datos en entornos orientados a la toma de
decisión, aunque en otro tipo de situaciones las BBDD operacionales podrían
funcionar mejor.

Fig. 6 Del DWH al Data Mart

Ventajas

Simple y rápido
Datos Departamentales
Procesamiento distribuido

Desventajas

Duplicidad de data
Posible incompatibilidad de los data mart al hacer análisis conjunto.

3.4.3 Diseño de un DWH

3.4.3.1 Modelo dimensional

36


Diseño dimensional es la técnica de diseño de base de datos que estructura la
información para poder ser accesada y analizada fácil y eficientemente.

Tabla Dimensional. Son atributos textuales que describen la forma cómo se
va a analizar la información, presentan una o más jerarquías para que el
usuario final pueda explotar la información.

Tabla Hecho. Incluye las medidas cómo parte de sus atributos, es lo que se
desea analizar, además en ella se ubican las claves foráneas de las
dimensiones.

Medidas. Representan el valor a ser analizado. Estas medidas deben ser
numéricas y permitirán realizar agregados de la información y servirán de
base para ejecutar cálculos.

Grano. Determina el nivel mínimo de análisis, sirve para: determinar los
requerimientos de datos, escoger el nivel más bajo de detalle, proporciona
capacidad de análisis del detalle de los datos.

Fig. 7 Componentes modelo dimensional

37


TIPOS DE MODELO DIMENSIONAL

3.4.3.1.1 Modelo estrella

El esquema en estrella es el más sencillo de los esquemas de almacenamiento
de datos. Se llama así porque el diagrama se asemeja a una estrella, con los
puntos que irradian desde un centro. El centro de la estrella consta de una o
más tablas de hechos y los puntos de la estrella son las tablas de dimensiones.

En concreto este esquema en estrella es ideal por su simplicidad y velocidad
para ser usado en análisis multidimensionales como los DM, ya que permite
acceder tanto a datos agregados como de detalle. Además, ofrece la
posibilidad de implementar la funcionalidad de una base de datos
multidimensional utilizando una clásica base de datos relacional.

El esquema en estrella consiste en estructurar la información en procesos,
vistas y métricas a modo de estrella. En la tabla de hechos encontramos los
atributos destinados al hecho que constituye el proceso de negocio a medir, es
decir, sus métricas.

Mientras, en las tablas de dimensión, los atributos se destinan a elementos de
nivel (que representan los distintos niveles de las jerarquías de dimensión) y a
atributos de dimensión (encargados de la descripción de estos elementos de
nivel). En el esquema en estrella la tabla de hechos es la única tabla que tiene
múltiples joins que la conectan con otras tablas. El resto de tablas del
esquema (tablas de dimensión) únicamente hacen join con esta tabla de
hechos. Las tablas de dimensión se encuentran además totalmente
desnormalizadas, es decir, toda la información referente a una dimensión se
almacena en la misma tabla.

38


Fig. 8 Modelo Estrella

3.4.3.1.2 Modelo copo de nieve

El esquema en copo de nieve (snowflake) es un esquema de representación
derivado del esquema en estrella, en el que las tablas de dimensión se
normalizan en múltiples tablas. Por esta razón, la tabla de hechos deja de ser
la única tabla del esquema que se relaciona con otras tablas, y aparecen
nuevas join o uniones entre tablas gracias a que las dimensiones de análisis se
representan ahora en tablas de dimensión normalizadas. En la estructura
dimensional normalizada, la tabla que representa el nivel base de la
dimensión es la que hace join directamente con la tabla de hechos. La
diferencia entre ambos esquemas (estrella y copo de nieve) reside entonces en
la estructura de las tablas de dimensión. Para conseguir un esquema en copo
de nieve se ha de tomar un esquema en estrella y conservar la tabla de hechos,
centrándose únicamente en el modelado de las tablas de dimensión, que si
bien en el esquema en estrella se encontraban totalmente desnormalizadas,
ahora se dividen en sub tablas tras un proceso de normalización.

39


Es posible distinguir dos tipos de esquemas en copo de nieve, un snowflake
completo (en el que todas las tablas de dimensión en el esquema en estrella
aparecen normalizadas) o un snowflake parcial (sólo se lleva a cabo la
normalización de algunas de ellas). (ORACLE Corporation, 2005)

Fig. 9 Modelo Copo de Nieve

3.4.4. Extraer, transformar y cargar (ETL)

El proceso trata de recuperar los datos de las fuentes de información y
alimentar el datawarehouse, consume entre el 60% y el 80% del tiempo de un
proyecto de Business Intelligence, por lo que es un proceso clave en la vida
de todo proyecto.

La extracción, transformación y carga (el proceso ETL) es necesario para
acceder a los datos de las fuentes de información al datawarehouse.

El proceso ETL se divide en 5 subprocesos:

40


3.4.4.1 Extracción.

La extracción de los datos se puede realizar bien de forma manual o bien
utilizando herramientas de ETL que extraigan los datos de las fuentes de
datos origen, aunque en otros casos se opta por las utilidades de replicar la
base de datos que tienen los motores de bases de datos. La alternativa más
rentable es las que proveen las herramientas especializadas de ETL, ya que
han sido diseñadas para llevar a cabo esta función y nos permiten visualizar el
proceso y detectar los errores durante el proceso o durante la carga. El
principal objetivo de la extracción es extraer tan sólo aquellos datos de los
sistemas transaccionales que son necesarios y prepararlos para el resto de los
subprocesos de ETL.

Normalmente hablamos de almacenes de datos intermedios (Data staging)
mientras que estamos en el proceso de limpieza de los datos. Se trata de un
paso intermedio entre la extracción y las etapas posteriores: Acumulamos
datos de distintas fuentes, en un momento determinado todos estos datos se
cargarán en el datawarehouse. Los usuarios finales nunca acceden a este
entorno.

3.4.4.2 Limpieza.

Los sistemas transaccionales contienen datos que no han sido depurados y
que deben ser limpiados. Las herramientas ETL tienen funcionalidades de
limpieza de datos, aunque existen herramientas especializadas para ello.
Veamos algunos ejemplos de datos “sucios”.

Ausencia de valor.
Campos que tienen distintas utilidades: Para algunos clientes ponemos
una información y para otros, otra distinta.
Valores crípticos.
Valores contradictorios.
Uso inapropiado de los campos, por ejemplo en las direcciones de los
clientes.

41


Vulneración de las reglas de negocio.
Reutilización de claves primarias con valores que se habían utilizado
en el pasado.
Identificadores que no son únicos.
Problemas de carga de antiguos sistemas o de integración entre
sistemas.
Selección del primer valor de una lista por defecto.

La limpieza de datos se divide en distintas etapas, que vamos a describir a
continuación:

Depurar los valores (Parsing63): Este proceso localiza e identifica
los elementos individuales de información en las fuentes de datos y
los aísla en los ficheros destino. Por ejemplo: separar el nombre
completo en nombre, primer apellido, segundo apellido, o la dirección
en: calle, numero, piso, etcétera.
Corregir (Correcting): Este proceso corrige los valores individuales
de los atributos usando algoritmos de corrección y fuentes de datos
externas. Por ejemplo: comprueba una dirección y el código postal
correspondiente.
Estandarizar (Standardizing): Este proceso aplica rutinas de
conversión para transformar valores en formatos definidos (y
consistentes) aplicando procedimientos de estandarización y definidos
por las reglas del negocio. Por ejemplo: trato de Sr., Sra., etc. o
sustituyendo los diminutivos de nombres por los nombres
correspondientes.
Relacionar (Matching): Este proceso busca y relaciona los valores
de los registros, corrigiéndolos y estandarizándolos, basándose en
reglas de negocio para eliminar duplicados. Por ejemplo:
identificando nombres y direcciones similares.
Consolidar (Consolidating): Este proceso analiza e identifica
relaciones entre registros relacionados y los junta en una sola
representación.

42


3.4.4.3 Transformación.

La transformación de los datos se hace partiendo de los datos una vez
“limpios”. Transformamos los datos de acuerdo con las reglas de negocio y
los estándares que han sido establecidos. La transformación incluye: cambios
de formato, sustitución de códigos, valores derivados y agregados. Los
agregados, como por ejemplo la suma de las ventas, normalmente se pre-
calculan y se almacenan para conseguir mayores rendimientos cuando
lanzamos las consultas que requieren el cálculo de totales al datawarehouse.

En este proceso también ajustamos el nivel de granularidad o detalle.
Podemos tener detalle a nivel de líneas de factura en los datos extraídos, pero
en el datawarehouse lo que almacenamos son las ventas semanales o
mensuales.

3.4.4.4 Integración.

La última etapa es la de integración en el datawarehouse: es el momento en el
que cargamos los datos y debemos comprobar si, por ejemplo, los totales de
ventas que hemos cargado coinciden con la información que residía en
nuestro sistema transaccional, así como si los valores que tienen los registros
cargados corresponden a los definidos en el datawarehouse. Es fundamental
comprobar que se ha desarrollado correctamente, ya que en caso contrario
pueden llevar a decisiones erróneas a los usuarios.

3.4.4.5 Actualización.

Este proceso determina la periodicidad con el que haremos nuevas cargas de
datos al datawarehouse.

3.4.5. Proceso analítico en línea (OLAP)

Es una tecnología utilizada en la Inteligencia de negocios, cuyo objetivo es
agilizar la consulta de grandes cantidades de datos. Para ello utiliza
estructuras multidimensionales (o Cubos OLAP) que contienen datos
resumidos de grandes Bases de datos o Sistemas Transaccionales (OLTP). Se
43


usa en informes de negocios de ventas, marketing, informes de dirección,
minería de datos y áreas similares.

La razón de usar OLAP para las consultas es la rapidez de respuesta. Una
base de datos relacional almacena entidades en tablas discretas si han sido
normalizadas. Esta estructura es buena en un sistema OLTP pero para las
complejas consultas multitabla es relativamente lenta. Un modelo mejor para
búsquedas (aunque peor desde el punto de vista operativo) es una base de
datos multidimensional.

En la base de cualquier sistema OLAP se encuentra el concepto de cubo
OLAP (también llamado cubo multidimensional o hipercubo). Se compone de
hechos numéricos llamados medidas que se clasifican por dimensiones. El
cubo de metadatos es típicamente creado a partir de un esquema en estrella o
copo de nieve, esquema de las tablas en una base de datos relacional. Las
medidas se obtienen de los registros de una tabla de hechos y las dimensiones
se derivan de la dimensión de los cuadros.

Tradicionalmente, los sistemas OLAP se clasifican según las siguientes
categorías:

ROLAP. Implementación OLAP que almacena los datos en un motor
relacional. Típicamente, los datos son detallados, evitando las
agregaciones y las tablas se encuentran desnormalizadas Los
esquemas más comunes sobre los que se trabaja son estrella o copo de
nieve, aunque es posible trabajar sobre cualquier base de datos
relacional. La arquitectura está compuesta por un servidor de banco de
datos relacional y el motor OLAP se encuentra en un servidor
dedicado. La principal ventaja de esta arquitectura es que permite el
análisis de una enorme cantidad de datos.
MOLAP. Esta implementación OLAP almacena los datos en una base
de datos multidimensional. Para optimizar los tiempos de respuesta, el
resumen de la información es usualmente calculado por adelantado.
Estos valores pre-calculados o agregaciones son la base de las

44


ganancias de desempeño de este sistema. Algunos sistemas utilizan
técnicas de compresión de datos para disminuir el espacio de
almacenamiento en disco debido a los valores pre-calculados.
HOLAP. Almacena algunos datos en un motor relacional y otros en
una base de datos multidimensional.

3.4.6 Metodologías para la construcción de un DWH.

3.4.6.1 Metodología propuesta por Bill Inmon

Esta metodología la definió su autor en el año 1992 en el libro “Building the
Data Warehouse”. En él proponía los mecanismos necesarios para llevar a
cabo la correcta realización de un DWH.

Para Bill Inmon, el diseño de un DWH comienza ya con la mera introducción
de datos en el mismo, debido a las grandes cargas de datos que deben hacerse
antes de su introducción en el DWH, dependiendo de ello la eficiencia de
estos sistemas para acceder a los datos. Además, la definición de Inmon
sustenta uno de los principios fundamentales del desarrollo de un DWH, el
principio que el ambiente de origen de los datos y el ambiente de acceso de
datos deben estar físicamente separados en diferentes bases de datos y en
equipos separados. Por último, los actuales sistemas tienen gran cantidad de
datos, lo que hace poco realista el intentar hacer cargas cada poco tiempo. Si
el volumen de datos no está cuidadosamente gestionado y condensado, dicho
volumen de datos impide que los objetivos del DWH se alcancen.

A Inmon se le asocia frecuentemente con los DWH a nivel empresarial, que
involucran desde un inicio todo el ámbito corporativo, sin centrarse en un
incremento específico hasta después de haber terminado completamente el
diseño del DWH. En su filosofía, un DM es sólo una de las capas del DWH y
los DM son dependientes del depósito central de datos o DWH Corporativo y
por lo tanto se construyen después de él. El enfoque de Inmon de desarrollar
una estrategia de DWH e identificar las áreas principales desde el inicio del
proyecto es necesario para asegurar una solución integral ya que esto ayuda a
evitar la aparición de situaciones inesperadas que puedan poner en peligro el
45


proyecto, debido a que se conoce con antelación y bastante exactitud la
estructura que presentarán los principales núcleos del desarrollo, lo que
permite enfocar los esfuerzos del desarrollo actual para ser compatible con los
subsiguientes.

Inmon es defensor de utilizar el modelo relacional para el ambiente en el que
se implementará el DWH Corporativo, ya que como él mismo afirma, la
creación de una base de datos relacional con una ligera normalización, son la
base de los DM. O lo que es lo mismo, a partir de los esquemas relacionales,
a los que se les irá añadiendo complejidad, se obtendrán finalmente los DM.
El desarrollo de la metodología propuesta por Inmon en se aprecia en la
siguiente figura:

Fig. 10 Desarrollo del DWH según la metodología de Bill Inmon

La metodología de Inmon tiene un enfoque a modo de explosión en el sentido
de que en cierto modo no viene acompañada del ciclo de vida normal de las
aplicaciones, sino que los requisitos irán acompañando al proyecto según
vaya comprobándose su necesidad. Esta visión de Inmon puede traer consigo
mucho riesgo a la compañía, ya que invierte grandes esfuerzos en el
46


desarrollo del DW y no es hasta la aparición de los DM cuando se empieza a
explotar la inversión y obtener beneficios.

Esta estrategia se contempla en el marco de que es imposible conocer cuáles
son las necesidades concretas de información de una empresa, el ambiente
dinámico en que se mueve la organización, el cambio de estructura que
conlleva el desarrollo de la nueva plataforma y los consiguientes cambios a
los sistemas transaccionales que su introducción implica. Esto hace muy
probable que después de la gran inversión en tiempo y recursos en el
desarrollo del DWH, se haga patente la necesidad de cambios fundamentales
que traen consigo altos costos de desarrollo para la organización, poniendo en
evidente peligro el éxito de todo el proyecto en sí y que podían ser evitados
con una pronta detección en una temprana puesta en explotación de un primer
avance del DWH.

Esta metodología para la construcción de un sistema de este tipo es frecuente
a la hora de diseñar un sistema de información, utilizando las herramientas
habituales como el esquema Entidad/Relación pero al tener un enfoque
global, es más difícil de desarrollar en un proyecto sencillo, pues estamos
intentando abordar el “todo”, a partir del cual luego iremos al “detalle”. Esta
es otra de las restricciones que trabajan en contra de la metodología de Inmon
ya que implica un consumo de tiempo mayor, teniendo como consecuencia
que muchas empresas se inclinen por usar metodologías con las que obtengan
resultados tangibles en un espacio menor de tiempo.

3.4.6.2 Metodología Kimball

Ralph Kimball es el autor considerado como el "Gurú" del DWH junto con
Bill Inmon. Su metodología se ha convertido en el estándar de facto en el área
de apoyo a las decisiones empresariales.

En el año 1998 dicha metodología se recoge como proceso a seguir en el
desarrollo de un DWH. La siguiente figura muestra de forma esquemática las
fases que componen la metodología propuesta por Kimball y los siguientes
apartados resumen el contenido de cada una de las fases.
47


Fig. 11 Ciclo de vida de la metodología de Ralph Kimball

3.4.6.2.1 Planificación del Proyecto

La planificación busca identificar la definición y el alcance del proyecto de
DWH, incluyendo las justificaciones del negocio y las evaluaciones de
factibilidad. Esta etapa se concentra sobre la definición del proyecto. “Antes
de comenzar un proyecto de datawarehouse o datamart, hay que estar seguro
si existe la demanda y de dónde proviene. Si no se tiene un usuario sólido,
posponga el proyecto” (KIMBALL, 1998).

Como metodología, en esta etapa propone identificar el alcance preliminar
basándose en los requerimientos del negocio y no en fechas límites,
construyendo la justificación del proyecto en términos del negocio.

A nivel de planificación del proyecto se establece la identidad del mismo, el
personal (los usuarios, gerentes del proyecto, equipo del proyecto), desarrollo
del plan del proyecto, el seguimiento y la monitorización.

3.4.6.2.2 Definición de los Requerimientos del Negocio

Un factor determinante en el éxito de un proceso de DWH es la interpretación
correcta de los diferentes niveles de requerimientos expresados por los
distintos grupos de usuarios.

La técnica utilizada para revelar los requerimientos de los analistas del
negocio difiere de los enfoques tradicionales guiados por los datos. Los
48


diseñadores de los DWH deben entender los factores claves que guían el
negocio para determinar efectivamente los requerimientos y traducirlos en
consideraciones de diseño apropiadas.

Los usuarios finales y sus requerimientos impactan siempre en la
implementación de un DWH. Los requerimientos del negocio se posicionan
en el centro del “universo del Data Warehouse” (KIMBALL, 1998). Como
destaca siempre el autor, los requerimientos del negocio deben determinar el
alcance del DWH (qué datos debe contener, cómo deben estar organizados,
cada cuánto tiempo debe actualizarse, quiénes y desde dónde accederán, etc.).

3.4.6.2.2 Modelo Dimensional

La definición de los requerimientos del negocio determina los datos
necesarios para cumplir los requerimientos analíticos de los usuarios. Diseñar
los modelos de datos para soportar estos análisis requiere un enfoque
diferente al usado en los sistemas operacionales. Básicamente, se comienza
con una matriz donde se determina la dimensionalidad de cada indicador y
luego se especifican los diferentes grados de detalle dentro de cada concepto
del negocio, así como la granularidad de cada indicador y las diferentes
jerarquías que dan forma al modelo dimensional del negocio (MDN) o mapa
dimensional.

3.4.6.2.2 Diseño Físico

El diseño físico de la base de datos se focaliza sobre la selección de las
estructuras necesarias para soportar el diseño lógico. Un elemento principal
de este proceso es la definición de estándares del entorno de la base de datos.
La indexación y las estrategias de particionamiento se determinan también en
esta etapa. En la estrategia de particionamiento o agregación, el DWH tiene, y
debe tener, todo el detalle de información en su nivel atómico. Así, por poner
algún ejemplo, en los sectores de telecomunicaciones o banca es habitual
encontrarse con DWH con miles de millones de registros. Sin embargo, la
mayoría de consultas no necesitan acceder a un nivel de detalle demasiado
profundo. Un jefe de producto puede estar interesado en los totales de venta
49


de sus productos mes a mes, mientras que el jefe de área consulta
habitualmente la evolución de ventas de sus zonas. Incluso con el uso de
índices, la compresión de las tablas, o con una inversión millonaria en
hardware, estas consultas habituales deberían leer, agrupar y sumar decenas
de millones de registros, lo que repercutiría directamente en el tiempo de
respuesta y en el descontento de los usuarios.

Por tanto, muchas veces lo más complicado será realizar la correcta elección
de las tablas agregadas necesarias. De nada sirve crear muchos agregados si
estos no se utilizan, por lo que es necesario conocer las consultas habituales
de los usuarios para hacer la selección de las tablas agregadas.

La solución ante estas situaciones pasa siempre por la preparación de tablas
agregadas. Estas tablas deben ser versiones reducidas de las dimensiones
asociadas con la granularidad de la tabla de hechos y añaden los indicadores
de las tablas de detalle a un nivel superior. Por ejemplo, las ventas podrían
pre-calcularse a nivel mensual, o por cliente, o por producto. De esta manera,
las consultas típicas del jefe de producto o del jefe de área podrían ejecutarse
en pocos segundos, sin necesidad de acceder a la tabla de ventas detalladas.
La existencia de estas tablas agregadas debe ser completamente transparente
para el usuario de negocio. Es decir, tanto el jefe de área como el jefe de
producto trabajarán con el indicador "Ventas", y la herramienta de BI hará el
resto.

Por otro lado, en la estrategia de indexación los índices son estructuras
opcionales optimizadas y orientadas a conjuntos de operaciones. Según Ralph
Kimball, las tablas de dimensión deben tener un único índice sobre las claves
primarias y sería recomendable que el índice estuviera compuesto de un único
atributo. Además recomienda el uso de índices de tipo árbol-B en atributos de
alta cardinalidad y aplicar los índices de mapas de bits en atributos de
cardinalidad media o baja.

La clave principal de la tabla de hechos es casi siempre un subconjunto de las
claves externas, de manera que se elegirá un índice concatenado de las

50


principales dimensiones de la tabla de hechos y dado que muchas consultas
tienen relación con la dimensión fecha, ésta debería liderar el índice definido.
Además, el atributo fecha en la primera posición permitirá aumentar la
velocidad de los procesos de carga de datos que se agrupan por fecha y, dado
que la mayoría de los optimizadores de consulta de los sistemas de gestión de
bases de datos permiten que se utilice más de un índice a la hora de resolver
una consulta, es posible construir diferentes índices en las demás claves
ajenas de la tabla de hechos.

3.4.6.2.3 Diseño y Desarrollo de la Presentación de Datos

Esta etapa es típicamente la más subestimada de las tareas en un proyecto de
DWH. Las principales actividades de esta fase del ciclo de vida son: la
extracción, la transformación y la carga (ETL process). Se definen como
procesos de extracción aquellos requeridos para obtener los datos que
permitirán efectuar la carga del Modelo

Físico diseñado. Así mismo, se definen como procesos de transformación los
procesos para convertir o recodificar los datos fuente a fin de poder efectuar
la carga efectiva del Modelo Físico. Por otra parte, los procesos de carga de
datos son los procesos requeridos para poblar el DWH.

Todas estas tareas son altamente críticas pues tienen que ver con la materia
prima del DWH: los datos. La desconfianza y pérdida de credibilidad del
DWH provocará efectos inmediatos e inevitables si el usuario se encuentra
con información inconsistente. Es por ello que la calidad de los datos es un
factor determinante en el éxito de un proyecto de DWH. Es en esta etapa
donde deben sanearse todos los inconvenientes relacionados con la calidad de
los datos fuente. Para cumplir con estas premisas es necesario tener en cuenta
ciertos parámetros a la hora de desarrollar las tablas de dimensión y la tabla
de hechos.

51


3.4.6.2.4 Diseño de la Arquitectura Técnica

Los entornos de DWH requieren la integración de numerosas tecnologías. Se
deben tener en cuenta tres factores: los requerimientos del negocio, los
actuales entornos técnicos y las directrices técnicas y estratégicas futuras
planificadas por la compañía para poder establecer el diseño de la arquitectura
técnica del entorno de DWH.

Algunos equipos de trabajo no entienden las ventajas de una arquitectura y
tienen la sensación de que las tareas son demasiado opacas, por lo que
entienden su diseño como una distracción y un obstáculo para el progreso del
DWH, así que optan por omitir el diseño de la arquitectura. Sin embargo, hay
otros equipos de trabajo que dedican un tiempo demasiado grande para el
diseño arquitectónico. El autor Ralph Kimball recomienda no irse a ninguno
de los dos extremos para hacerlo de una manera intermedia. Para ello propone
un proceso de 8 pasos para asegurar un correcto diseño arquitectónico sin
extenderse demasiado en el tiempo.

Establecer un Grupo de Trabajo de Arquitectura: Es muy útil disponer
de un pequeño grupo de trabajo de dos a tres personas que se centren
en el diseño de la arquitectura. Por lo general, es el arquitecto técnico,
trabajando con los datos de diseño, el que estará al frente de este
grupo de trabajo. Este grupo necesita establecer sus estatutos y la línea
de prestaciones en el tiempo. También es necesario educar al resto del
equipo sobre la importancia de una arquitectura.
Requisitos relacionados con la arquitectura La arquitectura se crea
para apoyar las necesidades del negocio, la intención no es comprar
más productos. En consecuencia, el elemento fundamental para el
proceso de diseño de la arquitectura proviene de los requerimientos de
negocio obtenidos en esa fase de definición. El enfoque principal es
descubrir las implicaciones arquitectónicas asociadas a las
necesidades críticas del negocio, por lo que además de aprovechar la
definición de los requisitos del proceso de negocio, también se llevan
a cabo entrevistas adicionales dentro de la organización para
52


comprender la normativa vigente dentro del marco tecnológico,
instrucciones técnicas previstas y los límites no negociables.
Documento de requisitos arquitectónicos Una vez definidos los
requerimientos de negocio y llevado a cabo las entrevistas
suplementarias es momento de documentar las conclusiones. La forma
de hacerlo ha de ser sencilla pues el objetivo es tener una lista con
cada requisito de negocio que tiene impacto en la arquitectura.
Desarrollo de un modelo arquitectónico de alto nivel Una vez que los
requisitos de la arquitectura se han documentado es hora de empezar a
formular modelos para apoyar las necesidades identificadas. Para ello
se dividen los equipos de trabajo según los componentes principales,
como el acceso a datos, metadatos y la infraestructura. A partir de
aquí, los equipos definen y refinan el modelo arquitectónico de alto
nivel.
Diseño y especificación de los subsistemas Una vez llegados a este
punto es momento de hacer un diseño detallado de los subsistemas.
Para cada componente, el grupo de trabajo diseña una lista con las
capacidades necesarias de dicho componente. Por otro lado se tienen
en cuenta las necesidades de seguridad, así como la infraestructura
física y las necesidades de configuración. En algunos casos, las
opciones de infraestructura, tales como el hardware del servidor y el
software de base de datos, están predeterminados por la propia
empresa. El tamaño, escalabilidad, rendimiento y flexibilidad son
factores clave a considerar al determinar el papel de los cubos OLAP
en el conjunto de la arquitectura técnica.
Determinar las fases de aplicación de la Arquitectura. Es probable que
no se puedan poner en práctica todos los aspectos de la arquitectura
técnica a la vez. Algunos no son negociables, mientras que otros se
pueden aplazar a una fecha posterior; éstos, son los requisitos de
negocios para establecer las prioridades de la arquitectura.
Documento de la Arquitectura Técnica. Se debe de documentar la
arquitectura técnica, incluyendo las fases de la implementación

53


prevista. El documento de arquitectura incluirá información adecuada
de manera que los profesionales cualificados puedan proceder con la
construcción del sistema.
Revisar y finalizar la Arquitectura Técnica. El plan de la arquitectura
se debe comunicar con diferentes niveles de detalle: equipo de
proyecto, sponsor y director del proyecto. Tras la revisión, la
documentación debe ser actualizada y utilizada inmediatamente en el
proceso de selección del producto.

3.4.6.2.5 Selección de Productos e Instalación

Utilizando el diseño de arquitectura técnica como marco es necesario
evaluar y seleccionar los componentes específicos de la arquitectura,
como la plataforma de hardware, el motor de base de datos, la
herramienta de ETL, las herramientas de acceso, etc.
Una vez evaluados y seleccionados los componentes determinados se
procede con la instalación y prueba de los mismos en un ambiente
integrado de DWH. Para ello es necesario tener en cuenta una serie de
premisas que recomienda el autor de esta metodología:
Comprender el proceso de compras corporativas. El primer paso antes
de seleccionar nuevos productos es entender el hardware y el software
interno, así como los procesos de aprobación de compras por parte de
la empresa. Los gastos deben ser aprobados por el departamento
correspondiente de la empresa.
Elaborar una matriz de evaluación del producto. Con el plan de la
arquitectura como punto de partida se desarrolla una matriz de
evaluación empleando, por ejemplo, hojas de cálculo en donde se
identificarán los criterios de evaluación, junto con factores de
ponderación para indicar su importancia. Cuanto más específico sea el
criterio, mejor. Estos criterios podrían incluir la funcionalidad,
arquitectura técnica, características del software, impacto en las
infraestructuras y viabilidad de los proveedores.

54

Sistema de soporte de decisiones para la gestión académica de la ULADECH

Sistema de soporte de decisiones para la gestión académica de la ULADECH

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Sistema de soporte de decisiones para la gestión académica de la ULADECH

Similar a Sistema de soporte de decisiones para la gestión académica de la ULADECH (20)

Más de Julio César Álvarez Reyes

Más de Julio César Álvarez Reyes (9)

Último

Último (20)

Sistema de soporte de decisiones para la gestión académica de la ULADECH