CONSTRUCCIÓN DE UN PROTOTIPO DE DATAMART PARA …

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.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.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.

ftp://ftp.icfes.gov.co/

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

ftp://ftp.e/

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





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.


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





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.




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





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.



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




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.




Caso de uso: Consultar resultado promedio por periodo de tiempo, área y género

ID: CU03-03

Actores: Usuario DW





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





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.


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


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).



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.




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

ID: CU03-06

Actores: Usuario DW





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.




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





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.




Caso de uso: Consultar resultado promedio por factores del colegio por periodo de tiempo.

ID: CU04-02

Actores: Usuario DW





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.




Caso de uso: Consultar resultado promedio por otros datos socioeconómicos por periodo de tiempo.

ID: CU04-03

Actores: Usuario DW





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.



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





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.


6. Se despliega un reporte del promedio de los resultados de las pruebas, por factores de estudiante por periodo de tiempo.




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

ID: CU04-05

Actores: Usuario DW




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.


6. Se despliega un reporte del promedio de los resultados, por variables socioeconómicas del hogar por periodo de tiempo.




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

ID: CU04-06

Actores: Usuario DW




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.


6. Se despliega un reporte del promedio de los resultados de las pruebas, por factores de hogar, estudiante y tiempo.




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.%

http://localhost.:8080/pentaho/

http://sourceforge.net/projects/pentaho/

ftp://ftp.icfes.gov.co/2. Saber 3,5 y 9/3. Resultados Saber 359/2017/6. Estudiante/

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/.

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.


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


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


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


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


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.


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.


dimEstudiante, resultados_pruebas_saber



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.


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.


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


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


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.


dimClegio



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.


dimSede



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.


dimCitacionExamen



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.


dimTiempo



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








ELSE

INSERT INTO

control.exepcion(id_excepcion,tipo,cantidad_registros,columna,descripcion

,


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








ELSE

INSERT INTO

control.exepcion(id_excepcion,tipo,cantidad_registros,tabla,descripcion,


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








ELSE

INSERT INTO

control.exepcion(id_excepcion,tipo,cantidad_registros,tabla,descripcion,


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';

CONSTRUCCIÓN DE UN PROTOTIPO DE DATAMART PARA …

Documents

Transcript of CONSTRUCCIÓN DE UN PROTOTIPO DE DATAMART PARA …