LEONARDO CRUZ GARCIA - Francisco José de Caldas District...
87
ANÁLISIS, DISEÑO Y DESARROLLO DE UN ALMACÉN DE DATOS PARA LA EVALUACIÓN Y ANÁLISIS DE LA PLANTA PROFESORAL BAJO EL MODELO DE ACREDITACIÓN INSTITUCIONAL EN LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS. LEONARDO CRUZ GARCIA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D.C, 2018
Transcript of LEONARDO CRUZ GARCIA - Francisco José de Caldas District...
ANÁLISIS, DISEÑO Y DESARROLLO DE UN ALMACÉN DE DATOS PARA LA
EVALUACIÓN Y ANÁLISIS DE LA PLANTA PROFESORAL BAJO EL MODELO DE
ACREDITACIÓN INSTITUCIONAL EN LA UNIVERSIDAD DISTRITAL FRANCISCO
JOSÉ DE CALDAS.
LEONARDO CRUZ GARCIA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C, 2018
ANÁLISIS, DISEÑO Y DESARROLLO DE UN ALMACÉN DE DATOS PARA LA
EVALUACIÓN Y ANÁLISIS DE LA PLANTA PROFESORAL BAJO EL MODELO DE
ACREDITACIÓN INSTITUCIONAL EN LA UNIVERSIDAD DISTRITAL FRANCISCO
JOSÉ DE CALDAS.
LEONARDO CRUZ GARCIA
PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE
SISTEMAS
DIRECTOR:
Ing. Alejandro Paolo Daza Corredor
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C, 2018
Nota de aceptación:
___________________________
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
________________________________
Firma del Director del Trabajo de Grado
________________________________
Firma del jurado
Bogotá. Abril de 2018
AGRADECIMIENTOS
A la Oficina Asesora de Sistemas de la Universidad Distrital por haberme facilitado los
recursos necesarios para la realización del proyecto, principalmente al ingeniero Jhon
Gabriel Castellanos por su apoyo y disposición permanente que hicieron posible el
desarrollo de este proyecto de la mejor manera. Al director de la Oficina de Docencia
docente e Ingeniero Gerardo Alberto Castang Montiel por su cordialidad y disponibilidad
sobre interrogantes que se presentaron. Al docente y director del proyecto Ingeniero
Alejandro Paolo Daza Corredor por su acompañamiento, confianza y apoyo a lo largo de
todo este proceso. Y para finalizar agradezco a mis padres, en especial a ellos por su
apoyo incondicional.
TABLA DE CONTENIDO
INTRODUCCIÓN ............................................................................................................. 1
PARTE 1 DEFINICIÓN DEL PROYECTO ........................................................................ 3
CAPÍTULO 1. PLANTEAMIENTO DEL PROBLEMA .................................................... 3
1.1 Descripción del problema ................................................................................... 3
1.2 Formulación del problema .................................................................................. 4
CAPÍTULO 2. OBJETIVOS .......................................................................................... 5
2.1. Objetivo General ............................................................................................... 5
2.2. Objetivos Específicos ........................................................................................ 5
CAPÍTULO 3. JUSTIFICACIÓN ................................................................................... 6
CAPÍTULO 4. La metodología de Kimball .................................................................... 7
CAPÍTULO 5. ALCANCES Y LIMITACIONES .............................................................. 9
5.1 Alcances ............................................................................................................. 9
5.2 Limitaciones ....................................................................................................... 9
PARTE 2 DESARROLLO DEL PROYECTO .................................................................. 10
CAPÍTULO 6. FASE DE PLANIFICACIÓN ................................................................. 10
6.1 Identificar las tareas ......................................................................................... 10
6.2 Programar las tareas ........................................................................................ 11
6.3 Observaciones: ................................................................................................ 14
CAPÍTULO 7. DEFINICIÓN DE REQUERIMIENTOS DEL NEGOCIO ....................... 15
CAPÍTULO 8. MODELADO DIMENSIONAL ............................................................... 20
8.1 Producción en la categoría Libro Docente ........................................................ 20
8.2 Producción en la categoría Revistas Indexadas Docente ................................. 22
8.3 Producción en la categoría Capítulo de Libro Docente ..................................... 25
8.4 Producción en la categoría Ponencia Docente ................................................. 27
8.5 Modelo gráfico de alto nivel .............................................................................. 29
8.6 Identificación de atributos de dimensiones y tabla de hechos ........................... 30
8.7 Implementar el modelo dimensional detallado .................................................. 30
8.8 Prueba del modelo ........................................................................................... 32
8.9 Revisión y validación del modelo ...................................................................... 35
8.10 Documentos finales ........................................................................................ 35
CAPÍTULO 9. DISEÑO FÍSICO .................................................................................. 36
CAPÍTULO 10. DISEÑO DEL SISTEMA (ETL),.......................................................... 38
10.1 Carga de datos a las dimensiones principales: ............................................... 38
10.2 Carga de datos a las dimensiones derivadas ................................................. 43
10.3 Carga de Hechos ........................................................................................... 44
10.4 Unificar Talend-Jobs: ...................................................................................... 45
CAPÍTULO 11. ESPECIFICACIÓN Y DESARROLLO DE APLICACIONES DE BI ..... 47
11.1 Elaboración .................................................................................................... 47
11.2 Querys Utilizados ........................................................................................... 47
CAPÍTULO 12. PRUEBAS FINALES .......................................................................... 51
CAPÍTULO 13. CONCLUSIONES .............................................................................. 57
CAPÍTULO 14. RECOMENDACIONES ...................................................................... 59
CAPÍTULO 15. TRABAJOS FUTUROS ..................................................................... 60
CAPÍTULO 16. BIBLIOGRAFÍA .................................................................................. 61
APÉNDICES .............................................................................................................. 63
Índice de tablas
Tabla 1: Tecnologías Usadas en la Bodega de datos. ................................................... 12
Tabla 2: Temas Analíticos Identificados - Definición de requerimientos del negocio ...... 15
Tabla 3: BUS MATRIX ................................................................................................... 17
Tabla 4: Dimensiones- Producción en la categoría Libro Docente ................................. 21
Tabla 5: Dimensiones - Producción categoría Revistas Indexadas Docente .................. 23
Tabla 6: Dimensiones - Producción en la categoría Capítulo de Libro Docente ............ 26
Tabla 7: Dimensiones - Producción en la categoría Ponencia Docente ........................ 28
Tabla 8: Prueba del Modelo ........................................................................................... 32
Tabla 9: Requerimientos de Hardware Utilizados ........................................................... 36
Tabla 10: Carga de datos dim_docente ......................................................................... 38
Tabla 11: Carga de datos dim_fecha_producto .............................................................. 40
Tabla 12: Carga de datos dim_producto ........................................................................ 40
Tabla 13: Carga de datos dim_proyecto_curricular ........................................................ 41
Tabla 14: Carga de datos dim_tiempo .......................................................................... 42
Tabla 15: Carga de datos dim_evaluador....................................................................... 43
Tabla 16: Carga de datos Hecho_nuevo_producto ........................................................ 44
Tabla 17: Union de Talend_jobs .................................................................................... 45
Índice de figuras
Ilustración 1: Tareas de la metodología de Kimball, ......................................................... 8
Ilustración 2: Estructura en estrella de un Datamart ....................................................... 13
Ilustración 3: Relación entre Docente y Proyecto curricular............................................ 19
Ilustración 4: Nivel de granularidad - Producción en la categoría Libro, ......................... 20
Ilustración 5: Nivel de granularidad - Producción en la categoría Libro, ......................... 21
Ilustración 6: Nivel de granularidad - Producción categoría Revistas Indexadas, ........... 23
Ilustración 7: Nivel de granularidad - Producción en la categoría Capítulo de Libro, ...... 25
Ilustración 8: Nivel de granularidad - Producción en la categoría Ponencia, .................. 27
Ilustración 9: Nivel de granularidad - Producción en la categoría Ponencia, .................. 28
Ilustración 10: Modelo Gráfico de Alto Nivel ................................................................... 30
Ilustración 11: Modelo dimensional detallado, ................................................................ 31
Ilustración 12: Query - Libros de Investigación Elaborados, ........................................... 47
Ilustración 13: Query - Artículos elaborados en Revistas Indexadas Internacionales, .... 48
Ilustración 14: Query - Artículos elaborados en Revistas indexadas Nacionales, ........... 48
Ilustración 15: Query - Ponencias Elaboradas,............................................................... 49
Ilustración 16: Query - Capítulos de Libro elaborados, ................................................... 49
Ilustración 17: Query - Libros de Texto elaborados, ....................................................... 50
Ilustración 18: Reporte Indicador 69, .............................................................................. 51
Ilustración 19: Reporte Indicador 70, .............................................................................. 52
Ilustración 20: Reporte Indicador 71, .............................................................................. 52
Ilustración 21: Reporte Indicador 73, ............................................................................. 53
Ilustración 22: Reporte Indicador 74, .............................................................................. 54
Ilustración 23: Reporte Indicador 75, .............................................................................. 55
Ilustración 24: Modelo de datos relacional KYRON ........................................................ 64
Ilustración 25: Bus Matrix ............................................................................................... 64
Ilustración 26: Modelo Dimensional - Hecho nueva producción. .................................... 64
Ilustración 27: Modelo Dimensional - Hecho nueva experiencia excelencia ................. 64
Ilustración 28: Modelo Dimensional - Hecho nueva observación. .................................. 64
Ilustración 29: Identificación de atributos dim_docente, ................................................. 64
Ilustración 30: Identificación de atributos dim_tiempo, ................................................... 64
Ilustración 31: Identificación de atributos dim_fecha_producto, ...................................... 64
Ilustración 32: Identificación de atributos dim_proyecto_curricular, ................................ 64
Ilustración 33: Identificación de atributos dim_evaluador, .............................................. 64
Ilustración 34: Identificación de atributos dim_producto, ................................................ 64
Ilustración 35: Identificación de atributos hecho_nuevo_prroducto,................................ 64
1
INTRODUCCIÓN
A medida que las tecnologías de manejo y análisis de la información evolucionan,
el concepto de almacenes de datos (Data warehouse) toman cada vez más importancia,
puesto que las instituciones u organizaciones empiezan a enfocarse en lo que se
denomina inteligencia de negocios, inteligencia empresarial, o BI (del inglés business
intelligence).
La inteligencia empresarial se entiende como la reunión de tecnologías,
habilidades, datos, técnicas productos enfocados en la innovación de conocimiento sobre
la empresa, por medio del estudio de la información existente generada por los datos
disponibles, en busca de ser una base sólida para la toma de decisiones empresariales
[13]. Con la inteligencia empresarial es posible identificar las debilidades y fortalezas de
una organización, así como también el establecer estrategias empresariales, ya que, por
medio de la información que es recolectada de todas las áreas de la empresa es posible
obtener el conocimiento que se necesita para ello.
Los componentes más importantes en el BI se destacan el Datamart y el Data
Warehouse (DW). Un DW o almacén de Datos es un repositorio de información de
distintas fuentes que hacen parte de una organización el cual permite procesarla y
analizarla desde una gran variedad de puntos de vista. [14]. Un Datamart es un
subconjunto de datos de un DW para un área en específico (departamentales),
caracterizado por estar especializado para analizar la información al detalle desde todas
las perspectivas que afecten a los procesos de dicho departamento. [14].
La Universidad Distrital Francisco José de Caldas, creada mediante Acuerdo Nº
10 de 1948 por el Concejo de Bogotá es un ente universitario autónomo de carácter
estatal del orden Distrital de Santa Fe de Bogotá D.C.,[15], entre las dependencias más
importantes que posee, se destaca La Oficina Asesora de Sistemas (OAS) la cual según
lo estipulado en el Plan Maestro de informática y Telecomunicaciones de la universidad,
uno de sus objetivos principales es gestionar el conocimiento en un único Sistema de
Información nombrado ATHENEA el cual se compone de un portal, un sistema de BI y la
bodega de datos [11].
2
El modelo de acreditación institucional que maneja la universidad exige cierta
información, la cual se ha venido solventando por medio del uso del sistema ATHENEA,
sin embargo entre los factores que demanda dicho modelo sobresale el denominado
Factor 03 (Docentes), el cual entre sus aspectos a evaluar demanda el considerar
criterios y mecanismos para la evaluación del desempeño, la producción intelectual y las
tareas asignadas a los docentes, sin embargo debido a la falta de acceso a los datos de
los mismos que antiguamente existía, no era posible resolver esta necesidad de
información por parte del sistema ATHENEA.
La dependencia de la universidad encargada de gestionar la producción Intelectual
Docente (Oficina de Docencia), cuenta con una base de datos alterna para este fin la cual
no almacena toda la información docente necesaria, sin embargo, por medio de esta se
ha dado respuesta parcialmente a la información docente solicitada por el modelo de
acreditación Institucional. Este proceso es externo al sistema ATHENEA y al no estar
automatizado, presenta intervención de terceras personas haciendo uso de herramientas
ofimáticas, lo cual pone en vulnerabilidad la seguridad de la información
(Confidencialidad, Integridad, Disponibilidad…Etc.), por otra parte desde el momento en
que la información es solicitada por parte del modelo de acreditación Institucional hasta
que la información está disponible y es presentada, los tiempos de respuesta oscilan
alrededor de 7 a 15 días.
En la actualidad con el desarrollo del sistema de gestión de información docente
KYRON, el cual es un sistema transaccional que hace parte del sistema integrado de
información de la universidad ECOSIIS [11], es posible el acceso a los datos de la
producción Intelectual Docente por lo cual es factible y necesario generar el Datamart
correspondiente, el cual hará parte de la bodega de datos de ATHENEA permitiendo
automatizar el proceso externo que sigue la Oficina de Docencia para dar respuesta a las
necesidades de Información que demanda el modelo de Acreditación Institucional.
En este trabajo se plantea el analizar, diseñar y desarrollar el Datamart
mencionado anteriormente bajo la metodología para la construcción de DW Kimball, y
con ello brindar respuesta a la necesidad de información que demanda el modelo de
acreditación institucional en su Factor 03 Docentes (Indicadores 69 - 75).
3
PARTE 1 DEFINICIÓN DEL PROYECTO
CAPÍTULO 1. PLANTEAMIENTO DEL PROBLEMA
1.1 Descripción del problema
El modelo de acreditación institucional de la Universidad Francisco José de Caldas
en su factor 03 (Docentes), entre sus aspectos a evaluar demanda el considerar criterios
y mecanismos para la evaluación del desempeño, la producción intelectual y las tareas
asignadas a los docentes.
La Oficina Asesora de Sistemas (OAS) según lo estipulado en el Plan Maestro de
informática y Telecomunicaciones tiene el objetivo gestionar el conocimiento en un único
sistema de información nombrado ATHENEA el cual se compone de un portal, un sistema
de BI y la bodega de datos [11], así pues los datos generados por las diferentes
dependencias de la universidad deben reunirse en dicho sistema y este debe ser capaz
de responder ante las diferentes necesidades de información que se pueda presentar.
Debido a que ATHENEA no contaba con acceso a la información de la producción
Intelectual docente, no era posible generar la información que solicita el modelo de
acreditación institucional en su factor 03 (Docentes). Es solo hasta el año 2017 que la
fase en la que se encuentra el sistema de información anteriormente mencionado con el
que cuenta la Universidad Francisco José de Caldas, cuenta con acceso a la base de
datos de docentes, esto debido al lanzamiento reciente del sistema de gestión de
información docente KYRON, sin embargo al no existir el DATAMART correspondiente,
la Bodega de Datos de ATHENEA no cuenta con esta información razón por la cual no
es posible soportar procesos ETL (Extract, Transform and Load), así como tampoco
obtener una respuesta masiva del estado de la información docente y por ello la
incapacidad de analizar y/o tomar de decisiones al respecto.
4
1.2 Formulación del problema
Ante la problemática descrita anteriormente, ¿Qué modelo de información permite
considerar la importancia del dato histórico, de la respuesta masiva, el análisis y la toma
de decisiones y por medio del mismo suplir las necesidades de información que solicita
el modelo de acreditación institucional en su factor 03 (Docentes) (Indicadores 69-75),
adaptándose a las políticas de gestión de información que maneja la Oficina Asesora de
Sistemas?
5
CAPÍTULO 2. OBJETIVOS
2.1. Objetivo General
Realizar el análisis, diseño y desarrollo de un DATAMART el cual por medio de
información relevante que almacene permita la evaluación y análisis de la misma bajo las
necesidades de información que requiere el modelo de acreditación institucional (Factor
03 - Indicadores 69 -75) en la Universidad Distrital Francisco José de Caldas.
2.2. Objetivos Específicos
Implementar un Almacén de Datos (DATAMART) orientado a los Docentes de
la universidad, que permita solventar las necesidades de información que
demanda el Modelo de acreditación Institucional en su Factor 03 Docentes
(Indicadores 69 -75).
Realizar el debido proceso de documentación que soporte el desarrollo del
Almacén de Datos con la finalidad de reducir el riesgo de ambigüedades y
confusiones que pongan en jaque el proyecto.
Establecer el ciclo de vida de los Datos de acuerdo a las pautas establecidas
por la Oficina Asesora de Sistemas de la Universidad Distrital Francisco José
de caldas.
Probar el modelo contra los requerimientos del negocio, por medio de diseños
de reportes creados a partir del mismo modelo y con ellos verificar el
cumplimiento de los requerimientos establecidos.
Permitir por medio del almacén de datos comprender la situación actual
relacionada con la producción intelectual de los Docentes que maneja la
universidad.
Disminuir la incertidumbre en la toma de decisiones al reducir el tiempo de
disponibilidad de la información docente por medio de los reportes efectuados
por el Datamart correspondiente.
6
CAPÍTULO 3. JUSTIFICACIÓN
Debido a la necesidad de satisfacer con los requisitos de información sobre la
producción intelectual (libros, capítulos de libros, ponencias, artículos) de la planta
profesoral de la Universidad que solicita el modelo de acreditación institucional, y la
insuficiencia de un modelo de datos que permita al sistema ATHENEA con el que cuenta
la OAS obtener dicha información masiva, de forma ágil y estructurada, se propone la
implementación de un DATAMART, el cual hará parte de la bodega de datos de
ATHENEA permitiendo analizar, dar control y seguimiento continuo al desarrollo de la
producción intelectual de los docentes de la universidad. De esta manera se asegurará
no solo el almacenamiento del dato histórico, sino que facilitará el análisis de la
producción intelectual por medio de consultas masivas generadas en forma de reportes
y en consecuencia solventar y estar un paso adelante de los requisitos de información
que demanda el modelo de acreditación, así como también tener un punto de referencia
sobre la toma de decisiones frente al tema.
Esta propuesta adicionalmente busca automatizar el proceso externo a ATHENEA
que sigue la oficina de Docencia para dar respuesta a las necesidades de información
del modelo de acreditación Institucional y por ende disminuir los tiempos de disponibilidad
de la información docente, por otra parte se busca contribuir a elevar el nivel académico
del profesorado de la universidad, a fin de nivelar en todas las disciplinas manejadas la
búsqueda continua de conocimiento y la producción intelectual, al proporcionar un
análisis de la situación actual de la misma.
7
CAPÍTULO 4. LA METODOLOGÍA DE KIMBALL
Con el avance propio de la tecnología, hoy en día el concepto de Data warehouse
(DW), está pasando a tener más relevancia a medida que las organizaciones empiezan
a considerar los esquemas de análisis de datos con igual importancia que los esquemas
de recolección de datos.
Un Data Warehouse es una base de datos multidimensional que está separada
del sistema operativo. Utilizada para obtener la información necesaria para la toma de
decisiones de una organización. Un Data Warehouse es integrado, no volátil y variable
en el tiempo. [1][2], “diseñado para favorecer el análisis y la divulgación eficiente de datos
(especialmente con herramientas OLAP, de procesamiento analítico en línea). [3]”.
La metodología de Ralph Kimball se fundamenta en lo que el mismo autor
denomina Ciclo de vida dimensional del proyecto (Business Dimensional Lifecycle) [1]
(Ilustración 1), Kimball considera que un almacén de datos puede ser considerado como
un conjunto de Datamart de datos consistentes y basado en dimensiones compartidas
conformadas [4].
El Business Dimensional Lifecycle se fundamenta en 4 principios:
Centrarse en el negocio: Enfocarse en la identificación de los requerimientos del
negocio y su valor asociado.
Construir una infraestructura de información adecuada: Diseñar una base de
información única, integrada, fácil de usar, de alto rendimiento en la que se podrá
evidenciar los requerimientos de negocio identificados.
Realizar entregas en incrementos significativos: crear el (DW) en incrementos
entregables dependiendo del valor de negocio de cada elemento identificado esto
con el fin de determinar el orden de aplicación de los incrementos.
Ofrecer la solución completa: Un DW sólido, con un buen diseño probado y que
sea accesible, además de ofrecer herramientas de consulta como informes y
análisis avanzado, documentación entre otros. [3].
8
Ya que la construcción de una solución de DW/BI (Data Warehouse/Business
Intelligence) puede resultar compleja, la metodología de Kimball es una de las más
usadas para dicho fin [2] ya que presenta:
Implementación más rápida: El enfoque de Kimball es de abajo hacia arriba. Por
lo tanto, el alcance de la investigación podría ser limitado. Por lo tanto, los usuarios
obtendrán beneficios inmediatos de la implementación.
Implementación más sencilla: El modelado dimensional en el enfoque de Kimball
facilita la comprensión entre los usuarios y los desarrolladores del sistema. [6].
Como se observa en la Ilustración 1, la tarea de Definición de Requerimientos del
Negocio es fundamental ya que es la que soporta las tareas siguientes, las cuales se
dividen en 3 segmentos así:
Segmento superior (Tecnología): Implica tareas relacionadas con software
específico, ejemplo: Microsoft SQL Analysis Services.
Segmento medio: (Datos): Implementación y diseño del Modelo Dimensional,
como también el diseño e Implementación del subsistema ETL (Extracción,
Transformación y Carga) para cargar el DW.
Segmento Inferior (Aplicaciones de BI): En este segmento se diseña y desarrolla
aplicaciones de negocios para los usuarios finales.
Ilustración 1: Tareas de la metodología de Kimball, Fuente: (Kimball et al 98, 08, Mundy & Thornthwaite 06)
9
CAPÍTULO 5. ALCANCES Y LIMITACIONES
5.1 Alcances
En términos de desarrollo de software el proyecto abarca el análisis, diseño y
desarrollo del Almacén de Datos (DATAMART).
El proyecto estará estructurado en 24 fases, 2 fases en la Planificación, 4 fases en
la Definición de Requerimientos del Negocio, 2 fases para el modelo dimensional,
2 fases en el diseño físico, 10 fases en el diseño del ETL, 3 fases para la
Especificación y desarrollo de aplicaciones de BI y 1 fase para las pruebas
correspondientes.
Cada fase corresponde a una semana
5.2 Limitaciones
La solución de software estará basada en una plataforma open source sin
embargo los ETL y el diseño del Datamart serán propiedad de la universidad
Francisco José de Caldas dando respuesta a políticas distritales e institucionales.
Realizar y documentar el análisis y diseño de los módulos descritos de acuerdo a
la metodología comunicada y establecida en el proyecto en un plazo de seis (6)
meses máximo.
El análisis y el diseño a desarrollar deben tener en cuenta las características
metodológicas que se emplearán.
Se presenta una limitación frente al acceso a la información que está relacionada
con otros proyectos de la oficina Asesora de sistemas.
Se presenta una limitación frente al tiempo para el desarrollo del proyecto, ya que
a partir de la aprobación de este documento se dispone de 6 meses como máximo
para su desarrollo.
10
PARTE 2 DESARROLLO DEL PROYECTO
A la par con la metodología planteada en este proyecto, el desarrollo del mismo se
dividió en 7 fases fundamentales.
Planificación
Definición de requerimientos de Negocio
Modelado dimensional
Diseño físico
Diseño del sistema de extracción transformación y carga (ETL)
Especificación y desarrollo de aplicaciones BI
Pruebas finales.
CAPÍTULO 6. FASE DE PLANIFICACIÓN
El propósito fundamental de esta fase es determinar la definición y el alcance de
la solución, incluye acciones típicas de un plan de proyecto, enfocadas en obtener una
aproximación inicial de las necesidades de información [3]. En la parte 1 de este
documento determinamos este propósito, tal como se observa en la descripción del
problema (Índice 1.1), la Justificación del proyecto (Capítulo 3) el alcance y limitaciones
del mismo (Capítulo 5).
6.1 Identificar las tareas
El propósito es identificar diferentes tareas a priori que permitan introducirse en la
solución del proyecto. Las siguientes son las tareas que se identificaron durante la fase
de planeación:
Obtener del modelo de datos relacional sistema de gestión de información docente
KYRON.
11
Composición actual de la Bodega de Datos por parte del sistema de información
ATHENEA.
Tecnologías usadas en la Bodega de datos.
Información estructural de los Datamart.
Estándares Utilizados.
6.2 Programar las tareas
Se estableció ejecutar las siguientes tareas en el lapso de 1 semana, como
resultado se obtuvo la siguiente información:
6.2.1 Obtener del modelo de datos relacional del sistema de gestión de
información docente KYRON.
El modelo de datos facilitado por la Oficina Asesora de Sistemas, se observa en la
Ilustración 10, Apéndice A.
6.2.2 Composición actual de la Bodega de Datos por parte del sistema de
información ATHENEA.
El Sistema de Bodega de Datos se encuentra actualmente en fase de producción,
cuenta con 8 Datamart los cuales recolectan información de las diferentes dependencias
de la Universidad [16], generando las distintas estructuras de conocimiento
representadas mediante el sistema de inteligencia de Negocio BI del sistema de
información ATHENEA, estos Datamart son:
Datamart de Admisiones
Datamart de Escalafón
Datamart de Proyectos Curriculares
Datamart de Bienestar Institucional
Datamart de Contratación
12
Datamart de Egresados
Datamart de Administración Financiera
Datamart de Investigaciones
6.2.3 Tecnologías usadas en la Bodega de datos.
Según el Plan Maestro de Informática y Telecomunicaciones [11], las tecnologías
utilizadas en relación con la bodega de datos se observan en la siguiente tabla.
Tabla 1: Tecnologías Usadas en la Bodega de datos.
Tecnología
Descripción
Talend Open Studio
Herramienta Open Source, utilizada para modelar
transformaciones de datos generando código Java.
TuleAp
Gestor de Proyectos para la administración
centralizada y supervisada de los proyectos de
software
PostgreSQL
Motor de Base de datos SQL
SpagoBI
Multiplataforma de código abierto desarrollada para
la Inteligencia de negocios (Business Intelligence).
Fuente: (Autores)
6.2.4 Información estructural de los Datamart
Los Datamart que hacen parte de la bodega de datos de ATHENEA, cuentan con
una estructura en estrella (Ilustración 2), la cual separa los datos en hechos y
13
dimensiones. Los hechos contienen datos medibles, las dimensiones son atributos que
describen los hechos. Este tipo de esquema fue la sugerencia que la Oficina Asesora de
Sistemas dio para la elaboración del Datamart.
6.2.5 Estándares Utilizados:
La Oficina Asesora de Sistemas indico una serie de reglas a seguir en la
elaboración del Datamart:
Los nombres de las dimensiones, los hechos y sus atributos, deben ser lo más
claros posibles, de los cuales se pueda inferir fácilmente la información
relacionada con estos.
Por convención para atributos con más de una palabra se utiliza guion al piso ‘_’
como separador.
Los nombres de las dimensiones, los hechos y sus atributos deben ir en letra
minúscula.
Ilustración 2: Estructura en estrella de un Datamart Fuente: (Autores)
14
6.3 Observaciones:
6.3.1 Definir el alcance
Para el caso particular del proyecto el alcance está definido por las necesidades
de información del modelo de acreditación institucional (característica 8 – Indicadores 69
- 75), indicadores relacionados sobre la planta profesoral de la Universidad Distrital
Francisco José de Caldas.
Sin embargo, los principios fundamentales de la metodología, impulsan a entregar
una solución completa con una infraestructura de información adecuada, esto significa
implementar una base de información única, de alto rendimiento que permita obtener gran
variedad de análisis o consultas donde se reflejen amplios requerimientos de negocio de
la empresa.
Por ello el Datamart docente contemplará toda la información presente en el
sistema de gestión de información docente KYRON, permitiendo en trabajos posteriores
implementar diferentes procesos analíticos que permitan realizar diferentes análisis de
información, aparte de los que son objeto en este proyecto.
6.3.2 Consideraciones
A partir de este punto, solo se tomarán las necesidades fundamentales de
información del proyecto, Modelo de acreditación Institucional en su Factor 03 Docentes
(Indicadores 69 -75).
Sin embargo, considerando toda la información de la producción intelectual
docente del modelo KYRON, el proceso sigue las mismas pautas que se presentan de
este punto en adelante. Los entregables más significativos (modelo dimensional, BUX
MATRIX) considerando toda la información de la producción intelectual docente del
modelo KYRON, se pueden encontrar en la Ilustración 25-28, Apéndice E.
15
CAPÍTULO 7. DEFINICIÓN DE REQUERIMIENTOS DEL NEGOCIO
El objetivo fundamental, es entender los factores claves, el comportamiento mismo
del negocio, con el objetivo de llegar a diseños eficientes para el almacén de datos,
puesto que será la base en la que se sostendrá todo el proyecto [3]. Ya que es en el
sistema de gestión de información docente KYRON donde se encuentra el acceso a la
información de la producción Intelectual de los docentes, se establecieron reuniones con
los entes directamente relacionados con el funcionamiento del mismo, estos son:
Oficina de Docencia de la universidad Distrital Francisco José de Caldas:
La oficina de docencia, es la dependencia encargada de gestionar la producción
intelectual realizada por los docentes de la universidad, la cual concedió todo el
conocimiento de las formas en que estas producciones se clasifican y del
significado de cada uno de los datos que se relacionan en KYRON.
Oficina Asesora de Sistemas (OAS):
En comunicación directa por medio del Ingeniero Jhon Gabriel Castellanos, esta
dependencia brindó la estructura, así como los detalles técnicos que implementa
KYRON, los cuales permitieron el análisis en función de un diseño efectivo.
A partir de reuniones con el personal presentado anteriormente y considerando las
necesidades de información del modelo de acreditación institucional, fundamentales en
este proyecto; se identificaron los temas detallados en la siguiente tabla.
Tabla 2: Temas Analíticos Identificados - Definición de requerimientos del negocio
Tema Analítico
Requerimiento Inferido o Pedido
Proceso de
Negocio
Datos correspondientes a los 3 últimos o Soporte
años acerca de: Número de libros elaborados por
los profesores como producto de la investigación
por año/ número de profesores de tiempo
completo y medio tiempo en TCE.
Producción en la
categoría Libro
Docente
16
Criterios y
mecanismos
para la
evaluación del
desempeño, la
producción
intelectual y las
tareas
asignadas a los
docentes.
Datos correspondientes a los 3 últimos años
acerca de: número de artículos elaborados por
los profesores en revistas internacionales
indexadas por año / número de profesores de
tiempo completo y medio tiempo en TCE.
Producción en la
categoría
Revistas
Indexadas
Docente
Datos correspondientes a los 3 últimos años
acerca de: número de artículos elaborados por
los profesores en revistas nacionales indexadas
por año / número de profesores de tiempo
completo y medio tiempo en TCE.
Producción en la
categoría
Revistas
Indexadas
Docente
Datos correspondientes a los 3 últimos años
acerca de: número de artículos elaborados por
los profesores en revistas especializadas
nacionales e internacionales por año / número de
profesores de tiempo completo y medio tiempo
en TCE.
Producción en la
categoría
Revistas
Indexadas
Docente
Datos correspondientes a los 3 últimos años
acerca de: número de ponencias en versión
completa, publicadas por los profesores, por año
/ número de profesores de tiempo completo y
medio tiempo en TCE.
Producción en la
categoría
Ponencia
Docente
Datos correspondientes a los 3 últimos años
acerca de: número de capítulos en libros
publicados por los profesores, por año / número
de profesores de tiempo completo y medio
tiempo en TCE.
Producción en la
categoría
Capítulo de Libro
Docente
17
Datos correspondientes a los tres últimos años,
sobre: número de libros de texto publicados por
los profesores, por año / número de profesores
de tiempo completo y medio tiempo en TCE.
Producción en la
categoría Libro
Docente
Fuente: (Autores)
Por medio del análisis de esta tabla, se implementó una herramienta trascendental
para el proceso de construcción del Datamart, denominada matriz de
procesos/dimensiones (BUX MATRIX), la cual es una herramienta de diseño clave ya que
representa los procesos de negocio y la dimensión asociada, así mismo se obtiene una
perspectiva transversal en como los datos del Datamart se integran en toda la
organización, es independiente de tecnología y base de datos permitiendo un desarrollo
escalable. [1].
Con base en los procesos de negocio, que soportan los requerimientos propuestos
en la tabla 2, y teniendo en cuenta la forma en que estos se reflejan en KYRON, así como
sus características propias, se deriva la mencionada BUX MATRIX (tabla 3).
Tabla 3: BUS MATRIX
Dimensiones
Proceso de Negocio
tiempo
fecha
producto
producto
proyecto
curricular
docente
Producción en la categoría
Ponencia Docente
X
X
X
X
X
Producción en la categoría
Revistas Indexadas Docente
X
X
X
X
X
18
Producción en la categoría
Capítulo de Libro Docente
X
X
X
X
X
Producción en la categoría
Libro Docente
X
X
X
X
X
Fuente: (Autores)
Como se observa, las dimensiones transversales son comunes para todos los
procesos, por ello, se pueden unificar en un solo macro-proceso “Nueva producción”, a
continuación, se describe las dimensiones que la conforman:
Tiempo: Es la dimensión relacionada con el (tratamiento de fechas y horas), de
cada “Nueva producción”, es fundamental puesto que se requiere una perspectiva
temporal de los requerimientos solicitados.
Fecha producto: Puesto que cada proceso de negocio, cuenta con dos
perspectivas temporales, (fecha de Acta de validación del producto, y fecha de
elaboración del producto), para evitar ambigüedades, se estableció la dimensión
fecha producto, la cual contiene información propia sobre la perspectiva temporal
en la que el producto fue elaborado, mas no en la que el producto fue validado y
verificado por la Universidad.
Producto: Hace referencia al objeto de una “Nueva producción”, para este caso
la dimensión producto, contiene todos los atributos descriptivos de las
producciones intelectuales docentes siguientes:
o Libro Docente
o Capítulo de Libro Docente
o Revista Indexada Docente
o Ponencia Docente
Proyecto curricular: Según el modelo relacional de KYRON la cardinalidad de la
relación que existe entre los Docentes y los Proyectos Curriculares es N: N (Un
proyecto curricular puede tener varios docentes, y un docente puede ejercer en
19
varios proyectos curriculares) (Ilustración 3). Para facilitar el análisis de los datos
se descompone la relación en dos dimensiones, una dimensión para el docente y
otra para el proyecto curricular en la cual la tabla de rompimiento resultante se
funde en la tabla de hechos permitiendo representar la relación N: N.
Docente: Además del análisis anterior, la dimensión docente es fundamental, ya
que hace referencia al autor de una “Nueva Producción”, de igual manera por
medio de esta, aumenta la capacidad de explorar los datos desde diferentes
perspectivas por parte del autor, como género, edad, entre otras.
Ilustración 3: Relación entre Docente y Proyecto curricular Según el modelo KYRON
Fuente: (Autores)
20
CAPÍTULO 8. MODELADO DIMENSIONAL
A partir de la BUS MATRIX (tabla 3), se ejecutan las siguientes actividades por
cada proceso de Negocio:
Establecer el Nivel de Granularidad.
Elegir las Dimensiones.
Identificar las medidas y hechos.
8.1 Producción en la categoría Libro Docente
8.1.1 Establecer el Nivel de Granularidad
En la Ilustración 4 y 5, se observa el máximo nivel de detalle posible, del proceso
de Producción en la categoría libro docente, en la cual se aprecian 11 tablas del modelo
KYRON relacionadas, de las cuales se evidencia la necesidad de manejar información
sobre “evaluador_libro_docente”.
Ilustración 4: Nivel de granularidad - Producción en la categoría Libro,
Fuente: (Autores)
21
Ilustración 5: Nivel de granularidad - Producción en la categoría Libro, Fuente: (Autores)
8.1.2 Elegir las dimensiones
En la tabla 4, se observan las dimensiones generadas con base al nivel de
granularidad analizado anteriormente y la BUX MATRIX.
Tabla 4: Dimensiones- Producción en la categoría Libro Docente
DIMENSION GRANULARIDAD
DIMENSION PRODUCTO:
Libro docente
Tipo de libro
Editorial
Universidad
DIMENSION TIEMPO:
Libro docente: En su atributo:
Fecha de acta
Numero de acta
Numero de caso
Normatividad
Estado
22
DIMENSION FECHA PRODCUTO:
Libro docente: En su atributo:
Año de publicación
DIMENSION PROYECTO CURRICULAR:
Proyecto Curricular
Facultad
DIMENSION DOCENTE:
Docente
Genero
Tipo de Documento
Fuente: (Autores)
8.1.3 Identificar las medidas y tabla de hechos
Para el caso particular del este proceso de negocio la medida viene dada por el
puntaje que se asigna al producto (libro_docente - puntaje).
8.2 Producción en la categoría Revistas Indexadas Docente
8.2.1 Establecer el Nivel de Granularidad
En la Ilustración 6, se observa el máximo nivel de detalle posible, del proceso de
Producción en la categoría Revistas Indexadas Docente, en la cual se aprecian 10 tablas
del modelo KYRON relacionadas, se evidencia información relacionada al tipo de
indexación la cual debe hacer parte de la dimensión producto.
23
Ilustración 6: Nivel de granularidad - Producción categoría Revistas Indexadas,
Fuente: (Autores)
8.2.2 Elegir las Dimensiones
En la tabla 5, se observan las dimensiones generadas con base al nivel de
granularidad analizado anteriormente y la BUX MATRIX.
Tabla 5: Dimensiones - Producción categoría Revistas Indexadas Docente
24
DIMENSION GRANULARIDAD
DIMENSION PRODUCTO:
Revista Indexada
Tipo de Indexación
País
Contexto
DIMENSION TIEMPO:
Revista Indexada: En su atributo:
Fecha de acta
Numero de acta
Numero de caso
Normatividad
Estado
DIMENSION FECHA PRODCUTO:
Revista Indexada: En su atributo:
Año de publicación
DIMENSION PROYECTO CURRICULAR:
Proyecto Curricular
Facultad
DIMENSION DOCENTE:
Docente
Genero
Tipo de Documento
Fuente: (Autores)
8.2.3 Identificar las medidas y tabla de hechos
La medida que surge de este proceso de negocio, al igual que la iteración anterior
está dada por el puntaje que se asignado al producto (Revista Indexada - puntaje).
25
8.3 Producción en la categoría Capítulo de Libro Docente
8.3.1 Establecer el Nivel de Granularidad
En la Ilustración 7, se observa el máximo nivel de detalle posible, del proceso de
Producción en la categoría Capítulo de Libro Docente, en la cual se aprecian 10 tablas
del modelo KYRON relacionadas, al igual que el proceso de Producción en la categoría
Libro Docente, se evidencia la necesidad de manejar información sobre
“evaluador_capitulo_libro_docente”.
Ilustración 7: Nivel de granularidad - Producción en la categoría Capítulo de Libro,
Fuente: (Autores)
26
8.3.2 Elegir las dimensiones
En la tabla 6, se observan las dimensiones generadas con base al nivel de
granularidad analizado anteriormente y la BUX MATRIX.
Tabla 6: Dimensiones - Producción en la categoría Capítulo de Libro Docente
DIMENSION GRANULARIDAD
DIMENSION PRODUCTO:
Capitulo libro
Editorial
Tipo Libro
DIMENSION TIEMPO:
Capitulo libro: En su atributo:
Fecha de acta
Numero de acta
Numero de caso
Normatividad
Estado
DIMENSION FECHA PRODCUTO:
Capitulo libro: En su atributo:
Año de publicación
DIMENSION PROYECTO CURRICULAR:
Proyecto Curricular
Facultad
DIMENSION DOCENTE:
Docente
Genero
Tipo de Documento
Fuente: (Autores)
27
8.3.3 Identificar las medidas y tabla de hechos
La medida que surge de este proceso de negocio, está dada por el puntaje que se
asigna al producto (Capítulo libro - puntaje).
8.4 Producción en la categoría Ponencia Docente
8.4.1 Establecer el Nivel de Granularidad
En la Ilustración 8 y 9, se observa las tablas vinculadas en el máximo nivel de
detalle posible, del proceso de Producción en la categoría Ponencia Docente. A diferencia
de los procesos anteriores se aprecian 8 tablas del modelo KYRON relacionadas, se
evidencia información relacionada al contexto de la ponencia la cual debe hacer parte de
la dimensión producto.
Ilustración 8: Nivel de granularidad - Producción en la categoría Ponencia, Fuente: (Autores)
28
Ilustración 9: Nivel de granularidad - Producción en la categoría Ponencia, Fuente: (Autores)
8.4.2 Elegir las dimensiones
En la tabla 7, se observan las dimensiones generadas con base al nivel de
granularidad analizado anteriormente y la BUX MATRIX.
Tabla 7: Dimensiones - Producción en la categoría Ponencia Docente
DIMENSION GRANULARIDAD
DIMENSION PRODUCTO:
Ponencia
Contexto Ponencia
DIMENSION TIEMPO:
Ponencia: En su atributo:
Fecha de acta
Numero de acta
Caso acta
Normatividad
Estado
DIMENSION FECHA PRODCUTO:
Ponencia: En su atributo:
Anno
DIMENSION PROYECTO CURRICULAR:
Proyecto Curricular
Facultad
29
DIMENSION DOCENTE:
Docente
Genero
Tipo de Documento
Fuente: (Autores)
8.4.3 identificar las medidas y tabla de hechos
La medida que surge de este proceso de negocio viene dada por el puntaje que
se asigna al producto (Ponencia - puntaje).
8.5 Modelo gráfico de alto nivel
Al finalizar el proceso dimensional Inicial, se generó el modelo gráfico de alto nivel
respectivo (Ilustración 10), en el cual se pueden detallar tres aspectos importantes:
Los procesos de negocio (capítulo de libro docente y Libro docente), presentan
una dimensión adicional llamada evaluador, normalmente la información de esta
dimensión estaría incluida en la dimensión producto, sin embargo la carnalidad de
la relación existente según el modelo relacional de KYRON, es 1: N, es decir un
solo producto puede tener varios evaluadores, motivo por el cual se decide luego
de un análisis con el Ingeniero Jhon Gabriel Castellanos, directamente relacionar
esta dimensión a la dimensión producto.
Los procesos de negocio se unifican en un macro proceso “Nueva producción”, ya
que como se evidencia en la BUS MATRIX (tabla 3) las dimensiones son comunes
entre todos los procesos.
La relación N: N entre docente y proyecto curricular se normaliza en el hecho de
“nueva producción”
30
8.6 Identificación de atributos de dimensiones y tabla de hechos
Por cada dimensión se procede a realizar tablas en las cuales se determinan los
atributos de estas, la fuente de los datos (esquema transaccional), el destino
(dimensiones - hechos), y las reglas de conversión, transformación y carga (ETL Rules).
Estas tablas se encuentran en las Ilustraciones 29-35, Apéndice F.
8.7 Implementar el modelo dimensional detallado
Esta etapa se centra en identificar atributos útiles, definiciones y reglas asociadas
que especifican cómo se cargan los datos [3].
Como se puede observar en las Ilustraciones (29 - 35) del Apéndice F, a diferencia
de dim_evaluador, la única relación existente entre las dimensiones es la que se identifica
en la dimensión hecho, puesto que, por cada nuevo registro, estarían las llaves foráneas
pertenecientes a cada dimensión. Así pues, luego de tener las dimensiones
correspondientes cargadas, entre ellas no existiría ninguna relación que pudiese efectuar
´JOIN´ para poder vincular las llaves foráneas de estas a la tabla de hechos.
Ilustración 10: Modelo Gráfico de Alto Nivel Fuente: (Autores)
31
Razón por la cual se hace necesario, agregar atributos comunes para todas las
dimensiones que permitan solventar esta situación.
Como se puede observar en el modelo dimensional detallado (Ilustración 11), los
siguientes atributos se establecieron comunes a todas las dimensiones:
Ilustración 11: Modelo dimensional detallado, Fuente: (Autores)
32
producto_nombre:
dni_docente
codigo_isbn
numero_issn_auto_id
numero_issn
ponencia_id
8.8 Prueba del modelo
El modelo se probó de una forma práctica, deduciendo como este podría dar
solución a los requerimientos de información del proyecto. (Ver Tabla 8).
Nota: Puesto que en el modelo de datos de KYRON, no existen datos relacionados
con, número de profesores de tiempo completo y medio tiempo en TCE, no es posible
obtener esta información del modelo dimensional generado y representarla en los
reportes.
Tabla 8: Prueba del Modelo
Requerimiento:
Datos correspondientes a los 3 últimos años acerca de: Número de libros elaborados
por los profesores como producto de la investigación por año/ número de profesores
de tiempo completo y medio tiempo en TCE.
Solución:
Desde la dimensión dim_producto, podemos hallar por medio de los atributos
producto_nombre y producto_tipo_id, todos los libros de investigación.
Desde la dimensión dim_tiempo, podemos presentar los resultados de los últimos años
agrupándolos por el atributo anno_acta.
33
Requerimiento:
Datos correspondientes a los 3 últimos años acerca de: número de artículos elaborados
por los profesores en revistas internacionales indexadas por año / número de
profesores de tiempo completo y medio tiempo en TCE.
Solución:
Desde la dimensión dim_producto, podemos hallar por medio de los atributos
producto_nombre y contexto_id, todos los artículos en revistas indexadas
internacionales.
Desde la dimensión dim_tiempo, podemos presentar los resultados de los últimos años
agrupándolos por el atributo anno_acta.
Requerimiento:
Datos correspondientes a los 3 últimos años acerca de: número de artículos elaborados
por los profesores en revistas nacionales indexadas por año / número de profesores de
tiempo completo y medio tiempo en TCE.
Solución:
Desde la dimensión dim_producto, podemos hallar por medio de los atributos
producto_nombre y contexto_id, todos los artículos en revistas indexadas nacionales.
Desde la dimensión dim_tiempo, podemos presentar los resultados de los últimos años
agrupándolos por el atributo anno_acta.
34
Requerimiento:
Datos correspondientes a los tres últimos años, sobre: número de libros de texto
publicados por los profesores, por año / número de profesores de tiempo completo y
medio tiempo en TCE.
Solución:
Desde la dimensión dim_producto, podemos hallar por medio de los atributos
producto_nombre y producto_tipo_id, todos los libros de texto.
Desde la dimensión dim_tiempo, podemos presentar los resultados de los últimos años
agrupándolos por el atributo anno_acta.
Requerimiento:
Datos correspondientes a los 3 últimos años acerca de: número de ponencias en
versión completa, publicadas por los profesores, por año / número de profesores de
tiempo completo y medio tiempo en TCE.
Solución:
Desde la dimensión dim_producto, podemos hallar por medio del atributo
producto_nombre todas las ponencias publicadas.
Desde la dimensión dim_tiempo, podemos presentar los resultados de los últimos años
agrupándolos por el atributo anno_acta.
Requerimiento:
Datos correspondientes a los 3 últimos años acerca de: número de capítulos en libros
publicados por los profesores, por año / número de profesores de tiempo completo y
medio tiempo en TCE.
Solución:
Desde la dimensión dim_producto, podemos hallar por medio del atributo
producto_nombre todos los capítulos en libros publicados
35
Desde la dimensión dim_tiempo, podemos presentar los resultados de los últimos años
agrupándolos por el atributo anno_acta.
Requerimiento:
Datos correspondientes a los 3 últimos años acerca de: número de artículos elaborados
por los profesores en revistas especializadas nacionales e internacionales por año /
número de profesores de tiempo completo y medio tiempo en TCE.
Solución
Fuente: (Autores)
8.9 Revisión y validación del modelo
Se estableció una reunión con el Ingeniero Jhon Gabriel Castellanos personal, con
la finalidad de revisar el modelo dimensional desde diferentes perspectivas, llegando a la
conclusión de que este es capaz de solventar las necesidades de información de los
requerimientos, sin apreciar la información sobre “número de profesores de tiempo
completo y medio tiempo en TCE”, puesto que esta no se encuentra disponible en el
modelo KYRON.
8.10 Documentos finales
Los siguientes son los documentos finales del proceso de Modelado Dimensional:
BUS MATRIX (Tabla 3).
Modelo de datos inicial de alto nivel (Ilustración 10).
Identificación de atributos de dimensiones y tabla de hechos (Ilustración 29
- 35, Apéndice F).
Modelo dimensional (Ilustración 11).
36
CAPÍTULO 9. DISEÑO FÍSICO
Ya que la universidad distrital francisco José de caldas por medio del sistema de
información ATHENEA, cuenta con un sistema de B/I (Servidores, Almacenamiento,
Procesamiento), actualmente en uso, de código libre, los requerimientos de Hardware
necesarios para la implementación del Datamart están solventados.
Se referencia la implementación realizada desde una laptop con los siguientes
requerimientos:
Tabla 9: Requerimientos de Hardware Utilizados
Características Secundarias Otros
Procesador:
AMD A-
Series A6-4400M
(2700 MHz - 3200
MHz)
RAM:
6GB DDR3
(1600 MHz)
Pantalla:
LED 17.3"
(1600x900)
Almacenamiento:
HDD 640GB
(5400rpm)
Tarjetas de video:
AMD Radeon
HD 7520G
(Integrada)
Peso:
2600 g.
Sistema Operativo:
Microsoft
Windows 8
Unidad óptica:
DVD±RW
Puertos de video:
HDMI | VGA
WiFi:
Genérica
(802.11 b/g/n)
Puertos USB:
3
Webcam:
0.3
LAN:
10 / 100 Mbps
Adaptador de
energía:
45W.
Lector de tarjetas:
5-en-1
¿Lector de huellas
digitales?
No
Fuente: (Autores)
37
El proceso de convertir el modelo de datos lógico al modelo de datos relacional,
contó con las siguientes etapas:
1. Se utilizó la herramienta MySQL-Workbench, para generar el modelo lógico
Dimensional del Datamart, (Ilustración 11).
2. Se generó el script SQL por medio de la misma herramienta.
3. Se convirtió el script MYSQL a un script soportado por POSTGRESQL ya que es
el sistema relacional de destino, para esto se utilizó un script PERL
“mysql2pgsql.perl” de uso libre, elaborado por Maxim Rudensky y Danilchuk [17].
4. Con el script POSTGRESQL generado, se solucionan algunos bugs generados del
ítem anterior.
5. Se creó la base de datos en POSTGRESQL y se cargó el script, finalizando la
implementación del modelo de datos relacional del Datamart.
38
CAPÍTULO 10. DISEÑO DEL SISTEMA (ETL),
EXTRACCIÓN TRANSFORMACIÓN Y CARGA
Se utilizó la herramienta libre TALEND OPEN STUDIO (Apéndice B), la cual entre
sus funcionalidades permite el diseñar un ETL desde varias perspectivas y
configuraciones, se dividió en cuatro etapas las cuales fueron:
10.1 Carga de datos a las dimensiones principales:
Como primera parte se procede a la carga de las dimensiones (Dim_docente,
Dim_fecha_producto, Dim_producto, Dim_proyecto_curricular, Dim_tiempo,
Dim_evaluador), para ello es necesario ejecutar cada Talend-Job (tablas 10 - 14) por
separado.
Tabla 10: Carga de datos dim_docente
Dim_docente:
Libro docente:
39
Capítulo de libro:
Revista indexada:
Dim_docente:
Ponencia:
Fuente: (Autores)
40
Tabla 11: Carga de datos dim_fecha_producto
Dim_fecha_producto:
Libro docente:
Capítulo de libro:
Revista Indexada:
Ponencia:
Fuente: (Autores)
Tabla 12: Carga de datos dim_producto
Dim_producto
Libro docente:
41
Capítulo de libro:
Revista Indexada:
Ponencia:
Fuente: (Autores)
Tabla 13: Carga de datos dim_proyecto_curricular
Dim proyecto curricular:
Libro docente:
42
Capítulo de libro
Revista indexada:
Ponencia:
Fuente: (Autores)
Tabla 14: Carga de datos dim_tiempo
Dim tiempo
Libro docente:
43
Capítulo de libro:
Revista Indexada:
Ponencia:
Fuente: (Autores)
10.2 Carga de datos a las dimensiones derivadas
Se realizó la carga de dim_evaluador con base a los datos ya cargados de la dimensión
dim_producto.
Tabla 15: Carga de datos dim_evaluador
Dim_evaluador:
Libro docente:
44
Capítulo de libro:
Fuente: (Autores)
10.3 Carga de Hechos
Una vez cargadas todas las dimensiones, se realizó la carga de los hechos también por
separado
Tabla 16: Carga de datos Hecho_nuevo_producto
Hecho nuevo producto:
Libro Docente:
Capítulo de libro:
45
Revista Indexada:
Ponencia:
Fuente: (Autores)
10.4 Unificar Talend-Jobs:
Una vez la carga de datos por separado es exitosa, se unifican en un solo talend-job.
Unificar Talend-Jobs:
Tabla 17: Union de Talend_jobs
Union dim docente
Union dim fecha producto
46
Union dim producto
Unión dim proyecto curricular
Unión dim tiempo
Union dim evaluadores:
Hechos_union
Unión final
Fuente: (Autores)
47
CAPÍTULO 11. ESPECIFICACIÓN Y DESARROLLO DE APLICACIONES DE BI
Para el caso particular del proyecto se utilizó SpagoBi (Apéndice C), una
plataforma Open Source, con la finalidad de satisfacer las necesidades de análisis de
datos del proyecto por medio de las herramientas que tiene, en este caso los reportes
estructurados tipo BIRT (herramienta de reportes open source para Java),
específicamente los reportes Chart.
Según la metodología, este tipo de reportes se encuentra dentro del conjunto de
Informes Estándar, al tener parámetros de consulta fijos.
11.1 Elaboración
Los reportes se elaboraron por medio de la información obtenida por Querys SQL,
la cual se representó en los gráficos tipo Chart. Esta herramienta de reportes permitió
agrupar la información, según las necesidades del proyecto, se agrupó por año,
específicamente información de los últimos 10 años. (Ilustración 12 – 17).
11.2 Querys Utilizados
Datos correspondientes a los 3 últimos años acerca de: Número de libros
elaborados por los profesores como producto de la investigación por año/ número
de profesores de tiempo completo y medio tiempo en TCE.
Ilustración 12: Query - Libros de Investigación Elaborados, Fuente: (Autores)
o Donde producto_tipo_id = 1, hace referencia a un libro de investigación.
48
Datos correspondientes a los 3 últimos años acerca de: número de artículos
elaborados por los profesores en revistas internacionales indexadas por año /
número de profesores de tiempo completo y medio tiempo en TCE.
Ilustración 13: Query - Artículos elaborados en Revistas Indexadas Internacionales, Fuente: (Autores)
o Donde contexto_id = 2, hace referencia a un contexto internacional
Datos correspondientes a los 3 últimos años acerca de: número de artículos
elaborados por los profesores en revistas nacionales indexadas por año / número
de profesores de tiempo completo y medio tiempo en TCE.
Ilustración 14: Query - Artículos elaborados en Revistas indexadas Nacionales, Fuente: (Autores)
o Donde contexto_id = 1, hace referencia a un contexto nacional.
Datos correspondientes a los 3 últimos años acerca de: número de artículos
elaborados por los profesores en revistas especializadas nacionales e
internacionales por año / número de profesores de tiempo completo y medio
tiempo en TCE.
Puesto que para este requerimiento es necesaria la información relacionada
a la especialidad de la revista indexada, es imposible el efectuar esta necesidad
49
de información ya que el dato fundamental (especialidad de la revista), no se
encuentra en el modelo de datos KYRON.
Datos correspondientes a los 3 últimos años acerca de: número de ponencias en
versión completa, publicadas por los profesores, por año / número de profesores
de tiempo completo y medio tiempo en TCE.
Ilustración 15: Query - Ponencias Elaboradas, Fuente: (Autores)
Datos correspondientes a los 3 últimos años acerca de: número de capítulos en
libros publicados por los profesores, por año / número de profesores de tiempo
completo y medio tiempo en TCE.
Ilustración 16: Query - Capítulos de Libro elaborados, Fuente: (Autores)
Datos correspondientes a los tres últimos años, sobre: número de libros de texto
publicados por los profesores, por año / número de profesores de tiempo completo
y medio tiempo en TCE.
50
Ilustración 17: Query - Libros de Texto elaborados, Fuente: (Autores)
o Donde producto_tipo_id = 3, hace referencia a un libro de texto
Observación: Ya que en el modelo de datos KYRON, no se encuentra los datos
sobre, número de profesores de tiempo completo y medio tiempo en TCE, no es posible
representar esta información en los gráficos chart.
51
CAPÍTULO 12. PRUEBAS FINALES
Junto con el Ingeniero Jhon Gabriel Castellanos se verificó la información
generada por los reportes tipo chart, para esto se relacionaron los requerimientos de
información del proyecto en contraste con la información generada por cada uno de los
reportes Ilustración 18 – 23.
Ilustración 18: Reporte Indicador 69, Fuente: (Autores)
52
Ilustración 20: Reporte Indicador 71, Fuente: (Autores)
Ilustración 19: Reporte Indicador 70, Fuente: (Autores)
53
Ilustración 21: Reporte Indicador 73, Fuente: (Autores)
54
Ilustración 22: Reporte Indicador 74, Fuente: (Autores)
55
.
Ilustración 23: Reporte Indicador 75, Fuente: (Autores)
56
Se observó que proporcionan la información solicitada, exceptuando aquella sobre
“número de profesores de tiempo completo y medio tiempo en TCE” y “número de
artículos elaborados por los profesores en revistas especializadas” puesto que dicha
información no se encuentra en el modelo de datos KYRON.
Por otra parte, se nota el contraste entre los reportes estructurados generados a
partir del Datamart y el proceso externo que sigue la Oficina de Docencia para resolver
las necesidades de información expuestas en este proyecto.
Los reportes estructurados permiten que al hacer uso del sistema BI de ATHENEA
se resuelvan las necesidades de información de manera inmediata ya que estos reportes
hacen uso de Querys previamente diseñados, en cambio el proceso externo de la Oficina
de Docencia resuelve esta información en el transcurso de 7 a 15 días, teniendo en
cuenta los riesgos de seguridad de la información a los que está expuesto además de
que este tiempo depende de la carga de trabajo que tenga esta dependencia.
57
CAPÍTULO 13. CONCLUSIONES
Se realizó el análisis, diseño y desarrollo del Datamart docentes, utilizando como
fuente todos los datos del sistema de gestión de información docente KYRON,
contemplando las tecnologías (libres) y los estándares que utiliza la bodega de
datos del sistema de Información ATHENEA de la Universidad Distrital Francisco
José de Caldas.
El sistema de Información ATHENEA, adquirió la capacidad para evaluar y analizar
el conocimiento general relacionado sobre toda la producción intelectual de los
docentes a raíz del desarrollo del Datamart, puesto que es una base sólida de
información para la consulta, análisis y toma de decisiones empresariales.
Por medio de la herramienta Talend, se desarrolló el proceso de extracción,
transformación y carga de datos, desde KYRON hacia el Datamart docente.
Se solventaron las necesidades de Información del proyecto, (Factor 03 -
Indicadores 69, 70, 71, 73, 74, 75, Modelo de Acreditación Institucional), sin
contemplar información relacionada sobre número de profesores de tiempo
completo y medio tiempo en TCE, puesto que dicha información no existe en
KYRON.
La necesidad de Información del proyecto, (Factor 03 – indicador 72, Modelo de
Acreditación Institucional), no se solventó puesto la información relacionada con
esta, no existe en KYRON.
A raíz de las limitantes de Información por parte del sistema fuente de datos del
Datamart (KYRON), las necesidades de información del proyecto se solucionaron
en un 85%.
Se realizó la documentación respectiva del Datamart docentes, siguiendo los
lineamientos expuestos en la metodología asegurando claridad y precisión en su
desarrollo.
Se estableció el ciclo de vida de los datos de acuerdo a la metodología desde la
planificación hasta las respectivas pruebas.
Las necesidades de información solventadas, se efectuaron por medio de reportes
tipo BIRT creados por medio de la plataforma Business Intelligence Spagobi.
58
Por medio de los reportes desarrollados (Factor 03 - Indicadores 69, 70, 71, 73,
74, 75, Modelo de Acreditación Institucional), es posible analizar, dar control y
seguimiento sobre la producción intelectual docente de los últimos 10 años.
El proceso que sigue la oficina de docencia para resolver las necesidades de
información docente del modelo de acreditación institucional desde el momento en
que la información es solicitada, presenta un tiempo de respuesta entre 7 a 15
días, en cambio con los reportes generados través del sistema BI de ATHENEA
haciendo uso del Datamart la respuesta es de manera inmediata.
El Datamart docente desarrollado contribuye a elevar el nivel académico del
profesorado de la universidad, comprendiendo la situación actual de la frecuencia
de producción intelectual, y gracias a esto tener la capacidad de desarrollar
estrategias para promover el desarrollo intelectual en producciones poco
abordadas por los docentes.
Los reportes estructurados permiten controlar y verificar la información generada
de una manera eficaz, en contraste con el proceso manual de la Oficina de
Docencia en el cual la seguridad de la información se encuentra altamente
vulnerable al seguir un proceso de manipulación y selección de datos para su
presentación efectuado por terceras personas.
59
CAPÍTULO 14. RECOMENDACIONES
Frente a las limitantes de Información evidenciadas en el desarrollo de este proyecto
recomienda los siguientes aspectos:
Complementar la dimensión dim_docente, con un atributo que haga referencia a
la característica tiempo completo y medio tiempo en TCE, con la finalidad de
evidenciar esta información en los reportes de los indicadores 69, 70 ,71, 73, 74,
75.
Incluir en el sistema ETL propuesto, una fuente de información de la cual permita
identificar la característica tiempo completo y medio tiempo en TCE, de los
docentes.
Implementar una nueva versión de la tabla del modelo KYRON “revista_indexada”,
de la cual se permita obtener información sobre la “especialidad” de la publicación
en la revista para así, resolver la necesidad de información del factor 03 – Indicador
72, del modelo de acreditación institucional.
60
CAPÍTULO 15. TRABAJOS FUTUROS
Con el desarrollo del Datamart docentes contemplando toda la información del sistema
de gestión de información docente KYRON, se propone incluir nuevas aplicaciones
Business Intelligence, de las cuales se permita analizar, dar control y seguimiento a un
amplio espectro de información relacionada sobre los distintos tipos de producción
intelectual docente en conjunto de los que son objeto de este proyecto.
61
CAPÍTULO 16. BIBLIOGRAFÍA
[1] Ralph Kimball, dan Margy Ross, The Data Warehouse Toolkit., New
York:John Wiley and Sons, Inc., 2002.
[2] L. Sapir, A. Shmilovici and L. Rokach, "A methodology for the design of a
fuzzy data warehouse," 2008 4th International IEEE Conference Intelligent Systems,
Varna, 2008, pp. 2-14-2-21.
[3] Gustavo R. Rivadera, “La metodología de Kimball para el diseño de
almacenes de datos (Data warehouses)”, [email protected] ,2011.
[4] L. Yessad and A. Labiod, "Comparative study of data warehouses modeling
approaches: Inmon, Kimball and Data Vault," 2016 International Conference on System
Reliability and Science (ICSRS), Paris, 2016, pp. 95-99.
[5] Mundy & Thornthwaite, The Microsoft DataWarehouse Toolkit—With
SQL Server 2005 and the Microsoft Business Intelligence Toolset, Indianapolis.
[6] Wiley, 2006. Y. Ruldeviyani and B. Mohammad, "Design and
implementation of merchant acquirer data warehouse at PT. XYZ," 2016 International
Workshop on Big Data and Information Security (IWBIS), Jakarta, 2016, pp. 47-50.
[7] Azuaje, “INFORME TECNICO-Metodología de Kimball.”, Universidad central
de Venezuela-facultad de ciencias-escuela de computación-inteligencia de negocio,
CARACAS, DICIEMBRE 2014.
[8] The PostgreSQL Global Development Group, “PostgreSQL 9.6.3
Documentation”, https://www.postgresql.org/docs/,1996-2017
[9] Geotap, “ETL con Talend (Integración de aplicaciones)“,
http://geotapgroup.com/etl-con-talend-integracion-de-aplicaciones/, 2012
[10] Majchrzak, Tim A. Jansen, Tobias; Kuchen, Herbert, “Efficiency evaluation
of open source ETL tools”, Proceedings of the ACM Symposium on Applied Computing,
p 287-294, 2011, 26th Annual ACM Symposium on Applied Computing, SAC 2011
[11] Oficina Asesora De Sistemas. Universidad Distrital FJDC, «Plan
Maestro de Informática y Telecomunicaciones,» Universidad Distrital, Bogotá, 2012.
[12] Stratebi Open Business intelligence, Spago BI,
http://www.stratebi.com/spagobi, Madrid, 2017
62
[13] Dedić N. & Stanier C. (2016). Measuring the Success of Changes to Existing
Business Intelligence Solutions to Improve Business Intelligence Reporting. Lecture
Notes in Business Information Processing. Springer International Publishing.
[14] Sinergia e Inteligencia de Negocio S.L. (2016). Business Intelligence,
http://www.sinnexus.com/business_intelligence/datawarehouse.aspx
[15] Universidad Distrital Francisco Jose De Caldas - Consejo Superior
Universitario, Estatuto General Acuerdo Nº003 (Abril 8 de 1997),
http://sgral.udistrital.edu.co/xdata/csu/acu_1997-003.pdf
[16] Oficina Asesora de Sistemas. Universidad Distrital, «Portal de Inteligencia
de Negocios,» Universidad Distrital, Bogotá, 2016.
[17] Maxim Rudensky, Valentine Danilchuk, mysql2pgsql.perl,
Https://github.com/openstreetmap/Nominatim/blob/master/mysql2pgsql/
63
APÉNDICES
Apéndice A: PostgreSQL.
PostgreSQL es un Sistema Gestor de Bases de Datos Relacional (ORDBMS)
objeto-relacional de código abierto, inicialmente creado como Post Ingres para solucionar
problemas existentes de las bases de datos que existían a mediados de los 80. Es
totalmente compatible con ACID (Son las siglas de atomicidad, consistencia, aislamiento,
durabilidad; Conjunto de 4 propiedades que garantizan que las transacciones en las
bases de datos se realicen de forma confiable). [8]
Incluye una biblioteca de funciones estándar con cientos de funciones integradas
que van desde las operaciones matemáticas básicas, operaciones con strings para
criptografía y compatibilidad con Oracle. Los disparadores (triggers) y procedimientos
almacenados pueden ser escritos en C y se cargan en la base de datos como una
biblioteca, lo cual permite una gran flexibilidad y ampliación de sus capacidades. Del
mismo modo, PostgreSQL incluye un framework que permite a los desarrolladores definir
y crear sus propios tipos de datos personalizados. Como resultado, una gran cantidad de
tipos de datos avanzados se han creado que van desde los geométricos y espaciales
para direcciones de red, incluso para los tipos de datos ISBN / ISSN (International
Standard Book Number / Número Internacional Normalizado de Publicaciones Seriadas),
los cuales pueden ser opcionalmente agregados al sistema.
PostgreSQL cuenta con una funcionalidad distinguible de otros sistemas gestores,
la cual es el control de concurrencia multi-versión (MVCC), que permite hacer
transacciones consistentes, con lo cual se incrementa el rendimiento del sistema.
Existen otras características en PostgreSQL como por ejemplo la llamada Hot-
Standby, la cual permite hacer búsquedas en los servidores mientras éstos se encuentran
en espera o en recuperación, por lo que no se requiere hacer bloqueo completo al sistema
para realizar tareas de mantenimiento.
Otras características que valen la pena remarcar son: PostgreSQL incluye la
herencia entre tablas haciéndolo un gestor de bases de datos objeto-relacional, realiza
copias de seguridad en “caliente” (Online/hot backups) siendo esto muy útil a no necesitar
64
deshabilitar toda la base de datos a la hora de hacer un backup, tiene múltiples métodos
de autenticación, a pesar de ser una herramienta de software libre posee una
documentación muy completa aunque por obvias no tiene soporte por una empresa como
tal.
Este sistema de bases de datos ofrece la posibilidad de definir funciones
personalizadas como PL/Perl, PL/PHP, PL/pgSQL, entre otras. Se encuentra disponible
para muchas plataformas tales como Solaris, Windows, Ubuntu, etc., y cualquier usuario
tiene a disposición el código fuente. [8].
Apéndice B: Talend
Ante la necesidad de integrar los diferentes sistemas que al paso del tiempo se
van imponiendo, surge el concepto de ETL (Extract, Transform and Load («extraer,
transformar y cargar»)), Los ETL son herramientas específicas para manejar y
transformar datos, así la aplicación de un ETL es la integración de sistemas que
intercambian datos. [9] [10].
Talend Open Studio (TOS) es una herramienta ETL Open source es
multiplataforma y con características visuales tanto para su desarrollo como su
despliegue. Pudiendo ejecutar desde cualquier sistema que permita la ejecución de Java.
Ofrece el permitir que los datos puedan ser leídos de múltiples fuentes y controlar las
posibles transformaciones que en el transcurso del proceso puedan sufrir los datos.
Talend Open Studio se encuentra entre las herramientas de código abierto más
completas y maduras en la actualidad respecto al rendimiento que presenta [10].
Apéndice C: Spagobi
Es una Multiplataforma de código abierto desarrollada para la Inteligencia de
negocios (Business Intelligence). Cumple con las necesidades de BI en cuestiones de
análisis, gestión de datos, administración y seguridad. En cuestiones de análisis brinda:
Presentación de informes
Análisis multidimensional (OLAP).
65
Minería de datos (Data Mining),
Tableros de mando (Dashboard)
Consultas ad-hoc.
Además de estas características posee herramientas ETL (extracción de datos,
transformación y carga). SpagoBI cuenta con la capacidad de limitar la visibilidad de los
datos en vínculo con los roles de los usuarios finales, así mismo tiene una estructura
modular la cual permite garantizar la unidad de la plataforma, así como su capacidad
evolutiva al tener todos los módulos relacionados con el núcleo del sistema.
Integra motores de análisis específicos para cada área (informes o reportes,
OLAP, tablero de mando o dashboard, minería de datos, etc.) y permite el uso de varios
motores de análisis al mismo tiempo (reportes o informes de varios motores al mismo
tiempo, la minería de datos en varios motores al mismo tiempo, etc.).
SpagoBI solo tiene una versión la cual es gratuita, esta plataforma es capaz de
regular la visibilidad en los datos de acuerdo a las exigencias y responsabilidades
empresariales, también cuenta con una arquitectura escalable que continúa en la lógica
del software libre.
SpagoBI al ser una plataforma de integración no se limita a un conjunto predefinido
de herramientas Tiene una configuración estructural modular en la cual todos los módulos
van relacionados al núcleo del sistema, esto respalda la armonía de la plataforma junto
con su capacidad evolutiva. Características:
Reporting: Crear informes personalizados y exportables al formato más adecuado
(HTML, PDF, XLS, XML, TXT, CSV, RTF)
Análisis multidimensional (OLAP): Explora los datos con diferentes ejes de análisis
y diferentes niveles de detalle.
Charts: Desarrollo de gráficos personalizables (histograms, pie charts, bar charts,
are charts, scatter diagrams, linea charts, bubble charts, dispersion charts) e
interactivos.
KPIs: SpagoBI ofrece un conjunto completo de herramientas para crear,
administrar, visualizar KPI, a través de diferentes métodos, reglas de cálculo,
umbrales y alarmas.
66
Interactive cockpits: Análisis de la información agregada en una sola vista, estable
las rutas de navegación, y permite explotar sus datos de manera dinámica y
gráfica.
Ad-hoc reporting: Permite al usuario crear sus propios informes de varias páginas,
incluyendo tablas, tablas cruzadas y gráficos.
Location Intelligence: Posibilidad de analizar sus datos de negocio con mapas e
interactuar de forma dinámica.
Free Inquiry: Es un motor para hacer la exploración y navegación de datos de una
manera intuitiva y fácil, gracias a una interfaz totalmente gráfica y web.
Data mining: Permite extraer conocimiento, descubrir patrones a partir de grandes
volúmenes de datos, para mejorar la toma de decisiones y estrategias de negocio.
ETL: SpagoBI integra Talend Open Studio para la creación de los procesos ETL
(extracción, transformación y carga de datos).
Collaboration: Crear dossier de informes estructurados, enriquecer el análisis con
notas personales y los comentarios publicados por los usuarios. A continuación,
compartirlos a través de un flujo de trabajo colaborativo.
Office automation: Publique sus documentos personales en el entorno BI,
integración con herramientas ofimáticas (Openoffice o MS Office).
Masterdata management: Los usuarios pueden escribir directamente en la base
de datos, añadiendo nuevos registros o modificando los existentes a través de una
interfaz de usuario intuitiva, cuyo comportamiento se puede configurar mediante
una configuración simple, utilizando modelos predefinidos.
External processes: Dispone de un panel para administrar los procesos de análisis,
puede ejecutarse en segundo plano o ser programados para iniciar y detener a
una hora programada.” [12].
67
Apéndice D: Modelo de datos relacional KYRON
Ilustración 24: Modelo de datos relacional KYRON Fuente: (Autores)
68
Apéndice E: Entregables significativos (BUS MATRIX, Modelo Dimensional)
considerando todo el modelo de datos KYRON.
Bus Matrix
Ilustración 25: Bus Matrix Fuente: (Autores)
69
Modelo dimensional
Nueva Producción
Ilustración 26: Modelo Dimensional - Hecho nueva producción. Fuente: (Autores)
70
Nueva Experiencia Excelencia
Ilustración 27: Modelo Dimensional - Hecho nueva experiencia excelencia Fuente: (Autores)
71
Nueva observación
Ilustración 28: Modelo Dimensional - Hecho nueva observación. Fuente: (Autores)
72
Apéndice F. Identificación de atributos de dimensiones y tabla de hechos
dim_docente
Ilustración 29: Identificación de atributos dim_docente,
Fuente: (Autores)
73
Dim_tiempo
Ilustración 30: Identificación de atributos dim_tiempo, Fuente: (Autores)
74
Dim_fecha_producto
Ilustración 31: Identificación de atributos dim_fecha_producto,
Fuente: (Autores)
75
Dim_proyecto_curricular
Ilustración 32: Identificación de atributos dim_proyecto_curricular,
Fuente: (Autores)
76
Dim_evaluador
Ilustración 33: Identificación de atributos dim_evaluador,
Fuente: (Autores)
77
Dim_producto
Ilustración 34: Identificación de atributos dim_producto, Fuente: (Autores)
78
Hecho_nuevo_producto
Ilustración 35: Identificación de atributos hecho_nuevo_prroducto, Fuente: (Autores)
