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.
1 Es necesario generar una cuenta para acceder al siguiente enlace (ftp://ftp.icfes.gov.co/). 2 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.
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.
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.
Base de datos SQL
Base de datos no
SQL
Hojas de Cálculo
Bases de datos operativas (día a día)
OLTP
D1
D4 D3
D2
H
Minería de datos, inteligencia de
negocios, reportes, tableros
de control, reportes.
ETL
Bodega de Datos
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.
Figura 4. Cubo OLAP, adaptado de la definición de Kimball.
Producto
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:
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
Programa/ Planificación de proyectos
Instalación y selección de
producto.
Diseño de arquitectura
técnica
Modelado dimensional
Diseño de aplicación BI
Diseño Físico
Diseño y despliegue
ETL
Despliegue
Definición de
requerimientos de negocio
Crecimiento
Mantenimiento
Programa / planificación de proyectos
Desarrollo de
aplicación BI
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]:
3 SQL 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.
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.
Procesos
Escuela
Insumos Productos
Contexto
Á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°-9°
3°-5°- 9°
3°-5°-9°
3°-5°-9°
3°-5°-9°
-
Matemáticas 5° - 9° 3°-5°-9° 3°-5°-9°
3°-5°- 9°
3°-5°-9°
3°-5°-9°
3°-5°-9°
-
Competencias ciudadanas
- 5° - 9° 5° - 9° - 5° - 9° - - -
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.
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.
0
100000
200000
300000
400000
500000
600000
700000
800000
900000
1000000
2009 2012 2013 2014 2015 2016 2017
Número de estudiantes evaluados
3° 5° 9°
2.7.6 TIPOS DE RESULTADOS Reporte para colegios:
Figura 10.Resultados para colegios [16].
Reporte para entidades territoriales:
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].
•Conocer cual es el estado del estudiante para resolver preguntas y problemas.
•Saber cual es el nivel de los estudiantes.
•Realizar comparaciones entre grupos.
Niveles de desempeño
•Determinar los puntajes más representativos dentro de las instituciones.
•Establecer los puntajes promedio de las instituciones.Puntaje promedio
•Se asocia a la dispersión de los resultados.
•Permite realizar comparaciones con otros grupos de referencia.Margen de estimación
•Sirven para ver la homogeneidad de los resultados.
•Comparar con la desviación estandar de otros grupos referentes.Desviación estandar
•Se compra componentes con establecimientos que obtuvieron un resultado parecido.
Fortalezas y debilidades en las competencias y
componentes
•Conocer cual es el estado del estudiante para resolver preguntas y problemas.
•Saber cual es el nivel de los estudiantes.
•Realizar comparaciones entre grupos.
Niveles de desempeño
•Determinar los puntajes más representativos dentro de las entidades territoriales.
•Establecer los puntajes promedio de las entidades territoriales.Puntaje promedio
•Se asocia a la dispersión de los resultados.
•Permite realizar comparaciones de una entidad territorial con otros grupos de referencia.
Margen de estimación
•Sirven para ver la homogeneidad de los resultados.
•Comparar con la desviación estandar de entidades territorialesotros grupos referentes.
Desviación estandar
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.
4 SMP (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 datos:
24 días mié 19/02/20 lun 23/03/20
Sprint 2 - Fase de diseño del modelo dimensional y ETL
27 días mar 24/03/20
mié 29/04/20
Sprint 3 - Fase de Implementación del modelo dimensional y del proceso ETL
23 días jue 30/04/20 lun 1/06/20
Sprint 4 Fase de Validación 27 días mar 2/06/20 mié 8/07/20
Sprint 5 - Fase de Instalación y evaluación 29 días jue 9/07/20 mar 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.
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.
Programa / Planificación de proyectos
Instalación y selección de
producto.
Diseño de arquitectura
técnica
Modelado dimensional
Diseño de aplicación BI
Diseño Físico
Diseño y despliegue
ETL
Despliegue
Definición de requerimientos
de negocio
Crecimiento
Mantenimiento
Programa / Gestión de proyectos
Desarrollo de
aplicación BI
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
9 El 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.
11 TSV que significa “Valores Separados por Tabulaciones” es un archivo muy parecido a los CSV, 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 medio de un colegio (estudiante) o fue individual.
Estudiante
ESTU_PAIS_RESIDE Código del país donde reside actualmente el Estudiante.
Texto
Información socioeconómica
FAMI_EDUCACIONPADRE Nivel educativo más alto alcanzado por el padre.
Primaria, Bachillerato, Técnico o Tecnólogo Universitario - Pregrado Universitario – Posgrado, NA.
FAMI_EDUCACIONMADRE Nivel educativo más alto alcanzado por la madre.
Primaria, Bachillerato, Técnico o Tecnólogo Universitario - Pregrado Universitario – Posgrado, NA.
FAMI_PERSONASHOGAR ¿Cuántas personas conforman el hogar donde vive actualmente, incluido usted?
2, 3, 4, 5, 6, NA.
FAMI_CUARTOSHOGAR En total, ¿en cuántos cuartos duermen las personas de su hogar?
1, 2, 3, 4, 5, 6, NA.
FAMI_TIENEINTERNET ¿Su hogar cuenta con servicio o conexión a internet?
No, Sí, NA.
FAMI_TIENESERVICIOTV ¿Su hogar cuenta con servicio cerrado de televisión?
No, Sí, NA.
FAMI_TIENECOMPUTADOR ¿Cuáles de los siguientes bienes posee su hogar?: Computador
No, Sí, NA.
FAMI_TIENELAVADORA ¿Cuáles de los siguientes bienes posee su hogar?: Máquina lavadora de ropa
No, Sí, NA.
FAMI_TIENEHORNOMICROOGAS ¿Cuáles de los siguientes bienes posee su hogar?: Horno Microondas u Horno eléctrico o a gas
No, Sí, NA.
FAMI_TIENEAUTOMOVIL ¿Cuáles de los siguientes bienes posee su hogar?: Automóvil particular
No, Sí, NA.
FAMI_TIENECONSOLAVIDEOJUEGOS ¿Cuáles de los siguientes bienes posee su hogar?: Consola para juegos electrónicos (PlayStation, Xbox, Nintendo, etc.)
No, Sí, NA.
FAMI_TRABAJOLABORPADRE Señale aquella labor que sea más Trabaja en el hogar; no trabaja o
similar al trabajo que realizó su padre durante la mayor parte del último año:
estudia. 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 similar al trabajo que realizó su madre durante la mayor parte del último año:
Trabaja en el hogar; no trabaja o estudia 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 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.
Otras socioeconómicas
ESTU_COMODESPLAZACOLEGIO 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 ¿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 ¿Cuántos años cursaste de preescolar?
Ninguno, Un año, Dos años, Tres años, No me acuerdo, NA.
ESTU_ESTECOLEGIO_ANOPASADO ¿Estudiaste en este colegio el año pasado?
No, Sí, NA.
ESTU_GRADOCOMENZO_ESTECOLEGIO ¿Desde qué grado estudias en este colegio?
Primero, Segundo, Tercero, 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 llegaste tarde a clase?
Nunca, Una o dos veces por semana, Una o dos veces por mes, Todos los días, NA.
ESTU_NOFUEALCOLEGIO 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 ¿Has recibido algún tipo de pago por realizar otra labor distinta a las escolares?
No, Sí, NA.
ESTU_SERETIROCOLEGIO ¿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
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?
0 a 10 libros, 11 a 25 libros, 26 a 100 libros, Más de 100 libros, NA.
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 establecimiento.
FEMENINO, MASCULINO, MIXTO.
COLE_NATURALEZA Indica la naturaleza del establecimiento
NO OFICIAL, OFICIAL.
COLE_BILINGUE Indica si el establecimiento es bilingüe o no
N, S.
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 está ubicada la sede.
Numérica
COLE_MCPIO_UBICACION Nombre del municipio donde está ubicada la sede.
Texto
COLE_COD_DEPTO_UBICACION Código Dane del departamento de la sede.
Numérica
COLE_DEPTO_UBICACION Nombre del departamento donde está ubicada la sede.
Texto
Datos citación del examen
ESTU_COD_MCPIO_PRESENTACION Código Dane del municipio presentación del examen.
Numérica.
ESTU_MCPIO_PRESENTACION Municipio de presentación del examen
Texto
ESTU_COD_DEPTO_PRESENTACION Código Dane del departamento del municipio de presentación del examen
Numérica
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 matemáticas.
Rango [100, 500]
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 estudiante.
Numérica – Rango [1,100]
ESTU_NSE_ESTABLECIMIENTO Nivel Socioeconómico del Establecimiento.
NSE1, NSE2, NSE3, NSE4.
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 negocio/ Evento
Año Sede Colegio Factores asociados
Lugar de Citación
Volumen de estudiantes
X X X X X
Promedio de desempeño
X
Nivele de desempeño
Incidencia Socioeconómica
X X X
Instituciones y entidades territoriales
X X X
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:
Figura 57. Modelo dimensional de alto nivel 1. Elaboración propia.
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
Estudiante
Colegio
Sede Factores asociados
Familiares
Tiempo Citación Factores asociados Estudiante
Resultado prueba saber
Estudiante
Colegio
Sede
Tiempo Citación
Área
Factores asociados Familiares
Factores asociados Estudiante
Resultado prueba saber
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
14 JSP 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 afectadas
dimSocieconomicoFamilia, dim_SocieconomicoEstudiante
Tipo de retorno Void
Parámetros que recibe
Nombre Tipo de dato
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 afectadas
dimEstudiante, resultados_pruebas_saber
Tipo de retorno Void
Parámetros que recibe
Nombre Tipo de dato
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.
1
2
3
4
5
6
#!/bin/bash
# Ejecución de proceso de carga de datos
# Directorio de instalación de Pentaho Data Integration
cd /home/diego/data-integration/
#Ejecución de carga con kitchen
./kitchen.sh -file
/home/diego/StageArea/scripts/CargaTareaAutomatizada.ktr
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:
1
2
3
4
5
6
7
8
#!/bin/bash
# Ejecución de proceso de carga de datos
# Directorio de instalación de Pentaho Data Integration
cd /home/diego/data-integration/
#Ejecución de la transformación de carga de dimensiones
./pan.sh -file /home/diego/StageArea/scripts/CargaDimensiones.ktr
#Ejecución de la transformación de carga de hechos
./pan.sh -file /home/diego/StageArea/scripts/procesocreaciónHechos.ktr
mv
/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.
1
2
3
4
5
select count(*)
from public.resultados_pruebas_saber h
inner join public.dimcolegio col on
col.cole_cod_dane_establecimiento=h.cole_cod_dane_establecimiento
inner join public.dimestudiante e on
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
2
3
4
5
6
7
8
select avg(punt_lenguaje)
from public.resultados_pruebas_saber h
inner join public.dimcolegio col
on col.cole_cod_dane_establecimiento=h.cole_cod_dane_establecimiento
inner join public.dimestudiante e
on 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)
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.
1
2
3
4
5
6
7
8
select NON EMPTY {[Measures].[Cantidad]} ON COLUMNS,
NON EMPTY {([Dimtiempo.Anio].[All Dimtiempo.Anios], [Estu genero].[All
Estu generos],
[Estu grado].[All Estu grados], [Cole jornada].[All Cole jornadas],
[Estu nofuealcolegio].[All Estu nofuealcolegios], [Estu
tardeaclase].[All Estu tardeaclases],
[Fami tieneinternet].[All Fami tieneinternets],
[Cole nombre establecimiento].[LICEO CULTURAL LUIS ENRIQUE OSORIO])}
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
Anio Estu
grado Cole nombre
establecimiento Cantidad Punt
lenguaje Punt
matematicas
2017
9 LICEO CULTURAL LUIS ENRIQUE OSORIO 87 349,977 360,08
#null LICEO CULTURAL LUIS 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 • Superusuario • Crear roles • Crea bases de datos
Public control
• 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 (Pentaho Data Integration)
• Heredar derechos de los roles principales • Temporary, create, connect • Select, insert, update, trigger, truncate
Public control
Reportes (Pentaho Server)
• Heredar derechos de los roles principales • Connect • Select
Public
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, creación de JPivot)
2
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_esa.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_TIENEHORNOMICROOGAS
¿Cuáles de los siguientes bienes 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_TIENECONSOLAVIDEOJUEGOS
¿Cuáles de los siguientes bienes 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_TIEMPODESPLAZACOLEGIO
¿Cuánto tiempo tardas en ir de tu casa al colegio?
ESTU_ANOSPREESCOLAR ¿Cuántos años cursaste de preescolar?
ESTU_ESTECOLEGIO_ANOPASADO
¿Estudiaste en este colegio el año pasado?
ESTU_GRADOCOMENZO_ESTECOLEGIO
¿Desde qué grado estudias en este 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_OTRASACTIVIDADES
¿Has recibido algún tipo de pago 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 afectadas
dimClegio
Tipo de retorno Void
Parámetros que recibe
Nombre Tipo de dato
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 afectadas
dimSede
Tipo de retorno Void
Parámetros que recibe
Nombre Tipo de dato
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 afectadas
dimCitacionExamen
Tipo de retorno Void
Parámetros que recibe
Nombre Tipo de dato
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 afectadas
dimTiempo
Tipo de retorno Void
Parámetros que recibe
Nombre Tipo de dato
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
2
3
<Schema name="DW">
<Dimension name="Dimtiempo" type="TimeDimension">
<Hierarchy name="Anio" hasAll="true" primaryKey="id_dim_tiempo">
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
<Table name="dimtiempo" schema="public"/>
<Level name="Anio" uniqueMembers="false" column="anio"
levelType="TimeYears" type="Numeric">
</Level>
</Hierarchy>
<Hierarchy name="Mes" hasAll="true" primaryKey="id_dim_tiempo">
<Table name="dimtiempo" schema="public"/>
<Level name="Mes" uniqueMembers="false" column="mes"
levelType="TimeMonths" type="Numeric">
</Level>
</Hierarchy>
</Dimension>
<Dimension name="Estu genero">
<Hierarchy hasAll="true" primaryKey="id_estu_consecutivo">
<Table name="dimestudiante" schema="public"/>
<Level name="Estu genero" uniqueMembers="false"
column="estu_genero" type="String">
</Level>
</Hierarchy>
</Dimension>
<Dimension name="Estu grado">
<Hierarchy hasAll="true" primaryKey="id_estu_consecutivo">
<Table name="dimestudiante" schema="public"/>
<Level name="Estu grado" uniqueMembers="false"
column="estu_grado" type="Numeric">
</Level>
</Hierarchy>
</Dimension>
<Dimension name="Cole jornada">
<Hierarchy hasAll="true" primaryKey="id_dim_sede">
<Table name="dimsede" schema="public"/>
<Level name="Cole jornada" uniqueMembers="false"
column="cole_jornada" type="String">
</Level>
</Hierarchy>
</Dimension>
<Dimension name="Estu nofuealcolegio">
<Hierarchy hasAll="true" primaryKey="id_soc_estudiante">
<Table name="dimsocieconomicoestudiante" schema="public"/>
<Level name="Estu nofuealcolegio" uniqueMembers="false"
column="estu_nofuealcolegio" type="String">
</Level>
</Hierarchy>
</Dimension>
<Dimension name="Estu tardeaclase">
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
<Hierarchy hasAll="true" primaryKey="id_soc_estudiante">
<Table name="dimsocieconomicoestudiante" schema="public"/>
<Level name="Estu tardeaclase" uniqueMembers="false"
column="estu_tardeaclase" type="String">
</Level>
</Hierarchy>
</Dimension>
<Dimension name="Fami tieneinternet">
<Hierarchy hasAll="true" primaryKey="fami_numlibros">
<Table name="dimsocieconomicofamilia" schema="public"/>
<Level name="Fami tieneinternet" uniqueMembers="false"
column="fami_tieneinternet" type="String">
</Level>
</Hierarchy>
</Dimension>
<Cube name="DW">
<Table name="resultados_pruebas_saber" schema="public"/>
<DimensionUsage name="Dimtiempo" source="Dimtiempo"
foreignKey="id_dim_tiempo"/>
<DimensionUsage name="Estu genero" source="Estu genero"
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';