diseÑo e implementaciÓn de un datamart para las...

DISEÑO E IMPLEMENTACIÓN DE UN DATAMART PARA LAS NOTAS HISTÓRICAS DE LOS ESTUDIANTES EN LA UNIVERSIDAD DISTRITAL

FRANCISCO JOSÉ DE CALDAS

AUTORES:

FABIAN ANDRES VALDERRAMA TRIVIÑO ARNOLD STIVEN GARCES BOHADA

PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS

DIRECTOR:

ING. ALEJANDRO PAOLO DAZA

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS

Bogotá D.C, 2018

TABLA DE CONTENIDO

CAPÍTULO 1. INTRODUCCIÓN ........................................................................................ 7

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA ......................................................... 8

CAPÍTULO 3. OBJETIVOS .............................................................................................. 10

3.1 Objetivo General .................................................................................................... 10

3.2. Objetivos Específicos ............................................................................................ 10

CAPÍTULO 4. JUSTIFICACIÓN ....................................................................................... 11

CAPÍTULO 5. MARCO TEÓRICO.................................................................................... 13

5.1. Inteligencia de Negocios ....................................................................................... 13

5.2. Bodega de datos ................................................................................................... 15

5.2.1 Datamart ......................................................................................................... 17

5.2.1.3. Características de un Datamart .................................................................... 19

5.2.2. Tabla de hechos. ............................................................................................ 20

5.2.3 Dimensiones .................................................................................................... 21

5.3 Proceso de Extracción, Transformación y carga de datos (ETL) ............................ 22

5.3.1 Extracción ........................................................................................................ 22

5.3.2. Transformación de Datos ................................................................................ 23

5.3.3 Carga de Datos ................................................................................................ 23

5.4. Herramientas de Desarrollo y Diseño .................................................................... 24

5.4.1 Talend Open Studio ......................................................................................... 24

5.4.2. SpagoBI .......................................................................................................... 26

CAPÍTULO 6. ALCANCES Y LIMITACIONES.................................................................. 28

6.1. Alcances ................................................................................................................ 28

6.2. Limitaciones .......................................................................................................... 28

CAPÍTULO 7. METODOLOGÍA ....................................................................................... 29

7.1. Iteración 1....................................................................................................... 30

7.1.1. Visión de la arquitectura de BI ................................................................. 30

7.1.2. Diagrama de procesos ................................................................................... 33

7.1.3. Viabilidad del proyecto ................................................................................... 36

7.1.4. Patrocinio ....................................................................................................... 36

7.1.5 Estudio de Factibilidad .................................................................................... 36

7.1.6. Alcance ........................................................................................................... 40

7.1.7. Comité de proyecto ......................................................................................... 40

7.1.8. Diagrama WBS ............................................................................................... 41

7.1.9. Plan de comunicaciones ................................................................................. 41

7.2. Iteración 2....................................................................................................... 45

7.2.1 Requerimientos del negocio ...................................................................... 45

7.2.1.1 Identificación de los Requerimientos ................................................... 46

7.2.2. MODELO DE NEGOCIO .......................................................................... 49

7.3. Iteración 3....................................................................................................... 51

7.3.1 Diseño de la matriz Dimensiones VS Procesos de Negocio ............................. 51

7.3.2 Matriz Impacto VS Factibilidad ......................................................................... 53

7.4. Iteración 4 ............................................................................................................. 55

7.4.1 EVALUACIÓN DE SOFTWARE .......................................................................... 55

7.5. Iteración 5....................................................................................................... 58

7.5.1 Modelado Dimensional..................................................................................... 58

7.5.1.1 Modelo dimensional Conceptual ................................................................... 58

7.5.2 MODELO LÓGICO DEL DATAMART. ............................................................. 59

7.5.3 Modelo dimensional Lógico .............................................................................. 64

7.5.4 Componente ETL de Talen Open Studio ......................................................... 65

7.6. Iteración 6....................................................................................................... 69

7.6.1 Dominio de Aplicaciones .................................................................................. 69

7.6.1.1 Estructura General ........................................................................................ 69

7.6.1.2 Reportes e Indicadores ................................................................................. 69

7.6.1.3 Estructura de los Reportes e Indicadores ...................................................... 70

7.6.1.4 Reportes Notas Estudiantes Por Año ............................................................ 71

7.6.1.5 Diseño de la tabla ......................................................................................... 71

7.6.2 BD en Postgrest ............................................................................................... 73

7.8. Iteración 8....................................................................................................... 74

CAPÍTULO 8. RECURSOS .............................................................................................. 75

8.1 Recursos del Proyecto ........................................................................................... 75

CAPÍTULO 9. CRONOGRAMA ........................................................................................ 76

CAPÍTULO 10. CONCLUSIONES ................................................................................... 77

CAPÍTULO 11. BIBLIOGRAFÍA ....................................................................................... 79

Índice de Figuras Figura 1. Modelo sistémico, proceso de inteligencia de negocio. Figura 2. Modelo de un Datamart. Figura 3. Datamart Dependiente. Figura 4. Datamart Independiente. Figura 5. Modelo dimensional. Tabla de hechos y dimensiones. Figura 6. Modelo Conectividad de Talend Studio. Figura 7. Modelo Migración Talend Studio. Figura 8. Modelo de la Metodología de Kimball. Figura 9. Metodología Kimball. Figura 10. Arquitectura general Oficina Asesora de sistemas. Fuente: OAS. Figura 11. Arquitectura BI propuesta. Figura 12. Diagrama de Procesos para la integración de datos. Figura 13. WBS del proyecto. Figura 14. Construcción de los requerimientos. Figura 15. Matriz de Impacto vs Factibilidad. Figura 16. Modelo dimensional conceptual: Notas históricas. Figura 17. Modelo Dimensional Lógico- Notas históricas. Figura 18. Modelo de ETL – Notas Históricas. Figura 19. Carga de la dimensión asignatura – Talend open Studio. Figura 20. Mapeo de datos asignatura – Talend open Studio. Figura 21. Carga de la dimensión Estudiante – Talend open Studio. Figura 22. Mapeo de Datos Estudiante – Talend open Studio. Figura 23. Carga tabla de hechos Notas – Talend open Studio. Figura 24. Mapeo de Datos Tabla de Hechos – Talend open Studio. Figura 25. Tabla Reporte de estudiantes - notas. Figura 26. Reporte en SPAGO BI del estudiante. Figura 27. Reporte en SPAGO BI del estudiante - Implementación. Figura 28. Query - Guardar estudiante – Talend open Studio. Figura 29. Query – Generar reporte de notas – Talend open Studio.

Índice de Tablas Tabla 1. Cuadro comparativo de un DataWarehouse y un Datamart. Tabla 2. Proceso de extracción de la información Tabla 3. Proceso de creación del ETL Tabla 4. Proceso de integración entre el ETL y el Datamart Tabla 5. Proceso de modelado de las BD Tabla 6. Presupuesto Proyecto, recurso humano. Tabla 7. Presupuesto Proyecto Total. Tabla 8. Acciones de comunicación: negocio. Tabla 9. Acciones de comunicación: requerimientos. Tabla 10. Acciones de comunicación: socialización. Tabla 11. Acciones de comunicación: entendimiento. Tabla 12. Acciones de comunicación: reuniones periódicas. Tabla 13. Planificación por fechas. Tabla 14. Requerimiento funcional: Reporte. Tabla 15. Requerimiento funcional: Reporte. Tabla 16. Requerimiento funcional: Reporte. Tabla 17. Requerimiento No funcional: Información. Tabla 18. Requerimiento No funcional: Desempeño. Tabla 19. Requerimiento No funcional: hardware. Tabla 20. Matriz dimensiones vs Procesos de Negocio. Tabla 21. Matriz evaluación de productos. Tabla 22. Matriz evaluación de productos. Tabla 23. Dimensión Asignatura. Tabla 24. Dimensión Estudiante. Tabla 25. Tabla de Hechos Notas. Tabla 26. Recursos requeridos en el proyecto. Tabla 27. Cronograma de Actividades.

CAPÍTULO 1. INTRODUCCIÓN En la actualidad y dadas las necesidades generadas de la globalización y la gestión del conocimiento la información que aparentemente no representaba nada ahora es el mayor activo en la organizaciones públicas y privadas. Pero ya desde los años 50 se empezaba a crear el concepto de inteligencia de negocios y la importancia de lograr una sinergia entre los procesos computacionales y los procesos administrativos, que eran considerados mutuamente excluyentes. A medida de que el análisis de información fue tomando fuerza empezaron a ser fuertes los procesos que convertían los grandes volúmenes de datos en información medible y entendible por las áreas de negocios, que era entre otras cosas convertir el lenguaje de maquina a un lenguaje comprensible por las personas apoyando la toma de decisiones. Con ello toma fuerza conceptos como inteligencia de negocios, DataWarehouse, Datamarts, ETL´s, modelos dimensionales. Es desde esta perspectiva que se tomó en consideración el mejorar los procesos de alojamiento y consulta de notas históricas en la Universidad Distrital. Para esto, se aplicó la Tecnología de Business Intelligence, el cual se consideró como punto principal y necesario la creación de un Datamart específico a la consulta de notas históricas que se encuentran en medio físico y con la diseño del modelo dimensional que comprende un mejoramiento sustancial en la consulta de la información. Dicha información que se tomará para la creación del Datamart se transformará en conocimiento y así lograr una visión clara del compendio de notas históricas que hasta el momento están en físico. En todo trabajo con éxito siempre existe una buena visualización detallada de su información, esto quiere decir que tener un exceso de datos no significa un éxito asegurado, sino, el conocer claramente su información lo es. Gracias a este tipo de informes detallados de temas específicos es que se dan las buenas decisiones y mejoras en todo aspecto. Este proyecto permitirá que los procesos manuales presentes en la consulta de notas históricas de la Universidad Distrital deje de ser un proceso arduo y arcaico, para convertirse en un insumo para el modelo dimensional y la visualización de información apoyando la toma de decisiones.

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA La Universidad Distrital Francisco José de Caldas, dedicada al estudio, la investigación y la difusión del saber y la cultura, fundada en 1950 de origen público con el fin de ser la Universidad del Distrito Capital generando inclusión social y académica distribuyendo sus facultades sobre toda la metrópolis requirió que las notas históricas de sus estudiantes que están en medio físico dentro del archivo, sean digitalizadas para consultas de la información más eficientes. Actualmente todas las notas históricas de la Universidad Distrital se encuentran alojadas en libros que están distribuidos por años. En cada libro se evidencian los estudiantes inscritos para ese periodo en específico y la asociación de cada materia vista con su respectiva calificación, además de la firma del profesor. Así que cada consulta de una calificación asociada a una materia y esta a su vez asociada a un estudiante se vuelve tediosa e ineficiente. Desde el año 2009, la Oficina Asesora de Sistemas (OAS) de la Universidad Distrital, ha venido adelantando el proyecto de “Sistema Informático Integrado de Información”, el cual está conformado por los subproyectos de Bodega de Datos y de Inteligencia de Negocio, cuyos objetivos son (Universidad Distrital, 2011): - “Un Repositorio Único, Sincronizado y no volátil de la Información: en donde los datos ingresen siguiendo reglas de carga, filtrado, extracción, previo procesamiento y análisis heurístico que se diseña a partir del análisis de los procesos del dominio, reglas de calidad y seguridad de la información garantizando un repositorio consolidado, confiable, íntegro y de alta disponibilidad que permita a los actores tener una visión compartida y única, tanto para el apoyo en la toma de decisiones como para la rendición de cuentas en procesos de autoevaluación, coevaluación, heteroevaluación, control y auditoría”. - “Un sistema de Orientación Temática: todos los datos deben estar organizados de acuerdo a los procesos estratégicos y misionales de la institución. Con ello, el sistema tiene la capacidad de dar respuesta a preguntas específicas de cada tema considerando la interrelación de procesos, información y datos”. - “Un sistema que garantice y preserve las características de Integridad, confidencialidad, confiabilidad y disponibilidad de la información e institucional.

La falta de centralización de los procesos en la Universidad causa un rompimiento en la sinergia que va orientada hacia el cumplimiento de la misión y la visión, con ello también se pierden los objetivos. El compilado de notas históricas hace parte de ese desmembramiento de los procesos, ya que son consultadas de manera manual cada vez que se solicite, y no están soportados en ninguna BD de la Universidad. Además si por alguna razón estos libros se perdieran o sufrieran algún tipo de daño no habría soporte de que existieron ni de las notas allí evidenciadas.

CAPÍTULO 3. OBJETIVOS 3.1 Objetivo General Diseño e implementación de un Datamart que contenga la información concerniente a las notas históricas de la Universidad Distrital Francisco José de Caldas de manera digital orientado hacia la inteligencia de negocios y a la eficiencia de los procesos internos de la Universidad con respecto a consultas y visualización de información. 3.2. Objetivos Específicos

Determinar los requerimientos necesarios para la elaboración y explotación del Datamart.

Definición captura de información (fuente Excel, Imágenes) con la finalidad de probar el Datamart con una carga inicial de 400 registros.

Definir el modelo dimensional del Datamart para la representación de información de notas históricas.

Abstraer y analizar los atributos medibles del proceso para realizar la tabla de hechos que sostiene el modelo en estrella dimensional.

Abstraer las dimensiones concernientes al área de negocio que complementen el modelo.

Elaborar los procedimientos para la Extracción, transformación y carga de datos (ETL) en el Datamart a través de la herramienta Talend Studio.

Diseños reportes en SPAGO BI donde se visualizara la información resultante del Datamart

CAPÍTULO 4. JUSTIFICACIÓN En la Universidad Distrital Francisco José de Caldas una gran cantidad de procesos están apoyados en sistemas de información académico-administrativos, de desarrollos propios o desarrollados por terceros. Estos sistemas son eficaces en cuanto al soporte de actividades operativas de la institución, pero, debido a su naturaleza transaccional y al tipo de desarrollo, presentan pobre desempeño cuando son sometidos a rutinas de procesamiento analítico de datos por parte de usuarios no expertos; por ejemplo seguimiento histórico de datos e indicadores, consultas temáticas, consolidados gráficos, proyecciones, inferencias, por parte tanto de los directivos y como de los organismos de seguimiento y control. A principios del año 2008 la Contraloría de Bogotá entregó el Informe de Auditoría Gubernamental con Enfoque Integral – Modalidad Regular; con el cual se daba cuenta de la primera fase de auditoría efectuada a la Universidad Distrital. En este informe el órgano de control concluía que en la Institución (Universidad Distrital, 2011): “La carencia de un sistema de información integral obstaculiza el acceso a la memoria institucional para la interrelación de las diferentes dependencias. Se observó desorganización en los archivos y la existencia de documentación sin clasificar ni archivar, a pesar de que la Universidad implementó acciones tendientes a conservar la memoria institucional... la falta de implementación del sistema de información no permite el control de las actividades financieras, contables y presupuestales, hecho que ha conllevado a la Universidad a que la información presentada sea diferente y al carecer de la validación de la misma, por contar con información manual y en hojas Excel.” Hecho que ya había sido determinado a partir de autoevaluaciones institucionales realizadas por la misma Oficina Asesora de Sistemas, en las cuales se concluía que: “La UD. requiere de un Sistema de Información Integrado, el cual le permita la armonización de dicha información con todas las dependencias, tanto administrativas como académicas, así como la interacción adecuada de estudiantes, docentes y administrativos con miras, al mejoramiento en el cumplimiento de las políticas generales de la Universidad. Por otro lado, aunque de manera desorganizada se han ido adquiriendo y desarrollando herramientas computacionales que nos permiten poder organizar nuestros propios Sistemas de Información y de Comunicaciones no se ha podido hacer un mejor uso de la tecnología adquirida. “

“Los procesos de la Universidad Distrital están parcialmente automatizados; la información de aquellos procesos que no están considerados en el sistema de información institucional no se encuentra identificada, clasificada y analizada. Así, las tareas de agregación, consolidación y generación de informes presentan grandes dificultades. La sincronización de la información guardada se realiza de forma manual o semi-automatizada, lo que genera redundancia y no integridad en los datos que la Universidad maneja”. “La información que sirve de soporte a aquellos procesos que están por fuera del Sistema de Información transaccional no está debidamente custodiada. Los esquemas de acceso y de manejo de la misma son pobres o están ausentes. Al no existir un inventario completo que identifique y valore los activos de información, ni un medio claro desde el cual la alta dirección institucional pueda extraer reportes que tengan definidos las fuentes, mucha de la información estratégica puede ser accedida por personal no capacitado ni autorizado para utilizar la misma. La fuga de información es un riesgo alto en ese grupo de procesos”. Y su implementación desde el 2009 al 2012 se materializó en una primera versión de un Sistema Integrado de Información a través del Sistema Bodega de Datos y del portal BI, donde se pueden consultar procesos como: presupuesto, nómina, contratación, admisiones, egresados, calidad académica (prueba académica) y matriculados entre otros. Dada las problemáticas generalizadas en la Universidad Distrital y la falta de un sistema Integrado que garantice que los procesos funcionaran de manera eficiente se comienza a tener en cuenta soluciones enfocadas hacia la inteligencia de negocios y con ello nace la idea de un Datamart específico que se centre en la carga, procesamiento y visualización de las notas históricas que se encuentran el archivo agilizando así los procesos de búsqueda y consulta no solo por parte de los estudiantes sino de los funcionarios de la universidad que requieran la información para la toma de decisiones.

CAPÍTULO 5. MARCO TEÓRICO 5.1. Inteligencia de Negocios El concepto de BI (Business Intelligence) se establece hace más de 50 años, ya en este entonces por 1958 en el IBM Journal se publica un artículo de Hans Peter Luhn titulado “A business Intelligence System”. En el expresa los primeros pasos para la organización y canales de comunicación de la información que va orientada a la creación de reportes entendibles desde el área administrativa, en pocas palabras, se trata de convertir una gran cantidad datos que emergen de un proceso organizacional que por sí solos no representan un valor agregado en un concepto que indica resultados y orienta a la toma de decisiones. Según Luhn, para cumplir con estos objetivos era necesaria la aplicación de diferentes técnicas como en su momento lo fueron:

Auto abstracción de documentos. Auto codificación de documentos. Creación y actualización automática de perfiles de usuarios.

Por si solos estos tres procesos no exponen de manera acertiva la inteligencia de negocios como concepto que se maneja en la actualidad. Basta con tomar estos tres procesos para que en sinergia correspondan a una idea más cercana y generalizada. Basados en la abstracción de documentos, se determina que los datos ya dejan de ser textos planos sin interpretación alguna y pasan a tener un sentido más humano, con ello, nos referimos a que la abstracción pasa a ser una representación de la realidad en un contexto dado. Ahora bien, la auto codificación pasa a ser la parte interpretativa de la información, para qué nos sirve, en que ayuda a la organización. Por último se encuentra la creación y actualización de perfiles de usuarios que no es más que la asignación de los datos procesados a las personas que les interesa. No todas las personas en una organización interpretan la información de la misma manera, esta se ajusta a las necesidades específicas del negocio. Según su trabajo, el objetivo del sistema es “proporcionar la información adecuada para soportar actividades específicas realizadas por individuos, grupos, departamentos, divisiones o aun unidades más grandes… estas actividades se deben realizar rápida y eficientemente.”

Como se ha visto, no se trata de un concepto nuevo emergente de las nuevas tecnologías de la información, desde aquel entonces la idea general ha sido a través de los procesos computacionales darle sentido a grandes cantidades de información con el fin de que las personas y entidades relacionadas puedan comprenderla con un valor agregado en la organización, además optimiza los procesos. Dado al avance computacional y tecnológico de los últimos años el concepto de inteligencia de negocios se encuentra más arraigado en las organizaciones, además de más autores dispuestos a aportar en el tema y ahondar en lo que sería la nueva era orientada a la información. No por nada la información pasó de ser un recurso a un activo valioso, y es que no es para menos, la información procesada ofrece la posibilidad de encontrar patrones, de hallar tendencias en los clientes, en el mercado. Desde la perspectiva técnica, para llevar a la práctica la Inteligencia de Negocios, fue necesario integrar varios elementos que hasta entonces estaban separados (años 90’s). Entre estos elementos están las bases de datos de procesamiento transaccional (OLTP), bases de datos analíticas (OLAP), minería de datos, sistemas de generación de reportes y visualización de datos. Así mismo se desarrollaron interfaces de intercambio de datos para permitir la comunicación entre múltiples sistemas operacionales en su objetivo de integrar la información de toda la organización. (IBM, 2000) “La sociedad de la información se refiere a una forma de desarrollo económico y social en el que la adquisición, almacenamiento, procesamiento, evaluación, transmisión, distribución y diseminación de la información con vistas a la creación de conocimiento y a la satisfacción de las necesidades de las personas y de las organizaciones, juega un papel central en la actividad económica, en la creación de riqueza y en la definición de la calidad de vida y las prácticas culturales de los ciudadanos.” (MSIP, 1997) Desde el punto de vista sistémico, la inteligencia de Negocios puede interpretarse como un modelo, con tres elementos claves: entradas, procesos y salidas.

Figura 1. Modelo sistémico, proceso de inteligencia de negocio (Fuente: autores) Las entradas corresponden a la información que emerge de la organización y que es retroalimentada en cada proceso, es en pocas palabras el histórico que alimenta el sistema. El proceso corresponde a la interpretación de la información a través de las herramientas que hoy en día facilitan la tarea como lo son Talen Open Studio y Spago BI. Con ello se realiza una abstracción a la realidad en el contexto organizacional para que la información suministrada no solo este organizada, sino que sea fácilmente obtenida con consultas sencillas. Las salidas son el “Front End” del sistema y es orientada a reportes, informes en la organización, de interpretación que corresponda la modelo del negocio 5.2. Bodega de datos Las bodegas de datos o Data Warehouses como son comúnmente llamados, nacen como una necesidad tangible por los años ochenta para facilitar la consolidación de la información en los sistemas de soporte a la toma de decisiones. Estos son llamados también como sistemas de apoyo a la decisión o DSS (Decision Support Systems) (Daniel, 1999). La idea central era la de cambiar el paradigma sobre los procesos computacionales para hacerlos más humanos, un poco más asequible al usuario final, que entre otras cosas es la persona que conoce el negocio, sabe que información necesita, para que sus procesos sean óptimos y orientados hacia la toma de decisiones dentro de la organización. De esta forma, una bodega de datos permite contener datos integrados y de carácter temático, es decir relativos a procesos particulares del negocio, los cuales son obtenidos de uno o más sistemas operacionales y de uno o más proveedores de información externos, los cuales son almacenados en una base de datos separada. Las principales características de una bodega de datos son las siguientes (Europa Management Consulting, 1996):

Integración. Contiene datos de múltiples sistemas operacionales. Consistencia. En una bodega de datos los datos estarán codificados de forma

consistente. Por ejemplo la letra “m” será siempre el símbolo que indique masculino para el género de una persona.

Organización temática. Los datos están organizados por temas. Por ejemplo ventas, compras, producción, inventario, entre otros, los cuales contienen sólo información relevante para la toma de decisiones.

Franja temporal. Las bodegas de datos contienen información histórica para comparar datos en períodos distintos e identificar tendencias.

No volatilidad. Una vez que los datos han sido cargados en la bodega de datos, éstos no deben ser modificados ni actualizados.

Entre los beneficios que pueden aportar este tipo de aplicación para almacenamiento se pueden mencionar las siguientes:

Se obtiene un acceso más rápido a los datos. Evita la caída en el rendimiento de los sistemas de procesamiento de

transacciones. Se convierten los datos operacionales en información relacionada y

estructurada. Se centraliza y homogeniza la información de gestión, evitando respuestas

distintas a la misma pregunta. Permite la visión global de la información de acuerdo con los conceptos de

negocio que tratan los usuarios. Reduce costos al evitar difíciles procesos de consulta y extracción manual de

información, así como las denominadas “islas de información”. Establece una base única para el modelo de información de la empresa u

organización. De acuerdo con William H. Inmon, una bodega de datos o Data Warehouses es una “colección de datos, orientados a hechos relevantes del negocio, integrados, que incluyen el tiempo como característica importante de referencia y no volátiles para el proceso de toma de decisiones” (Inmon, 1997). Dada la anterior definición, una bodega de datos se acerca más al concepto de sistema de información

Figura 2. Modelo de un Datmart. Fuente: Adaptación Inmon 1996

5.2.1 Datamart 5.2.1.1 Definición Un Datamart son subconjuntos de datos orientados hacia una misma área de negocio, con el fin de ayudar a la toma de decisiones. Un Datamart puede ser alimentado desde los datos de un Data Warehouse, o integrar por sí mismo un compendio de distintas fuentes de información. También es orientado a consulta, es decir, que a través de herramientas por lo general OLAP ofrecen una visión multidimensional de la información. Además de esta definición tenemos diferentes definiciones de que puede llegar a ser un Datamart que entre otras cosas nutren cada uno de los conceptos expuestos. Para Bill Inmon (1999), lo más importante en la definición de un Datamart, constituye que el departamento de la organización propietario del mismo posea el hardware, el software y datos que lo constituyen. Al poseer los derechos de propiedad de Datamart el departamento tiene el control y disciplina de los datos encontrados en el mismo. Un Datamart para Lane (1999), es una forma más sencilla de un Data Warehouse que está enfocado a una sola área funcional tales como ventas, finanzas o mercadeo. Debido a que se centra únicamente en una sola área, los Datamart se constituyen de menor cantidad de fuentes de datos que los Data Warehouse, las

cuales pueden ser sistemas operacionales internos o un Data Warehouse interno o externo. Es un conjunto de datos del Data Warehouse cuyo objetivo es responder a un determinado análisis función o necesidad, con una población de usuarios específica, al igual que un Data Warehouse, los datos están estructurados en modelo de estrella o copo de nieve, y un Datamart puede ser dependiente o independiente de un Data Warehouse (Curto, 2010). 5.2.1.2. Clasificación de un Datamart La clasificación de un Datamart emerge con Inmon como propuestas en las que se encuentran variaciones de la arquitectura de los Data Warehouse dado el concepto de Datamart como pequeñas bodegas que contienen información específica de algún tema presente en la organización como un proyecto o en áreas del negocio específicas. Se consideran tres tipos de Datamarts: Datamart Dependiente Los Datamart dependientes son aquellos que reciben los datos desde una Datawarehouse. En este tipo de Datamart la fuente de los datos es única.

Figura 3. Datamart Dependiente. Fuente: adaptado de Inmon.1996

Datamart Independiente Son aquellos que actúan como una bodega, toman sus datos directamente desde los sistemas transaccionales y no dependen de otros Data warehouse. Este tipo de Datamart se alimenta generalmente de las organizaciones.

Figura 4. Datamart Independiente. Fuente: adaptado de Inmon.1996

Datamart Hibrido Puede combinar las fuentes de información que lo nutren, es decir, desde archivos planos, BD transaccionales y hasta el propio data warehouse que se encuentre implementado. . También es posible encontrar tipos de Datamarts orientados a los populares cubos OLAP que por lo general ayudan a la visualización de información de manera que sea entendible para el usuario final, es decir, el área de negocio especifica. Esta visualización ya corresponde al proceso final, que evidencia los resultados en forma de reportes, informes, gráficos. 5.2.1.3. Características de un Datamart Bill Inmon (1999) plantea que un Datamart debe presentar las siguientes características. • Se centra únicamente en un área de la empresa. • El volumen de datos que maneja es inferior al de un Data Warehouse.

• No dispone del nivel de detalle ni los históricos que pueden disponer otros sistemas. • Son empleados en su mayoría como soporte para la toma de decisiones. Data Warehouse Datamart Alcance Creado con la finalidad de

satisfacer las necesidades de información de toda la organización.

Solo esta creado para satisfacer las necesidades de un área de negocio en específico.

Objetivo Optimizar la integración y la administración de los datos fuentes.

Optimiza la entrega de información de soporte de decisiones.

Característica de los Datos

Grandes cantidades de datos históricos.

Se concentra en administrar resúmenes.

Pertenencia Pertenece a toda la organización y a todas las áreas de negocio.

Pertenece al área de negocio al cual está orientado.

Administración Es administrado por la unidad de sistema de la organización.

Es administrado por el personal del sistema de la unidad que conoce del Datamart.

Tabla 1. Cuadro comparativo de un DataWarehouse y un Datamart 5.2.2. Tabla de hechos. La tabla de hechos o también llamadas fact Table son los atributos medibles en el modelo dimensional que establece las relaciones entre dichos atributos y las dimensiones que se desprenden de él. Denominamos “hechos” a los indicadores de negocio. Por ejemplo, son “hechos” las ventas, los pedidos, los envíos, las reclamaciones, las compras, etc. Es decir, son todas aquellas medidas numéricas que incluiremos en nuestro sistema Business Intelligence. Técnicamente, una tabla de hecho es la tabla central de un modelo en estrella. En el siguiente diagrama, la tabla de ventas es la tabla de hechos:

Figura 5. Modelo dimensional. Tabla de hechos y dimensiones (Fuente:

https://bdestrategica.wordpress.com/2013/04/)

La tabla de hechos solo contiene columnas de dos tipos: medidas y claves foráneas a las dimensiones. Las medidas son columnas que almacenan datos numéricos. Para las tablas de hechos es indispensable saber que atributos son medibles y cuáles no, ya que de los medibles son los indicadores de negocio de un proceso de negocio. Aquellos conceptos cuantificables que permiten medir nuestro proceso de negocio. Por ejemplo, en una venta tenemos el importe de la misma y la cantidad vendida. Existen métricas derivadas, como el precio unitario, que se obtiene al dividir el importe total por las unidades vendidas. Es una propiedad de un Hecho (casi siempre numérica). Las medidas más útiles para incluir en una tabla de hechos son los aditivos, es decir, aquellas medidas que pueden ser sumadas como por ejemplo la cantidad de producto vendido, los costes de producción o el dinero obtenido por las ventas; son medidas numéricas que pueden calcularse con la suma de varias cantidades de la tabla. En consecuencia, por lo general los hechos a almacenar en una tabla de hechos van a ser casi siempre valores numéricos, enteros o reales. 5.2.3 Dimensiones Es la representación en el data warehouse de un punto de vista para los hechos de cierto proceso de negocio. Si se va a un caso de estudio relacionado a una venta, para la misma tenemos el cliente que ha comprado, la fecha en la que se ha realizado, el producto vendido,… Estos conceptos pueden ser considerados como vistas para este proceso de negocio. Puede ser interesante recuperar todas las

compras realizadas por un cliente, o para un producto o familia de productos, o para un lapso determinado. Las jerarquías de las dimensiones presentan relaciones n-1 de manera que un valor de un nivel sólo puede ser agrupado por un único valor de cada nivel inmediatamente superior en la jerarquía. Esto facilita de manera rápida y sencilla el profundizar en el nivel de detalle (drill-down), disminuir el detalle(roll-up), selección (dice), proyección (slice) o pivotaje en las dimensiones (pivot), que son propios de los informes obtenidos a partir de data warehouse. 5.3 Proceso de Extracción, Transformación y carga de datos (ETL) El sistema de Extracción, Transformación y Carga (ETL) es la base sobre la cual se alimenta el Data warehouse. Si el sistema ETL se diseña de manera correcta, puede extraer los datos de los sistemas de origen de datos, aplicar diferentes reglas para aumentar la calidad y consistencia de los mismos, consolidar la información proveniente de distintos sistemas, y finalmente cargar (grabar) la información en el DW en un formato acorde para la utilización por parte de las herramientas de análisis. 5.3.1 Extracción La etapa de extracción es donde se tiene como meta la obtención de los datos desde las fuentes que sean necesarias. Los datos que se obtienen de esta etapa serán más a delante transformados y cargados en el almacén de datos, ya sea un Datamart o un Data Warehouse. Según Palomar & Trujillo (2001), las fuentes de datos que normal mente suministran los insumas para esta operación son:

Archivos de texto plano. Datos provenientes de documentos de texto, hojas de cálculos, etc. Data warehouse empresarial, en caso que el destino del proceso ETL sea un

Datamart. Datamart de la organización.

5.3.2. Transformación de Datos Lane (1999), se plantea que la transformación de los datos para el Datamart se puede definir como una serie de pasos, que consiste en llevar a cabo las transformaciones de cada atributo a considerar en el Datamart de forma separada mediante operaciones de SQL y/o procedimientos en lenguajes estructurados; por lo que se crean tablas temporales donde se almacenan los resultados parciales de estas operaciones. Para llevar a cabo esta estrategia se debe proveer de checkpoints o puntos seguros dentro del flujo de transformaciones con miras a llevar el monitoreo del proceso y poder reiniciar el mismo en caso de alguna falla. 5.3.3 Carga de Datos Existen diferentes formas de cargar los datos, se pueden cargar de manera masiva o casi de manera manual, pero la forma acertada de cargar los datos a un Datamart hace parte del proceso de modelado orientado a las necesidades del área de negocio y de los datos históricos que se obtengan o se requieran. Pero de manera generalizada en esta etapa es donde se depositan los datos en el sistema destino, los cuales se pueden llevar en las siguientes formas (Cardoza, 2015):

Cargas Secuenciales: Cargas organizadas una tras otra y generalmente de gran volumen de datos.

Proceso por lotes (Batchs): Son cargas largas que son supervisadas por el administrador de base de datos y que son generalmente realizadas por programas de forma periódica para mantener actualizado el Datamart.

Procesamiento paralelo y técnicas incrementales: Aquí solo se cargan datos nuevos y se modifican aquellos que han sido alterados desde su origen. Permite la consulta del Datamart aun cuando se esté llevando a cabo la actualización.

5.4. Herramientas de Desarrollo y Diseño A continuación se exponen las dos herramientas que se utilizaran para modelar el Datamart, el ETL de carga, la tabla de hechos y las dimensiones que nutren el modelo dimensional de las notas históricas de los estudiantes en la Universidad Distrital Francisco José de Caldas. Son herramientas de open Source (políticas de la Oficina Asesora de Sistemas) que ofrecen la capacidad de modelar y diseñar los ETL de carga iniciales que nutrirán el Datamart, la tabla de hechos para el modelo en estrella de datos, las dimensiones que complementa el modelo dimensional junto a la tabla de hechos. 5.4.1 Talend Open Studio Talend Open Studio es una herramienta de open Source de la compañía Talend que ofrece la posibilidad de modelar los ETL de carga y el modelo dimensional. ¿Por qué Talend Studio? No hay nada nuevo sobre el hecho de que los sistemas de información de las organizaciones tienden a crecer en complejidad. Las razones para esto incluye la "tendencia de acumulación de capas" (se implementa una nueva solución aunque los sistemas antiguos aún se mantienen) y el hecho de que los sistemas de información deben estar cada vez más conectados con los de proveedores, socios y clientes (Talend, 2017). Una tercera razón es la multiplicación de formatos de almacenamiento de datos (archivos XML, archivos planos posicionales, archivos planos delimitados, archivos de múltiples valores, etc.), protocolos (FTP, HTTP, SOAP, SCP, etc.) y tecnologías de bases de datos. De estas afirmaciones surge una pregunta: cómo gestionar una integración adecuada de estos datos dispersos en todo el sistema de información de la compañía. Varias funciones se encuentran detrás del principio de integración de datos: inteligencia de negocios o integración analítica (almacenamiento de datos) e integración operativa (captura y migración de datos, base de datos) sincronización, intercambio de datos entre aplicaciones.

Tanto ETL para análisis como ETL para necesidades de integración operativa son tratados por Talend Studio. Si bien es prácticamente invisible para los usuarios de la plataforma de BI, los procesos de ETL recuperan los datos de todos los sistemas operativos y pre-procesarlo para las herramientas de análisis e informes. Talend Studio ofrece conectividad casi integral para:

Aplicaciones empaquetadas (ERP, CRM, etc.), bases de datos, mainframes, archivos, servicios web, etc. para abordar el creciente disparidad de fuentes.

Almacenes de datos, mercados de datos, aplicaciones OLAP: para análisis,

informes, tableros, tablas de puntuación, etc.

Componentes avanzados incorporados para ETL, incluidas las manipulaciones de cadena, Dimensiones de cambio lento, manejo de búsqueda automática, soporte de cargas masivas, etc.

La mayoría de los conectores que abordan cada una de las necesidades anteriores se detallan en la documentación de componentes de Talend. Por información sobre su orquestación en Talend Studio, ver Diseño de un trabajo. Para negocios de alto nivel orientados modelado, ver Diseño de un modelo comercial.

Figura 6. Modelo Conectividad de Talend Studio. (Fuente: Talend Studio Guide)

La integración de datos operativos a menudo se aborda mediante la implementación de programas o rutinas personalizados, completados por pedido para una necesidad específica. La migración / carga de datos y la sincronización / replicación de datos son las aplicaciones más comunes de los datos operativos integración, y a menudo requieren (Talend, 2017):

Mapeos complejos y transformaciones con agregaciones, cálculos, etc. debido a la variación en los datos estructura

Conflictos de datos a ser gestionados y resueltos teniendo en cuenta la precedencia de la actualización del registro o "propietario del registro",

Sincronización de datos casi en tiempo real ya que los sistemas implican baja latencia.

Figura 7. Modelo Migración Talend Studio. (Fuente: Talend Studio Guide)

5.4.2. SpagoBI Es una multiplataforma que cubre satisfactoriamente todos los requisitos de BI (Business Intelligence), tanto en términos de análisis, gestión de datos, administración y seguridad. Desde el punto devista analítico ofrece soluciones para la presentación de informes, análisis multidimensional (OLAP), minería de datos (Data Mining), tableros de mando (Dashboard) y consultas ad-hoc. Añade módulos originales para la gestión de procesos de colaboración a través de análisis dossiers y el análisis de geo-referencia (SpagoBi guide, 2017). Además, SpagoBI es una plataforma de integración (y no una plataforma de productos), ya que no se basa en un conjunto predefinido de herramientas. Tiene una estructura modular en la que todos los módulos están relacionados con el sistema central, asegurando la armonía de la plataforma junto con sus capacidades en evolución (Strate BI, 2017). Spago BI cuenta con los siguientes módulos de diseño, implementación y visualización de información (Strate BI, 2017):

Reporting: Cree informes personalizados y exporte al formato más apropiado (HTML, PDF, XLS, XML, TXT, CSV, RTF).

MULTIDIMENSIONAL ANALYSIS (OLAP): Explore datos con diferentes ejes de análisis y diferentes niveles de detalle, con operaciones de profundización.

CHARTS: Desarrollo de gráficos personalizables e interactivos (histogramas, gráficos circulares, diagramas de barras, diagramas de dispersión, gráficos de líneas, diagramas buble, diagramas de dispersión).

KPIS: SpagoBI ofrece un conjunto completo de herramientas para crear, administrar y visualizar KPI, a través de diferentes métodos, reglas de cálculo, umbrales y alarmas.

INTERACTIVE COCKPITS: Análisis de la información agregada en una sola vista, rutas de navegación estables y permite que los datos exploten dinámicamente su forma gráfica.

AD-HOC REPORTING: Permite a los usuarios crear sus propios informes de varias páginas, incluidas tablas, tablas cruzadas y gráficos

LOCATION INTELLIGENCE: Posibilidad de analizar sus datos comerciales con mapas e interactuar dinámicamente.

DATA MINING: Permite extraer conocimiento, descubrir patrones de grandes volúmenes de datos para mejorar la toma de decisiones y las estrategias comerciales.

ETL: SpagoBI integra Talend Open Studio para la creación de procesos ETL (extraer, transformar y cargar datos.

CAPÍTULO 6. ALCANCES Y LIMITACIONES 6.1. Alcances

● El proyecto abarca el diseño e implementación de un único Datamart sobre Notas Históricas para la Universidad Distrital con un paquete de carga inicial que contiene imágenes digitalizadas de cada registro y un archivo de Excel con el total de registros seleccionados en un rango de años entre 1950 a 1972 con la salvedad de 400 registros de la Facultad de ingeniería.

● Carga inicial a través de un ETL con 400 registros (Digitalizado y en Excel) con la finalidad de realizar pruebas iniciales en el Datamart.

● Pruebas unitarias con la carga inicial del ETL al Datamart y visualización de información.

6.2. Limitaciones

Cantidad de registros: Para la recolección inicial de información se tendrán en cuenta 400 registros.

Software: El software presente en la Oficina Asesora de Sistemas (OAS) es de open source cumplimiento con las políticas organizacionales de la Universidad Distrital, entre los aplicativos a utilizar se encuentra Talend Studio Y SpagoBI 5.0, no se tendrá soporte de instalación ni de uso, pero se contará con documentación vía online de manera gratuita en el idioma inglés.

Hardware: Con el fin de realizar pruebas en el Datamart con los datos de carga inicial, se tiene la disponibilidad de un servidor propiedad de la Universidad ubicado en las instalaciones de la OAS en los horarios de 6 am a 8 pm, pero adicional a esto se deben tener en cuenta los procesos que estén ejecutando los funcionarios de la Universidad para no saturar el servidor, por ello, primero se hará una petición formal que permita la ejecución de pruebas.

Disponibilidad de la información: La información de carga inicial en la que se comprende los 400 registros estará disponible en libros físicos alojados en el archivo de la sede Aduanilla de Paiba de la Universidad Distrital Francisco José de Caldas a cargo de la funcionaria Mery, en un horario de 8 am a 5 pm.

Recursos monetarios y en tiempo: Los recursos monetarios correrán por cuenta de los dos ingenieros que diseñarán e implementarán el proyecto y el tiempo de recolección de información, diseño, implementación y pruebas

está contemplado en 4 meses a partir de la radicación del anteproyecto. La disponibilidad de tiempo será parcial y en fines de semana.

Disponibilidad de los recursos físicos: Se debe contar con una cámara digital que provee la funcionaria de la Aduanilla de Paiba en horario de 8 am a 5 pm. Los computadores y su mantenimiento estarán a cargo de los dos ingenieros que ejecutaran el proyecto.

CAPÍTULO 7. METODOLOGÍA La metodología propuesta por el grupo Kimball conocida como “Business Dimensional Lifecycle” (BDL), estructura la definición de un sistema de inteligencia de negocios como una solución completa a la necesidad de obtener un repositorio de datos con información consolidada, ya que provee no solo los procedimientos necesarios para el diseño de almacenes de datos dimensionales (Datamarts), sino que también permite definir la infraestructura que soportará y las aplicaciones necesarias para el acceso a la bodega, presentando de esta forma un concepto más amplio de lo que se conoce normalmente como un proyecto de inteligencia de negocios.

Figura 8. Modelo de la Metodología de Kimball

Los procesos en las tres áreas fundamentales por donde marcha el producto de definición de arquitectura son: dominio de datos, de tecnología y de aplicaciones, los cuales vienen antecedidos de un proceso de definición de requerimientos que está completamente centrado en los requerimientos de negocio, por lo que plantea que los proyectos de este tipo sean inclusivos con los usuarios y los patrocinadores del mismo; de una adecuada relación con los implicados depende prácticamente un adecuado levantamiento de requerimientos que refleje en la construcción de la bodega las reales necesidades del negocio.

Figura 9. Metodología Kimball, The Data Warehouse Lifecycle Toolkit, Second Edition 2008.

Se realizarán las iteraciones de la metodología Kimball las cuales se resumen a continuación: 7.1. Iteración 1 7.1.1. Visión de la arquitectura de BI La arquitectura es la forma de representar la estructura de los datos, la comunicación, el procesamiento y la presentación para el usuario final. En primera instancia se presentara la arquitectura general de la OAS para dimensionar de qué manera se están transfiriendo los datos y sobre que dependencias para así plantear la arquitectura de BI para las Notas históricas.

7.1.1.1. Arquitectura General (Oficina Asesora de Sistemas)

Figura 10. Arquitectura general Oficina Asesora de sistemas. Fuente: OAS.

En el anterior diagrama se resume la arquitectura propuesta para el macro sistema de centralización de la información de la cual hace parte el sistema de que visualizara la información de las notas históricas de la universidad Distrital, el cual es el objetivo de explicación del presente documento. En este diagrama se explica la interconectividad del sistema implementado una arquitectura orientada a servicios, de esta manera se reduce el tiempo de desarrollo y la complejidad en la interacción entre sistemas, permitiendo realizar una mejor integración entre sistemas a medida que pasan de etapa de desarrollo a producción, también presentan una mayor compatibilidad con servicios externos

7.1.1.2. Arquitectura Propuesta BI

Figura 11. Arquitectura BI propuesta. Fuente: Autores

La arquitectura BI presentada para este proyecto se fundamenta sobre cuatro importantes pilares: Fuentes de datos, gestión del almacenamiento, gestión de la explotación y por último la gestión del aprovisionamiento. La fuente de datos se obtiene del archivo de la universidad distrital que contiene de manera física los libros con la relación, nota, estudiante, materia. Para que sean fuentes para el sistema, la información presente en los libros es digitada a hojas de Excel, además se realiza un escáner de cada hoja física transcrita para que la evidencia tangible se vea reflejada en el sistema. La gestión del almacenamiento implica en primera instancia una transformación de los datos a través de los que llamaríamos un ETL y alimentara alguna de las dependencias de la Universidad Distrital para este caso al Área Académica – Notas Históricas del Datawarehouse. Posteriormente se pasara la información al Datamart que de manera específica guardara los datos según las áreas. Para la gestión de la explotación tomamos la información en el Datamart para visualizarla sobre SPAGO BI, allí también se crearan las consultas que estarán alineadas con los requerimientos del negocio y por último el despliegue de la información. A lo largo del proyecto se tendrá presente la gestión de aprovisionamiento en donde se coordinará la recepción, la transformación y la carga

de los datos que se necesiten ya sea para las entrada de datos como para el análisis. 7.1.2. Diagrama de procesos

Figura 12. Diagrama de Procesos para la integración de datos. Fuente: Autores

El diagrama de procesos expondrá de manera general cuatro de los procesos que se llevaran a cabo durante el proyecto del Datamart para las notas históricas de la Universidad:

Extracción Carga de ETL’s Integración Modelado

PROCESO

Nombre: Extracción de Información

Código: P1

Número: 1

DESCRIPCION DEL PROCESO El proceso por el cual se extrae la información a partir de los libros físicos que se encuentran alojados en la Universidad Distrital área de Archivo. La información es digitada en libros de Excel y posteriormente se escanea cada una de las hojas, para contar con información de evidencia con respecto al libro original.

LISTA DE REFERENCIAS DEL PROCESO

CONECTADO VIA CONECTADO A

Estructuras Fuentes de Datos

Datos de Archivo ETL (Talend Studio)

Tabla 2. Proceso de extracción de la información

Tabla 3. Proceso de creación del ETL

NOMBRE DEL PROCESO Nombre: Carga de ETL’s Código: P2 Número: 2 DESCRIPCION DEL PROCESO Proceso por el cual se toma la información en los archivos de Excel y de las imágenes escaneadas, para alojarla en el Datamart de la universidad Distrital. Se crea un Job de carga para los archivos

LISTA DE REFERENCIAS DEL PROCESO CONECTADO VIA CONECTADO A Dimensiones y Hechos Datamart “Notas históricas” Datos Multidimensionales SPAGO BI

NOMBRE DEL PROCESO

Nombre: Integración

Código: P3

Número: 3

DESCRIPCION DEL PROCESO

Proceso en el cual la información providente del ETL llega al DW de la Universidad Distrital y posteriormente es alojado en el datamart de las notas históricas



Cubos Cubos

Reportes y Consultas Usuarios Finales

Tabla 4. Proceso de integración entre el ETL y el Datamart

NOMBRE DEL PROCESO

Nombre: Modelado

Código: P4

Número: 04

DESCRIPCION DEL PROCESO

Proceso en el cual se diseña el modelo conceptual, lógico y físico que llevara la información concerniente a las notas históricas dela Universidad Distrital. Se crean dos tablas dimensionales (Estudiante y Asignatura) y una tabla de hechos correspondiente a las notas.



Cubos Cubos

Reportes y Consultas Usuarios Finales

Tabla 5. Proceso de modelado de las BD

7.1.3. Viabilidad del proyecto El presente análisis de factibilidad constituye una de las actividades comprendidas en el mencionado proyecto y permitirá evaluar la viabilidad de la propuesta para la realización de un datamart para las notas históricas en la Universidad Distrital. 7.1.4. Patrocinio El patrocinio está acordado entre las los ingenieros a cargos del proyecto y la Oficina Asesora de Sistemas. Los salarios correspondientes al arquitecto de software (Profesor Alejandro Daza) y el contratista externo (Jhon Castellanos) corresponden a rubros dados en la universidad Distrital. 7.1.5 Estudio de Factibilidad 7.1.5.1. Factibilidad Técnica

Hardware: una estación de trabajo (Universidad Distrital). o Servidores o Dos computadores (Ingenieros de Sistemas – Estudiantes)

Software: herramientas libres o Talend Open Studio Data Integration. o SPAGOBI o PostgreSQL (pgmodeler, pgAdmin)

Personal Técnico: Dos ingenieros de Sistemas, un arquitecto de Software y un contratista externo (Ingeniero de Software)

7.1.5.2. Factibilidad Operativa

Control de la información que se genera de las áreas implícitas con respecto a los reportes como deserción de estudiantes; así como de las tendencias que se generan sobre las notas en algunas asignaturas de antes con respecto a datos actuales.

Disminución de los tiempos de búsqueda de información. Agilitar el proceso de la toma de decisiones. Mejora de los procesos correspondientes a la entrega de notas

solicitadas por los estudiantes antiguos. Generación de certificados de manera ágil. Impacto en los usuarios finales con respecto a la información

suministrada

7.1.5.3. Factibilidad Financiera

Costos asociados al personal

Tabla 6. Presupuesto Proyecto, recurso humano. Fuente: Autores

Costos asociados a los recursos

Tabla 7. Presupuesto Proyecto Total. Fuente: Autores

Tipo

de

Recu

rso

Recu

rso

Cant

idad

Mes

1M

es 2

Mes

3M

es 4

Tota

l Cu

rso

Tale

nd S

tudi

o2

$ 1.

000.

000

$ 2.

000.

000

Spag

oBI

2$

1.50

0.00

0$

3.00

0.00

0Co

urse

ra D

atM

art

2$

1.50

0.00

0$

3.00

0.00

0Hu

man

o$

29.7

08.3

33Co

mpu

tado

r2

$ 4.

000.

000

$ 8.

000.

000

Impr

esor

a1

$ 1.

000.

000

$ 1.

000.

000

Inte

rnet

1$

80.0

00$

80.0

00$

80.0

00$

80.0

00$

320.

000

Buse

s2

$ 12

3.20

0$

123.

200

$ 12

3.20

0$

123.

200

$ 98

5.60

0

USB

1$

80.0

00$

80.0

00Fo

toco

pias

1$

15.0

00$

15.0

00$

15.0

00$

15.0

00$

60.0

00Pa

pele

ría e

n G

ener

al1

$ 30

.000

$ 30

.000

$ 30

.000

$ 30

.000

$ 12

0.00

0Lu

z1

$ 40

.000

$ 40

.000

$ 40

.000

$ 40

.000

$ 16

0.00

0Te

lefo

no1

$ 20

.000

$ 20

.000

$ 20

.000

$ 20

.000

$ 80

.000

Agua

1$

5.00

0$

5.00

0$

5.00

0$

5.00

0$

20.0

00Ga

stos d

e Al

imen

taci

ón

1$

150.

000

$ 15

0.00

0$

150.

000

$ 15

0.00

0$

600.

000

$ 49

.133

.933

$ 7.

370.

090

$ 56

.504

.023

SubT

otal

Pro

yect

o15

%To

tal p

roye

cto

Capa

cita

cion

es

Equi

pos

Tran

spor

te

Mat

eria

les

Serv

icio

s Púb

licos

Costo.- Se realizará un análisis global de la arquitectura actual de los Datamarts desarrollados en la Universidad Distrital para conocer sus fuentes de información, transformación y enriquecimiento de datos, y definición de sus tablas de hecho, así mismo como es la estandarización de los nombres en las tablas y en los atributos.

Producto.- De este análisis se evaluará cualquier punto de mejora, que se considere importante para garantizar cumplir con los objetivos del proyecto, así como para asegurar el óptimo uso de los recursos tecnológicos de la Universidad Distrital con respecto al Datamart

Pruebas técnicas y de funcionalidad con los usuarios técnicos de la

Universidad Distrital

Las pruebas con los usuarios finales las realizará el personal de la Oficina Asesora de Sistemas y el Archivo de la Universidad.

Se planteara la actualización de los procesos con respecto a la

adquisición de las notas históricas solicitadas por los estudiantes. 7.1.5.4. Impacto La solución implementada se enfoca en brindar seguridad de la información que se muestra en los reportes de acuerdo a la estructura actual de la organización. Las consultas ágiles en base a la solución implementada, brinda información veraz y en línea a los responsables de las áreas TI y BI, pudiendo estos convertirse en promotores de la búsqueda de fuentes de crecimiento de la organización. La optimización de los procesos con respecto a la generación de certificados de notas a egresados de la Universidad Distrital ya que estos procesos actúan como pilar en el eje de enlace egresado – organización y suministran información al DW de la Universidad Distrital, para que otras áreas puedan hacer uso de la información allí almacenada.

7.1.5.5. Factibilidad administrativa Buena relación entre analistas de negocio (usuarios de la bodega) y el departamento IT: Si es posible que este último se adapte fácilmente a los requerimientos que tengan los primeros. Cultura de uso e importancia de herramientas de BI: Básicamente evaluar la disposición de los potenciales usuarios a usar una bodega de datos y a cambiar los procesos que llevan a cabo para ejecutarlos según como se implementen en el proyecto. 7.1.6. Alcance El proyecto abarca el diseño e implementación de un único Datamart sobre Notas Históricas para la Universidad Distrital con un paquete de carga inicial que contiene imágenes digitalizadas de cada registro y un archivo de Excel con el total de registros seleccionados en un rango de años entre 1950 a 1972 con la salvedad de 400 registros de la Facultad de ingeniería. Carga inicial a través de un ETL con 400 registros (Digitalizado y en Excel) con la finalidad de realizar pruebas iniciales en el Datamart. Pruebas unitarias con la carga inicial del ETL al Datamart y visualización de información. 7.1.7. Comité de proyecto Es necesario integrar un equipo mixto entre usuarios de negocio y usuarios con conocimientos de IT, sería ideal que estas características se encontraran en las mismas personas. Los roles deseados para este tipo de proyectos son:

Patrocinador principal o jefe del proyecto- Alejandro Daza- Arquitecto del proyecto

Líder de negocio/técnico – Jhon Castellanos Ingenieros/Analistas de sistemas – Fabian Valderrama y Arnold Garces.

7.1.8. Diagrama WBS La Figura 12 ilustra las fases en las que se ha dividido el proyecto; así como las etapas en que cada una de estas se ha dividido.

Figura 13. WBS del proyecto. Fuente: Autores 7.1.9. Plan de comunicaciones El plan de comunicaciones está relacionado con los mecanismos utilizados por el grupo asignado al proyecto del datamart de notas históricas para la universidad Distrital con el fin de que la comunicación entre las partes del proyecto mantenga su sinergia en pro del objetivo principal.

7.1.9.1. Acciones de comunicación

NEGOCIO

Código 001

Descripción/Objetivos - Realizar un entendimiento con el negocio (Archivo UD)

para determinar los requerimientos que plantean los parámetros del Datamart para las notas históricas.

Responsable(s)

Ingenieros Responsables de la recolección de requerimientos:

- Arnold Garces - Fabian Valderrama

Audiencia objetivo Archivo Universidad Distrital Dependencias/ Condicionantes

Recursos humanos y materiales Ingenieros/Analistas.

Canales de comunicación Socialización por medio de una reunión.

Observaciones

Tabla 8. Acciones de comunicación: negocio. Fuente: Autores

REQUERIMIENTOS

Código 002

Descripción/Objetivos - Realizar una contextualización entre los requerimientos

recolectados del negocio al grupo técnico y administrativo del proyecto.

Responsable(s)

Ingenieros Responsables del levantamiento de requerimientos:


Audiencia objetivo Archivo Universidad Distrital Dependencias/ Condicionantes Oficina Asesora de Sistemas

Recursos humanos y materiales

Canales de comunicación Socialización por medio de una reunión

Observaciones

Tabla 9. Acciones de comunicación: requerimientos. Fuente: Autores

SOCIALIZACIÓN

Código 003

Descripción/Objetivos - Socialización de las bases recolectadas del archivo de la universidad Distrital

Responsable(s)

Ingenieros Responsables de la digitación en el libro de Excel de las notas históricas.


Audiencia objetivo Oficina Asesora de Sistemas

Dependencias/Condicionantes Archivo UD


Canales de comunicación

Observaciones

Tabla 10. Acciones de comunicación: socialización. Fuente: Autores

ENTENDIMIENTO

Código 004

Descripción/Objetivos

- Entendimiento sobre los procesos implementados en la Oficina Asesora de Sistemas para el desarrollo de los proyectos (estandarización, herramientas, metodología)

Responsable(s)

Ingenieros Responsables:

- Ing. Arnold Garces - Ing. Fabian Valderrama - Ing. Alejandro Daza ( Director Interno) - Ing. Jhon Castellanos (Director externo)

Audiencia objetivo Ingenieros- Estudiantes Dependencias/Condicionantes Archivo UD


Canales de comunicación Manuales, políticas de la OAS, metodologías. Observaciones

Tabla 11. Acciones de comunicación: entendimiento. Fuente: Autores

REUNIONES PERIODICAS

Código 005

Descripción/Objetivos - Reuniones periódicas para el avance del proyecto con los integrantes de cada área.

Responsable(s)

Ingenieros presentes en las reuniones periódicas:


Audiencia objetivo Oficina Asesora de Sistemas Dependencias/Condicionantes Archivo UD


Sala de reuniones, seguimiento dado el cronograma de las actividades adelantadas en la semana.

Canales de comunicación Presentación del estado del Proyecto.

Observaciones

Tabla 12. Acciones de comunicación: reuniones periódicas. Fuente: Autores

En este apartado se identificarán las acciones de comunicación previstas.

• Código identificativo se la acción: En el transcurso del proyecto es posible identificar planes de acción a través de su código único, además facilita su búsqueda en la documentación.

• Descripción de la acción de comunicación y objetivos principales perseguidos

• Responsable(s) de la realización de dicha acción.

• Audiencia objetivo: Perfil o colectivo al que va dirigida la comunicación.

• Dependencias/Condicionantes: Se indicarán las posibles dependencias con otras acciones dentro del plan, así como condicionantes necesarios para la realización de la misma.

• Recursos humanos y materiales necesarios para el desarrollo de la acción.

• Canales de comunicación: Identificar las herramientas, medios o información

necesarios para llevar a cabo la comunicación de la acción en cuestión.

• Observaciones o comentarios que se consideren de interés.

7.1.9.2. Planificación

Código Acción Responsable(s) Fecha

Inicio Fecha

Fin

001 Ingenieros: - Arnold Garces - Fabian Valderrama

20- Nov-2017

21-Dic-2017


22- dic-2017

05-ene-2018


08- ene-2018

31-ene-2018

004


31-ene-2018

10-feb-2018

005


20-nov-2017

23-Abril-2018

Tabla 13. Planificación por fechas. Fuente: Autores

Una vez se conforma un grupo de trabajo, se necesita definir la periodicidad con la que se realizarán reuniones de seguimiento y los temas que se tratarán en cada una. Las reuniones pueden ser de alto nivel, cuando se realiza entre líderes del proyecto, pero también pueden realizarse entre analistas para tratar temas técnicos que puedan llegar a afectar el discurrir del proyecto. 7.2. Iteración 2 7.2.1 Requerimientos del negocio Los requerimientos del negocio deben plantearse desde una contextualización del negocio y un análisis posterior con los directamente involucrados, para este caso el Archivo de la Universidad Distrital Francisco José de Caldas.

6.Identificación de los Requerimientos No

Funcionales del Sistema

Enunciado del proyecto

Formatos Establecidos

para Especificación

Documento de Especificación de Requerimientos No Funcionales

Acta de Constitrución

3.Identificación de módulos del sistema y / o Procesos de Negocio

1.Análisis inicial del mundo del Sistema.

Documento de Especificación de

Módulos del Sistema

4.Identificación de todos los Actores que

componen el Sistema

5.Identificación detallada de Casos de Uso del

Sistema

Documento de Casos de Uso del Sistema

6.Especificación detallada de

Requerimientos

Documento de Actores del

Sistema

Documento de Especificación detallada de

Casos de Uso

Acta de Aprobación de la

Especificación

2.Identificación general de los Requerimientos

Funcionales del Sistema

Administración de Requerimientos

(Controles de Cambios)

Figura 14. Construcción de los requerimientos. Fuente: http://www.estratega.org/articulo/el-area-de-ti-contribuye-valor-al-negocio-sepa-como-medirlo-parte-1

7.2.1.1 Identificación de los Requerimientos En este apartado se detalla los requerimientos funcionales y no funcionales que son necesarios para la elaboración del presente proyecto de notas históricas en la Universidad Distrital. 7.2.1.2 Requerimientos Funcionales La identificación de los requerimientos se realizó en conjunto con el coordinador del proyecto a partir de las preguntas detalladas en el alcance de la propuesta del proyecto, de esta forma se realizó una depuración y se codificaron para facilitar la referenciación de estos requerimientos.

http://www.estratega.org/articulo/el-area-de-ti-contribuye-valor-al-negocio-sepa-como-medirlo-parte-1

http://www.estratega.org/articulo/el-area-de-ti-contribuye-valor-al-negocio-sepa-como-medirlo-parte-1

Código RF01

Nombre Listado de un estudiante en especifico Tipo Reporte

Resumen

Crear un reporte en el que se permita listar los estudiantes con los siguientes datos: Facultad, materia, estudiante, código estudiante, nota, periodo académico.

Entradas Semestre, Programa, Curso

Resultados esperados Se espera un reporte con las materias vistas por el estudiante y las notas correspondientes a cada asignatura

Tabla 14. Requerimiento funcional: Reporte. Fuente: Autores

Código RF02 Nombre Visualización de las imágenes que soportan los libros físicos

alojados en el archivo de la UD Tipo Consulta Resumen

Crear una opción que permita al usuario ingresar a la información en la imagen que corresponde al libro original de la Universidad Distrital.

Entradas Semestre, Programa, Curso Resultados esperados Despliegue de la imagen del sistema cuando se realice un click sobre el documento a consultar.


Código RF03

Nombre Listado de un estudiante en especifico Tipo Reporte

Resumen

Crear un reporte en el que se permita listar los estudiantes con los siguientes datos: Facultad, materia, estudiante, código estudiante, nota, periodo académico.

Entradas Semestre, Programa, Curso

Resultados esperados Se espera un reporte con las materias vistas por el estudiante y las notas correspondientes a cada asignatura


7.2.1.3 Requerimientos No Funcionales Los requerimientos no funcionales son aquellos requerimientos relacionados directamente con la performance y rendimiento de los Datamarts; del mismo modo están relacionados con la elección de las herramientas a emplear para la elaboración de estos. A continuación se exponen los requerimientos no funcionales:

Código RT1

Nombre Integridad de la información

Tipo Seguridad Resumen

Los datos recogidos y/o la información producida por el sistema deben estar protegidos de corrupción, pérdida o modificación malintencionada, no autorizada o accidental

Entradas Datos de fuentes de información

Resultados esperados Reportes e Informes generados por el Datamart

Tabla 17. Requerimiento No funcional: Información. Fuente: Autores

Código RT2 Nombre Concurrencia y desempeño Tipo Infraestructura

Resumen Permitir un buen desempeño de los informes y estadísticas según demanda de uso del sistema Datamart.

Entradas Acceso de usuario y solicitudes al servidor. Resultados esperados Tiempos consecuentemente buenos en los resultados obtenidos.

Tabla 18. Requerimiento No funcional: Desempeño. Fuente: Autores

Código RT3

Nombre Requerimientos de Servidor

Tipo Infraestructura

Resumen

Se debe contar con las siguientes especificaciones de Servidores en las cuales se divide en dos capas: Base de datos y Aplicaciones, a continuación se detalla las características básicas necesarias para los ambientes de pruebas y a partir de su implementación se hará un dimensionamiento para determinar si estas mismas características se pueden usar en producción:

Servidor de aplicaciones para pruebas

Procesador de 2 núcleos a 64 bits. Memoria RAM: 16 GB Disco duro: 300 GB o superior. Servidor de Base de Datos:

Entradas Servicios y solución Datamart

Resultados esperados Recursos adecuados y tiempos buenos para la demanda de solicitudes y peticiones al servidor.

Tabla 19. Requerimiento No funcional: hardware. Fuente: Autores 7.2.2. MODELO DE NEGOCIO Para comprender el desarrollo que se llevó a cabo durante el periodo en que se realizó el proyecto del datamart para las notas históricas para los estudiantes de la Universidad Distrital Francisco José de Caldas, en el cual los autores del presente proyecto de grado estuvieron involucrados con el rol de ingenieros/analistas de sistemas, se deben comprender los procesos que se llevan a cabo para realizar dicha implementación, estos abarcan desde la petición que se hace por parte del egresado para obtener las notas históricas presentes en los libros físicos de la Universidad pasando por la consulta de los libros por parte del personal del archivo, y posteriormente en la consulta del datamart para obtener las notas y asignaturas asociadas. A continuación se describirán cada uno de estos procesos, los cuales fueron planteados por todo el equipo de trabajo del proyecto Datamart para las notas

históricas de los estudiantes en la Universidad Distrital (Interesados, Arquitecto de Software e Ingenieros/Analistas de Sistemas). 7.2.2. Carga de Notas, materias y estudiantes de la Universidad Para poder realizar el proceso de consulta al datamart de las notas históricas se deben cargar los archivos Excel que se digitaron a partir de los libros físicos presentes en el Archivo de la universidad. Cada archivo de Excel contiene varios registros de los estudiantes, donde se encuentra asociados los campos de: Facultad, asignatura, Estudiante, nota, periodo académico. A continuación se muestra un diagrama de proceso para este caso: 7.2.2.2 Carga de imágenes (escáner) evidencia de los libros físicos Posterior a la carga de los archivos Excel que contiene los datos de los estudiantes y las notas, se procede a la carga de las imágenes de escáner sobre las hojas físicas de los libros donde en un inicio se transcribió toda la información de los estudiantes de la Universidad Distrital. A continuación se muestra un diagrama de proceso para este caso: 7.2.2.3 Consulta de la Notas Históricas Para el proceso de consulta para las notas históricas, en primera instancia debe existir la petición por parte del usuario final quien es el egresado. La petición de su consulta dispara el proceso de obtener las notas y asignaturas asociadas a dicho estudiante del datamart de notas históricas. Con antelación la información fuente que son los archivos de Excel y las imágenes ya han pasado por el ETL que es un sub-proceso de extraer la información de los archivos planos para que lleguen al datamart. Una vez en el datamart la información es trasladada a SPAGO BI en donde se podrá desplegar la consulta con un servidor. A continuación se muestra un diagrama de proceso para este caso:

7.3. Iteración 3 Una vez se ha logrado consenso en los procesos identificados en las reuniones con el personal del Archivo de la Universidad se puede llegar a la priorización de los procesos La priorización dependerá de la evaluación de la factibilidad, medida según el número de dimensiones requeridas para cada proceso y del impacto, medido según el número de procesos afectados por una dimensión; la idea es iniciar con aquellos procesos que se encuentren en un punto intermedio entre ambos factores (aunque se favorece un poco más la factibilidad sobre el impacto) y por consiguiente se realicen en ciclos cortos (requieren implementar pocas dimensiones) dentro de un proyecto de mediano o largo plazo de tal forma que hagan las veces de estados transitorios que permitan mostrar avances a los patrocinadores del proyecto, mientras se logra consolidar procesos de mayor impacto. 7.3.1 Diseño de la matriz Dimensiones VS Procesos de Negocio Proceso de Negocio: Consulta de un estudiante. Dimensión: Estudiante, asignatura Como el área de TI no puede contribuir valor en todos estos ejes en forma simultánea de una manera que sea viable para el negocio, éste debe definir el peso relativo o ponderación de cada dimensión. La Figura analiza la contribución de valor de los servicios de TI al proceso Consultar un estudiante especifico, desde la dimensión de Estudiante y asignatura. Para agregar valor, los servicios de TI deben ser capaces de hacer que el proceso de negocio sea más confiable, tome menos tiempo, sea flexible ante cambios, cueste lo menos posible, minimice el uso de activos, ofrezca cualidades innovadoras y permita establecer y cultivar relaciones con el usuario.

Tabla 20. Matriz dimensiones vs Procesos de Negocio. Fuente: Autores

Las celdas de la tabla precedente definen el nivel de contribución de un servicio de TI a un subproceso desde la dimensión Estudiante y asignatura: P: el servicio contribuye en forma principal S: contribución secundaria Intersección gris: el servicio de TI no tiene relación con el subproceso. Esta matriz permite focalizar en los servicios que más contribuyen al negocio desde una dimensión de valor específica. Con esta metodología es posible diseñar los componentes del valor de TI según los procesos de negocio soportados. Los indicadores de desempeño de TI se organizan según la estructura de un Balanced Scorecardque tiene cuatro perspectivas: Aprendizaje y crecimiento, Procesos, Clientes y Financiera. Esta última consolida los indicadores que miden la contribución de valor de TI al negocio. En general, las áreas de TI miden muy bien el desempeño de sus recursos, la eficacia y eficiencia operacionales, y la respuesta ante incidentes o pedidos del usuario. Adicionalmente, la importancia de cada indicador se pondera en relación con el negocio, para que al área de TI pueda priorizar las mejoras de los servicios. Así tenemos servicios que en al principio del proyecto solo se cargaran desde los archivos fuente, que son los libros físicos que se encuentran en el archivo de la

Universidad distrital, pero luego se cargaran casi de manera automática desde otra dependencia o desde el aplicativo de Sistema de Gestión Académica. Hay otros servicios que dependen de las labores casi diarias en la Universidad, como el exportar los archivos obtenidos a Excel o emitir una certificación sonreí los datos consultados. También se cuenta con un subproceso que se realizara una sola vez en el proyecto que corresponde a la digitación de las notas a los archivos de Excel pero que tiene un impacto significativo en los servicios de TI que se implementaran durante todo el proyecto, por eso su importancia en la matriz. 7.3.2 Matriz Impacto VS Factibilidad Conceptos Impacto: Es el efecto esperado que va a tener la iniciativa en caso de ser implementada. Tenemos que intentar imaginar el efecto de la idea una vez implementada y concretada. Factibilidad: Mide la complejidad de una iniciativa para ser implementada. Hay que tomar en cuenta los recursos materiales y humanos en los que debemos incurrir para implementarla.

Figura 15. Matriz de Impacto vs Factibilidad. Fuente: Autores Bajo Impacto / Baja Factibilidad: Son los procesos que no son relevantes dentro del proyecto. Bajo Impacto / Alta Factibilidad: Son procesos que debemos llevar a cabo rápidamente. La realización del proceso de carga de estudiantes, asignaturas y notas de la universidad Distrital es de bajo impacto en la versión final del proyecto, pero es factible en el apoyo que se da para el proyecto, ya que son el insumo para todo el análisis que se desprende en iteraciones posteriores. Alto Impacto / Baja Factibilidad: Son las los procesos de muy difícil realización. Es importante tener siempre una o dos en análisis que nos sirvan como aspiracional. Sin embargo, es un error apostar todo a ellas ya que el riesgo de no concreción es muy alto.

Carga de Notas, materias y estudiantes de la

Universidad

Carga de imágenes (escáner) evidencia de

los libros físicos

Consulta de la Notas Históricas

Alto Impacto / Alta Viabilidad: Son los procesos relevantes para el proyecto y que su ejecución de manera asertiva dan como hecho varios objetivos planteados al principio del proyecto. 7.4. Iteración 4 7.4.1 EVALUACIÓN DE SOFTWARE Las siguientes tablas y matrices están basadas a la discusión de cómo evaluar un software y los criterios propuestos en la página de Matriz de Evaluación – Parte I, los productos a evaluar son: Software 1= Talend Open Studio. Software 2= Spago BI El análisis comparativo técnico se hará sobre productos finales; es decir productos ensamblados que vienen en formato de ejecutables. Para lo cual se apreciaran las características de cada software y se estimaran, dándoles ponderación a cada una, verificando y comparando así que programa es mejor en cada aspecto y cuál es el más conveniente al momento de su uso

7.4.1.1 Matriz de evaluación de productos La siguiente tabla indica lo que se evaluara para ambos software:

CARACTERÍSTICA SUB

CARACTERÍSTICA PONDERACIÓN DESCRIPCIÓN

Funcionablidad

Adecuación 5

Registro de control de procesos y procedimientos correctos funcionales

Exactitud 4

Control de permiso de impresiones a color y por cuotas

Interoperabilidad 4 Capacidad de trabajar con plataforma estándares

Seguridad 7

Capacidad de ingresos a los módulos por cuentas de usuarios y contraseñas

Fiabilidad Recuperabilidad 5

Posee utilidades de backup y restore

Tolerancia a Fallas 5 Posee modulos de fallas. Aprendizaje Facilidad de aprender su uso

Eficiencia

Desempeño 5 Tiempos de respuesta

Utilizacion de Recursos 10

Bajos requerimientos de recursos (Procesamiento, memoria y disco duro y requiere el equipo dedicado.

Manteniabilidad Acoplamiento 5

Presencia de Interacciones entre componentes del sistema.

Modularidad 5

Presenta componentes que dependen unos de otros del sistema

Portabilidad

Adaptabilidad 10 Facilidad de operar

Instalabilidad 5 Pocos pasos asistidos para su instalación

Coexistencia 5

Capacidad de operar junto a otros software instalados en el servidor

Reemplazabilidad 10

Capacidad de ser utilizado en el lugar de otro software, en el mismo entorno

No funcionales Productividad 4

Tiempo adecuado para realizar configuraciones.

Actualizaciones 7 Existencia de actualizaciones Satisfacción 4 Nivel de satisfacción

TOTAL 100

Tabla 21. Matriz evaluación de productos. Fuente: Autores

Tabla 22. Matriz evaluación de productos. Fuente: Autores

El peso ponderado asignado para cada característica en específico, fueron dados por el grupo del proyecto, y se encuentra alineado a las necesidades del negocio contando con el cumplimiento de los objetivos, sin excluir el impacto de cada una con respecto a la funcionalidad, eficiencia, mantenibilidad, fiabilidad, portabilidad. Para la segunda fase es recomendable ser cautos en la elección del producto, no se trata de elegir el software o hardware más avanzado, sino de aquel que realmente satisface los requerimientos de negocio, la estrategia para la selección del producto es con hoja de requerimientos en mano, realizar una investigación de mercado apoyada por recomendaciones del equipo de trabajo, analistas, IT. El puntaje esta dado de 1 a 10 y es también asignado por el equipo del proyecto dados los análisis y la experiencia en que han manejado los software anteriormente evaluados. Cabe aclarar que son programas de código abierto y no existe soporte formal sobre los mismos, pero existe suficiente documentación. 7.5. Iteración 5 7.5.1 Modelado Dimensional En esta sección se denotan cada uno de los elementos multidimensionales que forman parte de la solución. Para el modelado de la solución se tomó como base la información alojada en los libros físicos de la Universidad Distrital, en los cuales se encuentra información como facultad, periodo académico, estudiante, asignatura, estudiante. 7.5.1.1 Modelo dimensional Conceptual

Figura 16. Modelo dimensional conceptual: Notas históricas. Fuente: Autores

El modelo dimensional antes expuesto está compuesto por dos dimensiones que corresponden al estudiante y a la asignatura, que a su vez se encuentran relacionadas con una tabla que llamaremos Notas, que corresponde a la tabla de hechos del modelo. Dicha relación corresponde de manera analógica a una tabla de rompimiento por la relación presente entre la dimensión de estudiante y la dimensión asignatura ya que dicha relación se presenta de mucho a muchos. 7.5.2 MODELO LÓGICO DEL DATAMART. A continuación, se confeccionó el modelo lógico de la estructura del Datamart, teniendo como base el modelo conceptual. A partir de este último se desarrolló el Modelo físico de la base de datos o arquitectura de base de datos que se focalizó sobre la selección de las estructuras de almacenamiento (variables, tipo, longitud, entre otros). Las dimensiones que se derivan de los requerimientos son las que se describen a continuación. 7.5.2.1 TABLA DE DIMENSIONES. Cada perspectiva definida en el modelo conceptual constituye una tabla dimensión, para definir una dimensión se toma en cuenta lo siguiente:

Dim: Representa un dimensión. Nombre Tabla: Nombre de la tabla a la que hace referencia la dimensión. Formato: Dim Nombre de la tabla a la que hace referencia.

Lista de dimensiones. Dim_Asignatura Dim_Estudiante

Descripción de las dimensiones. Dimensión Asignatura

Tabla DimAsignatura

Descripción Tabla de registro de Asignaturas en la Universidad Distrital

Destino Origen

Columna Desc. Tipo Tabla Campo Tipo

ASIGNATURA_CODIGO Llave primaria PK_ INT (11)

Archivo Plano Materia

ASIGNATURA_CODPENSUM Código del pensum INT (3) Archivo Plano

ASIGNATURA_CODCARRERA Código de la carrera. INT (11) Archivo Plano

ASIGNATURA_NOMBRE Nombre de la asignatura

VARCHAR (100)

Archivo Plano

ASIGNATURA_CODDEPARTAMENTO Codigo del departamento INT (3) Archivo

Plano

ASIGNATURA_NOMDEPARTAMENTO Nombre del departamento de la asignatura

VARCHAR (100)

Archivo Plano

ASIGNATURA_SEMESTRE

Semestre que transcurre INT (3) Archivo

Plano

ASIGNATURA_TIPO Tipo de asignatura INT (3) Archivo Plano

ASIGNATURA_ELECTIVA Si la asignatura es elctiva o no

VARCHAR (3)

Archivo Plano

ASIGNATURA_ESTADO Estado de la asignatura

VARCHAR (8)

Archivo Plano

ASIGNATURA_ESTADOPENSUM

Estado de la asignatura en el pensum

VARCHAR (8)

ASIGNATURA_NUMEROCREDITOS Numero de creditos asignados INT (4) Archivo

Plano

ASIGNATURA_HORASTEORIA Horas teoricas INT (3) Archivo Plano

ASIGNATURA_HORASPRACT Horas de practica INT (3) Archivo

Plano

ASIGNATURA_HORASAUTO Horas Autoaprendizaje

INT (3) Archivo Plano

Tabla 23. Dimensión Asignatura. Fuente: Autores

Dimensión Estudiante

Tabla DimESTUDIANTE Descripción Tabla de registro de Estudiantes en la Universidad Distrital Destino Origen


ESTUDIANTE_CODIGO Llave primaria BIGINT (20)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_CODIGO

ESTUDIANTE_TIPOID Tipo dicumento del estudiante

VARCHAR (4)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_TIPOID

ESTUDIANTE_NUMEROID Numero de identificación

VARCHAR (15)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_NUMEROID

ESTUDIANTE_PRIMERAPE Primer apellido VARCHAR (45)

Archivo Plano Nombre

ESTUDIANTE_SEGUNDOAPE Segundo apellido VARCHAR (45)


ESTUDIANTE_PRIMERNOMBRE Primer nombre VARCHAR (45)


ESTUDIANTE_SEGUNDONOMBRE Segundo nombre VARCHAR (45)


ESTUDIANTE_GENERO Genero del estudiante INT (1)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_GENERO

ESTUDIANTE_LUGARNAC Lugar de nacimiento del estudiante

VARCHAR (30)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_LUGARNAC

ESTUDIANTE_FECHANAC Fecha de nacimiento del estudiante

DATE DMD_BIE_ESTUDIANTE

ESTUDIANTE_FECHANAC

ESTUDIANTE_DIRECCIONRES Dirección de residencia

VARCHAR (100)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_DIRECCIONRES

ESTUDIANTE_TELEFONOFIJO Número de teléfono fijo INT (10)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_TELEFONOFIJO

ESTUDIANTE_TELEFONOMOVIL Número de teléfono movil INT (13)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_TELEFONOMOVIL

ESTUDIANTE_FECHAINGRESO Fecha de Ingreso a la Universidad DATE

DMD_BIE_ESTUDIANTE

ESTUDIANTE_FECHAINGRESO

ESTUDIANTE_ESTADO

Estado del estudiante (ACTIVO, EN VACACIONES, INACTIVO)

VARCHAR(20)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_ESTADO

ESTUDIANTE_PORCENTAJECARR Porcentaje de carrera del estudiante

INT (5) DMD_BIE_ESTUDIANTE

ESTUDIANTE_PORCENTAJECARR

Tabla DimESTUDIANTE Descripción Tabla de registro de Estudiantes en la Universidad Distrital Destino Origen


ESTUDIANTE_FECHATERMI En caso de grado, fecha de terminación

DATE DMD_BIE_ESTUDIANTE

ESTUDIANTE_FECHATERMI

ESTUDIANTE_TIPOSANGRE Tipo de Sangre estudiante

VARCHAR (1)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_TIPOSANGRE

ESTUDIANTE_RHSANGRE RH sangre estudiante

VARCHAR (10)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_RHSANGRE

ESTUDIANTE_NUMEROLIBRETA Numero de Libreta militar (hombre)

VARCHAR(14)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_NUMEROLIBRETA

ESTUDIANTE_DISTRITOMILITAR Distrito Militar inscrito

VARCHAR (3)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_DISTRITOMILITAR

ESTUDIANTE_TIPOIDANTERIOR

Tipo de documento anterior por el estudiante

VARCHAR (4)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_TIPOIDANTERIOR

ESTUDIANTE_NOIDANTERIOR

Número de documento anterior por el estudiante

VARCHAR (14)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_NOIDANTERIOR

ESTUDIANTE_NUMEROPENSUM Codigo del pensum asignado al estudiante

VARCHAR (10)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_NUMEROPENSUM

ESTUDIANTE_CODCIVIL Codigo estado civil del estudiante

VARCHAR (5)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_CODCIVIL

ESTUDIANTE_ESTADOCIVIL Estado civil del estudiante

VARCHAR (10)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_ESTADOCIVIL

ESTUDIANTE_EMAIL Email personal del estudiante

VARCHAR (30)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_EMAIL

ESTUDIANTE_EMAILINSTITUCIONAL

Email institucional del estudiante

VARCHAR (30)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_EMAILINSTITUCIONAL

ESTUDIANTE_ACUERDO

Acuerdo académico al cual está inscrito el estudiante

VARCHAR (10)

DMD_BIE_ESTUDIANTE

ESTUDIANTE_ACUERDO

ESTUDIANTE_PROYECTO

Proyecto curricular al cual está inscrito el estudiante.

VARCHAR (20)

Archivo Plano

Proyecto curricular

Tabla 24. Dimensión Estudiante. Fuente: Autores

TABLA DE HECHOS

Tabla HECHOS_NOTA

Descripción Tabla de registro de notas en la Universidad Distrital

Destino Columna Desc. Tipo

NOTA_ASIGNATURA_CODIGO Llave primaria. Código de la asignatura INT (11) PK NOTA_ASIGNATURA_CODPENSUM Llave primaria. Código de Pensum INT (3) PK NOTA_ASIGNATURA_CODCARRERA Llave primaria. Código Carrera INT (11) PK

NOTA_ESTUDIANTE_CODIGO Llave primaria. Código estudiante BIGINT (20) PK

NOTA_PERIODO_ACADEMICO Llave primaria. Periodo académico INT (10) PK NOTA_VALOR Valor de la Nota correspondiente Double (2,1)

NOTA_CODIGOFACULTAD Facultad donde se registro la nota VARCHAR (3)

NOTA_NOMBREFACULTAD Nombre de la facultad VARCHAR (20)

NOTA_SEDE Sede VARCHAR (20)

NOTA_APROBADO Aprobación de la asignatura (APROBADO, NO APROBADO) VARCHAR (1)

NOTA_HABILITADO Valor de la Nota Habilitada Double (2,1)

NOTA_OBSERVACIONES Observaciones sobre las asignaturas VARCHAR (200)

NOTA_DOCENTE Docente encargado VARCHAR (200)

NOTA_LBRO Numero Libro fisico donde se encuentra la nota VARCHAR (5) NOTA_PAGINA Pagina del libro VARCHAR (10)

NOTA_ANNO Año en que se curso la asignatura VARCHAR (6)

Tabla 25. Tabla de Hechos Notas. Fuente: Autores

7.5.3 Modelo dimensional Lógico

Figura 17. Modelo Dimensional Lógico- Notas históricas. Fuente: Autores

El modelo dimensional lógico del datamart contiene tres tablas: Dim_Asignatura, Dim_Estudiante y Hechos_Nota. Las tres tablas contienen los atributos que identifican cada dimensión y finalmente organizan los datos para ser presentados en la parte de análisis. La relación entre el estudiante y la asignatura es una relación de muchos a muchos N – N que representa que un estudiante puede ver muchas asignaturas y una asignatura puede ser vista por muchos estudiantes. Para que la relación entre asignatura y estudiante sea eficiente para su consulta, se crea una tabla de hechos que contiene los atributos medibles como el valor de la nota. La tabla Hechos_Nota se crea en otras palabras como una tabla de rompimiento como se realiza analógicamente en un modelo entidad relación. 7.5.4 Componente ETL de Talen Open Studio En el desarrollo de la solución se usó como herramienta ETL a la plataforma Open Source Talend Open Studio, para ejecutar la extracción, transformación y carga de los datos. Las estructuras dimensionales van a ser creadas a partir de los lineamientos expuestos para la creación del Data Mart, el contar con la transformación dentro del componente ETL da la facilidad de realizar o disponer de operaciones definidas para el uso exclusivo de la organización en base a sus necesidades. 7.5.4.1 Extracción, Transformación y Carga A partir de esta sección se detallarán los pasos para realizar la extracción, transformación y carga de los datos en las dimensiones necesarias desde el repositorio fuente del sistema SWISS. Para realizar el proceso ETL se utiliza la herramienta Open Source Talend Open Studio

Figura 18. Modelo de ETL – Notas Históricas. Fuente: Autores

Proceso ETL- Talend Studio Notas Históricas -

DATAMART Transformación

Extracción Carga

A continuación se detallan las secuencias de trabajo que se crearon para el proyecto. 7.5.4.2 Procesos ETL Creación de Dimensiones Este proceso gestiona las extracciones y transformaciones necesarias para las dimensiones. A continuación se detallan las secuencias creadas: Dimensión Asignatura La secuencia de extracción y carga de la Asignatura, tomará la información del archivo fuente de Excel obtenido de la digitación de la información “Notas_Historicas” para crear la tabla y dimensión: Dim_Asignatura. Además de la información en el archivo de Excel se cuenta con información alojada en la tabla DMD_PRC_ASIGNATURA de la universidad Distrital que acabaran con llenar los campos concernientes a la Dimensión Asignatura. El resultado del Job son los registros alojados en la base de Datos Postgres anteriormente diseñada.

Figura 19. Carga de la dimensión asignatura – Talend open Studio. Fuente: Autores

Mapeo de datos Asignatura El mapeo de datos realiza un empalme entre los atributos de la tabla origen Notas (archivo Excel) y la base de datos Conexión_All (Postgres) para que los datos estén alojados en las columnas seleccionadas.

Figura 20. Mapeo de datos asignatura – Talend open Studio. Fuente: Autores

Dimensión Estudiante La secuencia de extracción y carga de un estudiante, tomará la información del archivo fuente de Excel obtenido de la digitación de la información “Notas_Historicas” para crear la tabla y dimensión: Dim_Estudiante. Además de la información en el archivo de Excel se cuenta con información alojada en la tabla DMD_BIE_ESTUDIANTE de la universidad Distrital que acabaran con llenar los campos concernientes a la Dimensión Estudiante.

Figura 21. Carga de la dimensión Estudiante – Talend open Studio. Fuente: Autores

Mapeo de datos Estudiante El mapeo de datos realiza un empalme entre los atributos de la tabla origen Estudiante (archivo Excel) y la base de datos Conexión_All (Postgres) para que los datos estén alojados en las columnas seleccionadas.

Figura 22. Mapeo de Datos Estudiante – Talend open Studio. Fuente: Autores

Creación de tabla de Hechos La secuencia de extracción y carga de la tabla de hechos que contiene las Notas de los estudiantes, tomará la información del archivo fuente de Excel obtenido de la digitación de la información “Notas_Historicas” para crear la tabla de hechos: Hechos_Nota.

Figura 23. Carga tabla de hechos Notas – Talend open Studio. Fuente: Autores

Mapeo de datos tabla de hechos El mapeo de datos realiza un empalme entre los atributos de la tabla origen Estudiante (archivo Excel) y la base de datos Conexión_hechos (Postgres) para que los datos estén alojados en las columnas seleccionadas.

Figura 24. Mapeo de Datos Tabla de Hechos – Talend open Studio. Fuente: Autores

7.6. Iteración 6 7.6.1 Dominio de Aplicaciones Diseño y desarrollo de aplicaciones analíticas. Creación de plantillas de reportes y análisis. 7.6.1.1 Estructura General En SPAGO BI los cubos se especifican mediante un archivo donde se describe la estructura de los mismos (dimensiones, jerarquías, niveles, hechos, medidas) así como se realizan los mapeos entre estas estructuras y las tablas donde se encuentran almacenados los datos que pueblan las mismas. 7.6.1.2 Reportes e Indicadores El problema a resolver dentro de este proyecto fue la generación de reportes e indicadores académicos creados a partir de los datos registrados, de manera que los reportes e indicadores sean usados para la toma de decisiones de la facultad.

La herramienta usada para la creación de los indicadores y reportes es SPAGO BI. Para la creación de cada reporte se siguieron los siguientes pasos:

Se configuró la fuente de datos en la cual se agregan las conexiones y demás configuraciones.

Se asigna la conexión a la base de datos donde se encuentra cargado el Datamart en Postgrest dado el modelo físico de la solución.

De la vista del análisis se obtiene la consulta MDX utilizada para

obtener los datos a presentar.

Se seleccionan las columnas a mostrar.

Luego se pasa a la etapa de personalización del reporte .

El último paso es la publicación del reporte dentro del servidor para que pueda ser visualizado.

7.6.1.3 Estructura de los Reportes e Indicadores Una definición general de un reporte consiste en un conjunto de secciones que definen la disposición y contenido de la información dentro de éste. Estas secciones son:

Cabecera y pie del reporte: Es impreso al comienzo y fin del reporte respectivamente.

Cabecera y pie de página: Son impresos al comienzo y fin de cada página respectivamente.

Cabecera y pie de grupo: Son impresos al comienzo y fin de cada

grupo respectivamente. Un grupo, generalmente, contiene el nombre de una columna y su valor.

Ítems o detalles: Contienen los datos obtenidos de la consulta. Estos

valores se repiten tantas veces como las devuelva en la consulta. A continuación se detalla la estructura general de los reportes e indicadores:

7.6.1.4 Reportes Notas Estudiantes Por Año Para la creación de plantillas para la visualización de la información se tomó como base el formato original de los libros físicos donde se encuentran las notas históricas de la Universidad Distrital 7.6.1.5 Diseño de la tabla

Figura 25. Tabla Reporte de estudiantes - notas. Fuente: Autores

Se crearon un reporte que muestra las materias con sus respectivas notas para un año en específico y una página del libro original. El reporte está compuesto por tres partes:

La cabecera que contiene el Nombre de la Universidad, el área encargada (Oficina Asesora de Sistemas), el nombre del reporte, Periodo académico (Año).

El agrupamiento de la cabecera que tiene el nombre del estudiante, el código del estudiante, el código de la facultad, el nombre de la facultad, el código del proyecto curricular, el nombre del proyecto curricular, la página del libro físico.

El cuerpo genera información de la asignatura, semestre,

Habilitación, Nota, Observaciones.

El parte final se cargara la imagen que corresponde a la evidencia del libro físico.

Figura 26. Reporte en SPAGO BI del estudiante. Fuente: Autores

Figura 27. Reporte en SPAGO BI del estudiante - Implementación. Fuente: Autores

7.6.2 BD en Postgrest Una vez estando en SPAGO BI se procede a realizar la conexión a la base de datos en Postgrest. Como ya se observó en la extracción, transformación y carga de información la salida de dicho proceso es la Base de datos Postgrest que se convierte en el insumo en SPAGO para cargar la información con un reporte previamente elaborado y atendiendo las necesidades del negocio. 7.6.2.1 Diseño de querys Para la consulta de la información obtenida el ETL y alojada en la base de datos Postgres (dimensión estudiante, de la dimensión asignatura y de la tabla de hechos) se crearon dos querys que extraen la información del estudiante en conjunto con las notas históricas para formar el reporte de notas históricas de la Universidad Distrital Francisco José de Caldas. 7.6.2.2 Query - Guardar Estudiante

Figura 28. Query - Guardar estudiante – Talend open Studio. Fuente: Autores

7.6.2.3 Query - Generar reporte

Figura 29. Query – Generar reporte de notas – Talend open Studio. Fuente: Autores

7.8. Iteración 8 Implementación y Mantenimiento: Se juntan los dominios, se educa a los usuarios. Se hace mantenimiento para asegurar que la bodega permanece alineada a su propósito. Y finalmente se asegura mejoramiento continuo creciendo la bodega con nuevos proyectos retornando al inicio del ciclo. En esta última parte de la metodología, hay que estar en acompañamiento continuo para asegurar que los usuarios están satisfechos con la bodega y se les ha convertido en una herramienta imprescindible para su trabajo. A los usuarios hay que ayudarlos en dos frentes, soporte y educación, el primero exige estar muy pendiente a las primeras reacciones de los usuarios y al monitoreo de posibles errores que se puedan presentar, en el segundo aspecto se hace necesario repasar algunos de los entregables de material educativo de la anterior iteración, hay que recordar que entre más educación se les entregue a los usuarios más interesados estarán en usar la bodega. Por último siempre es importante revisar oportunidades de mejora y crecimiento, según el éxito de la bodega, se replantearan nuevas necesidades que se convertirán a su vez en motivo de implementación de nuevas funcionalidades, las cuales pueden ser implementadas iniciando con la primera iteración de la metodología.

CAPÍTULO 8. RECURSOS Se contempla en la Tabla 2, los recursos que se estiman serán necesarios en el proceso de recolección de información, planeación, diseño, ejecución y pruebas del Datamart Notas históricas. 8.1 Recursos del Proyecto

Tipo de Recurso Recurso Cantidad

Humano Analista de

Requerimientos 1 Arquitecto De Software 1 Ingeniero de Sistemas 1

Equipos Computador 2 Impresora 1 Internet 5 MB

Transporte Buses 2 diarios Materiales USB 32 GB

Fotocopias Papelería en General

Almacenamiento disponible en google

Drive 2 GB Servicios Públicos Energía Eléctrica

Teléfono Agua

Gastos de Alimentación 1 al día

Tiempo Meses 4

Tabla 26. Recursos requeridos en el proyecto. Fuente: Autores

CAPÍTULO 9. CRONOGRAMA

Tabla 27. Cronograma de Actividades. Fuente: Autores

Recolección de Información Planeación Diseño Ejecución (Metodología Kimball-Iteraciones) Pruebas

Fase (Actividad) Duración (Días)

Mes 1 Mes 2 Mes 3 Mes 4 Semana Semana Semana Semana

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Recolección de Información (Aduanilla de Paiba) 20 Digitalización Notas históricas (Notas) Digitación información Notas a Hojas de Excel Planeación 30 Análisis de metodología Kimball (iteraciones) Desarrollo del plan de trabajo Selección de roles Asignación de presupuesto Diseño 40 Determinar los requerimientos del Datamart Definición y diseño del modelo Dimensional Abstracción atributos medibles (Tabla de hechos) Asignación de las dimensiones al modelo dimensional Elaboración de procedimientos para el ETL Ejecución 20 Ejecución de las 8 iteraciones (Metodología) Desarrollo de mocktus para reportes Alistamiento de recursos físicos Pruebas 10 Prueba Unitaria Carga del ETL Mostrar información con reportes

CAPÍTULO 10. CONCLUSIONES El presente trabajo de pasantía tuvo como objetivo el diseñar y posteriormente implementar un Datamart encargado de administrar las notas históricas en la Universidad Distrital Francisco José de Caldas con los datos comprendidos desde 1960 hasta 1972 de las facultades de medio ambiente e ingeniería que se encontraban en libros físicos del archivo de la universidad, por ende la información que se encontraba de manera física y que era de difícil acceso con respecto a la búsqueda y en la logística de transportar los libros para emitir una certificación requerida, o datos solicitados por planeación, se convirtió en datos de entrada digitalizados que nutren el Datamart de notas históricas, conservando la calidad e integridad de la información y apoyando la toma de decisiones bajo el concepto de Business Intelligence respecto a los datos debidamente organizados en Base de Datos y visualizados en los portales de la Universidad Distrital. Para las pruebas realizadas se tomaron 462 registros de entrada digitados en tablas de Excel y la digitalización de cada una de las hojas físicas de los libros para preservar la evidencia tangible. Durante el periodo de tiempo mediante el cual se llevaron a cabo las pasantías de las cuales el presente documento sirve como informe, se realizaron diferentes etapas del diseño entre ellas el diseño del modelo conceptual, el diseño de lógico de la base datos, el diseño de un ETL (Extracción, transformación y carga de datos), y el diseño de un reporte donde se visualizara la información anteriormente procesada. El primer paso corresponde al levantamiento de requerimientos, que conlleva básicamente al entendimiento del negocio y las necesidades del área. El proceso de alistamiento de las fuentes de información que en este caso correspondían a libros físicos, y ser convertidos en archivos planos representa en tiempos de respuesta un mejoramiento abismal eliminando así procesos manuales para convertirlos en automáticos como la búsqueda de estudiantes con notas registradas. La integración con las diferentes herramientas de open source utilizadas por la Oficina Asesora de sistemas (OAS) permite una sincronización efectiva entre los datos y las operaciones transaccionales que se realizan con estos, lo cual permite integridad y calidad de los datos. El proceso de ETL desarrollado en Talend Open Studio, el proceso de guardar la información en las bases de datos Posgrest y el proceso de visualización de la información a los usuarios finales a partir de SPAGO BI son por ente procesos mutuamente incluyentes donde la salida de una representa bajo la teoría general de sistemas la entrada del otro

Un datamart que apoye y nutra el Datawarehouse de la Universidad Distrital es de vital importancia y apoya a la planeación de la universidad. Así mismo se mejora el proceso en el cual se expide certificaciones sobre las notas históricas de los estudiantes.

CAPÍTULO 11. BIBLIOGRAFÍA

Luhh, Hans Peter (1958). “A business Intelligence System” IMB Journal, October 1958.

Universidad Distrital Francisco José de Caldas (2011). Bodega de datos versión 0.0.1.0–, Bogotá, Colombia, 25 de Julio de 2011

Universidad Distrital Francisco José de Caldas (2011). Plan Maestro de

Informática y Telecomunicaciones página 125–, Bogotá, Colombia.

Inmon, W. H., (1996. Using the Data Warehouse). John Wiley & Sons

Inmon, Bill. (1999). Data Marts and the Data warehouse: Information Architecture for the millennium. New York: Informix.

Inmon, Bill. (2000). OLAP and the Data warehouse. New York: Informix

IBM (2005). (International Business Machines) Business Performance Management Meets Business Intelligence. New York: IBM Red Book

MSIP (1997). (Misión para la Sociedad de la Información en Portugal), “Livro Verde para a Sociedade da Informação em Portugal”, Lisboa

Europa Management Consulting (1996). Las tecnologías de la información

en la empresa. Madrid: Cinco Días.

Turban, E.; Aronson, J.E. (1998). Decision Support Systems and Intelligent Systems. (5a Ed.) New Jersey: Prentice Hall.

J. Daniel (1999). What is a decision support system?

Curto Díaz, Josep. (2010). Introducción al Business Intelligence.

Trujillo, J. C., Palomar M. (2001 ). Uso y diseño de Base de Datos Multidimensionales y almacenes de datos.

Warren Thornthwaite (Ralph Kimball Group). (2003). Data Warehouse Lifecycle in Depth. Lecture Note Taken by Arman Kanooni

Lane. (1999). Oracle 8i Data Warehousing guide

Kimball. (2008). The Data Warehouse Lifecycle Toolkit. 2nd Edition. New York, Wiley.

Kimball & Caserta. (2004). The Data Warehouse ETL Toolkit, Indianapolis, Wiley

The Data Warehouse ETL Toolkit: Practical Techniques for Extracting

Talend Connecting The Data-Driven Enterprise, Talend Open Studio for Data Integration User Guide (2017), Talend is a trademark of Talend, Inc. Open Source Documentation

Spago BI, SPAGO BI guide (2017). Open source documentation

BD Estrategia (2013), Tabla de hechos y dimensiones, Archivos mensuales (abril) https://bdestrategica.wordpress.com/2013/04/)

Rivadera , Gustavo R (2010). La metodología de Kimball para el diseño de almacenes de datos (Data warehouses). http://www1.ucasal.edu.ar/htm/ingenieria/cuadernos/archivos/5-p56-rivadera-formateado.pdf

https://bdestrategica.wordpress.com/2013/04/

http://www1.ucasal.edu.ar/htm/ingenieria/cuadernos/archivos/5-p56-rivadera-formateado.pdf

http://www1.ucasal.edu.ar/htm/ingenieria/cuadernos/archivos/5-p56-rivadera-formateado.pdf

diseÑo e implementaciÓn de un datamart para las...

Documents