anÁlisis, diseÑo y desarrollo de un almacÉn de datos...

ANÁLISIS, DISEÑO Y DESARROLLO DE UN ALMACÉN DE

DATOS PARA LA ADMINISTRACIÓN DE DATOS MAESTROS DE

ESPACIOS FÍSICOS DE LA UNIVERSIDAD DISTRITAL

FRANCISCO JOSÉ DE CALDAS

DANIEL FELIPE SOTO PEÑA

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

Bogotá D.C, 2016

ANÁLISIS, DISEÑO Y DESARROLLO DE UN ALMACÉN DE

DATOS PARA LA ADMINISTRACIÓN DE DATOS MAESTROS DE

ESPACIOS FÍSICOS DE LA UNIVERSIDAD DISTRITAL

FRANCISCO JOSÉ DE CALDAS


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

SISTEMAS

DIRECTOR:

Ing. Alejandro Daza Corredor

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

Bogotá D.C, 2016

Nota de aceptación:

___________________________

_____________________________

_____________________________

_____________________________

_____________________________

_____________________________

_____________________________

________________________________ Firma del Director del Trabajo de Grado

_________________________________ Firma del jurado

Bogotá. Noviembre de 2016

Dedicatoria

“Gracias a ella, los pisos de tierra golpeada, los muros de

barro sin encalar, los rústicos muebles de madera

construidos por ellos mismos estaban siempre limpios.”

Gabriel García Márquez

A mi amorosa madre, por supuesto.

AGRADECIMIENTOS

A la Oficina Asesora de Sistemas de la Universidad Distrital, en cabeza del

ingeniero Carlos Montenegro, y especialmente al ingeniero Jhon Gabriel

Castellanos, por su apoyo y disposición permanente, que hicieron posible el

desarrollo de este proyecto de la mejor manera.

A mi director de tesis, ingeniero Alejandro Daza Corredor, por darme la confianza

y el apoyo tan necesarios a lo largo de todo este proceso.

A todos los que compartieron un café conmigo, por prestarme un poco de su vida.

A mi madre Aída Rocío, por su apoyo incondicional, su incansable amor, sus

sabios consejos y su infinita paciencia; a ella en especial.

P á g i n a | 6

Daniel Felipe Soto Peña

TABLA DE CONTENIDO

INTRODUCCIÓN ......................................................................................................... 10

PARTE 1: CONTEXTUALIZACIÓN DEL PROYECTO ................................................ 12

1. PLANTEAMIENTO DEL PROBLEMA .................................................................. 12

1.1. Descripción del problema ........................................................................... 12

1.2. Formulación del problema .......................................................................... 13

2. JUSTIFICACION .................................................................................................. 13

3. OBJETIVOS ......................................................................................................... 15

3.1. Objetivo General .......................................................................................... 15

3.2. Objetivos Específicos ................................................................................. 15

4. DELIMITACIÓN .................................................................................................... 16

4.1. Alcances ....................................................................................................... 16

4.2. Limitaciones ................................................................................................. 16

5. MARCO REFERENCIAL ...................................................................................... 17

5.1. Antecedentes ............................................................................................... 17

5.2. Marco Teórico .............................................................................................. 18

5.2.1. Bases de Datos ..................................................................................... 18

5.2.2. Protocolo LDAP .................................................................................... 19

5.2.3. Extracción, Transformación y Carga de Datos ................................... 21

5.2.4. Almacén de Datos................................................................................. 26

5.2.5. Administración de Datos Maestros ..................................................... 29

5.2.6. Metodología Kanban ............................................................................ 31

5.2.7. Herramientas Tecnológicas Usadas.................................................... 33

5.3. Marco Contextual ......................................................................................... 35

5.4. StakeHolders ................................................................................................ 37

PARTE 2: DESARROLLO DEL PROYECTO .............................................................. 39

6. FASE DE PLANEACIÓN ...................................................................................... 39

6.1. Recolección de información previa ............................................................ 39

6.1.1. Acercamiento con la OAPC ................................................................. 39

6.1.2. Acercamiento con la OAS .................................................................... 42

6.2. Plan general del Proyecto ........................................................................... 46

6.2.1. Definición de Tarjetas Kanban ............................................................. 46

6.2.2. Definición de artefactos ....................................................................... 47

6.2.3. Definición de tareas .............................................................................. 49

7. FASE DE ANÁLISIS ............................................................................................ 52

7.1. Definición de Datos Maestros ..................................................................... 52

P á g i n a | 7


7.2. Base de Datos de Espacios Físicos ........................................................... 53

7.3. Esquema LDAP de Espacios Físicos ......................................................... 54

7.4. Almacén de Datos ........................................................................................ 56

7.5. Extracción de Datos. ................................................................................... 57

7.6. Transformación de datos ............................................................................ 57

7.7. Carga de Datos ............................................................................................ 58

8. FASE DE EJECUCIÓN ........................................................................................ 59

8.1. Preparación del entorno de trabajo ........................................................... 59

8.2. Creación de bases de datos relacionales .................................................. 59

8.3. Extensión del esquema LDAP .................................................................... 59

8.4. Elaboración de trabajos de Talend ............................................................. 61

8.4.1. ETL entre Base de datos relacional y LDAP ....................................... 61

8.4.2. ETL entre LDAP y Almacén de datos (Esquema Físico) .................... 63

8.4.3. ETL para registro de datos en la tabla de Hechos ............................. 64

8.4.4. Otros trabajos de apoyo ....................................................................... 65

9. FASE DE PRUEBAS ............................................................................................ 67

9.1. Preparación para pruebas de ETL a LDAP ................................................ 68

9.2. Pruebas ETL de Sedes ................................................................................ 68

9.3. Pruebas ETL de Edificios ............................................................................ 68

9.4. Pruebas ETL de espacios físicos ............................................................... 69

9.5. Pruebas de ETL de datos dimensionales ................................................... 70

9.6. Pruebas de ETL de la tabla de hechos ....................................................... 71

PARTE 3: CIERRE DEL PROYECTO ......................................................................... 72

CONCLUSIONES ........................................................................................................ 72

TRABAJOS FUTUROS ............................................................................................... 72

GLOSARIO DE TÉRMINOS ........................................................................................ 74

BIBLIOGRAFÍA ........................................................................................................... 76

ANEXOS ..................................................................................................................... 78

P á g i n a | 8


Índice de Figuras

Figura 1. Transformación multiproceso. Tomado de [8] ............................................... 24

Figura 2. Transformación secuencial de datos. Tomado de [8] .................................... 25

Figura 3. Tablas dimensionales y de hechos en un modelo dimensional. Tomado de [7]

.................................................................................................................................... 27

Figura 4. Elementos básicos de un almacén de datos. Tomado de [7] ........................ 29

Figura 5. Diagrama Relacional Base de Datos Actual Espacios Físicos. Fuente: Autor 36

Figura 6. StakeHolders del proyecto. Fuente: Autor ..................................................... 37

Figura 7. Atributos Asociados a Espacios Físicos. Adaptado de Anexo 1 .................... 40

Figura 8. Espacios físicos inventariados. Adaptado de Anexo 1 .................................. 41

Figura 9. Estructura de tipificación y clasificación de espacios. Adaptado de Anexo 1. 41

Figura 10. Arquitectura General Sistema CIRENE. Tomado de [22] ............................ 43

Figura 11. Esquema general de los almacenes de datos. Fuente: autor ...................... 44

Figura 12. Diagrama E-R de Base de Datos propuesto. Fuente: Autor ........................ 54

Figura 13. Diagrama del esquema lógico LDAP. Fuente: Autor ................................... 55

Figura 14. Diagrama Relacional Almacén de Datos. Fuente: Autor .............................. 57

Figura 15. Construcción del elemento EspacioFisico. Fuente: Autor ............................ 60

Figura 16. Proceso de extensión del esquema LDAP. Fuente: Autor. .......................... 61

Figura 17. Mapeo de sedes. Fuente: Autor .................................................................. 61

Figura 18. Mapeo de edificios. Fuente: Autor ............................................................... 62

Figura 19. Mapeo de espacios físicos. Fuente: Autor. .................................................. 62

Figura 20. Primera transformación de datos en Mapeo de espacios físicos. Fuente:

Autor. ........................................................................................................................... 63

Figura 21. ETL entre LDAP y almacén de datos. Fuente: Autor. .................................. 64

Figura 22. Segunda transformación de datos en mapeo de espacios físicos. Fuente:

Autor ............................................................................................................................ 64

Figura 23. ETL hacia la tabla de hechos. Fuente: Autor ............................................... 65

Figura 24. Transporte de datos hacia la tabla de hechos. Fuente: Autor...................... 65

Figura 25. Registro de eliminación de entradas en LDAP ............................................ 66

Figura 26. Carga desde archivo xls a LDIF. Fuente: Autor. .......................................... 66

Figura 27. Esquema lógico LDAP. Fuente: Autor ......................................................... 67

Figura 28. Resultado de pruebas a carga de sedes. Fuente: Autor .............................. 68

Figura 29. Resultado de pruebas de carga de edificios. Fuente: Autor. ....................... 68

Figura 30. Resultado de pruebas de carga de espacios físicos. Fuente: Autor. ........... 69

Figura 31. Esquema físico LDAP resultante. Fuente: Autor ......................................... 70

Figura 32. Resultado de pruebas de carga de datos dimensionales. Fuente: Autor ..... 70

Figura 33. Resultado de pruebas de carga de la tabla de hechos. Fuente: Autor. ....... 71

P á g i n a | 9


Índice de Tablas

Tabla 1. Tecnologías usadas por la Oficina Asesora de Sistemas. Fuente: Autor ........ 45

Tabla 2. Tarjeta Kanban 1. Fuente: Autor .................................................................... 46




Tabla 6. Artefactos tarjeta Kanban 1. Fuente: Autor .................................................... 47




Tabla 10. Tareas tarjeta Kanban 1. Fuente: Autor ....................................................... 49




Tabla 14. Tipos de Atributos LDAP Espacios físicos. Fuente: Autor ............................ 55

Tabla 15. Clase de Objeto EspacioFisico. Fuente: Autor ............................................. 56

Tabla 16. Valores por defecto. Proceso de trasformación. Fuente: Autor..................... 58

P á g i n a | 10


INTRODUCCIÓN

La minería de datos dentro de una organización se ha convertido en una

herramienta fundamental para la toma de decisiones tanto a nivel ejecutivo como

técnico, ya que permite la abstracción de información de interés gerencial que de

otra forma sería imposible analizar. Por el contrario, la falta de administración

sobre grandes cantidades de datos obliga a las organizaciones a comportarse de

manera reactiva ante las potenciales situaciones adversas, pues no poseen un

historial de su propio comportamiento en el pasado y dependen exclusivamente

de la experiencia de quienes toman las decisiones.

Una bodega de datos es el recurso principal del proceso de minería de datos,

pues es el mecanismo en el cual se almacenan y se consultan los cambios

históricos de la organización reflejados en los diferentes estados de la

información en el transcurso de los años. Este sistema está conformado

principalmente por subsistemas llamados “almacenes”, que se especializan en el

bodegaje de los datos de un área específica de la organización.

En el ámbito de una organización que tiene como objeto social la educación de

los ciudadanos, como lo es la Universidad Distrital Francisco José de Caldas, la

técnica de minería de datos brinda un valor agregado al proceso de formación

vocacional de sus estudiantes, pues permite optimizar mediante la

automatización y el análisis computacional procesos administrativos y

académicos que históricamente han tenido falencias por la falta de integración de

la información.

De esta manera una bodega de datos le permite a la Institución conocer

información acerca del desempeño de sus estudiantes, el comportamiento

histórico de la tasa de deserción y la adaptación de la planta física a las

necesidades propias de su actividad entre otras, mediante la integración de

información de los diferentes almacenes que la conforman.

En este documento se describen las fases de análisis, diseño y desarrollo de un

almacén de datos que provee información acerca de la administración de

espacios físicos de la Universidad Distrital Francisco José de Caldas, de tal

manera que sirva como recurso para los procesos de minería de datos sobre la

información de inventarios y asignación de salones, salas, auditorios y demás.

Su estructura está compuesta por tres secciones principales: contextualización,

desarrollo y cierre del Proyecto. En la primera parte se define el contexto en el

P á g i n a | 11


cual se desarrolló el proyecto, describiendo el problema y las estrategias para

solucionarlo así como los elementos teóricos requeridos para abordar el tema. En

la segunda sección se describe el desarrollo del proyecto, el cual fue ejecutado

en cuatro fases (planeación, análisis, ejecución y pruebas) que permitieron

cumplir los objetivos planteados garantizando en todo caso la solución del

problema. Por último, el proyecto concluye haciendo un análisis de los objetivos

logrados y planteando tres trabajos propuestos a desarrollar a partir de este.

P á g i n a | 12


PARTE 1: CONTEXTUALIZACIÓN DEL

PROYECTO

1. PLANTEAMIENTO DEL PROBLEMA

1.1. Descripción del problema

El Sistema de Información del Plan Maestro de Desarrollo Físico de la

Universidad Distrital Francisco José de Caldas comprende la definición de un

modelo de información geoespacial y de edificios por sede, de carácter distribuido

y con una estructura de datos utilizada para la representación de la información

de arquitectura e ingeniería acorde con el Plan de Ordenamiento Territorial de

Bogotá. [2]

En la adopción de este Plan se estableció como política general implementar un

Sistema Integral para la Planeación, Administración y Protocolo de

Mantenimiento de la Planta Física general, apoyado en un Sistema de

Información General, con el fin de reglamentar la organización espacial, el uso y

administración de los espacios para el óptimo funcionamiento de la infraestructura

Institucional. [2]

La Oficina Asesora de Planeación y Control (en adelante OAPC), mediante el

Grupo de Desarrollo Físico actualmente gestiona la administración de espacios

físicos mediante el Sistema de Administración de la Planta Física SAPF-UD, el

cual articula y establece los medios tecnológicos, normativos y procedimentales

necesarios para gestionar la red de sedes que conforman el Campus

Universitario.

La Oficina Asesora de Sistemas (en adelante OAS), se ha propuesto la tarea de

centralizar la administración del conocimiento en un único Sistema de Información

denominado Bodega de Datos [1]. Lo anterior le obliga a realizar investigaciones

preliminares que le indiquen el estado actual de los datos generados por las

P á g i n a | 13


diferentes dependencias de la Universidad y tomarlos como punto de partida para

la ejecución del proyecto.1

La información generada por el Grupo de Desarrollo Físico, mediante SAPF-UD

está aislada de la Bodega de Datos desarrollada por la OAS, pues no existe

actualmente una interfaz que posibilite la comunicación y el transporte de datos

entre los Sistemas SAPF-UD (de la OAPC) y Bodega de Datos (de la OAS)

1.2. Formulación del problema

¿Qué modelo de información permite realizar un análisis de los datos generados

por la Oficina Asesora de Planeación y Control respecto a espacios físicos que

se adapte a las políticas de gestión de información que maneja la Oficina Asesora

de Sistemas?

2. JUSTIFICACION

Debido a la necesidad creciente de un análisis transversal de la información

contenida en todas las dependencias, se hace necesaria la unificación de los

datos generados a partir del funcionamiento de cada una de ellas, sin embargo,

debido a la diversidad de circunstancias en las que se han creado estos datos,

en la actualidad no es posible construir una base de información sólida y uniforme

que permita a los diferentes interesados obtener conocimiento aprovechable de

éstos.

Dentro de cada sistema de información manejado por las dependencias se

pueden encontrar datos de distintos tipos:

No estructurados, como los encontrados en documentos de texto plano,

portales de intranet, archivos PDF, entre otros

Transaccionales, que son un tipo relacionado con interacciones dentro de

un sistema de datos, como información de ingreso de estudiantes, de

movimiento de inventarios, seguimiento de casos, etcétera.

Metadatos, que son aquellos que brindan información sobre otros datos y

pueden encontrarse en forma de documentos XML, plantillas, descripción

de columnas en una base de datos y archivos de configuración.

1 Proyección Bodega de Datos. Plan Maestro de Informática y Telecomunicaciones [1]

P á g i n a | 14


Jerárquicos, que guardan información sobre las relaciones entre los demás

datos. Pueden estar incluidos dentro de un sistema de información o

separadamente como descripciones de relaciones entre entidades en el

mundo real.

Maestros, que se definen como críticos para cualquier organización y son

el motivo central por el cual se realiza una administración de Datos.

Pueden organizarse en cuatro grupos: personas, cosas, lugares y

conceptos.

De lo anterior surge la necesidad de establecer un procedimiento de

Administración de Datos Maestros para la construcción de un almacén de Datos

que brinde un tratamiento especializado de la gran cantidad de información

consignada, generada y transformada por el Grupo de Desarrollo Físico de la

OAPC orientado por las políticas de la OAS

P á g i n a | 15


3. OBJETIVOS

3.1. Objetivo General

Realizar el análisis, diseño y desarrollo de un almacén de datos que contenga la

información relevante generada por el Grupo de Desarrollo Físico de la Oficina

Asesora de Planeación y Control y permita una integración con los demás

almacenes de datos desarrollados por la Oficina Asesora de Sistemas.

3.2. Objetivos Específicos

Conocer el funcionamiento general del Sistema de Administración de la

Planta Física SAPF-UD, con el fin de establecer las interfaces de

comunicación con el almacén de datos de Espacios Físicos.

Realizar el levantamiento de la información relevante de acuerdo a los

criterios de la Oficina Asesora de Sistemas de la Universidad Distrital

Francisco José de Caldas con el objetivo de establecer la arquitectura del

almacén de datos.

Realizar los procesos requeridos de extracción, transformación y carga de

datos con el fin de lograr la estandarización de la información de acuerdo

a las políticas de la Oficina Asesora de Sistemas.

Realizar el diseño y desarrollo de un almacén de datos que albergue la

información relevante generada por la división de espacios físicos de la

Oficina Asesora de Planeación y Control.

Desarrollar procesos de extracción, transformación y carga de datos entre

el esquema LDAP y el almacén de datos creados con el fin llevar a cabo

la estandarización y disponibilidad de la información.

P á g i n a | 16


4. DELIMITACIÓN

4.1. Alcances

Se realizó un prototipo de base de datos de la división de espacios físicos

de la Oficina Asesora de Planeación y Control sobre la cual se hizo

extracción de información relevante para la Oficina Asesora de Sistemas

de la Universidad Distrital Francisco José de Caldas.

Se diseñó y desarrolló un almacén de datos de una dimensión para

espacios físicos a partir de la información que maneja la OAPC de la

Universidad Distrital Francisco José de Caldas y que es de importancia

para la OAS por su rol de administrador de la Bodega de Datos.

Se creó un esquema de datos LDAP para la estandarización de la

información que sirve de intermediario entre la base de datos de la división

de espacios físicos de la OAPC y el almacén de datos de la OAS de la

Universidad Distrital Francisco José de Caldas.

Se desarrollaron los procesos ETL entre la base de datos de Espacios

Físicos, el esquema LDAP y el Almacén de Datos.

4.2. Limitaciones

El proceso de Administración de Datos Maestros se limitó al tratamiento

de los datos de espacios físicos que maneja actualmente la OAPC,

dejando documentado el procedimiento realizado de tal manera que sirva

como antecedente y modelo para su implementación con almacenes de

datos de otras dependencias.

Se realizó la documentación referente al proceso realizado únicamente

para la administración de datos maestros de espacios físicos.

De acuerdo a las políticas de la OAS, las cuales se rigen por los

lineamientos de la Universidad Distrital Francisco José de Caldas, se

trabajaron herramientas libres para el desarrollo del software necesario.

P á g i n a | 17


5. MARCO REFERENCIAL

5.1. Antecedentes

En el Plan Estratégico de Desarrollo 2008-2016 de la Universidad Distrital

Francisco José de Caldas [3] se estableció como política de la Institución la

modernización de la gestión administrativa, financiera y del talento humano. Una

de las estrategias que se propuso para alcanzar esta meta fue la del

mejoramiento de la productividad de los recursos institucionales, mediante el

desarrollo de un programa titulado “Desarrollo de un sistema integrado y

articulado de información de la gestión académica y administrativa de la

Universidad”2.

En junio de 2009, mediante resolución 015 del Consejo Superior, se adopta el

Plan Maestro de Desarrollo Físico [2], cuya política número siete “Sostenibilidad

de la Infraestructura Física” resuelve implementar un Sistema Integral para la

Planeación, Administración y Protocolo de Mantenimiento de la Planta Física

general, apoyado en un SIG, con el fin de reglamentar la organización espacial,

el uso y administración de los espacios para el óptimo funcionamiento de la

infraestructura Institucional.

Adicionalmente en el Artículo N° 29 de la mencionada Resolución se estableció

lo siguiente:

“DOCUMENTOS Y PROYECTOS A ELABORAR: Son componentes

determinantes en la formulación de los planes de consolidación y desarrollo de

proyectos específicos, los estudios y diseños que se realicen para tal fin, labores

a desarrollar en la Oficina Asesora de Planeación y Control y Control:

a. Inventario Físico Espacial: Actualización de Áreas, Usos y Planimetría.

b. Formulación del Plan General de Ordenamiento Físico de la universidad.

c. Implementar herramientas tecnológicas (SIG) como soporte administrativo

de los espacios físicos de la Universidad.”

De igual manera, la Resolución N° 1101 de 2002, por la cual se establece el

Manual Descriptivo de Funciones Generales y Específicas de la Universidad

Distrital; establece como macro función de la Oficina Asesora de Planeación y

Control la de “Establecer sistemas modernos de información que faciliten la

gestión y el control”.

2 Punto 2.4.4.1. Artículo primero del Acuerdo 01 de 2008.

P á g i n a | 18


En octubre de 2012 la OAS de la Universidad presentó el Plan Maestro de

Informática y Telecomunicaciones 2012-2018 [1] en el cual publica el desarrollo

de una Bodega de Datos en su fase número 1, cuyo objetivo es integrar fuentes

no homogéneas de información, construyendo un sistema de conocimiento

confiable, íntegro y coherente con las necesidades de información de la

Institución. Cita en el documento como logros el diseño, desarrollo e

implementación de almacenes de datos de algunas divisiones pero reconoce

problemas para la consolidación de la bodega debidos a la baja calidad o la falta

de información en algunas fuentes3.

Según información suministrada por la OAPC, la OAS y la OAPC están

trabajando articuladamente para lograr al mes de diciembre del año en curso el

“Diseño e implementación de interfaces para la administración, sostenibilidad y

acceso a la información de la Base de Datos Espacial” que soporte la etapa de

visualización del SIG institucional y la consolidación de la Información geográfica

mediante la migración de la misma a la base de datos acorde a un modelo lógico

validado por la OAS e integrado con el Sistema de Gestión académica - Cóndor,

con el fin de poner a servicio de la comunidad universitaria la IG asociada a la

planta física de la UDFJC. (Anexo 1).

En la actualidad el proyecto de Bodega de Datos cuenta con ocho Almacenes de Datos que se encuentran en fase de implementación (Admisiones, Bienestar institucional, Contratación, Egresados, Docencia, Administración financiera, Investigaciones, Proyectos curriculares), pero carece de un almacén de datos que articule la información referente a Espacios Físicos.

5.2. Marco Teórico

Se definen a continuación los conceptos más relevantes concernientes a bases

de datos, protocolos LDAP, procesos ETL, almacén de datos, administración de

datos maestros y la metodología KANBAN que serán utilizados en el proyecto.

5.2.1. Bases de Datos

Según Silverschatz [4], una colección de datos, normalmente denominada base

de datos, contiene información relevante para una organización. Un sistema

gestor de bases de datos es una herramienta de software cuya responsabilidad

es proporcionar una forma de almacenar y recuperar la información de una base

de datos de manera que sea tanto práctica como eficiente.

3 Punto 3. Plan Maestro de Informática y Telecomunicaciones

P á g i n a | 19


5.2.1.1. Modelo de Datos

Bajo la estructura de la base de datos se encuentra el modelo de datos: una

colección de herramientas conceptuales para describir los datos, las relaciones,

la semántica y las restricciones de consistencia. Los diferentes modelos

propuestos históricamente se clasifican en tres grupos diferentes: lógicos

basados en objetos, lógicos basados en registros y físicos.

5.2.1.2. Modelo Entidad – Relación

El modelo de datos entidad-relación (E-R) está basado en una percepción del

mundo real que consta de una colección de objetos básicos, llamados entidades,

y de relaciones entre ellos. Una entidad es una «cosa» u «objeto» en el mundo

real que es distinguible de otros. Por ejemplo, cada persona es una entidad, y los

espacios físicos de una organización pueden ser estudiados como entidades. Las

entidades se describen en una base de datos mediante un conjunto de atributos.

5.2.1.3. Modelo Relacional

En el modelo relacional se utiliza un grupo de tablas para representar los datos y

las relaciones entre ellos. Cada tabla está compuesta por varias columnas, y cada

columna tiene un nombre único.

El modelo relacional es un ejemplo de un modelo basado en registros. Los

modelos basados en registros se denominan así porque la base de datos se

estructura en registros de formato fijo de varios tipos. Cada tabla contiene

registros de un tipo particular. Cada tipo de registro define un número fijo de

campos, o atributos. Las columnas de la tabla corresponden a los atributos del

tipo de registro.

El modelo de datos relacional es el modelo más ampliamente usado, y una gran

mayoría de sistemas de bases de datos actuales se basan en el modelo relacional

5.2.2. Protocolo LDAP

LDAP es un protocolo de comunicación usado para acceder a información

guardada centralmente a través de la red [5]. Está basado en el estándar X.500

para compartir directorios, pero es menos complejo e intensivo en el uso de

recursos. Por esta razón, a veces se habla de LDAP como "X.500 Lite." El

estándar X.500 es un directorio que contiene información de forma jerárquica y

categorizada, que puede incluir nombres, directorios y números telefónicos.

P á g i n a | 20


Como X.500, LDAP organiza la información en un modo jerárquico usando

directorios. Estos directorios pueden almacenar una gran variedad de información

y se pueden incluso usar de forma similar al Servicio de información de red (NIS),

permitiendo que cualquiera pueda acceder a su cuenta desde cualquier máquina

acreditada en la red con LDAP.

Sin embargo, en la mayoría de los casos, LDAP se usa simplemente como un

directorio telefónico virtual, permitiendo a los usuarios acceder fácilmente la

información de contacto de otros usuarios. Pero LDAP va mucho más lejos que

un directorio telefónico tradicional, ya que es capaz de propagar su consulta a

otros servidores LDAP por todo el mundo, proporcionando un repositorio de

información ad-hoc global. Sin embargo, en este momento LDAP es mayormente

usado dentro de organizaciones individuales, como universidades,

departamentos del gobierno y compañías privadas.

LDAP es un sistema cliente/servidor. El servidor puede usar una variedad de

bases de datos para guardar un directorio, cada uno optimizado para operaciones

de lectura rápidas y en gran volumen. Cuando una aplicación cliente LDAP se

conecta a un servidor LDAP puede, o bien consultar un directorio, o intentar

modificarlo. En el evento de una consulta, el servidor, puede contestarla

localmente o puede redirigirla a otro servidor LDAP que tenga la respuesta. Si la

aplicación cliente está intentando modificar información en un directorio LDAP, el

servidor verifica si el usuario cuenta con los permisos necesarios para efectuar el

cambio y después añade o actualiza la información. [6]

Las bodegas de datos pueden estar en riesgo si existen muchas maneras de

acceder a ellas, asimismo, pueden verse comprometidas si la seguridad no está

controlada de una manera centralizada. Una solución apropiada para estos

problemas es el uso de un servidor LDAP el cual controle todos los accesos que

se den fuera del Gateway a la bodega de datos. El servidor LDAP permite que

todas las solicitudes de los usuarios sean autenticadas de una manera uniforme

sin importar si están dentro o fuera del edificio o si provienen de una ubicación

remota a través de Internet. Una vez autenticado el usuario, el servidor del

directorio lo asocia a un rol. Después, el servidor de la aplicación (basado en el

rol del usuario) toma la decisión de si las credenciales de la persona le dan

privilegios para visualizar la información. Como las bodegas de datos crecen

hasta el punto de llegar a miles de usuarios y cientos de roles distintos, las

ventajas de esta arquitectura de cuello de botella se vuelve fundamental. [7]

De esta manera, se puede decir que la mayor ventaja de LDAP es que se puede

consolidar información para toda una organización dentro de un repositorio

central. Por ejemplo, en vez de administrar listas de usuarios para cada grupo

P á g i n a | 21


dentro de una organización, es posible usar LDAP como directorio central,

accesible desde cualquier parte de la red. Puesto que LDAP soporta la Capa de

conexión segura (SSL) y la Seguridad de la capa de transporte (TLS), los datos

confidenciales se pueden proteger de los curiosos.

LDAP también soporta un número de bases de datos back-end en las que se

guardan directorios. Esto permite que los administradores tengan la flexibilidad

para desplegar la base de datos más indicada para el tipo de información que el

servidor tiene que diseminar. También, ya que LDAP tiene una interfaz de

programación de aplicaciones (API) bien definida, el número de aplicaciones

acreditadas para LDAP son numerosas y están aumentando en cantidad y

calidad. [6]

5.2.3. Extracción, Transformación y Carga de Datos

Los procesos de Extracción, Transformación y Carga (ETL por sus siglas en

inglés) se encargan de extraer, integrar y limpiar los datos de fuentes

operacionales para alimentar la bodega de datos. En una arquitectura de tres

capas, los procesos ETL alimentan la capa de conciliación (una fuente de datos

de alta calidad, única, detallada y completa) que en su momento se encarga de

alimentar la bodega de datos. Por esta razón, los ETL son vistos frecuentemente

como una “reconciliación”. Asimismo, son los pasos más complejos y

técnicamente desafiantes del proceso de DataWhareHousing.

Estos procesos se empiezan a utilizar cuando la bodega recibe los primeros datos

y desde entonces se utilizan cada vez que se realicen actualizaciones en ella.

Oracle, en su guía de DataWhareHousing de Bases de Datos [8], ofrece una

buena identificación y definición de cada uno de estos procesos:

5.2.3.1. Proceso de extracción

De acuerdo con Oracle, en el proceso de extracción los datos son identificados,

y extraídos de diferentes fuentes incluidas bases de datos y aplicaciones.

Frecuentemente no es posible identificar los sobconjuntos de datos de interés,

por tanto más información de la estrictamente necesaria es extraída. La

identificación de datos relevantes será hecha más adelante en el proceso. De

acuerdo con las capacidades técnicas del sistema origen, algunas

transformaciones pueden hacerse en el momento de la extracción. El tamaño de

los datos en la extracción varía entre varios cientos de kilobytes a Gigabytes

P á g i n a | 22


dependiendo de la información y las necesidades del negocio. Igualmente, el

tiempo de extracción puede estar entre minutos, horas e incluso días. Algunos

servidores, por ejemplo llegan a crecer cientos de megabytes en periodos de

tiempo muy cortos.

a. Métodos de extracción lógica

Existen dos tipos de extracción lógica:

Extracción completa. En ella la totalidad de los datos del sistema son

obtenidos. En este tipo de extracción no es necesario hacer un análisis de

cambios sobre la base de datos, además sólo la información de la base es

proveída, sin datos adicionales como tiempo de extracción ni diferencias o

cálculos adicionales. La mayor desventaja de este mecanismo es,

obviamente el transporte innecesario de datos y la reescritura de los

mismos en los sistemas destino.

Extracción incremental: En un tiempo determinado, sólo la información que

ha cambiado desde el último evento definido será obtenida. Este evento

puede ser la última extracción, un periodo de tiempo o un evento

importante para la organización (como cierre contable o fin de mes). Para

identificar la información que ha cambiado se puede construir una columna

adicional que indique el tiempo de la última modificación en cada registro

o mediante una tabla de auditoría que guarda los últimos cambios hechos

en la base de datos. El segundo método requiere generar una lógica de

extracción adicional.

Generalmente las bodegas de datos no utilizan la extracción incremental del

lado del sistema origen. En su lugar, extraen toda la información de las tablas

y las comparan con la guardada en la bodega con el fin de almacenar

únicamente aquella que ha sido cambiada o actualizada. Esta técnica hace

que el proceso sea mucho más rápido en el sistema origen, pero puede afectar

el rendimiento de la bodega, especialmente si el tamaño de la información es

muy grande.

b. Métodos de extracción física

Dependiendo del método de extracción lógica escogido, la información puede ser

extraída físicamente por dos mecanismos: con una estructura en línea o fuera de

servicio. Esta estructura puede haber sido generada previamente por una rutina

de extracción. Estos son:

P á g i n a | 23


Extracción en línea. La información es extraída directamente del sistema.

El objeto encargado de la extracción puede conectarse directamente al

sistema origen para acceder a las tablas de este o a un sistema intermedio

que guarda la información de una manera especial previamente

configurada. Es de notar que este sistema intermedio no tiene que estar

necesariamente físicamente fuera del sistema origen.

Extracción fuera de línea. La información no es extraída directamente del

sistema origen pero es almacenada estrictamente fuera del mismo. Esta

información ya tiene una estructura predefinida o fue previamente creada

por una rutina de extracción.

Las estructuras de información extraídas generalmente se encuentran en los

siguientes formatos:

Archivos planos. En los que los datos se guardan con una estructura pero

es necesaria información del sistema origen para que puedan ser

interpretadas.

Archivos de backup. Los datos se guardan en el lenguaje de la base de

datos de origen, con lo que son fácilmente interpretados.

Archivos de log. En ellos se guarda información adicional de la estructura

de origen.

Espacios de tablas transportables. En algunos sistemas existen ciertos

tipos de archivos que guardan los datos de una manera que permiten ser

interpretados directamente como tablas dentro de la bodega de datos.

5.2.3.2. Proceso de transformación

La transformación de los datos generalmente es la más compleja y, en términos

de tiempo de procesamiento, la más costosa parte del proceso ETL. Las

operaciones pueden variar desde las más sencillas técnicas de conversión de

datos hasta complejas técnicas de depuración. La mayoría (si no todas) de las

transformaciones se dan dentro de la base de datos origen.

a. Flujos de transformación

Desde el punto de vista de la arquitectura, los datos se pueden transformar de

dos formas:

Transformación multiproceso. El proceso de extracción en muchas bases

de datos consiste en múltiples pasos. Por ejemplo, en la transformación de

múltiples registros cuando se van a insertar en una tabla de ventas, pueden

haber varios pasos diferentes para validar cada porción de la información.

P á g i n a | 24


En la figura 1 se muestra de forma gráfica ésta lógica de transformación.

Una estrategia común es implementar cada transformación como una

operación SQL aislada y crear una tabla provisional a parte

(new_sales_step1 y new_sales_step2 en la figura 1) para almacenar los

resultados incrementales de cada paso. Esta estrategia de carga-luego-

transforma también provee un esquema natural de puntos de restauración

que logra que el proceso sea más fácilmente monitoreado y reiniciable. En

contraste, una desventaja de esta estrategia es que los tiempos y

requerimientos de espacio aumentan.

Transformación secuencial. Aquí el flujo de ETL cambia dramáticamente y

la base de datos se convierte en una parte integral de la solución ETL.

Figura 1. Transformación multiproceso. Tomado de [8]

En esta técnica la tarea de transformación puede cambiar fácilmente de la

técnica transforma-luego-carga (usada en la mayoría de procesos ETL) o

de la carga-luego-transforma a una técnica mejorada de transforma-

mientras-cargas. Con lo que se logra que la tarea de transformación sea

más escalable y transaccional. Su desventaja es que, al ser vista como

una transacción, no posee puntos de restauración con lo que se debe

asegurar que el canal de comunicación sea lo más fiable posible para

evitar pérdidas en la información. Esta técnica se ilustra en la figura 2

P á g i n a | 25


Figura 2. Transformación secuencial de datos. Tomado de [8]

5.2.3.3. Proceso de Carga

El momento de cargar la información a la bodega de datos es relativamente el más

sencillo, pues toda la información está formateada de tal manera que es admisible por el

esquema de la bodega de datos. Desde luego, en esta etapa la información ya tiene que

estar disponible para la bodega de datos, ya sea en archivos planos, archivos de backup

o tablas.

Existen varias técnicas para la carga de información en esta tarea.

Carga mediante SQL. El motor de la bodega de datos carga la información desde

un archivo plano y puede a su ver realizar las últimas transformaciones que hagan

falta (como el tratamiento por defecto de algunos campos nulos). Muchas

bodegas de datos utilizan este método para cargar los datos por cuestiones de

eficiencia en rendimiento.

Carga mediante tablas. Algunos motores permiten construir tablas virtuales con

los datos requeridos, las cuales pueden ser consultadas y unidas mediante

peticiones en lenguaje SQL como una tabla convencional. Con este recurso los

procesos de transformación y carga se pueden hacer simultáneamente y sin

riesgo de pérdida de la información entre ellos.

Carga mediante OCI y APIs

Esta técnica es usada cuando los datos son transformados y analizados fuera de

la base de datos fuente y no es necesario tener un mecanismo intermedio. Es

decir cuando se puede contar con la base de datos dentro del entorno de la

bodega de datos

Carga Directa. En esta técnica la información es cargada como viene de la base

de datos y no es posible realizar operaciones complejas de transformación y

carga.

P á g i n a | 26


5.2.4. Almacén de Datos

Kimball [7] ofrece la definición de algunos conceptos referentes a

DataWarehousing y almacén de datos que es pertinente rescatar, pues su

lenguaje es relativamente sencillo y fácil de interpretar.

5.2.4.1. Tabla de Hechos

Una Tabla de Hechos es el elemento principal en un modelo dimensional, donde

las medidas numéricas de desempeño del negocio son almacenadas. De lo

anterior puede definirse un Hecho como una medida del negocio. Para

entenderlo mejor podemos situarnos en un supermercado observando qué

productos son vendidos y anotando la cantidad vendida y la cantidad en dinero

vendida de cada producto en la tienda. Una medida es tomada en la intersección

de todas las dimensiones (día, producto, y tienda) esta lista de dimensiones

define la granularidad de la tabla e indica el cuál es el objetivo de la medición.

Por tanto, un registro en una tabla de hechos corresponde a una medición. Así

mismo, una medición es un registro en una tabla de hechos y todas las

mediciones en una tabla deben tener la misma granularidad.

5.2.4.2. Tablas Dimensionales

Las tablas dimensionales (también llamadas tablas de dimensiones) son

analogías integrales de las tablas de hechos. Estas contienen los descriptores

textuales del negocio. En un modelo dimensional correctamente diseñado las

tablas dimensionales tienen muchas columnas (o atributos) Estos atributos

describen las filas en la tabla. Es común, por lo tanto que una tabla dimensional

contenga entre 50 y 100 atributos. Estos elementos tienden a crecer

exponencialmente (usualmente alrededor de un millón de filas). Cada dimensión

es definida por una llave primaria simple que sirve como base para la integridad

referencial con cualquier tabla de hechos dada con la cual puede ser cruzada.

5.2.4.3. Relación entre tablas de hechos y tablas dimensionales.

Como se ilustra en la figura 3. La tabla de hechos, que contiene mediciones

numéricas es cruzada con un conjunto de tablas de dimensión, las cuales

contienen atributos descriptivos. Esta estructura cuya forma se asemeja a una

estrella es usualmente llamada esquema de unión en estrella.

P á g i n a | 27


Figura 3. Tablas dimensionales y de hechos en un modelo dimensional. Tomado de [7]

Resalta en primer lugar que el esquema resultante es simétrico y simple.

Evidentemente los usuarios de los datos se benefician de la simplicidad ya que

de este modo los datos serán más fáciles de entender y navegar. Además, se ha

reducido el número de tablas y se distingue el uso de descriptores de negocio

con significado.

5.2.4.4. Almacén de Datos

Según Kimball [7] un Almacén de Datos se define como “una copia de los datos

transaccionales estructurados específicamente para consultas y análisis”, así

mismo, Imhoff [9] lo describe como una colección de datos orientada a un

determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable

en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza.

Se trata, sobre todo, de un historial completo de la organización, más allá de la

información transaccional y operacional, almacenada en una base de datos

diseñada para favorecer el análisis y la divulgación eficiente de datos

(especialmente con herramientas OLAP, de procesamiento analítico en línea).

Datawarehousing es un proceso, no un producto. Se trata de una técnica para

consolidar y administrar datos de variadas fuentes con el propósito de responder

preguntas de negocios y tomar decisiones, de una forma que no era posible hasta

ahora, consolidar datos desde una variedad de fuentes, manejar grandes

volúmenes de datos de una forma que no era posible, o no era costo efectiva. A

estos medios se les puede agrupar en Procesamiento y Administración de Datos.

Acceder a los datos de una forma más directa, en "el lenguaje del negocio", y

analizarlos para obtener relaciones complejas entre los mismos. Estos procesos

se engloban en dos categorías: Acceso a los Datos y Descubrimiento o minería

de datos.

P á g i n a | 28


5.2.4.5. Requerimientos que debe cumplir un Almacén de Datos

Las necesidades de las organizaciones respecto al manejo de datos suelen ser

universales, a continuación se presenta una lista de requerimientos que recoge

estas necesidades:

● La información de la compañía debe ser accesible fácilmente

● Se debe presentar la información de la organización de manera

consistente

● El almacén de Datos debe ser adaptable y resistente al cambio

● El almacén de Datos debe ser una fortaleza que protege la información

● El almacén de Datos debe servir como fundamento para mejorar la toma

de decisiones

● La comunidad de usuarios debe aceptar y considerar exitoso el almacén

de Datos

5.2.4.6. Componentes de un Almacén de Datos

Existen cuatro componentes a tener en consideración cuando se intenta construir

una bodega de datos: Sistemas Operativos de Origen, Área intermedia de

procesamiento de datos, área de presentación de datos y herramientas de acceso

a datos [7]. A continuación se da una breve definición de cada una de ellas.

5.2.4.7. Sistemas Operativos de Origen

Un sistema de almacenamiento utiliza fuentes heterogéneas de datos. Esos se

almacenan originalmente en la base de datos relacional o en bases de datos

legadas, también pueden provenir de sistemas de información externos a la

empresa. Todos estos son los Sistemas Operativos de Origen.

5.2.4.8. Área intermedia de procesamiento de datos

En esta área se materializan los datos operativos obtenidos después de la

integración y la limpieza de datos desde el origen. Como resultado, los datos son

integrados, coherentes, actuales y detallados.

P á g i n a | 29


5.2.4.9. Área de presentación de datos

La información es almacenada en un repositorio centralizado denominado data

warehouse o bodega de datos. El data warehouse puede ser accedido

directamente, pero este también puede ser usado como fuente para creación de

data marts, los cuales parcialmente replican contenidos de los data warehouse y

son diseñados por necesidades de dependencias específicas en una empresa.

Los repositorios que contienen la meta data almacenan información como

fuentes, procedimientos de acceso, extracción de datos, usuarios, esquemas de

data mart, etc.

5.2.4.10. Herramientas de acceso a datos

En esta capa, la integración de datos es eficiente y de acceso flexible para

generar informes, analizar la información de forma dinámica y simular escenarios

hipotéticos de negocio. Esta capa debe funcionar con navegadores de datos

agregados, optimizadores de consultas complejas, y con interfaces gráficas de

usuario de fácil manejo.

La figura 4 muestra un diagrama descriptivo de los elementos básicos de un

almacén de datos.

Figura 4. Elementos básicos de un almacén de datos. Tomado de [7]

5.2.5. Administración de Datos Maestros

De acuerdo con IBM [10] “los datos maestros aquellos que describen uno o más

atributos de entidades centrales como clientes, proveedores, productos e

P á g i n a | 30


inventario.” por tanto estos datos son de bastante utilidad cuando se requiere

caracterizar la información socialmente, económicamente, etc.

Ahora bien. La administración de datos maestros describe un conjunto de

disciplinas, tecnologías y soluciones utilizadas para crear y mantener datos

coherentes, completos, contextuales y precisos de todas las partes (usuarios,

aplicaciones, almacenes de datos, procesos y socios).

La clave para la administración de datos maestros es la “gestión”. Este proceso

no crea nuevos datos o nuevos entornos aislados de datos, sino que proporciona

un método mediante el cual una organización puede gestionar de manera eficaz

datos ya presentes en distintos sistemas. La gestión de datos maestros utiliza los

sistemas presentes, recopilando información de cada uno de dichos sistemas y

proporcionando la tecnología y procesos que automaticen y validen la distribución

y análisis preciso y oportuno de datos en toda la empresa.

Algunos de los atributos de una solución de gestión de datos maestros incluyen:

● Consolidación de los conocimientos de clientes, de otras fuentes y de los

entornos aislados existentes en el ámbito de toda la empresa

● Repartición de datos en todos los sistemas como un conjunto de procesos

y servicios empresariales centrados en torno al cliente

● Maestro común para todos los clientes, productos y proveedores para

acelerar la entrada, recuperación y análisis de datos

● Soporte de múltiples usuarios de los datos, incluyendo la capacidad de

limitar la posibilidad de que los usuarios añadan, actualicen o vean

procesos que mantienen los datos maestros

● Integración de la gestión de información de productos, gestión de

relaciones con clientes, integración de datos de clientes y otras soluciones

que proporcionan acceso al análisis de los datos maestros.

Debido a que los métodos y procesos asociados con la gestión de datos maestros

funcionan independientemente de la línea de negocios y de otros sistemas,

pueden también proporcionar no sólo la recuperación, actualización y distribución

de los datos, sino también responder a todos los distintos usos de los datos

maestros. La gestión de datos maestros permite una utilización operativa

integrando los datos con las aplicaciones operativas en tiempo real. La gestión

de datos maestros permite el uso cooperativo de los datos maestros

proporcionando un proceso de autorización para crear, definir y sincronizar dichos

datos. Finalmente, la gestión de datos maestros da soporte al uso analítico de

datos maestros enviando los datos a aplicaciones analíticas mediante una

herramienta de gestión de sucesos.

P á g i n a | 31


5.2.6. Metodología Kanban

Kanban es una de las llamadas metodologías ágiles de desarrollo, pues permite

controlar de manera eficaz la producción y documentación de las tareas de

software implementadas en un proyecto.

El término fue acuñado en 2010 por David Anderson, en su libro “Kanban: Cambio

Evolutivo Exitoso para Su Negocio de Tecnología” (Kanban: Successful

Evolutionary Change for Your Technology Business [11]) tomando como

referencia un proyecto de Microsoft definido usando teorías de restricciones, pero

incorporando todos los elementos del sistema Kanban inventado por Toyota4.

Tomando como referencia a Anderson, la metodología Kanban busca adaptarse

a los procesos de cambio evolutivos en las organizaciones. Usa un tablero virtual

para visualizar los elementos de trabajo, generalmente intangibles. De esta

manera el flujo de trabajo es entendible para todos los participantes del proyecto.

Una de las ventajas más importante es que limita la cantidad de trabajo en curso,

lo que en un momento dado ayuda a evidenciar en qué áreas del proyecto se

presentan falencias y estimula la colaboración del equipo de trabajo para mejorar

continuamente el sistema [12].

5.2.6.1. Principios de la metodología Kanban

La metodología Kanban se rige por tres principios fundamentales y Anderson [11]

los describe así:

a) Comenzar con lo que se hace ahora:

Kanban no le pide que cambie sus procesos. Se basa en el concepto de

evolución constante de éstos. No se busca implementar nuevas

definiciones de procesos o estilos de trabajo.

b) Acordar con todo el equipo perseguir el cambio evolutivo e incremental:

El equipo de trabajo debe ser consciente de que en sus actuales

circunstancias es necesario el mejoramiento continuo, de lo contrario la

metodología Kanban no podrá ser implementada con éxito.

4 El Sistema Kanban fue inventado por Toyota e implementado como metodología en sus plantas de producción. El elemento clave dentro de este sistema son las llamadas Tarjetas Kanban. Se definen como señales que disparan eventos dentro de la planta de producción y controlan en qué momento aumentar o disminuir la elaboración de un elemento según la cantidad disponible y la demanda del mismo. [23]

P á g i n a | 32


c) Respetar los procesos, roles, responsabilidades y títulos profesionales

actuales:

Este aspecto es importante, pues al sentir que tienen un lugar y son

respaldados por el equipo de trabajo los miedos al cambio se reducirán,

pues las responsabilidades, roles y procesos estarán bien definidos.

Cuando se logran asimilar esos principios se sugiere usar las cinco propiedades

intrínsecas de la metodología. Estas son:

a) Visualizar el flujo de trabajo:

Kanban le pide al equipo de desarrollo de software determinar estados en

los que se manifiesta un cambio importante en la generación de

información, es decir cuando ésta alcanza un punto de no retorno, a partir

del cual se puede transformar nuevamente. Un ejemplo de ello es el

análisis, una actividad que genera información y cuando ésta alcanza un

punto de no retorno se dice que ha sido “analizada”.

b) Limitar el Trabajo en Progreso:

Esto es medir la capacidad de trabajo que tiene el equipo en cada estado

del desarrollo de software y asignar las tareas de acuerdo a esta

capacidad. De esta manera no se podrán asignar tareas que sobrepasen

el límite establecido.

c) Administrar el flujo de trabajo:

Se debe monitorear el flujo de los elementos de trabajo entre cada estado.

Idealmente se busca obtener un alto flujo de trabajo, lo que indica que el

sistema está creando valor rápidamente y reduciendo costos de retrasos.

d) Establecer claramente las reglas del proceso:

Es imposible realizar alguna mejora a un proceso que no es fácilmente

reconocible. Sin que el equipo de trabajo tenga un conocimiento explícito

de lo que se hace y cómo funcionan las cosas, cualquier discusión sobre

los problemas tenderá a volverse emocional, y subjetiva. Por el contrario,

teniendo claridad sobre éstos, es posible cambiar a una discusión de los

hechos mucho más real, racional y objetiva.

e) Mejorar la colaboración (haciendo uso de modelos y métodos científicos):

El uso de modelos le permite al equipo realizar predicciones respecto a

cómo afectará al proyecto un cambio propuesto, Así, tras la

implementación de una propuesta el resultado puede ser observado

mediante la medición del flujo de trabajo y el análisis de los datos

P á g i n a | 33


obtenidos. En cuanto a los métodos científicos, Anderson propone tres

modelos útiles: La teoría de las restricciones (identificación de cuellos de

botella), La teoría del conocimiento profundo (estudio de la variación y

cómo afecta ésta a los procesos) y el modelo de economía ligera (basada

en los conceptos de desperdicio y optimización de recursos); sin embargo,

el autor indica que se puede adaptar cualquier otro método según las

necesidades del proyecto.

5.2.7. Herramientas Tecnológicas Usadas

A continuación se da una breve definición de las herramientas tecnológicas

utilizadas en el proyecto.

5.2.7.1. FreeIPA

Según el sitio oficial del propietario [13], FreeIPA es una solución de

administración de autenticación integrada para redes basadas en Linux/Unix. Un

servidor FreeIPA provee los servicios de autenticación centralizada, información

de cuentas, mediante el almacenamiento de usuarios, grupos y máquinas entre

otros objetos indispensables para administrar los aspectos de seguridad de una

red de computadores.

FreeIPA es la solución implementada por la OAS para la autenticación

centralizada de usuarios dentro de la Institución.

5.2.7.2. OpenLDAP

Es un proyecto de software desarrollado en 1998 por la Fundación OpenLDAP.

Su objetivo es implementar un software libre para el tratamiento del protocolo

LDAP. [14]

Este elemento es utilizado en el proyecto como sustituto de FreeIPA, pues brinda

las funcionalidades básicas para el acceso a datos del protocolo y es

completamente homologable con el servidor mencionado anteriormente ya que

sus interfaces son las mismas (Archivos LDIF)

5.2.7.3. PHP LDAP Admin

También conocido como PLA, es un cliente web para LDAP. Su principal ventaja

radica en que presenta la información organizada jerárquicamente en forma de

árbol de búsqueda, además de ser independiente del sistema operativo. [15]

P á g i n a | 34


5.2.7.4. PgAdmin

Es un cliente para la administración de bases de datos basadas en el motor de

bases de datos PostgreSQL. Puede ser usada en plataformas Linux, FreeBSD,

Solaris, macOS y Windows.

Está diseñado para responder a las necesidades de todos los usuarios, desde

escribir consultas SQL sencillas hasta desarrollar bases de datos complejas. La

interfaz gráfica puede ejecutarse en el escritorio o en un servidor web y admite

todas las características comunes de PostgreSQL. La aplicación incluye una

sintaxis que resalta el editor de SQL. [16]

5.2.7.5. Talend – Data Integration

Es una herramienta para integración de datos, desarrollada por la Compañía

Talend como parte de la solución homónima.

Talend-DI ofrece un conjunto de interfaces interconectables para integrar, realizar

tareas de limpieza enmascarar extraer y transportar información entre fuentes de

datos heterogéneas. Está basada en JAVA y funciona en plataformas Windows y

Linux. Cuenta con más de 900 conectores de diversas fuentes de datos. [17]

5.2.7.6. TuleAp

Es una plataforma completamente libre para la administración ágil de proyectos

de software.

TuleAp ofrece herramientas como repositorios, seguimiento de tareas,

integración de equipos de trabajo, gestores de documentación de proyecto,

versionamiento, entre otras para la administración de proyectos bajo las

metodologías SCRUM y KANBAN, facilitando las tareas de todos los miembros

del equipo de desarrollo [18].

TuleAp.udistrital.edu.co es la plataforma empleada por la OAS para la

administración de los proyectos de software desarrollados allí5.

5 Gestión de proyectos. Oficina Asesora de Sistemas. URL: https://tuleap.udistrital.edu.co/

https://tuleap.udistrital.edu.co/

P á g i n a | 35


5.3. Marco Contextual

En la Universidad Distrital, la OAPC tiene como misión coordinar y orientar el

diseño y la implementación de Políticas, Planes, Programas y Proyectos,

brindando métodos, procedimientos y herramientas técnicas que apoyen a la

toma de decisiones y permitan responder adecuadamente a los cambios del

entorno y el desarrollo de la Universidad. [19]

Esta Oficina tiene como uno de sus objetivos específicos el de Asesorar el

desarrollo del Proceso de Gestión de Infraestructura Física de la Universidad, a

través de la implementación de estudios, manuales, mecanismos

procedimentales y normativos, que permita el cumplimiento de la Misión y Visión

de la Institución. [19]

Este objetivo articula las tareas de la OAPC respecto a la gestión y administración

de espacios físicos, la cual se hace en coordinación con las diferentes facultades.

Para cumplir con éste objetivo, de acuerdo al plan de acción con vigencia 2016

publicado en el portal institucional [20] se especifican once tareas que evidencian

la situación actual de la administración de espacios físicos por parte de la Oficina.

Estas son:

1. Evaluación y proyección del estado y desarrollo de planta física universitaria

2. Elaborar los estudios necesarios para la incorporación de nueva planta física

al sistema de campus universitario en las modalidades de adquisición,

arrendamiento y comodato

3. Generar y actualizar la información relacionada con la infraestructura física

4. Establecer los lineamientos para la Formulación del Plan Maestro de

Desarrollo Físico, el cual contempla las políticas y proyectos para el

crecimiento, sostenibilidad y organización de la infraestructura física de la

Universidad

5. Mantener actualizada y custodiada toda la información física y digital de la

planta física de la Universidad a todas sus escalas (Urbana, sede y

arquitectónica).

6. Asesorar la formulación de los planes de reordenamiento físico para las

diferentes facultades y presentarlos para su aprobación

7. Generar los planos oficiales de usos del suelo de todo el sistema de campus

universitario

8. Aprobar las modificaciones e intervenciones que pretendan realizar las

Facultades en la planta física

P á g i n a | 36


9. Establecer los manuales, normas e instructivos para el uso, administración e

intervención de la planta física

10. Coordinar con las facultades mediante sus grupos de trabajo la asignación y

el uso eficiente de los espacios físicos en las diferentes sedes

11. Proponer y diseñar mecanismos procedimentales, normativos y tecnológicos

que permitan una utilización eficaz y racional de los espacios físicos.

Estas tareas permiten conocer en primera instancia la metodología de trabajo de

la Oficina respecto a la gestión de espacios físicos; la cual se desarrolla en

coordinación permanente con las diferentes facultades (tarea 10) y teniendo

como herramienta fundamental la actualización constante de los componentes de

la planta física de la Universidad (tarea 1). Así mismo se evidencia que la Oficina

es la dueña y custodia de esta información (tarea 5), lo cual supone un

inconveniente para el conocimiento holístico de toda la información de

Universidad, pues no se siguen los estándares que busca implementar la OAS.

Con la colaboración de la OAS se conoció el modelo de base de datos que está

manejando actualmente la OAPC para realizar la gestión de espacios físicos en

el SAPF-UD. El diagrama del mismo se muestra en la figura 5.

Figura 5. Diagrama Relacional Base de Datos Actual Espacios Físicos. Fuente: Autor

En este modelo se identificaron tres problemas fundamentales que impiden que

se pueda ejercer una óptima administración y minería sobre los datos

consignados en la base de datos.

P á g i n a | 37


1. Las tablas no presentan relaciones entre ellas, de manera que existe el

riesgo inminente de que los datos de una tabla sean inconsistentes cuando

se van a comparar con cualquier otra tabla dentro del mismo modelo.

2. La definición de nombres tanto de las tablas como de los campos no

corresponde con los estándares manejados por las bases de datos

actuales, lo que afecta la escalabilidad de la base de datos y la extracción

de información de ella.

3. La base de datos, al igual que el software que la alimenta ha sido

desarrollados como proyectos inHouse sin documentación, lo que no

permite el conocimiento teórico de su filosofía ni funcionamiento interno.

Estos aspectos evidencian areas susceptibles de mejorar y pueden ayudar a que

la Base de Datos que soporta el SAPF-UD sirva como una interfaz que permita

el adecuado trato de los datos a partir de la información actual que maneja la

OAPC, que no afecte su funcionamiento y pueda integrarse con los almacenes

de datos con que cuenta actualmente el proyecto de Bodega de Datos de la OAS

[21]

5.4. StakeHolders

En la figura 6 se presentan los stakeholders identificados para el proyecto:

Figura 6. StakeHolders del proyecto. Fuente: Autor

De esta manera, la OAS mediante el grupo de DataWareHousing, de acuerdo a

lo establecido en [1] son considerados un actor interno del sistema dado que la

OFICINA ASESORA

DE PLANEACIÓN Y

CONTROL

Grupo de

desarrollo

físico

Actores externos

OFICINA ASESORA

DE SISTEMAS

Grupo de

DataWare-

Housing

Actores internos

P á g i n a | 38


Oficina es la encargada de realizar todos los procedimientos técnicos de la

administración de la información referente a la Bodega de Datos del Sistema

Integrado de Información, mientras que la OAPC, representada en el grupo de

desarrollo físico, son vistos como un actor externo del sistema, ya que son los

encargados de realizar la gestión de los espacios físicos y por tanto, generar la

información que alimenta el Sistema de bodega de datos de Espacios Físicos,

según lo indicado en [20]

P á g i n a | 39


PARTE 2: DESARROLLO DEL PROYECTO

Técnicamente el proyecto fue desarrollado en cuatro fases que permitieron su

ejecución controlada y medible dentro de los plazos establecidos en la planeación

del mismo. Estas fases fueron en su orden: fase de planeación, fase de análisis,

fase de ejecución y fase de pruebas y son descritas a continuación.

6. FASE DE PLANEACIÓN

El objetivo de esta fase fue organizar un plan de ejecución que guiara el proyecto

de manera coherente y permitiera generar todos los artefactos de software de

manera ágil y eficaz, teniendo en cuenta los recursos efectivos con que contó el

proyecto.

6.1. Recolección de información previa

6.1.1. Acercamiento con la OAPC

Con el fin de tener un conocimiento global del contexto del proyecto, así como su

utilidad y alcances se llevó a cabo un proceso de levantamiento de información

pertinente, realizando acercamientos tanto con la OAPC como con la OAS.

Por parte de la OAPC se contactó al grupo de desarrollo físico, quien en respuesta

a solicitud de información por parte del investigador del proyecto, remitió una

carta en la que dio claridad sobre el proyecto de administración de espacios

físicos, el cual hace parte del Sistema de Información Geográfica Institucional,

definido en [2], el cual se enmarca en la resolución 015 del 30 de junio de 2009 y

tiene como referente su política número 7 “Sostenibilidad de la Infraestructura

Física” del Plan Maestro de Desarrollo Físico que resuelve implementar un


Mantenimiento de la Planta Física general, apoyado en un SIG, con el fin de

reglamentar la organización espacial, el uso y administración de los espacios para

el óptimo funcionamiento de la infraestructura Institucional. Igualmente el Plan

Maestro de Informática y Telecomunicaciones define el Sistema de Información

del Plan Maestro de Desarrollo Físico como un modelo de información

geoespacial y de edificios por sede, de carácter distribuido y con una estructura

P á g i n a | 40


de datos utilizada para la representación de la información de arquitectura e

ingeniería que debe responder apropiadamente a los requerimientos de gestión

académica y administrativa de la UDFJC. (Anexo 1)

En cuanto a la articulación que se lleva a cabo actualmente con la Oficina Asesora

de Sistemas, en el mismo documento, el grupo de desarrollo físico de la OAPC

informó lo siguiente:

“la OAS y la OAPC están trabajando articuladamente para lograr al mes de diciembre

del año en curso el “Diseño e implementación de interfaces para la administración,

sostenibilidad y acceso a la información de la Base de Datos Espacial” que soporte la

etapa de visualización del SIG institucional y la consolidación de la Información

geográfica mediante la migración de la misma a la base de datos acorde a un modelo

lógico validado por la OAS e integrado con el Sistema de Gestión académica - Cóndor,

con el fin de poner a servicio de la comunidad universitaria la IG asociada a la planta

física de la UDFJC” (Anexo 1)

Por lo anterior se observa que la OAPC tiene la responsabilidad de crear un


Mantenimiento de la Planta Física general, para lo cual ha diseñado el nombrado

Sistema de Información Geográfica Institucional. Estos elementos serán los

recursos de los cuales se alimentará el almacén de datos para generar

información histórica, como base de conocimiento de los espacios físicos de la

Universidad Distrital.

Así mismo, la OAPC reportó los resultados del proyecto, del cual es importante

resaltar los logrados en relación a la gestión de espacios físicos, que se

evidencian en los gráficos de las figuras 7 a 9

Figura 7. Atributos Asociados a Espacios Físicos. Adaptado de Anexo 1

P á g i n a | 41


En los últimos ocho años se ha aumentado en treinta y siete (37) el número de

atributos asociados a los espacios físicos a escala arquitectónica y se incluyeron

treinta y ocho (38) nuevos atributos en la escala de sede.

Figura 8. Espacios físicos inventariados. Adaptado de Anexo 1

Se aumentó el listado de inventarios a escala arquitectónica en 98% respecto a la

medición de hace ocho años y se incluyeron doscientos setenta y dos (272) nuevos

espacios a escala de sede.

Figura 9. Estructura de tipificación y clasificación de espacios. Adaptado de Anexo 1

P á g i n a | 42


Se redujo el número de usos generales en más de la mitad, transmitiendo este

corte a los tipos, que aumentaron sesenta por ciento (60%) y a los subtipos, que

en la medición anterior no existían.

Lo anterior permite entender que el Sistema de Información Geográfica

Institucional con que cuenta actualmente la OAPC representa una fuente

confiable de información, que alimente el Sistema de Administración de Datos

Maestros, representado en el almacén de datos de Espacios Físicos que se

desarrolló.

6.1.2. Acercamiento con la OAS

Con esta Oficina se realizó una investigación previa en la que se obtuvo

información sobre la arquitectura general del Sistema de Información Geográfico

dentro del cual se enmarca el proyecto de Bodega de Datos, además de un

informe del estado actual del Sistema de Bodega de datos y la definición de las

arquitecturas de los diferentes almacenes que dicha Bodega alberga, así como

los estándares de nomenclaturas que se manejan en la OAS.

6.1.2.1. Arquitectura General del Sistema de Información Geográfico -

CIRENE

El Sistema de Información Geográfico CIRENE es, según se estableció en [1],

una estrategia de la OAS ideada como soporte para la Gestión de la

Infraestructura Física de la Universidad Distrital, que permita la toma de

decisiones de carácter estratégico, táctico y operativo, soportadas en la

integridad, calidad y consistencia de la información; que regule la adquisición,

seguridad y actualización de la misma e igualmente permita su manejo, acceso,

análisis y reproducción.

Su estructura está distribuida en tres capas principales definidas a continuación

e ilustradas en la figura 10:

a. La capa de Persistencia, que alberga las Bases de Datos de los

diferentes Proyectos, entre ellos el de Bodega de Datos.

b. La capa de Servicios, encargada de generar interfaces para la

comunicación con la Capa de Persistencia.

c. La capa de Presentación, encargada de la gestión del conocimiento

y la interfaz de usuario con los clientes finales del Sistema.

P á g i n a | 43


Figura 10. Arquitectura General Sistema CIRENE. Tomado de [22]

Se observa en este diagrama que la capa de persistencia contiene un módulo

LDAP que no ha sido implementado aún, por lo que apoyado en el criterio de la

OAS, se decidió utilizar este recurso como sistema manejador de datos para la

gestión de los datos maestros de Espacios Físicos.

6.1.2.2. Estado Actual del Sistema de Bodega de Datos

El Sistema de Bodega de Datos se encuentra actualmente en fase de producción,

contando con ocho almacenes de datos que recogen meta-información de las

diferentes dependencias de la Universidad. Estos son:

- Almacén de Admisiones

- Almacén de Bienestar Institucional

- Almacén de Contratación

- Almacén de Egresados

- Almacén de Escalafón (clasificación de docentes)

- Almacén de Administración Financiera (compuesto por 5 almacenes)

- Almacén de Investigaciones

- Almacén de Proyectos Curriculares (Compuesto por dos almacenes)

P á g i n a | 44


Cada almacén es alimentado por la información generada por las diferentes

dependencias y genera las distintas estructuras de conocimiento que son

representadas mediante el sistema de inteligencia de Negocio Spago-BI,

adoptado por la Universidad [22].

6.1.2.3. Arquitectura De Los Almacenes De Datos

Los ocho almacenes de datos constan de un conjunto de tablas dimensionales

que se agrupan generalmente en un esquema de unión en estrella, como se

ilustra en la figura 11, variando el tamaño de las tablas dimensionales y de

hechos. Algunas incluso constan de varias tablas de hechos, sin que esto afecte

el esquema.

Figura 11. Esquema general de los almacenes de datos. Fuente: autor

De esta manera, se pudo inferir que este es el esquema que mejor se adapta a

los almacenes alojados dentro de la Bodega de Datos y por tanto se asumieron

como una recomendación a seguir en la creación del almacén de Espacios

Físicos.

6.1.2.4. Estándares de nomenclatura.

La OAS establece para las bodegas de datos algunas reglas sencillas pero

importantes en cuanto a la definición de nombres, que se aceptaron como

recomendaciones a tener en cuenta en el desarrollo del proyecto. Estas son:

P á g i n a | 45


d. Los nombres de las tablas deben ser claros para cualquier lector,

por tanto se recomienda que sean nombres completos separados

entre palabras con un guion al piso (_).

e. Los nombres de tablas y atributos deben estar escritos en letra

minúscula.

f. Tanto los nombres de tablas como los atributos y relaciones deben

incluir un comentario que describa brevemente el elemento.

Estas pautas se establecieron explícitamente, sin olvidar que se debían también

respetar las demás de diseño de bases de datos (reglas de normalización).

6.1.2.5. Tecnologías usadas por la OAS

La OAS informó que, siguiendo la filosofía que se determinó en el Plan Maestro

de Informática y Telecomunicaciones [1], utiliza las siguientes tecnologías de

código abierto para el desarrollo de los diferentes proyectos que allí se adelantan

y que tienen relación con la Bodega de Datos que se construyó. Se describen en

la tabla 1:

Tabla 1. Tecnologías usadas por la Oficina Asesora de Sistemas. Fuente: Autor

Nombre Descripción

PostgreSQL Motor de Base de datos SQL para la gestión de Bases de Datos Relacionales

FreeIPA Servidor LDAP para la gestión de esquemas bajo el protocolo LightWeight Directory Access Protocol.

TuleAp Gestor de Proyectos para la administración centralizada y supervisada de los proyectos de software

Talend-DI Software de escritorio para la integración de datos de fuentes heterogéneas

Se determinó seguir las recomendaciones de tecnologías usadas por la OAS,

haciendo salvedad con el servidor FreeIPA, que se reemplazó con OPENLDAP,

una herramienta de la misma naturaleza, también de código abierto, con

funcionalidades básicas de manejo de LDAP, lo que permite que su línea de

aprendizaje sea más corta que la de FreeIPA

P á g i n a | 46


6.2. Plan general del Proyecto

6.2.1. Definición de Tarjetas Kanban

Siguiendo la metodología escogida se propuso dividir el proyecto en cuatro áreas

o tarjetas Kanban articuladas de tal manera que pudieran desarrollarse tareas

paralelamente en la mayoría de los casos y se obtuviera claridad sobre el estado

del trabajo adelantado en cada una de ellas. Las tablas 2 a 5 describen éstas

tarjetas:

Tabla 2. Tarjeta Kanban 1. Fuente: Autor

ID 01

Nombre Documentación

Objetivo Generar la documentación necesaria con el fin de lograr un acercamiento teórico al proyecto y conocimiento previo necesario para abordar éste con propiedad

Justificación Debido a que el proyecto no abarca las etapas de implementación y despliegue se consideró importante dejar establecidos documentos que permitieran no sólo al desarrollador, sino al personal que en el futuro tenga contacto con el proyecto, conocer el vocabulario, las tecnologías a usar y los elementos generales que componen el Proyecto de Almacén de datos. Esta tarjeta es ideada como una fuente primaria de información que brinde la justificación teórica necesaria de las tareas desarrolladas en las demás tarjetas


ID 02

Nombre Bases de Datos

Objetivo Realizar los procesos de Análisis, diseño y desarrollo de las bases de Datos relacionales de espacios Físicos y Almacén de Datos.

Justificación La base de datos de Espacios físicos, al igual que el almacén de datos están soportadas en un motor de Datos SQL (PSQL), por lo que se consideró que las tareas, documentación y artefactos relacionados con éstas tendrían en común el lenguaje y por tanto podrían ser referenciados más claramente al momento de búsqueda de información dentro del proyecto.

P á g i n a | 47



ID 03

Nombre ETL

Objetivo Realizar los procesos ETL desarrollados en el Proyecto.

Justificación La determinación de tener una tarjeta para los procesos ETL surge debido a que éstos procesos se desarrollan transversalmente en el Proyecto, por tanto están presentes en diferentes etapas del mismo.


ID 04

Nombre LDAP

Descripción Generar una base de datos de espacios físicos desarrollada bajo la tecnología LDAP.

Justificación Debido a que es la tecnología diferenciadora del proyecto se creó esta tarjeta Kanban para agrupar todos los elementos que tienen relación con LDAP.

6.2.2. Definición de artefactos

Así mismo se definieron los artefactos que se pretendía desarrollar en el proyecto.

Estos son:

6.2.2.1. Artefactos de la tarjeta 01 (Documentación)

Tabla 6. Artefactos tarjeta Kanban 1. Fuente: Autor

ID NOMBRE DESCRIPCIÓN

ART101 RFC 4512 Reseña sobre el documento RFC4512

ART102 RFC 4519 Reseña sobre el documento RFC4519

ART103 Diagrama E-R Actual

Diagrama E-R de la base de datos del sistema actual que maneja La oficina Asesora de Planeación

ART104 Diagrama E-R Propuesto

Diagrama E-R de la base de datos que tendrá el sistema final de espacios físicos. Suministrada por el Ing. Alejandro Daza.

ART105 Organigrama UD. Organigrama UD.

ART106 Registro de Espacios físicos

Reporte en Excel de espacios físicos. Documento sin depurar.

ART107 Acercamiento a los procesos ETL

Documento de referencia para entender los procesos ETL

P á g i n a | 48


ART108 DataWareHousing. Kimball

Documento de referencia para entender los procesos ETL

ART109 Caso de estudio. BI espacios Físicos

Artículo de referencia sobre espacios físicos en un caso de estudio de la Universidad del Magdalena

ART110 Nomenclatura OAS Documento de referencia para conocer los estándares de nomenclatura que maneja la OAS

ART111 Informe OAPC Espacios Físicos

Informe de la OAPC sobre los procedimientos de gestión de espacios físicos. (Anexo 1)

Nota: el artefacto 111 se incluyó por ser un artefacto generado por un actor

(OAPC) que sirve para documentar el proyecto.

6.2.2.2. Artefactos de la tarjeta 02 (Bases de Datos)



ART201 BackUp Base de datos – Espacios Físicos

BackUp final de la base de datos de espacios fisicos. Incluido esquema de la BD y datos

ART202 Diagrama E-R Base de Datos. Espacios físicos

Diagrama E-R de la base de datos de espacios físicos creada para el proyecto

ART203 BackUp Data Mart BackUp final de la base de datos del datamart que tiene la dimensión d_espacios_fisicos y la tabla de hechos h_historico_espacios_fisicos. Notar además los triggers de la tabla de hechos

6.2.2.3. Artefactos de la tarjeta 03 (ETL)



ART301 Registro de espacios físicos. Depurado

Documento después de la limpieza y corrección de datos para llenar la base de datos

ART302 Extracción de Datos – Sedes

extracción de datos de sedes

ART303 Extracción de Datos – Edificios

extracción de datos de edificios

ART304 Extracción de Datos – Espacios Físicos

extracción de datos de tipos de espacios

P á g i n a | 49


ART305 Job de Talend para Cargar_a_LDIF

Carga los datos de la BD de espacios a un archivo LDIF listo para importar a LDAP

ART306 Job de Talend para Cargar a DataMart

Carga los datos desde LDAP a la tabla d_Espacios_fisicos de la Bodega de datos

ART307 Job de Talend para Cargar_tabla_hechos

Llena la tabla de hechos con los datos suministrados por la base de datos y el LDAP

ART308 Job de Talend para Xlsx_a_LDAP

Carga la estructura del archivo xlsx al directorio LDAP

6.2.2.4. Artefactos de la tarjeta 04 (LDAP)



ART401 Criterios de definición de Atributos a utilizar

Definición de criterios para componer un espacio físico en el directorio LDAP

ART402 Esquema lógico LDAP – Organigrama

Esquema del organigrama formateado para importar a LDAP

ART403 Esquema físico LDAP – Espacios Físicos

Esquema final de espacios físicos en LDAP. Esto se puede cargar al LDAP de una vez. Ya están todas las entradas formateadas.

6.2.3. Definición de tareas

En esta etapa se definieron un conjunto de tareas con el fin de cumplir el objetivo

planteado en las tarjetas. Cada tarea tiene asignado uno o más artefactos como

producto final de su desarrollo.

6.2.3.1. Tareas de la Tarjeta 01 (Documentación)

Tabla 10. Tareas tarjeta Kanban 1. Fuente: Autor

ID NOMBRE DESCRIPCIÓN ARTEFACTOS (ART-)

101 Conocer las generalidades del Protocolo LDAP

Realizar una investigación de los RFC 4512, 4519 y relacionados para conocer de qué trata el protocolo, y establecer cuál será la estructura general de la base de datos LDAP

101,102,109

102 Conocer el concepto de

Realizar la investigación pertinente para entender los conceptos de

108

P á g i n a | 50


bodega de datos

Bodega de datos, almacén de datos, dimensión, tabla de hechos y cubo de datos

103 Instalar LDAP Instalar LDAP y configurar un esquema de datos nombrado "co.udistrital.dwh.EspaciosFisicos"

109

104 Conocer los elementos de la metodología Kanban

Realizar la investigación pertinente para entender los términos de la metodología Kanban y generar un documento referente

109

105 Conocer los estándares de nombres manejados por la Oficina Asesora de Sistemas

Realizar la investigación pertinente con el fin de entender los estándares de nomenclatura definidos por la OAS para los nombres de Bases de Datos con el fin de generar un producto de utilidad para esta Oficina.

110,401

106 Conocer el contexto de la gestión de espacios físicos por parte de la Oficina Asesora de Planeación

Realizar el acercamiento e investigación necesarios con la OAPC con el fin de entender el funcionamiento del sistema administrador de espacios físicos que ésta oficina maneja

103, 105, 111, 202

6.2.3.2. Tareas de la tarjeta 02 (Bases de Datos)



201 Análisis del modelo de base de datos manejado actualmente por la Oficina Asesora de Planeación.

Con base en el modelo conocido realizar un análisis de su estructura y generar un diagnóstico relacionado con su utilidad para la extracción de datos maestros.

103, 202, 301

202 Reingeniería de la base de datos de espacios físicos

Realizar los ajustes necesarios al modelo analizado con el fin de que sea adecuado para la

201, 202,

P á g i n a | 51


extracción de datos maestros.

203 Diseño del almacén de Datos

Diseñar las dimensiones y hechos del almacén de datos de espacios físicos y sus relaciones

203

204 Análisis de la información relevante para la bodega de datos

Análisis de los datos almacenados por la Base de datos de espacios físicos que son de utilidad en el almacén de datos

401, 402,403

6.2.3.3. Tareas de la tarjeta 03 (ETL)



301 Extracción de datos desde la Base de Datos SQL hacia el esquema físico LDAP

Generar la extracción de los datos desde la base de Datos de espacios físicos hacia la base de datos LAP. Para esto se realizará en ese orden la extracción de las sedes, los edificios y los espacios físicos para asegurar la integridad referencial de cada objeto dependiente.

301, 302, 303, 304, 305,

302 Definición del tratamiento en la transformación de datos

Definir el tratamiento que se dará a los datos nulos o defectuosos que se carguen hacia el esquema LDAP y posteriormente al almacén de datos.

401, 403,

303 Carga de datos del esquema físico LDAP al almacén de datos

Realizar la carga de datos desde el directorio LDAP (espacios físicos) hacia la dimensión destinada del almacén de datos

201, 305

304 Carga de datos del esquema lógico LDAP al almacén de datos

Realizar la carga de datos desde el directorio LDAP (organigrama) hacia la tabla de hechos destinada del almacén de datos

402, 308

P á g i n a | 52


6.2.3.4. Tareas de la tarjeta 04 (LDAP)



401 Diseño del esquema lógico (organigrama)

Diseñar un esquema LDAP que sea capaz de representar el organigrama de la Universidad

402

402 Diseño del esquema físico

Diseñar un esquema LDAP que sea capaz de representar la información de datos maestros requeridos

403

403 Extender el esquema

Desarrollar la estrategia adecuada con el objetivo de extender el esquema LDAP para incluir los atributos propios de los espacios físicos.

305

7. FASE DE ANÁLISIS

Tras la planeación del proyecto se procedió a realizar el análisis técnico de los

componentes definiendo las estructuras que se deben desarrollar.

7.1. Definición de Datos Maestros

Como producto del análisis de la información generada por la OAPC se dio a un

conjunto de datos la clasificación de Datos Maestros, con el fin de realizar la

extracción de éstos desde la base de datos de Espacios físicos hacia el almacén

de Datos. De esta manera, se obtuvo el siguiente conjunto de Datos Maestros:

Id: Identificador único del espacio físico

Nombre: Nombre descriptivo del espacio físico

Planta: Piso en el cual se ubica el espacio físico dentro de un edificio

Estancia: Identificación secuencial de un espacio físico en una

planta. Por ejemplo el salón 203 del edificio Sabio Caldas se ubica

en la estancia 3 de la planta 2, así como el 307 en la estancia 7 de

la planta 3.

P á g i n a | 53


Sede: Identificador de la sede a la cual se asocia el espacio físico.

Nombre de Sede: Nombre de la sede a la cual se asocia el espacio

físico.

Edificio: Identificador del edificio en el cual se ubica el espacio físico.

Nombre de Edificio: Nombre del edificio en el cual se ubica el

espacio físico.

Código de Tipo de espacio: Identificador del tipo de espacio físico.

Tipo de espacio: Nombre del tipo de espacio físico

Código de subtipo de espacio: Identificador del subtipo de espacio

físico.

Subtipo de espacio: Nombre del subtipo de espacio físico.

Uso principal: Uso al que se destina principalmente el espacio físico.

Estado del espacio físico: Indica si el espacio está activo o inactivo.

Área: Área en metros cuadrados del espacio físico.

Esta clasificación se realizó y aprobó en coordinación con la OAS y se estableció

como el elemento de información objetivo del proyecto.

7.2. Base de Datos de Espacios Físicos

Debido a que el esquema actual de la base de datos de Espacios Físicos que

maneja la OAPC es inconveniente para su tratamiento dentro de la bodega de

datos se determinó diseñar un nuevo modelo que mantuviera la integridad que

de la estructura usada actualmente y tuviera las interfaces necesarias para

realizar los procesos ETL hacia el almacén de datos. Por lo anterior se consideró:

Eliminar los prefijos GE de los nombres de las tablas

Eliminar los prefijos de tabla en los atributos (por ejemplo el prefijo

EDI en EDI_NOMBRE, de la tabla Edificio)

Cambiar el nombre de la tabla SALONES por el de Espacio_Fisico,

generalizando su definición para incluir cualquier elemento de este

tipo de la Institución

Incluir una tabla llamada Dependencia que agregue las estructuras

organizacionales de la Universidad.

Crear las relaciones necesarias entre las tablas.

Así, se obtuvo el modelo Relacional ilustrado en la figura 12.

P á g i n a | 54


Figura 12. Diagrama E-R de Base de Datos propuesto. Fuente: Autor

Este modelo fue diseñado y aprobado en coordinación con el grupo de

DataWareHousing de la OAS.

7.3. Esquema LDAP de Espacios Físicos

El directorio LDAP es la estructura fundamental para la generación de los

procesos ETL, por lo cual su diseño requirió de una investigación exhaustiva para

conocer de qué manera se podía adaptar este protocolo para albergar la

información de espacios físicos. En el diseño de éste artefacto se concluyó que:

b. Para el esquema lógico (organigrama) era posible utilizar las clases de

objetos “Unidad Organizacional” pues corresponden con esta definición

dentro del protocolo LDAP6 y fueron construidas como objetos con un

identificador único (ou) y una descripción que indicara su nombre

(description). De esta manera, el árbol jerárquico debía seguir el esquema

de la figura 13, en la que cada elemento del primer nivel sería identificado

por un nombre distinguido (dn, por sus siglas en inglés) conformado

únicamente por su nombre distinguido relativo (rdn, por sus siglas en

inglés), mientras que cada elemento del segundo nivel tendría un nombre

distinguido conformado por su rdn concatenado con el dn del elemento

padre y así sucesivamente.

6 Definición de Unidad organizacional dentro de la sección “ObjectClasses”, en [5]

P á g i n a | 55


Figura 13. Diagrama del esquema lógico LDAP. Fuente: Autor

c. Se debía establecer un estándar de nombres que permitiera su fácil

identificación, por lo tanto se resolvió crear el prefijo OU0x donde la letra x

es sustituida por el nivel en el cual se encuentra la unidad organizacional

dentro del organigrama y es utilizado para diferenciar éstos elementos de

los espacios físicos. Además se decidió establecer un estándar de cuatro

caracteres alfanuméricos después del prefijo, que serán el identificador de

cada elemento. Así, por ejemplo la estructura de la unidad organizacional

Consejo Superior es:

ou: OU01CSUP description: Consejo superior

c. Para el esquema físico fue necesario extender la funcionalidad del

protocolo LDAP para incluir las clases de atributos indicadas en la tabla 14

y la nueva clase de objeto indicada en la tabla 15:

Tabla 14. Tipos de Atributos LDAP Espacios físicos. Fuente: Autor

Atributo Tipo de dato

planta DirectoryString

estancia DirectoryString

id_tipo DirectoryString

tipo DirectoryString

id_subtipo DirectoryString

id_sede DirectoryString

sede DirectoryString

id_edificio DirectoryString

edificio DirectoryString

área NumericString

uso_principal DirectoryString

Activo Boolean

3er nivel2do nivel1er nivel

dn=ou1

dn=ou2,ou1

dn=ou4,ou2,ou1

dn=ou5,ou2,ou1

dn=ou3,ou1 dn=ou6,ou3,ou1

P á g i n a | 56


Tabla 15. Clase de Objeto EspacioFisico. Fuente: Autor

Nombre Descripción Atributos obligatorios

EspacioFisico Espacio Físico ou (heredado de Organizational Unit), description (heredado de Organizational Unit) y todos los indicados en la tabla 14.

La obligatoriedad de los atributos en la clase se pensó como estrategia de apoyo

a los procesos ETL, pues no pueden existir campos nulos, como sí se presentan

en la base de datos relacional.

7.4. Almacén de Datos

El diseño del almacén de datos se hizo teniendo en cuenta que esta sería la

estructura final de recopilación de la información, por tanto es allí donde deben

guardarse en conjunto los datos maestros del esquema lógico y el esquema

físico.

Debido a que los datos maestros de espacios físicos no presentan relaciones de

ningún tipo, se consideró crear una dimensión llamada Espacios_Fisicos.

Por otro lado, ya que la información del organigrama no requiere transformación

de datos se determinó que el esquema LDAP lógico sería la segunda dimensión

del almacén de datos.

Por último, se creó una tabla de hechos que relacionara la información de las dos

dimensiones, ya que será este el elemento al que se accederá en los proyectos

de minería de datos que desarrolle la OAS con este almacén.

La figura 14 ilustra el modelo relacional que se estableció para el almacén de

datos.

P á g i n a | 57


Figura 14. Diagrama Relacional Almacén de Datos. Fuente: Autor

7.5. Extracción de Datos.

Como parte del proceso de transporte se estableció realizar sobre la información

una extracción de tipo completo, pues la base de datos origen (Espacios físicos)

no guarda un registro histórico de los movimientos transaccionales; y fuera de

línea, pues interesa extraer únicamente el conjunto de datos maestros

mencionados en la sección 7.1

7.6. Transformación de datos

Se estableció para los datos una transformación de tipo secuencial, que garantiza

la integridad de los datos desde la base de datos relacional (PSQL) y su posterior

interpretación en el esquema LDAP.

Puede entenderse como la fase de –limpieza- de la información, pues es aquí

donde se establecen los valores por defecto que recibirán los campos en caso de

traer valores nulos. En la tabla 16 se puede observar que algunos campos

permiten otorgar valores por defecto, de tal manera que el registro pueda ser

cargado al esquema LDAP; por el contrario si los campos id, idSede o

NombreSede tienen valores nulos el registro será rechazado.

P á g i n a | 58


Tabla 16. Valores por defecto. Proceso de trasformación. Fuente: Autor

CAMPO PSQL TIPO PSQL

CAMPO LDAP

TIPO LDAP VALOR POR

DEFECTO

Id varchar ou DirectoryString [rechazar]

Nombre varchar description DirectoryString [Igual que id]

Planta numeric planta DirectoryString 0

Estancia varchar estancia DirectoryString 0

Idsede varchar idSede DirectoryString [rechazar]

NombreSede varchar sede DirectoryString [rechazar]

IdEdificio varchar idEdificio DirectoryString sinEdificio

Edificio varchar edificio DirectoryString sinEdificio

IdTipo varchar idTipo DirectoryString 00

Tipo_espacio varchar tipo DirectoryString General

IdSubtipo varchar idSubtipo DirectoryString 00

Subtipo_espacio varchar subtipo DirectoryString SinSubtipo

Uso_principal varchar usoPrincipal DirectoryString General

Activo boolean activo Boolean False

Se puede observar que si el campo Nombre está vacío se puede validar

otorgando el mismo valor del id, pues éste último tiene una semántica particular,

que permite identificar en todo caso al espacio físico.

7.7. Carga de Datos

Debido a que los datos han sido previamente transformados el proceso de carga

desde el esquema LDAP hacia el almacén de datos no presentó ningún

inconveniente, ambas bases de datos presentan los mismos tipos de datos. Se

realizó una carga mediante comandos SQL al almacén y esta deberá ser la regla

de carga en posteriores operaciones de carga, pues garantiza la máxima fidelidad

en la transacción pues se realiza una conexión directa entre el esquema LDAP y

la Base de datos del almacén, con las ventajas que esto representa (Propiedades

ACID de las bases de datos)

Los procesos de extracción, transformación y carga de datos (ETL por sus siglas

en inglés) se ejecutaron para el desarrollo del proyecto como se definieron

anteriormente, y se espera que sean respetados en futuras operaciones entre la

base de datos y el almacén en entornos de producción.

P á g i n a | 59


8. FASE DE EJECUCIÓN

En la fase de ejecución del proyecto se desarrollaron las tareas establecidas para

cada tarjeta Kanban, de tal manera que se obtuvieran los artefactos descritos en

la sección 6.2.2

8.1. Preparación del entorno de trabajo

Como primera medida se preparó el entorno realizando las instalaciones de las

herramientas Postgres, OpenLDAP y Talend sobre una distribución Ubuntu 16.04

de Linux.

Las herramientas fueron instaladas y configuradas siguiendo las instrucciones de

los respectivos fabricantes.

8.2. Creación de bases de datos relacionales

La implementación del diseño de las bases de datos de espacios físicos y

almacén de datos no presentó mayor inconveniente, pues se siguió el diseño

planteado en la etapa de análisis dejando documentadas en lenguaje SQL tanto

tablas como las columnas y relaciones de ambas bases de datos.

Para la creación de estas bases de datos se utilizó la herramienta de entorno

gráfico PgAdmin III y los comandos de consola propios de Postgres.

8.3. Extensión del esquema LDAP

La extensión del esquema LDAP requirió un trabajo arduo que implicó entender

el funcionamiento de la estructura de esquemas de OpenLDAP, la interpretación

que el motor le da a cada archivo de esquema y su jerarquización dentro del árbol

principal.

Se logró extender el esquema mediante el algoritmo explicado en detalle a

continuación.

En primer lugar fue necesario generar un esquema propio que especificara los

atributos nuevos y la clase que los implementaría. Así, la figura 15 ilustra la

sintaxis de éstos. Cada atributo debe heredar las características de un tipo de

dato de nivel superior de acuerdo a lo que se especifica en [5].

P á g i n a | 60


Figura 15. Construcción del elemento EspacioFisico. Fuente: Autor

Posteriormente se creó un archivo de configuración que incluyera el esquema

generado y los demás pertinentes que permitan el correcto funcionamiento de la

base de datos LDAP en general.

A continuación, se empleó la herramienta testldap de OpenLDAP para realizar la

conversión del archivo de esquema en un archivo LDIF.

Por último se incluyó el archivo LDIF producido anteriormente dentro del esquema

original LDAP mediante la herramienta slapadd de OpenLDAP.

Al reiniciar el servidor LDAP el esquema EspaciosFisicos estuvo disponible para

la generación de nuevos elementos del tipo EspacioFisico.

El proceso general del algoritmo es ilustrado en la figura 16.

Espacio

Físico

P á g i n a | 61


Figura 16. Proceso de extensión del esquema LDAP. Fuente: Autor.

8.4. Elaboración de trabajos de Talend

En la herramienta Talend se realizaron tres trabajos principales y dos de apoyo

para permitir la automatización de los procesos ETL entre las fuentes de datos.

8.4.1. ETL entre Base de datos relacional y LDAP

Este trabajo contiene tres sub trabajos con el fin de estructurar la información

para ser cargada desde la base de datos relacional de espacios físicos y el

servidor LDAP.

8.4.1.1. Mapeo de Sedes

La figura 17 muestra el esquema general del sub trabajo encargado de mapear

las sedes. Los componentes de la rutina son una conexión a la base de datos y

una representación de un archivo LDIF de salida. Los detalles técnicos se

encuentran documentados en el anexo 3.

Figura 17. Mapeo de sedes. Fuente: Autor

Generación del

esquema

Creación archivo

de configuración

Conversión del

esquema con

testldap

Conversión

del esquema

con testldap

Inclusión de archivo

LDIF generado al

esquema general

Reinicio del

servidor LDAP

P á g i n a | 62


Dentro de la rutina se hizo una consulta a la base de datos sobre el id y la

descripción de las sedes, los cuales se escriben en formato LDIF en el archivo

denominado “sedes”

8.4.1.2. Mapeo de Edificios

El mapeo de edificios se hizo con los mismos componentes utilizados en la

subrutina anterior; en la base de datos relacional se realizó una consulta sobre la

tabla edificio requiriendo los campos id y nombre de cada registro. Los detalles

técnicos se encuentran documentados en el anexo 4. La figura 18 ilustra este

escenario.

Figura 18. Mapeo de edificios. Fuente: Autor

8.4.1.3. Mapeo de Espacios Físicos

Debido a que es aquí donde los datos presentan mayor volatilidad se hizo

necesario introducir, además de los componentes que interactúan en las dos

subrutinas anteriores, un mapeador, encargado de analizar los datos de entrada

y darles un formato especial de acuerdo al formato requerido en el archivo de

salida. De esta manera, la figura 19 ilustra el escenario general de esta sub rutina

y la figura 20 una vista específica del elemento mapeador, del cual se puede

evidenciar que si bien algunos campos son cargados tal como se extraen de la

base de datos relacional, otros, como la descripción y el tipo necesitan un

tratamiento especial (por ejemplo, LDAP no acepta caracteres especiales (tildes,

diéresis, etc.) por tanto se sustituyeron estos caracteres con equivalentes que no

le quitaran semántica al campo). Los detalles técnicos se encuentran

documentados en el anexo 5.

Figura 19. Mapeo de espacios físicos. Fuente: Autor.

P á g i n a | 63


Figura 20. Primera transformación de datos en Mapeo de espacios físicos. Fuente: Autor.

Las tres sub rutinas se ejecutaron en el orden en que quedaron consignadas en

este documento, y de la misma manera fueron cargadas al esquema LDAP, pues

de otra manera hubiese sido imposible llenarlo, ya que un espacio físico no puede

registrarse si no existe un edificio en el cual se albergue y de la misma manera

un edificio no puede registrarse sin que exista una sede a la cual sea asociado.

8.4.2. ETL entre LDAP y Almacén de datos (Esquema Físico)

Se construyó un trabajo que facilitara los procesos ETL entre el esquema LDAP

(cuyos campos cuentan con información completa y estructurada) y la dimensión

de espacios físicos del almacén de datos.

En este escenario se utilizaron dos mapeadores, como se evidencia en la figura

21. El primero de ellos se encarga de convertir el campo área, que en el esquema

LDAP se almacena como cadena de texto (DirectoryString) y en el almacén de

datos requiere ser un tipo numérico de coma flotante.

P á g i n a | 64


Figura 21. ETL entre LDAP y almacén de datos. Fuente: Autor.

El segundo mapeador establece las conexiones necesarias entre las dos fuentes

de datos, tal como se evidencia en la figura 22, ya que no tienen el mismo orden

y podrían presentarse inconsistencias si se escoge una estrategia de carga

directa como en los trabajos descritos en 9.4.1.1 y 9.4.1.2.

Figura 22. Segunda transformación de datos en mapeo de espacios físicos. Fuente: Autor

Los detalles técnicos de este trabajo se encuentran documentados en el anexo

6.

8.4.3. ETL para registro de datos en la tabla de Hechos

La carga de información hacia la tabla de hechos del almacén de datos es la tarea

que completa el procedimiento de datawarehousing y en ella se cruza la

información del esquema de datos lógico (LDAP) y el esquema de datos físico

(tabla de dimensión). El escenario se configuró como se muestra en la figura 23

y el mapeador empleado aquí (figura 24) se utilizó para unificar los identificadores

de los espacios físicos y los nombres distinguidos de las estructuras

P á g i n a | 65


organizacionales del organigrama. Se incluyeron además dos disparadores a

nivel de base de datos que son activados cuando se ingresa o actualiza una tupla,

actualizando la fecha de registro o la última modificación según sea el caso.

Figura 23. ETL hacia la tabla de hechos. Fuente: Autor

Figura 24. Transporte de datos hacia la tabla de hechos. Fuente: Autor

Los detalles técnicos de este trabajo se encuentran documentados en el anexo

7.

8.4.4. Otros trabajos de apoyo

Para soportar las tareas ETL y el manejo de la información se crearon dos

trabajos auxiliares que si bien no se usan en el flujo regular del proyecto son útiles

para apoyar escenarios particulares

P á g i n a | 66


8.4.4.1. Eliminación masiva de registros LDAP

Este trabajo está ilustrado en la figura 25 y permite generar un registro de los

objetos eliminados del esquema LDAP. De esta manera, siempre que se utilice

esta rutina se estarán monitoreando los registros suprimidos. En el proyecto se

utilizó para tener un listado de los espacios que presentaban irregularidades y

debían ser eliminados del directorio y en un entorno de producción puede ser

empleado como parte de un proceso de auditoría a la base de datos LDAP.

Figura 25. Registro de eliminación de entradas en LDAP

8.4.4.2. Carga desde hoja de cálculo hacia LDAP

La generación del esquema lógico se esquematizó en una hoja de cálculo y fue

cargada mediante el trabajo que se ilustra en la figura 26 al esquema lógico

LDAP. Su generación no implicó ningún problema, pues se siguieron las

especificaciones planteadas en la fase de análisis y todos los datos fueron

cargados manualmente al archivo.

En un entorno de producción puede desplegarse el potencial de esta rutina, pues

se pueden cargar grandes cantidades de datos al esquema LDAP desde ficheros

de almacenamiento común de información.

Figura 26. Carga desde archivo xls a LDIF. Fuente: Autor.

Este archivo se cargó al directorio LDAP y generó el esquema indicado en la

figura 27, que sirve como insumo de pruebas en la siguiente fase. En la figura se

diferencian los niveles de las diferentes unidades organizacionales.

P á g i n a | 67


Figura 27. Esquema lógico LDAP. Fuente: Autor

9. FASE DE PRUEBAS

La fase de pruebas se realizó en tres etapas: pruebas de ETL a LDAP, pruebas

de ETL de datos dimensionales y pruebas de ETL de la tabla de hechos.

Como recurso para generar las pruebas se obtuvo con ayuda de la OAS un

reporte que contaba con una estructura similar a la de la tabla de hechos, de tal

manera que los datos sirvieron de insumo para la generación de pruebas ETL en

el esquema físico LDAP y el almacén de datos.

El reporte cuenta con datos reales producidos por la OAPC, por tanto permitirá

generar pruebas muy cercanas al entorno de producción en que se despliegue

el sistema.

P á g i n a | 68


9.1. Preparación para pruebas de ETL a LDAP

En primer lugar se cargaron los datos a las respectivas tablas de la base de datos

relacional, eliminando la restricción de obligatoriedad de las columnas, pues no

todos los campos están llenos (como se supone podría estar actualmente el

sistema de la SAPF-UD de la OAPC) y las cadenas de caracteres no están

estandarizadas.

9.2. Pruebas ETL de Sedes

Una vez poblada la base de datos relacional, se procedió a ejecutar el trabajo

definido en la sección 8.4.1.1 La figura 28 muestra el desempeño de la sub rutina

generando satisfactoriamente un archivo LDIF con 24 registros correspondientes

a las sedes.

Figura 28. Resultado de pruebas a carga de sedes. Fuente: Autor

Este archivo fue cargado al directorio LDAP y se integró correctamente con el

esquema.

9.3. Pruebas ETL de Edificios

Se procedió de la misma manera para realizar pruebas sobre la subrutina definida

en la sección 8.4.1.2 La figura 29 muestra el desempeño de esta, generando un

archivo LDIF con 59 registros correspondientes a los edificios.

Figura 29. Resultado de pruebas de carga de edificios. Fuente: Autor.

De igual manera se cargó el archivo generado y se integró correctamente con el

esquema.

P á g i n a | 69


9.4. Pruebas ETL de espacios físicos

Similarmente se procedió con la tercera subrutina, que cargó los datos de

espacios físicos desde la base de datos relacional a un archivo LDIF. La figura

30 indica que se generaron en esta subrutina 1081 registros que corresponden a

la totalidad de espacios físicos consignados en el reporte.

Figura 30. Resultado de pruebas de carga de espacios físicos. Fuente: Autor.

Igual que con los anteriores, se procedió a cargar el archivo al directorio LDAP,

pero se registraron 107 errores de carga.

Se hicieron los análisis correspondientes y se encontró que el protocolo LDAP no

acepta caracteres especiales, por tanto se refinó la transformación de datos,

como se indicó en la sección 7.6 y se repitió el proceso, obteniendo esta vez un

100% de efectividad en los registros cargados

Como resultado de las pruebas ETL se puedo obtener el esquema ilustrado en la

figura 31, en el cual se indican los elementos de primer, segundo y tercer nivel.

P á g i n a | 70


Figura 31. Esquema físico LDAP resultante. Fuente: Autor

9.5. Pruebas de ETL de datos dimensionales

Se realizaron pruebas sobre los datos consignados en el esquema LDAP

anteriormente generado, ejecutando el trabajo definido en la sección 8.4.2

Debido a que los datos ya han sido transformados en la prueba anterior, no se

encontró ninguna dificultad para su carga a la tabla dimensional del almacén de

datos. La figura 32 demuestra que se cargaron exitosamente. 1081 registros en

2,13 segundos

Figura 32. Resultado de pruebas de carga de datos dimensionales. Fuente: Autor

P á g i n a | 71


9.6. Pruebas de ETL de la tabla de hechos

Para esta prueba se reunieron las fuentes de datos del esquema lógico LDAP

(organigrama) y la tabla dimensional de espacio físicos del almacén. Debido a

que el objetivo de la prueba se limitó únicamente a garantizar la correcta carga

de los datos y el funcionamiento de los disparadores de la tabla de hechos, se

realizó una consulta sencilla que cruzó los datos de ambas fuentes, generando

50.807 registros, como se muestra en la figura 33.

Figura 33. Resultado de pruebas de carga de la tabla de hechos. Fuente: Autor.

En un entorno de producción se deben ajustar las búsquedas sobre las fuentes

de datos para generar únicamente la información relevante en cada carga.

P á g i n a | 72


PARTE 3: CIERRE DEL PROYECTO

CONCLUSIONES

1. Se realizó el diseño y desarrollo de un almacén de datos siguiendo las

políticas de estructuración y manejo de información establecidas por la OAS

que es alimentado por una base de datos propuesta como fuente de datos

del sistema SAPF-UD de tal manera que es perfectamente integrable con los

demás almacenes de datos que se encuentran en desarrollo dentro del

proyecto Bodega de Datos de la OAS.

2. Se obtuvo información sobre el funcionamiento del sistema de Administración

de Planta Física (SAPF-UD) por parte de la OAPC y en coordinación con la

OAS se realizó un análisis de la base de datos actual, sobre la cual se

propusieron mejoras que permitieran crear interfaces para desarrollar el

proceso de DataWhareHousing al almacén de datos.

3. Los estándares de manejo de datos fueron suministrados por la OAS y con

base en estos se realizó la fase de análisis y diseño de los artefactos

producidos. Este trabajo conjunto permite la integración del proyecto con los

demás desarrollados en la OAS.

4. Se realizaron los procesos de extracción, transformación y carga de datos

desde las diferentes fuentes de información hacia el directorio LDAP y el

almacén de datos, desarrollando pruebas que verificasen su correcta

implementación.

5. Se diseñó un almacén de datos de dos dimensiones, una de las cuales es

una base de datos dimensional y la otra, un esquema LDAP. Sobre este se

hicieron pruebas y verificaciones en conjunto con la OAS.

TRABAJOS FUTUROS

El trabajo desarrollado en este proyecto responde a la necesidad que presenta

actualmente la OAS en cuanto al almacenamiento de Datos Maestros, por lo que

se proponen como trabajos futuros los siguientes:

P á g i n a | 73


Un proyecto de inteligencia de negocios que integre el almacén de datos

de Espacios Físicos con los demás dentro de la Bodega de datos con el

fin de realizar un análisis transversal de información.

Un proyecto de inteligencia de negocios que genere las interfaces de

bodega de datos (cubos de datos) y de usuario con el fin de hacer

operaciones de consulta sobre la información del almacén de datos.

Un proyecto de datawharehousing que refine los procesos ETL aquí

desarrollados con el fin de optimizar los movimientos de las grandes

cantidades de datos que tendrá a futuro el almacén y sus orígenes de

datos.

P á g i n a | 74


GLOSARIO DE TÉRMINOS

1. ACID: Propiedad que deben asegurar las transacciones. Siglas

correspondientes a los términos Atomicidad, Consistencia Aislamiento y

Durabilidad en inglés.

2. Almacén de Datos: Base de datos que almacena grandes cantidades de

datos de un nicho de negocio dentro de una organización. Tiene las

características de ser un sistema integrado, no volátil y variable en el tiempo.

3. Booleano, (Dato): Tipo de dato dicotómico que puede tomar únicamente

valores de 0 o 1

4. DirectoryString (Tipo): Tipo de dato especial del protocolo LDAP destinado

a almacenar cadenas de caracteres. Especialmente nombres de directorios

5. ETL: Siglas de los Procesos de extracción, Transformación y Carga de Datos.

6. LDAP: (Lightweight Directory Access Protocol). Protocolo de acceso a datos

ordenados en forma de directorio que trabaja sobre la pila TCP/IP. Provee un

mecanismo para la conexión, búsqueda y modificación de directorios de

internet.

7. Mapeador: Elemento de trabajo del software Talend que recoge los datos de

una o varias entradas, les da un tratamiento especial y las traduce en valores

con significado para la salida.

8. Meta-información: Información que revela comportamientos ocultos

(tendencias, indicadores, comportamiento histórico) de un hecho o conjunto

de hechos.

9. Nombre distinguido (dn): Elemento del protocolo LDAP por medio del cual

se identifica indistintamente a cualquier registro dentro de un directorio LDAP.

Está compuesto por uno o más nombres distinguidos relativos.

10. Nombre distinguido relativo (rdn): Identificador de un registro que forma

parte del nombre distinguido y es relativo a este.

11. NumericString (Tipo): Tipo de dato especial del protocolo LDAP destinado

a almacenar valores numéricos como cadenas de caracteres.

12. OAPC: Oficina Asesora de Planeación y Control. Órgano de la Universidad

Distrital Francisco José de Caldas.

13. OAS: Oficina Asesora de Sistemas. Órgano de la Universidad Distrital

Francisco José de Caldas.

14. Slapadd: Herramienta del software OpenLDAP utilizada para agregar

elementos a un directorio LDAP.

15. Testldap: Herramienta del software OpenLDAP utilizada entre otras cosas

para convertir archivos de configuración de acuerdo a la jerarquía de

esquemas del Directorio LDAP.

P á g i n a | 75


16. Trabajo (Talend): Subrutina creada en el software Talend diseñada para

automatizar tareas que implican tratamiento de datos entre diferentes fuentes

de información.

17. Tupla: Conjunto ordenado de elementos (datos, principalmente) de

naturaleza generalmente diferente.

18. Volatilidad (información): Característica de la información que hace que

presente grandes variaciones a través del tiempo.

P á g i n a | 76


BIBLIOGRAFÍA

[1] Oficina Asesora De Sistemas. Universidad Distrital FJDC, «Plan Maestro de

Informática y Telecomunicaciones,» Universidad Distrital, Bogotá, 2012.

[2] Consejo Superior, Universidad Distrital Francisco José de Caldas, «Plan Maestro

de Desarrollo Fisico,» 30 junio 2009. [En línea]. Disponible en:

http://sgral.udistrital.edu.co/xdata/csu/res_2009-015.pdf.

[3] Consejo Superior. Universidad Distrital Francisco José de Caldas, «Secretaría

General. Acuerdo 01 de 2008,» 18 Enero 2008. [En línea]. Disponible en:

http://sgral.udistrital.edu.co/xdata/csu/acu_2008-001.pdf. [Último acceso: Agosto

2016].

[4] A. Silberschatz, Fundamentos de Bases de Datos. Cuarta Edición en español,

Madrid. España: McGraw-Hill Inc, 2002.

[5] J. Sermersheim, «RFC 4511. Lightweight Directory Access Protocol (LDAP): The

Protocol,» 2006.

[6] MIT, «LDAP. Red Hat Enterprise Linux 4: Manual de referencia.,» [En línea].

Disponible en: http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/ch-ldap.html .

[Último acceso: Agosto 2016].

[7] R. Kimball y M. Ross, 1. Kimball, Ralph. The data warehouse toolkit: the complete

guide to dimensional modeling / — 2nd Ed., Kimball Group, 2002.

[8] Oracle, «Data Warehousing Guide. 11g Release 2 (11.2),» Julio 2013. [En línea].

Disponible en: https://docs.oracle.com/cd/E11882_01/server.112/e25554.pdf.

[Último acceso: Agosto 2016].

[9] I. &. Galemmo, Mastering Data Warehouse Design: Relational and Dimensional

Techniques, Wiley Publishing, 2003.

[10] IBM, Gestión de Datos Maestros. Superar la visión única para encontrar la visión

adecuada., http://www-05.ibm.com/services/es/cio/pdf/CIO_Series_0402.pdf,

2007.

[11] D. J. Anderson, Kanban: Successful Evolutionary Change for Your Technology

Business, Kanban Group, 2010.

[12] K. Scotland, «Aspects of Kanban,» Methods & Tools, 2012. [En línea]. Disponible

en: http://www.methodsandtools.com/archive/archive.php?id=104. [Último acceso:

Agosto 2016].

[13] freeipa.org, «freeipa.org,» [En línea]. Disponible en:

https://www.freeipa.org/page/About. [Último acceso: 21 Septiembre 2016].

[14] The OpenLDAP Project, «OpenLDAP,» [En línea]. Disponible en:

http://www.openldap.org/project/. [Último acceso: 21 septiembre 2016].

[15] PhpLDAPAdmin Project, «PhpLDAPAdmin,» [En línea]. Disponible en:

http://phpldapadmin.sourceforge.net/wiki/index.php/Main_Page. [Último acceso: 21

septiembre 2016].

P á g i n a | 77


[16] the PgAdmin Team, «PgAdmin,» [En línea]. Disponible en:

https://www.pgadmin.org/index.php. [Último acceso: 21 septiembre 2016].

[17] Talend Corporation, «Talend Data Integration,» [En línea]. Disponible en:

https://www.talend.com/products/data-integration. [Último acceso: 21 septiembre

2016].

[18] Enalean SAS, «Tuleap Project Managment,» [En línea]. Disponible en:

https://www.tuleap.org/get-started. [Último acceso: 21 septiembre 2016].

[19] Universidad Distrital francisco José de Caldas, «Dependencia Oficina Asesora de

Sistemas,» Universidad Distrital, 2010. [En línea]. Disponible en:

https://www.udistrital.edu.co/dependencias/tipica.php?id=10. [Último acceso:

Agosto 2016].

[20] Universidad Distrital Francisco José de Caldas, «Plan De acción Oficina Asesora

de Planeación. Vigencia 2016. (Corte inicial 2016).,» 2016. [En línea]. Disponible

en: http://chronos.udistrital.edu.co:8095/Icaro/. [Último acceso: Agosto 2016].

[21] Oficina Asesora de Sistemas. Universidad Distrital, Proyecto de Bodega de Datos,

Bogotá: Universidad Distrital, 2010.

[22] Oficina Asesora de Sistemas. Universidad Distrital, «Portal de Inteligencia de

Negocios,» Universidad Distrital, Bogotá, 2016.

[23] Toyota, «Just-in-Time — Philosophy of complete elimination of waste. Sitio

Corporativo,» Toyota, [En línea]. Disponible en: http://www.toyota-

global.com/company/vision_philosophy/toyota_production_system/just-in-

time.html. [Último acceso: Agosto 2016].

[24] Oficina Asesora de Planeación y Control. Universidad Distrital, «Sistema De

Información Geográfico Institucional GIS-UD. Informe ejecutivo de avance,»

Universidad Distrital, Bogotá, 2016.

P á g i n a | 78


ANEXOS

Anexo 1. Respuesta de la OAPC a solicitud de información sobre el Sistema

de Administración de Espacios Físicos.

Bogotá D.C., Octubre 27 de 2016


Estudiante Ingeniería de Sistemas

Universidad Distrital Francisco José de Caldas

Ciudad

Referencia: Sistema de Información Geográfica Institucional – Plan Maestro de Desarrollo Físico

Reciba un cordial saludo, mediante el presente nos permitimos dar a conocer algunos

aspectos relacionados con el proyecto del Sistema de Información Geográfica

Institucional:

1. El proyecto se enmarca en la resolución 015 del 30 de junio de 2009 y tiene

como referente su política número 7 “Sostenibilidad de la Infraestructura Física”

del Plan Maestro de Desarrollo Físico que resuelve implementar un Sistema

Integral para la Planeación, Administración y Protocolo de Mantenimiento de la

Planta Física general, apoyado en un SIG, con el fin de reglamentar la

organización espacial, el uso y administración de los espacios para el óptimo

funcionamiento de la infraestructura Institucional. Igualmente el Plan Maestro de

Informática y Telecomunicaciones define el Sistema de Información del Plan

Maestro de Desarrollo Físico como un modelo de información geoespacial y de

edificios por sede, de carácter distribuido y con una estructura de datos utilizada

para la representación de la información de arquitectura e ingeniería que debe

responder apropiadamente a los requerimientos de gestión académica y

administrativa de la UDFJC.

Adicionalmente en el Artículo N° 29 de la mencionada Resolución se estableció lo

siguiente:

“DOCUMENTOS Y PROYECTOS A ELABORAR: Son componentes determinantes en la

formulación de los planes de consolidación y desarrollo de proyectos específicos, los

estudios y diseños que se realicen para tal fin, labores a desarrollar en la Oficina

Asesora de Planeación y Control:

a. Inventario Físico Espacial: Actualización de Áreas, Usos y Planimetría

P á g i n a | 79


b. Formulación del Plan General de Ordenamiento Físico de la universidad

c. Implementar herramientas tecnológicas (SIG) como soporte administrativo de los espacios físicos de la Universidad.”

De igual manera, la Resolución N° 1101 de 2002, por la cual se establece el

Manual Descriptivo de Funciones Generales y Específicas de la Universidad Distrital;

establece como macro función de la Oficina Asesora de Planeación la de

“Establecer sistemas modernos de información que faciliten la gestión y el control”.

Asimismo, el jefe de la Oficina Asesora de Planeación tiene dentro de sus

funciones lo siguiente:

“9. Organizar y coordinar la utilización racional de la planta física de la institución según

las necesidades académicas y administrativas.

(…)

11. Adoptar herramientas gerenciales que permitan incorporar racionalidad en la

administración a partir de criterios de eficiencia, eficacia y efectividad, logrando el mejor

uso de los recursos humanos, físicos y financieros”.

Así las cosas, el apartado Planteamiento del Problema del anteproyecto

‘ANÁLISIS, DISEÑO Y DESARROLLO DE UN ALMACÉN DE DATOS PARA LA

ADMINISTRACIÓN DE DATOS MAESTROS DE ESPACIOS FÍSICOS DE LA UNIVERSIDAD

DISTRITAL FRANCISCO JOSÉ DE CALDAS’ presenta serias inconsistencias pues es la

Oficina Asesora de Planeación y Control quien ha liderado el proyecto

ejecutándolo mediante recursos provenientes del proyecto de inversión 380

“Mejoramiento y Ampliación de la Planta Física”.

2. Articulación con la Oficina Asesora de Sistemas.

De acuerdo con la Resolución 1101 de 2002, el jefe de la OAS tiene dentro de

sus funciones: “Asesorar a las directivas y a las diferentes dependencias de la

Universidad en los asuntos relacionados con sistemas de información”; y dentro

de las de la macro-funciones de la Oficina Asesora de Sistemas está: “Prestar

asesoría y soporte técnico a profesores estudiantes y trabajadores (…) en el

desarrollo de sistemas manuales y automáticos a todas las dependencias de la

Universidad”. Bajo este marco, y en el desarrollo metodológico de la segunda

etapa del proyecto “CONSOLIDACIÓN DEL SIG INSTITUCIONAL”, la OAS y la OAPC

están trabajando articuladamente para lograr al mes de diciembre del año en

curso el “Diseño e implementación de interfaces para la administración,

sostenibilidad y acceso a la información de la Base de Datos Espacial” que soporte la

etapa de visualización del SIG institucional y la consolidación de la Información

geográfica mediante la migración de la misma a la base de datos acorde a un

modelo lógico validado por la OAS e integrado con el Sistema de Gestión

P á g i n a | 80


académica - Cóndor, con el fin de poner a servicio de la comunidad universitaria

la IG asociada a la planta física de la UDFJC.

3. Resultados del proyecto

A la fecha se resaltan los siguientes:

Etapa de Implementación

Componente Unidad de Medida

Línea Estado

Base Actual

(Año (Año

2008) 2016)

Etap

a N

° 1

: C

on

form

ació

n B

ase

Ge

ogr

áfic

a

Procesos de Actualización de Datos Escala Arquitectónica y Sede

Cantidad 0 2

Estructura de Codificación

Cantidad 0 1

Estructura de Tipificación y Clasificación de Espacios

Usos Generales 11 5

Tipos de Espacio 44 64

Subtipos de Espacio 0 89

Planimetría Oficial

Codificación

Escala

48 155 Estandarizada y Verificada

Arquitectónica

Escala Sede 0 12

Estandarización

Escala

0 155 Arquitectónica

Escala Sede 0 12

Verificación y Ajuste

Escala

0 155 Arquitectónica

Atributos Asociados a los Espacios Físicos

Escala Arquitectónica 38 75

Escala Sede 0 38

Espacios Físicos Inventariados


Escala Sede 0 272

Reportes de Información


Alfanuméricos

P á g i n a | 81


Estandarizados y Escala Sede 0 18

Codificados Escala Urbana 1 13

Reportes de Información

Geográficos (Mapas)

Escala Urbana 1 30 Estandarizados y Codificados

Sesiones de Trabajo Software GIS

Cantidad 10 43

Capas Geográficas Generadas

Cantidad 0 28

Modelos de Geo procesamiento

Cantidad 0 4

Uso de visor web de datos geográficos

Cantidad 0 1

Diseño e Implementación

de Página Web para la Divulgación de Reportes Cantidad 0 1

Geográficos de la Planta

Física Institucional

Etap

a N

° 2

: C

on

solid

aci

ón

SIG

Inst

itu

cio

nal

Ite

raci

ón

N°

1

Levantamiento de

Cantidad 0 1 Requerimientos y

Documentación

Diagnóstico General de Clasificación de la I.G

Cantidad 0 1

Diseño Conceptual, Físico y Lógico de la BDE

Cantidad 0 1

Diseño Preliminar

Cantidad 0 1 Arquitectura del Sistema

P á g i n a | 82


Casos de Uso Levantados y Especificados

Cantidad 0 16

Ite

raci

ón

N°

2

Procesos de Actualización de Datos Escala Arquitectónica y Sede

Cantidad 0 1

Procedimientos para la Gestión de Información del SIG Institucional

Cantidad 0 1

Capas Geográficas

Estructuradas según Diseño BDE

Cantidad 0 44

Tablas de Datos

Estructuradas según Diseño BDE

Cantidad 0 83

Dado que el Sistema de Información Geográfica Institucional es el componente

articulador del Sistema de Administración de la Planta Física - SAPFUD debido a que

brinda el soporte tecnológico y de información necesario para la actuación y

funcionamiento integral del sistema, se mencionan a continuación los avances

relacionados con los procedimientos de gestión de infraestructura física que soporta el

SIG institucional.

INDICADORES DE AVANCE - IMPLEMENTACIÓN SISTEMA DE

ADMINISTRACIÓN DE LA PLANTA FÍSICA (2008-2016)

Procedimiento Componente

Línea Base (Año 2008)

Estad o Actual (Año 2016)

Planificación Consolidación de

Sedes Existentes

Programas de Áreas y Necesidades Elaborados

0 4

Planes de Reordenamiento Físico - Espacial 0 5

Estudios técnicos para el saneamiento Jurídico de predios ocupados por Sedes

Existentes 2 2

Saneamiento efectuado (títulos de

propiedad otorgados) 0 1

Incorporaciones topográficas y proyección

de minutas para saneamiento de predios 0 1

Levantamientos y Diagnósticos Urbano

Catastrales ejecutados 0 2

P á g i n a | 83


Lotes de Terreno Adquiridos mediante

procesos de Gestión Predial 0 1

Nuevos

Equipamientos

Educativos

Programas de Áreas y Necesidades Elaborados

0 1

Estudios Técnicos y Modelos de Geoprocesamiento para la Expansión y Crecimiento de las Sedes Universitarias

0 2

Lotes de Terreno Adquiridos mediante

procesos de Gestión Predial 0 1

Levantamientos y Diagnósticos Urbano

Catastrales ejecutados 0 2

Incorporación

Procedimiento documentado (caracterización y flujograma)

0 1

Formatos estandarizados que soporten el

procedimiento 0 1

Predios incorporados mediante la

implementación gradual del procedimiento 0 4

Estudios técnicos de viabilidad para la

incorporación de inmuebles 0 14

Instrumentos normativos transitorios

adoptados (Circulares) 0 1

Intervención


0 1

Formatos estandarizados que soporten el

procedimiento 0 3

Instrumentos normativos transitorios

adoptados (Circulares) 0 2

Propuesta de estructura de administración

implementada para el procedimiento 0 1

Solicitudes tramitadas y analizadas para

retroalimentar el procedimiento 0 145

Asignación

de Espacios

Físicos

Asignación de

Espacios Físicos de

Uso Académico (Asignación

Semestral)


0 2

Herramienta tecnológica para la asignación

óptima de espacios (Macro Excel) 0 1

Lineamientos Técnicos para la Elaboración de

Horarios 0 3

Módulo de Gestión de Espacios Físicos - Cóndor

0 1

Reportes Estandarizados Utilización de

Espacios Físicos Académicos 0 16

Asignación de


Uso Académico (Asignación

Transitoria)

Nodos de administración del

procedimiento implementados 0 2

Espacios web diseñados e implementados

para la reserva de espacios físicos 0 1

Asignaciones Efectuadas Uso

Administrativo y Servicios 0 36

Asignación de


Solicitudes tramitadas y analizadas para

retroalimentar el procedimiento 0 73

P á g i n a | 84


Uso

Administrativo, Común y Servicios.

Criterios para el arrendamiento de

espacios físicos para la prestación de

bienes y servicios

0 1

Estos avances y en especial los resultados obtenidos de la primera etapa del SIG

(Conformación de la Base Geográfica), han sido el insumo que le ha permitido a la

institución avanzar en la gestión de su infraestructura física en los diferentes niveles

(Operativo, Táctico y estratégico), dentro de los cuales se destacan los siguientes:

- Asignación de Espacios Físicos.

- Diseño e Implementación de Módulos Informáticos y Web.

- Incorporación de inmuebles al sistema de sede de la Universidad.

- Planes de mantenimiento para el sistema de sedes de la Universidad.

- Procesos de Reordenamiento Físico en las sedes (Vivero, Porvenir, Macarena

y Tecnológica).

- Programas de Áreas y Necesidades para los proyectos del PMDF.

- Estudios Técnicos y Modelos de Geoprocesamiento para la Expansión y

Crecimiento de las Sedes Universitarias.

- Módulo de Gestión de Espacios Físicos en el Sistema Cóndor.

- Reportes de información para los procesos de acreditación y renovación del

registro calificado de los programas de pregrado y posgrado.

Sin otro particular agradezco de antemano la atención prestada.

Cordialmente,

GRUPO DE DESARROLLO FÍSICO

Oficina Asesora de Planeación y Control

Universidad Distrital Francisco José de Caldas

P á g i n a | 85


Anexo 2. Respuesta de la OAPC a solicitud de información sobre el Sistema

de Administración de la Planta Física SAPF-UD.

P á g i n a | 86


P á g i n a | 87


P á g i n a | 88


P á g i n a | 89


P á g i n a | 90


P á g i n a | 91


P á g i n a | 92


P á g i n a | 93


P á g i n a | 94


P á g i n a | 95


P á g i n a | 96


P á g i n a | 97


P á g i n a | 98


Anexo 3. Detalles Técnicos. Trabajo ETL Mapeo de Sedes a LDIF

Jobs

Generated by Talend Open Studio for Data Integration

Description

Properties Values

Name cargar_a_LDIF

Author [email protected]

Version 1.0

Purpose

Status PRODUCTION

Description

Creation Oct 10, 2016 3:18:46 PM

Modification Nov 11, 2016 8:08:01 AM

Preview Picture

Component List

Component Name Component Type

tFileOutputLDIF_2 tFileOutputLDIF

tPostgresqlInput_2 tPostgresqlInput

Components Description

Component tFileOutputLDIF

UNIQUE NAME tFileOutputLDIF_2

INPUT(S) tPostgresqlInput_2

LABEL sedes OUTPUT(S) none

mailto:[email protected]

P á g i n a | 99


Component Parameters:

Properties Values

Unique Name tFileOutputLDIF_2

Component Name tFileOutputLDIF

Version 0.101 (ALPHA)

Family File/Output

Startable false

SUBTREE_START false

END_OF_FLOW true

Activate true

DUMMY false

tStatCatcher Statistics false

Help org.talend.help.tFileOutputLDIF

Update components true

IREPORT_PATH

JAVA_LIBRARY_PATH /home/daniel/Downloads/TOS_DI 20160704_1411V6.2.1/configuration/lib/java

Subjob color

Title color

File Name "/home/daniel/Downloads/TOS_DI 20160704_1411V6.2.1/workspace/sedes.ldif"

Wrap 78

Change type none

REPOSITORY_ALLOW_AUTO

_SWITCH

false

Schema BuiltIn

Append false

Validate Attribute Value false

Create directory if does not

exist

true

Custom the flush buffer size false

Row number 1

Encoding "ISO885915"

Don't generate empty file false

Label format sedes

Hint format UNIQUE_NAME 

 COMMENT

Connection format row

Show Information false

Comment

Use an existing validation rule false

Validation Rule Type

P á g i n a | 100


Schema for tFileOutputLDIF_2 :

Column Key Type Length Precision Nullable Comment

id false String true

ou false String 4 false

objectclass false String true

description false String 50 false

Original Function Parameters:

Component

tPostgresqlInput

UNIQUE NAME tPostgresqlInput_2 INPUT(S) none

LABEL PosgresSQL OUTPUT(S) tFileOutputLDIF_

2


Properties Values

Unique Name tPostgresqlInput_2

Component Name tPostgresqlInput


Family Databases/PostgreSQL

Start true

Startable true

SUBTREE_START true

END_OF_FLOW false

Activate true

DUMMY false


Help org.talend.help.tPostgresqlInput


IREPORT_PATH


Subjob color

Title color

Property Type repository: DB

(POSTGRESQL):PosgresSQL Use an existing connection false

Component List

DB Version PRIOR_TO_V9

Host "localhost"

Database Driver POSTGRESQL

P á g i n a | 101


Port "5432"

Database "dbEspacios"

Schema "public"

Username "postgres"

Password *************

REPOSITORY_ALLOW_AUTO_SWITCH false

Schema BuiltIn

Table Name ""

Query Type BuiltIn

Guess Schema ""

Query

"SELECT 'ou=' || \"SEDE\".id

||',ou=sedes,dc=co,dc=udistrital,dc=dwh'a

s id,

\"SEDE\".id as ou,

'organizationalUnit' as objectclass,

\"SEDE\".nombre as description

FROM public.\"SEDE\""

Specify a data source alias false

Data source alias ""

Mapping postgres_id


Use cursor false

Cursor size 1000

Trim all the String/Char columns false

Trim column

[{TRIM=false, SCHEMA_COLUMN=id},

{TRIM=false, SCHEMA_COLUMN=ou},

{TRIM=false,

SCHEMA_COLUMN=objectclass},

{TRIM=false,

SCHEMA_COLUMN=description}]

Label format PosgresSQL


 COMMENT



Comment



Schema for tPostgresqlInput_2 :

P á g i n a | 102


Anexo 4. Detalles técnicos. Trabajo ETL Mapeo de Edificios a LDIF

Jobs


Description

Properties Values

Name cargar_a_LDIF


Version 0.1

Purpose

Status PRODUCTION

Description



Preview Picture

Component List





P á g i n a | 103




UNIQUE NAME

tFileOutputLDIF_3 INPUT(S) tPostgresqlInput_3

LABEL edificios OUTPUT(S) none


Properties Values




Family File/Output

Startable false

SUBTREE_START false

END_OF_FLOW true

Activate true

DUMMY false




IREPORT_PATH


Subjob color

Title color

File Name "/home/daniel/Downloads/TOS_DI 20160704_1411V6.2.1/workspace/edificios.ldif"

Wrap 78

Change type none


Schema BuiltIn

Append false


Create directory if does not exist true


Row number 1



Label format edificios


 COMMENT

P á g i n a | 104


Comment



Schema for tFileOutputLDIF_3 :







Component tPostgresqlInput

UNIQUE NAME

tPostgresqlInput_3 INPUT(S) none

LABEL PosgresSQL OUTPUT(S) tFileOutputLDIF_3


Properties Values





Start true

Startable true

SUBTREE_START true

END_OF_FLOW false

Activate true

DUMMY false




IREPORT_PATH


Subjob color

Title color

Property Type repository: DB

(POSTGRESQL):PosgresSQL

P á g i n a | 105


Use an existing connection false

Component List


Host "localhost"


Port "5432"


Schema "public"

Username "postgres"

Password *************


Schema BuiltIn

Table Name ""

Query Type BuiltIn

Guess Schema ""

Query

"SELECT 'ou=' || \"EDIFICIO\".id || ',ou='||\"EDIFICIO\".id_sede

||',ou=sedes,dc=co,dc=udistrital,dc=dwh'a

s id,

\"EDIFICIO\".id as ou, 'organizationalUnit'

as objectclass, \"EDIFICIO\".nombre as

description FROM public.\"EDIFICIO\""



Mapping postgres_id


Use cursor false

Cursor size 1000


Trim column

[{TRIM=false, SCHEMA_COLUMN=id},

{TRIM=false, SCHEMA_COLUMN=ou},

{TRIM=false,

SCHEMA_COLUMN=objectclass},

{TRIM=false,

SCHEMA_COLUMN=description}]



 COMMENT



Comment

P á g i n a | 106








P á g i n a | 107


Anexo 5. Detalles técnicos. Trabajo ETL mapeo de espacios físicos a LDIF.

Jobs


Description

Properties Values

Name cargar_a_LDIF


Version 0.1

Purpose

Status PRODUCTION

Description



Preview Picture

Context List

Component List



tMap_1 tMap



P á g i n a | 108




UNIQUE NAME tFileOutputLDIF_1 INPUT(S) tMap_1

LABEL espacios_fisicos OUTPUT(S) none


Properties Values




Family File/Output

Startable false

SUBTREE_START false

END_OF_FLOW true

Activate true

DUMMY false




IREPORT_PATH

JAVA_LIBRARY_PATH /home/daniel/Downloads/TOS_DI

20160704_1411V6.2.1/configuration/lib/java

Subjob color

Title color

File Name "/home/daniel/Downloads/TOS_DI

20160704_1411V6.2.1/workspace/espacios.ldif"

Wrap 278

Change type none

REPOSITORY_ALLOW_AUTO_SWITC

H

false

Schema BuiltIn

Append false


Create directory if does not exist true


Row number 1

Encoding "UTF8"


Label format espacios_fisicos


 COMMENT



Comment

P á g i n a | 109


Schema for tFileOutputLDIF_1:





description false Object false

planta false String 2 false

estancia false int 10 false

idsede false String 4 false

nombresede false String 50 false

idedificio false String 10 false

edificio false String 100 false

idtipo false int 10 false

tipo false String 100 false

idsubtipo false int 10 false

subtipo false int 10 false

usoprincipal false String true

area false Float 8 8 true

activo false String true




LABEL PosgresSQL OUTPUT(S) tMap_1


Properties Values





Start true

Startable true

SUBTREE_START true

END_OF_FLOW false

Activate true

DUMMY false




IREPORT_PATH

JAVA_LIBRARY_PATH /home/daniel/Downloads/TOS_DI

20160704_1411V6.2.1/configuration/lib/java

P á g i n a | 110


Subjob color

Title color

Property Type repository: DB (POSTGRESQL):PosgresSQL


Component List


Host "localhost"


Port "5432"


Schema "public"

Username "postgres"

Password *************


Schema BuiltIn

Table Name ""

Query Type BuiltIn

Guess Schema ""

Query

"SELECT 'ou=' || \"ESPACIO_FISICO\".id ||',ou='

|| \"EDIFICIO\".id || ',ou=' || \"SEDE\".id ||

',ou=sedes,dc=co,dc=udistrital,dc=dwh'as id,

\"ESPACIO_FISICO\".id as ou, 'EspacioFisico' as

objectclass, \"ESPACIO_FISICO\".nombre as description,

\"ESPACIO_FISICO\".planta,

\"ESPACIO_FISICO\".estancia, \"SEDE\".id AS idsede,

\"SEDE\".nombre AS nombresede,

\"EDIFICIO\".id AS idedificio,

\"EDIFICIO\".nombre AS edificio,

\"TIPO_ESPACIO_FISICO\".id AS idtipo,

\"TIPO_ESPACIO_FISICO\".descripcion AS tipo,

\"SUBTIPO_ESPACIO_FISICO\".id AS idsubtipo,

\"SUBTIPO_ESPACIO_FISICO\".id_tipo_espacio AS

subtipo, \"ESPACIO_FISICO\".uso_principal AS

usoprincipal, \"ESPACIO_FISICO\".area, (case when

\"ESPACIO_FISICO\".activo='t' then 'TRUE' else 'FALSE'

end) as activo FROM public.\"ESPACIO_FISICO\",

public.\"SEDE\", public.\"EDIFICIO\",

public.\"TIPO_ESPACIO_FISICO\",

public.\"SUBTIPO_ESPACIO_FISICO\" WHERE

\"ESPACIO_FISICO\".subtipo_espacio =

\"SUBTIPO_ESPACIO_FISICO\".id AND

\"ESPACIO_FISICO\".tipo_espacio =

\"TIPO_ESPACIO_FISICO\".id AND

\"ESPACIO_FISICO\".edificio = \"EDIFICIO\".id AND

\"EDIFICIO\".id_sede = \"SEDE\".id AND

\"SUBTIPO_ESPACIO_FISICO\".id_tipo_espacio

= \"TIPO_ESPACIO_FISICO\".id"

P á g i n a | 111




Mapping postgres_id


Use cursor false

Cursor size 1000




 COMMENT



Comment








description false String false

planta false String 2 false

estancia false int 10 false

idsede false String 4 false

nombresede false String 50 false

idedificio false String 10 false

edificio false String 100 false

idtipo false int 10 false

tipo false String 100 false

idsubtipo false int 10 false

subtipo false int 10 false


area false Float 8 8 true



Component tMap

UNIQUE NAME tMap_1 INPUT(S) tPostgresqlInput_1

LABEL UNIQUE_NAME OUTPUT(S) tFileOutputLDIF_1

P á g i n a | 112



Properties Values


Mapping links display as: AUTO

Temp data directory path:

Max buffer size (nb of rows): 2000000

Ignore trailing zeros for BigDecimal false


Comment


Mapper table for tMap_1 ( input ): Mapper table Properties( row1 ):

Properties Values

Name row1

Matchingmode UNIQUE_MATCH

isMinimized false

isReject false

isRejectInnerJoin false

isInnerJoin false

expressionFilter null

Metadata Table Entries( row1 ):

Name Type Expression isNullable

id String true

ou String false

objectclass String true

description String false

planta String false

estancia int false

idsede String false

nombresede String false

idedificio String false

edificio String false

idtipo int false

tipo String false

idsubtipo int false

subtipo int false

usoprincipal String true

area Float true

activo String true

P á g i n a | 113


Mapper table for tMap_1 ( output ):

Mapper table Properties( s1 ):

Properties Values

Name s1

Matchingmode

isMinimized false

isReject false


isInnerJoin false


Metadata Table Entries( s1 ):


id String row1.id true

ou String row1.ou false

objectclass String row1.objectclass true

description

Object

StringHandling.EREPLACE(StringHandling.EREPLAC

E(StringHandling.EREPLACE(StringHandling.EREPLA

CE(StringHandling.EREPLACE(StringHandling.EREPL

ACE(StringHandling.EREPLACE((StringHandling.ERE

PLACE((StringHandling.EREPLACE(row1.description,"

Á","A")),"É","E")),"Í","I"),"Ó","O"),"Ú","U"),"Ñ","N"),"Ü","

U"),"¿","x"),"N°","No.")"Ú","U"),"Ñ","N"),"Ü","U"),"¿","x"),

"N°","No.")

false

planta String row1.planta false

estancia int row1.estancia false

idsede String row1.idsede false

nombresede

String






Á","A")),"É","E")),"Í","I"),"Ó","O"),"Ú","U"),"Ñ","N"),"Ü","

U"),"¿","x"),"N°","No.")

false

idedificio String row1.idedificio false

edificio

String






Á","A")),"É","E")),"Í","I"),"Ó","O"),"Ú","U"),"Ñ","N"),"Ü","

U"),"¿","x"),"N°","No.")

false

idtipo int row1.idtipo false

P á g i n a | 114


tipo

String






Á","A")),"É","E")),"Í","I"),"Ó","O"),"Ú","U"),"Ñ","N"),"Ü","

U"),"¿","x"),"N°","No.")

false

idsubtipo int row1.idsubtipo false

subtipo int row1.subtipo false

usoprincipal

String






Á","A")),"É","E")),"Í","I"),"Ó","O"),"Ú","U"),"Ñ","N"),"Ü","

U"),"¿","x"),"N°","No.")

true

area Float row1.area true

activo String row1.activo true

Mapper table for tMap_1 ( var ):

Mapper table Properties( Var ):

Properties Values

Name Var

Matchingmode

isMinimized true

isReject false


isInnerJoin false


P á g i n a | 115


Anexo 6: Detalles técnicos. Trabajo ETL entre LDAP y Tabla Dimensional.

Jobs


Description

Properties Values

Name cargar_a_DataMart


Version 1.0

Purpose cargar el DataMart desde el LDAP

Status DEV

Description Cargar el DataMart con los datos del LDAP


Modification Oct 22, 2016 1:18:17 AM

Preview Picture

Component List


tConvertType_1 tConvertType

tLDAPInput_1 tLDAPInput

tMap_1 tMap

tPostgresqlOutput_1 tPostgresqlOutput


Component tConvertType

UNIQUE NAME tConvertType_1 INPUT(S) tLDAPInput_1

LABEL UNIQUE_NAME OUTPUT(S) tMap_1


P á g i n a | 116



Properties Values

Unique Name tConvertType_1

Component Name tConvertType


Family Processing

Startable false

SUBTREE_START false

END_OF_FLOW false

Activate true

DUMMY false


Help org.talend.help.tConvertType


IREPORT_PATH

JAVA_LIBRARY_PATH /home/daniel/Downloads/TOS_DI20160704_1411 V6.2.1/configuration/lib/java

Subjob color

Title color


Schema BuiltIn

Auto Cast true

Manual Cast []

Schema BuiltIn Set empty values to Null before converting

true

Die on error false

Label format UNIQUE_NAME

Hint format UNIQUE_NAME 

COMMENT



Comment



Schema for metadata :

Column Key Type

Length Precision Nullable Comment

ou false String true

description false String true

activo false Boolean true

area false String true

edificio false String true

estancia false String true

idEdificio false String true

idSede false String true

idSubtipo false String true

idTipo false String true

nombreSede false String true

P á g i n a | 117


planta false String true

subTipo false String true

tipo false String true

usoPrincipal false String true

Original Function Parameters: Component tLDAPInput

UNIQUE NAME tLDAPInput_1 INPUT(S) none

LABEL LDAPEspacios OUTPUT(S) tConvertType_1


Properties Values

Unique Name tLDAPInput_1

Component Name tLDAPInput


Family Databases/LDAP

Start true

Startable true

SUBTREE_START true

END_OF_FLOW false

Activate true

DUMMY false


Help org.talend.help.tLDAPInput


IREPORT_PATH

JAVA_LIBRARY_PATH /home/daniel/Downloads/TOS_DI20160

704_1411 V6.2.1/configuration/lib/java

Subjob color

Title color

Property Type BuiltIn


Component List

Host "127.0.0.1"

Port 389

Base DN "ou=sedes,dc=co,dc=udistrital,dc=dwh"

Protocol LDAP

Advanced CA false

Store CA to "c::/mycacerts"

Keystore password **

Trust all certs false

Authentication true

User "cn=admin,dc=co,dc=udistrital,dc=dwh"

P á g i n a | 118


Password *************

Alias dereferencing always

Referral handling ignore

Filter "(&(objectClass=EspacioFisico))"

Multi valued field separator ";"

Limit 1200

Time Limit 0

Paging false

Page Size 100

Die on error true


Schema BuiltIn

Reject Schema BuiltIn

Use field options(for binary setting) false

Field options

[{BINARY=false, SCHEMA_COLUMN=ou},

{BINARY=false,

SCHEMA_COLUMN=description}, {BINARY=false, SCHEMA_COLUMN=planta}, {BINARY=false, SCHEMA_COLUMN=estancia}, {BINARY=false, SCHEMA_COLUMN=idsede}, {BINARY=false, SCHEMA_COLUMN=nombresede}, {BINARY=false, SCHEMA_COLUMN=idedificio}, {BINARY=false, SCHEMA_COLUMN=edificio}, {BINARY=false, SCHEMA_COLUMN=idtipo}, {BINARY=false, SCHEMA_COLUMN=tipo}, {BINARY=false, SCHEMA_COLUMN=idsubtipo}, {BINARY=false, SCHEMA_COLUMN=subtipo}, {BINARY=false, SCHEMA_COLUMN=area}, {BINARY=false, SCHEMA_COLUMN=usoprincipal}, {BINARY=false, SCHEMA_COLUMN=activo}]

Label format LDAPEspacios


COMMENT



Comment



Schema for metadata :


ou false String true

description false String 18 true

planta false String true

estancia false String true

idsede false String true

nombresede false String true

P á g i n a | 119


idedificio false String true

edificio false String true

idtipo false String true

tipo false String true

idsubtipo false String true

subtipo false String true

area false String true



Original Function Parameters: Component tPostgresqlOutput

UNIQUE NAME tPostgresqlOutput_1 INPUT(S) tMap_1

LABEL TABLE OUTPUT(S) none


Properties Values

Unique Name tPostgresqlOutput_1

Component Name tPostgresqlOutput



Startable false

SUBTREE_START false

END_OF_FLOW true

Activate true

DUMMY false


Help org.talend.help.tPostgresqlOutput


IREPORT_PATH

JAVA_LIBRARY_PATH /home/daniel/Downloads/TOS_DI20160704_1411 V6.2.1/configuration/lib/java

Subjob color

Title color

Property Type repository: DB (POSTGRESQL):DataMart


Component List


Host "localhost"

Port "5432"

Database "DMDEspacios"


Schema "public"

Username "postgres"

Password *************

Table "d_espacios_fisicos"

Action on table NONE

Action on data INSERT

P á g i n a | 120



Schema repository: DB (POSTGRESQL):DataMart D_Espacios_Fisicos

Reject Schema repository: DB (POSTGRESQL):DataMart D_Espacios_Fisicos

Use spatial options false

Create Spatial index false

Create geometry columns reference false



Die on error false

Mapping postgres_id

Use save point false


Commit every 10000

Additional columns []

Use field options false

Enable debug mode false

Support null in "SQL WHERE" statement false

Use Batch Size true

Batch Size 10000

Label format TABLE


COMMENT



Comment



Schema for D_Espacios_Fisicos :

Column Key

Type Length Precision Nullable Comment

id

false

String

50

false

identificador unico del espacio fisico. Llave compuesta por la concatenacion de (id_edificio)planta) (estancia)

nombre false String 300

true nombre del espacio fisico

estancia

false

String

50

true

espacio en el cual se ubica el espacio fisico dentro de la planta

sede

false

String

20

true

id de la sede en la cual se encuentra el espacio fisico

P á g i n a | 121


nombre_sede

false

String

200

true

nombre de la sede en la cual se encuentra el espacio fisico

codigo_edificio

false

String

50

true

id del edificio en el cual se encuentra el espacio fisico

edificio

false

String

200

true

nombre del edificio en el cual se encuentra el espacio fisico

codigo_tipo false String 50

true id del tipo de espacio fisico

tipo

false

String

150

true

descripcion del tipo de espacio fisico

codigo_sub_tipo

false String 50

true id del subtipo de espacio fisico

sub_tipo

false

String

150

true

descripcion del sub tipo de espacio fisico

uso_principal

false

String

150

true

uso principal al cual se destina el espacio fisico

activo

false

Boolean

1

true

verdadero si esta activo falso si no esta activo (logico, no ;) )

area

false

String

20

true

area en metros cuadrados del espacio fisico

planta

false

String

50

true

planta (piso) en el cual se ubica el espacio fisico

Original Function Parameters: Component tMap

UNIQUE NAME tMap_1 INPUT(S) tConvertType_1

LABEL UNIQUE_NAME OUTPUT(S) tPostgresqlOutput_1


Properties Values





P á g i n a | 122


Ignore trailing zeros for BigDecimal false


Comment


Mapper table for tMap_1 (input ): Mapper table Properties( row2 ):

Properties Values

Name row2


isMinimized false

isReject false


isInnerJoin false




ou String true

description String true

activo Boolean true

area String true

edificio String true

estancia String true

idEdificio String true

idSede String true

idSubtipo String true

idTipo String true

nombreSede String true

planta String true

subTipo String true

tipo String true

usoPrincipal String true

Mapper table Properties( salidaBD ):

Properties Values

Name salidaBD

Matchingmode

isMinimized false

isReject false


isInnerJoin false


P á g i n a | 123


Metadata Table Entries( salidaBD ):


id String row2.ou false

nombre String row2.description true

estancia String row2.estancia true

sede String row2.idSede true

nombre_sede String row2.nombreSede true

codigo_edificio String row2.idEdificio true

edificio String row2.edificio true

codigo_tipo String row2.idTipo true

tipo String row2.tipo true

codigo_sub_tipo String row2.idSubtipo true

sub_tipo String row2.subTipo true

uso_principal String row2.usoPrincipal true

activo Boolean row2.activo true

area String row2.area true

planta String row2.planta true

Mapper table for tMap_1 ( var ): Mapper table Properties( Var ):

Properties Values

Name Var

Matchingmode

isMinimized true

isReject false


isInnerJoin false


P á g i n a | 124


Anexo 7: Detalles técnicos. Trabajo ETL carga a tabla de Hechos.

Jobs


Description

Properties Values

Name cargar_tabla_hechos


Version 0.1

Purpose alimentar la tabla de hechos desde las fuentes de datos

Status TEST

Description

Se utilizan las fuentes de datos (Inicialmente LDAP de organigrama y db.tabla d_espacios_fisicos para llenar la tabla de hechos

Creation Oct 22, 2016 11:04:15 AM

Modification Oct 24, 2016 4:23:58 PM

Preview Picture

Settings

Name Value

COMP_DEFAULT_FILE_DIR

Multi thread execution false

Implicit tContextLoad false

Status & Logs

Name Value

Use statistics (tStatCatcher) false

Use logs (tLogCatcher) false

Use volumetrics (tFlowMeterCatcher) false

On Console false


P á g i n a | 125


On Files false

On Databases false

Catch components statistics false

Catch runtime errors true

Catch user errors true

Catch user warnings true

Component List


tLDAPInput_1 tLDAPInput

tMap_1 tMap


tPostgresqlOutput_1 tPostgresqlOutput


Component tLDAPInput

UNIQUE NAME tLDAPInput_1 INPUT(S) none

LABEL metadataOrganigr

ama

OUTPUT(S) tMap_1


Properties Values

Unique Name tLDAPInput_1

Component Name tLDAPInput


Family Databases/LDAP

Start false

Startable true

SUBTREE_START false

END_OF_FLOW false

Activate true

DUMMY false


Help org.talend.help.tLDAPInput


IREPORT_PATH

JAVA_LIBRARY_PATH /home/daniel/Downloads/TOS_DI20160704_1411V6.2.1/

configuration/lib/java

Subjob color

Title color

Property Type repository: LDAP:LDAPOrganigrama


Component List

Host "127.0.0.1"

Port 389

Base DN "ou=organigrama,dc=co,dc=udistrital,dc=dwh"

P á g i n a | 126


Protocol LDAP

Advanced CA false

Store CA to "c::/mycacerts"

Keystore password **

Trust all certs false

Authentication true

User "cn=admin,dc=co,dc=udistrital,dc=dwh"

Password *************

Alias dereferencing always

Referral handling ignore

Filter "(&(objectClass=*)(!(ou=organigrama)))"

Multi valued field separator ";"

Limit 1000

Time Limit 0

Paging false

Page Size 100

Die on error true


Schema BuiltIn

Reject Schema BuiltIn

Use field options(for binary setting) false

Field options [{BINARY=false, SCHEMA_COLUMN=ou}, {BINARY=false, SCHEMA_COLUMN=description}]

Label format metadataOrganigrama

Hint format UNIQUE_NAME COMMENT



Comment



Schema for metadataOrganigrama :


ou false String 11 true

description false String 52 true




LABEL TABLE OUTPUT(S) tMap_1


Properties Values

P á g i n a | 127





Start true

Startable true

SUBTREE_START true

END_OF_FLOW false

Activate true

DUMMY false




IREPORT_PATH

JAVA_LIBRARY_PATH /home/daniel/Downloads/TOS_DI20160704_1411V6.2.1/confi

guration/lib/java

Subjob color

Title color



Component List


Host "localhost"


Port "5432"


Schema "public"

Username "postgres"

Password *************

REPOSITORY_ALLOW_AU

TO_SWITCH

false

Schema repository: DB (POSTGRESQL):DataMart

D_Espacios_Fisicos

Table Name "d_espacios_fisicos"

Query Type BuiltIn

Guess Schema ""

P á g i n a | 128


Query

"SELECT

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"id\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"nombre\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"estancia\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"sede\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"nombre_sed

e\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"codigo_edifi

cio\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"edificio\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"codigo_tipo\

",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"tipo\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"codigo_sub_

tipo\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"sub_tipo\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"uso_principa

l\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"activo\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"area\",

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\".\"planta\"

FROM

\"DMDEspacios\".\"public\".\"d_espacios_fisicos\""



Mapping postgres_id


Use cursor false

Cursor size 1000

Trim all the String/Char

columns false

Trim column

[{TRIM=false, SCHEMA_COLUMN=id}, {TRIM=false,

SCHEMA_COLUMN=nombre},

{TRIM=false, SCHEMA_COLUMN=estancia}, {TRIM=false,

SCHEMA_COLUMN=sede},

{TRIM=false, SCHEMA_COLUMN=nombre_sede},

{TRIM=false, SCHEMA_COLUMN=codigo_edificio},

{TRIM=false, SCHEMA_COLUMN=edificio},

{TRIM=false, SCHEMA_COLUMN=codigo_tipo}, {TRIM=false,

SCHEMA_COLUMN=tipo},

{TRIM=false, SCHEMA_COLUMN=codigo_sub_tipo},

{TRIM=false, SCHEMA_COLUMN=sub_tipo}, {TRIM=false,

SCHEMA_COLUMN=uso_principal}, {TRIM=false,

SCHEMA_COLUMN=activo}, {TRIM=false,

SCHEMA_COLUMN=area}, {TRIM=false,

SCHEMA_COLUMN=planta}]

P á g i n a | 129


Label format TABLE




Comment

Use an existing validation

rule false


Schema for D_Espacios_Fisicos :


id

false

String

50

false

identificador unico del espacio fisico. Llave compuesta por la concatenacion de (id_edificio)planta) (estancia)

nombre false String 300 true nombre del espacio fisico

estancia

false

String

50

true

espacio en el cual se ubica el espacio fisico dentro de la planta

sede

false

String

20

true

id de la sede en la cual se encuentra el espacio fisico

nombre_sede

false

String

200

true

nombre de la sede en la cual se encuentra el espacio fisico

codigo_edificio

false

String

50

true

id del edificio en el cual se encuentra el espacio fisico

edificio

false

String

200

true

nombre del edificio en el cual se encuentra el espacio fisico

codigo_tipo false String 50 true id del tipo de espacio fisico

tipo false String 150 true descripcion del tipo de espacio fisico

codigo_sub_tipo

false String 50 true id del subtipo de espacio fisico

sub_tipo false String 150 true descripcion del sub tipo de espacio fisico

P á g i n a | 130


uso_principal

false

String

150

true

uso principal al cual se destina el espacio fisico

activo

false

Boolean

1

true verdadero si esta activo falso si no esta activo (logico, no ;) )

area

false

String

20

true area en metros cuadrados del espacio fisico

planta

false

String

50

true planta (piso) en el cual se ubica el espacio fisico


Component tPostgresqlOutput

UNIQUE NAME

tPostgresqlO

utput_1

INPUT(S) tMap_1, tLDAPInput_1

LABEL TABLE OUTPUT(S) none


Properties Values

Unique Name tPostgresqlOutput_1

Component Name tPostgresqlOutput



Startable false

SUBTREE_START false

END_OF_FLOW true

Activate true

DUMMY false


Help org.talend.help.tPostgresqlOutput


IREPORT_PATH

JAVA_LIBRARY_PATH /home/daniel/Downloads/TOS_DI20160704_1411V6.2.1/configuration/lib/java Subjob color

Title color



Component List


Host "localhost"

Port "5432"



Schema "public"

Username "postgres"

Password *************

Table "h_historico_espacios_fisicos"

Action on table NONE

Action on data INSERT

REPOSITORY_ALLOW_AUTO_SWITCH

false

Schema repository: DB (POSTGRESQL):DataMart h_historico_espacios_fisicos Reject Schema BuiltIn

P á g i n a | 131


Use spatial options false

Create Spatial index false

Create geometry columns reference

false



Die on error true

Mapping postgres_id

Use save point false


Commit every 10000

Additional columns []

Use field options false

Field options

[{UPDATE_KEY=false, DELETE_KEY=false, UPDATABLE=true, INSERTABLE=true,

SCHEMA_COLUMN=id_espacio}, {UPDATE_KEY=false, DELETE_KEY=false, UPDATABLE=true, INSERTABLE=true, SCHEMA_COLUMN=id_unidad_organizacional},

{UPDATE_KEY=false, DELETE_KEY=false, UPDATABLE=true, INSERTABLE=true, SCHEMA_COLUMN=fecha_registro}, {UPDATE_KEY=false, DELETE_KEY=false, UPDATABLE=true, INSERTABLE=true, SCHEMA_COLUMN=ultima_modificacion}]

Enable debug mode false

Support null in "SQL WHERE" statement

false

Use Batch Size false

Batch Size 10000

Label format TABLE




Comment

Use an existing validation rule false Validation Rule Type

Schema for h_historico_espacios_fisicos :


id_espacio

false

String

10

true

id de espacio fisico. coincide con id de la tabla d_espacios_fisicos

id_unidad_organizacional

false

String

120

true

id de la unidad organizacional que coincide con el atributo <ou> del directorio del organigrama. (ldap logico)

fecha_registro false java.util.Date 13 true fecha en la cual se registra el hecho

ultima_modificacion

false

java.util.Date

13

true

fecha en la cual se hace la ultima modificacion del hecho

P á g i n a | 132


Original Function Parameters: Component tMap

UNIQUE NAME

tMap_1 INPUT(S) tMap_1, tLDAPInput_1

LABEL UNIQUE_N

AME

OUTPUT(S) tPostgresqlOutput_1


Mapper table Properties( row1 ):

Properties Values

Name row1


isMinimized false

isReject false


isInnerJoin false


Properties Values





Ignore trailing zeros for

BigDecimal

false


Comment

Use an existing validation rule False

P á g i n a | 133




id String false

nombre String true

estancia String true

sede String true

nombre_sede String true

codigo_edificio String true

edificio String true

codigo_tipo String true

tipo String true

codigo_sub_tipo String true

sub_tipo String true

uso_principal String true

activo Boolean true

area String true

planta String true

Mapper table Properties( row2 ):

Properties Values

Name row2

Matchingmode ALL_ROWS

isMinimized false

isReject false


isInnerJoin false




ou String true

description String true

Mapper table for tMap_1 ( output ): Mapper table Properties( registro_de_hechos ):

Metadata Table Entries( registro_de_hechos ):


id_espacio String row1.id false

id_unidad_organizacio

nal

String row2.ou false

fecha_registro java.util.Date true

ultima_modificacion java.util.Date true

anÁlisis, diseÑo y desarrollo de un almacÉn de datos...

Documents