Está en la página 1de 146

CONSTRUCCIÓN DE UN PROTOTIPO DE DATAMART PARA REALIZAR

INTELIGENCIA DE NEGOCIOS CON LOS RESULTADOS DE LAS PRUEBAS SABER 5°


Y 9° DURANTE EL PERIODO 2017-2019.

DIEGO ALEJANDRO PARRA DAZA


20141020063

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERÍA DE SISTEMAS

BOGOTÁ D.C.
2021
CONSTRUCCIÓN DE UN PROTOTIPO DE DATAMART PARA REALIZAR
INTELIGENCIA DE NEGOCIOS CON LOS RESULTADOS DE LAS PRUEBAS
SABER 5° Y 9° DURANTE EL PERIODO 2017-2019.

DIEGO ALEJANDRO PARRA DAZA


20141020063

PROYECTO DE GRADO

DIRECTORA
ALBA CONSUELO NIETO LEMUS
MSc. INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERÍA DE SISTEMAS

BOGOTÁ D.C.
2021
AGRADECIMIENTOS

Quiero agradecer a la Universidad Distrital Francisco José de Caldas por acogerme


durante todo este tiempo de formación y que me permitió estar rodeado de
excelentes docentes que me dieron los conocimientos y valores necesarios para
poderle aportar con ellos a la sociedad. De la misma manera al grupo de
investigación GESDATOS de la universidad Distrital donde trabaje temas que
dieron origen a este proyecto.

Agradezco a mi directora de tesis MSc. Alba Consuelo Nieto Lemus, por toda la
dedicación, la paciencia y orientación durante el desarrollo de este proyecto, por
haber trasmitido todos sus conocimientos incondicionalmente. Fue muy importante
en esta etapa contar con su ayuda.

A mi jurado, Ph.D. Sonia Ordóñez Salinas, que mediante su labor tomo el tiempo
para leer, revisar y dar sus aportes para tener en cuenta en el desarrollo de esta
investigación.

Finalmente, pero no menos importante agradecer a mi familia, quienes son mi


mayor fuente de motivación y apoyo en todo momento, además me inculcaron los
valores que me caracterizan, también por su incentivo en mi formación personal y
profesional.
TABLA DE CONTENIDO

1. DESCRIPCION DEL PROYECTO .................................................................... 13


1.1 INTRODUCCIÓN ..................................................................................... 13
1.2 PLANTEAMIENTO DEL PROBLEMA ...................................................... 14
1.2.1 CONTEXTO DEL PROBLEMA .......................................................... 14
1.2.2 FORMULACIÓN DEL PROBLEMA ................................................... 16
1.3 OBJETIVOS ............................................................................................. 16
1.3.1 OBJETIVO GENERAL ....................................................................... 16
1.3.2 OBJETIVOS ESPECIFICOS ............................................................. 17
1.4 JUSTIFICACIÓN ...................................................................................... 17
1.4.1 ACADÉMICA ..................................................................................... 17
1.4.2 SOCIAL ............................................................................................. 17
1.4.3 INVESTIGATIVA................................................................................ 17
1.5 ALCANCES Y LIMITACIONES ................................................................ 18
1.5.1 ALCANCES ....................................................................................... 18
1.5.2 LIMITACIONES ................................................................................. 18
2. MARCO TEÓRICO ......................................................................................... 19
2.1 BODEGA DE DATOS (DATA WAREHOUSE - DW) ................................ 19
2.2 DATAMART ............................................................................................. 20
2.3 MODELO DIMENSIONAL Y LENGUAJE DE CONSULTA MDX ............. 21
2.4 INTELIGENCIA DE NEGOCIOS .............................................................. 22
2.5 METODOLOGÍAS DE DESARROLLO DE BODEGAS DE DATOS ......... 22
2.5.1 METODOLOGÍA DE RALPH KIMBALL ............................................. 22
2.5.2 METODOLOGÍA DE BILL INMON ..................................................... 24
2.5.3 METODOLOGÍA DE CHRISTODMAN .............................................. 25
2.6 ESTRATEGIAS O MECANISMOS DE PERSISTENCIA PARA BODEGAS
DE DATOS O DATAMARTS .............................................................................. 26
2.6.1 MODELOS RELACIONALES ............................................................ 26
2.6.2 MODELOS NO RELACIONALES ...................................................... 26
2.7 MARCO CONCEPTUAL DEL ÁREA DE CONOCIMIENTO ESPECÍFICO
27
2.7.1 PROPÓSITO DE LAS PRUEBAS SABER 3°, 5° Y 9° ....................... 27
2.7.2 PRUEBAS QUE SE REALIZAN......................................................... 28
2.7.3 PERIODICIDAD ................................................................................. 29
2.7.4 COBERTURA .................................................................................... 29
2.7.5 ¿QUÉ SE MIDE? ............................................................................... 30
2.7.6 TIPOS DE RESULTADOS ................................................................. 31
2.7.7 VALORES PLAUSIBLES ................................................................... 32
2.8 HERRAMIENTAS TECNOLÓGICAS PARA LA IMPLEMENTACIÓN DE
BODEGAS DE DATOS - DATAMARTS ............................................................. 33
2.8.1 PENTAHO ® ...................................................................................... 33
2.8.2 SPAGO BI ® [21] ............................................................................... 34
2.8.3 ORACLE DATABASE 11G ® [22]...................................................... 35
2.8.4 SQL SERVER DATA WAREHOUSE ® [23] ...................................... 35
3. MARCO REFERENCIAL ................................................................................ 36
3.1 ESTADO DE ARTE INVESTIGATIVO ICFES SOBRE LAS PRUEBAS
SABER 3°, 5° Y 9° ............................................................................................. 36
3.2 OTROS ESTUDIOS DE INTERÉS ........................................................... 37
4. MARCO METODOLÓGICO ............................................................................ 38
4.1 IMPLEMENTACIÓN DE LA METODOLOGÍA DE RALPH KIMBALL PARA
EL PROYECTO.................................................................................................. 38
4.2 METODOLOGÍA DE DESARROLLO DE PROYECTOS – SCRUM [28] .. 40
5. DESARROLLO DEL PROYECTO .................................................................. 42
5.1 DESCRIPCIÓN DE LA METODOLOGÍA DE DESARROLLO DEL
PROYECTO ....................................................................................................... 42
5.2 DESARROLLO DEL SPRINT 1 ................................................................ 47
5.2.1 ESTRATEGIA PARA EL LEVANTAMIENTO DE REQUERIMIENTOS
47
5.2.2 CASOS DE USO ............................................................................... 54
5.2.3 DOCUMENTACIÓN DE LOS CASOS DE USO ................................ 57
5.2.4 IDENTIFICAR LAS FUENTES DE DATOS ....................................... 70
5.2.5 EXPLORACIÓN DE DATOS.............................................................. 72
5.2.6 DESCARGA E INSTALACIÓN DE LA HERRAMIENTA PENTAHO [33]
[34]. 78
5.2.7 DISEÑO DE LA ARQUITECTURA DEL SISTEMA. ........................... 86
5.2.8 RESUMEN DEL SPRINT 1 ................................................................ 88
5.3 DESARROLLO DEL SPRINT 2 ................................................................ 88
5.3.1 MATRIZ BUS DE ALTO NIVEL ......................................................... 89
5.3.2 DEFINIR GRANO .............................................................................. 90
5.3.3 DEFINIR DIMENSIONES .................................................................. 90
5.3.4 DEFINIR MÉTRICAS ......................................................................... 97
5.3.5 DEFINIR HECHOS ............................................................................ 97
5.3.6 DISEÑO DEL MODELO DIMENSIONAL ........................................... 98
5.3.7 DISEÑO APP BI SCIRE .................................................................... 99
5.3.8 DISEÑO DEL PROCESO ETL......................................................... 102
5.3.9 RESUMEN SPRINT 2 ...................................................................... 105
5.4 DESARROLLO DEL SPRINT 3 .............................................................. 105
5.4.1 ESPECIFICAR TABLAS DE AGREGADOS .................................... 105
5.4.2 IMPLEMENTACIÓN DEL MODELO DIMENSIONAL ...................... 107
5.4.3 DEFINICIÓN DEL PROCESO DE TRANSFORMACIÓN Y CARGA 108
5.4.4 ESQUEMA DE ALMACENAMIENTO DE METADATOS DE
CONTROL .................................................................................................... 111
5.4.5 RESUMEN DEL SPRINT 3 .............................................................. 113
5.5 DESARROLLO DEL SPRINT 4 .............................................................. 113
5.5.1 VALIDACIÓN DEL CARGUE DE DATOS EN DATAMART ............. 113
5.5.2 VALIDACIÓN DEL MODELO DIMENSIONAL ................................. 115
5.5.3 VALIDACIÓN DE RESULTADOS OBTENIDOS. ............................. 115
5.5.4 EJECUCIÓN DE CONSULTAS OLAP-BI (REPORTES,
INDICADORES, AGRUPACIONES) ............................................................. 118
5.5.5 AJUSTES NECESARIOS PARA OPTIMIZAR EL PROCESO DE
CARGA 120
5.5.6 RESUMEN DEL SPRINT 4 .............................................................. 121
5.6 DESARROLLO DEL SPRINT 5 .............................................................. 121
5.6.1 INSTALACIÓN DEL PROTOTIPO ................................................... 121
5.6.2 POLÍTICAS DE ADMINISTRACIÓN Y CONFIGURACIÓN ............. 122
6. RESULTADOS OBTENIDOS ....................................................................... 124
6.1 RESULTADOS DEL PROTOTIPO FUNCIONAL ................................... 124
7. CONCLUSIONES ......................................................................................... 126
8. TRABAJO FUTURO. .................................................................................... 127
9. BIBLIOGRAFÍA ............................................................................................. 129
10. ANEXOS ................................................................................................... 131
10.1 ANEXO 1: TABLAS DE LA INFORMACIÓN SOCIOECONÓMICA EN LAS
PRUEBAS SABER 3°, 5° Y 9° PARA EL AÑO 2017. ...................................... 131
10.2 ANEXO A (DOCUMENTACIÓN) ............................................................ 132
10.2.1 DOCUMENTACIÓN DE LAS DIMENSIONES ................................. 132
10.2.2 DOCUMENTACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS
DE POSTGRESQL. ...................................................................................... 133
10.2.3 REPORTES PENTAHO SERVER ................................................... 134
10.3 ANEXO B (CÓDIGO) ............................................................................. 138
10.3.1 XML DEL CUBO OLAP (PARA EL ANÁLISIS DE COLEGIOS) ...... 138
10.3.2 PROCEDIMIENTOS ALMACENADOS ............................................ 140
ÍNDICE DE TABLAS

Tabla 1. Número de estudiantes evaluados por grado y por año [3]. .................... 14
Tabla 2. Pruebas y grados evaluados en cada año de aplicación [2]. ................... 29
Tabla 3. Número de estudiantes evaluados por grado y por año. ......................... 29
Tabla 4. Resumen de los Sprints. ......................................................................... 41
Tabla 5. Resumen sprint 1. Elaboración propia..................................................... 47
Tabla 6. Documentación caso de uso CU02-01. Elaboración propia. ................... 58
Tabla 7. Documentación caso de uso CU02-02. Elaboración propia. ................... 59
Tabla 8. Documentación caso de uso CU02-03. Elaboración propia. ................... 60
Tabla 9.Documentación caso de uso CU03-01. Elaboración propia. .................... 61
Tabla 10. Documentación caso de uso CU03-02. Elaboración propia. ................. 61
Tabla 11. Documentación caso de uso CU03-03. Elaboración propia. ................. 62
Tabla 12. Documentación de caso de uso CU03-04. Elaboración propia. ............ 63
Tabla 13. Documentación de caso de uso CU03-05. Elaboración propia. ............ 64
Tabla 14. Documentación de caso de uso CU03-06. Elaboración propia. ............ 65
Tabla 15. Documentación caso de uso CU04-01. Elaboración propia. ................. 66
Tabla 16. Documentación caso de uso CU04-02. Elaboración propia. ................. 67
Tabla 17.Documentación de casos de uso CU04-03. Elaboración propia. ........... 68
Tabla 18. Documentación de caso de uso CU04-04. Elaboración propia. ............ 69
Tabla 19. Documentación de caso de uso CU04-05. Elaboración propia. ............ 69
Tabla 20. Documentación de caso de uso CU04-06. Elaboración propia. ............ 70
Tabla 21. Descripción de los datos. Elaboración propia. ....................................... 85
Tabla 22.Matriz de bus. Elaboración propia. ......................................................... 90
Tabla 23. Tabla de convenciones del modelo dimensional. Elaboración propia. .. 90
Tabla 24. Tabla de hechos para el modelo dimensional 1. Elaboración propia. ... 92
Tabla 25.Tabla de hechos para el modelo dimensional 2. Elaboración propia. .... 92
Tabla 26. Resumen Sprint 3. Elaboración propia. ............................................... 105
Tabla 27.Documentación procedimiento almacenado CargarSocieconomicas.
Elaboración propia .............................................................................................. 111
Tabla 28.Documentación procedimiento almacenado CargarEstudiante.
Elaboración propia. ............................................................................................. 111
Tabla 29. Resumen sprint 4. elaboración propia. ................................................ 113
Tabla 30. Resultado consulta MDX para El colegio Luis Enrique Osorio.
Elaboración propia. ............................................................................................. 118
Tabla 31. Resumen sprint 5. Elaboración propia. ................................................ 121
Tabla 32. Roles PostgreSQL. elaboración propia. .............................................. 123
Tabla 33.Roles Pentaho server. elaboración propia. ........................................... 123
Tabla 34. Entregables del proyecto. elaboración propia. .................................... 124
Tabla 35.Documentación dimensión tiempo. Elaboración propia ........................ 133
Tabla 36.Documentación procedimiento almacenado CargarColegio. Elaboración
propia. ................................................................................................................. 133
Tabla 37.Documentación procedimiento almacenado CargarSede. Elaboración
propia. ................................................................................................................. 133
Tabla 38.Documentación procedimiento almacenado CargarCitacion. Elaboración
propia. ................................................................................................................. 134
Tabla 39. Documentación procedimiento almacenado CargarTiempo. Elaboración
propia. ................................................................................................................. 134
INDICE DE FIGURAS

Figura 1. Datos presentados por el Icfes en el servidor FTP................................. 16


Figura 2. Flujo de información adaptado del modelo de Kimball [1]. ..................... 20
Figura 3. DataMarts [8]. ......................................................................................... 21
Figura 4. Cubo OLAP, adaptado de la definición de Kimball. ................................ 21
Figura 5. Diagrama del ciclo de vida de Kimball [1]............................................... 23
Figura 6. Enfoque Inmon - DW Corporativo [11]. .................................................. 25
Figura 7.Modelo de puntos multidimensional [12]. ................................................ 25
Figura 8.Modelo Contexto, Insumos, Procesos y Productos (CIPP) [4] ................ 28
Figura 9.Gráfico de número de estudiantes evaluados por año. ........................... 30
Figura 10.Resultados para colegios [16]. .............................................................. 31
Figura 11.Resultados para entidades territoriales [17]. ......................................... 31
Figura 12. Distribución posterior de un test de 6 ítems [18]. ................................. 32
Figura 13. Suite de Pentaho. [20] .......................................................................... 33
Figura 14. Arquitectura de Spago BI. .................................................................... 34
Figura 15. Estructura SQL Server - Data Warehouse [23]. ................................... 36
Figura 16. Épicas del proyecto. Elaboración propia. ............................................. 42
Figura 17. Adaptación de ciclo de vida de la metodología de Kimball. .................. 43
Figura 18.Backlog del proyecto (parte1). Elaboración propia. ............................... 44
Figura 19. Backlog del proyecto (parte 2). Elaboración propia. ............................. 45
Figura 20. Historias de usuario por sprint. Elaboración propia. ............................. 46
Figura 21. Porcentaje de estudiantes según niveles de desempeño (Consulta de
un colegio al azar) [29]. ......................................................................................... 48
Figura 22.Porcentaje de estudiantes por niveles de desempeño en el
establecimiento educativo, la entidad territorial certificada (ETC) correspondiente y
el país (Consulta de un colegio al azar) [29]. ........................................................ 48
Figura 23.Puntaje promedio y desviación estándar en el establecimiento educativo,
la ETC, el país y los tipos de establecimientos de la ETC según NSE (Consulta de
un colegio al azar) [29]. ......................................................................................... 48
Figura 24.Comparación de porcentajes según niveles de desempeño por año [29].
.............................................................................................................................. 49
Figura 25. Diagrama de requerimientos funcionales para el DataMart. Elaboración
propia. ................................................................................................................... 50
Figura 26. Diagrama de requerimientos para gestión de indicadores de volumen de
estudiantes. Elaboración propia. ........................................................................... 51
Figura 27.Diagrama requerimientos para la gestión estadísticas de desempeño.
Elaboración propia. ............................................................................................... 51
Figura 28. Diagrama de requerimientos funcionales para la gestión de factores
asociados. Elaboración propia. ............................................................................. 52
Figura 29. Diagrama de requerimientos funcionales para las la gestión de
generación de reportes. Elaboración propia. ......................................................... 52
Figura 30. Diagrama de requerimientos no funcionales. Elaboración propia. ....... 53
Figura 31. Diagrama de requerimientos no funcionales para definición. Elaboración
propia. ................................................................................................................... 53
Figura 32.Diagrama de requerimientos no funcionales para configuración.
Elaboración propia. ............................................................................................... 54
Figura 33. Actores de los casos de uso del DataMart. Elaboración propia. .......... 54
Figura 34. Diagrama de casos de uso. Elaboración propia. .................................. 55
Figura 35. Casos de uso volumen de estudiantes. Elaboración propia. ................ 55
Figura 36. Casos de uso estadísticas de desempeño. Elaboración propia. .......... 56
Figura 37. Casos de uso factores asociados. Elaboración propia. ........................ 56
Figura 38. Modelo de Documentación de los casos de uso. [30] .......................... 57
Figura 39. Jerarquía de archivos en el servidor del Icfes. Elaboración propia. ..... 71
Figura 40. Importar archivo CSV en Mongo por medio de Studio 3T. Elaboración
propia. ................................................................................................................... 73
Figura 41. Consola de operaciones de Studio 3t. Elaboración propia. .................. 73
Figura 42.Salida previa de un documento de un estudiante en formato JSON.
Elaboración propia. ............................................................................................... 73
Figura 43. Descripción de la colección de los resultados de las pruebas saber 3, 5
y 9del 2017. ........................................................................................................... 74
Figura 44. número de estudiantes que presentaron la prueba saber 3, 5 y 9 en el
año 2017. Elaboración propia................................................................................ 75
Figura 45. Consulta de estudiantes que presentaron la prueba saber 3, 5 y 9 por
género en el año 2017. Elaboración propia. .......................................................... 75
Figura 46. Nivel académico de los padres (A la izquierda del padre y a la derecha
de la madre). Elaboración propia. ......................................................................... 75
Figura 47. Agregación por categoría de niveles de desempeño de los estudiantes
(A la izquierda la prueba de lenguaje y a la derecha la prueba de matemáticas).
Elaboración propia. ............................................................................................... 75
Figura 48. Valores máximos y mínimos en el área de matemáticas. Elaboración
propia. ................................................................................................................... 76
Figura 49. Valores máximos y mínimos en el área de lenguaje. Elaboración propia.
.............................................................................................................................. 77
Figura 50. Resultados para la variable "FAMI_TIENEINTERNET". Elaboración
propia. ................................................................................................................... 77
Figura 51. Tiempos en lo que los estudiantes tardan en desplazarse al colegio.
Elaboración propia. ............................................................................................... 77
Figura 52. Ejemplo de registro con valores nulos. Elaboración propia. ................. 78
Figura 53. Ventana de login de Pentaho Server. ................................................... 86
Figura 54. Arquitectura del sistema. Elaboración propia. ...................................... 87
Figura 55. Estándar de nombre del stage area. Elaboración propia. .................... 88
Figura 56.Resumen Sprint 1. Elaboración propia. ................................................. 89
Figura 57. Modelo dimensional de alto nivel 1. Elaboración propia....................... 91
Figura 58. Modelo dimensional de alto nivel 2. Elaboración propia. ...................... 91
Figura 59. Documentación dimensión estudiante. Elaboración propia. ................. 94
Figura 60. Documentación dimensión factores asociados familiares Elaboración
propia. ................................................................................................................... 95
Figura 61, Documentación dimensión factores asociados del estudiante.
Elaboración propia. ............................................................................................... 97
Figura 47. Documentación tabla de hechos. elaboración propia. .......................... 98
Figura 63. Tipos de aplicaciones BI. Adaptación de [4]......................................... 99
Figura 64. Modelo Dimensional del DataMart. Elaboración propia...................... 100
Figura 50. Plantilla básica para informes. Elaboración propia. ............................ 101
Figura 66. Tabla elaborada con Jpivot en la herramienta SCIRE. Elaboración
propia. ................................................................................................................. 102
Figura 67 Dashboard con Pentaho Server en la aplicación SCIRE. Elaboración
propia. ................................................................................................................. 102
Figura 68. BPMN del proceso ETL. Elaboración propia. ..................................... 104
Figura 69. Tabla de agregado simple para colegios y sedes. Elaboración propia.
............................................................................................................................ 106
Figura 70. Tabla de agregado colapsada para factor asociado. Elaboración propia.
............................................................................................................................ 106
Figura 71. Niveles de agregado no colapsadas en Jerarquía por fecha.
Elaboración propia. ............................................................................................. 107
Figura 72. Creación de tablas en PostgreSQL. Elaboración propia. ................... 107
Figura 73. Herramientas de Spoon para la elaboración de procesos ETL [19]. .. 108
Figura 74. Diagrama de Pentaho Data Integration para la creación de las
dimensiones. Elaboración propia. ....................................................................... 109
Figura 75. Diagrama de pentaho data inegration para el cargue de estudiantes y la
tabla de hechos. Elaboración propia. .................................................................. 109
Figura 76. Modelo de control de procesos. Elaboración propia........................... 112
Figura 77. Tarea de carga. Elaboración propia. .................................................. 112
Figura 78. Ejecución Pentaho Data Integration. Elaboración propia. .................. 114
Figura 79. Tabla de procesos. Elaboración propia. ............................................. 114
Figura 80. Tabla excepciones. Elaboración propia.............................................. 114
Figura 81. Archivos del log y de errores. Elaboración propia. ............................. 114
Figura 82. Diseño del modelo dimensional en SCIRE - validación de colegios,
sedes y grados. Elaboración propia. ................................................................... 115
Figura 83. Cantidad de estudiantes evaluados de colegio Luis Enrique Osorio.
[reporte ICFES] ................................................................................................... 116
Figura 84. Cantidad de estudiantes colegio Luis Enrique - PostgreSQL.
Elaboración propia. ............................................................................................. 116
Figura 85. Puntaje promedio en lenguaje para el colegio Luis Enrique Osorio.
Elaboración propia. ............................................................................................. 116
Figura 86.Puntaje promedio en lenguaje de estudiantes colegio Luis Enrique -
PostreSQL. Elaboración propia. .......................................................................... 117
Figura 87.Reporte 1 - Promedios y cantidad de estudiantes por grado. Elaboración
propia. ................................................................................................................. 118
Figura 88.Reporte de desempeño por área, género y periodo de tiempo.
elaboración propia. .............................................................................................. 119
Figura 89. Reporte de factor asociado estudio del padre. Elaboración propia. ... 119
Figura 90. Reporte de desempeño por factor socioeconómico de los trabajos de
los padres. Elaboración propia. ........................................................................... 120
Figura 91. Reporte de desempeño por factor socioeconómico de asistencia del
estudiante. Elaboración propia. ........................................................................... 120
Figura 92. Optimización de carga para la dimensión de sedes. Elaboración propia.
............................................................................................................................ 121
Figura 93.Plugins necesarios para la elaboración de repostes, Jpivot y
visualizaciones. Elaboración propia .................................................................... 122
Figura 94. Plugin tapa. Elaboración propia. ........................................................ 122
Figura 80.Reporte de volumen de estudiantes para el año 2017 y 2019. ........... 135
Figura 81. Reporte de volumen de estudiantes por entidad territorial. Elaboración
propia. ................................................................................................................. 135
Figura 82. Reporte de desempeño por área, género y periodo de tiempo.
Elaboración propia. ............................................................................................. 136
Figura 83. Reporte de desempeño del año 2017 y 2019 por género. Elaboración
propia. ................................................................................................................. 136
Figura 84. Reporte de desempeño según herramientas tecnológicas. Elaboración
propia. ................................................................................................................. 137
Figura 85. reporte de desempeño por factor de estudio de la madre. Elaboración
propia. ................................................................................................................. 137
Figura 86. Reporte de volumen por factores de colegio. Elaboración propia. ..... 138
Figura 87. Reporte de volumen por factores de colegio para el año 2017.
Elaboración propia. ............................................................................................. 138
1. DESCRIPCION DEL PROYECTO

1.1 INTRODUCCIÓN

El Instituto Colombiano para la Evaluación de la Educación (ICFES) es la entidad


encargada de evaluar la calidad de la educación a nivel nacional en los niveles de
básica primaria, secundaria, profesional y tecnológico. Para ello ha elaborado las
pruebas Saber 3°, 5° y 9°, entre otras, que buscan medir las competencias de los
estudiantes de educación primaria y secundaria. Se realizaron inicialmente en el
año 2009 y se tenía planeado que fueran realizadas cada 3 años, pero a partir del
año 2012 el gobierno decidió que fueran realizadas anualmente.

Estas pruebas tienen como objetivo conocer el estado actual de los conocimientos
de los estudiantes, además de hacer un seguimiento con los resultados históricos.
Son elaboradas para que las instituciones puedan conocer debilidades y fortalezas,
y que de esta manera se generen estrategias para mejorar la calidad de educación
[1]. Para el Icfes también es importante conocer las razones y factores que llevan a
estos resultados. Dichos factores se obtienen a través de información que se brinda
por parte de estudiantes, profesores y rectores, y que hace parte del entorno
personal y podría estar relacionada con el desempeño en las pruebas.

Los datos que entrega el Icfes a las entidades se presentan agregados y resumidos
estadísticamente a nivel de institución educativa y entidad territorial, basados
únicamente en el valor del resultado de cada área evaluada, dejando a un lado
información importante como los datos socioeconómicos y demográficos, que
pueden tener relaciones directas o indirectas con los resultados individuales de los
estudiantes. Por otro lado, la extracción de los datos se hace difícil para las
personas que no están familiarizadas con herramientas tecnológicas y más cuando
se trata de realizar estudios de inteligencia de negocios.

Este proyecto tuvo como finalidad construir un DataMart que facilita el análisis de
los resultados de las pruebas de 5° y 9° para los años del 2017-2019, por medio de
la inteligencia de negocios, para ver aspectos que a simple vista no son identificados
en los reportes estadísticos entregados actualmente por el Icfes. Se va a simplificar
la visualización con una herramienta open source para las personas interesadas en
la investigación, de igual manera para las instituciones educativas que quieran
conocer aspectos que le permitan generar estrategias para mejorar los resultados
de sus estudiantes en una etapa temprana de formación.
1.2 PLANTEAMIENTO DEL PROBLEMA

1.2.1 CONTEXTO DEL PROBLEMA

El Icfes es una entidad del estado ligada al Ministerio de Educación Nacional que,
en su facultad de ofrecer un servicio de evaluación de la educación por medio de
los exámenes de estado en sus diferentes niveles, publica los resultados obtenidos
para crear proyectos e investigaciones, que permitan concebir estrategias y tomar
decisiones que permitan mejorar la calidad [2].

En cumplimiento de su misión, el Icfes estableció las pruebas saber para los grados
3°, 5° y 9, entre otras. Estas pruebas se han venido aplicando desde el año 2009
hasta el 2017 con una cobertura inicial de 1’520.713, llegando hasta 2’132.611 de
evaluados. En el año 2018 no se aplicaron las pruebas por ajustes institucionales;
se aplicaron nuevamente en el año 2019 y a la fecha (2021), se está a la espera de
los resultados.

La prueba puede ser aplicada de dos maneras [3]:


• Muestral: Se selecciona una muestra simbólica de los colegios a todo el nivel
nacional. La aplicación de la prueba es responsabilidad del Icfes.
• Censal: Está dirigida a todos los estudiantes de los grados 3°, 5° y 9°. La
aplicación de la prueba es responsabilidad de las secretarias de educación y
de las instituciones educativas.

En la Tabla 1 se resume la cantidad de evaluados por año y grado. Como se puede


observar, el volumen de datos es grande, lo que implica dificultades para su
procesamiento y análisis.

3° 5° 9°
2009 0 859.624 661.089
2012 782.549 774.236 583.866
2013 772.702 759.515 578.625
2014 773.139 758.905 590.935
2015 749.851 711.610 549.240
2016 779.346 752.259 586.152
2017 762.724 778.863 591.024
Tabla 1. Número de estudiantes evaluados por grado y por año [3].

El Icfes presenta los resultados estadísticos de las pruebas (desempeño, promedio,


desviación estándar) agrupados por entidad territorial, institución educativa y
jornadas de estudio. Hasta el año 2016, las estadísticas se hacían con los valores
plausibles [4], que son posibles valores de la habilidad de cada alumno tomado de
manera aleatoria de su pertinente distribución, pero a partir del año 2017, las
estadísticas se hacen con el resultado individual que obtiene el estudiante en cada
una de las pruebas. Estos resultados son publicados en el sitio web del Icfes para
que puedan ser consultados por las entidades utilizando el código DANE asociado
a cada una de ellas. Permiten hacer comparaciones grupales de los estudiantes con
respecto a grupos similares a nivel de entidad territorial, colegio y jornada. El único
dato que se analiza en los reportes es el valor plausible o el resultado, pero no se
hacen estadísticas con otras variables, como las socioeconómicas (ver anexo 10.1).

Los datos están disponibles en el servidor FTP del Icfes, distribuidos en diferentes
carpetas como se ven en la
Figura 1. Los resultados de cada una de las pruebas se almacenan en formatos
“.txt”, “.csv” y algunos “.pdf”. La disposición de los datos se encuentra en un orden
que es poco accesible y de difícil manejo e interpretación para investigadores y
personas interesadas en hacer estudios, y que en general no conocen de la
estructura de los datos, ni de herramientas, ni de aspectos tecnológicos que
permitan su procesamiento y análisis.
Además de los resultados, también es publicada la información de los factores
socioeconómicos del estudiante, en la que se incluyen preguntas como ¿Qué bienes
posee?, ¿cómo se desplaza hacia el colegio?, ¿Qué nivel de educación tienen los
padres?, ¿Tiene internet en la casa?, entre otros, que podrían ser factores que
sirvan para entender qué condiciones pueden afectar el desempeño del estudiante
en las pruebas. Es importante aclarar que las variables socioeconómicas no son
consideradas en las estadísticas que publica actualmente el Icfes, pues como se
mencionó anteriormente, sólo se analizan los resultados grupales de la prueba.
Figura 1. Datos presentados por el Icfes en el servidor FTP1.

Finalmente, es muy difícil extraer todos los datos desde el repositorio FTP del Icfes,
porque están distribuidos en múltiples carpetas por año, y cada carpeta puede
contener información diferente. Además, los datos se presentan en distintos
formatos de archivo (csv, txt, pdf), la estructura de los archivos puede variar en a
través de los años, incluyendo o excluyendo información, lo cual dificulta la lectura
y análisis de los mismos.

En este proyecto se propone la sistematización de los procesos de extracción,


transformación y carga, para llevar los datos desde el repositorio FTP del Icfes,
hasta el DataMart, elaborando la metadata que sea necesaria para construir
reportes y hacer inteligencia de negocios que permitan analizar la relación de los
resultados de las pruebas saber 5° y 9° con las variables socioeconómicas y
demográficas.

1.2.2 FORMULACIÓN DEL PROBLEMA

¿A partir de los datos publicados por el Icfes, es factible construir un DataMart


soportado en la metodología de Ralph Kimball, que permita realizar inteligencia de
negocios, relacionando los factores asociados como el nivel de educación de los
padres, el desplazamiento del estudiante al colegio, los bienes que tiene en la casa,
el trabajo de los padres, con los resultados de las pruebas saber 5° y 9° de un
periodo particular?

1.3 OBJETIVOS

1.3.1 OBJETIVO GENERAL

Analizar, diseñar e implementar un prototipo de DataMart que sirva de herramienta


a directivos de instituciones de básica primaria y secundaria, investigadores y
entidades encargadas de definir políticas educativas en general, para apoyar la
toma de decisiones desde la inteligencia de negocios (Business Intelligence- BI) y
con el fin de analizar la incidencia de los factores asociados2, en los resultados de
las pruebas saber 5° y 9° realizadas por el Icfes durante el periodo 2017-2019.

1Es necesario generar una cuenta para acceder al siguiente enlace (ftp://ftp.icfes.gov.co/).
2Los factores asociados son componentes o elementos que se relacionan al entorno y composición
socioeconómica del estudiante, por ejemplo, uso del internet, bienes que posee en el hogar, trabajo
y nivel educativo de los padres, entre otros.
1.3.2 OBJETIVOS ESPECIFICOS

• Especificar los requerimientos de análisis de datos, tanto de estadística


básica (promedio, desviación estándar, distribución, entre otros), como de
incidencia de los factores asociados, en los resultados de las pruebas 5° y 9°
para el periodo considerado, tomando como fuente los informes publicados
por el Icfes.
• Implementar un DataMart aplicando la metodología de Kimball [1] que
permita hacer el análisis de factores asociados con respecto a los resultados
individuales obtenidos por cada estudiante en las pruebas 5° y 9°.
• Desarrollar una aplicación web, que será desplegada en un servidor de
pruebas, que permita generar reportes y consultas predefinidas para dar
respuesta a los requerimientos de análisis de datos, utilizando una
herramienta OLAP open source.
• Documentar la metodología de extracción, transformación y carga de manera
que el proceso se pueda replicar sistemáticamente con los resultados de
pruebas saber 5° y 9°para otros periodos.

1.4 JUSTIFICACIÓN

1.4.1 ACADÉMICA
El desarrollo de una herramienta web para apoyar el proceso de inteligencia de
negocios a partir de datos de desempeño recolectados en las pruebas saber 5° y 9°
permitirá que personas que no tienen un manejo suficiente de la tecnología puedan
hacer los análisis que requieran, sin tener que ejecutar complejos procedimientos
manuales para la extracción transformación y carga de los datos. La construcción
del modelo para las pruebas saber 5° y 9°, puede servir como base metodológica
de trabajo para ser implementada en otros escenarios, como las pruebas saber 11°.

1.4.2 SOCIAL
Este proyecto pretende estudiar desde una herramienta tecnológica los resultados
de las pruebas saber de los grados 5° y 9° para contribuir al crecimiento de la
investigación de manera que entidades educativas puedan entender, establecer
rutas de trabajo y formular estrategias que permitan mejorar los resultados en una
etapa temprana de la educación. También soluciona el problema de acceso a los
datos, con vistas más amigables para generar informes o reportes de los análisis
ejecutados sobre el DataMart.

1.4.3 INVESTIGATIVA
La presente investigación se enfocará en la implementación de la metodología de
desarrollo de bodegas de datos de Ralph Kimball en el proceso de construcción de
un DataMart, con el fin de analizar a un nivel de detalle más específico aspectos
que no se tienen en cuenta en los reportes actuales entregados por el Icfes, como
por ejemplo los factores asociados al desempeño.

1.5 ALCANCES Y LIMITACIONES

1.5.1 ALCANCES
• Se plantea trabajar con los datos de las pruebas 5° y 9° que están publicados
en el servidor FTP, datos que están disponibles para el público de manera
libre en formato de archivo plano. Aunque en este documento se mencionan
los resultados de las pruebas 3°, 5° y 9°, se excluyen las pruebas saber 3°
porque no se evalúan áreas como ciencias y competencias ciudadanas,
además la estructura de la prueba y la periodicidad de aplicación es diferente
a las de los grados 5° y 9.
• La selección de las variables socioeconómicas asociadas al desempeño que
se incluirán en el análisis, se hará de acuerdo a los datos base, es decir, a
las preguntas que se realizan año tras año y su continuidad en el tiempo.
• Las pruebas en otros niveles educativos como SABER 11, SABER PRO y las
pruebas del grado 3° no se tendrán en cuenta en el proyecto, ya que estas
pruebas son diferentes y no tienen las mismas características.
• Las herramientas de trabajo en su totalidad serán software libre, porque son
de fácil acceso y robustas para los procesos OLAP que se van a realizar.
• En un principio, el DataMart estará disponible en un servidor de prueba de
libre acceso, para que los interesados puedan realizar las consultas que
requieran.
• Se contemplan los años del 2017 en adelante, esto porque los resultados de
los años anteriores fueron entregados en valores plausibles.

1.5.2 LIMITACIONES
• La generación de estrategias y planes de mejoramiento académico, serán
formuladas por parte de las entidades educativas y los investigadores
interesados en el tema. Estas estrategias no están contempladas dentro de
los alcances del proyecto.
• La adquisición de los datos va a estar sujeta a la disposición del Icfes en el
servidor FTP, esto quiere decir, que cualquier modificación o problema con
el servidor de datos, deberá ser considerado dentro del proyecto para realizar
los ajustes necesarios.
• El Ministerio de Educación y el Icfes, determinaron no ejecutar a nivel
nacional las Pruebas Saber 2018 para los grados 3, 5 y 9, por un cambio de
metodología que se había previsto desde hace 3 años para este, es por esta
razón que no hay datos para el año 2018 [5].
• Los datos del año 2019 aún no se encuentran disponibles en el servidor FTP,
para lo que se espera que en el año 2020 ya se encuentren para poder hacer
los ajustes necesarios.

2. MARCO TEÓRICO

2.1 BODEGA DE DATOS (DATA WAREHOUSE - DW)

Una bodega de datos es una técnica de almacenamiento de datos que tiene como
objetivo el almacenar grandes cantidades de datos históricos, principalmente
originados en diferentes fuentes durante periodos de tiempo extensos [6].

A diario se trabaja en bases de datos operativas de tipo OLTP (OnLine Transaction


Processing), que pueden ser de diferentes tipos y con estructuras de
almacenamiento de datos que no son necesariamente relacionales; también se
pueden tener datos en archivos de texto, Excel o XML, entre otros. Por medio de un
proceso de extracción, transformación y carga (ETL- Extract, Transform and Load)
es posible llevar estos datos a un repositorio de tipo OLAP (On-Line Analytical
Processing), donde la intención es poder realizar análisis sobre un consolidado de
datos [6].

Como se observa en la Figura 2, las fuentes de datos pueden estar dispersas y por
este motivo es muy importante tener claro cuál es el objetivo con el que se va a
construir el modelo dimensional, identificando las necesidades del negocio y
diseñando los procesos necesarios para extraer, transformar y cargar los datos en
la bodega, de manera que facilite las tareas de presentación, interpretación y
análisis de la información.
Hojas de Cálculo

Base de D2
D1
datos no
SQL ETL
H

D3 D4

Base de
datos SQL
Minería de datos,
Bodega de Datos inteligencia de
Bases de datos negocios,
operativas reportes, tableros
(día a día) de control,
OLTP reportes.
Figura 2. Flujo de información adaptado del modelo de Kimball [1].

2.2 DATAMART

Un DataMart es una Bodega de datos con una característica muy particular, y es


que está enfocada a una parte especial del área de negocio para brindar información
más específica (ver Figura 3) y su construcción depende de las necesidades
puntuales de los usuarios finales [7].

Un DataMart puede contener datos de una bodega de datos, o integrar por sí mismo
datos como sea posible de diferentes fuentes de información, es decir, que puede
llegar a ser más complejo incluso que una bodega de datos, al poder lograr una
mayor complejidad no se considera como una pequeña bodega de datos. El objetivo
de un DataMart es integrar los datos necesarios para resolver las necesidades
específicas de una aplicación de inteligencia de negocios, enfocado en un
departamento de la empresa.
Figura 3. DataMarts [8].

2.3 MODELO DIMENSIONAL Y LENGUAJE DE CONSULTA MDX

El modelo dimensional de datos se plantea para poder simplificar los datos en pocas
tablas que sean más fáciles de consultar y de realizar análisis; se asocia a un “Cubo”
de n dimensiones (Figura 4), en el que se comparan diferentes aspectos de la
bodega de datos.

Las dimensiones proporcionan toda la información pertinente al contexto de "quién,


qué, dónde, cuándo, por qué y cómo" de lo que rodea un evento del área de estudio.
Las tablas de dimensiones contienen la descripción con todos los atributos utilizados
por las aplicaciones de inteligencia de negocios para filtrar y agrupar los hechos.
Por ejemplo, en la Figura 4 se establecen 3 dimensiones (producto, tiempo y
proveedor). Las unidades de medida tienen que ser definidas en el modelo
dimensional, para saber qué y cómo se van a medir las variables. El modelo
dimensional se define como un conjunto de propiedades, que estructuran una
visualización de los datos de manera que sea más fácil de analizar y entender.

Producto

Figura 4. Cubo OLAP, adaptado de la definición de Kimball.


El lenguaje de consulta más conocido es el MDX que es el acrónimo de
MultiDimensional eXpressions, que corresponde al lenguaje consulta para bases de
datos multidimensionales, más específicamente en bases de datos OLAP. Es un
lenguaje muy poderoso para realizar reportes por la configuración previa de las
relaciones; las consultas son más eficientes que en lenguaje SQL. Aunque MDX no
es el lenguaje estándar de consulta universal de motores OLAP, es el más utilizado.
Las consultas son similares a las de SQL, pero MDX es un lenguaje más rico en
análisis, que potencializa la velocidad de consulta y permite realizar varias acciones
con los cubos OLAP, como rotarlo, rebanarlo y cortarlo en dados más pequeños [9].

2.4 INTELIGENCIA DE NEGOCIOS

La inteligencia de negocios (Business Intelligence - BI) comprende un conjunto de


elementos tecnológicos que permiten extraer información de diversas bases de
datos transaccionales de la compañía, para convertirla en conocimiento que
ayudará a la toma de decisiones de negocio, de la mano con el análisis de los datos.
Es fundamental el apoyo a las personas para que tomen decisiones, partiendo de
los datos que a simple vista no son claros, pero con la integración de procesos y
métodos determinar acciones acertadas.

La inteligencia de negocios mejora el soporte de las estrategias de negocio


propuestas por las compañías. Permite mejorar la visión del cliente, generar
indicadores de desempeño, controlar los costos, monitorear aspectos puntuales y
operar el crecimiento de la información [10].

2.5 METODOLOGÍAS DE DESARROLLO DE BODEGAS DE DATOS

2.5.1 METODOLOGÍA DE RALPH KIMBALL


En la metodología de Kimball se propone un modelo para planificar las tareas de un
diseño que produzca un resultado esperado de bodegas de datos e inteligencia de
negocios. En la Figura 5 se ve el modelo que describe a un alto nivel de detalle el
ciclo de vida Kimball.

Este modelo se establece como una plantilla para la elaboración de proyectos de


DW / BI, pero es flexible a los requerimientos del cliente, abierto a la creatividad y
experiencia de quien haga uso de este modelo [1].
La metodología de Kimball está basada en cuatro principios básicos que son:

• Centrarse en el negocio
• Construir una infraestructura de información adecuada
• Realizar entregas en incrementos significativos
• Ofrecer solución completa

El ciclo de vida de Kimball propone varias etapas de alto nivel como se muestra en
la Figura 5, a modo de guía para la elaboración de proyectos de bodegas de datos,
muy flexible de acuerdo a las necesidades del proyecto. Los hitos del ciclo de vida
son:

Diseño de Instalación y
arquitectura selección de Crecimiento
técnica producto.

Programa/ Definición
Planificación
Modelado Diseño Diseño y Despliegue
de dimensional Físico despliegue
de proyectos
requerimie ETL
ntos de
negocio
Diseño de Desarrollo
aplicación BI de
Mantenimi
aplicación
ento
BI

Programa / planificación de proyectos

Figura 5. Diagrama del ciclo de vida de Kimball [1].

Programa / Planificación de proyectos: Se realiza la determinación de programa y


proyectos, para lo que hay mucha mayor consistencia en torno a la planificación del
proyecto, desde de la definición del alcance del proyecto DW / BI. Se necesita un
conocimiento básico en inteligencia de negocios para delimitar de manera acertada
los alcances.

Programa / Gestión de Proyectos: En esta etapa se fija la evaluación del estado del
proyecto, seguimiento de problemas y el control de cambios para mantener los
límites de alcance.

Requerimientos de negocio: Es significativo que los requerimientos sean entendidos


considerando los factores que mueven el negocio, de esta manera convertir los
requerimientos en herramientas de éxito.

Ruta tecnológica: Una vez se han definido los requerimientos hay tres vías
simultáneas que se agrupan en la tecnología, datos y las aplicaciones de
inteligencia empresarial. Para lo que se detalla la arquitectura técnica del negocio.

Ruta de datos: Comprende un conjunto paralelo de actividades que se deben


desarrollar, que incluye desde el diseño del modelo dimensional de destino, a la
instanciación física del modelo, y finalmente el proceso ETL, donde se extraen los
datos, se transforman y se cargan en el repositorio final.

Ruta de aplicación de inteligencia de negocios: El diseño y el desarrollo de


aplicaciones de inteligencia de negocios, se desarrolla con el objetivo de tener
interfaces de despliegue de resultados amigables con los usuarios finales. La
aplicación agrupa varias tareas de configuración y construcción de software.

Despliegue: En el despliegue convergen la tecnología, los datos y las aplicaciones,


cuidadosamente tiene que ser una orquestación bien realizada, para cumplir con lo
planeado.

Mantenimiento: Esta parte del ciclo de vida se inicia una vez el sistema de DW / BI
se despliega y en producción, se debe asegurar su funcionamiento, rendimiento y
persistencia.

Crecimiento: Si todo ha funcionado de la mejor manera y se encuentra marchando


como todo se planeó, es importante que se piense en el crecimiento del sistema.
Se hace con la finalidad de dar más valor a los datos y evolucionar el negocio.

2.5.2 METODOLOGÍA DE BILL INMON


Bill Inmon propone una metodología en la que la información se transfiera a
diferentes áreas especializadas como se puede observar en la figura 6, donde los
datos se distribuyan según los diferentes objetivos de análisis. Este modelo
identifica las áreas temáticas clave y, lo que es más importante, las entidades clave
con las que opera [11].

El modelo normalizado hace que cargar los datos sea menos complejo, pero usar
esta estructura para realizar consultas es difícil ya que involucra muchas tablas y
uniones. De tal manera, Inmon sugiere construir DataMarts específicos para los
departamentos, lo que resulta más eficiente para realizar el procesamiento y
generar informes con más precisión [11].
Figura 6. Enfoque Inmon - DW Corporativo [11].

2.5.3 METODOLOGÍA DE CHRISTODMAN


La metodología de Todman es una metodología conocida como “DOT Modeling”
que permite a las personas que no son técnicas construir su propio modelo
conceptual reflejando su percepción personal de la organización en términos
dimensionales. Por otro lado, suministra una forma ordenada para construir un
modelo lógico (relacional) partiendo desde el modelo conceptual, por medio de un
modelado de puntos que se basa en los requisitos simplificados para los modelos
dimensionales [12].

Un diagrama de modelo de puntos contiene tres elementos básicos que son:


• Punto (representa los hechos).
• Nombres de dimensiones.
• Conectores (los conectores se colocan entre los hechos y las dimensiones
para mostrar las dimensiones de primer nivel).

La Figura 7 muestra, a la izquierda un modelo sencillo con un punto de hechos y 6


dimensiones, pero los modelos pueden llegar a ser tan complejos que agrupen
varias áreas temáticas, como se observa a la derecha de la Figura 7.

Figura 7.Modelo de puntos multidimensional [12].


Para el desarrollo de este proyecto se adoptará el ciclo de vida propuesto en la
metodología de Kimball, cuyas actividades puntuales serán descritas más adelante
en este documento.

2.6 ESTRATEGIAS O MECANISMOS DE PERSISTENCIA PARA BODEGAS


DE DATOS O DATAMARTS

Hay varias alternativas de persistencia para las bodegas de datos o DataMarts, a


continuación, se mencionan algunos de ellos:

2.6.1 MODELOS RELACIONALES


Un base de datos relacional o también conocida como base de datos SQL3, es una
colección de elementos de datos con relaciones predefinidas entre ellos. Tiene su
origen en la teoría de conjuntos; estos elementos se organizan como un conjunto
de tablas con columnas y filas.

Los modelos relacionales están basados en las 12 reglas de Codd, que son un
conjunto de premisas que debe cumplir un sistema relacional de bases de datos, en
la implementación algunas reglas son difíciles de efectuar. Un sistema de bases de
datos se pude considerar “más relacional” siempre que mejor cumpla cada una de
estas reglas.
También, soporta las propiedades ACID de las cuatro iniciales de las propiedades
en inglés (Atomicity, Consistency, Isolation y Durability, respectivamente) [13].

2.6.2 MODELOS NO RELACIONALES


Las bases de datos no relacionales o NoSQL, hacen referencia a las bases de datos
que no cumplen con las especificaciones de una base de datos relacional, es decir,
no permiten almacenar información en un modelo entidad relacional y tampoco
tienen una estructura de tablas.

Su variedad es muy extensa, están diseñadas para dar solución a problemas de


almacenamiento en los que las bases de datos relacionales no tienen un
rendimiento aceptable. Permite la escalabilidad y flexibilidad con situaciones donde
existen datos estructurados y no estructurados [14].

La lista de bases de datos NoSQL es extensa, pero a continuación se mencionan


algunos de los más conocidos [14]:

3SQL de las siglas en inglés Structured Query Language o en español Lenguaje de Consulta
Estructurada.
• Clave-Valor: En este tipo de bases de datos NoSQL, cada elemento está
identificado por una clave única, que permite que la velocidad de
almacenamiento y recuperación de cada dato sea mucho más rápida.
Algunas de estas bases de datos son Redis, BigTable o HBase y Apache
Cassandra.
• Documentos: Se almacena la información en estructuras como documentos,
por ejemplo, JSON o XML. Para cada registro se asigna una clave única, de
esta manera también permite hacer búsquedas por clave-valor que resultan
siendo más rápidas. La base de datos documental más conocida es Mongo
DB.
• Grafos: Basado en la teoría grafos, almacena la información por medio de
vértices y aristas, generando una navegación más rápida con ayuda de los
modelos existentes para la teoría de grafos. Las más conocidas son Neo4j,
InfoGrid.
• Orientadas a objetos: Se almacenan la información con la misma estructura
que se tiene en la programación orientada a objetos y escritas totalmente en
lenguajes como Delphi, Ruby, Python, Perl, Java, Visual Basic.NET, etc.
• Multivalor: Son bases de datos muy flexibles en la asignación de valores a
un atributo, ya que permite asignar valores adicionales en forma de lista. Las
más tradicionales son JBase, OpenQM y InfinityDB.

Como resultado de la revisión bibliográfica que se hizo para elaborar el presente


documento, se puede concluir que el diseño de bodegas de datos no relacionales
es un campo aún poco explorado en el que existen algunos trabajos; sin embargo,
no están documentados a profundidad con los detalles necesarios para conocer la
elaboración. Parte de este proyecto consistirá en explorar la conveniencia de la
utilización de una base de datos NoSQL como soporte de persistencia para un
DataMart.

2.7 MARCO CONCEPTUAL DEL ÁREA DE CONOCIMIENTO ESPECÍFICO

El Instituto Colombiano para la Evaluación de la Educación (ICFES) en su


competencia como organización encargada de evaluar la educación a nivel nacional
y en los diferentes niveles, elaboró las pruebas Saber 3°, 5° y 9° para medir las
competencias de los estudiantes de educación primaria y secundaria.

2.7.1 PROPÓSITO DE LAS PRUEBAS SABER 3°, 5° Y 9°


Las pruebas son aplicadas con el fin de evaluar la educación básica primaria y
básica secundaria, para conocer cuál es el estado actual de los conocimientos de
los estudiantes, además de hacer un seguimiento con los resultados históricos son
elaboradas para que las instituciones puedan conocer debilidades y fortalezas, de
tal manera que generen estrategias para mejorar la calidad de educación [4].

El objetivo no solo es evaluar el desempeño de los estudiantes; para el Icfes también


es importante conocer las razones y factores que llevan a estos resultados. Dichos
factores se obtienen a través de información que se brinda por parte de estudiantes,
profesores y rectores; información que hace parte del entorno personal y que podría
estar relacionado con el desempeño en las pruebas.

Modelo Contexto, Insumos, Procesos y Productos (CIPP)


La información pertinente a los factores asociados al desempeño, fue construida
con base en el Modelo Contexto, Insumos, Procesos y Productos (CIPP), un
concepto que aprecia los factores a tener en cuenta a la hora de realizar un estudio
del aprendizaje, independientemente del contexto, como se puede observar en la
Figura 8.

Contexto Escuela

Insumos Procesos Productos

Figura 8.Modelo Contexto, Insumos, Procesos y Productos (CIPP) [4]

• El contexto hace parte de todos aquellos factores externos a la institución,


como sociales, económicos y sus familias.
• Los insumos son los elementos con los que cuenta la institución para
brindarle a sus estudiantes.
• Los procesos son todas las actividades que desarrolla la institución dentro de
las aulas para cumplir con sus objetivos.
• Los productos son los resultados obtenidos por las instituciones luego de
todo el trabajo realizado.

2.7.2 PRUEBAS QUE SE REALIZAN


Desde el año 2009, el Icfes evaluó las áreas de lenguaje, matemáticas, ciencias
naturales y competencias ciudadanas, como se observa en la Tabla 2. La base de
estas pruebas son las áreas de matemáticas y lenguaje, que están presentes en
todos los años que se aplicaron, además, en la mayoría de los cursos evaluados.
Área/Año 2009 2012 2013 2014 2015 2016 2017 2018

Ciencias 5° - 9° 5° - 9° - 5° - 9° - 5° - 9° - -

Lenguaje 5° - 9° 3°-5°-9° 3°-5°- 3°-5°- 3°-5°- 3°-5°- 3°-5°- -


9° 9° 9° 9° 9°

Matemáticas 5° - 9° 3°-5°-9° 3°-5°- 3°-5°- 3°-5°- 3°-5°- 3°-5°- -


9° 9° 9° 9° 9°

Competencias - 5° - 9° 5° - 9° - 5° - 9° - - -
ciudadanas
Tabla 2. Pruebas y grados evaluados en cada año de aplicación [2].

2.7.3 PERIODICIDAD
Las pruebas se realizaron inicialmente en el año 2009 y se tenía paneado que
fueran realizadas cada 3 años, pero a partir del año 2012 el gobierno decidió que
fueran realizadas anualmente, con la excepción del año 2018 en el que no se
llevaron a cabo por algunos ajustes que estuvieron realizando por parte del Icfes y
el Ministerio de Educación.

2.7.4 COBERTURA
La prueba puede ser aplicada de dos maneras:

• Muestral: Se aplica a una muestra simbólica de los colegios a todo el nivel


nacional y es responsabilidad del Icfes.
• Censal: Se aplica a todos los estudiantes de los grados 3°, 5° y 9°, su
aplicación censal es responsabilidad de las secretarias de educación y de las
instituciones educativas [15].

En la Tabla 3 y en la Figura 9 se observa el número de estudiantes evaluados por


año y grado.
3° 5° 9°
2009 0 859.624 661.089
2012 782.549 774.236 583.866
2013 772.702 759.515 578.625
2014 773.139 758.905 590.935
2015 749.851 711.610 549.240
2016 779.346 752.259 586.152
2017 762.724 778.863 591.024
Tabla 3. Número de estudiantes evaluados por grado y por año.
Número de estudiantes evaluados
3° 5° 9°
1000000
900000
800000
700000
600000
500000
400000
300000
200000
100000
0
2009 2012 2013 2014 2015 2016 2017

Figura 9.Gráfico de número de estudiantes evaluados por año.

2.7.5 ¿QUÉ SE MIDE?


Se busca medir las competencias de los estudiantes de acuerdo a los estándares
básicos de competencias en Lenguaje, Matemáticas, Ciencias y Ciudadanas
establecidos por el Ministerio de Educación Nacional (MEN) y Ascofade (Asociación
Colombiana de Facultades de Educación).

El Icfes genera dos tipos de resultados a entidades educativas y territoriales que se


describen a continuación en la Figura 10 y la Figura 11 respectivamente.
2.7.6 TIPOS DE RESULTADOS
Reporte para colegios:
•Conocer cual es el estado del estudiante para resolver preguntas y problemas.
Niveles de desempeño •Saber cual es el nivel de los estudiantes.
•Realizar comparaciones entre grupos.

•Determinar los puntajes más representativos dentro de las instituciones.


Puntaje promedio
•Establecer los puntajes promedio de las instituciones.

•Se asocia a la dispersión de los resultados.


Margen de estimación
•Permite realizar comparaciones con otros grupos de referencia.

•Sirven para ver la homogeneidad de los resultados.


Desviación estandar
•Comparar con la desviación estandar de otros grupos referentes.

Fortalezas y debilidades
•Se compra componentes con establecimientos que obtuvieron un resultado
en las competencias y
parecido.
componentes

Figura 10.Resultados para colegios [16].

Reporte para entidades territoriales:


•Conocer cual es el estado del estudiante para resolver preguntas y problemas.
Niveles de •Saber cual es el nivel de los estudiantes.
desempeño •Realizar comparaciones entre grupos.

•Determinar los puntajes más representativos dentro de las entidades


Puntaje promedio territoriales.
•Establecer los puntajes promedio de las entidades territoriales.

•Se asocia a la dispersión de los resultados.


Margen de
•Permite realizar comparaciones de una entidad territorial con otros grupos de
estimación referencia.

•Sirven para ver la homogeneidad de los resultados.


Desviación estandar •Comparar con la desviación estandar de entidades territorialesotros grupos
referentes.

Figura 11.Resultados para entidades territoriales [17].

Otro factor que se busca mirar son los niveles de desagregación, es decir, los
resultados agrupados por entidades territoriales, departamentos, municipios,
establecimientos y sedes. Pero debe tenerse en cuenta que hacer comparaciones
a nivel de sede con la muestra controlada, resulta imposible realizarse porque la
muestra no es estable en todos los periodos de tiempo [3].
2.7.7 VALORES PLAUSIBLES
Es una técnica de estadística utilizada en pruebas como las de 3°, 5° y 9°, donde
se desean conocer los datos a nivel de informes, para agrupar y resumir datos de
una manera que se describan a nivel grupal y no individual. Los valores plausibles
se construyen a partir de la desviación estándar posterior (ver Figura 12), generando
unos rangos como se ve en la figura, donde luego se asigna un valor aleatorio a
cada ítem y que será el valor plausible correspondiente.

Figura 12. Distribución posterior de un test de 6 ítems [18].

La creación de los valores plausibles en las pruebas del estado SABER 3°, 5° y 9°,
consisten en conseguir números aleatorios a partir de las distribuciones posteriores
y que describan el comportamiento grupal, pero no es recomendable para realizar
distribuciones individuales [18].

Los valores plausibles fueron la única manera que utilizo el Icfes para la publicación
de los resultados de los años 2009, 2012, 2013, 2014, 2015 y 2016. En el año 2017
fueron publicados de dos maneras, los valores plausibles y los resultados
individuales de los estudiantes, de tal manera que abre un conjunto más amplio de
investigación sobre los resultados, porque permite ejecutar análisis con las variables
de cada estudiante. Por este motivo se tienen en cuenta los resultados individuales
del año 2017 y sus posteriores que cuenten con el resultado obtenido por cada
estudiante en cada área evaluada.
2.8 HERRAMIENTAS TECNOLÓGICAS PARA LA IMPLEMENTACIÓN DE
BODEGAS DE DATOS - DATAMARTS

2.8.1 PENTAHO ®
Pentaho es un paquete de inteligencia de empresarial, de código abierto que incluye
una plataforma web y una serie de herramientas para todo el proceso de análisis de
datos, desde la limpieza y carga, hasta la visualización de informes. Existen dos
versiones, ambas desarrolladas en Java, la primera es la edición Enterprise y la
segunda se trata de la edición Community. La diferencia de las dos versiones de la
suite, se encuentra en que la edición Enterprise posee características y servicios de
soporte que no se encuentran en la Community [19].

Como se observa en la Figura 13, Pentaho incluye varias herramientas en su


plataforma de inteligencia de negocios:

Figura 13. Suite de Pentaho. [20]

• Reporting: En este componente se facilita la elaboración de informes


programados
• Analysis: Contempla una gran cantidad de operaciones y es la parte más
especializada de la plataforma, porque además de tener muchas
herramientas, es posible integrar todo el trabajo por medio de tableros de
control.
• Dashboard: Este es un panel que facilita la visualización de informes y
análisis, con plantillas completas para usuarios de negocios.
• Process Management o Pentaho Data Integration (antes Kettle): Es una
herramienta de integración de datos de diferentes fuentes, con una amplia
fuente de datos, análisis de Big Data y además herramientas para la
transformación de datos.

Pentaho será la herramienta que se utilizará para el desarrollo del proyecto, por ser
una plataforma open source, robusta y con las herramientas necesarias para crear
las soluciones requeridas por el proyecto.

2.8.2 SPAGO BI ® [21]


SpagoBI es una suite de inteligencia de negocios de open source que cubre todas
las áreas analíticas de los proyectos de inteligencia de negocios, con temas y
motores innovadores.

Como se ve en la Figura 14, está integrada por los siguientes componentes:

• SpagoBI Server: Comprende al núcleo de la suite que incluye las


herramientas y características de análisis.
• SpagoBI Studio: Es el entorno de desarrollo integrado.
• SpagoBI Meta: Entorno de metadata.
• SpagoBI SDK: La capa de integración que permite usar SpagoBI con
herramientas externas.
• SpagoBI Applications: Hace parte de un conjunto de modelos analíticos
verticales que se desarrollan utilizando Spago BI.

Figura 14. Arquitectura de Spago BI.


2.8.3 ORACLE DATABASE 11G ® [22]
Es una plataforma de warehousing e inteligencia de negocios con un amplio número
de herramientas para procesos ETL, DataWarehouse, Datamarts. Además, cuenta
con una plataforma especializada para el análisis, incorporando herramientas
OLAP, Data Mining y elementos de estadística en la base de datos. Oracle ofrece
toda la funcionalidad de un motor analítico autónomo con la escalabilidad, seguridad
y confiabilidad empresarial de una base de datos Oracle.

Oracle Warehouse Builder:


Es la herramienta para la integración de datos, la cual cuenta inicialmente con la
base de datos gratuita y adicional tiene tres opciones con requerimientos de
integración con más detalle.

Oracle Partitioning:
Esta herramienta es esencial para administrar bases de datos grandes, para dividir
tablas a medida que estas tablas crecen.

Oracle OLAP:
Es el motor OLAP incluido en Oracle Database, ayuda a mejorar las bodegas de
datos, al mejorar el desempeño de las consultas y al agregar contenido beneficiado
sobre los análisis.

Oracle Data Mining:


Oracle incorporo OLAP, minería de datos y estadísticas dentro de su motor de base
de datos. Con el fin de no mover los datos de un lugar a otro.

2.8.4 SQL SERVER DATA WAREHOUSE ® [23]

Microsoft permite a los usuarios ejecutar SQL Server en su plataforma, en sus


ambientes locales como en la nube. SQL Server da las herramientas para que las
organizaciones usen los datos de manera más efectiva, veloz, escalable y ágil.
Microsoft ofrece opciones para mantener la capacidad de almacenamiento, el tipo y
la ubicación de una bodega de datos de acuerdo a la Figura 15.

Microsoft ofrece las siguientes opciones para almacenar datos que incluyen:
• Track Fast Track en las instalaciones: Esta basado en la arquitectura de
referencia de multiprocesamiento simétrico4 (SMP), con capacidad de cálculo
de hasta 150 TB y 1,2 PB de capacidad de almacenamiento.

4SMP (Symmetric Multi-Processing) es una arquitectura de ordenadores en que dos o más


procesadores comparten una única memoria central.
• Fast Fast Track basado en Azure: Para máquinas virtuales de Azure es una
solución de nube alojada basada en una arquitectura de referencia SMP.
• Analytics Platform System: Es un dispositivo MPP5 local para almacenes de
datos más grandes que ofrece escalabilidad lineal a más de 6 PB.
• Azure SQL Data Warehouse: Es una solución MPP en la nube alojada para
grandes almacenes de datos. El cómputo y el almacenamiento están
separados, lo que resulta en un rendimiento predecible y escalable.

Figura 15. Estructura SQL Server - Data Warehouse [23].

3. MARCO REFERENCIAL

3.1 ESTADO DE ARTE INVESTIGATIVO ICFES SOBRE LAS PRUEBAS


SABER 3°, 5° Y 9°

En la página web del Icfes6 se encuentran publicados varios proyectos sobre los
resultados de las pruebas saber 3°, 5° y 9°, pero el enfoque está en otras áreas de
conocimiento como la psicología, la sociología, metodologías de educación y no en
relación al uso de las TIC´s como soporte al procesamiento de los datos para
entender diversas variables que afectan de cierta manera los resultados obtenidos

5 MPP (Massively Parallel Processor) es una arquitectura de procesamiento paralelo en que cada
procesador tiene su propia memoria local, pero puede también tener acceso a la memoria de otros
procesadores.
6 ICFES, resultados de investigación en: https://www.icfes.gov.co/web/guest/resultado-de-

investigaciones.
por los estudiantes. Se puede evidenciar que la investigación en el campo de las
pruebas saber 3°, 5° y 9° tiene un vacío que motiva investigar sobre estos
resultados.

En particular, está el proyecto titulado “La calidad de la educación inicial y el


desempeño académico en la educación básica primaria en Bogotá”, cuyo objetivo
fue analizar la calidad de la educación inicial a partir del desempeño académico en
la educación básica primaria. Al final del documento se realizan unas
recomendaciones para mejorar la calidad de la educación, afirmando que es
importante el acompañamiento cercano de los docentes con los estudiantes, de
igual manera, que es significativo analizar y llevar un control sobre las habilidades
de los niños [24].

Una de las áreas con más trabajos enfocados al aprendizaje y estudios sobre las
pruebas del ICFES se encuentra en la Maestría en Enseñanza de las Ciencias
Exactas y Naturales de la Universidad Nacional de Colombia, teniendo en cuenta
que sus estudios buscan mejorar y fortalecer las capacidades de los estudiantes.
Cabe destacar el trabajo “Enseñanza basada en problemas como instrumento para
fortalecer los conceptos de líneas y puntos notables del triángulo en grado once
mediante las TIC, un enfoque hacia las pruebas saber” donde enmarcan el diseño
de un modelo para la enseñanza de aspectos importantes en estudiantes de grado
undécimo apoyado en el uso de las TIC [25].

3.2 OTROS ESTUDIOS DE INTERÉS

Un proyecto relevante que está en los trabajos de investigación publicados por el


Icfes es el de “Predicción del desempeño académico usando técnicas de
aprendizaje de máquinas”, que se desarrolla con un enfoque de minería de datos
para predecir los resultados y factores de éxito de estudiantes que son admitidos en
la Universidad de los Andes durante el periodo del 2015 al 2017. Se identifican
variables que son relevantes (de acuerdo a los resultados del Icfes) para la
predicción por medio de técnicas de aprendizaje de máquinas. Utilizaron datos
como la identificación, resultados del Icfes y algunos resultados en los cursos
básicos en la universidad; los datos tuvieron que ser estandarizados según el año
de ingreso con métodos estadísticos. Las técnicas utilizadas por los autores fueron
regresión logística con Stepwise Selection, regresión logística con regularización
Lasso, Boosting de árboles, máquinas de soporte vectorial y redes neuronales. Los
hallazgos encontrados son algo sesgados al tipo de población que se aplicó la
técnica, ya que la población presentaba una cuasi-homogeneidad, además de que
la relación de los resultados en las notas del semestre se relacionaba más a el
contexto semestral [26].
En el trabajo “Improving kinematic lab practices by image processing” se propone
que la deficiencia evidente de los estudiantes, tanto en la comprensión de diferentes
áreas de conocimiento, como en sus habilidades y competencias para resolver
problemas en situaciones cotidianas. Se implementan las TIC dentro del proceso de
enseñanza. Además, desarrollan un software compatible con el sensor Kinect,
donde el software toma la información del experimento en tiempo real para crear
una interfaz de realidad aumentada [27].

4. MARCO METODOLÓGICO

A continuación, se precisa la metodología que se aplicará en la construcción del


prototipo de DataMart, para realizar inteligencia de negocios con los resultados de
las pruebas saber 5° y 9°:

4.1 IMPLEMENTACIÓN DE LA METODOLOGÍA DE RALPH KIMBALL PARA


EL PROYECTO

Programa / Planificación de proyectos:


En esta etapa se determina la definición y el alcance del proyecto, también se define
el cronograma de actividades (se detalla más adelante), con las actividades y fechas
en que se van a realizar. Se especifican los requerimientos para análisis de datos
de los resultados de las pruebas 5° y 9° para el periodo 2017-2019, a partir de los
datos publicados por el Icfes.

Programa / Gestión de Proyectos:


En esta etapa se fija la evaluación del estado del proyecto, seguimiento de
problemas con datos, desarrollo de aplicaciones y el control de cambios para
mantener los límites de alcance. Se evalúan aspectos como la integración de los
datos del periodo 2019, que a la fecha no han sido publicados y se espera su
publicación en el desarrollo del proyecto.

Definición de requerimientos de negocio:


Se realiza la descarga de los resultados de las pruebas saber 5° y 9° para
explorarlos y definir su calidad, es importante conocer cuáles son las necesidades
de los investigadores, docentes y todos los interesados de los datos de las pruebas
saber 5° y 9°, para dar una solución acertada. La especificación de los
requerimientos se hará a partir de los informes que publica el Icfes y de las
preguntas frecuentes que se formulan en el portal del Icfes.
Ruta tecnológica:
Una vez se han definido los requerimientos hay tres vías simultáneas que se
agrupan en la tecnología, datos y las aplicaciones de inteligencia empresarial. Para
lo que se detalla la arquitectura técnica del negocio.

• Diseño de arquitectura técnica del prototipo de DataMart para realizar


inteligencia de negocios.
• Modelado dimensional del DataMart que permita hacer el análisis de factores
asociados con respecto a los resultados individuales obtenidos por cada
estudiante en las pruebas.
• Diseño aplicación BI para la visualización y creación de informes de los
resultados de las Pruebas saber 5° y 9.

Ruta de datos:
Comprende un conjunto paralelo de actividades que se deben desarrollar, que
incluye desde el diseño del modelo dimensional de destino, a la instanciación física
del modelo y finalmente el proceso ETL.
• Construcción de la metadata para hacer el cargue, integración y agregación
de los datos en el modelo multidimensional.
• Instalación de la herramienta Pentaho y el motor de base de datos
PostgreSQL.
• Creación del diseño físico que asegure la integridad y acceso de los datos.

Ruta de aplicación de inteligencia de negocios:


El diseño y el desarrollo de la aplicación de inteligencia de negocios, se desarrolla
con el objetivo de tener una interfaz de despliegue de resultados amigables con los
usuarios finales, que generen valor a los estudios que se desarrollan sobre las
pruebas saber 3°, 5° y 9°. La aplicación agrupa varias tareas que en general están
separadas por el desarrollo ETL y el desarrollo de la aplicación de inteligencia de
negocios, que comprende las siguientes actividades:

• Diseño y despliegue ETL que permita mover los datos tomados desde el
repositorio del Icfes y llevarlos a otro sistema operacional con un modelo
multidimensional.
• Bodega de datos y cubo OLAP que soporte la ejecución de consultas con el
lenguaje multidimensional MDX.
• Desarrollo de la aplicación BI que permita el análisis de los resultados de las
pruebas saber y creación de reportes a partir del modelo multidimensional,
utilizando la herramienta Pentaho.
• Creación de tableros de control para la visualización del análisis previo del
modelo multidimensional.
• Ejecución de consultas MDX y comparación con los reportes entregados por
el Icfes.
• Creación de reglas de integridad para el acceso a la aplicación BI.
• Elaboración de reportes que permitan entender de manera resumida y rápida
el comportamiento de los resultados de las pruebas, para mejorar la toma de
decisiones.
• Es necesario la validación de los resultados obtenidos en las consultas y
reportes, a partir los resultados estadísticos básicos publicados por el Icfes,
y de los datos originales provistos por el servidor FTP.

Despliegue:
En el despliegue convergen la tecnología, los datos individuales de los estudiantes
en cada área evaluada y las aplicaciones, cuidadosamente tiene que ser una
orquestación bien realizada, para cumplir con lo planeado. En esta fase también se
ejecutarán las actividades para cargar el DataMart, la instalación y configuración de
la aplicación de inteligencia de negocios en un servidor de pruebas.
• Instalación del motor de bases de datos en el servidor.
• Despliegue de la bodega de datos.
• Instalación de la aplicación de inteligencia de negocios y su conexión con la
bodega de datos.
• Ajustes necesarios que se presenten en la instalación dentro del servidor.
• Evaluación de los resultados obtenidos y revisión del funcionamiento del
prototipo.

Crecimiento:
Si la aplicación funciona según lo planeado, es importante que se piense en el
crecimiento del sistema. Se hace con la finalidad de dar más valor a los datos y
evolucionar el negocio; como trabajos futuros se podría implementar con otros
resultados de la misma o diferentes pruebas saber. Al finalizar el proyecto se
dejarán recomendaciones que permitan ejecutar la fase de crecimiento del sistema.

4.2 METODOLOGÍA DE DESARROLLO DE PROYECTOS – SCRUM [28]

Scrum es un framework o estructura para proyectos ágiles, creado con el fin de


ejecutar proyectos con buenas prácticas de trabajo en equipo; se enfoca en las
necesidades del cliente y su uso es en proyectos donde el tiempo para el desarrollo
es corto. El presente proyecto se ajustará la metodología de trabajo por entregas
parciales del producto final, con periodos de desarrollo conocidos como sprints. Se
ejecutará el proyecto en 5 Sprints y cada uno de ellos tendrá un tiempo estimado de
un mes.

Artefactos en SCRUM:

1. Product Backlog: Es la lista de características base del prototipo de DataMart


elaborada a partir de la especificación de los requerimientos.
2. Sprint Backlog: Son sub conjuntos de objetivos definidos en cada uno de los
ítems de la lista del Product Backlog.
3. SCRUM Taskboard: Es un soporte que se utiliza para tener en cuenta los
elementos que se van a ejecutar en cada sprint.
4. Burndown chart: Es la herramienta visual que se utiliza para medir el estado
del proyecto con el cronograma.

En la Tabla 4 se muestran los Sprints que se van a ejecutar durante el desarrollo del
proyecto, como inicio del proyecto se establece el día de radicación del proyecto,
con una duración de 26 semanas.

Nombre de tarea Duración Comienzo Fin


Sprint 1 - Comprensión del problema y los lun
24 días mié 19/02/20
datos: 23/03/20
Sprint 2 - Fase de diseño del modelo mar mié
27 días
dimensional y ETL 24/03/20 29/04/20
Sprint 3 - Fase de Implementación del
23 días jue 30/04/20 lun 1/06/20
modelo dimensional y del proceso ETL
Sprint 4 Fase de Validación 27 días mar 2/06/20 mié 8/07/20
mar
Sprint 5 - Fase de Instalación y evaluación 29 días jue 9/07/20
18/08/20
Tabla 4. Resumen de los Sprints.
5. DESARROLLO DEL PROYECTO

5.1 DESCRIPCIÓN DE LA METODOLOGÍA DE DESARROLLO DEL


PROYECTO

El desarrollo del proyecto está enmarcado en la metodología ágil Scrum. En primer


lugar, se definen las historias de usuario de alta complejidad de desarrollo, que se
conocen como épicas, las cuales no se logran cubrir en un solo sprint, no pueden
tener una estimación del tiempo, pero sí contener más de una historia de usuario y
su desarrollo se da en diferentes sprints del proyecto. Teniendo en cuenta que la
metodología de Ralph Kimball está compuesta de varias etapas o también llamadas
rutas, se hizo una asociación de las rutas para la creación de las épicas que se
listan en la Figura 16, cada una se identifica con un color que más adelante estará
presente en las historias de usuario.

Figura 16. Épicas del proyecto. Elaboración propia.

En la Figura 17 se puede ver la adaptación del modelo de Kimball para el proyecto,


resaltando con el color correspondiente de las épicas de la Figura 16. En el caso
particular de la ruta de mantenimiento, se encuentra con una línea puntada y
sombreada ya que en el proyecto no se tiene en cuenta las tareas técnicas de
supervisión, apoyo, mantenimiento y tampoco la optimización. Por otro lado, la
etapa de crecimiento solo contempla el desarrollo de una pequeña parte y son los
trabajos futuros, donde se mencionan detalles que se pueden extender en
funcionalidades, casos que se pueden implementar y el crecimiento del campo de
investigación.
Diseño de Instalación y Crecimiento
arquitectura selección de
técnica producto.

Programa / Definición de Modelado Diseño Diseño y Despliegue


Planificación requerimientos
de proyectos dimensional Físico despliegue
de negocio ETL

Diseño de Desarrollo
aplicación BI de Mantenimiento
aplicación BI

Programa / Gestión de proyectos


Figura 17. Adaptación de ciclo de vida de la metodología de Kimball.

Se establece de igual manera alineado a las tareas más específicas de cada una
de las épicas, las historias de usuario ordenadas en el Backlog (Figura 18 y Figura
19) donde cada historia de usuario esta identificada con un color que corresponde
a las épicas de la Figura 16. Las tareas definidas en el Backlog se ordenan de
manera que las que tienen más prioridad sean realizadas en las primeras
iteraciones siguiendo las etapas del modelo de Kimball. Las historias de usuario se
agrupan en 5 sprints, como se puede ver en la Figura 4.

Los puntos de cada historia de usuario representan la complejidad; para este


proyecto se definieron 3 puntajes que son bajo (5), medio (10) y alto (15). La suma
de los puntos de todas las historias de los sprints es de 460 puntos.
Figura 18.Backlog del proyecto (parte1). Elaboración propia.
Figura 19. Backlog del proyecto (parte 2). Elaboración propia.
Figura 20. Historias de usuario por sprint. Elaboración propia.
5.2 DESARROLLO DEL SPRINT 1

Actividades ▪ Definir la estrategia para el levantamiento de


requerimientos.
▪ Crear los diagramas de requerimientos y los casos
de uso.
▪ Elaboración de las historias de usuario.
▪ Descargar los datos desde el servidor FTP del
Icfes.
▪ Descarga, descripción y exploración de los datos
que se encuentran en el servidor FTP del Icfes.
▪ Descargar e instalar la herramienta Pentaho.
▪ Definición de la arquitectura.

Entregables ▪ Diagrama de requerimientos.


▪ Diagrama de casos de uso.
▪ Diccionario de datos de los archivos.
▪ Manual de instalación de la herramienta.

Duración 4 semanas.

Tabla 5. Resumen sprint 1. Elaboración propia.

5.2.1 ESTRATEGIA PARA EL LEVANTAMIENTO DE REQUERIMIENTOS

Listado de requerimientos
Los requerimientos se especificaron a partir de las guías de interpretación y las
estadísticas presentadas por el Icfes por medio de informes a las diferentes
entidades territoriales o educativas. Se tuvieron en cuenta los aspectos que son
fundamentales para los reportes y a su vez el complemento que podría tener con
los datos de los factores asociados.

El portal web del Icfes dispone de un espacio de consulta7 de reportes de las


pruebas saber 3°, 5° y 9, donde se requiere únicamente el nombre de la entidad a
consultar o el código de identificación de DANE8 para realizar consultas de los
reportes por año o por históricos de varios años y las áreas evaluadas. Los reportes
que entrega el Icfes a las entidades territoriales y los colegios, se tomaron como
punto de partida del proyecto para entender los requerimientos a la hora de
presentar los resultados al usuario.

7 Consulta de resultados pruebas saber 3°, 5° y 9°, para departamento, colegios o municipios -
http://www2.icfesinteractivo.gov.co/ReportesSaber359/.
8 El código de identificación DANE es un número único, inmodificable e irrepetible que se crea y

asigna por una única vez a los establecimientos educativos legalmente constituidos y a
organizaciones territoriales – www.dane.gov.co.
Lo primero que se puede apreciar en el reporte como el de la Figura 36 es la
descripción de los puntajes en rangos y porcentajes de estudiantes, para conocer
qué tantos estudiantes de la entidad están en los 4 niveles de desempeño que son:
avanzado, satisfactorio, mínimo e insuficiente. Otra forma en la que se presentan
los datos es como se ve en la Figura 22, una comparación de los resultados de la
institucion frente al municipio y el departamento, comparando los niveles
porcentuales de desempeño en una misma gráfica. De forma similar, se muestra el
puntaje promedio con la desviación estándar, con una comparación similiar frente a
el municipio, departamento y ademas con una clasificación entre los colegios.

Figura 21. Porcentaje de estudiantes según niveles de desempeño (Consulta de un colegio al azar) [29].

Figura 22.Porcentaje de estudiantes por niveles de desempeño en el establecimiento educativo, la entidad


territorial certificada (ETC) correspondiente y el país (Consulta de un colegio al azar) [29].

Figura 23.Puntaje promedio y desviación estándar en el establecimiento educativo, la ETC, el país y los tipos
de establecimientos de la ETC según NSE (Consulta de un colegio al azar) [29].
Existe otra forma de consultar los reportes y esta resulta útil para agrupar diferentes
periodos como una opción de históricos, se pueden seleccionar todos los periodos
o solo los de interés. En la Figura 24 se muestra una gráfica en la que se
seleccionaros los periodos 2016 y 2017, las gráficas son de forma similar a los
reportes mencionados anteriormente, pero permite ver paralelamente los diferentes
periodos.

Figura 24.Comparación de porcentajes según niveles de desempeño por año [29].

Se determinaron variables importantes que están en los reportes, como: cantidad


de estudiantes que presentaron las pruebas y sus agrupaciones por entidades
territoriales, el desempeño de los estudiantes agrupados por instituciones
educativas y entidades territoriales. Por otro lado, se identificaron los factores
asociados (variables socioeconómicas y demográficas) para que investigadores e
interesados puedan encontrar relaciones de dichas variables con los resultados
obtenidos, que como se observa en los gráficos anteriores, no hacen parte de los
reportes que actualmente entrega el Icfes.

En la Figura 25 se aprecia el diagrama de requerimientos funcionales, agrupados


en cuatro módulos: indicadores de volumen, estadísticas de desempeño, factores
asociados y generación de reportes.
Figura 25. Diagrama de requerimientos funcionales para el DataMart. Elaboración propia.

En la Figura 26 los requerimientos funcionales de indicadores de volumen de


estudiantes, describen los aspectos que son importantes para conocer el volumen
de cobertura de las pruebas saber 5° y 9°.
Figura 26. Diagrama de requerimientos para gestión de indicadores de volumen de estudiantes. Elaboración
propia.

En la Figura 27 los requerimientos funcionales de estadísticas de desempeño


representan los aspectos relacionados al puntaje de los estudiantes y nivel de
desempeño en periodos de tiempo y variables relevantes de clasificación.

Figura 27.Diagrama requerimientos para la gestión estadísticas de desempeño. Elaboración propia.

En la Figura 28 los requerimientos funcionales de factores asociados describen el


impacto de los factores asociados en el promedio de los estudiantes, clasificados
en grupos.
Figura 28. Diagrama de requerimientos funcionales para la gestión de factores asociados. Elaboración propia.

En la Figura 29 los requerimientos funcionales de las salidas gráficas, hacen


referencia a los resultados como reportes, gráficas y tableros de control necesarios
para representar los análisis realizados.

Figura 29. Diagrama de requerimientos funcionales para las la gestión de generación de reportes. Elaboración
propia.

En la Figura 30 y Figura 31 se describe el listado de requerimientos no funcionales,


separado en dos grupos que son: definición y configuración.
Figura 30. Diagrama de requerimientos no funcionales. Elaboración propia.

Figura 31. Diagrama de requerimientos no funcionales para definición. Elaboración propia.

En la Figura 32 los requerimientos no funcionales de configuración son criterios de


disposición de las herramientas necesarias para el despliegue del DataMart.
Figura 32.Diagrama de requerimientos no funcionales para configuración. Elaboración propia.

5.2.2 CASOS DE USO


El enfoque de los casos de uso debe comprender cuáles son las funciones que
existen en el sistema, obtener los requisitos y funciones que se desean para el
sistema que se va a desarrollar, por último, establecer quiénes interactuarán con
el sistema y cómo lo harán. [30]

Figura 33. Actores de los casos de uso del DataMart. Elaboración propia.

En la Figura 34 se describe el diagrama de casos de uso.


Figura 34. Diagrama de casos de uso. Elaboración propia.

Casos de uso gestión del volumen de estudiantes.

Figura 35. Casos de uso volumen de estudiantes. Elaboración propia.


Casos de uso gestión de estadísticas de desempeño.

Figura 36. Casos de uso estadísticas de desempeño. Elaboración propia.


Casos de uso gestión de factores asociados.

Caso de uso gestión de factores asociados.

Figura 37. Casos de uso factores asociados. Elaboración propia.


5.2.3 DOCUMENTACIÓN DE LOS CASOS DE USO
La plantilla utilizada para realizar la documentación de los casos de uso es diferente
a las que se usan convencionalmente, teniendo en cuenta que el tipo de interacción
que tiene el usuario es de consultas sobre la bodega de datos (ver Figura 38). Se
utilizó como base la tesis de doctorado “Data Warehouse Design With UML”, un
trabajo que muestra una forma de crear y hacer la documentación de los casos de
uso UML, partiendo de los requerimientos de un proyecto de bodega de datos o en
este caso de un DataMart [30].

Figura 38. Modelo de Documentación de los casos de uso. [30]

Identificadores de los casos de uso:


• CU02: Gestión del volumen de estudiantes.
• CU03: Gestión de estadísticas de desempeño.
• CU04: Gestión de los factores asociados.

Gestión del volumen de estudiantes

Caso de uso:
Consultar volumen de estudiantes por grado y periodo de tiempo.
ID:
CU02-01
Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.
Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar los
datos por volumen de estudiantes que han presentado las pruebas.
2. Se despliega una visualización de estudiantes que presentaron las
pruebas saber 5° y 9° en diferentes escenarios.
3. El usuario selecciona la clasificación de volumen de estudiantes que
presentaron las pruebas saber 5° y 9° clasificados por grado y periodo
de tiempo.
4. Se agrupa la cantidad de estudiantes por grado, en periodo de tiempo.
5. Se hace la suma de estudiantes en cada uno de los grados, teniendo en
cuenta el periodo de tiempo.
6. Despliega la consulta del número de estudiantes agrupados.
7. Se muestra el reporte del volumen de estudiantes que presentaron las
pruebas saber 5° y 9° por grado y periodo de tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos seleccionados por el
usuario durante el procedimiento.
Tabla 6. Documentación caso de uso CU02-01. Elaboración propia.

Caso de uso:
Consultar volumen de estudiantes por periodo de tiempo, entidad territorial y
por grado.
ID:
CU02-02
Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar los
datos de volumen de estudiantes que han presentado las pruebas.
2. Se despliega una visualización de estudiantes que presentaron las
pruebas saber 5° y 9° en diferentes escenarios.
3. El usuario selecciona la clasificación de número de estudiantes que
presentaron las pruebas saber 5° y 9° por periodo de tiempo, entidad
territorial y por grado.
4. Se agrupa la cantidad de estudiantes por periodo de tiempo, entidad
territorial y por grado.
5. Se hace la suma de estudiantes en entidad territorial y grado de acuerdo
al periodo de tiempo.
6. Desplegar la información del número de estudiantes.
7. Mostrar el reporte del volumen de estudiantes que presentaron las
pruebas saber 5° y 9° por periodo de tiempo, entidad territorial y por
grado.

Postcondiciones:
1. El sistema genera un reporte con los hechos seleccionados por el
usuario durante el procedimiento.

Tabla 7. Documentación caso de uso CU02-02. Elaboración propia.

Caso de uso:
Consultar volumen de estudiantes por género y periodo de tiempo.
ID:
CU02-03
Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar los
datos por volumen de estudiantes que han presentado las pruebas.
2. Se despliega una visualización de estudiantes que presentaron las
pruebas saber 5° y 9° en diferentes escenarios.
3. El usuario selecciona la clasificación de número de estudiantes que
presentaron las pruebas saber 5° y 9° por género y periodo de tiempo.
4. Se agrupa la cantidad de estudiantes por género y periodo de tiempo.
5. Se realiza la suma de los estudiantes que presentaron la prueba.
6. Desplegar la información del número de estudiantes de acuerdo a la
clasificación configurada.
7. Se muestra el reporte del volumen de estudiantes que presentaron las
pruebas saber 5° y 9° por género y periodo de tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos seleccionados por el
usuario durante el procedimiento.

Tabla 8. Documentación caso de uso CU02-03. Elaboración propia.

Gestión de estadísticas de desempeño

Caso de uso:
Consultar puntaje promedio de estudiantes por periodo de tiempo y área.
ID:
CU03-01
Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar los
datos por de estadísticas de desempeño.
2. El usuario selecciona la clasificación de puntaje de estudiantes por
periodo de tiempo y área.
3. Se agrupa la cantidad de estudiantes por puntaje de estudiantes por
periodo de tiempo y área.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por área y periodo de tiempo.
5. Desplegar la información del puntaje de los estudiantes agrupado por
área y periodo de tiempo.
6. Se despliega un reporte del puntaje promedio de los estudiantes por
periodo de tiempo y área.

Postcondiciones:
1. El sistema genera un reporte con los hechos seleccionados por el
usuario durante el procedimiento.

Tabla 9.Documentación caso de uso CU03-01. Elaboración propia.

Caso de uso:
Consultar resultado promedio por periodo de tiempo y género.

ID:
CU03-02

Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar
estadísticas de desempeño.
2. El usuario selecciona la clasificación de promedio del estudiante por
periodo de tiempo y género.
3. Se agrupa la cantidad de estudiantes por puntaje de estudiantes por
periodo de tiempo y género.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por periodo de tiempo y área.
5. Desplegar la información del promedio de los resultados de los
estudiantes de acuerdo a la clasificación de área por periodo de tiempo.
6. Se despliega un reporte del promedio de los resultados obtenidos por
los estudiantes por periodo de tiempo y área.

Postcondiciones:
1. El sistema genera un reporte con los hechos seleccionados por el
usuario durante el procedimiento.

Tabla 10. Documentación caso de uso CU03-02. Elaboración propia.


Caso de uso:
Consultar resultado promedio por periodo de tiempo, área y género
ID:
CU03-03
Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar los
datos de estadísticas de desempeño.
2. El usuario selecciona la clasificación por periodo de tiempo, área y
género.
3. Se agrupa la cantidad de estudiantes por periodo de tiempo, área y
género.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por área y género.
5. Desplegar la información del promedio de estudiantes de acuerdo a la
clasificación configurada.
6. Se despliega un reporte del promedio por periodo de tiempo, área y
género.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.
Tabla 11. Documentación caso de uso CU03-03. Elaboración propia.

Caso de uso:
Consultar resultado promedio por institución, área y grado en periodo de
tiempo.
ID:
CU03-04
Actores:
Usuario DW
Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar
estadísticas de desempeño.
2. El usuario selecciona la clasificación por institución, área y grado en
periodo de tiempo.
3. Se agrupan los datos en la cantidad de estudiantes por institución, área
y grado en periodo de tiempo.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por institución, área y grado en periodos de tiempo.
5. despliega la información del número de estudiantes de acuerdo a la
clasificación configurada.
6. Se despliega un reporte del promedio por institución, área y grado en
periodo de tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.

Tabla 12. Documentación de caso de uso CU03-04. Elaboración propia.

Caso de uso:
Caso de uso consultar nivel de desempeño de instituciones por género, área y
periodo de tiempo
ID:
CU03-05
Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.
3. El Icfes clasifica en rangos del puntaje total de las pruebas que son:
insuficiente (0-252), mínimo (253-344), satisfactorio (345-423) y
avanzado (424-500).

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar
estadísticas de desempeño.
2. El usuario selecciona la clasificación por género, área y periodo de
tiempo.
3. Se agrupan los datos en la cantidad de estudiantes por género, área y
periodo de tiempo y nivel de desempeño.
4. Se suma el número de estudiantes en cada nivel de desempeño.
5. Desplegar la información del número de estudiantes de acuerdo a la
clasificación configurada.
6. Se despliega un reporte del total en cada nivel de los estudiantes
agrupados por género, área y periodo de tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.

Tabla 13. Documentación de caso de uso CU03-05. Elaboración propia.

Caso de uso:
Consultar nivel de desempeño por área, grado y periodo de tiempo.
ID:
CU03-06

Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar
estadísticas de desempeño.
2. El usuario selecciona la clasificación por área, grado y periodo de
tiempo.
3. Se agrupan los datos en la cantidad de estudiantes por área, grado y
periodo de tiempo.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por área, grado y periodo de tiempo.
5. Mostrar la información del promedio de los resultados de los
estudiantes de acuerdo a la clasificación.
6. Se despliega un reporte del promedio por área, grado y periodo de
tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.

Tabla 14. Documentación de caso de uso CU03-06. Elaboración propia.

Gestión de Factores asociados

Los factores asociados son componentes o elementos que se relacionan al entorno


y composición socioeconómica del estudiante, por ejemplo, uso del internet, bienes
que posee en el hogar, trabajo y nivel educativo de los padres, entre otros. Estas
preguntas son realizadas a los estudiantes como parte del cuestionario, a los
docentes y directivos de las instituciones.

Caso de uso:
Consultar resultado promedio por factores socioeconómicos familiares por
periodo de tiempo
ID:
CU04-01
Actores:
Usuario DW
Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.
Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar
factores asociados.
2. El usuario selecciona la clasificación por factores socioeconómicos
familiares por periodo de tiempo.
3. Se agrupan los datos en la cantidad de estudiantes por factores
socioeconómicos familiares por periodo de tiempo.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por factores socioeconómicos familiares y periodo de tiempo.
5. Mostrar la información del promedio de los resultados de los estudiantes
de acuerdo a la clasificación configurada.
6. Se despliega un reporte del promedio por factores socioeconómicos
familiares por periodo de tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.

Tabla 15. Documentación caso de uso CU04-01. Elaboración propia.

Caso de uso:
Consultar resultado promedio por factores del colegio por periodo de tiempo.
ID:
CU04-02

Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar
factores asociados.
2. El usuario selecciona la clasificación por factores del colegio por periodo
de tiempo.
3. Se agrupan los datos en la cantidad de estudiantes por factores del
colegio por periodo de tiempo.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados en factores socioeconómicos del colegio por periodo de
tiempo.
5. Mostrar la información del promedio de los resultados de las pruebas de
los estudiantes de acuerdo a la clasificación.
6. Se despliega un reporte del promedio por factores del colegio por
periodo de tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.

Tabla 16. Documentación caso de uso CU04-02. Elaboración propia.

Caso de uso:
Consultar resultado promedio por otros datos socioeconómicos por periodo de
tiempo.
ID:
CU04-03
Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar
factores asociados.
2. El usuario selecciona la clasificación por otros datos socioeconómicos
por periodo de tiempo.
3. Se agrupan los datos en la cantidad de estudiantes por otros datos
socioeconómicos por periodo de tiempo.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por otros factores socioeconómicos.
5. Mostrar la información del número de estudiantes de acuerdo a la
clasificación configurada.
6. Se despliega un reporte del promedio por otros datos socioeconómicos
por periodo de tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.

Tabla 17.Documentación de casos de uso CU04-03. Elaboración propia.

Caso de uso:
Consultar resultado promedio por factores de estudiante por periodo de tiempo.
ID:
CU04-04

Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de consultar
factores asociados.
2. El usuario selecciona la clasificación promedio por factores de
estudiante por periodo de tiempo.
3. Se agrupan los datos en la cantidad de estudiantes promedio por
factores de estudiante por periodo de tiempo.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por factores de estudiante.
5. Mostrar la información del número de estudiantes de acuerdo a la
clasificación configurada.
6. Se despliega un reporte del promedio de los resultados de las pruebas,
por factores de estudiante por periodo de tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.
Tabla 18. Documentación de caso de uso CU04-04. Elaboración propia.

Caso de uso:
Consultar resultado promedio por variables socioeconómicas del hogar por
periodo de tiempo.
ID:
CU04-05

Actores:
Usuario DW

Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la opción de factores
asociados.
2. El usuario selecciona la clasificación por variables socioeconómicas del
hogar por periodo de tiempo.
3. Se agrupan los datos en la cantidad de estudiantes por variables
socioeconómicas del hogar por periodo de tiempo.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por variables socioeconómicas de hogar.
5. Mostrar la información del número de estudiantes de acuerdo a la
clasificación configurada.
6. Se despliega un reporte del promedio de los resultados, por variables
socioeconómicas del hogar por periodo de tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.

Tabla 19. Documentación de caso de uso CU04-05. Elaboración propia.


Caso de uso:
Consultar resultado promedio por factores de hogar, estudiante y tiempo.

ID:
CU04-06

Actores:
Usuario DW
Precondiciones:
1. Se debe realizar la extracción, transformación y carga de las pruebas
saber 5° y 9° en la bodega de datos.
2. Crear usuario para el acceso a la aplicación de visualización.

Fuente de datos:
La fuente de datos principal se encuentra en la base de datos del Icfes y estos
datos se someten a un proceso ETL y posteriormente se alojan en una bodega
de datos.

Flujo de eventos:
1. El usuario de la bodega de datos selecciona la configuración de factores
asociados.
2. El usuario selecciona la clasificación por factores de hogar, estudiante y
tiempo.
3. Se agrupan los datos en la cantidad de estudiantes por factores de
hogar, estudiante y tiempo.
4. Se hace el cálculo del promedio, sumando los puntajes de los
estudiantes que se agrupan, dividido en el número de estudiantes
agrupados por factores de hogar, estudiante y tiempo.
5. Mostrar la información del número de estudiantes de acuerdo a la
clasificación configurada.
6. Se despliega un reporte del promedio de los resultados de las pruebas,
por factores de hogar, estudiante y tiempo.

Postcondiciones:
1. El sistema genera un reporte con los hechos configurados por el usuario
durante el procedimiento.

Tabla 20. Documentación de caso de uso CU04-06. Elaboración propia.

5.2.4 IDENTIFICAR LAS FUENTES DE DATOS


La fuente de datos son los archivos de estudiantes de las pruebas saber 3°, 5° y 9°,
que son publicados por el Icfes en el servidor FTP9. Los datos que se utilizan son
archivos “.zip” que al descomprimirse contienen un archivo de texto “.txt” delimitado

9El servidor FTP es un repositorio donde se encuentran todos los datos de las diferentes pruebas
del Icfes, pero para el proyecto se usan solo los datos de estudiantes de las pruebas 3°, 5° y 9° que
se encuentran en la url ftp://200.41.6.169/2. Saber 3,5 y 9/3. Resultados Saber 359.
por barras que permite ser leído desde una hoja de cálculo como un archivo “.csv”.

Los datos obtenidos del servidor de Icfes fueron modificados por última vez el
17/02/2020 a las 7:00:00 p. m. Se encuentran junto a los resultados de otras
pruebas realizadas, que cuenta con diferentes carpetas y los resultados de los
diferentes periodos en que se llevaron a cabo, con resultados agrupados en
diferentes niveles de agrupación como se ve en la Figura 39.

Figura 39. Jerarquía de archivos en el servidor del Icfes. Elaboración propia.

La descarga del archivo “.zip” con los datos de los resultados de las pruebas saber
3, 5° y 9°, se realiza desde un navegador web por medio del protocolo ftp y es
necesario solicitar un usuario para acceder a la base de datos10. Lo primero es
ingresar los datos requeridos por el Icfes para recibir una contraseña vía correo
electrónico y con ella se accede al servidor que almacena los datos.

En la descarga del archivo de los resultados individuales de las pruebas saber 3°,
5° y 9° del año 2017 se obtuvo un archivo de tipo “.zip” con un tamaño de 69,5 MB,
10 Sitio web de Icfes para Acceso a las bases de datos y diccionarios de las pruebas
https://www.icfes.gov.co/web/guest/investigadores-y-estudiantes-posgrado/acceso-a-bases-de-
datos#Acceso%20a%20Bases%20de%20datos%20y%20diccionarios
el tiempo de descarga fue de 49.64 segundos a una velocidad de bajada de
1.4MB/S.

5.2.5 EXPLORACIÓN DE DATOS


Los datos se encuentran en un único archivo plano con columnas delimitadas por
barras; las variables se describen en la Tabla 21 y estas son clasificadas por el Icfes
en 7 grupos que son:
• Información personal: Corresponde a la información básica del estudiante
como edad, género, nacionalidad, tipo de documento, entre otros.
• Información socioeconómica: Son los datos relacionados a los bienes que
tiene en el hogar y composición de la familia.
• Otras socioeconómicas: Son preguntas de tipo social o económico que están
afines al proceso formativo del estudiante, por ejemplo, tiempo que tarda en
desplazarse al colegio, si ha perdido años, número de fallas, si recibe pagos
por realizar tareas diferentes a las del colegio, entre otras.
• Información del colegio: Estos datos son de información propia del colegio,
como la ubicación, jornada, la naturaleza, etc.
• Datos de citación del examen: Municipio y departamento donde presentó las
pruebas
• Resultados: Son los datos de las pruebas por puntaje y nivel de desempeño
en cada área.
• Información adicional: Índice y nivel socioeconómico del estudiante.

La exploración se realizó con MongoDB [31], una base de datos NoSQL orientada
a documentos, con el fin de obtener una visión general de los datos y perfilarlos
para asegurar que apoyan los requerimientos del negocio. Se llevaron a cabo varias
consultas para entender los datos, el estado en que se encuentran y la calidad de
los mismos; el proceso general de exploración se describe a continuación.

Para importar los datos del archivo a la base de datos se puede utilizar la consola,
con el comando “mongoimport” que es una herramienta propia de MongoDB, pero
también es posible hacerlo con la interfaz gráfica de usuario de Studio 3t [32], una
interfaz para administrar bases de datos de MongoDB y con la que se puede
importar archivos JSON, BSON, CSV o TSV11; en este caso es un archivo CSV
separado por barras como se ve en la Figura 40.

TSV que significa “Valores Separados por Tabulaciones” es un archivo muy parecido a los CSV,
11

muy utilizado en hojas de cálculo. Ver más en (https://www.reviversoft.com/es/file-extensions/tsv).


Figura 40. Importar archivo CSV en Mongo por medio de Studio 3T. Elaboración propia.

Una vez cargados los datos en la colección de resultados de la base de datos de


pruebas Saber, la consola de operaciones (ver Figura 41) muestra el número de
documentos y el tiempo que tardó en realizar la inserción de la información. Cada
documento contiene toda la información de un solo estudiante anonimizado en una
estructura JSON como se muestra en la Figura 42.

Figura 41. Consola de operaciones de Studio 3t. Elaboración propia.

Figura 42.Salida previa de un documento de un estudiante en formato JSON. Elaboración propia.


Desde la interfaz gráfica de usuario de Robo 3t se puede observar en la Figura 43
que hay 2.1 millones de documentos, que corresponde a 3.9 GB que es el tamaño
de la colección de los resultados del 2017.

Figura 43. Descripción de la colección de los resultados de las pruebas saber 3, 5 y 9del 2017.

Para explorar los datos se formularon algunas preguntas de interés como:


• ¿Cuántos estudiantes presentaron la prueba por grado? (ver figura Figura
44)
• ¿Cuántos estudiantes por género presentaron las pruebas? (ver Figura 45).
• ¿Cuántos estudiantes hay por cada nivel académico de padre y madre? (ver
Figura 46).
• ¿Cuántos estudiantes hay por nivel de desempeño? (ver Figura 47)
• ¿Cuáles son los valores máximos y mínimos en la prueba de matemáticas?
(ver

• Figura 48).
• ¿Cuáles son los valores máximos y mínimos en la prueba de lenguaje? (ver

• Figura 49).
• ¿Cuántos estudiantes tienen internet? (ver Figura 50).
• ¿De qué manera se desplazan los estudiantes a su colegio y cuantos hay por
cada categoría? (ver Figura 51).
Figura 44. número de estudiantes que presentaron la prueba saber 3, 5 y 9 en el año 2017. Elaboración
propia.
La consulta de cantidad de estudiantes por género que se ve en la Figura 45. Esta
muestra que existen datos “No aplica” para denotar que no pertenece a ninguno de
los dos géneros establecidos, pero también se encuentra una cantidad considerable
de datos nulos.

Figura 45. Consulta de estudiantes que presentaron la prueba saber 3, 5 y 9 por género en el año 2017.
Elaboración propia.

En la Figura 46 se ve al lado izquierdo una agregación por categoría de estudio de


los padres y a la derecha para las madres de los estudiantes.

Figura 46. Nivel académico de los padres (A la izquierda del padre y a la derecha de la madre). Elaboración
propia.

En la Figura 47 se ve al lado izquierdo una agregación por categoría de niveles de


desempeño de los estudiantes en las pruebas saber del año 2017, a la izquierda la
prueba de lenguaje y a la derecha la prueba de matemáticas.

Figura 47. Agregación por categoría de niveles de desempeño de los estudiantes (A la izquierda la prueba de
lenguaje y a la derecha la prueba de matemáticas). Elaboración propia.

Los valores máximos y mínimos en el área de matemáticas, obtenidos en las


pruebas saber 3, 5 y 9 del año 2017 se observan en la

Figura 48, en todos los grados (incluyendo el valor nulo) el máximo es 500.

Figura 48. Valores máximos y mínimos en el área de matemáticas. Elaboración propia.

Los valores máximos y mínimos en el área de lenguaje, obtenidos en las pruebas


saber 3, 5 y 9 del año 2017 se observan en la

Figura 49, en todos los grados (incluyendo el valor nulo) el máximo es 500.
Figura 49. Valores máximos y mínimos en el área de lenguaje. Elaboración propia.

Sobre las variables socioeconómicas, en algunas de ellas los valores son “Si”, “No”,
“NA” o en su defecto un dato nulo. Por ejemplo, en la Figura 50 se ven las
respuestas para la variable que dice si el estudiante tiene internet en su casa, cerca
del 25 % de los estudiantes tienen como valor “No”, es decir que no tienen acceso
a internet y esta es una de las variables que es de relevancia en el estudio de BI
sobre los factores asociados.

Figura 50. Resultados para la variable "FAMI_TIENEINTERNET". Elaboración propia.

El tiempo que tarda el estudiante al desplazarse a su colegio desde la casa, es otra


de las variables socioeconómicas en las que se definen 4 rangos que se ven en la
Figura 51.

Figura 51. Tiempos en lo que los estudiantes tardan en desplazarse al colegio. Elaboración propia.

El número de datos nulos es el mismo en todas las consultas que se realizaron, que
corresponde a 37.467 registros, que corresponde aproximadamente al 1% del total
de los datos. Al inspeccionar cada registro de los que posee estos datos nulos, se
observa que son los mismos datos nulos en las preguntas relacionadas a
información socioeconómica y algunas columnas de información personal del
estudiante como se ve en la Figura 52, sin embargo, en todos los registros se
encuentra la información del colegio y datos del estudiante como el consecutivo,
tipo de documento y la nacionalidad.

Figura 52. Ejemplo de registro con valores nulos. Elaboración propia.

En la Tabla 21 se presenta el diccionario de datos para las pruebas saber 3, 5 y 9


del año 2017 con el listado de todas las columnas que contiene el archivo, la
descripción y el tipo de dato que contiene cada una de las variables, también una
breve descripción del archivo general.

5.2.6 DESCARGA E INSTALACIÓN DE LA HERRAMIENTA PENTAHO


[33] [34].
Pentaho es un paquete de inteligencia de empresarial, de código abierto que incluye
una plataforma web y una serie de herramientas, existen dos versiones, ambas
desarrolladas en Java. Para el desarrollo del DataMart, se utilizó la herramienta de
Spoon para hacer el proceso de ETL y Pentaho Server para el despliegue de la
aplicación de inteligencia de negocios.

Pentaho data integration.


Para instalar PDI se debe seguir las siguientes instrucciones:
• Instalar Java Runtime Environment (JRE) de Sun Microsystems, versión 1.5
o superior. JRE se puede descargar libre y gratuitamente de
http://www.javasoft.com/.
• Descargar Kettle, desde la siguiente dirección:
http://sourceforge.net/projects/pentaho/files/Data%20Integration/
• Descomprimir el archivo recientemente descargado, en un directorio de su
elección. Por ejemplo: "/home/datos/programas/".
DICCIONARIO DE DATOS PARA LOS RESULTADOS DEL 2017
Nombre del archivo Saber_359_Estudiante_2017
Fecha de consulta Junio del 2020
Tamaño del archivo 1,03 GB
Número de registros 2’080.164
Fecha de publicación en el servidor FTP 7 de junio del 2018
Información personal
Variable Descripción Tipo de dato
ESTU_TIPODOCUMENTO Tipo de Documento del estudiante. CC, CCB, CE, CR, NES, NUIP,
OD, PC, PE, RC, TI.
ESTU_NACIONALIDAD Nacionalidad del estudiante (País). Texto
ESTU_GENERO Género del estudiante. M, F.
ESTU_EDAD Edad del estudiante. PARA TERCERO: 7 años o
menos, 8 años, 9 años, 10 años o
más.
PARA QUINTO: 9 años o menos,
10 años, 11 años, 12 años o más.
PARA NOVENO: 13 años o
menos, 14 años, 15 años, 16 años
o más, NA.
ESTU_GRADO Grado del estudiante. 3, 5, 9
ESTU_FECHANACIMIENTO Fecha de nacimiento del estudiante. [DD/MM/AAAA]
Periodo Abierta (ejemplo 20101-20102). 2017
ESTU_CONSECUTIVO Identificador público del estudiante. Texto

ESTU_ESTUDIANTE Indica si realizó la inscripción por Estudiante


medio de un colegio (estudiante) o
fue individual.
ESTU_PAIS_RESIDE Código del país donde reside Texto
actualmente el
Estudiante.
Información socioeconómica
FAMI_EDUCACIONPADRE Nivel educativo más alto alcanzado Primaria, Bachillerato, Técnico o
por el padre. Tecnólogo Universitario - Pregrado
Universitario – Posgrado, NA.
FAMI_EDUCACIONMADRE Nivel educativo más alto alcanzado Primaria, Bachillerato, Técnico o
por la madre. Tecnólogo Universitario - Pregrado
Universitario – Posgrado, NA.
FAMI_PERSONASHOGAR ¿Cuántas personas conforman el 2, 3, 4, 5, 6, NA.
hogar donde vive actualmente,
incluido usted?
FAMI_CUARTOSHOGAR En total, ¿en cuántos cuartos 1, 2, 3, 4, 5, 6, NA.
duermen las personas de su hogar?
FAMI_TIENEINTERNET ¿Su hogar cuenta con servicio o No, Sí, NA.
conexión a internet?
FAMI_TIENESERVICIOTV ¿Su hogar cuenta con servicio No, Sí, NA.
cerrado de televisión?
FAMI_TIENECOMPUTADOR ¿Cuáles de los siguientes bienes No, Sí, NA.
posee su hogar?: Computador
FAMI_TIENELAVADORA ¿Cuáles de los siguientes bienes No, Sí, NA.
posee su hogar?: Máquina lavadora
de ropa
FAMI_TIENEHORNOMICROOGAS ¿Cuáles de los siguientes bienes No, Sí, NA.
posee su hogar?: Horno Microondas
u Horno eléctrico o a gas
FAMI_TIENEAUTOMOVIL ¿Cuáles de los siguientes bienes No, Sí, NA.
posee su hogar?: Automóvil particular
FAMI_TIENECONSOLAVIDEOJUEGOS ¿Cuáles de los siguientes bienes No, Sí, NA.
posee su hogar?: Consola para
juegos electrónicos (PlayStation,
Xbox, Nintendo, etc.)
FAMI_TRABAJOLABORPADRE Señale aquella labor que sea más Trabaja en el hogar; no trabaja o
similar al trabajo que realizó su padre estudia.
durante la mayor parte del último
año: Es dueño de un negocio pequeño
(tiene pocos empleados o no tiene;
por ejemplo, tienda, papelería,
salón de belleza, lavandería, etc.)

Es dueño de un negocio grande


(empresa o institución); tiene un
cargo de nivel directivo o gerencial

Tiene un trabajo de tipo auxiliar


administrativo (por ejemplo,
secretario o asistente)

Es vendedor, vende por catálogo o


trabaja en atención al público

Es agricultor, pescador o jornalero


Trabaja por cuenta propia (por
ejemplo, plomero, electricista)

Es operario de máquinas o
conduce vehículos (taxista, chofer)

Realiza labores de limpieza,


mantenimiento, seguridad o
construcción

Trabaja como profesional (por


ejemplo, médico, abogado)
Es pensionado

NA
FAMI_TRABAJOLABORMADRE Señale aquella labor que sea más Trabaja en el hogar; no trabaja o
similar al trabajo que realizó su estudia
madre durante la mayor parte del
último año: Es dueño de un negocio pequeño
(tiene pocos empleados o no tiene;
por ejemplo, tienda, papelería,
salón de belleza, lavandería, etc.)

Es dueño de un negocio grande


(empresa o institución); tiene un
cargo de nivel directivo o gerencial

Tiene un trabajo de tipo auxiliar


administrativo (por ejemplo,
secretario o asistente)

Es vendedor, vende por catálogo o


trabaja en atención al público

Es agricultor, pescador o jornalero


Trabaja por cuenta propia (por
ejemplo, plomero, electricista)

Es operario de máquinas o
conduce vehículos (taxista, chofer)

Realiza labores de limpieza,


mantenimiento, seguridad o
construcción

Trabaja como profesional (por


ejemplo, médico, abogado)

Es pensionado

NA
ESTU_DEDICACIONINTERNET Usualmente, ¿cuánto tiempo al día No navego en internet, 30 minutos
dedica a navegar en internet? o menos, Entre 30 y 60 minutos,
Excluya actividades académicas Entre 1 y 3 horas, Más de 3 horas,
NA.
Otras socioeconómicas
ESTU_COMODESPLAZACOLEGIO Usualmente, ¿cómo te desplazas al Caminando o en bicicleta, En bus
colegio? o transporte público, En transporte
escolar o particular, Otro (burro o
caballo, canoa, lancha, etc.), NA.
ESTU_TIEMPODESPLAZACOLEGIO ¿Cuánto tiempo tardas en ir de tu Menos de 15 minutos, Entre 15 y
casa al colegio? 30 minutos, Entre 30 minutos y
una hora Más de 1 hora, NA.
ESTU_ANOSPREESCOLAR ¿Cuántos años cursaste de Ninguno, Un año, Dos años, Tres
preescolar? años, No me acuerdo, NA.
ESTU_ESTECOLEGIO_ANOPASADO ¿Estudiaste en este colegio el año No, Sí, NA.
pasado?

ESTU_GRADOCOMENZO_ESTECOLEGIO ¿Desde qué grado estudias en este Primero, Segundo, Tercero,


colegio? Cuarto, Quinto, NA.
ESTU_REPROBOGRADO ¿Has repetido algún grado? PARA QUINTO: No, Sí
PARA NOVENO: No, nunca Sí, en
primaria y secundaria, Solamente
en primaria, Solamente en
secundaria, NA.
ESTU_TARDEACLASE En el último mes, ¿cuántas veces Nunca, Una o dos veces por
llegaste tarde a clase? semana, Una o dos veces por
mes, Todos los días, NA.
ESTU_NOFUEALCOLEGIO En el último mes, ¿cuántos días Nunca, Uno o dos días, Tres a
dejaste de ir al colegio? cinco días, Más de cinco días, NA
ESTU_REMUNERA_OTRASACTIVIDADES ¿Has recibido algún tipo de pago por No, Sí, NA.
realizar otra labor distinta a las
escolares?
ESTU_SERETIROCOLEGIO ¿Alguna vez te retiraste del colegio o No, Sí menos de un año, Sí un
suspendiste tus estudios? año, Sí dos años o más, NA
FAMI_NUMLIBROS ¿Cuántos libros físicos o electrónicos 0 a 10 libros, 11 a 25 libros, 26 a
hay en tu hogar excluyendo 100 libros, Más de 100 libros, NA.
periódicos, revistas, directorios
telefónicos y libros del colegio?
Información del colegio
COLE_COD_DANE_ESTABLECIMIENTO Código Dane del establecimiento. Numérica
COLE_NOMBRE_ESTABLECIMIENTO Nombre del Establecimiento. Texto
COLE_GENERO Indica el género de la población del FEMENINO, MASCULINO,
establecimiento. MIXTO.
COLE_NATURALEZA Indica la naturaleza del NO OFICIAL, OFICIAL.
establecimiento
COLE_BILINGUE Indica si el establecimiento es N, S.
bilingüe o no
COLE_CARACTER Indica el carácter del establecimiento. ACADÉMICO, TÉCNICO,
TÉCNICO/ACADÉMICO, NO
APLICA.
COLE_COD_DANE_SEDE Código Dane de la sede. Numérica
COLE_NOMBRE_SEDE Nombre de la Sede. Texto
COLE_AREA_UBICACION Área de ubicación de la sede. RURAL, URBANO.
COLE_JORNADA Jornada de la sede. COMPLETA, MAÑANA, NOCHE,
SABATINA, TARDE UNICA.
COLE_COD_MCPIO_UBICACION Código Dane del municipio donde Numérica
está ubicada la sede.
COLE_MCPIO_UBICACION Nombre del municipio donde está Texto
ubicada la sede.
COLE_COD_DEPTO_UBICACION Código Dane del departamento de la Numérica
sede.
COLE_DEPTO_UBICACION Nombre del departamento donde Texto
está ubicada la sede.
Datos citación del examen
ESTU_COD_MCPIO_PRESENTACION Código Dane del municipio Numérica.
presentación del examen.
ESTU_MCPIO_PRESENTACION Municipio de presentación del Texto
examen
ESTU_COD_DEPTO_PRESENTACION Código Dane del departamento del Numérica
municipio de presentación del
examen
Resultados
PUNT_LENGUAJE Puntaje del estudiante en lenguaje Rango [100, 500]
NIVEL_DESEMP_LENGUAJE Nivel de desempeño en lenguaje. Insuficiente, Mínimo, Satisfactorio,
Avanzado.
PUNT_MATEMATICAS Puntaje del estudiante en Rango [100, 500]
matemáticas.
NIVEL_DESEMP_MATEMATICAS Nivel de desempeño en matemáticas Insuficiente, Mínimo, Satisfactorio.
Información adicional
ESTU_INSE_INDIVIDUAL Índice socioeconómico a nivel de Numérica – Rango [1,100]
estudiante.
ESTU_NSE_ESTABLECIMIENTO Nivel Socioeconómico del NSE1, NSE2, NSE3, NSE4.
Establecimiento.
Tabla 21. Descripción de los datos. Elaboración propia.
Pentaho Server.
El núcleo de mondrian es un JAR que actúa como JDBC para OLAP. Con lo que
es posible obtener conexiones y consultas SQL contra la base de datos relacional
que proporciona los datos.

Lo primero es realizar la descarga de Pentaho Server desde el sitio oficial12, en la


sección de “Files” se encuentra un directorio con el nombre de “Bussiness
intelligence Server” y luego seleccionar preferiblemente la versión 8.0.

Extraer pentaho-server-ce-8.1.0.0-12.zip en la carpeta creada anteriormente.


En el caso de windows será necesario crear nueva variable del sistema o variable
de entorno.
Pentaho server es un servidor que su interfaz se da desde un navegador (ver Figura
53), así que es necesario abrir en el navegador de internet y acceder a la ruta
“http://localhost.:8080/pentaho/”

Figura 53. Ventana de login de Pentaho Server.

El detalle de la instalación se puede consultar en el Manual de Instalación de toda


la aplicación, el cual tiene el paso a paso de la instalación de Pentaho data
integration y Pentaho server, que son las herramientas de inteligencia de negocios.

5.2.7 DISEÑO DE LA ARQUITECTURA DEL SISTEMA.


La arquitectura describe los componentes que hacen parte de la solución para
implementar el DataMart con el fin de cumplir con los requerimientos de negocio ya
definidos. En la Figura 54 se ve el flujo de los datos desde el servidor del Icfes hasta
la aplicación de análisis de negocio; para conseguir ese flujo son necesarias algunas
herramientas como Mongo para la exploración, Pentaho para el proceso ETL y el
análisis de los datos.

La fuente de datos corresponde al servidor del Icfes que mediante el protocolo ftp y
un usuario se puede acceder a la descarga de los archivos de los resultados en la
ruta13 de los resultados individuales (ver Figura 54). Los datos llegan al área de
12 Sitio oficial para la descarga de recursos de Pentaho http://sourceforge.net/projects/pentaho/
13 Ruta especifica de los resultados individuales por estudiante de las pruebas 3°, 5° y 9°
(ftp://ftp.icfes.gov.co/2.%20Saber%203,5%20y%209/3.%20Resultados%20Saber%20359/2017/6.%
stage o zona de landing que en la arquitectura es un área de datos intermedia entre
el DataMart y las fuentes de datos. La zona de stage se divide en dos, las carpetas
donde se almacena los datos en bruto (ver Figura 55) y la segunda parte que
corresponde a MongoDB para la exploración de los datos.

Siguiendo con el flujo, en el procesamiento y almacenamiento se presentan dos


servidores, en primera medida, el servidor de Pentaho Data Integration para las
tareas de transformación y carga con la herramienta Spoon, con el fin de poder
pasar los datos al servidor de bases de datos PostgreSQL que es el motor que
tendrá la bodega de datos a fin de ser consumida por la capa de análisis de datos,
donde está el servidor de Pentaho encargado de los procesos OLAP y suministrar
al usuario final una interfaz con informes, tableros y herramientas de análisis de los
datos.

Figura 54. Arquitectura del sistema. Elaboración propia.

La arquitectura combina varias herramientas que componen el sistema desde la


extracción de los datos, hasta el análisis de negocio donde se destaca Pentaho
como herramienta de transformación, carga, inteligencia de negocios, procesos
OLAP y análisis de datos.

20Estudiante/). Índice de ftp://ftp.icfes.gov.co/2. Saber 3,5 y 9/3. Resultados Saber 359/2017/6.


Estudiante/.
Figura 55. Estándar de nombre del stage area. Elaboración propia.

5.2.8 RESUMEN DEL SPRINT 1


Con base en los requerimientos extraídos de los reportes de resultados entregados
por el Icfes a las diferentes instituciones educativas y entidades territoriales, parte
todo el trabajo del sprint 1, desde la descripción de los requerimientos de negocio,
donde se detalla la gestión de volumen de estudiantes, la gestión de estadísticas de
desempeño y la gestión factores asociados, con el objetivo de clasificar variables
importantes desde distintos periodos de tiempo. Es fundamental que los
requerimientos sean claros con la finalidad del negocio, pues es el punto de partida
del diseño del modelo dimensional.

En la extracción y exploración de los datos, un aspecto que se resalta es el número


de datos nulos en columnas de factores socioeconómicos y de datos personales del
estudiante; el número de datos nulos es el mismo en todas las consultas que se
realizaron, que corresponde a 37.467 registros equivalente al 1.8% de los datos, los
cuales podrían ser eliminados. Sin embargo, el modelo de Ralph Kimball
recomienda no tomar este tipo de decisiones en esta etapa de la construcción del
proyecto, ya que puede ser muy apresurado dado que estos registros tienen
información de la institución educativa, que es un factor que puede ser de valor en
el análisis [4]. En resumen, los datos presentan una buena calidad ya que se maneja
un estándar para cada variable, son consistentes y las variables de interés se
encuentran bien definidas.

5.3 DESARROLLO DEL SPRINT 2

Actividades ▪ Elaboración de la matriz bus de alto nivel


▪ Definir grano de la tabla de hechos
▪ Definir dimensiones
▪ Definir tabla de hechos
▪ Realizar modelo de alto nivel
▪ Creación de modelo dimensional detallado
▪ Diseño de aplicación BI (Reportes y estadísticas
con factores asociados).
▪ Diseño del proceso ETL
Entregables ▪
Matriz bus

Modelo del DataMart

Documentación de las dimensiones y de la tabla de
hechos.
▪ Diseño de aplicación BI y reportes
▪ Proceso de extracción
Duración 5 semanas

Figura 56.Resumen Sprint 1. Elaboración propia.

5.3.1 MATRIZ BUS DE ALTO NIVEL


Para iniciar el modelamiento dimensional se debe tener en cuenta que el modelo
debe estar basado en la sencillez, con el objetivo de facilitar el análisis de la
información; este análisis es realizado por medio de reportes, de modo que al
modelar el DataMart se debe tener como objetivo la información requerida en los
reportes [4].

El primer paso del diseño es determinar el proceso de negocio o evento de


medición. Para ser modelados se debe construir la matriz bus, un entregable de la
metodología de Kimball, que permite sintetizar dimensiones y procesos de negocio
para iniciar la creación del modelo dimensional, en esta matriz las filas de la matriz
corresponden a los procesos de negocio. Las columnas de la matriz pertenecen a
las agrupaciones naturales de datos que pueden describir contundentemente
características de los procesos de negocio [4].

Las dimensiones deben describir el "quién, qué, cuándo, dónde, por qué y cómo"
del contexto de la medición [4]. Para el caso de las pruebas Saber se hace un
bosquejo de las posibles entidades que pueden responder estas preguntas, con el
fin de empezar a construir las dimensiones del modelo dimensional.

La matriz de bus permite establecer los procesos de negocio en relación a las


dimensiones conformadas o más claramente de agrupaciones naturales que dan
luz de sustantivos o verbos descriptivos para realizar el análisis de los datos [4].

Dimensiones comunes
Procesos de Año Sede Colegio Factores Lugar de
negocio/ Evento asociados Citación
Volumen de X X X X X
estudiantes
Promedio de X
desempeño
Nivele de
desempeño
Incidencia X X X
Socioeconómica
Instituciones y X X X
entidades
territoriales
Tabla 22.Matriz de bus. Elaboración propia.

Identificar los participantes y definir aspectos como las convenciones y nombres


adecuados para los diferentes elementos del modelo dimensional. A continuación,
se describen las convenciones y abreviaturas que se utilizan en el modelo
dimensional, la mayoría de los nombres de variables se conservan ya que tiene una
estructura concisa y una semántica asociada.

Convención Significado
FAMI Atributo que hace referencia a una característica familiar del
estudiante.
ESTU Atributo que hace referencia a datos propios del estudiante.
COLE Atributo que describe valores de la institución educativa.
PUNT Puntaje
DIM Convención utilizada en las dimensiones, antes del nombre de
la tabla.
Tabla 23. Tabla de convenciones del modelo dimensional. Elaboración propia.

5.3.2 DEFINIR GRANO


La declaración del grano de la tabla de hechos, consiste en definir exactamente una
fila de la tabla hechos en el modelo dimensional de procesos de negocio propuesto;
es la parte más fina que se puede obtener al realizar una consulta dentro del modelo
dimensional.

El grano del modelo dimensional para las pruebas saber de 5° y 9° se define como
el registro individual de cada estudiante en las pruebas presentadas en un año; de
esta forma será posible llegar al grado de detalle de consultar por estudiante
específico (anonimizado), aunque este no sea el objetivo. El registro individual tiene
los datos personales de cada estudiante, el año de presentación, información de la
institución, los factores asociados, datos de la citación al examen y finalmente los
resultados de las pruebas por asignatura [4].

5.3.3 DEFINIR DIMENSIONES


A partir del grano, el diseño se construye con las dimensiones que adquieren un
valor único en el grano declarado que será representado en la tabla de hechos. Las
tablas de dimensiones consisten en datos muy bien agrupados, para representar
los objetos principales del objetivo de negocio, tales como los estudiantes, colegios
o entidades territoriales.

Es importante analizar varias situaciones en dos de las dimensiones señaladas,


pues, en primer lugar, son 25 las columnas que contienen información
socioeconómica del estudiante, pero que se puede clasificar en dos tipos: por un
lado, la información socioeconómica que va relacionada con el núcleo familiar del
estudiante (14 columnas) y por otro lado la información socioeconómica más
específica del estudiante (11 columnas). Lo óptimo para distribuir las columnas de
la información socioeconómica, es contemplar dos categorías que son candidatas
a ser dimensiones, estas son los factores socioeconómicos familiares y los factores
socioeconómicos del estudiante. Esta clasificación incluso puede mejorar aspectos
de análisis y rendimiento en las consultas OLAP. Con la matriz bus de la Tabla 22
se pueden identificar las dimensiones que participan para la construcción del
modelo dimensional. Se plantean los siguientes dos modelos de alto nivel iniciales:

Estudiante Factores asociados


Familiares Sede

Resultado
Colegio prueba saber

Citación Factores asociados Tiempo


Estudiante

Figura 57. Modelo dimensional de alto nivel 1. Elaboración propia.

Factores asociados
Estudiante Familiares Sede

Colegio Resultado Área


prueba saber

Citación Factores asociados Tiempo


Estudiante

Figura 58. Modelo dimensional de alto nivel 2. Elaboración propia.

Los modelos de alto nivel de las Figuras 42 y 43 se diferencian en la dimensión


Área, pues es una dimensión que podría permitir el almacenamiento de resultados
de diferentes asignaturas que se puedan agregar a futuro. A continuación, se hace
una muestra en la Tabla 24 y la Tabla 25 de cómo se podría comportar cada uno de
estos modelos, para definir el modelo definitivo:

TABLA DE HECHOS
Estu Col Sed Tiem Fa_Fa Fa_Es Cit P_Mate P_Len P_otra Cant
E1 C1 S1 T1 F1 FE1 C1 300 300 Na 1
E2 C1 S1 T1 F2 FE2 C2 100 100 Na 1
E3 C2 S2 T1 F3 FE3 C3 250 250 Na 1
E4 C3 S3 T1 F4 FE4 C3 210 210 Na 1
E5 C3 S4 T1 F5 FE5 C4 350 350 Na 1
E6 C4 S5 T2 F6 FE6 C5 120 120 280 1
Tabla 24. Tabla de hechos para el modelo dimensional 1. Elaboración propia.

De la Tabla 24 se toma el estudiante “E1” se obtiene que es del colegio “C1”, la


sede “S1”, puntaje matemáticas “300”, puntaje lenguaje “300” y puntaje de otra
asignatura “Na” y esto es porque en ese periodo de tiempo no se aplicaron otras
asignaturas diferentes a lenguaje y matemáticas, cosa que no pasa con el
estudiante “E6” pues presentó las pruebas en otro periodo de tiempo diferente y en
este se presentó una asignatura diferente, esto es en un caso hipotético en el que
se previene algún cambio a futuro, sin embargo, desde el inicio de las pruebas en
el 2009 hasta el 2020, siempre se mantuvieron las mismas 4 asignaturas que solo
se alternan algunas cada año. Teniendo en cuenta esto, es poco probable que el
cambio sea drástico, pues el objetivo siempre es conocer el resultado de los
estudiantes en el núcleo común, entonces para este modelo se dejan los campos
de estas áreas y un campo para poder almacenar otra que pueda ser integrada a
las pruebas más adelante.

TABLA DE HECHOS
Estu Col Sed Tiem Fa_Fa Fa_Es Cit Área Puntaje Cant
E1 C1 S1 T1 F1 FE1 C1 L 300 1
E1 C1 S1 T1 F1 FE1 C1 M 300 1
E2 C2 S2 T1 F2 FE2 C2 L 100 1
E2 C2 S2 T1 F2 FE2 C2 M 150 1
E3 C3 S3 T2 F3 FE3 C3 L 250 1
E3 C3 S3 T2 T2 FE3 C3 M 200 1
E3 C3 S3 T2 T2 FE3 C3 C 180 1
Tabla 25.Tabla de hechos para el modelo dimensional 2. Elaboración propia.

La Tabla 25 representa la tabla de hechos para el modelo dimensional 2, el primer


aspecto que se debe analizar es que para cada área que el estudiante presente la
prueba, aparecerá un registro en la tabla de hechos. Como podemos ver, el
estudiante “E1” tiene dos registros, pues si bien toda la información es la misma,
solo cambia el área y el puntaje de la misma. Si se diera el caso de que apareciera
otra área, como el caso del estudiante “E3” que presentó su prueba en un periodo
de tiempo diferente, tendrá otro registro adicional, ya que en este periodo fueron 3
pruebas.
Después del análisis, se puede concluir que el modelo dimensional de la Figura 57,
es más apropiado pues se estima que el Icfes mantenga las mismas áreas desde el
inicio de la aplicación de las pruebas saber 3°, 5° y 9°. Sin embargo, tendrá espacio
el modelo para algún cambio o un área nueva a futuro.

Así que las dimensiones del modelo dimensional para almacenar los resultados de
las pruebas 5° y 9° serán las siguientes:

• Estudiante: Es importante tener la dimensión del estudiante, ya que contiene


el resultado individual y el perfil del estudiante, para contrastar la información.
• Colegio: Los informes del Icfes dan importancia a los resultados agrupados
por colegios, ya que permite evaluar el rendimiento de las instituciones en las
pruebas.
• Sede: Es un agrupamiento más específico, ya que los colegios poseen varias
sedes ubicadas en diferentes municipios, características que pueden
diversificar los resultados.
• Citación: Lugar que fue citado el estudiante para presentar las pruebas.
• Factores asociados familiares: Es la información que se quiere analizar, de
preguntas socioeconómicas que se relacionan al entorno familiar del
estudiante.
• Factores asociados estudiante: Es la información que se quiere analizar, de
preguntas socioeconómicas que se relacionan propiamente al estudiante.
• Tiempo: Determina el periodo en que se presentaron las pruebas.

En las siguientes plantillas se documentan algunas dimensiones, las demás se


pueden consultar en el Anexo 10.2.1.

Dimensión Estudiante
Dimensión Frecuencia PK
Dim_estudiante Anual Estu_consecutivo
Descripción
Dimensión que permite almacenar datos de estudiantes a nivel individual con la
información personal que puede ser publicada por el Icfes, ya que no todos los
datos personales son de acceso público.
Atributos
Nombre Tipo Descripción
estu_consecutivo Varchar(20) Identificador público del estudiante, es un
consecutivo que se asigna a cada uno de
los estudiantes inscritos a la plataforma
del Icfes. Es una identificación única en el
sistema del icfes.
estu_tipodocumento Varchar(6) Tipo de Documento del estudiante.
estu_nacionalidad Varchar(18) Nacionalidad del estudiante.
estu_genero Varchar(8) Género del estudiante.
estu_edad Varchar(40) PARA TERCERO: 7 años o menos, 8
años, 9 años, 10 años o más.
PARA QUINTO: 9 años o menos, 10 años,
11 años, 12 años o más.
PARA NOVENO: 13 años o menos, 14
años, 15 años, 16 años o más, NA.
estu_grado Integer Grado del estudiante.
estu_fechanacimiento Date Fecha de nacimiento del estudiante.
[DD/MM/AAAA]
estu_inscripcion Varchar(20) Indica si realizó la inscripción por medio de
un colegio (estudiante) o fue individual.
estu_pais_recide Varchar(30) Código del país donde reside actualmente
el Estudiante.
estu_inse_individual Integer Índice socioeconómico a nivel de
estudiante.
Figura 59. Documentación dimensión estudiante. Elaboración propia.

Dimensión Factores asociados Familiares


Dimensión Frecuencia PK
dimSocieconomicoFamilia Anual Id_dim_tiempo
Descripción
Dimensión de las variables socioeconómicas familiares relacionados al
estudiante. Información sobre los factores que inciden en los resultados
académicos. El ICFES realiza el estudio de factores asociados en el que
estudiantes, docentes y rectores respondieron preguntas sobre sus contextos
personales, socioeconómicos y escolares que permitieran conocer los factores
que inciden en el aprendizaje de los primeros.
Atributos
Nombre Tipo Descripción
id_soc_familia integer Llave subrogada que identifica la
información socioeconómica
familiar asociada al estudiante.
fami_educacionpadre Varchar(29) Nivel educativo más alto
alcanzado por el padre. Primaria,
Bachillerato, Técnico o
Tecnólogo Universitario -
Pregrado Universitario –
Posgrado, NA.
fami_educacionmadre Varchar(29) Nivel educativo más alto
alcanzado por la madre.
Primaria, Bachillerato, Técnico o
Tecnólogo Universitario -
Pregrado Universitario –
Posgrado, NA.
fami_personashogar Varchar(4) ¿Cuántas personas conforman el
hogar donde vive actualmente,
incluido usted? (2, 3, 4, 5, 6, NA)
fami_cuartoshogar Varchar(4)
En total, ¿en cuántos cuartos
duermen las personas de su
hogar? (1, 2, 3, 4, 5, 6, NA)
fami_tieneinternet Varchar(3) ¿Su hogar cuenta con servicio o
conexión a internet? (No, Sí, NA)
fami_tieneserviciotv Varchar(3) ¿Su hogar cuenta con servicio
cerrado de televisión? (No, Sí,
NA)
fami_tienecomputador Varchar(3) ¿Cuáles de los siguientes bienes
posee su hogar?: Computador
No, Sí, NA
fami_tienelavadora Varchar(3) ¿Cuáles de los siguientes bienes
posee su hogar?: Máquina
lavadora de ropa
No, Sí, NA
fami_tienehornomicroogas Varchar(3) ¿Cuáles de los siguientes bienes
posee su hogar?: Horno
Microondas u Horno eléctrico o a
gas
No, Sí, NA
fami_tieneautomovil Varchar(3) ¿Cuáles de los siguientes bienes
posee su hogar?: Automóvil
particular
No, Sí, NA
fami_tieneconsolavideojuegos Varchar(3) ¿Cuáles de los siguientes bienes
posee su hogar?: Consola para
juegos electrónicos (PlayStation,
Xbox, Nintendo, etc.)
No, Sí, NA
fami_trabajolaborpadre Varchar(150) Señala aquella labor que sea
más similar al trabajo que realizó
el padre durante la mayor parte
del último año
fami_trabajolabormadre Varchar(150) Señala aquella labor que sea
más similar al trabajo que realizó
su padre durante la mayor madre
del último año.
Figura 60. Documentación dimensión factores asociados familiares Elaboración propia.

Factores asociados Estudiante


Dimensión Frecuencia PK
dimSocieconomicoEstudiante Anual id_soc_estudiante
Descripción
Dimensión de las variables socioeconómicas propias de los estudiantes.
Información sobre los factores que inciden en los resultados académicos. El
ICFES realiza el estudio de factores asociados en el que estudiantes, docentes y
rectores respondieron preguntas sobre sus contextos personales,
socioeconómicos y escolares que permitieran conocer los factores que inciden en
el aprendizaje de los primeros.
Atributos
Nombre Tipo Descripción
id_soc_estudiante Integer Llave subrogada que identifica
las variables socieconómicas del
estudiante.
estu_dedicacioninternet Varchar(25) Usualmente, ¿cuánto tiempo al
día dedica a navegar en
internet? Excluya actividades
académicas
No navego en internet, 30
minutos o menos, Entre 30 y 60
minutos, Entre 1 y 3 horas, Más
de 3 horas, NA.
estu_comodesplazacolegio Varchar(25) Usualmente, ¿cómo te
desplazas al colegio?
Caminando o en bicicleta, En
bus o transporte público, En
transporte escolar o particular,
Otro (burro o caballo, canoa,
lancha, etc.), NA.
estu_tiempodesplazacolegio Varchar(36) ¿Cuánto tiempo tardas en ir de
tu casa al colegio?
Menos de 15 minutos, Entre 15
y 30 minutos, Entre 30 minutos y
una hora Más de 1 hora, NA.
estu_anospreescolar Varchar(15) ¿Cuántos años cursaste de
preescolar?
Ninguno, Un año, Dos años,
Tres años, No me acuerdo, NA.
estu_estecolegio_anopasado Varchar(3) ¿Estudiaste en este colegio el
año pasado?
No, Sí, NA.
estu_gradocomenzo_estecolegio Varchar(9) ¿Desde qué grado estudias en
este colegio?
Primero, Segundo, Tercero,
Cuarto, Quinto, NA.
estu_reprobogrado Varchar(35) ¿Has repetido algún grado?
PARA QUINTO: No, Sí
PARA NOVENO: No, nunca Sí,
en primaria y secundaria,
Solamente en primaria,
Solamente en secundaria, NA
estu_tardeaclase Varchar(29) En el último mes, ¿cuántas
veces llegaste tarde a clase?
Nunca, Una o dos veces por
semana, Una o dos veces por
mes, Todos los días, NA.
estu_nofuealcolegio Varchar(22) En el último mes, ¿cuántos días
dejaste de ir al colegio?
Nunca, Uno o dos días, Tres a
cinco días, Más de cinco días,
NA
estu_remunera_otrasactividades Varchar(3) ¿Has recibido algún tipo de
pago por realizar otra labor
distinta a las escolares?
No, Sí, NA.
estu_seretirocolegio Varchar(23) ¿Alguna vez te retiraste del
colegio o suspendiste tus
estudios?
No, Sí menos de un año, Sí un
año, Sí dos años o más, NA
Figura 61, Documentación dimensión factores asociados del estudiante. Elaboración propia.

5.3.4 DEFINIR MÉTRICAS


Con las pruebas saber 5° y 9° el Icfes busca medir las competencias de los
estudiantes de acuerdo a los estándares básicos de competencias en Lenguaje,
Matemáticas, Ciencias y Ciudadanas establecidos por el Ministerio de Educación
Nacional (MEN) y Ascofade (Asociación Colombiana de Facultades de Educación).
[1]

En quinto y noveno, los estudiantes son evaluados en matemáticas, lenguaje,


competencias ciudadanas y ciencias naturales, donde las dos últimas se intercalan
entre años desde 2012. Esto implica que en un año los estudiantes son evaluados
en las áreas de lenguaje, matemáticas y competencias ciudadanas y al siguiente
año son evaluados en las áreas de lenguaje, matemáticas y ciencias naturales. Para
el año 2017 el Icfes realizó las pruebas a los grados 5° y 9° en las áreas de
matemáticas y lenguaje [35]; Así de esta manera, las variables que se van a
convertir en las metricas son el puntaje de las áreas de lenguaje, Matemáticas,
ciencias, cultura ciudadana y se deja el campo de otra asignatura que a futuro se
pueda incluir por el Icfes.

5.3.5 DEFINIR HECHOS


La tabla de hechos contiene las métricas resultantes de los eventos de proceso de
negocio y de medición de los resultados de las pruebas saber 5° y 9°.

Resultados_pruebas_saber
PK id_pruebasaber
Atributo Tipo Descripción
id_pruebasaber Bigint llave subrogada que
identifica un hecho individual
o grano más pequeño de las
pruebas saber.
id_estu_consecutivo Varchar(20) Llave foránea de la
dimensión de estudiante.
cole_cod_dane_sede Integer Llave foránea de la
dimensión sede
id_dim_tiempo Integer Llave foránea de la
dimensión tiempo.
cole_cod_dane_establecimiento Integer Llave foránea de la
dimensión de colegio.
id_soc_familia Integer Llave foránea de la
dimensión de factores
socioeconómicos de familia.
id_soc_estudiante Integer Llave foránea de la
dimensión de variables
socioeconómicas de
estudiante.
estu_cod_mcpio_presentacion Integer Llave foránea de la
dimensión del municipio de
presentación de las pruebas.
punt_lenguaje Integer Métrica del puntaje obtenido
por el estudiante en lenguaje.
punt_matematicas Integer Métrica del puntaje obtenido
por el estudiante en
matemáticas.
punt_sociales Integer Métrica del puntaje obtenido
por el estudiante en sociales
punt_biologia Integer Métrica del puntaje obtenido
por el estudiante en biología.
punt_otra_area Integer Métrica para un puntaje de
áreas que podrían ser
evaluadas en otros años
posteriores.
cantidad Integer Cantidad de hechos por
estudiante (en este caso
como es un registro por cada
estudiante el valor será 1 y
servirá para realizar
conteos).
Figura 62. Documentación tabla de hechos. elaboración propia.

5.3.6 DISEÑO DEL MODELO DIMENSIONAL


Cada uno de los procesos de negocio del modelo dimensional para las pruebas
saber, 5° y 9° se representa mediante un modelo dimensional que consta de una
tabla hechos, que contiene las mediciones de los resultados de las diferentes
pruebas individuales por asignatura, relacionada a dimensiones que contienen el
contexto del resultado (ver Figura 64). Esta estructura característica se conoce
como modelo en estrella y cuando son almacenados en un esquema de
procesamiento analítico en línea multidimensional (OLAP) se llaman cubos [4].

Una vez que se termina el modelo de alto nivel, se definen las llaves o
identificadores de cada una de las dimensiones, para lo cual es necesario conocer
la lista de atributos de cada dimensión para escoger el atributo que sea el mejor
candidato o en su defecto construirlo. Poco a poco se llega al modelo detallado, que
se construye iniciando con las dimensiones y finalmente la tabla de hechos, donde
convergen todas las llaves de las dimensiones.

5.3.7 DISEÑO APP BI SCIRE


La aplicación se centra en conjuntos de informes en relación con el análisis de un
proceso de negocio en particular. Requiere una capa de interfaz de usuario para el
acceso a las herramientas y sirve como canal de comunicación con las fuentes de
datos [4].

Figura 63. Tipos de aplicaciones BI. Adaptación de [4].

El reto de la construcción de la aplicación debe satisfacer una lista amplia de


características, sin embargo, entre las más importantes en la metodología de
Kimball se destaca que debe ser una aplicación correcta, debe desempeñarse bien,
ser fácil de usar, verse bien y sobre todo ser una inversión a largo plazo [4].
Figura 64. Modelo Dimensional del DataMart. Elaboración propia.
La plantilla individual para los informes debe cumplir con aspectos básicos y
generales, ya que estos reportes pueden variar entre diferentes tipos de reportes
que se realicen. Se plasman en la plantilla parámetros básicos como el nombre, el
título, el cuerpo del informe, encabezado y pie de página (Categoría del reporte,
nombre y el recurso que se utilizó para su elaboración).

Figura 65. Plantilla básica para informes. Elaboración propia.

El portal de BI de la herramienta SCIRE cuenta con un entorno de navegación


sencillo y que se adapta según el tipo de usuario para tener entornos acordes a las
necesidades de cada uno de ellos. La plataforma Pentaho BI proporciona una
infraestructura para construir aplicaciones, reportes y procesos de inteligencia de
negocios. Además de todo esto, posee un enfoque de desarrollo sencillo para el
usuario final, pues es muy intuitivo ya que permite a los usuarios de negocio acceder
y fusionar cualquier tipo de datos, independientemente de la cantidad. Con una
amplia gama de herramientas de análisis avanzadas, desde informes básicos hasta
modelos de predicción, los usuarios pueden ayudarse a sí mismos para analizar y
visualizar los datos a través de múltiples medidas y dimensiones [34].

Especificación de las aplicaciones.


JPivot es una librería de componentes JSP14 que se utiliza para construir tablas
OLAP generadas de forma dinámica. Este tipo de tablas es de gran utilidad ya que
permite mostrar los resultados de las consultas filtrando por los campos de la tabla
de manera que se puedan quitar y poner distintos criterios de búsqueda de los datos
(ver Figura 66). [34]

Los reportes personalizables que ofrece Pentaho son un producto web en la que se

14JSP JavaServer Pages es una tecnología para optimizar la creación de páginas web dinámicas
basadas en HTML, XML y otros tipos de documentos.
muestran datos de forma interactiva con el usuario. Esta capa web se puede insertar
en diferentes fuentes de datos o bien realizar el despliegue directamente en Pentaho
Server, que es el lugar en el que se crean. También cuenta con tecnologías como
HTML, CSS, Bootstrap, JavaScript y jQuery, lo que permite una gama amplia de
posibilidades para poder mostrar los datos ver (
Figura 67) [34].

Figura 66. Tabla elaborada con Jpivot en la herramienta SCIRE. Elaboración propia.

Figura 67 Dashboard con Pentaho Server en la aplicación SCIRE. Elaboración propia.

5.3.8 DISEÑO DEL PROCESO ETL


Kimball propone que, para poder contar con información concreta y fiable, los
procesos ETL deben generar confianza sin importar en qué nivel de detalle se esté
generando, debe estar disponible para el usuario en todo momento y finalmente
garantizar la manejabilidad ya que a medida que va creciendo el DataMart los
procesos ETL deben ir evolucionando al mismo ritmo, pues así se pueden ir
cumpliendo los objetivos de negocio. ETL es más que extraer, transformar y cargar
datos, pues contiene una serie de tareas con un alto nivel de complejidad [4].

El diagrama BPMN de la Figura 68 describe el proceso ETL, donde se muestra la


secuencia de actividades y el flujo de datos entre los diferentes actores y el uso de
tecnologías para almacenar, explorar, cargar y analizar los datos en el DataMart. El
modelo describe las actividades de alto nivel de detalle, haciendo énfasis en el flujo
de los datos.
Figura 68. BPMN del proceso ETL. Elaboración propia.
5.3.9 RESUMEN SPRINT 2
Se diseñó el modelo dimensional basado en una estructura estrella convencional
que parte del análisis de los requerimientos y la matriz bus que facilita la conexión
de los procesos de negocio con entidades que se postulan como dimensiones del
modelo. En un inicio son dos modelos que se plantean y su principal diferencia es
el tratamiento que se le da al almacenamiento del puntaje de las áreas, sin embargo,
almacenar en una dimensión las áreas causa que se tengan que generar tantos
registros de estudiantes como asignaturas se evalúen en ese periodo, es por esto
que se descartó la opción de una dimensión para las áreas.

Para la aplicación BI se utilizará Pentaho Server, que cuenta con varias


herramientas de inteligencia de negocios para crear tableros de control, informes,
cubos, análisis OLAP, entre otras. En este sprint se generó la plantilla para los
informes y un acercamiento a las herramientas que se van a utilizar para la
construcción de los cubos OLAP y el análisis de negocios.

5.4 DESARROLLO DEL SPRINT 3

Actividades ▪ Especificar tablas de agregados.


▪ Ejecución del proceso de Extracción.
▪ Implementación del modelo dimensional del
DataMart.
▪ Definición del proceso de Transformación y carga.
▪ Ejecución los procesos ETL – Carga de datos.
Entregables ▪ Diseño de tablas de agregados.
▪ Diagramas del proceso de transformación.
▪ Diagrama del diseño de control.
▪ Documentación de las funciones o procedimientos
almacenados.
Duración 4 semanas

Tabla 26. Resumen Sprint 3. Elaboración propia.

5.4.1 ESPECIFICAR TABLAS DE AGREGADOS


Las tablas de agregado se encuentran en un nivel de granularidad diferente al
descrito en la tabla de hechos, sin embargo, convive con la tabla de hechos y el
objetivo es pre-agregar medidas definidas a partir de la tabla de hechos. Estas
tablas se crean en el mismo esquema, de modo que al construir los cubos se pueda
elegir entre las tablas de agregados en lugar de la tabla de hechos principal.

Se crearon 3 tablas de agregados usando formas diferentes para cada caso y de


esta manera resumir los datos para optimizar algunas de las consultas OLAP. En
primera medida se hizo una tabla de agregado desde el motor de base de datos
como se ve en la Figura 69, donde se agruparon los datos por sedes y colegios,
acompañadas de las medidas correspondientes de los puntajes en las diferentes
áreas y la cantidad de estudiantes.
Figura 69. Tabla de agregado simple para colegios y sedes. Elaboración propia.

Otro tipo de agregados que se pueden crear son las dimensiones colapsadas, que
consiste en llevar el campo de una dimensión a la tabla de hechos. Para el caso de
la Figura 70, se realizó la agregación del campo en la construcción del cubo OLAP
colapsando la columna “Estu_nofuealcolegio”.

Figura 70. Tabla de agregado colapsada para factor asociado. Elaboración propia.

Finalmente, otra agregación que se realizó desde la construcción del cubo es la de


la Figura 71, que consiste en un agregado no colapsado en forma de jerarquía para
la dimensión del tiempo ya que podemos hacer un escalafón de año y mes.

Figura 71. Niveles de agregado no colapsadas en Jerarquía por fecha. Elaboración propia.

5.4.2 IMPLEMENTACIÓN DEL MODELO DIMENSIONAL


Con la documentación realizada del modelo dimensional se hace la creación del
script de la construcción de los objetos de la bodega de datos como tablas, llaves,
columnas, índices y relaciones en el motor de bases de datos PostgreSQL. Se crea
una base de datos nueva con el nombre DW_PruebasSaber59 en la que se ejecuta
el script, en este caso en la consola de consultas de la interfaz pgAdmin 4. El script
generado con la herramienta de modelado, crea las sentencias según la definición
del modelo dimensional.

Luego de la ejecución del script, se realiza la validación de los campos que fueron
creados con los mismos parámetros del modelo, en la Figura 72 se ven las tablas
que se crearon en la base de datos DW_PruebasSaber59 y así finalmente se
comprueba que la creación de los objetos sea de acuerdo a la definición de la
documentación del modelo dimensional del DataMart.

Figura 72. Creación de tablas en PostgreSQL. Elaboración propia.


5.4.3 DEFINICIÓN DEL PROCESO DE TRANSFORMACIÓN Y CARGA
Para la transformación de los se utilizó Pentaho Data Integration en el que se
modela el flujo de tareas con las que se van a ejecutar la lectura, transformación de
los datos y finalmente el llamado a las funciones o procedimientos almacenados de
la base de datos. Son las funciones las encargadas de comprobar los datos y
realizar las inserciones en las respectivas filas de cada dimensión del DataMart.

La transformación se construye con el componente Spoon de Pentaho data


integration que ofrece una caja de herramientas y conectores para elaborar estos
procesos, en la Figura 73 se ven las categorías de herramientas que se pueden
utilizar para diagramar y ejecutar acciones con los datos.

Figura 73. Herramientas de Spoon para la elaboración de procesos ETL [19].

En la Figura 74 se muestra el diagrama de las tareas de transformación y carga:


inicia con la lectura de los datos del archivo csv, luego se separan los datos en 3
dimensiones que son colegios, sedes y citaciones. El paso siguiente es crear el
proceso de control para cada flujo, que consiste en dar una hora de inicio y un
estado de las excepciones y así poder empezar con el llenado de las dimensiones
con la función o procedimiento almacenado; en caso de presentarse un error, se
genera un archivo de error con los datos que no se pudieron insertar, con el objetivo
de que sea analizado y poder reintentar su carga.
Figura 74. Diagrama de Pentaho Data Integration para la creación de las dimensiones. Elaboración propia.

Por otro lado, se desarrolla un modelo para la carga de la dimensión de estudiante


y la creación de la tabla de hechos como se ve en la Figura 75.

Figura 75. Diagrama de pentaho data inegration para el cargue de estudiantes y la tabla de hechos.
Elaboración propia.

La carga de datos se realiza en dos fases, una inicialmente ejecutada desde Spoon
y la segunda mediante la ejecución de funciones o procedimientos almacenados de
la base de datos.
Antes de hacer la ejecución se debe hacer la preparación del ambiente en la base
de datos, configurando cómo van a entrar los datos y cómo se van a organizar en
cada una de las dimensiones. Aunque desde Pentaho Data Integration se hace un
primer acercamiento al direccionamiento de los datos, los procedimientos
almacenados en PostgreSQL van asegurar mejor rendimiento en los procesos de
carga se van restringir errores de inserción y de información errónea en la base de
datos. El objetivo es recibir los parámetros con el tipo de dato definido, validar que
no exista este valor en la tabla, y si no existe hacer la inserción del registro del nuevo
colegio. En la Tabla 27 y la Tabla 28 se encuentra la descripción de los
procedimientos almacenados en PostgreSQL para cargar las dimensiones de
valores socioeconómicos y de estudiante respectivamente; las demás tablas de la
documentación de los procedimientos almacenados se pueden encontrar en el
anexo 10.2.2 y algunos de los scripts en el anexo 10.3.2.

Nombre CargarSocieconomicas
Descripción La función consulta si se encuentra el registro en las dos
dimensiones de factores socioeconómicos, con los mismos
parámetros recibidos y si no están los inserta como un nuevo
registro de la base de datos. Consulta el máximo del id para
asignar el siguiente valor al registro que se va a insertar.
También se encarga de almacenar los metadatos
correspondientes al control, seguimiento de carga de los
datos como la cantidad de registros que se insertaron o se
repitieron.
Dimensiones dimSocieconomicoFamilia, dim_SocieconomicoEstudiante
afectadas
Tipo de retorno Void
Parámetros Nombre Tipo de dato
que recibe Id_soc_familia Bigint
fami_educacionpadre Varchar (29)
fami_educacionmadre Varchar (29)
fami_personashogar Varchar (49)
fami_cuartoshogar Varchar (4)
fami_tieneinternet Varchar (3)
fami_tieneserviciotv Varchar (3)
fami_tienecomputador Varchar (3)
fami_tienelavadora Varchar (3)
fami_tienehornomicroogas Varchar (3)
fami_tieneautomovil Varchar (3)
fami_tieneconsolavideojuegos Varchar (3)
fami_trabajolaborpadre Varchar (150)
fami_trabajolabormadre Varchar (150)
fami_numlibros Varchar (60)
Id_soc_estudiantes Bigint
Estu_dedicacioninternet Varchar (25)
estu_comodesplazacolegio Varchar (25)
estu_tiempodesplazacolegio Varchar (36)
estu_anospreescolar Varchar (15)
estu_estecolegio_anopasado Varchar (3)
estu_gradocomenzo_estecolegio Varchar (9)
estu_reprobogrado Varchar (35)
estu_tardeaclase Varchar (29)
estu_nofuealcolegio Varchar (22)
estu_remunera_otrasactividades Varchar (3)
estu_seretirocolegio Varchar (23)
Tabla 27.Documentación procedimiento almacenado CargarSocieconomicas. Elaboración propia

Nombre CargarEstudiante
Descripción La función consulta si se encuentra el consecutivo del
estudiante en la dimensión estudiante, de no estar crea un
nuevo registro de estudiante y además se genera el hecho en
la tabla resultados_pruebas_saber, para lo cual consulta el
valor máximo del id_pruebasaber. También se encarga de
almacenar los metadatos correspondientes al control,
seguimiento de carga de los datos como la cantidad de
registros que se insertaron o se repitieron.
Dimensiones dimEstudiante, resultados_pruebas_saber
afectadas
Tipo de retorno Void
Parámetros Nombre Tipo de dato
que recibe estu_consecutivo Varchar (20)
estu_tipodocumento Varchar (6)
estu_nacionalidad Varchar (18)
estu_genero Varchar (8)
estu_edad Varchar (40)
estu_grado Integer
estu_fechanacimiento Date
estu_estudiante Varchar (20)
estu_pais_reside Varchar (30)
estu_inse_individual Double
Punt_lenguaje Integer
Punt_matematicas Integer
Punt_ciencias Integer
Punt_competencias_ciudadanas Integer
Punt_otra_area Integer
Cantidad Integer
Tabla 28.Documentación procedimiento almacenado CargarEstudiante. Elaboración propia.

5.4.4 ESQUEMA DE ALMACENAMIENTO DE METADATOS DE


CONTROL
Para manejar el control de errores, fechas de carga y cantidad de datos insertados,
se diseñó el modelo de la Figura 76. En este esquema el objetivo es almacenar
información de los procesos de carga ejecutados y las excepciones que se generen
en cada ejecución. En el esquema también se almacena toda la información de la
cantidad de datos insertados en cada tabla, así como también los datos omitidos
por ser repetidos o tener errores dado el caso de las validaciones en el proceso de
inserción.
Figura 76. Modelo de control de procesos. Elaboración propia.

Automatización del proceso de transformación carga de datos


Para automatizar el proceso de carga se realiza una tarea para que el usuario pueda
ejecutar una carga de datos más sencilla, desde la misma herramienta Spoon de
Pentaho en la sección “Jobs” podemos programar transformaciones conjuntas y
definir sus secuencias o también sus tiempos de ejecución. En la Figura 77 se
diseña el flujo para la carga de datos, ejecutando las transformaciones de la carga
de dimensiones Figura 74 y carga de la tabla de hechos de la Figura 75.

Figura 77. Tarea de carga. Elaboración propia.

Esta programación se lleva su ejecución desde un script de bash en el que se hace


el llamado a la tarea por medio de la herramienta kitchen. A continuación, se
observa el script que ejecuta la tarea de carga de datos al DataMart.

#!/bin/bash
# Ejecución de proceso de carga de datos
1 # Directorio de instalación de Pentaho Data Integration
2 cd /home/diego/data-integration/
3 #Ejecución de carga con kitchen
4 ./kitchen.sh -file
5 /home/diego/StageArea/scripts/CargaTareaAutomatizada.ktr
6 mv
/home/diego/StageArea/Pruebas_saber59/ResultadosParaLaCarga/Resuultados
Estudiante.csv /home/diego/StageArea/Pruebas_saber59/ResultadosCargados

La ejecución de las transformaciones también se puede realizar directamente con


la herramienta Pan de Pentaho como se ve en el script a continuación:
#!/bin/bash
# Ejecución de proceso de carga de datos
1
# Directorio de instalación de Pentaho Data Integration
2
cd /home/diego/data-integration/
3
#Ejecución de la transformación de carga de dimensiones
4
./pan.sh -file /home/diego/StageArea/scripts/CargaDimensiones.ktr
5
#Ejecución de la transformación de carga de hechos
6
./pan.sh -file /home/diego/StageArea/scripts/procesocreaciónHechos.ktr
7
mv
8
/home/diego/StageArea/Pruebas_saber59/ResultadosParaLaCarga/Resuultados
Estudiante.csv /home/diego/StageArea/Pruebas_saber59/ResultadosCargados

El proceso de carga de los datos inicial se da con la ejecución manual del modelo
desde Spoon y luego este proceso al insertar datos en el motor de PostgreSQL se
activan los disparadores o funciones que van a determinar acciones para cada una
de las inserciones. Al finalizar el script Bash mueve el archivo a una carpeta
diferente para que este no sea cargado de nuevo.

5.4.5 RESUMEN DEL SPRINT 3


En el sprint 3 se realizó la ejecución de la carga de los datos al DataMart, se
obtuvieron los resultados de ejecución por medio de log de Pentaho Data Integration
(PDI) y también los datos del esquema de control que da la información para
conocer la cantidad de datos que se insertaron, tuvieron algún inconveniente al ser
insertados, los tiempos fueron registrados y permitieron generar un proceso de
optimización al llamado de los procedimientos almacenados de PostgreSQL.

5.5 DESARROLLO DEL SPRINT 4

Actividades ▪ Validación del modelo dimensional.


▪ Ejecución de consultas OLAP-BI en SCIRE
(Reportes, indicadores, agrupaciones).
▪ Validación de resultados obtenidos.
▪ Ajustes necesarios.
Entregables Validaciones de consultas al DataMart
Consultas OLAP-BI
Reportes
Duración 1 semana

Tabla 29. Resumen sprint 4. elaboración propia.

5.5.1 VALIDACIÓN DEL CARGUE DE DATOS EN DATAMART

En la Figura 78 se pueden ver los tiempos de ejecución, donde también se puede


ver el seguimiento a la cantidad de datos y la velocidad de procesamiento.
Figura 78. Ejecución Pentaho Data Integration. Elaboración propia.

En la tabla de procesos (ver Figura 79) del esquema de control se ven los procesos
que se ejecutaron para la carga de datos en el DataMart.

Figura 79. Tabla de procesos. Elaboración propia.

La tabla de excepciones del esquema de control es la que quizás nos da una mejor
panorámica de los tiempos, datos repetidos, datos insertados y las tablas que se
vieron afectadas, como se ve en la tabla de la Figura 80.

Figura 80. Tabla excepciones. Elaboración propia.

Al finalizar la ejecución de la carga de los datos, es posible observar los archivos


del log de la ejecución que nos da un estatus de todo el proceso y mensajes
enviados por Pentaho, también están los archivos de errores y los archivos
generados para la lectura de PostgreSQL (Ver Figura 81).

Figura 81. Archivos del log y de errores. Elaboración propia.


5.5.2 VALIDACIÓN DEL MODELO DIMENSIONAL
El modelo dimensional lo verificamos con la elaboración del cubo OLAP, pues en
su construcción se pueden evaluar todas las características de las dimensiones, la
tabla de hechos y la relación de los datos de las diferentes dimensiones. En el anexo
10.3.1 se puede ver el código XML que corresponde al diseño de la Figura 82, que
es un esquema que permite al motor interpretar el cubo con especificaciones
dimensionales, de esta manera se valida el modelo dimensional para la creación de
reportes de colegios, sedes y grados.

Figura 82. Diseño del modelo dimensional en SCIRE - validación de colegios, sedes y grados. Elaboración
propia.

Se evalúan las dimensiones correctamente, las métricas y la relación de las


columnas de cada tabla de modelo se acoplan correctamente desde el diseño en
Pentaho server.

5.5.3 VALIDACIÓN DE RESULTADOS OBTENIDOS.


Para verificar que la información cargada al DataMart es completa y cumple con la
integridad requerida, se van a comparar los valores reportados por el Icfes a las
instituciones educativas con la información almacenada en el DataMart y la
información de un Jpivot para un colegio especifico en la herramienta SCIRE.

Se tomó como muestra de validación un reporte entregado al colegio Liceo Cultural


Luis Enrique Osorio de los estudiantes de 9° para las pruebas de Lenguaje en el
año 2016 y 2017. En la Figura 83 encontramos el primer dato a corroborar que sería
la cantidad de estudiantes evaluados.
Figura 83. Cantidad de estudiantes evaluados de colegio Luis Enrique Osorio. [reporte ICFES]

En la base de datos del DataMart ejecutamos la siguiente consulta donde sumamos


los estudiantes de grado 9°. Un detalle importante es que los estudiantes de esta
institución con el campo de grado null, corresponden a estudiantes de este grado
ya que complementan la cifra tal como está en el reporte del Icfes.

select count(*)
1 from public.resultados_pruebas_saber h
2 inner join public.dimcolegio col on
3 col.cole_cod_dane_establecimiento=h.cole_cod_dane_establecimiento
4 inner join public.dimestudiante e on
5 e.id_estu_consecutivo=h.id_estu_consecutivo
where col.cole_cod_dane_establecimiento=311001000921 and
(e.estu_grado=9 or e.estu_grado is null)

El resultado de la consulta es de 90 estudiantes como se ve en la Figura 84.

Figura 84. Cantidad de estudiantes colegio Luis Enrique - PostgreSQL. Elaboración propia.

La siguiente validación corresponde al promedio de las pruebas saber para el grado


9° en el área de lenguaje (ver Figura 85).

Figura 85. Puntaje promedio en lenguaje para el colegio Luis Enrique Osorio. Elaboración propia.
A continuación, la consulta ejecutada para validar este promedio en el DataMart en
PostgreSQL.

1 select avg(punt_lenguaje)
2 from public.resultados_pruebas_saber h
3 inner join public.dimcolegio col
4 on col.cole_cod_dane_establecimiento=h.cole_cod_dane_establecimiento
5 inner join public.dimestudiante e
6 on e.id_estu_consecutivo=h.id_estu_consecutivo
7 where col.cole_cod_dane_establecimiento=311001000921
8 and (e.estu_grado=9 or e.estu_grado is null)

De la consulta anterior obtenemos como resultado el que se muestra en la Figura


86.

Figura 86.Puntaje promedio en lenguaje de estudiantes colegio Luis Enrique - PostreSQL. Elaboración propia.

Finalmente, se valida la información en la interfaz de la aplicación SCIRE que es lo


que verá el usuario final. Para ello se ejecuta la siguiente sentencia MDX desde un
JPivot para consultar los resultados del mismo colegio que se utilizó como muestra.

select NON EMPTY {[Measures].[Cantidad]} ON COLUMNS,


1 NON EMPTY {([Dimtiempo.Anio].[All Dimtiempo.Anios], [Estu genero].[All
2 Estu generos],
3 [Estu grado].[All Estu grados], [Cole jornada].[All Cole jornadas],
4 [Estu nofuealcolegio].[All Estu nofuealcolegios], [Estu
5 tardeaclase].[All Estu tardeaclases],
6 [Fami tieneinternet].[All Fami tieneinternets],
7 [Cole nombre establecimiento].[LICEO CULTURAL LUIS ENRIQUE OSORIO])}
8 ON ROWS
from [DW]

Como resultado de la consulta sobre el modelo dimensional tenemos la Tabla 30, y


se observa que la información en las 3 partes evaluadas solo discrepa en
aproximaciones de decimales en el promedio, pues los datos están en el mismo
margen.
Medidas
Estu Cole nombre Punt Punt
Anio grado establecimiento Cantidad lenguaje matematicas
LICEO CULTURAL LUIS
9 ENRIQUE OSORIO 87 349,977 360,08
LICEO CULTURAL LUIS
2017 #null ENRIQUE OSORIO 3 355 194
Tabla 30. Resultado consulta MDX para El colegio Luis Enrique Osorio. Elaboración propia.

5.5.4 EJECUCIÓN DE CONSULTAS OLAP-BI (REPORTES, INDICADORES,


AGRUPACIONES)
Tomando como base fundamental los requerimientos planteados y los casos de uso
desarrollados al inicio del proyecto, los reportes elaborados deben cumplir con las
pautas y dar la información que satisfaga dichos requerimientos. De esta manera a
continuación se encuentran algunos de los reportes que dan la información que se
podría encontrar en un reporte entregado por el Icfes.

La cantidad de estudiantes que presentaron las pruebas de grado 5° y 9° para el


año 2017 fue de 1.362.021, de los cuales el 55% de ellos son del grado 5° (Ver
Figura 87).

Figura 87.Reporte 1 - Promedios y cantidad de estudiantes por grado. Elaboración propia.

Los usuarios podrán generar reportes en el menú “visualizer” de la aplicación BI de


SCIRE y todas las variables se pueden tomar de las fuentes de datos establecidas
para el análisis, las fuentes de datos son modelos OLAP que toman el DataMart y
las tablas de agregados. En la Figura 88, Figura 89, Figura 90 y Figura 91 se
muestran otros de los reportes elaborados para aquellos usuarios que solamente
van a visualizar la información, Para ver otros reportes ver el anexo o remitirse a la
aplicación web siguiendo el manual de usuario.

Figura 88.Reporte de desempeño por área, género y periodo de tiempo. elaboración propia.

Figura 89. Reporte de factor asociado estudio del padre. Elaboración propia.
Figura 90. Reporte de desempeño por factor socioeconómico de los trabajos de los padres. Elaboración
propia.

Figura 91. Reporte de desempeño por factor socioeconómico de asistencia del estudiante. Elaboración propia.

5.5.5 AJUSTES NECESARIOS PARA OPTIMIZAR EL PROCESO DE CARGA


En la carga de datos se observaron unos tiempos de carga muy altos ya que el
modelo inicial en Spoon realizaba la carga dato por dato, es decir, que llama al
procedimiento almacenado por cada fila del archivo. Para mejorar la carga de datos,
en la Figura 92 se plantea un modelo de transformación y carga optimizado para la
carga de la dimensión de la sede, pues ya que con el diseño de la Figura 74 se
tuvieron tiempos muy altos. El modelo consiste en generar un archivo plano con los
datos que se van a insertar y en la función de PostgreSQL se hace la validación e
inserción de los datos de este archivo.

Figura 92. Optimización de carga para la dimensión de sedes. Elaboración propia.

El nuevo flujo automatizado para la carga de la dimensión Sede bajo de 12 horas a


45 segundos y es un cambio que reduce bastante el tiempo; esta opción se puede
aplicar en las demás dimensiones.

5.5.6 RESUMEN DEL SPRINT 4


Las validaciones realizadas al modelo dimensional corresponden a la creación de
un esquema dimensional, basado en la arquitectura estrella del DataMart el cual se
puede esquematizar en las dimensiones, medidas y la tabla de hechos. Por otro
lado, se validó la trazabilidad de los datos tomando como muestra un reporte
entregado por el Icfes a uno de los colegios, comparando su información con la
cargada en el Datamart y la que se muestra desde el servidor de Inteligencia de
Negocios – Pentaho Server. Esta comparación certifica que la información que se
va a presentar en los informes es acorde a los reportes del Icfes y así se procede a
la elaboración de reportes con salidas gráficas y tablas basado en los
requerimientos previamente definidos.

5.6 DESARROLLO DEL SPRINT 5

Actividades ▪ Instalación del prototipo


▪ Proposición de políticas de administración.
▪ Evaluación de los resultados.
▪ Determinación de futuras fases.
Entregables Documentación del prototipo
Manuales de instalación
Duración 1 semana

Tabla 31. Resumen sprint 5. Elaboración propia.

5.6.1 INSTALACIÓN DEL PROTOTIPO


Para más claridad en la instalación consultar el manual de instalación de la
aplicación de SCIRE. A continuación, se muestran los plugins necesarios para
poder ejecutar los desarrollos de reportes (Ver Figura 93), su instalación se lleva a
cabo desde el Marketplace de Pentaho server; estos plugins se encuentran
disponibles y gratuitos para poder fortalecer el análisis en el servidor BI.
Figura 93.Plugins necesarios para la elaboración de repostes, Jpivot y visualizaciones. Elaboración propia

Para la personalización del ambiente de Pentaho Server la opción que se utilizó fue
mediante el uso del plugin “tapa” (Ver Figura 94), en el cual se pueden personalizar
logos, colores y títulos del ambiente, también desde una opción más avanzada es
posible descargar el formato web de la plantilla y modificar el código fuente de la
plantilla para personalizar aspectos más profundos de la aplicación [36].

Figura 94. Plugin tapa. Elaboración propia.

5.6.2 POLÍTICAS DE ADMINISTRACIÓN Y CONFIGURACIÓN


En la Tabla 32 se muestran los roles definidos en PostgreSQL para la administración
y el manejo de los datos en la base de datos, donde se definieron 3 roles para cada
uno de los escenarios de transformación, administración y lectura.

Roles Base de Datos PostgreSQL

Rol Permisos Esquemas

Administrador • Puede iniciar sesión Public


• Superusuario control
• Crear roles
• Crea bases de datos
• Actualizar catálogo
• Heredar derechos de los roles principales
• Puede iniciar la replicación y las copias de
seguridad de la transmisión
• Create, temporary, connect, with grant option
• Select, insert,delete, truncate, references,
trigger

PDI • Heredar derechos de los roles principales Public


(Pentaho • Temporary, create, connect control
Data • Select, insert, update, trigger, truncate
Integration)

Reportes • Heredar derechos de los roles principales Public


(Pentaho • Connect
Server) • Select
Tabla 32. Roles PostgreSQL. elaboración propia.

En la Tabla 33 se muestran los roles definidos en Pentaho Server para la


administración y el manejo de los reportes, donde se definieron 4 roles para cada
uno de los escenarios de inteligencia de negocios.

Roles SCIRE Pentaho Server

rol Permisos

Administrator • Administrar seguridad


• Programar contenido
• Leer contenido
• Publicar contenido
• Crear contenido
• Ejecutar
• Administrar fuentes de datos

Business Analyst • Publicar contenido

Power User • Programar contenido


• Leer contenido
• Publicar contenido
• Crear contenido
• Ejecutar

Report Author • Programar contenido


• Publicar contenido
Tabla 33.Roles Pentaho server. elaboración propia.
6. RESULTADOS OBTENIDOS

Tabla de entregables
Para el desarrollo de este proyecto se modelaron e implementaron los siguientes
artefactos de software:

Nombre del entregable Cantidad


Requerimientos funcionales 22
Requerimientos no funcionales 9
Casos de uso 18
Diagrama BPMN 1
Modelo Arquitectura 1
Diagrama dimensional 1
Diccionario de datos 1
Flujo ETL 3
Flujo automatización 1
Scripts PL/PgSQL 6
Scripts Bash 2
Estructura OLAP XML 3
Aplicación BI 1
Manual de Instalación 1
Manual de usuario 1
Videos (Instalación, creación de reportes, 2
creación de JPivot)
Tabla 34. Entregables del proyecto. elaboración propia.

6.1 RESULTADOS DEL PROTOTIPO FUNCIONAL


Siguiendo la metodología de Ralph Kimball para la creación de bodegas de datos y
Scrum como metodología ágil de desarrollo, se construyó el DataMart con los
resultados de las pruebas saber 5° y 9°del año 2017, además una aplicación de
inteligencia de negocios OLAP para la elaboración de reportes y análisis de los
datos. Esta es una herramienta de soporte para las personas que estén interesadas
en el análisis de estos datos a partir de los diferentes factores que pueden afectar
el resultado en las áreas de matemáticas y lenguaje. Queda a disposición del
usuario final poder sacar el máximo provecho a las diferentes funcionalidades del
prototipo.

Como valor agregado a los reportes entregados por el Icfes a los colegio y entidades
territoriales, el prototipo SCIRE contempla variables socioeconómicas en los
análisis, reportes y consultas. Además de la flexibilidad de análisis de todos los
periodos de tiempo, niveles de granularidad y aspectos que se relacionan directa o
indirectamente con el estudiante y que es posible de agrupar para hallar casuísticas
en los resultados de las pruebas.

Los usuarios que accedan a la aplicación SCIRE podrán, dependiendo del rol
asignado en el sistema BI, visualizar todos los reportes de inteligencia de negocios
desarrollados o desde un perfil de analista BI crear reportes, tablas OLAP, gráficas,
análisis y usar las fuentes de datos para otro tipo de análisis sobre las pruebas saber
5° y 9°.

El proyecto deja como resultado la metodología para la extracción, transformación


y carga de los datos de las pruebas saber 5° y 9° 2017-2019, que puede ser usada
para otros periodos de tiempo o también como una guía para otras pruebas
aplicadas por el Icfes, ya que esta metodología de desarrollo contempla como hacer
el uso de Pentaho, PostgreSQL, MongoDB y los datos de los repositorios de Icfes
para construir el DataMart. Para replicar la metodología, se pueden aplicar las
tareas definidas para cada uno de los sprints (ver Figura 17, Figura 18, Figura 19 y
Figura 20), las cuales integran tanto el ciclo de vida de Kimball como las historias
de usuario de Scrum.

El modelo dimensional en PostgreSQL esta soportado por los procedimientos


almacenados y un esquema de control en el que el administrador del sistema podrá
realizar seguimiento a la carga de datos, con los tiempos y cantidad de registros en
cada proceso de la ejecución del flujo ETL en Spoon.

La herramienta SCIRE estará disponible en el enlace15 para que los usuarios


puedan explorar los reportes con análisis de volumen de estudiantes, el desempeño,
factores asociados y otras variables que se encuentran en las fuentes de datos para
el estudio en la aplicación de Pentaho Server. En la Figura 95 se ve la pagina de
inicio de la herramienta SCIRE.

Figura 95. Página de inicio de la herramienta SCIRE. Elaboración propia.

15 Enlace para consultar el acceso a la aplicación e información básica relacionada


https://dparradaza.github.io/SCIRE/
7. CONCLUSIONES

La metodología de Ralph Kimball ayudó a definir el proceso y tareas que se deben


realizar para la construcción de un DataMart basado en las necesidades de análisis
de resultados de las pruebas saber 5° y 9°, también como herramienta que facilita
el proceso de inteligencia de negocios, para analizar los factores asociados y
entender la incidencia de estos en los resultados de los estudiantes.

La metodología Scrum de desarrollo ágil con la que se definieron los sprints, las
historias de usuario y el cronograma del proyecto, al ser iterativo e incremental
permitió ajustar, redefinir y cambiar tareas durante la realización del proyecto con el
fin de mejorar la calidad del prototipo.

Se comprobó la trazabilidad e integridad de los datos que se presentan al usuario


final por medio de pruebas y validación en cada uno de los servidores en los que se
tomó una muestra un reporte entregado por el Icfes y los valores fueron los mismos
en todo el flujo de los datos.

La aplicación SCIRE fue diseñada con el fin de que directivos de instituciones de


básica primaria y secundaria, investigadores y entidades encargadas de definir
políticas educativas en general, puedan realizar análisis sobre los reportes
generados o crear sus propios reportes para encontrar razones de causalidad en
los factores que influyeron en los resultados de las pruebas y así poder crear
estrategias de mejoramiento.

El uso de tecnologías libres como Pentaho, PostgreSQL y MongoDB redujo costos


en licencias de software y se pudo crear un sistema completo e interoperable para
todo el proceso de exploración, transformación, carga y análisis de los datos.

Si bien la suite de herramientas de Pentaho es muy útil para realizar transformación


de datos y configurar el flujo de actividades de los procesos ETL, el desempeño es
bajo y es necesario, por lo tanto, implementar procesos de carga directamente
desde la base de datos que permitan optimizar la ejecución, llevar el control de la
metadata de los procesos y hacer seguimiento de errores.

Una dificultad presentada en el desarrollo de la aplicación SCIRE fue la obtención


de los datos, en primera medida, la creación del usuario para acceder a los datos
en el repositorio del Icfes fue demorado y en el momento de contar con el acceso al
servidor, este presentaba constantes caídas o bloqueos que no permitieron acceder
oportunamente a la información. Por otro lado, los datos de los años posteriores no
han sido publicados en el repositorio del Icfes a la fecha de la terminación del
prototipo SCIRE. Para la validación de la carga de otros periodos de tiempo se
realizó una simulación con la misma base de los datos del 2017, cambiando el
periodo de tiempo al 2019 y modificando los identificadores del estudiante, Sin
embargo, se aclara que esta carga es sólo temporal y que los datos del periodo
2019 deben ser removidos en el momento de socializar el proyecto con usuarios
finales.

Se requiere una aplicación para facilitar el proceso ETL, para poder ejecutar los
procesos y además hacer seguimiento desde una parte grafica que sea amigable
con el usuario final, esta aplicación no se tuvo presente por razones de alcance y
tiempos del proyecto.

No se puede abordar el uso completo de la aplicación SCIRE sin el conocimiento


previo del funcionamiento de un DataMart, pues la herramienta, aunque tiene la
integración para facilitar el análisis de los datos, no remplaza el conocimiento de los
temas, el esfuerzo para construir el DaMart está sobre todo en el proceso ETL y
toma importancia en la construcción de los reportes finales para poder sacar
provecho al máximo la información.

8. TRABAJO FUTURO.

El desarrollo del prototipo de DataMart para realizar inteligencia de negocios sobre


las pruebas saber 5° y 9°, puede abrir paso a nuevas funcionalidades como:

• Implementar al DataMart resultados de las pruebas Saber 5° y 9° de otros


periodos posteriores. Los datos pueden ser incluidos siguiendo la
metodología de extracción, transformación y carga aplicada en este trabajo.

• Desarrollar una aplicación para realizar la gestión de archivos, tablas de


control y administración de usuarios, esto ayudaría a mejorar la interacción
del usuario final con el proceso de extracción, transformación, carga y
administración del sistema de inteligencia de negocios.

• Ampliar el estudio a pruebas Saber 11°, a partir de la metodología


desarrollada en este proyecto sobre un DataMart especializado en otro tipo
de pruebas.

• Implementar la optimización de los procesos de carga de las dimensiones de


colegios, citaciones, estudiantes y tabla de hechos. Siguiendo las
recomendaciones de la sección de ajustes (ver 0), que se aplicaron al
proceso de carga de la dimensión de sede.

• Explorar las ventajas del MDX como un lenguaje de consulta para el análisis
dimensional sobre un DataMart, también de la importancia de procesos de
inteligencia de negocios, en este caso relacionados a los resultados de las
pruebas saber.

• Diseñar más reportes para enriquecer el material de estudio para los


investigadores y personas interesadas en explorar sobre los resultados de
las pruebas saber 5° y 9°.
• Integrar el DataMart con aplicaciones de minería de datos o ciencia de datos
que permitan hacer análisis más profundo con el fin de clasificar, proyectar,
predecir y explorar datos para soportar toma de decisiones que tiendan a
mejorar la calidad de los resultados de las pruebas 5° y 9°.
9. BIBLIOGRAFÍA

[1] R. Kimball, Ralph Kimball The data warehouse lifecycle toolkit, WILEY, 2008.
[2] C. d. Colombia, "Ley 1324," 13 Julio 2009. [Online]. Available:
https://www.mineducacion.gov.co/1621/articles-210697_archivo_pdf_ley_1324.pdf.
[Accessed 16 Noviembre 2019].
[3] ICFES, "Documentación de la prueba saber 3°, 5° y 9°," ICFES, Colombia, 2017.
[4] ICFES, "Guía de interpretación de resultados," [Online]. [Accessed octubre 2019].
[5] "¿Por qué este año no se realizarán las Pruebas Saber en 3, 5 y 9?," Semana,
Lunes, 11 de noviembre de 2019.
[6] A. l. T. a. A. l. Nestor Darío Duque Méndez, «DATA WAREHOUSE (BODEGA DE
DATOS). HERRAMIENTA PARA LA TOMA DE DECISIONES PARTE 1,»
Universidad Nacional, p. 9.
[7] W. H. Inmon, "The Data Warehouse Environment," in Bulding the Data Warehouse
4 Edition, New York, Wiley, 2002, p. 31.
[8] "quoracdn.net," [Online]. Available: https://qph.fs.quoracdn.net/main-qimg-
5f1d329ce904abe8abb9bc3bde1fea8a. [Accessed 1 Novimbre 2019].
[9] Microsoft, «Acceso a datos de modelos multidimensionales (Analysis Services:
datos multidimensionales),» [En línea]. Available: https://docs.microsoft.com/es-
es/analysis-services/multidimensional-models/mdx/multidimensional-model-data-
access-analysis-services-multidimensional-data?view=sql-server-2017. [Último
acceso: Noviembre 2019].
[10] ORACLE, «oracle,» [En línea]. Available:
https://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/317529_e
sa.pdf. [Último acceso: 31 01 2020].
[11] W. Inmon, in Bulding the Data Warehouse, New York, willey, 2002, pp. 41,.
[12] C. Todman, "The conceptual model," in Designing a data warehouse, United States
of America, Hewlett-Packard Professional Books, 2001, pp. 127-129.
[13] A. Silberschatz, Fundamentos de bases de datos, Aravaca (Madrid): McGRAW-
HILL/, 2006.
[14] Telefonica, «Blog acens,» 02 2014. [En línea]. Available:
https://www.acens.com/wp-content/images/2014/02/bbdd-nosql-wp-acens.pdf.
[Último acceso: 12 2019].
[15] ICFES, "Informe Resultados Nacionales Saber 3°,5° Y 9° 2012-2017," Colombia,
2018.
[16] ICFES, «Guía de Interpretación y Uso de Resultados de las pruebas Saber 3°, 5° y
9° (Entidades Educativas),» Colombia, 2016.
[17] ICFES, «Guía de Interpretación y Uso de Resultados de las pruebas Saber 3°, 5° y
9° (Entidades Territoriales),» Colombia, 2016.
[18] P. I. d. E. d. A. (PISA), "Manual de análisis de datos," Madrid, España, 2005.
[19] Hitachi Vantara, "Pentaho Platform," 2019. [Online]. Available:
http://www.pentaho.com/. [Accessed Noviembre 2019].
[20] "Pentaho Tutorial: Learn Data Integration Reports," guru99, [Online]. Available:
https://www.guru99.com/pentaho-tutorial.html. [Accessed Noviembre 2019].
[21] SpagoBI, "Spago," [Online]. Available: https://www.spagobi.org. [Accessed
Noviembre 2019].
[22] G. Lumpkin, «Oracle Database 11g para Data Warehousing e Inteligencia de
Negocios,» Oracle Corporation , U.S.A, 2007.
[23] Microsoft, "Build a Modern Data Warehouse," EEUU, 2017.
[24] C. R.-G. T. J. T. P.-C. P. G. Carolina Maldonado-Carreñoa, «La calidad de la
educación inicial y el desempeño académico en la educación básica primaria en
Bogotá,» ICFES, p. 5, 2019.
[25] M. A. H. Gómez, Enseñanza basada en problemas como instrumento para
fortalecer los conceptos de líneas y puntos notables del triángulo en grado once
mediante las TIC, un enfoque hacia las pruebas saber, Bogotá: BDIGITAL.
[26] H. L. B. G. Á. J. R. V. Ferney J. Rodríguez Dueñas, Predicción del desempeño
académico usando técnicas de aprendizaje de máquinas. ICFES, Bogotá: ICFES,
2018.
[27] J. I. M.-H. Antonio Ramos Murillo, «Improving kinematic lab practices by image
processing,» IEEE, p. 5, 2014.
[28] C. S. manager, SCRUM MANAGER v 2.6, 2016.
[29] E. G. R. Lamus, Diseño e implementación de un prototipo de datamart para hacer
analisis OLAP de los resultados de la prueba saber 11 del ICFES para el periodo
2000-2012, Bogotá, 2013.
[30] What are plausible values and why are, M. von Davier, E. Gonzalez, R. J. Mislevy.
[31] "¿Qué es una base de datos relacional?," AWS, [Online]. Available:
https://aws.amazon.com/es/relational-database/. [Accessed noviembre 2019].
10. ANEXOS

10.1 ANEXO 1: TABLAS DE LA INFORMACIÓN SOCIOECONÓMICA EN LAS


PRUEBAS SABER 3°, 5° Y 9° PARA EL AÑO 2017.

Variable Significado de la variable

FAMI_EDUCACIONPADRE Nivel educativo más alto


alcanzado por el padre

FAMI_EDUCACIONMADRE Nivel educativo más alto


alcanzado por la madre

FAMI_PERSONASHOGAR ¿Cuántas personas conforman el


hogar donde vive actualmente,
incluido usted?
FAMI_CUARTOSHOGAR En total, ¿en cuántos cuartos
duermen las personas de su
hogar?
FAMI_TIENEINTERNET ¿Su hogar cuenta con servicio o
conexión a internet?
FAMI_TIENESERVICIOTV ¿Su hogar cuenta con servicio
cerrado de televisión?
FAMI_TIENECOMPUTADOR ¿Cuáles de los siguientes bienes
posee su hogar?: Computador
FAMI_TIENELAVADORA ¿Cuáles de los siguientes bienes
posee su hogar?: Máquina
lavadora de ropa

FAMI_TIENEHORNOMICROOGA ¿Cuáles de los siguientes bienes


S posee su hogar?: Horno
Microondas u Horno eléctrico o a
gas
FAMI_TIENEAUTOMOVIL ¿Cuáles de los siguientes bienes
posee su hogar?: Automóvil
particular
FAMI_TIENECONSOLAVIDEOJU ¿Cuáles de los siguientes bienes
EGOS posee su hogar?: Consola para
juegos electrónicos (PlayStation,
Xbox, Nintendo, etc.)
FAMI_TRABAJOLABORPADRE Señale aquella labor que sea más
similar al trabajo que realizó su
padre durante la mayor parte del
último año:

FAMI_TRABAJOLABORMADRE Señale aquella labor que sea más


similar al trabajo que realizó su
madre durante la mayor parte del
último año:
ESTU_DEDICACIONINTERNET Usualmente, ¿cuánto tiempo al día
dedica a navegar en internet?
Excluya actividades académicas

COMODESPLAZACOLEGIO Usualmente, ¿cómo te desplazas al


colegio?
ESTU_TIEMPODESPLAZACOLE ¿Cuánto tiempo tardas en ir de tu
GIO casa al colegio?
ESTU_ANOSPREESCOLAR ¿Cuántos años cursaste de
preescolar?

ESTU_ESTECOLEGIO_ANOPAS ¿Estudiaste en este colegio el año


ADO pasado?
ESTU_GRADOCOMENZO_ESTE ¿Desde qué grado estudias en este
COLEGIO colegio?

ESTU_REPROBOGRADO ¿Has repetido algún grado?

ESTU_TARDEACLASE En el último mes, ¿cuántas veces


llegaste tarde a clase?

ESTU_NOFUEALCOLEGIO En el último mes, ¿cuántos días


dejaste de ir al colegio?
ESTU_REMUNERA_OTRASACTI ¿Has recibido algún tipo de pago
VIDADES por realizar otra labor distinta a las
escolares?
ESTU_SERETIROCOLEGIO ¿Alguna vez te retiraste del colegio
o suspendiste tus estudios?
FAMI_NUMLIBROS ¿Cuántos libros físicos o
electrónicos hay en tu hogar
excluyendo periódicos, revistas,
directorios telefónicos y libros del
colegio?

10.2 ANEXO A (DOCUMENTACIÓN)


10.2.1 DOCUMENTACIÓN DE LAS DIMENSIONES
Dimensión Tiempo
Dimensión Frecuencia PK
Dim_tiempo Anual Id_dim_tiempo
Descripción
Tabla de la dimensión de tiempo o periodo del año en que se realizaron las pruebas.
Para la construcción de esta dimensión se toma el año que aparece en los archivos del
Icfes y el mes que se debe investigar para cada prueba realizada, con el fin de poder
generar agrupaciones por periodos de tiempo.
Atributos
Nombre Tipo Descripción
Id_dim_tiempo Integer llave subrogada que identifica el periodo
de tiempo.
Año Date año en que se presentaron las pruebas
(AAAA).
Mes Date Mes del año en que se presentaron las
pruebas (MM).
Tabla 35.Documentación dimensión tiempo. Elaboración propia

10.2.2 DOCUMENTACIÓN DE LOS PROCEDIMIENTOS ALMACENADOS


DE POSTGRESQL.

Nombre CargarColegio
Descripción La función valida si existe el registro en la dimensión de colegio con
la misma llave primaria (Cole_cod_dane_establecimiento) recibida
en el parámetro y si no está lo inserta como un nuevo registro de la
base de datos. También se encarga de almacenar los metadatos
correspondientes al control, seguimiento de carga de los datos
como la cantidad de registros que se insertaron o se repitieron.
Dimensiones dimClegio
afectadas
Tipo de retorno Void
Parámetros que Nombre Tipo de dato
recibe Cole_cod_dane_establecimiento Bigint
cole_nombre_establecimiento Varchar (100)
cole_genero Varchar (3)
cole_naturaleza Varchar (15)
cole_bilingue Varchar (5)
cole_caracter Varchar (30)
cole_inse_establecimiento Bigint
Tabla 36.Documentación procedimiento almacenado CargarColegio. Elaboración propia.

Nombre CargarSede
Descripción La función consulta si existe el registro en la dimensión de sede
con la misma llave primaria (Cole_cod_dane_sede) recibida en el
parámetro y si no está lo inserta como un nuevo registro de la base
de datos. También se encarga de almacenar los metadatos
correspondientes al control, seguimiento de carga de los datos
como la cantidad de registros que se insertaron o se repitieron.
Dimensiones dimSede
afectadas
Tipo de retorno Void
Parámetros que Nombre Tipo de dato
recibe cole_cod_dane_sede Bigint
cole_nombre_sede Varchar (80)
cole_area_ubicacion Varchar (10)
cole_jornada Varchar (16)
cole_cod_mcpio_ubiacion Integer
cole_mcpio_ubicacion Varchar (50)
cole_cod_depto_ubicacion Bigint
cole_depto_ubicacion Varchar (50)
Tabla 37.Documentación procedimiento almacenado CargarSede. Elaboración propia.
Nombre CargarCitacion
Descripción La función consulta si se encuentra el registro en la dimensión de
citación con la misma llave primaria (id_dim_citacion) recibida en el
parámetro y si no está lo inserta como un nuevo registro de la base
de datos. Consulta el máximo del id para asignar el siguiente valor
al registro que se va a insertar. También se encarga de almacenar
los metadatos correspondientes al control, seguimiento de carga de
los datos como la cantidad de registros que se insertaron o se
repitieron.
Dimensiones dimCitacionExamen
afectadas
Tipo de retorno Void
Parámetros que Nombre Tipo de dato
recibe id_dim_citacion Bigint
cole_nombre_sede Varchar (80)
estu_cod_mcpio_presentacion Varchar (10)
estu_cod_depto_preentacion Varchar (16)
Tabla 38.Documentación procedimiento almacenado CargarCitacion. Elaboración propia.

Nombre CargarTiempo
Descripción La función consulta si se encuentra el registro en la dimensión de
tiempo con la misma llave primaria (id_dim_tiempo) recibida en el
parámetro y si no está lo inserta como un nuevo registro de la base
de datos. Consulta el máximo del id para asignar el siguiente valor
al registro que se va a insertar. También se encarga de almacenar
los metadatos correspondientes al control, seguimiento de carga de
los datos como la cantidad de registros que se insertaron o se
repitieron.
Dimensiones dimTiempo
afectadas
Tipo de retorno Void
Parámetros que Nombre Tipo de dato
recibe id_dim_tiempo Bigint
Año Date
Mes Date
Tabla 39. Documentación procedimiento almacenado CargarTiempo. Elaboración propia.

10.2.3 REPORTES PENTAHO SERVER


Figura 96.Reporte de volumen de estudiantes para el año 2017 y 2019.

Figura 97. Reporte de volumen de estudiantes por entidad territorial. Elaboración propia.
Figura 98. Reporte de desempeño por área, género y periodo de tiempo. Elaboración propia.

Figura 99. Reporte de desempeño del año 2017 y 2019 por género. Elaboración propia.
Figura 100. Reporte de desempeño según herramientas tecnológicas. Elaboración propia.

Figura 101. reporte de desempeño por factor de estudio de la madre. Elaboración propia.
Figura 102. Reporte de volumen por factores de colegio. Elaboración propia.

Figura 103. Reporte de volumen por factores de colegio para el año 2017. Elaboración propia.

10.3 ANEXO B (CÓDIGO)


10.3.1 XML DEL CUBO OLAP (PARA EL ANÁLISIS DE COLEGIOS)

1 <Schema name="DW">
2 <Dimension name="Dimtiempo" type="TimeDimension">
3 <Hierarchy name="Anio" hasAll="true" primaryKey="id_dim_tiempo">
4 <Table name="dimtiempo" schema="public"/>
5 <Level name="Anio" uniqueMembers="false" column="anio"
6 levelType="TimeYears" type="Numeric">
7 </Level>
8 </Hierarchy>
9 <Hierarchy name="Mes" hasAll="true" primaryKey="id_dim_tiempo">
10 <Table name="dimtiempo" schema="public"/>
11 <Level name="Mes" uniqueMembers="false" column="mes"
12 levelType="TimeMonths" type="Numeric">
13 </Level>
14 </Hierarchy>
15 </Dimension>
16 <Dimension name="Estu genero">
17 <Hierarchy hasAll="true" primaryKey="id_estu_consecutivo">
18 <Table name="dimestudiante" schema="public"/>
19 <Level name="Estu genero" uniqueMembers="false"
20 column="estu_genero" type="String">
21 </Level>
22 </Hierarchy>
23 </Dimension>
24 <Dimension name="Estu grado">
25 <Hierarchy hasAll="true" primaryKey="id_estu_consecutivo">
26 <Table name="dimestudiante" schema="public"/>
27 <Level name="Estu grado" uniqueMembers="false"
28 column="estu_grado" type="Numeric">
29 </Level>
30 </Hierarchy>
31 </Dimension>
32 <Dimension name="Cole jornada">
33 <Hierarchy hasAll="true" primaryKey="id_dim_sede">
34 <Table name="dimsede" schema="public"/>
35 <Level name="Cole jornada" uniqueMembers="false"
36 column="cole_jornada" type="String">
37 </Level>
38 </Hierarchy>
39 </Dimension>
40 <Dimension name="Estu nofuealcolegio">
41 <Hierarchy hasAll="true" primaryKey="id_soc_estudiante">
42 <Table name="dimsocieconomicoestudiante" schema="public"/>
43 <Level name="Estu nofuealcolegio" uniqueMembers="false"
44 column="estu_nofuealcolegio" type="String">
45 </Level>
46 </Hierarchy>
47 </Dimension>
48 <Dimension name="Estu tardeaclase">
49 <Hierarchy hasAll="true" primaryKey="id_soc_estudiante">
50 <Table name="dimsocieconomicoestudiante" schema="public"/>
51 <Level name="Estu tardeaclase" uniqueMembers="false"
52 column="estu_tardeaclase" type="String">
53 </Level>
54 </Hierarchy>
55 </Dimension>
56 <Dimension name="Fami tieneinternet">
57 <Hierarchy hasAll="true" primaryKey="fami_numlibros">
58 <Table name="dimsocieconomicofamilia" schema="public"/>
59 <Level name="Fami tieneinternet" uniqueMembers="false"
60 column="fami_tieneinternet" type="String">
61 </Level>
62 </Hierarchy>
63 </Dimension>
64 <Cube name="DW">
65 <Table name="resultados_pruebas_saber" schema="public"/>
66 <DimensionUsage name="Dimtiempo" source="Dimtiempo"
67 foreignKey="id_dim_tiempo"/>
68 <DimensionUsage name="Estu genero" source="Estu genero"
69 foreignKey="id_estu_consecutivo"/>
<DimensionUsage name="Estu grado" source="Estu grado"
foreignKey="id_estu_consecutivo"/>
<DimensionUsage name="Cole jornada" source="Cole jornada"
foreignKey="id_dim_sede"/>
<DimensionUsage name="Estu nofuealcolegio" source="Estu
nofuealcolegio" foreignKey="id_soc_estudiante"/>
<DimensionUsage name="Estu tardeaclase" source="Estu tardeaclase"
foreignKey="id_soc_estudiante"/>
<DimensionUsage name="Fami tieneinternet" source="Fami
tieneinternet" foreignKey="id_soc_familia"/>
<Measure name="Cantidad" column="cantidaad" aggregator="sum"/>
<Measure name="Punt lenguaje" column="punt_lenguaje"
aggregator="avg"/>
<Measure name="Punt matematicas" column="punt_matematicas"
aggregator="avg"/>
</Cube>
</Schema>

10.3.2 PROCEDIMIENTOS ALMACENADOS

Creación de colegio

CREATE OR REPLACE FUNCTION crearcolegio (


codigo bigint,
nombre varchar(70),
genero varchar(15) ,
naturaleza varchar(15) ,
bilingue varchar(5) ,
caracter varchar(30) ,
inse_colegio bigint
)
RETURNS void AS $$
begin
IF EXISTS (Select cole_cod_dane_establecimiento FROM dimcolegio WHERE
cole_cod_dane_establecimiento= codigo)THEN
--VALIDAR SI EXISTE EL REGISTRO DE LA EXEPCION DE DATO REPETIDO
IF EXISTS (SELECT e.id_excepcion FROM control.exepcion e WHERE
e.id_excepcion = 2) THEN
UPDATE control.exepcion
SET cantidad_registros = (select e.cantidad_registros+1
from control.exepcion e where e.id_excepcion = 2),
hora_fin = clock_timestamp()
WHERE control.exepcion.id_excepcion=2;
ELSE
INSERT INTO
control.exepcion(id_excepcion,tipo,cantidad_registros,columna,descripcion
,
hora_inicio,hora_fin, id_proceso)
VALUES(2,'REPETIDOS',1,'COLEGIO','REGISTROS
REPETIDOS',clock_timestamp(),clock_timestamp(),
(select max(id_proceso) from control.proceso
));
END IF;

ELSE
--CREAR NUEVO COLEGIO
INSERT INTO dimcolegio
(cole_cod_dane_establecimiento, cole_nombre_establecimiento,
cole_genero,cole_naturaleza,cole_bilingue,
cole_caracter,cole_inse_establecimiento)
VALUES
(codigo,nombre,genero,naturaleza,bilingue,caracter,inse_colegio);

--VALIDAR SI EXISTE EL REGISTRO DE LA EXEPCION DE NUEVO DATO


IF EXISTS (SELECT e.id_excepcion FROM control.exepcion e WHERE
e.id_excepcion = 1) THEN
UPDATE control.exepcion
SET cantidad_registros = (select e.cantidad_registros+1
from control.exepcion e where e.id_excepcion = 1),
hora_fin = clock_timestamp()
WHERE control.exepcion.id_excepcion=1;
ELSE
INSERT INTO
control.exepcion(id_excepcion,tipo,cantidad_registros,columna,descripcion
,
hora_inicio,hora_fin, id_proceso)
VALUES(1,'INSERTADOS',1,'COLEGIO','CANTIDAD DE REGISTROS
INSERTADOS',clock_timestamp(),
clock_timestamp(),(select max(id_proceso) from
control.proceso));
END IF;

END IF;
END;
$$
LANGUAGE 'plpgsql';

Creación de estudiante y hecho

CREATE OR REPLACE FUNCTION crearhechos (


--estudiante 10
idestudiante varchar(30),doc varchar(15) ,nac varchar(15),gen
varchar(5),edad varchar(30),grado bigint,
fecnac date,incripcion varchar (20),recide varchar (30),
--SE familiares
educacionpadre varchar (29),educacionmadre varchar
(29),personashogar varchar (4),cuartoshogar varchar (4),
tieneinternet varchar (3),tieneserviciotv varchar
(3),tienecomputador varchar (3), tienelavadora varchar (3),
tienehornomicroogas varchar (3),tieneautomovil varchar (3),
tieneconsolavideojuegos varchar (3),
trabajopadre varchar (150), trabajomadre varchar (150),
numlibros varchar (60),
--SE estudiante 11
dedicacioninternet varchar (25),comodesplza
varchar(25),tiempodesplaza varchar(36),anospreescolar varchar(16),
anopasado varchar(4),gradocomenzo varchar(9),reprobogrado
varchar(35),tardeaclase varchar(29),
nofuealcolegio varchar(22), remunera varchar(3),seretirocolegio
varchar(23),
--llaves foraneas 3
colegio bigint,sede bigint,citacion bigint,
--medidas
lenguaje bigint, matematicas bigint
)
RETURNS void AS $$
begin
IF EXISTS (Select idestudiante FROM dimestudiante WHERE
id_estu_consecutivo= idestudiante)THEN
--VALIDAR SI EXISTE EL REGISTRO DE LA EXEPCION DE DATO REPETIDO
IF EXISTS (SELECT e.id_excepcion FROM control.exepcion e WHERE
e.id_excepcion = 7) THEN
UPDATE control.exepcion
SET cantidad_registros = (select e.cantidad_registros+1
from control.exepcion e where e.id_excepcion = 7),
hora_fin = clock_timestamp()
WHERE control.exepcion.id_excepcion=7;
ELSE
INSERT INTO
control.exepcion(id_excepcion,tipo,cantidad_registros,tabla,descripcion,
hora_inicio,hora_fin, id_proceso)
VALUES(7,'REPETIDOS',1,'HECHOS','REGISTROS
REPETIDOS',clock_timestamp(),clock_timestamp(),
(select max(id_proceso) from control.proceso
));
END IF;

ELSE
--CREAR NUEVO estudiante
INSERT INTO dimestudiante
(id_estu_consecutivo,estu_tipodocumento,estu_nacionalidad,estu_gen
ero,estu_edad,estu_grado,estu_fechanacimiento,
estu_inscripcion,estu_pais_recide,estu_inse_individual)
VALUES
(idestudiante,doc,nac,gen,edad,grado,fecnac,incripcion,recide,null);

--CREAR NUEVOS socioeconomiacas familiares


INSERT INTO public.dimsocieconomicofamilia
(id_soc_familia,fami_educacionpadre,fami_educacionmadre,fami_perso
nashogar,fami_cuartoshogar,fami_tieneinternet,
fami_tieneserviciotv,fami_tienecomputador,fami_tienelavadora,fami_
tienehornomicroogas,fami_tieneautomovil,

fami_tieneconsolavideojuegos,fami_trabajopadre,fami_trabajomadre,fami_num
libros)
VALUES(COALESCE((select max(id_soc_familia)+1 from
dimsocieconomicofamilia
),1),educacionpadre,educacionmadre,personashogar,cuartoshogar,

tieneinternet,tieneserviciotv,tienecomputador,tienelavadora,tienehornomic
roogas,tieneautomovil,
tieneconsolavideojuegos,trabajopadre,trabajomadre,numlibros);

--CREAR NUEVOS socioeconomiacas estudiante


INSERT INTO public.dimsocieconomicoestudiante
(id_soc_estudiante,estu_dedicacioninternet,estu_comodesplzacolegio
,estu_tiempodesplazacolegio,estu_anospreescolar,
estu_estecolegio_anopasado,estu_gradocomenzo_estecolegio,estu_repr
obogrado,estu_tardeaclase,estu_nofuealcolegio,
estu_remunera_otrasactividades,estu_seretirocolegio)
VALUES(COALESCE((select max(id_soc_estudiante)+1 from
dimsocieconomicoestudiante ),1),dedicacioninternet,comodesplza,

tiempodesplaza,anospreescolar,anopasado,gradocomenzo,reprobogrado,tardeac
lase,nofuealcolegio,remunera,seretirocolegio);

--CREAR HECHO
INSERT INTO public.resultados_pruebas_saber
(id_pruebasaber,id_estu_consecutivo,id_dim_sede,id_dim_tiempo,cole
_cod_dane_establecimiento,id_soc_familia,
id_soc_estudiante,estu_cod_mcpio_presentacion,punt_lenguaje,punt_m
atematicas,cantidaad)

VALUES(COALESCE((select max(id_pruebasaber)+1 from


resultados_pruebas_saber ),1),idestudiante,
(select max(id_dim_sede) from public.dimsede
where cole_cod_dane_sede=sede and
cole_jornada=COALESCE(jornada,' ')
and cole_cod_mcpio_ubiacion=COALESCE(mcpio_sede,'
') )
,1,colegio,
(select max(id_soc_familia) from
dimsocieconomicofamilia),(select max(id_soc_estudiante) from
dimsocieconomicoestudiante),
citacion,lenguaje,matematicas,1);

--VALIDAR SI EXISTE EL REGISTRO DE LA EXEPCION DE NUEVO DATO


IF EXISTS (SELECT e.id_excepcion FROM control.exepcion e WHERE
e.id_excepcion = 8) THEN
UPDATE control.exepcion
SET cantidad_registros = (select e.cantidad_registros+1
from control.exepcion e where e.id_excepcion = 8),
hora_fin = clock_timestamp()
WHERE control.exepcion.id_excepcion=8;
ELSE
INSERT INTO
control.exepcion(id_excepcion,tipo,cantidad_registros,tabla,descripcion,
hora_inicio,hora_fin, id_proceso)
VALUES(8,'INSERTADOS',1,'HECHOS','CANTIDAD DE REGISTROS
INSERTADOS',clock_timestamp(),
clock_timestamp(),(select max(id_proceso) from
control.proceso));
END IF;

END IF;
END;
$$
LANGUAGE 'plpgsql';

También podría gustarte