universidad de guayaquil facultad de ingenieria...

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE INGENIERIA INDUSTRIAL DEPARTAMENTO ACADÉMICO DE GRADUACIÓN

TRABAJO DE TITULACIÓN PREVIO A LA OBTENCIÓN DEL TITULO DE

LICENCIADO EN SISTEMAS DE INFORMACIÓN

ÁREA SISTEMAS DE INFORMACIÓN

TEMA “REDISEÑO E IMPLEMENTACIÓN DE ETL OPEN

SOURCE PARA DATAMART DE CARTERA”

AUTORA PANCHANA JARAMILLO GLORIA STEFANIA

DIRECTOR DEL TRABAJO ING. ELECT. UGARTE FAJARDO JORGE G., MBA

2015

GUAYAQUIL – ECUADOR

i

DECLARACION DE AUTORIA

“La responsabilidad del contenido de este Trabajo de Titulación, me corresponde

exclusivamente; y el patrimonio intelectual del mismo a la Facultad de Ingeniería

Industrial de la Universidad de Guayaquil”

Gloria Stefania Panchana Jaramillo

c.c. 0930124110

ii

DEDICATORIA

A mis padres quienes me brindaron su apoyo constante e incondicional para el

cumplimiento de este logro personal y profesional.

A mi hermana por ser un pilar importante en mi vida y generar la confianza

necesaria en mis logros.

iii

AGRADECIMIENTO

A Dios por brindarme la luz necesaria para seguir el camino que me ha llevado a

la culminación de una etapa más en mi vida profesional.

A mis padres por ser fieles colaboradores de mis logros y metas, quienes dándome

fuerza día a día me han acompañado durante este arduo camino.

A mi compañera de carrera que junto a ella con mucho empeño hemos alcanzado

nuestro más ansiado objetivo.

iv

INDICE GENERAL

N° Descripción Pág.

PRÓLOGO 1

INTRODUCCIÓN


Tema 2

Alcance de la investigación 2

Objeto de la investigación 3

Objetivos 4

CAPÍTULO I

MARCO TEÓRICO


1.1 Antecedentes 6

1.2 Fundamentación Teórica 6

1.2.1 Inteligencia de Negocios (Business Intelligence “BI”) 7

1.3 Integración de Datos con Software de Código Libre 16

1.3.1 Talend Open Studio 17

1.4 Oracle Business Intelligence 11g 22

1.4.1 Características 22

1.5 Metodología de Kimball 23

CAPÍTULO II

METODOLOGÍA


2.1 Descripción de la Arquitectura 24

2.2 Análisis de los Repositorios Fuentes 26

2.3 Calidad de Datos 26

v


2.4 Frecuencia de Carga 26

2.5 Métricas del Cubo 27

2.6 Modelado Multidimensional 29

2.6.1 Dimensión Empresa 30

2.6.2 Dimensión Establecimiento 30

2.6.3 Dimensión Periodos 31

2.6.4 Dimensión Vendedor 31

2.6.5 Dimensión Zona 32

2.6.6 Dimensión Punto de Venta 32

2.6.7 Dimensión División 33

2.6.8 Dimensión Región 33

2.6.9 Dimensión Documento 34

2.6.10 Dimensión Forma de Pago 34

2.6.11 Dimensión Rango Días Vencidos 35

2.6.12 Dimensión Rango Días por Vencer 35

2.6.13 Dimensión Rango Plazos Crédito 36

2.6.14 Dimensión Rango Edad de Cartera 36

2.7 Esquema Multidimensional 37

2.8 Implementación de la Solución 38

2.8.1 Componente ETL – Talend Open Studio 38

2.8.2 Estructura General – OBIIE 53

2.9 Plan de Implementation 57

2.9.1 Riesgos en la Implementacion 57

2.10 Plan de Pruebas 58

2.11 Resultados 58

CAPÍTULO III

PROPUESTA


3.1 Titulo 59

3.2 Objetivos 59

vi


3.3 Elaboración 59

3.3.1 Descripción de la Propuesta 59

3.3.2 Estudio de Factibilidad 60

3.4 Impacto 63

3.4.1 Informe de Tiempos de Ejecución 65

3.5 Conclusiones 68

3.6 Recomendaciones 69

GLOSARIO DE TÉRMINOS 70

ANEXOS 74

BIBLIOGRAFÍA 157

vii

ÍNDICE DE TABLAS


1 Listado de Métricas 28

2 Dimensión Empresa 30

3 Dimensión Establecimiento 30

4 Dimensión Periodo 31

5 Dimensión Vendedor 31

6 Dimensión Zona 32

7 Dimensión Punto de Venta 32

8 DimensiónDivisión 33

9 DimensiónRegión 33

10 Dimensión Documento 34

11 Dimensión Forma de Pago 34

12 Dimensión Rango Días Vencidos 35

13 Dimensión Rango Días por Vencer 35

14 Dimensión Rango Plazos de Crédito 36

15 Dimensión Rango Edad Cartera 36

16 Factibilidad Técnica - Hardware 61

17 Factibilidad Financiera - Personal 61

18 Factibilidad Financiera - Hardware 62

19 Cuadro Comparativo de Tiempos de Consulta 64

20 Cuadro Comparativo de Tiempos de Ejecución 64

21 Tiempos de Ejecución – Tablas Dimensionales 65

22 Tiempos de Ejecución – Tablas Temporales 66

23 Tiempos de Ejecución – Tabla de Hecho “Fc_Cartera” 66

24 Tiempos de Ejecución Global – Proceso ETL 68

viii

ÍNDICE DE GRÁFICOS


1 Cuadrante de la Inteligencia de Negocios 8

2 Proceso ETL 11

3 Datamart OLAP 13

4 Datamart OLPT 14

5 Logotipo Talend 17

6 Arquitectura Big Data con Talend 18

7 Modo Gráfico de la Herramienta Talend 20

8 Visualización de un Job en Talend Open Studio 21

9 Arquitectura BI Oracle 22

10 Arquitectura del Cubo de Cartera 24

11 Esquema del Modelo de Cartera General 37

12 Esquema del Modelo de Cartera Vencida 37

13 Esquema del Modelo de Cartera por Vencer 38

14 Proceso ETL 39

15 Secuencia Dim_Empresa 40

16 Secuencia Dim_Establecimiento 40

17 Secuencia Dim_Periodos 41

18 Secuencia Dim_Vendedor 41

19 Secuencia Dim_Zona 42

20 Secuencia Dim_Punto_Venta 42

21 Secuencia Dim_Division 43

22 Secuencia Dim_Region 43

23 Secuencia Dim_Documento 44

24 Secuencia Dim_Forma_Pago 44

25 Secuencia Dim_Dias_Vencidos 45

26 Secuencia Dim_Rango_Dias_x_Vencer 45

27 Secuencia Dim_Rango_Plazo_Credito 46

ix


28 Secuencia Dim_Edad_Cartera 46

29 Secuencia Dimensiones 47

30 Tabla Temporal Tmp_Pdp 47

31 Tabla Temporal Tmp_Pdv 48

32 Tabla Temporal Tmp_Rot_Cart 48

33 Tabla Temporal Tmp_Vventas_Prom_Diario 49

34 Tabla Temporal Tmp_Vventas_Prom_Mensual 49

35 Tabla Temporal Tmp_Vent_Acum 50

36 Tabla Temporal Tmp_Rango_Edad_Cartera 50

37 Tabla Temporal Tmp_Rango_Vencidos 50

38 Tabla Temporal Tmp_Rango_x_Vencer 51

39 Tabla Temporal Tmp_Rango_Plazo_Credito 51

40 Secuencia Principal – Tablas Temporales 52

41 Tabla de Hecho Cartera 52

42 Crontab del Servidor 53

43 Ambiente OBIEE 53

44 Estructura del Datamart 54

45 Presentación en OBIEE 55

46 Graficas de Consultas al Cubo 55

47 Reporte Datamart 56

48 Grafica del Reporte 56

49 Arquitectura Propuesta 60

50 Secuencia Principal Cubo de Cartera 67

51 Log de ejecuciónCubo de Cartera 67

x

ÍNDICE DE ANEXOS


1 Presupuesto 75

2 Cronograma 76

3 Detalle de Métricas 77

4 Detalle de Dimensiones 78

5 Manual de Instalación ETL Talend Open Studio 79

6 Manual de Instalación Cliente OBIEE 11G 87

7 Manual de Usuario 95

8 Manual Tecnico 107

9 Cuadratura de Dimensiones 135

10 Cuadratura de Métricas 143

xi

AUTOR : GLORIA STEFANIA PANCHANA JARAMILLO

TITULO : REDISEÑO E IMPLEMENTACION DE ETL OPEN

SOURCE PARA DATAMART DE CARTERA

DIRECTOR : ING. UGARTE FAJARDOJORGEGUSTAVO, MBA

RESUMEN

El presente plan de titulación tiene como objetivo principal, proveer a la

compañía Ecuaquímica una solución tecnológica que procese de manera mensual

sus transacciones, su principal gestor de procesamiento es un ETL de código

abierto que genera información estructurada. La información podrá ser visualizada

en el datamart de cartera construido en la herramienta OBIEE 11g, disminuyendo

así los tiempos de análisis y mejora en áreas, como: ventas y cobranzas. Haciendo

uso de la observación científica y el método de Investigación Descriptivo se

realizó el análisis del enfoque actual del negocio, así como de las necesidades del

área contable para mejorar sus análisis crediticios dentro del mercado de clientes

actual. Los tiempos de respuesta alcanzados por la solución implementada abarcan

hasta un 98.33% de mejoría, comparativa realizada en base al proceso que la

compañía manejaba anteriormente. El diseño y presentación de informes para la

gestión de toma de decisiones se vuelve muy dinámico con las interfaces del

OBIEE lo cual genera un valor agregado al análisis que se quiera realizar y

presentar. Esta óptima fuente dará un soporte para la resolución de fallas en áreas

específicas.

PALABRAS CLAVES: Métrica, Toma, Decisiones, Datamart, BI,

Software, Libre, Talend, Open, Studio

Panchana Jaramillo Gloria Stefania Ing. Elect. Ugarte Fajardo Jorge G., MBA

C.C. 0930124110 Director del Trabajo

xii

AUTHOR : PANCHANA JARAMILLOGLORIA STEFANIA

SUBJECT : REDISIGN AND IMPLEMENTATION OF ETL OPEN

SOURCE FOR DATAMART

DIRECTOR : ELECT. ENG. UGARTE FAJARDO JORGE GUSTAVO,

MBA

ABSTRACT

The present plan has as a main objective to provide to Ecuaquímica

Company a technological solution that processes its transactions on a monthly

basis, its main processing promoter is an open source ETL that generates

structured information. The information will be visualized in the datamart

portfolio built in the tool OBIEE 11g, thus reducing the time of analysis and

improvement in areas such as: sales and collections. By making use of the

scientific observation and the descriptive research method, the analysis of the

current business focus was performed, as well as the accounting department needs

to improve its credit analysis within the market of current clients. The response

times achieved by the implemented solution include up to 98.33% improvement,

comparative based to the process that the company operated before. The design

and reporting for management decision-making becomes very dynamic with

OBIEE interfaces which generates an added value to the analysis that it wants to

perform and present. This optimal source will give a support for resolving failures

in specific areas.

KEY WORDS: Meter, Decisions, Datamart, BI, Open, Source, Software,

Talend, Open, Studio

Panchana Jaramillo Gloria Stefania Ing. Elect. Ugarte Fajardo Jorge G., MBA

C.C. 0930124110 Director of Work

v Marco Teórico

PRÓLOGO

Este trabajo de investigación presenta la propuesta de un rediseño e

implementación de un ETL Open Source para un Datamart de Cartera. A lo largo

de los capítulos se describen las tecnologías actuales que serán implementadas en

el proyecto; así como también los tiempos que se necesitarán para realizar el

trabajo y recopilación de información para los reportes que serán requeridos por el

usuario final.

Se presenta un marco teórico que abarca los conceptos básicos de las

herramientas y tecnologías que serán usadas; así como tambiéntodo lo que se

aplicará en el avance del proyecto, tanto los beneficios conseguidos al aplicar este

tipo de implementación de herramientas de tipo Open Source y la de crear un

Datamart con tecnología nueva que proveerá de mejores resultados para la toma

de decisiones en la compañía.

Se describe también la metodología que seráutilizada para el desarrollo de

la investigación y se sustentarán las herramientas de investigación;

ademássepresentará el diseño de los cuestionarios, el análisis de los reportes, las

métricas, los diagramas, las tablas e imágenes para demostrar la solución más

viable.

Por último, se presenta el capítulo de la propuesta en el cual se detalla la

arquitectura final de este proyecto, la factibilidad económica y tecnológica.

Además abarca las conclusiones y recomendaciones,las cuales se detallarán

acorde a las situaciones que se presenten en el desarrollo de este proyecto.

vi Marco Teórico

INTRODUCCIÓN

El proyecto presentado a continuación tiene como finalidad utilizar una

herramienta ETL de código abierto (Open Source) para la creación de un

Datamart de Cartera.

Este trabajo es producto de una previa investigación sobre las necesidades

que presenta actualmente la compañía ECUAQUIMICA.

ECUAQUIMICA, cuenta actualmente con un Datamart de cartera en

ambiente Oracle Discoverer; debido a que esta tecnología no cuenta con soporte y

presenta tiempos elevados para procesar la información en cubos, se requiere

migrar dichos procesos a una nueva tecnología, realizando un proceso de

reingeniería para cumplir con las necesidades actuales del usuario final.

Dado que ECUAQUIMICA adquirió una nueva versión de Oracle (Oracle

Business Intelligence 11 G), el cual se especializa en el manejo de datamarts con

muchas ventajas para el usuario final, la empresa decidió realizar un proceso de

reingeniería al Datamart de Cartera utilizando esta herramienta, la misma que

ofrece al operador una interfaz amigable capaz de proveer seguridad en su uso.

Tema

Rediseño e Implementación de ETL Open Source para Datamart de Cartera.

Alcance de la investigación

El alcance de la propuesta es una reingeniería del Datamart de cartera que

actualmente se encuentra en la herramienta Discoverer de Oracle, además de

contar con un cubo y los reportes del mismo en la nueva adquisición, un Oracle

Business Intelligence 11G.

Introducción 3

Objeto de la investigación

Diseñar e Implementar un Sistema de Información Gerencial para el cubo

de Cartera utilizando herramientas BI.

Justificación

Justificación Práctica

Se justifica realizar la implementación en Ecuaquímica, debido a que las

métricas no cumplen con la estrategia actual del negocio y mejorar la eficiencia en

tiempos tanto de procesamiento como de reportes que puedan servir al

crecimiento de la misma.

Podemos considerar el hecho de enriquecer el proceso con el uso de la

herramienta ETL, que facilitará la extracción y preparación del ambiente donde se

realizará la creación de este Datamart.

La herramienta Open Source se encuentra presente en la actualidad

grandes compañías a nivel mundial donde ha demostrado una enorme capacidad

en relación con ETLs de licencia, motivo por el cual se lo escogió para integrar

datos.

Se planea que la empresa genere sus proyecciones y planeaciones en base

a sus procesos mejorados y pueda afianzar lazos en el mercado, demostrando su

alta capacidad de servicio.

Justificación Teórica

El proceso actual de cartera que Ecuaquímica ha usado durante varios años

demanda de elevados tiempos tanto en procesamiento como en reportes. Es así

que estos procesos le toman a la compañía un día en procesar información y 3

horas para visualizar un reporte.

Introducción 4

La investigación podrá determinar las acciones de mejora que deberá

tomar la compañía en los procesos administrativos y de crédito, los cuales son

fuente esencial de una cartera.

Poder utilizar una herramienta ETL con un alto poder para trabajar en

múltiples plataformas con bajo recursos financieros, hace gratificante a la

compañía su aprendizaje y empoderamiento del mismo.

Con la implementación de este proyecto se espera describir y conocer a

través de los procesos, los actores principales de cambio para cada caso en donde

se genere información o se la actualice, lo que facilitará de gran manera la entrega

de una solución práctica y apropiada a sus necesidades.

Se marcará de esta forma el comienzo de la mejora en los procesos

intervinientes en la cartera.

La indagación se realizará tomando en cuenta el método de investigación

conocido como: científico racional, método que se basa en una serie ordenada de

procedimientos que hace uso la investigación exploratoria por que se funda en la

razón de la observación lo cual significa que parte de conceptos, razonamientos y

no de apariencias y supuestos.

El impacto en el ambiente tecnológico será notable con el uso de una

herramienta de fácil acceso como es un aplicativo de código abierto, en este caso

la herramienta conocida como Talend Open Studio.

OBJETIVOS

Objetivo General

Realizar la reingeniería del cubo de cartera de la Empresa

ECUAQUIMICA, usando las herramientas: Oracle Bussiness Intelligence 11G y

Talend Open Studio.

Introducción 5

Objetivos Específicos

Los objetivos específicos que se pretenden conseguir en el funcionamiento

del Sistema de Información Gerencial son los siguientes:

Corregir el funcionamiento del Sistema de Información Gerencial actual.

Analizar la infraestructura tecnológica actual utilizada en el cubo de

cartera de ECUAQUIMICA y los resultados generados.

Realizar reingeniería del cubo de cartera.

Implementar procesos de extracción, transformación y carga de los datos

usando Talend Open Studio.

Construir un cubo de cartera que permita el acceso veraz y eficaz a la

información sobre las divisiones del negocio. Mejorando con esto el

tiempo de respuesta de los reportes gerenciales.

Marco Teórico 7

CAPITULO I

MARCO TEÓRICO

1.1 Antecedentes

En la actualidad existen diversos Sistemas de Información Gerencial que

implementan en sus desarrollos herramientas que facilitan la creación y

manipulación de reportes gerenciales que puedan mejorar la toma de decisiones y

ayuden al enfoque de cambios oportunos o puntuales para el crecimiento de las

empresas en base a sus propios movimientos diarios. En el país hay empresas que

se dedican a realizar proyectos BI, los cuales tratan la información con

herramientas especializadas las cuales manipulan grandes cantidades de data, que

por sí solas las herramientas Open Source disponibles no llenarían la expectativa

de los clientes.

La compañía ECUAQUIMICA cuenta con un Datamart de cartera en

Oracle Discoverer, este cubo actualmente no cumple con las expectativas y

necesidades de la empresa. La organización ha renovado procesos principales y

funcionalidades para cubrir el mercado actual.

1.2 Fundamentación Teórica

La información que proveerá el Datamart será base fundamental para

efectuar mejoras en las áreas de marketing, contabilidad, ventas y logística; ya que

son los procesos principales que generan la información que se podrá analizar con

la ayuda del cubo.

El conocimiento que brindará el Sistema de Información Gerencial

repercutirá en campañas de marketing para ganar mercado a nivel nacional, cubrir

zonas que despunten en ventas y que actualmente no hayan puntos de venta

Marco Teórico 8

disponibles, ampliar rangos de crédito para líneas de negocio puntuales por el tipo

de cosecha o castigar cartera conociendo las debilidades de la cobranza efectuada

en la organización.

Conocer la amplitud actual del negocio y la manera en que se brinda

servicio al cliente efectuando cambios en la logística y abastecimiento de los

puntos de venta para que la organización sea la primera opción del mercado

nacional.

1.2.1 Inteligencia de Negocios (Business Intelligence “BI”)

La inteligencia de negocios comprende la facultad que tiene una compañía

para realizar un estudio de su comportamiento y acciones en una línea histórica,

donde el objetivo principal será entender donde la organización ha estado, su

situación actual y realizar una proyección hacia el futuro.

Todo esto en base a la recolección, consolidación y análisis de múltiples

fuentes de información para toma de decisiones estratégicas.

Todo esto se basa en una acción primordial el “Análisis”.

1.2.1.1 Beneficios de una Implementación BI

Los beneficios que otorgará el rediseño e implementación de este sistema

BI son: incremento en la eficiencia de la toma de decisiones, mejor visión del

mercado actual para incrementos o decrementos de créditos definidos por líneas

de negocios específicas, identificación de riesgos, presentación de soluciones en

base al conocimiento del negocio, etc.

La mayoría de beneficios acorde a la implementación del cubo son

intangibles porque se derivan de la mejora en la gestión de la organización. Esto

dificulta la tarea de calcular el ROI (ReturnOnInvestment) para la obtención de

beneficios cuantificables.

Marco Teórico 9

No obstante, gracias a la implementación podemos observar una reducción

de costos al aumentar el rendimiento de la infraestructura tecnológica de la

empresa y un incremento de la productividad de las áreas implicadas, debido a la

rapidez en la obtención de la información y la calidad de la misma. Pero como se

describió anteriormente cuantificar desde una perspectiva económica-financiera

con este tipo de parámetros se vuelve una tarea difícil de realizar.

1.2.1.2 Cuadrante de la Inteligencia de Negocios

Este cuadrante es una herramienta promovida por la empresa Gartner, la

cual muestra la gráfica del mercado tecnológico en un periodo de tiempo, donde

permite visualizar, identificar y diferenciar los proveedores de tecnologías de

información que se rigen como líderes al respecto de otros.

FIGURA N° 1

CUADRANTE DE LA INTELIGENCIA DE NEGOCIOS

Fuente: Gartner (Febrero 2015)

Elaborado por: Gartner

1.2.1.3 Arquitectura y componentes BI

a. Sistemas Operacionales

Son los sistemas que capturan las transacciones que genera de

forma diaria la organización.

Pueden ser diversos y pueden a la vez utilizar diferentes motores de

bases de datos y/o archivos planos.

Marco Teórico 9

b. ETLExtract, Transformer& Load (Extracción, Transformación y Carga)

La data se extrae de uno o varios repositorios fuentes sean estos

archivos planos o bases de datos, esta data sufrirá transformaciones

dependiendo de la necesidad y para lo que vaya a ser utilizada, para

luego ser información valiosa para la organización la cual se

cargara en el repositorio destino.

Cuando la información está en el proceso de transformación se

ejecuta en el área conocida como Staging la que se encarga de

evitar que el proceso de limpieza se realice en el momento en que

los datos sean cargados.

c. Data Warehouse

Es una base de datos corporativa que se caracteriza por integrar y depurar

información de una o más fuentes distintas, para luego procesarla

permitiendo su análisis desde infinidad de perspectivas y con grandes

velocidades de respuesta

La información se califica en base a las necesidades de la

compañía.

La información se encuentra integrada, lo que permite que los

datos se puedan visualizar de diversas maneras.

d. Datamart

Es una base de datos departamental, especializada en el almacenamiento

de los datos de un área de negocio específica.

Hay dos tipos de Datamarts:

Dependientes: obtienen sus datos por medio de un Data

Warehouse

Independientes: obtienen sus datos de fuentes separadas.

Marco Teórico 10

e. Cubos

Son estructuras dimensionales que contienen datos pre-calculados

definidos por la organización acorde a sus necesidades.

f. Metadata

Son datos que describen otros datos.

Técnico: describe estructuras físicas y el proceso que

transforma y mueve los datos en el ambiente.

Negocio: describe la estructura de datos y las reglas que

tenga el negocio disponible.

g. Reportes

Son los recursos finales y tangibles que poseerán los usuarios

encargados en la organización de la toma de decisiones, es la

recopilación de datos de las tablas o consultas que permiten

generar archivos de impresión primordialmente para el análisis,

facilitando la visualización de datos representativos para la

organización que los use.

1.2.1.4 Proceso ETL

Este término viene de inglés de las siglas Extract-Transform-Load que

significan Extraer, Transformar y Cargar y se refiere a los datos en una empresa.

ETL es el proceso que organiza el flujo de los datos entre diferentes sistemas en

una organización y aporta los métodos y herramientas necesarias para mover datos

desde múltiples fuentes a un almacén de datos, reformatearlos, limpiarlos y

cargarlos en otra base de datos, Datamart ó bodega de datos. ETL forma parte de

la Inteligencia Empresarial (Business Intelligence), también llamado “Gestión de

los Datos” (Data Management).

Marco Teórico 11

La idea es que una aplicación ETL lea los datos primarios de unas bases de

datos de sistemas principales, realice transformación, validación, el proceso

cualitativo, filtración y al final escriba datos en el almacén y en este momento los

datos son disponibles para analizar por los usuarios. (ETL-TOOLS.INF)

FIGURA N° 2

PROCESO ETL

Fuente: DataPrix (www.dataprix.com)

Elaborado por: DataPrix

1.2.1.5 Datawarehouse

Es una base de datos corporativa que se caracteriza por integrar y depurar

información de una o más fuentes distintas, para luego procesarla permitiendo su

análisis desde infinidad de perspectivas y con grandes velocidades de respuesta.

La creación de un datawarehouse representa en la mayoría de las ocasiones el

primer paso, desde el punto de vista técnico, para implantar una solución completa

y fiable de Business Intelligence.

La ventaja principal de este tipo de bases de datos radica en las estructuras

en las que se almacena la información (modelos de tablas en estrella, en copo de

nieve, cubos relacionales... etc.). Este tipo de persistencia de la información es

homogénea y fiable, y permite la consulta y el tratamiento jerarquizado de la

misma (siempre en un entorno diferente a los sistemas operacionales).

Marco Teórico 12

El término Datawarehouse fue acuñado por primera vez por Bill Inmon, y

se traduce literalmente como almacén de datos.

No obstante, y como cabe suponer, es mucho más que eso.

Según definió el propio Bill Inmon, un datawarehouse se caracteriza por ser:

Integrado

Temático

Histórico

No volátil

Para comprender íntegramente el concepto de datawarehouse, es

importante entender cuál es el proceso de construcción del mismo, denominado

ETL (Extracción, Transformación y Carga), a partir de los sistemas operaciones

de una compañía:

a. Extracción: obtención de información de las distintas fuentes tanto internas

como externas.

b. Transformación: filtrado, limpieza, depuración, homogeneización y

agrupación de la información.

c. Carga: organización y actualización de los datos y los metadatos en la base

de datos.(SINNEXUS)

1.2.1.6 Datamart

Datamart es una base de datos departamental, especializada en el

almacenamiento de los datos de un área de negocio específica. Se caracteriza por

disponer la estructura óptima de datos para analizar la información al detalle

desde todas las perspectivas que afecten a los procesos de dicho departamento.

Un datamart puede ser alimentado desde los datos de un datawarehouse, o

integrar por sí mismo un compendio de distintas fuentes de información.

Marco Teórico 13

1.2.1.7 Tipos de Datamart

Datamart OLAP (Procesamiento Analítico en Línea - On-Line

AnalyticalProcessing)

Se basan en los populares cubos OLAP, que se construyen agregando,

según los requisitos de cada área o departamento, las dimensiones y los

indicadores necesarios de cada cubo relacional. El modo de creación, explotación

y mantenimiento de los cubos OLAP es muy heterogéneo, en función de la

herramienta final que se utilice.

FIGURA N° 3

DATAMART OLAP

Fuente: DataPrix (www.dataprix.com)

Elaborado por: DataPrix

Datamart OLTP (Procesamiento de Transacciones En Línea -

OnLineTransactionProcessing)

Pueden basarse en un simple extracto del datawarehouse, no obstante, lo

común es introducir mejoras en su rendimiento (las agregaciones y los filtrados

suelen ser las operaciones más usuales) aprovechando las características

particulares de cada área de la empresa. Las estructuras más comunes en este

sentido son las tablas report, que vienen a ser fact-tables reducidas (que agregan

las dimensiones oportunas), y las vistas materializadas, que se construyen con la

Marco Teórico 14

misma estructura que las anteriores, pero con el objetivo de explotar la reescritura

de queries (aunque sólo es posible en algunos SGBD avanzados, como Oracle).

(SINNEXUS)

El proceso de transacciones en línea de hoy en día requiere cada vez más

el apoyo para transacciones que abarcan una red y pueden incluir más de una

compañía. Por esta razón, el nuevo software de OTLP usa un procesamiento

cliente/servidor y un software intermediario que permite que las transacciones se

den en diferentes plataformas computacionales en una red.(Rouse, 2012)

FIGURA N° 4

DATAMART OLTP

Fuente: Wikipedia

Elaborado por: Anónimo

1.2.1.8 Cubos de Información

Los cubos son elementos claves en OLAP (online analyticprocessing), una

tecnología que provee rápido acceso a datos en un almacén de datos (data

warehouse).

Los cubos proveen un mecanismo para buscar datos con rapidez y tiempo

de respuesta uniforme independientemente de la cantidad de datos en el cubo o la

complejidad del procedimiento de búsqueda.

Marco Teórico 15

Los cubos son subconjuntos de datos de un almacén de datos, organizado y

sumarizado dentro de una estructura multidimensional. Los datos se sumarizan de

acuerdo a factores de negocio seleccionados, proveyendo el mecanismo para la

rápida y uniforme tiempo de respuesta de las complejas consultas.

La definición del cubo, es el primero de tres pasos en la creación de un

cubo. Los otros pasos son, el especificar la estrategia de sumarización diseñando

las agregaciones (elementos pre calculados de datos), y la carga del cubo para

procesarlo. Para definir un cubo, seleccione una tabla objetivo y seleccione las

medidas (columnas numéricas de interés a los usuarios del cubo) dentro de esta

tabla. Entonces seleccione las dimensiones, cada compuesta de una o más

columnas de otra tabla. Las dimensiones proveen la descripción categórica por el

cual las medidas son separadas para su análisis por los usuarios del cubo.

1.2.1.9 Dimensiones

Son categorías descriptivas por los cuales los datos numéricos (Las

Mediciones) en un cubo, son separados para su análisis. Por ejemplo, si una

medición de un cubo es el conteo de la producción, y las dimensiones son

Tiempo, localización de la fábrica y el producto, los usuarios del cubo, podrán

separar el conteo de la producción, dentro de varias categorías de tiempo,

localización de la fábrica y productos. Una dimensión puede ser creada para

usarse en un cubo individual o en múltiples cubos. Una dimensión creada para un

cubo individual, es llamada dimensión privada.

Por el contrario si esta puede ser usada por múltiples cubos, se le llama

dimensión compartida. Estas podrán ser usadas dentro de todo cubo, en la base de

datos, así se optimiza el tiempo y se evita el andar duplicando dimensiones

privadas.

Las dimensiones compartidas, también habilitan la estandarización de las

métricas de negocios entre cubos. Por ejemplo, el estandarizar las dimensiones

compartidas para el tiempo y localización geográfica, aseguran que los datos

analizados, desde diferentes cubos, estén organizados similarmente.

Marco Teórico 16

1.2.1.10 Medidas

Son datos numéricos de interés primario para los usuarios del cubo.

Algunas medidas comunes son Ventas en unidades, ventas en pesos, costo de

ventas, gastos, conteo de la producción, presupuesto, etc.

Estas son usadas por el procedimiento de agregación de los servicios de

OLAP y almacenadas para su rápida respuesta a las peticiones de los usuarios.

Se puede crear una medida calculada y calcular miembros de dimensiones,

combinando expresiones multidimensionales (MDX), fórmulas matemáticas y

funciones definidas por el usuario (UDFs. (GESTIOPOLIS)

1.3 Integración de Datos con Software de Código Libre

La integración de datos se compone de los procesos a través de los cuales

la información de diferentes módulos de los sistemas de información es

transportada, combinada y consolidada.

Estos procesos usualmente consisten en:

Extraer datos de diferentes fuentes (bases de datos, archivos, aplicaciones,

servicios web, correo electrónico, etc.)

Aplicar transformaciones (uniones, búsquedas, comparaciones, cálculos,

etc.)

Enviar los datos transformados a los sistemas destinos (Data Warehouse,

aplicaciones BI, etc.)

1.3.1 Talend Open Studio

Es una herramienta open-source (licencia GPL) que permite de forma

visual modelar transformaciones de datos generando código Java.

Marco Teórico 17

FIGURA N° 5

LOGOTIPO TALEND

Fuente: Talend (www.talend.com)

Elaborado por: Talend

Los usos de Talend Open Studio incluyen:

ETL

Sincronización o replicación de bases de datos

Migración

Transformación de datos

Ofrece un diseñador visual (basado en Eclipse RCP) que permite definir

todo el flujo de transformaciones en base a componentes predefinidos (más de

400, también se pueden crear y ampliar).

Este diseñador proporciona una vista gráfica de los procesos, con

componentes arrastrables que permiten: mappings, transformaciones, etc;

funciones especializadas como data filtering, data multiplexing, o ELT; y soporte

para RDBMS, file formats, LDAP directories, etc.

Otro punto en el que destaca Talend Open Studio es en las capacidades de

depuración, que permite seguir en tiempo real los datos que fluyen a través de los

procesos de transformación. (Gracia, 2010)

Marco Teórico 18

FIGURA N° 6

ARQUITECTURA BIG DATA CON TALEND

Fuente: Talend (www.talend.com)

Elaborado por: Talend

1.3.1.1 Razones para su Uso

1.- Talend Open Studio es un producto completo que incluye muchas

funcionalidades y un amplio conjunto de conectores. El producto estrella de

Talend, es la solución de integración, disponible hoy en día, más abierta,

innovadora y poderosa. Talend Open Studio no es un producto de prueba o de

funcionalidad limitada, contiene todas las funcionalidades requeridas para

construir procesos poderosos de integración de datos y se puede descargar de

manera gratuita bajo una licencia de uso GPL v2.

2.- Implementar Talend Open Studio es fácil y rápido.

3.- Las herramientas de Talend son amigables y fáciles de manejar. La

interface gráfica de usuario es intuitiva no requiere entrenamiento formal.

Marco Teórico 19

4.- Con Talend, el costo de la solución está basada en el número de

desarrolladores de los procesos de integración de datos.

5.- La comunidad en línea de Talend ofrece muchos recursos que facilitan la

implementación y mantenimiento de las soluciones de Talend.

6.- Con más de 400 conectores, las soluciones de Talend virtualmente ofrecen

conectividad ilimitada a sistemas empresariales, bases de datos, paquetes de

software, mainframes, archivos, servicios web, etc.

7.- Las soluciones de integración de datos de Talend no se encuentran

limitadas para la funcionalidad (Extraer-Transformar-Cargar) para Inteligencia

de Negocio, sino que pueden utilizarse para proyectos de integración de datos

operacionales; típicamente estos son realizados manualmente, pero pueden

beneficiarse por un ambiente de integración de datos.

Los proyectos de integración de datos son muy variados. Con las soluciones

de Talend se pueden reutilizar desarrollos existentes en nuevos proyectos

ganando en productividad y tiempo.

8.- Lejos de los estereotipos de falta de profesionalismo que ronda al alrededor

del código libre, las soluciones de Talend son verdaderas herramientas de

trabajo, que ofrecen un nivel de funcionalidad igual al de las herramientas

propietarias.

9.- Las soluciones de Talend son entre 50% y 80% más baratas que las

herramientas propietarias equivalentes que se ofrecen en el mercado. Además,

son más baratas de implementar, mantener y dar soporte.

Adicional a esto permiten un desarrollo y puesta en marcha más rápido

comparada con las soluciones propietarias y la codificación ad-hoc. (Howard,

2009)

Marco Teórico 20

1.3.1.2 Niveles de Talend

Talend basa su diseño en 3 niveles:

Business Models (Modelos de Negocios): es nivel diseñado para modelar

de manera teórica la aplicación, para lo cual se realizan diagramas de flujo

básicos con actores de los procesos.

Job Designs (Diseño de Trabajos): el nivel más interesante, en el cual se

diseña el trabajo en sí, el código que será ejecutado.

Contexts (Contextos): Es el nivel que contiene los contextos, los cuales

pueden ser definidos como variables globales de ejecución del programa,

como la carpeta donde se ejecutará la aplicación final o variables iniciales

de entrada.

FIGURA N° 7

MODO GRÁFICO DE LA HERRAMIENTA TALEND

Fuente: JasperSoft (www.jaspersoft.com)

Elaborado por: JasperETL

1.3.1.3 Jobs Design

Es el nivel empleado con mayor frecuencia en Talend Open Studio.

Formado por el conjunto de Jobs, o tareas a realizar. Cada Job inicialmente de una

Marco Teórico 21

grilla (grid) en blanco, donde se arrastran elementos de una paleta ubicada en la

parte derecha del diseñador.

En dicha paleta se encuentran varios elementos configurables, llamados

Subjobs, los cuales se encargan de ejecutar tareas predeterminadas pero

configurables como conexiones, consultas, código personalizado, etc.Algunos

Subjobs que pueden resultar interesantes son:

Conexiones estandarizadas y personalizables a bases de datos, incluye

soporte a gran cantidad de las bases de datos Open Source (MySQL,

PostgreSQL, SLQLite) e incluso Sybase y Oracle.

Ejecutores de consultas y procedimientos almacenados en las mencionadas

bases de datos.

Iteradores, repetidores de subtareas.

Conexión a FTP para envío y descarga de archivos.

Filtros de información.(Marco, 2011)

FIGURA N° 8

VISUALIZACIÓN DE UN JOB EN TALEND OPEN STUDIO

Fuente: JasperSoft (www.jaspersoft.com)

Elaborado por: JasperETL

http://www.jaspersoft.com/

Marco Teórico 22

1.4 Oracle Business Intelligence 11g

FIGURA N° 9

ARQUITECTURA BI ORACLE

Fuente: Oracle (www.oracle.com)

Elaborado por: Oracle

1.4.1 Características

Integración y análisis de datos provenientes de múltiples fuentes: potente

servidor de análisis y consulta que permite integrar múltiples y diversas

fuentes de datos y visualizarlas en una pantalla simplificada de

información corporativa.

Herramienta de generación de informes fácil de utilizar basada en la web:

puede crear y publicar documentos corporativos formateados, informes

operativos, así como permitir el análisis ad hoc de datos del negocio.

Además, se integran herramientas como MS Word y Adobe Acrobat en la

redacción de informes.

Interfaz única basada en la web para el rendimiento de la empresa y los

negocios: creación de paneles interactivos y personalizados con

parámetros corporativos y KPI para los usuarios de negocios.

Marco Teórico 23

Herramienta ETL para configurar y mantener un almacén de datos eficaz y

de alta calidad.

1.5 Metodología de Kimball

La metodología se basa en lo que Kimball denomina Ciclo de Vida

Dimensional del Negocio (Business Dimensional Lifecycle) (Kimball et al 98, 08,

Mundy & Thornthwaite 06).

Este ciclo de vida del proyecto de DW, está basado en cuatro principios básicos:

Centrarse en el negocio: Hay que concentrarse en la identificación de los

requerimientos del negocio y su valor asociado, y usar estos esfuerzos para

desarrollar relaciones sólidas con el negocio, agudizando el análisis del

mismo y la competencia consultiva de los implementadores.

Construir una infraestructura de información adecuada: Diseñar una base

de información única, integrada, fácil de usar, de alto rendimiento donde

se reflejará la amplia gama de requerimientos de negocio identificados en

la empresa.

Realizar entregas en incrementos significativos: crear el almacén de datos

(DW) en incrementos entregables en plazos de 6 a 12 meses. Hay que usa

el valor de negocio de cada elemento identificado para determinar el orden

de aplicación de los incrementos. En esto la metodología se parece a las

metodologías ágiles de construcción de software.

Ofrecer la solución completa: proporcionar todos los elementos necesarios

para entregar valor a los usuarios de negocios. Para comenzar, esto

significa tener un almacén de datos sólido, bien diseñado, con calidad

probada, y accesible.También se deberá entregar herramientas de consulta

ad hoc, aplicaciones para informes y análisis avanzado, capacitación,

soporte, sitio web y documentación.

Metodología 24

CAPITULO II

2 METODOLOGÍA

2.1 Descripción de la arquitectura

Para tener una visión amplia y general del sistema tomando en cuenta la

plataforma elegida para la implementación de la solución Talend Open Studio, a

continuación se explica la arquitectura común utilizada en los Datamart,

detallando cada uno de los procesos que conforman el proyecto de tesis.

Comprende básicamente de 5 procesos en los cuales se encuentra

estructurado el proyecto de tesis:

Fuente u origen de datos.

Extracción, transformación y carga

Cubo de información

Presentación (Reportes e Indicadores)

Administración

FIGURA N° 10

ARQUITECTURA DEL CUBO DE CARTERA

Fuente: Investigación directa

Elaborado por: Panchana Jaramillo Gloria Stefania

Oracle Business Intelligence 11G

Metodología 25

El primer proceso que se detalla en este proyecto corresponde a la fuente

de información, las bases de datos Oracle 11g, repositorios que utilizan en la

actualidad los sistemas de información de la organización para almacenar los

datos referentes a sus transacciones diarias.

El proceso ETL comprende de una serie de subprocesos tales como la

extracción, manipulación, transformación, control, integración, limpieza de datos,

carga y actualización del Datamart, se ejecutarán todos estos pasos necesarios

para compilar la información necesaria para el cubo que dispondrá la

organización.

El modelo OLAP que se utiliza es el nervio central del sistema. En el

Datamart se almacenan los datos operacionales en las estructuras dimensionales

que son el punto clave para el acceso a las consultas siendo estas flexibles y las

cuales contendrán la metadata de toda la información almacenada pues ofrece la

información descriptiva de los índices de la tabla de hecho final.

En el proceso de la presentación de los resultados se encuentra la

interacción con el usuario final donde éste recibe los datos almacenados en forma

de reportería útil creada en el OBI (Oracle Business Intelligence).

Esta herramienta se comunica directamente con el servidor mediante las

consultas realizadas, las cuales retornan información transformada y presentada

para la visualización final a nivel de la gerencia.

Todo reporte que se base en el análisis de la cartera se centra en este

proceso.

Por último para el proceso de la administración encontramos las

herramientas administrativas de la plataforma. Gestión de usuarios, conexiones de

repositorios fuentes, para cada herramienta usada tanto OBI como Talend está

disponible para la administración.

Metodología 26

2.2 Análisis de los Repositorios Fuentes

Los datos que fueron usados para la alimentación del Datamart

corresponden a datos del Sistema de la organización actual (SWISS). Tal sistema

contiene información relacionada con todas las transacciones y operaciones de la

empresa.

El uso de reportes para la toma de decisiones está basado prácticamente en

reportes que se pueden generar con el SWISS, aun así estos no abarcan toda la

información requerida en reuniones de la alta gerencia; por lo cual el Jefe de

Cartera toma estos reportes y los manipula creando reportes finales a su medida

para las reuniones gerenciales.

2.3 Calidad de los Datos

Al realizar el análisis de los datos, tablas y entidades relación se entrevistó

al Jefe del Área TI, el cual dispuso el conocimiento necesario para el uso de la

data que se utilizará ya que la base actual nace de una migración y reconstrucción

de base – tablas que se encuentra en un data aún sin depurar o a su vez hay data

importante en campos indiferentes a su importancia.

Fue necesario conocer cada uno de estos casos porque afectaban

directamente a la información que se visualizará en la reportería y que estará

contemplada en el Datamart de Cartera.

2.4 Frecuencia de Carga

De acuerdo al análisis realizado y las reuniones con el personal a cargo del

proyecto, la gerencia de la organización tomo la decisión de que la frecuencia de

carga del proceso ETL se realizará de forma mensual.

Los procesos que se ejecutan son:

Metodología 27

Extracción de tablas del repositorio fuente.

Creación de las dimensiones.

Creación de la tabla de hecho mapeo con dimensiones.

Creación de las métricas.

Estos procesos se ejecutan bajo el sistema operativo con la ayuda del

archivo crontab del S.O.

El archivo crontab es el programador de tareas en el servidor, aquí se

detallan los procesos que deseamos ejecutar definiendo el día y la hora del evento.

2.5 Métricas del Cubo

Las métricas consideradas para el cubo para proveer información acorde a

las necesidades de la organización son planteadas a continuación:

Métricas:

Días de Venta en Cartera - Rotación

Promedio de Venta Diario

Tiempo Promedio de Días de Cobros

Tiempo Promedio de Días Vencidos

Valor Cartera Real

# de Cobros del Periodo

# de cheques protestados asociados

Valor de los cheques protestados

Efectividad monto

Porcentaje de Cartera Morosa

Porcentaje de Cartera Vencida

Porcentaje de Cartera Cobrada

Porcentaje de Cartera Diferida

Metodología 28

TABLA N° 1

LISTADO DE MÉTRICAS

NOMBRE MÉTRICA DEFINICIÓN

Días de venta en cartera -

rotación

Cuantos días de labor de venta se requiere para la

cartera actual. Su cálculo es Total de Cartera /

Promedio de Ventas Diaria.

Promedio de venta diario Se calcula de la siguiente manera: las ventas

acumuladas de los últimos 5 años por

cliente/(3600*5 )

Ponderado días de pagos (Sumatoria de ( valor del pago * días desde la

fecha de emisión a la fecha de pago ) de cada

recibo )/ (Sumatoriadel valor de las deudas)

No se consideran cheques posfechados. No se

consideran Notas de crédito ponderado días vencidos (Sumatoria de ( valor del pago * días desde la

fecha de emisión a la fecha de vencimiento ) de

cada recibo )/ (Sumatoria del valor de las deudas)

No se consideran cheques posfechados. No se

consideran Notas de crédito Cantidad de cheques protestados Cantidad de cheques protestados

Valor de los cheques protestados Sumatoria de valor de cheques protestados

Porcentaje de cartera vencida Cartera vencida/cartera real

Porcentaje de cartera por vencer Cartera por vencer / cartera real

Porcentaje de cartera normal Cartera normal / cartera real

Porcentaje de cartera dudosa Cartera dudosa / cartera real

Porcentaje de cartera eliminada Cartera eliminada / cartera real

Valor cartera real Sumatoria de toda la cartera

Valor de cartera vencida Sumatoria de la cartera con estatus vencida

Valor de cartera por vencer Sumatoria de la cartera con estatus por vencer

Valor de cartera normal Sumatoria de la cartera con estatus normal

Valor de cartera dudosa Sumatoria de la cartera con estatus dudosa

Valor de cartera eliminada Sumatoria de la cartera eliminada

Cantidad de cobros Cantidad de cobros

Cobro acumulado Sumatoria de cobros acumulados por mes Factor ponderado cobro Sumatorio de días de cobro Días de cobro:

Fecha de pago – Fecha de emisión

Venta mensual promedio Se calcula de la siguiente manera:

Sumatoria de Venta Bruta – Sumatoria de Notas de

Crédito

Se considera ventas brutas a las ventas antes de

impuesto

No se considera si la nota de crédito esta cruzada o

no con la venta.



Metodología 29

2.6 Modelado Multidimensional

En esta sección se mencionan los modelos que se utilizarán en la creación

del nuevo cubo de cartera así como las dimensiones que estos modelos incluirán

en sus estructuras.

Las métricas que se manejarán para el análisis de la información también

serán descritas ya que forman parte de la solución, fueron básicamente

provenientes del cubo anterior pero se generará información con un diferente

parámetro de tiempo o más de haberse implementado métricas nuevas durante la

fase del análisis.

Las dimensiones que se derivan para la construcción del cubo son las que

se describen a continuación:

Empresa

Establecimiento

Periodos

Vendedor

Zona

Punto de Venta

División

Región

Documento

Rango Días Vencidos

Rango Días por Vencer

Rango Edad de la Cartera

Plazo Crédito

Forma de Pago

Cada dimensión tiene a su vez diferentes formas de organizarse, estas

jerarquías definen que tipo de información se podrá utilizar.

Metodología 30

2.6.1 Dimensión Empresa

Contiene la jerarquía de las empresas que se consolidan en

ECUAQUIMICA

TABLA N° 2

DIMENSIÓN EMPRESA

Empresa

Código

Nombre

Ruc

001

ECUAQUIMICA

0990018707001



2.6.2 Dimensión Establecimiento

Contiene la información de los clientes que conforman la cartera de

ECUAQUIMICA

TABLA N° 3

DIMENSIÓN ESTABLECIMIENTO

Establecimiento

Código

Negocio

Corporación

Nombre

Identificación

Dirección

Teléfono

0001

Agroindustria

Agripac S.A.

Agripac S.A.

0990006687001

GENERAL CORDOVA 623 PADRE

SOLANO

042560400 Fuente: Investigación directa


Metodología 31

2.6.3 Dimensión Periodos

Es la fecha en la que se realiza el corte y se puede analizar de la siguiente

manera:

Jerarquía Año, Semestre, Trimestre, Mes, Día.

TABLA N° 4

DIMENSIÓN PERIODO

Periodos

Año

Semestre

Trimestre

Mes

Día

2015

Primer Semestre

Primer Trimestre

Enero

12 Fuente: Investigación directa


2.6.4 Dimensión Vendedor

Contiene la información de los vendedores que trabajan en

ECUAQUIMICA

TABLA N° 5

DIMENSIÓN VENDEDOR

Vendedor

Código Vendedor

Identificación

Nombre

00001

0906325145

Juan José Pérez Almeida



Metodología 32

2.6.5 Dimensión Zona

Contiene la información de las zonas donde se realizan las ventas de

acuerdo a su situación geográfica y comercial.

TABLA N° 6

DIMENSIÓN ZONA

Zona

Zona Comercial

Vendedor

Oficial/Crédito

Punto/Venta/Zona

Zona Geográfica

Subzona

UIO

Juan José Pérez Almeida

Juan Carlos Espinoza Carriel

El Recreo

Sierra

Pichincha Fuente: Investigación directa


2.6.6 Dimensión Punto de Venta

Contiene la información de los puntos de venta, donde se realizan las

ventas de acuerdo a la estructura regional de la organización.

TABLA N° 7

DIMENSIÓN PUNTO DE VENTA

Punto de Venta

Código

Oficina

Descripción

UIO-001

El Recreo

Avda. Ilalo Km.1.5 entre Alondras y Cisnes Fuente: Investigación directa


Metodología 33

2.6.7 Dimensión División

Contiene la jerarquía de las regiones actuales donde tiene flujo

transaccional de ventas la compañía.

TABLA N° 8

DIMENSIÓN DIVISIÓN

División

División

Línea de Negocio

Unidad de Negocio

Agroquímicos

AGRO

Ciclo Corto



2.6.8 Dimensión Región

Contiene las descripciones de las distintas regiones transaccionales que

cuenta la compañía.

TABLA N° 9

DIMENSIÓN DIVISIÓN

División

Región

Código

Descripción

1

C

Costa



Metodología 34

2.6.9 Dimensión Documento

Contiene las descripciones de los distintos tipos de documentos

transaccionales usados por la compañía.

TABLA N° 10

DIMENSIÓN DOCUMENTO

Documento

Tipo Documento

Documento

Factura

Venta Especial



2.6.10 Dimensión Forma de Pago

Contiene de información de las distintas formas de pago de los clientes de

la organización.

TABLA N° 11

DIMENSIÓN FORMA DE PAGO

Forma de Pago

Código

Descripción

001

Cheque



Metodología 35

2.6.11 Dimensión Rango Días Vencidos

Contiene los rangos para calcular los días vencidos de las ventas

realizadas.

TABLA N° 12

DIMENSIÓN RANGO DÍAS VENCIDOS



0 a 15 días

16-30 días

31 a 45 días

46 a 60 días

61 a 90 días

91 a 180 días

180 a 365 días

> 365 días Fuente: Investigación directa


2.6.12 Dimensión Rango Días Por Vencer

Contiene los rangos para calcular los días por vencer de las ventas

realizadas.

TABLA N° 13

DIMENSIÓN RANGO DE DÍAS POR VENCER

Rango de Días por Vencer

0 días

1 a 7 días

8 a 15 días

16 a 30 días

31 a 60 días

61 a 90 días

91 a 120 días

121 a 150 días

151 a 180 días

181 a 240 días

241 a 360 días

>360 días Fuente: Investigación directa


Metodología 36

2.6.13 Dimensión Rango Plazos Crédito

Contiene los rangos de los plazos de crédito para las ventas realizadas.

TABLA N° 14

DIMENSIÓN RANGO PLAZOS DE CRÉDITO

Rango Plazos de Crédito

Contado

1-8 días

9 a 20 días

21 a 30 días

31 a 35 días

36 a 45 días

46 a 60 días

> 60 días Fuente: Investigación directa


2.6.14 Dimensión Rango Edad de Cartera

Contiene los rangos para calcular la edad de la cartera.

TABLA N° 15

DIMENSIÓN RANGO EDAD DE CARTERA


Contado

0-30 días

31 a 45 días

46 a 60 días

61 a 75 días

76 a 90 días

91 a 120 días

121 a 150 días

151 a 180 días

181 a 240 días

241 a 300 días

301 a 360 días

>361 días Fuente: Investigación directa


Metodología 37

2.7 Esquema Multidimensional

A continuación se muestran los esquemas multidimensionales que se

definieron para la creación del cubo de cartera.

FIGURA N° 11

ESQUEMA DEL MODELO DE CARTERA GENERAL



FIGURA N° 12

ESQUEMA DEL MODELO DE CARTERA VENCIDA



Metodología 38

FIGURA N° 13

ESQUEMA DEL MODELO DE CARTERA POR VENCER



2.8 Implementación de la Solución

A continuación se detalla el proceso de implementación de la solución diseñada.

2.8.1 Componente ETL de Talen Open Studio

En el desarrollo de la solución se usó como herramienta ETL a la

plataforma Open Source Talend Open Studio, para ejecutar la extracción,

transformación y carga de los datos.

Las estructuras dimensionales van a ser creadas a partir de los

lineamientos expuestos para la creación del Data Mart, el contar con la

transformación dentro del componente ETL da la facilidad de realizar o disponer

de operaciones definidas para el uso exclusivo de la organización en base a sus

necesidades.

Metodología 39

2.8.1.1 Extracción, Transformación y Carga

A partir de esta sección se detallarán los pasos para realizar la extracción,

transformación y carga de los datos en las dimensiones necesarias desde el

repositorio fuente del sistema SWISS.

2.8.1.1.1 Introducción

Para realizar el proceso ETL se utiliza la herramienta Open Source Talend

Open Studio.

FIGURA N° 14

PROCESO ETL



A continuación se detallan las secuencias de trabajo que se crearon para el

proyecto.

2.8.1.1.2 Procesos ETL

2.8.1.1.2.1 Creación de Dimensiones

Este proceso gestiona las extracciones y transformaciones necesarias para

las dimensiones que va a utilizar el Cubo de Cartera. A continuación se detallan

las secuencias creadas:

SWISS – ORACLE 11G

Metodología 40

La secuencia de extracción y carga DIM_EMPRESA, tomará la

información de la compañía ECUAQUIMICA desde la tabla ECORTEMPRESA

para crear la tabla y dimensión: DIM_EMPRESA.

FIGURA N° 15

SECUENCIA DIM_EMPRESA



La secuencia de extracción y carga DM_ESTABLECIMIENTO, tomará la

información desde las tablas ECORTESTABLECIMIENTO, ECORTPERSONA,

ECORTCORPORACION, ECORTEMPRESA, ECORTEMPRESA_PERSONA,

ECORTCALIFICACIONES, para crear la tabla y dimensión:

DIM_ESTABLECIMIENTO la que corresponderá a los clientes de la

organización.

FIGURA N° 16

SECUENCIA DIM_ESTABLECIMIENTO



Metodología 41

La secuencia de extracción y carga DM_PERIODOS, tomará la

información de la tabla ECARTCARTERA, para crear la tabla y dimensión:

DIM_PERIODOS la que corresponde a los rangos de periodos utilizados en las

transacciones.

FIGURA N° 17

SECUENCIA DIM_PERIODOS



La secuencia de extracción y carga DM_VENDEDOR, tomará la

información de las tablas ECORTESTABLECIMIENTO, ECORTPERSONA,

ECORTEMPRESA, ECORTEMPRESA_PERSONA, para crear la tabla y

dimensión: DIM_VENDEDOR la que corresponderá a la información de los

vendedores de la organización.

FIGURA N° 18

SECUENCIA DIM_VENDEDOR



La secuencia de extracción y carga DM_ZONA, tomará la información de

la tabla ECORTZONA, para crear la tabla y dimensión: DIM_ZONA la cual

tendrá la información de las zonas geográficas y comerciales de las transacciones

de la organización.

Metodología 42

FIGURA N° 19

SECUENCIA DIM_ZONA



La secuencia de extracción y carga DM_PUNTO_VENTA, tomará la

información de la tabla ECORTPUNTO_VENTA, para crear la tabla y dimensión:

DIM_PUNTO_VENTA la cual tendrá información de los puntos de venta a nivel

nacional de la organización.

FIGURA N° 20

SECUENCIA DIM_PUNTO_VENTA



La secuencia de extracción y carga DM_DIVISIÓN, tomará la

información de las tablas ECORTLINEA_NEGOCIO, ECORTTIPO_NEGOCIO,

para crear la tabla y dimensión: DIM_DIVISIÓN la cual tendrá información de la

división de la organización así como de las líneas de negocio.

Metodología 43

FIGURA N° 21

SECUENCIA DIM_DIVISIÓN



La secuencia de extracción y carga DM_REGION, tomará la información

de la tabla ECORTREGION, para crear la tabla y dimensión: DIM_REGION la

cual tendrá las regiones donde se realizan transacciones por venta de la

organización.

FIGURA N° 22

SECUENCIA DIM_REGION

Fuente: Investigación directa Elaborado por: Panchana Jaramillo Gloria Stefania

La secuencia de extracción y carga DM_DOCUMENTO, tomará la

información de las tablas ECORTDOCUMENTO Y

ECORTTIPO_DOCUMENTO, para crear la tabla y dimensión:

DIM_DOCUMENTO la cual tendrá los tipos de documentos utilizados en las

transacciones de la organización para las ventas y cobros.

Metodología 44

FIGURA N° 23

SECUENCIA DIM_DOCUMENTO

Fuente: Investigación directa Elaborado por: Panchana Jaramillo Gloria Stefania

La secuencia de extracción y carga DM_FORMA_PAGO, tomará la

información de las tablas ECORTFORMA_PAGO, para crear la tabla y

dimensión: DIM_FORMA_PAGO la cual tendrá los tipos de pagos que recibe la

organización de sus clientes.

FIGURA N° 24

SECUENCIA DIM_FORMA_PAGO



La secuencia de extracción y carga DM_DIAS_VENCIDOS, tomará la

información de las tablas ECORTRANGO Y ECORTTIPO_RANGO, para crear

la tabla y dimensión DIM_RANGOS_DIAS_VENCIDOS, en dicha dimensión se

encontrarán los rangos que definan a la cartera como vencida.

Metodología 45

FIGURA N° 25

SECUENCIA DIM_DIAS_VENCIDOS



La secuencia de extracción y carga DM_DIAS_X_VENCER, tomará la


la tabla y dimensión DIM_RANGO_DIAS_X_VENCER en dicha dimensión se

encontrarán los rangos que definan a la cartera como por vencer.

FIGURA N° 26

SECUENCIA DIM_RANGO_DIAS_X_VENCER



La secuencia de extracción y carga DM_PLAZO_CRÉDITO, tomará la


la tabla y dimensión DIM_RANGO_PLAZO_CRÉDITO en dicha dimensión se

encontrarán los rangos que definan los créditos para los clientes.

Metodología 46

FIGURA N° 27

SECUENCIA DIM_RANGO_PLAZO_CRÉDITO



Las secuencias de extracción y carga DM_EDAD_CARTERA, tomará la


la tabla y dimensión DIM_RANGO_EDAD_CARTERA en dicha dimensión se

encontrará la información necesaria para armar la edad de la cartera.

FIGURA N° 28

SECUENCIA DIM_EDAD_CARTERA



La secuencia principal que organiza la ejecución de las dimensiones se

llama DIMENSIONES, por medio de esta secuencia se ejecutaran en paralelo las

dimensiones antes descritas, aquí podremos visualizar y monitorear los procesos

de manera general.

Metodología 47

FIGURA N° 29

SECUENCIA DIMENSIONES



2.8.1.1.2.2 Creación de Tablas Temporales

Este proceso gestiona las extracciones y transformaciones necesarias para

las tablas temporales que va a utilizar la secuencia final del proceso ETL para la

carga final a la tabla de hecho. A continuación se detallan las secuencias creadas:

La secuencia de extracción y carga TMP_PDP ejecutara la creación de la

tabla temporal TMP_PDP, misma que contiene la métrica Ponderado Días de

Pago usada en la creación de la tabla de hecho.

FIGURA N° 30

TABLA TEMPORAL TMP_PDP



Metodología 48

La secuencia de extracción y carga TMP_PDV ejecutara la creación de la

tabla temporal TMP_PDV, misma que contiene la métrica Ponderado Días de

Venta usada en la creación de la tabla de hecho.

FIGURA N° 31

TABLA TEMPORAL TMP_PDV



La secuencia de extracción y carga TMP_ROT_CART ejecutara la

creación de la tabla temporal TMP_ROT_CART, misma que contiene la métrica

Rotación de Cartera usada en la creación de la tabla de hecho.

FIGURA N° 32

TABLA TEMPORAL TMP_ROT_CART



La secuencia de extracción y carga TMP_VVENTAS_PROM_DIARIO

ejecutara la creación de la tabla temporal TMP_VVENTAS_PROM_DIARIO,

misma que contiene la métrica Promedio Diario de Ventas usada en la creación de

la tabla de hecho.

Metodología 49

FIGURA N° 33

TABLA TEMPORAL TMP_VVENTAS_PROM_DIARIO



La secuencia de extracción y carga TMP_VVENTAS_PROM_MENSUAL

ejecutara la creación de la tabla temporal TMP_VVENTAS_PROM_MENSUAL,

misma que contiene la métrica Promedio Mensual de Ventas usada en la creación

de la tabla de hecho.

FIGURA N° 34 TABLA TEMPORAL

TMP_VVENTAS_PROM_MENSUAL



La secuencia de extracción y carga TMP_VENT_ACUM ejecutara la

creación de la tabla temporal TMP_VENT_ACUM, misma que contiene la

métrica Venta Acumulada usada en la creación de la tabla de hecho.

Metodología 50

FIGURA N° 35

TABLA TEMPORAL TMP_VENT_ ACUM



La secuencia de extracción y carga TMP_RANGO_EDAD_CARTERA

ejecutara la creación de la tabla temporal TMP_RANGO_EDAD_CARTERA,

misma que contiene la métrica Rango Edad Cartera usada en la creación de la

tabla de hecho.

FIGURA N° 36

TABLA TEMPORAL TMP_RANGO_EDAD_CARTERA



La secuencia de extracción y carga TMP_RANGO_VENCIDOS ejecutara

la creación de la tabla temporal TMP_RANGO_VENCIDOS, misma que contiene

la métrica Rango Días Vencidos usada en la creación de la tabla de hecho.

FIGURA N° 37

TABLA TEMPORAL TMP_RANGO_VENCIDOS



Metodología 51

La secuencia de extracción y carga TMP_RANGO_X_VENCER ejecutara

la creación de la tabla temporal TMP_RANGO_X_VENCER, misma que

contiene la métrica Rango Días Por Vencer usada en la creación de la tabla de

hecho.

FIGURA N° 38

TABLA TEMPORAL TMP_RANGO_X_VENCER



La secuencia de extracción y carga TMP_RANGO_PLAZO_CREDITO

ejecutara la creación de la tabla temporal TMP_RANGO_PLAZO_CREDITO,

misma que contiene la métrica Rango Plazo Crédito usada en la creación de la

tabla de hecho.

FIGURA N° 39

TABLA TEMPORAL TMP_RANGO_PLAZO_CREDITO



La secuencia principal que organiza la ejecución y creación de las Tablas

Temporales se llama Tablas_Temporales, en esta secuencia se ejecutaran en

paralelo las secuencias antes descritas, aquí podremos visualizar y monitorear los

procesos de manera general.

Metodología 52

FIGURA N° 40

SECUENCIA PRINCIPAL - TABLAS TEMPORALES



2.8.1.1.2.3 Creación y carga de la tabla de hecho

Estos procesos gestionan las transformaciones y trabajos intermedios a

ejecutar, realizando la carga y ordenado de la información requerida hacia la tabla

de hecho que se va a utilizar para la creación del cubo de información.

A continuación se detallan los procesos creados:

FIGURA N° 41

TABLA DE HECHO CARTERA



Este job ejecuta la generación de la tabla de hechos de la cartera,

mapeando todas las tablas dimensionales antes creadas. En la sección del stage

TMap se crearán las columnas calculadas de acuerdo a las métricas definidas para

el cubo de cartera.

Metodología 53

2.8.1.1.3 Ejecución del Proceso ETL

Las tablas dimensionales, temporales y la tabla de hecho diseñadosen el

ETL para la trasformación y la carga de información, se ejecutan cada fin de mes

de forma automática mediante el crontab del servidor OBI.

A continuación se presentan las líneas de código que se crearon en el

crontab (programador de tareas) del servidor Linux, para automatizar los procesos

que se usaron en el desarrollo del proyecto:

FIGURA N° 42

CRONTAB DEL SERVIDOR



2.8.2 Estructura General– OBIIE

A continuación se presenta la estructura del cubo dentro del proyecto.

Como se puede observar en la figura de la herramienta Obi, vemos el nodo del

cubo de Cartera y los componentes que se desprenden del mismo.

FIGURA N° 43

AMBIENTE OBIEE



Metodología 54

FIGURA N° 44

ESTRUCTURA DEL DATA MART



Cubo Cartera

El cubo contiene un conjunto de dimensiones que se encuentra en el

primer nivel, también la tabla de hecho y por último las medidas calculadas que

serán necesarias para obtener los diferentes tipos de reportes para la gerencia.

2.8.2.1.1 Reportes e Indicadores

El caso a resolver en este proyecto era tener una data apropiada dentro de

los estándares y de la actual situación de la organización para la generación de los

reportes e indicadores creados a partir de las métricas aplicadas, de manera que

estos indicadores sirvan para la toma de decisiones en la organización.

La herramienta usada para la creación de los indicadores y reportes es

Publisher este es el componente de Oracle para el diseño y la publicación de

reportes en internet.

Metodología 55

FIGURA N° 45

PRESENTACION EN OBIEE



FIGURA N° 46

GRAFICAS DE CONSULTAS AL CUBO



Metodología 56

FIGURA N° 47

REPORTE DATAMART



FIGURA N° 48

GRAFICA DEL REPORTE



Metodología 57

2.9 Plan de Implementación

Para la implementación del proceso se realizó la siguiente planificación,

consta de las siguientes tareas:

Capacitación a Usuario de la instalación y uso de la herramienta

ETL Talend Open Studio.

Capacitación a Usuario de la instalación del cliente OBIEE.

Pruebas Internas de Secuencias ETL.

Preparación de Ambiente de Produccion.

Ejecución y Monitoreo del Proceso ETL en Producción.

Capacitación a Usuario (Jefa TI - Ecuaquímica).

Pruebas de Usuario del Proceso ETL en Producción.

Capacitación a Usuario del Ambiente OBIEE.

Pruebas de Usuario – Consultas y Reportes en OBIEE.

Los manuales de instalación y capacitación pueden ser visualizados en los

Anexos.

2.9.1 Riesgos en la Implementación

La compañía Ecuaquímica consta de un servidor OBI 11g instalado por la

compañía Maint hace 3 años, el cual no ha sido usado y EL cual consta de una

instalación con valores por defecto.

Al no tener un ambiente preparado con anticipación para evitar riesgos en

la implementación se realizaron las siguientes tareas:

Configuración de table spaces de la Base de Datos.

Configuración de la tabla TEMP en Base de Datos

Configuración del ambiente OBIEE.

Creación de un directorio raíz en el servidor para guardar los

componentes del proceso ETL.

Metodología 58

Creación del usuario Talend en el servidor.

Creación del archivo crontab para los usuarios Oracle y Talend.

Para que un proceso diseñado en Talend Open Studio pueda ejecutarse en

el servidor se debe compilar el proceso, esta acción generara archivos .jar que se

alojaran en la ruta creada dentro del servidor.

Cada vez que se ejecute el proceso consumirá la Virtual Machine del

servidor, si esta memoria se encontrase ocupada el proceso abortara; por este

motivo se implementó dentro del archivo .sh la limpieza de la VM, así cada vez

que se ejecute el proceso tendrá un ambiente depurado y evitara que aborte su

ejecución.

2.10 Plan de Pruebas

Las pruebas del proceso se las realizaron en dos fases, en la primera fase

se realizaron las cuadraturas de las dimensiones y de los cálculos de cada

métricas, mientras que la segunda fase fue comprobar la estabilidad del proceso

tantos en el tiempo del procesamiento como en la calidad de la información.

El proceso paso por un periodo de prueba mientras se realizó la carga de la

cartera histórica desde el mes de noviembre del 2012.

2.11 Resultados

Con la implementación del proceso la Jefe TI de Ecuaquímica recalco los

beneficios obtenidos con el proceso actual, la minimización de los tiempos de

ejecución del proceso y los tiempos de consulta hacía en cubo de cartera en

OBIEE. Los resultados de las cuadraturas y de la mejora obtenida en tiempos de

ejecución puede ser revisada en los Anexos.

CAPITULO III

3 PROPUESTA

3.1 Titulo

“Rediseño e Implementación de ETL Open Source para DATAMART de Cartera”

3.2 Objetivos

Implementar para el uso del departamento TI, una solución integral para

los reportes BI a nivel gerencial, usando el servidor OBI 11g e

implementando el uso de una herramienta ETL open source Talend Opend

Studio.

Construir un Data Mart de Cartera que se base en la dimensión de la

organización actual y de la demanda de los clientes en los últimos 5 años.

Generar reportes gerenciales usando Publisher en el OBI, los cuales

generen reportes realizados al momento de forma manual por el jefe de

cartera.

Mejorar en un 80% los tiempos de respuesta en las consultas al cubo de

cartera en comparación al cubo de información utilizado anteriormente.

3.3 Elaboración

3.3.1 Descripción de la Propuesta

El sistema propuesto se compone de los siguientes componentes:

Repositorio Fuente del Sistema de Información SWISS.

Propuesta 60

ETL Open Source Talend Open Studio

Repositorio Destino Oracle Business Intelligence 11G

FIGURA N° 49

ARQUITECTURA PROPUESTA



Se accederá a la base Oracle del SWISS para obtener la información que

armará los modelos y la dimensiones con la herramienta ETL Talen Open Studio

formando el cubo de cartera en el servidor Oracle 11g con la tecnología de

Publisher, por medio de esta los usuarios acceden a los reportes y gráficos en línea

como el ambiente tecnológico de este siglo amerita para realizar una toma de

decisión al instante.

3.3.2 Estudio de Factibilidad

3.3.2.1 Factibilidad Técnica

Hardware: una estación de trabajo (cliente)

Software: herramienta libre (Talend Open Studio Data Integration) y

PLSQL

Personal Técnico: dos programadores y un administrador del sistema de

información.

Propuesta 61

TABLA N° 16

FACTIBILIDAD TÉCNICA- HARWARE

Hardware Ordenador 1 Ordenador 2

Memoria RAM 8 Gb 8 Gb

Disco Duro 750 Gb 750 Gb

Procesador Core i3 Core i3

Tarjeta de Red Si Si



3.3.2.2 Factibilidad Operativa

Control de la información que se genera de las áreas implícitas en el cubo

como cobranzas, contabilidad; así como de las tendencias que se generan

en el mercado actual en base al entorno social, económico, ambiental y

político.

Disminución de los tiempos de búsqueda de información.

Agilitar el proceso de la toma de decisiones.

Generación de nuevos reportes conductuales en base a un solo cubo.

3.3.2.3 Factibilidad Financiera

Personal

TABLA N° 17

FACTIBILIDAD FINANCIERA- PERSONAL

Personal Requerido Perfil

1 Administrador

2 Programador



Propuesta 62

Hardware: una estación de trabajo (cliente)

TABLA N° 18

FACTIBILIDAD FINANCIERA-HARWARE

Hardware Ordenador

Memoria RAM 8 Gb

Disco Duro 750 Gb

Procesador Core i3

Tarjeta de Red Si

Recurso Requerido Valor

Recursos Tecnológicos 2070

2070

Recursos Especializados 1200

2 (600 c/u)

Recursos Extras 4230

4230

Costo total $ 7500



Ver detalle de costos en ANEXO A.

Costo.- Se realizará un análisis global de la arquitectura actual del

datamart de Cartera para conocer sus fuentes de información,

transformación y enriquecimiento de datos, y definición de sus tablas de

hecho.

Producto.- De este análisis se evaluará cualquier punto de mejora, que se

considere importante para garantizar cumplir con los objetivos del

proyecto, así como para asegurar el óptimo uso de los recursos

tecnológicos de ECUAQUIMICA.

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

ECUAQUIMICA.

Propuesta 63

Las pruebas con los usuarios finales las realizará el personal de

ECUAQUIMICA.

Finalmente se generarán y actualizarán todos los documentos

correspondientes tales como manual técnico, manual de operador, etc.

3.4 Impacto

La solución implementada se enfoca en brindar seguridad de la

información que se muestra en los reportes de acuerdo a la estructura actual de la

organización.

Promueve el crecimiento de la organización en base a las tendencias

económicas, sociales y ambientales de la actualidad siendo este puente principal

de mejoras en las áreas implícitas del cubo de información gracias a la toma de

decisiones por parte del nivel gerencial.

Las consultas ágiles en base a la solución implementada, brinda

información veraz y en línea a los responsables de las áreas TI y BI, pudiendo

estos convertirse en promotores de la búsqueda de fuentes de crecimiento de la

organización.

La optimización de los procesos crediticios y de cobranzas, ya que estos

procesos actúan como pilar en el eje de enlace cliente – organización; debido a

que en las divisiones agrícolas hay necesidades de diversas culturas de crédito que

se hacen visibles con la implementación realizada.

Conocer el volumen de las ventas y la localidad de donde se generan da la

oportunidad de conocer si los puntos de venta actuales son los necesarios o se

deben abrir nuevas localidades a los cuales los clientes accedan de manera más

rápida y oportuna, brindando la organización una satisfacción de su

administración.

Propuesta 64

Si la organización tiene en sus manos información relevante como el

tiempo que los clientes con crédito se demoran pagar sus deudas, se los puede

clasificar por línea o unidad de negocio esto daría ventaja a la organización para

tomar decisiones precisas sean para generar mejores créditos, para realizar un

castigo a la cartera o por brindar una retroalimentación efectiva en el

departamento de cobranza para cobrar los créditos otorgados.

La compañía ECUAQUIMICA cuenta con nichos de mercado que han

sido explotados por años pero el Sistema de Información Gerencial es capaz de

brindar una visión de posibles lugares a los que se debería desplegar una campaña

de marketing para ganar mercado virgen y generar ingresos a la compañía.

Al realizar consultas comparativas en el cubo de cartera actual podemos

rescatar los siguientes tiempos en ejecución que permiten apreciar el porcentaje de

rapidez que tiene la versión actual contra la versión anterior del cubo de Cartera.

TABLA N° 19

CUADRO COMPARATIVO DE TIEMPOS DE CONSULTA

TIPO/CONSULTA

TIEMPO/EJECUCION

POR HERRAMIENTA

DISCOVERER OBI

TIEMPOS DE

EJECUCION

Reporte Edad Cartera 50 min 10 min

Reporte Ventas Mes Enero 40 min 5 min

Reporte Recuperación/Cartera 1 hr 20 min Fuente: Investigación directa


TABLA N° 20

CUADRO COMPARATIVO DE TIEMPOS DE EJECUCION

EJECUCION

TIEMPO/EJECUCION

POR HERRAMIENTA

DISCOVERER ETL

TIEMPOS DE

EJECUCION

Proceso de Creación Tabla de

Hecho 24 horas 24 min



Propuesta 65

3.4.1 Informe de Tiempos de Ejecución

3.4.1.1 Análisis

3.4.1.1.1 Creación de Dimensiones

Tiene como finalidad conocer al detalle el nombre de las dimensiones que

se crean en el ambiente OBI y el tiempo que toma este proceso en ejecutarse.

TABLA N° 21

TIEMPOS DE EJECUCION - TABLAS DIMENSIONALES

NOMBRE_TABLA

TIEMPO/CREACION hh:mi:sg

DIM_EMPRESA 00:00:01

DIM_ESTABLECIMIENTO 00:00:04

DIM_PERIODOS 00:00:24

DIM_VENDEDOR 00:00:01

DIM_ZONA 00:00:02

DIM_PUNTO_VENTA 00:00:01

DIM_DOCUMENTO 00:00:01

DIM_RANGO_EDAD_CARTERA 00:00:01

DIM_RANGO_DIAS_VENCIDOS 00:00:01

DIM_RANGO_DIAS_X_VENCER 00:00:01

DIM_RANGO_PLAZO_CREDITO 00:00:01

DIM_REGION 00:00:01

DIM_DIVISION 00:00:01

DIM_FORMA_PAGO 00:00:01



La ejecución de las tablas dimensionales se realiza en paralelo.

Propuesta 66

3.4.1.1.2 Creación de Tablas Temporales

Tiene como finalidad conocer al detalle el nombre de las tablas temporales

que se crean en el ambiente OBI y el tiempo que toma este proceso en ejecutarse.

TABLA N° 22

TIEMPOS DE EJECUCION - TABLAS TEMPORALES

NOMBRE_TABLA TIEMPO/CREACION hh:mi:sg

TMP_PDP 00:02:53

TMP_PDV 00:01:50

TMP_VENT_ACUM 00:00:09

TMP_ROT_CART 00:02:17

TMP_VVENTAS_PROM_DIARIO 00:01:10

TMP_VVENTAS_PROM_MENSUAL 00:01:10

TMP_RANGO_EDAD_CARTERA 00:05:26

TMP_RANGO_DIAS_VENCIDOS 00:02:51

TMP_RANGO_DIAS_X_VENCER 00:02:50

TMP_RANGO_PLAZO_CREDITO 00:02:39



3.4.1.1.3 Creación de Tabla de Hecho

Tiene como finalidad conocer el tiempo estimado que toma la creación de

la tabla de hecho de cartera.

TABLA N° 23 TIEMPO DE EJECUCION - TABLA DE HECHO

"FC_CARTERA"

NOMBRE_TABLA TIEMPO/CREACION hh:mi:sg

FC_CARTERA 00:13:08



Propuesta 67

3.4.1.2 Proceso de análisis

El proceso principal del Cubo de Cartera cuenta con 3 procesos:

Creación de Tablas Dimensionales.

Creación de Tablas Temporales.

Creación de la Tabla de Hecho Fc_Cartera.

Como se puede apreciar en la secuencia a continuación:

FIGURA N° 50

SECUENCIA PRINCIPAL CUBO DE CARTERA



De acuerdo al Log de la Ejecución de la secuencia, podemos obtener los

tiempos para cada proceso.

FIGURA N° 51

LOG DE EJECUCION CUBO DE CARTERA



Propuesta 68

TABLA N° 24

TIEMPOS DE EJECUCION GLOBAL - PROCESO ETL

PROCESO EN EJECUCION TIEMPO TOTAL

TABLAS DIMENSIONALES 24 sg

TABLAS TEMPORALES 12 min 4 sg

CREACION TABLA DE HECHO FC_CARTERA 13 min 8 sg

TIEMPO DE EJECUCION TOTAL 25 min 36 sg



3.4.1.3 Conclusiones del Informe

De acuerdo al análisis realizado podemos indicar que:

El proceso ETL del Cubo de Cartera toma 25 minutos aproximadamente en

ejecutarse actualmente y obtener el resultado final que es la tabla de hecho

FC_CARTERA en comparación del proceso del Discoverer que tomaba 1 día en

ejecutarse con lo que hemos logrado un ahorro de tiempo del 98.33%.

3.5 Conclusiones

Del trabajo realizado a lo largo del desarrollo de este proyecto se pudo concluir lo

siguiente:

La data se filtra en base a la información necesaria para la formación del

Data Mart, hay mucha información que no saldrá al ambiente operacional,

solo los datos que realmente sean necesarios ingresarán al ambiente del

Data Mart.

El desarrollo de los procesos de extracción, transformación y carga son los

apropiados según la información requerida por la organización.

Del análisis de la información se diseñaron 3 modelos adecuados para la

construcción del cubo, estos modelos pueden ser objetos reutilizables para

el desarrollo de nuevos cubos.

Propuesta 69

La implementación de la herramienta ETL de software libre genera bajos

costos para la organización lo que disminuye la inversión para el cubo

desarrollado y próximos proyectos.

El uso de una interfaz BI de reportes en OBI permite el manejo intuitivo y

sencillo a los usuarios finales para generar sus reportes y análisis acorde a

las necesidades del negocio en comparación del uso de hojas de cálculo.

3.6 Recomendaciones

Usar el presente proyecto como base para la creación de otros cubos que

desee implementar el departamento de TI en la organización.

Dedicar el tiempo necesario para el análisis de las fuentes de datos de los

Data Mart, de esta manera se agilitará el trabajo al momento de la

construcción y ejecución del proceso de extracción, transformación y

carga.

Se recomienda recolectar la información de los requerimientos

directamente con los usuarios y propietarios de la data, ya que si es a

través de intermediarios dicha información puede resultar no segura y

provocará problemas en el desarrollo.

Generar otros reportes e indicadores tanto de los clientes como de los

tiempos de pago por tipo de unidad de negocio.

Capacitar a los usuarios del Sistema de Información y que estos saquen el

mayor provecho de esta fuente de información.

GLOSARIO DE TERMINOS

BI (Business Intelligence).- Es la habilidad para transformar los datos en

información, y la información en conocimiento, de forma que se pueda optimizar

el proceso de toma de decisiones en los negocios.

Se puede definir Business Intelligence como el conjunto de metodologías,

aplicaciones y tecnologías que permiten reunir, depurar y transformar datos de los

sistemas transaccionales e información desestructurada (interna y externa a la

compañía) en información estructurada, para su explotación directa (reporting,

análisis OLTP / OLAP, alertas...) o para su análisis y conversión en conocimiento,

dando así soporte a la toma de decisiones sobre el negocio.

Crontab.- Crontab es un simple archivo de texto que guarda una lista de

comandos a ejecutar en un tiempo especificado por el usuario. Crontab verificará

la fecha y hora en que se debe ejecutar el script o el comando, los permisos de

ejecución y lo realizará en el background. Cada usuario puede tener su propio

archivo crontab, de hecho el /etc/crontab se asume que es el archivo crontab del

usuario root, cuando los usuarios normales (e incluso root) desean generar su

propio archivo de crontab, entonces utilizaremos el comando crontab.

Crontab es la manera más sencilla de administrar tareas de cron en

sistemas multiusuario, ya sea como simple usuario de sistema o usuario root.

Datamart.- Un Data mart es una versión especial de almacén de datos

(data warehouse). Son subconjuntos de datos con el propósito de ayudar a que un

área específica dentro del negocio pueda tomar mejores decisiones. Los datos

existentes en este contexto pueden ser agrupados, explorados y propagados de

múltiples formas para que diversos grupos de usuarios realicen la explotación de

los mismos de la forma más conveniente según sus necesidades.

http://es.wikipedia.org/wiki/Almac%C3%A9n_de_datos

Glosario de Términos 71

El Data mart es un sistema orientado a la consulta, en el que se producen

procesos batch de carga de datos (altas) con una frecuencia baja y conocida. Es

consultado mediante herramientas OLAP (On line AnalyticalProcessing -

Procesamiento Analítico en Línea) que ofrecen una visión multidimensional de la

información. Sobre estas bases de datos se pueden construir EIS

(ExecutiveInformationSystems, Sistemas de Información para Directivos) y DSS

(DecisionSupportSystems, Sistemas de Ayuda a la toma de Decisiones).

Etl.- Extract, Transform and Load (Extraer, transformar y cargar en inglés,

frecuentemente abreviado a ETL) es el proceso que permite a las organizaciones

mover datos desde múltiples fuentes, reformatearlos y limpiarlos, y cargarlos en

otra base de datos, data mart, o data warehouse para analizar, o en otro sistema

operacional para apoyar un proceso de negocio.

Mdx.- Las expresiones multidimensionales (MDX es el acrónimo de

MultiDimensionaleXpressions) es un lenguaje de consulta para bases de datos

multidimensionales sobre cubos OLAP, se utiliza en Business Intelligence para

generar reportes para la toma de decisiones basados en datos históricos, con la

posibilidad de cambiar la estructura o rotación del cubo.

Modelo entidad relación.- Es un tipo de modelo de datos conceptual de

alto nivel que se emplea en el diseño de las base de datos relacionales.

El modelo entidad-relación muestra la estructura de la base de datos

empleando todo tipo de herramientas conceptuales.

Obi.- Oracle BI (Business Intelligence) es una plataforma de Oracle con

soluciones de inteligencia de negocios y almacenamiento de datos, que nos

permitirá visualizar los datos, convertirlos en una base para tomar decisiones

correctas en la empresa. Podremos ver gráficas y la tendencia de nuestros datos

sobre eso descubriremos problemas o bien oportunidades de negocio.

http://es.wikipedia.org/wiki/OLAP

http://es.wikipedia.org/wiki/Sistemas_de_informaci%C3%B3n_ejecutiva

http://es.wikipedia.org/wiki/Sistemas_de_soporte_a_decisiones

http://es.wikipedia.org/wiki/Acr%C3%B3nimo

http://es.wikipedia.org/wiki/Base_de_datos

http://es.wikipedia.org/wiki/Cubo_OLAP

http://es.wikipedia.org/wiki/Business_Intelligence


OLAP (procesamiento analítico en línea).- Es el tratamiento informático

que permite a los usuarios extraer fácilmente y de forma selectiva y ver los datos

desde diferentes puntos de vista. Para facilitar el análisis, los datos OLAP se

almacenan en una base de datos multidimensional. Considerando que una base de

datos relacional puede ser pensada como de dos dimensiones, una base de datos

multidimensional considera cada atributo de datos como un separado

“dimensión”. El software OLAP puede localizar la intersección de las

dimensiones y lo muestra.

OLTP (online TransactionProcessing).- Es un tipo de procesamiento de

transacciones a través de una red de computadoras. Algunos tipos de aplicaciones

OLTP pueden ser banca electrónica, procesamiento de pedidos o comercio

electrónico. Es un programa que facilita y administra aplicaciones transaccionales,

usualmente para data entry y transacciones en empresas, incluyendo bancos,

aerolíneas, etc. Los nuevos paquetes de Software para OLTP se basa en la

arquitectura cliente-servidor ya que suelen ser utilizados por empresas que no se

encuentran 100% en el mismo medio fisico, sino expandidas geográficamente.

Oracle Publisher.- Es una solución de reporting para realizar, gestionar y

entregar informes y documentos de forma más fácil y rápida que con las

herramientas de reporting tradicionales. Posee herramientas de escritorio

familiares basadas en navegación Web para crear desde documentos de pixelación

perfecta hasta informes de gestión interactivos desde prácticamente cualquier

fuente de datos.

Query.- En base de datos, query significa consulta. Es decir, un query en

base de datos es una búsqueda o pedido de datos almacenados en una base de

datos.

Tabla de hecho.- En un data warehouse, una tabla de hechos (o tabla fact)

es la tabla central de un esquema dimensional (en estrella o en copo de nieve) y

contiene los valores de las medidas de negocio. Cada medida se toma mediante la


intersección de las dimensiones que la definen, dichas dimensiones estarán

reflejadas en sus correspondientes tablas de dimensiones que rodearán la tabla de

hechos y estarán relacionadas con ella.

Ti (Tecnología de la información).- Es la aplicación de ordenadores y

equipos de telecomunicación para almacenar, recuperar, transmitir y manipular

datos, con frecuencia utilizado en el contexto de los negocios u otras empresas. El

término es comúnmente utilizado como sinónimo para los computadores, y las

redes de computadoras, pero también abarca otras tecnologías de distribución de

información, tales como la televisión y los teléfonos. Múltiples industrias están

asociadas con las tecnologías de la información, incluyendo hardware y software

de computador, electrónica, semiconductores, internet, equipos de

telecomunicación, e-commerce y servicios computacionales.

http://es.wikipedia.org/wiki/Ordenador

http://es.wikipedia.org/wiki/Telecomunicaci%C3%B3n

http://es.wikipedia.org/wiki/Negocios

http://es.wikipedia.org/wiki/Empresas

http://es.wikipedia.org/wiki/Computador

http://es.wikipedia.org/wiki/Red_de_computadoras

http://es.wikipedia.org/wiki/Hardware

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Electr%C3%B3nica

http://es.wikipedia.org/wiki/Semiconductor

http://es.wikipedia.org/wiki/Internet

http://es.wikipedia.org/wiki/E-commerce

ANEXOS

Anexos 75

ANEXO 1

PRESUPUESTO

№ RUBRO CANTIDAD VALORUN

ITARIO VALOR

RUBRO

1 RECURSOSNECESARIOS

Computadores

Impresora

2

1

1000

70

2000

70

SUBTOTAL 2070

2 RECURSOSHUMANOS

TutordeTrabajodeGraduaciónTribunaldeTrabajodeGr

aduaciónInvestigador(Autortrabajode

grado)

1

2

1

---

---

---

---

---

---

0

SUBTOTAL

2 RECURSOSMATERIALES

MaterialdeEscritorio

Tonerimpresoraláser(B/N)Resmasdepapel

CartuchosacolorCANONCajadeCDs

Carpetadeperfil

EmpastadosPortaminasMinasdeLápizBorrador

MaterialBibliográfico

Internet

Fotocopiasdelibros

2

3

4

1

4

4

2

12

2

30

3,8

21

20

0,5

15

3

0,4

0,2

60

11,4

84

20

2

60

6

4,8

0,4

Material Bibliográfico

Internet 4 meses 100 100

Copias 200 200

SUBTOTAL 2,439

4 OTROS

TransporteAlmuerzoGastosVarios 4 meses 2 600

4 meses 2 600

4 meses --- 200

SUBTOTAL 3839

TOTALGASTOS 7,500

TOTALDELPRESUPUESTO 7,500

Anexos 76

ANEXO 2

CRONOGRAMA

Anexos 77

ANEXO 3

DETALLE METRICAS

Nombre Métrica Tipo Cálculo

en

Herrami

enta de

BI

Usuario/Área

Responsable

Periodici

dad de

Consulta

Agregació

n

Días de Venta en Cartera -

Rotación

BASICA NO Cartera Mensual Mensual

Promedio de Venta Diario DERIVA

DA

NO Cartera Mensual Mensual

Ponderado Días de Pagos DERIVA

DA


Ponderado Días Vencidos BASICA NO Cartera Mensual Mensual

Cantidad de cheques

protestados


Valor de los cheques

protestados


Porcentaje de Cartera

Vencida


Porcentaje de Cartera por

vencer


Porcentaje de Cartera Normal BASICA NO Cartera Mensual Mensual

Porcentaje de Cartera Dudosa BASICA NO Cartera Mensual Mensual

Porcentaje de Cartera

Eliminada


Porcentaje de Recuperación

de Cartera


Valor Cartera Real BASICA NO Cartera Mensual Mensual

Valor de Cartera Vencida BASICA NO Cartera Mensual Mensual

Valor de Cartera por vencer BASICA NO Cartera Mensual Mensual

Valor de Cartera Normal BASICA NO Cartera Mensual Mensual

Valor de Cartera Dudosa BASICA NO Cartera Mensual Mensual

Valor de Cartera Eliminada BASICA NO Cartera Mensual Mensual

Valor de Recuperación de

Cartera


cantidad de cobro (count

pagos) *


cobro acumulado BASICA NO Cartera Mensual Mensual

factor ponderado cobro * DERIVA

DA


venta mensual prom 3mese BASICA NO Cartera Mensual Mensual

Anexos 78

ANEXO 4

DETALLE DE DIMENSIONES

79 Anexos

ANEXO 5

MANUAL DE INSTALACION TALEND OPEN STUDIO

1 Acceder Pagina de Talend Open Studio

Accedemos a la página de talend, tal como se aprecia en la imagen para luego

ubicarnos en la pestaña Products y escoger Data Integration Studio.

2 Escoger Data Integration de la pestaña Products

http://www.talend.com/

80 Anexos

3 Ubicarnos en la parte inferior de la página que se muestra a continuación

y escoger la opción de descargar gratis.

4 A continuación escoger el instalador de la herramienta de acuerdo al S.O.

que vayamos a utilizar.

81 Anexos

5 La descarga dará inicio, esperamos a que se termine de descargar el

instalador y proseguimos con el siguiente paso. La descarga demorara

alrededor de 12 minutos.

6 Ejecutamos el instalador a continuación de su descarga. Se debe crear

una carpeta en el disco C para que se aloje la instalación de la

herramienta.

82 Anexos

7 Una vez que hemos dado la ubicación donde se alojara la herramienta

damos click en Install.

.

8 De esta manera se comenzaran a extraer los componentes de la

herramienta en la ubicación dada.

83 Anexos

9 Una vez finalizada la extracción damos click en Close.

10 La primera vez que ejecutemos la herramienta nos mostrara los términos

de la licencia open source.

.

84 Anexos

11 Se debe crear un repositorio local para poder utilizar la herramienta

como cliente en nuestra máquina.

85 Anexos

12 Una vez realizado este paso podremos crear un proyecto para nuestro uso

local.

13 Teniendo nuestro nuevo proyecto le daremos click a Open y podremos

observar cómo se cargan los componentes para la vista grafica de la

herramienta.

86 Anexos

14 Cuando se ha concluido la carga de la herramienta podremos contar con

la interfaz gráfica dela misma y así podremos construir nuestros

proyectos.

87 Anexos

ANEXO 6

MANUAL DE INSTALACION CLIENTE OBIEE G

Para la conexión al servidor Oracle se requiere el componente OCI de Oracle por

lo cual se debe seguir los siguientes pasos:

1. Descargar el cliente Oracle de acuerdo a la maquina en que se instalara (

32 o 64 bits) .

http://www.oracle.com/technetwork/database/enterprise-

edition/downloads/112010-win64soft-094461.html

2. Descomprimir el archivo, buscar el archivo setup.exe y dar clic

3. Escoger la opción personalizada y presionar siguiente

http://www.oracle.com/technetwork/database/enterprise-edition/downloads/112010-win64soft-094461.html

http://www.oracle.com/technetwork/database/enterprise-edition/downloads/112010-win64soft-094461.html

88 Anexos

4. Seleccionar los idiomas en que se instalara el componente

89 Anexos

5. Especificar la ubicación donde se procederá a realizar la instalación

6. Escoger los componentes Oracle Call Interface y Oracle ODBC Driver

90 Anexos

7. Dar clic en siguiente para que Oracle realice la revisión de los

requerimientos

8. Dar clic en terminar

91 Anexos

Instalación del Cliente OBIIE 11G

1. Descargar de la ruta http://www.oracle.com/technetwork/middleware/bi-

enterprise-edition/downloads/bus-intelligence-11g-165436.html

2. Descomprimir el archivo y dar clic en el ejecutable

3. Elegir el idioma en el cual se procederá la instalación

http://www.oracle.com/technetwork/middleware/bi-enterprise-edition/downloads/bus-intelligence-11g-165436.html

http://www.oracle.com/technetwork/middleware/bi-enterprise-edition/downloads/bus-intelligence-11g-165436.html

92 Anexos

4. Dar clic en siguiente

5. Elegir la ubicación donde se instalara el componente y dar clic en

siguiente

6. Seleccionar en donde aparecerá el acceso directo

93 Anexos

7. Dar clic en instalar

8. Configurar el ODBC

9. Escribir el nombre del odbc y el servidor BI que debe acezar

94 Anexos

10. Escribir el login y password de servidor BI

11. Dar clic en finalizar

95 Anexos

ANEXO 7

MANUAL DE USUARIO

Introducción

El presente documento describe en su totalidad el proceso ETL del Cubo de

Cartera. Describe la arquitectura de la solución, el modelo de procesos y su

operación.

Condiciones y Supuestos

Este manual fue escrito bajo la premisa que el operador ha recibido capacitación

básica del uso de las herramientas:

- Talend Open Studio for Data Integration

- Putty

Arquitectura de la Solución

El proceso ETL del Cubo de Cartera genera información procesada de la empresa

en base a su cartera de cliente, manteniendo correlación con las métricas y regles

integradas bajo el análisis de las áreas implicadas. La creación de las tablas

dimensionales y de la tabla de hecho de la cartera se realiza mediante la

herramienta Talend Open Studio for Data Integration, con su respectiva carga en

el almacén de datos Oracle OBI.

swiis

96 Anexos

Modelo del Proceso

Estructura de Directorios del Proceso ETL – Cubo de Cartera

El proceso del Cubo de Cartera tiene 1 filesystem principal.

- El filesystem de script y datos: Lugar donde residen los componentes que

genera la solución en el ETL, así como del código en Shell que lanza las

ejecuciones automáticas.

/home/TalendOpenStudio/Cubo_Cartera_0.1

Configuración de las Ejecuciones Automáticas

Archivo Cron en el Servidor

El “cron” o demonio nativo del servidor para la ejecución calendarizada de

procesos, será el medio por el cual el proceso ETL se ejecutara de forma

automática. Por lo tanto el archivo crontab del usuario tendra configuradas las

ejecuciones.

Calendarización del Proceso del Cubo de Cartera

El proceso del Cubo de Cartera tiene un proceso principal, el que maneja

secuencias individuales encargadas de la creación de las dimensiones, tablas

temporales e inserción en la tabla de hecho de cartera.

El proceso esta calendarizado en el archivo crontab, para iniciar cada fin de mes a

las 10:00 pm:

Proceso del Cubo de Cartera

97 Anexos

Si se desea modificar la calendarización del proceso, se debe acceder en modo

consola al servidor OBI, y con el comando crontab –e editar las ejecuciones que

se encuentran calendarizadas en el sistema.

Ejecución Manual del Proceso ETL del Cubo de Cartera

Accediendo en modo consola al servidor, dirigirse a la ruta:

/home/TalendOpenStudio/Cubo_Cartera_0.1/Cubo_Cartera/

Habiendo encontrado el Proceso Principal del ETL Cubo_Cartera_run.sh podemos

ejecutarlo con parametro de entrada para ejecutar una fecha en especifico, por lo

cual se ejecutara el comando de forma manual con el siguiente comando:

./Cubo_Cartera_run.sh.

Configuración y Parametrización del Proceso de Backlog

El proceso del Cubo de Cartera utiliza puntos globales de configuración para el

proceso:

- Objetos de Conexión de Base de Datos

Objetos de Conexión de Base de Datos

La solución del Cubo de Cartera utiliza objetos de configuración globales para las

conexiones de base de datos. De esa forma el administrador puede actualizar la

clave y permitir el uso de la conexión al resto del equipo, sin comprometer

información crítica.

Los objetos de conexión en Talend Open Studio sirven

para encapsular las credenciales de conexión y facilitar su gestión. En el caso de

Oracle se han usado los siguientes tipos de conexiones:

Conector Oracle Input: Conector Oracle Output:

Los objetos de conexión principales del proyecto son:

A pesar que son tipos de conexión distintas, sus interfaces son iguales:

98 Anexos

Los parametros que tiene que definir son los siguientes:

Nombre del

Parámetro

Valor por Defecto Descripción

DB Type Oracle with SID Tipo de conexión a la base de

datos.

Db Version Oracle 11 Versión de la Base de datos.

StringOfConnection Jdbc:oracle:thin:@:1521: Cadena de conexión que se

genera automáticamente,

cuando se han rellenado los

campos posteriores.

Login OBI_EQ Nombre de usuario para

conectarse.

Contraseña ********* Contraseña para dicho

usuario.

Server 192.168.1.26 Dirección IP del servidor

donde se desea conectar.

Puerto 1521 Puerto de conexión para la

base de datos a donde se desea

conectar.

SID OBI Nombre único para una

instancia del servidor oracle.

Debido a que este objeto de conecion es utilizado por varios procesos, se debe

aceptar la actualizacion de las secuencias que se habilitara apenas se realice un

cambio en este apartado.

Script del Proceso

En la ruta /home/TalendOpenStudio/Cubo_Cartera_0.1/Cubo_Cartera/se

encuentra el archivo script Cubo_Cartera_run.sh que realiza la ejecución de los

jars generados por la herramienta Talend Open Studio para el proceso ETL del

Cubo de Cartera.

99 Anexos

Operativa del Script Cubo_Cartera.sh

El script está diseñado para ser ejecutado de dos formas:

Automática: Se ejecuta por medio del crontab del sistema.

Manual: Se ejecuta con un parámetro inicial (fecha en formato yyyymmdd)

para cargar una fecha específica a la tabla de hecho fc_cartera.

Ejecución Automática Cubo_Cartera.sh

En el servidor se creó el usuario talend para ejecutar el proceso ETL. Las

ejecuciones se levantaran según la programación dada en el archivo crontab del

usuario.

Para visualizar todos los archivos crontab que existen en el servidor por usuario,

se debe ir a la ruta /var/spool/cron/ del servidor.

Para visualizar el contenido del archivo crontab del usuario talend, procedemos a

iniciar sesion con el usuario y luego ejecutamos el comando crontab –l:

Las ejecuciones programadas en el archivo se han divido por el ultimo dia del

mes, es por eso que tenemos 3 lineas de ejecucion.

La primera linea indica que el script se ejecutara cada 29 de febrero a las

10:00 pm.

La segunda linea indica que el script se ejecutara cada 30 de los meses

4,6,9,11 (abril, junio, septiembre, noviembre) a las 10:00 pm.

La tercera y ultima linea indica que el script se ejecutara cada 31 de los

meses 1,3,5,7,8,10,12 (enero, marzo, mayo, julio, agosto, octubre,

diciembre) a las 10:00 pm.

Al ser una ejecucion automatica, el script genera la fecha invocando la fecha del

servidor y pasando como parametro a las secuencias de Talend que la requieran.

100 Anexos

Ejecución Manual Cubo_Cartera.sh

El script está diseñado para que pueda ser ejecutado de manera manual con o sin

parámetro inicial, básicamente la idea de ejecutarlo de forma manual es para

cargar alguna fecha en especial a la tabla de hecho.

Para realizar la ejecución manual con parámetro inicial, el operador deberá

acceder a la ruta del script

/home/TalendOpenStudio/Cubo_Cartera_0.1/Cubo_Cartera/ donde se debe aplicar

el siguiente formato al comando:

./Cubo_Cartera_run.sh <fecha>

La fecha que se ingrese debe estar en formato yyyymmdd, si esta no fuese

ingresada en el formato correcto, el script devolverá el mensaje de error

sea el caso que se haya dado por una longitud no correcta o por haber

ingresado un valor diferente al del formato (letras, símbolos), dejando sin

ejecutar el proceso.

Un ejemplo de la ejecución manual seria:

Código del Script Cubo_Cartera.sh

El código empleado en el script cuenta con las siguientes secciones:

Cabecera: nomenclatura del proveedor, nombres de los integrantes del

proyecto, fecha de creación y breve explicación del script.

Variables: en esta sección se localiza la variable que se obtiene cuando se

ha procedido a ejecutar el script de forma manual.

Validación de la fecha manual: se evalúa la longitud de la fecha ingresada

y el contenido de la misma, si esta ha sido ingresada en un formato

numérico requerido o si esta fecha tuviese algún carácter especial por error

humano.

Delete con parámetro fecha por comando a la tabla de hecho: se realiza

una limpieza de registros en cada ejecución del proceso por seguridad en

casos donde se haya perdido estabilidad del servidor por colapso o caída,

así se elimina la posibilidad de tener data duplicada en la tabla de hecho.

101 Anexos

Ejecución de jars de Talend: se levantan los jars de las secuencias

diseñadas en el talend con el parámetro fecha sea este autogenerado por el

script o ingresado de forma manual.

Sección: CABECERA

Sección: VARIABLES

Sección: VALIDACION DE LA FECHA INGRESADO O AUTO

GENERACION DE FECHA

Sección: DELETE CON PARAMETRO FECHA POR COMANDO A LA

TABLA DE HECHO

102 Anexos

Sección: EJECUCION DE JARS DE TALEND

Operativa del Proceso ETL del Cubo de Cartera

A continuación se describen las operaciones del proceso ETL del Cubo de

Cartera. Operaciones como:

- Creación de dimensiones.

- Creación de Tablas Temporales.

- Creación de Tabla de Hecho Fc_Cartera.

Monitorear el Funcionamiento Correcto del Proceso ETL del Cubo de

Cartera

En esta sección se describe el funcionamiento correcto del proceso y todos sus

componentes. Los componentes principales del proceso son el proceso de creación

de dimensiones, creación de tablas temporales y la creación de la tabla de hecho.

Estado Correcto del Proceso Cubo de Cartera

El estado actual se lo puede comprobar leyendo el archivo

Ejecucion_Cubo_Cartera.txt en la ruta del servidor

/home/TalendOpenStudio/Cubo_Cartera_0.1/Cubo_Cartera/. Direcciónese a la

ruta para revisar el estado del proceso.

Comportamiento Regular: Si la ejecución del proceso no tuvo inconveniente

alguno para iniciar, el archivo Ejecucion_Cubo_Cartera.txt deberá mostrarse

como a continuación:

103 Anexos

Estado Correcto del Proceso de Creación de Dimensiones

El estado actual se lo puede comprobar leyendo los archivos

Ejecucion_Cubo_Cartera.txt y Logs_Cubo_Cartera.txt en la ruta del servidor



Comportamiento Regular: Si la ejecución del proceso no tuvo inconveniente, el

archivo Logs_Cubo_Cartera.txt deberá mostrarse como a continuación:

Y el archivo Ejecucion_Cubo_Cartera.txt deberá mostrar el estatus de inicio y fin

de la ejecución.

Estado Correcto del Proceso de Creación de Tablas Temporales








de la ejecución.

104 Anexos

Estado Correcto del Proceso de Creación de la tabla de hecho de Cartera








de la ejecución.

Proceso ETL de Dimensiones

A continuación se describen cuáles son las dimensiones que el proceso ETL

genera:

- Dim_empresa

- Dim_establecimiento

- Dim_periodos

- Dim_documento

- Dim_division

- Dim_vendedor

- Dim_rangos_dias_vencidos

- Dim_region

- Dim_forma_pago

- Dim_punto_venta

- Dim_zona

- Dim_rangos_dias_x_vencer

- Dim_rango_edad_cartera

- Dim_rango_plazo_credito

Estructura de Directorios del Proceso ETL – Cubo de Cartera

105 Anexos

El proceso ETL de Dimensiones tiene 1 filesystem principal.

- El filesystem de script y datos: Lugar donde residen los componentes que

genera la solución en el ETL, así como del código en Shell que lanza las

ejecuciones automáticas.

/home/TalendOpenStudio/DIMENSIONES_0.1/DIMENSIONES

Script del Proceso

En la ruta /home/TalendOpenStudio/DIMENSIONES_0.1/DIMENSIONES se

encuentra el archivo script DIMENSIONES_run.sh que realiza la ejecución de los

jars generados por la herramienta Talend Open Studio para el proceso ETL de

Dimensiones.

Operativa del Script DIMENSIONES_run.sh

El script se ejecuta de una manera:

Manual: Se ejecuta sin parámetro inicial generar las dimensiones que

serán utilizadas por el entorno OBI.

Ejecución Manual DIMENSIONES_run.sh

Para realizar la ejecución manual, el operador deberá acceder a la ruta del script

/home/TalendOpenStudio/DIMENSIONES_0.1/DIMENSIONES donde se debe

ejecutar el siguiente comando:

./DIMENSIONES_ run.sh

Un ejemplo de la ejecución manual seria:

Operativa del Proceso ETL de Dimensiones

Monitorear el Funcionamiento Correcto del Proceso ETL de Dimensiones

En esta sección se describe el funcionamiento correcto del proceso y todos sus

componentes. EL componente principal del proceso es la creación de

dimensiones.

Estado Correcto del Proceso ETL de Dimensiones


Ejecucion_Dimensiones.txt y Logs_Dimensiones.txt en la ruta del servidor

/home/TalendOpenStudio/DIMENSIONES_0.1/DIMENSIONES. Direcciónese a

la ruta para revisar el estado del proceso.


archivo Logs_Dimensiones.txt deberá mostrarse como a continuación:

106 Anexos

Y el archivo Ejecucion_Dimensiones.txt deberá mostrar el estatus de inicio y fin

de la ejecución.

107 Anexos

ANEXO 8

MANUAL TECNICO

Secuencias y Jobs del proceso ETL del Cubo de Cartera

A continuación se describen las operaciones del proceso ETL del Cubo de

Cartera. Operaciones como:

- Proceso Principal del Cubo de Cartera.

- Creación de Dimensiones.

- Creación de Tablas Temporales.

- Creación de Tabla de Hecho Fc_Cartera.

Proceso Principal del Cubo de Cartera

La Secuencia Principal del Proceso ETL se llama Cubo_Cartera 0.1. Esta

secuencia administra la ejecución secuencial de la creación de dimensiones, de las

tablas temporales y de la tabla de hecho fc_cartera.

Sus componentes principales son los siguientes tRun_job:

- Dimensiones: administra la ejecucion en paralelo de las dimensiones que

utiliza el cubo de cartera.

- Tablas_Temporales: administra la ejecucion en paralelo de las tablas

temporales que sirven para la creacion del cubo de cartera.

- Cartera: realiza la creacion de la tabla de hecho del cubo de cartera.

108 Anexos

Creación de Dimensiones

La secuencia de creación de dimensiones es DIMENSIONES 0.1. Esta secuencia

administra la creación en paralelo de las dimensiones del cubo de cartera.

DIMENSION EMPRESA

La secuencia de la Dimension Empresa ejecuta la creacion de la tabla

DIM_EMPRESA; la cual contiene la jerarquía de las empresas que se consolidan

en ECUAQUIMICA.

DIMENSION ESTABLECIMIENTO

La secuencia de la Dimension Establecimiento ejecuta la creacion de la tabla

DIM_ESTABLECIMIENTO; la cual contiene la información de los clientes que

conforman la cartera de ECUAQUIMICA.

109 Anexos

DIMENSION PERIODOS

La secuencia de la Dimension Periodos ejecuta la creacion de la tabla

DIM_PERIDOS; la cual contiene los periodos en base a las fechas que se realiza

el corte.

DIMENSION DOCUMENTO

La secuencia de la Dimension Documento ejecuta la creacion de la tabla

DIM_DOCUMENTO; la cual contiene las descripciones de los distintos tipos de

documentos transaccionales usados por la compañía.

DIMENSION DIVISION

La secuencia de la Dimension Division ejecuta la creacion de la tabla

DIM_DIVISION; la cual contiene la jerarquía de las regiones actuales donde tiene

flujo transaccional de ventas la compañía.

110 Anexos

DIMENSION VENDEDOR

La secuencia de la Dimension Vendedor ejecuta la creacion de la tabla

DIM_VENDEDOR; la cual contiene la información de los vendedores que

trabajan en ECUAQUIMICA.

DIMENSION DIAS VENCIDOS

La secuencia de la Dimension Dias Vencidos ejecuta la creacion de la tabla

DIM_RANGOS_DIAS_VENCIDOS; la cual contiene los rangos para calcular los

días vencidos de las ventas realizadas.

DIMENSION REGION

La secuencia de la Dimension Region ejecuta la creacion de la tabla

DIM_REGION; la cual contiene las regiones habiles donde ECUAQUIMICA

realiza transacciones de venta.

111 Anexos

DIMENSION FORMA DE PAGO

La secuencia de la Dimension Forma de Pago ejecuta la creacion de la tabla

DIM_FORMA_PAGO; la cual contiene de información de las distintas formas de

pago de los clientes de la organización.

DIMENSION PUNTO DE VENTA

La secuencia de la Dimension Punto de Venta ejecuta la creacion de la tabla

DIM_PUNTO_VENTA; la cual contiene la información de los puntos de venta,

donde se realizan las ventas de acuerdo a la estructura regional de la organización.

DIMENSION ZONA

La secuencia de la Dimension Zona ejecuta la creacion de la tabla DIM_ZONA; la

cual contiene la información de las zonas donde se realizan las ventas de acuerdo

a su situación geográfica y comercial.

112 Anexos

DIMENSION DIAS POR VENCER

La secuencia de la Dimension Dias X Vencer ejecuta la creacion de la tabla

DIM_RANGOS_DIAS_X_VENCER; la cual contiene los rangos para calcular los

días por vencer de las ventas realizadas.

DIMENSION EDAD DE LA CARTERA

La secuencia de la Dimension Edad de la Cartera ejecuta la creacion de la tabla

DIM_RANGO_EDAD_CARTERA; la cual contiene los rangos para calcular la

edad de la cartera.

DIMENSION PLAZO CREDITO

La secuencia de la Dimension Plazo Credito ejecuta la creacion de la tabla

DIM_RANGO_PLAZO_CREDITO; la cual contiene los rangos de los plazos de

crédito para las ventas realizadas..

113 Anexos

Creación de Tablas Temporales

La secuencia de creación de tablas temporales es TABLAS_TEMPORALES 0.1.

Esta secuencia administra la creación en paralelo de las tablas temporales que

serán consumidas por el proceso de creación de la tabla de hecho fc_cartera.

Tabla Temporal TMP_PDP

La secuencia TMP_PDP ejecuta la creacion de la tabla temporal TMP_PDP; la

cual contiene registros calculados sobre la metrica Ponderado Dias de Cobro.

114 Anexos

Tabla Temporal TMP_PDV

La secuencia TMP_PDV ejecuta la creacion de la tabla temporal TMP_PDV; la

cual contiene registros calculados sobre la metrica Ponderado Dias de Venta.

Tabla Temporal TMP_ROT_CART

La secuencia TMP_ROT_CART ejecuta la creacion de la tabla temporal

TMP_ROT_CART; la cual contiene registros calculados sobre la metrica

Rotacion de Cartera - Diaria.

Tabla Temporal TMP_VVENTAS_PROM_DIARIO

La secuencia TMP_VVENTAS_PROM_DIARIO ejecuta la creacion de la tabla

temporal TMP_VVENTAS_PROM_DIARIO; la cual contiene registros

calculados sobre la metrica Ponderado de Ventas Diarias.

Tabla Temporal TMP_VVENTAS_PROM_MENSUAL

La secuencia TMP_VVENTAS_PROM_MENSUAL ejecuta la creacion de la

tabla temporal TMP_VVENTAS_PROM_MENSUAL; la cual contiene registros

calculados sobre la metrica Ponderado de Ventas Mensual.

115 Anexos

Tabla Temporal TMP_VENT_ACUM

La secuencia TMP_VENT_ACUM ejecuta la creacion de la tabla temporal

TMP_VENT_ACUM; la cual contiene registros calculados sobre la metrica Valor

de Cobros Acumulados.

Tabla Temporal TMP_RANGO_EDAD_CARTERA

La secuencia TMP_RANGO_EDAD_CARTERA ejecuta la creacion de la tabla

temporal TMP_RANGO_EDAD_CARTERA; la cual contiene los rangos de la

edad de la cartera en base a los registros de la cartera cargada.

Tabla Temporal TMP_RANGO_VENCIDOS

La secuencia TMP_RANGO_VENCIDOS ejecuta la creacion de la tabla temporal

TMP_RANGO_VENCIDOS; la cual contiene los rangos de los dias vencidos en

base a los registros de la cartera cargada.

116 Anexos

Tabla Temporal TMP_RANGO_X_VENCER

La secuencia TMP_RANGO_X_VENCER ejecuta la creacion de la tabla

temporal TMP_RANGO_X_VENCER; la cual contiene los rangos de los dias por

vencer en base a los registros de la cartera cargada.

Tabla Temporal TMP_RANGO_PLAZO_CREDITO

La secuencia TMP_RANGO_PLAZO_CREDITO ejecuta la creacion de la tabla

temporal TMP_RANGO_PLAZO_CREDITO; la cual contiene los rangos de los

creditos de las ventas en base a los registros de la cartera cargada.

Proceso de Creación de la Tabla de Hecho Fc_Cartera

El proceso de Creación de la tabla de Hecho de Cartera realiza el mapeo

correspondiente del Query principal con las tablas temporales en base al

establecimiento y el punto de venta del cliente que tenga registros en el mes de

carga para crear la tabla de hecho.

117 Anexos

Scripts del proceso ETL

Cubo_Cartera_run.sh

En la ruta del código del proyecto

/home/TalendOpenStudio/Cubo_Cartera_0.1/Cubo_Cartera se encuentra un script

que realiza la ejecución del proceso ETL del Cubo de Cartera

Cubo_Cartera_run.sh.

Entradas

Fecha (Opcional): en formato yyyymmdd.

Salidas

Ninguna.

Archivos Creados/Modificados

- deleteHW.log: registro de la ejecución del delete en la tabla de hecho en base

a la fecha que se cargara.

- Ejecucion_Cubo_Cartera.txt: Guarda el registro de la fecha y hora del

comienzo y fin de ejecución de las secuencias principales: Cubo de Cartera,

Dimensiones, Tablas Temporales y Cartera.

- Logs_Cubo_Cartera.txt: Guarda el registro de las secuencias que se están

ejecutando al momento de forma detallada.

Variables Declaradas

#-------------------------------------

PassSql=ecuaquimica11

UserSql=OBI_EQ

#-------------------------------------

Mapeo entre Secuencias

Secuencia Principal Secuencia Detalle

Creación de

Dimensiones

Dimensiones 0.1

DM_EMPRESA

DM_ESTABLECIMIENTO

DM_PERIODOS

DM_DOCUMENTO

DM_DIVISION

DM_VENDEDOR

DM_DIAS_VENCIDOS

DM_REGION

DM_FORMA_PAGO

DM_PUNTO_VENTA

DM_ZONA

DM_DIAS_X_VENCER

DM_EDAD_CARTERA

118 Anexos

DM_PLAZO_CREDITO

Creación de

Tablas

Temporales

Tablas_temporales

0.1

TMP_PDP

TMP_PDV

TMP_ROT_CART

TMP_VVENTAS_PROM_DIARIO

TMP_VVENTAS_PROM_MENSUAL

TMP_VENT_ACUM

TMP_RANGO_EDAD_CARTERA

TMP_RANGO_VENCIDOS

TMP_RANGO_X_VENCER

TMP_RANGO_PLAZO_CREDITO

Cartera Cartera 0.1

Proceso

Principal del

Cubo de

Cartera

Cubo_Cartera 0.1

DIMENSIONES

TABLAS TEMPORALES

CARTERA

Uso de Parámetros y Creación del Context Group

Para hacer uso de parámetros en el ambiente Talend Open Studio, debemos

considerar el crear gestor de parámetros desde la pestaña Repositorio donde

encontraremos la sección Context y podremos crear un nuevo Context Group

desde el ambiente grafico de Talend.

Si damos click derecho sobre esta seccion, encontraremos un menu desplegable

del cual escogeremos la opcion Create Context Group:

119 Anexos

En pantalla se mostrara la ventana inicial para dar nombre al nuevo grupo de

parametros:

Luego de dar nombre al grupo de parámetros, configuraremos los parámetros

necesarios a utilizar dentro del proceso ETL:

Los campos a llenar son:

Name: El primer campo corresponde al nombre del parametro a crear.

Type: Dentro de la lista desplegable, escoja el tipo de dato que

correspondera para el parametro que se creara.

Default/Value: Si configura el valor por defecto al parámetro este será el valor

inicial en cada ejecución de su secuencia, caso contrario este campo

permanecerá en null.

120 Anexos

Default/Prompt: Si ha activado el check debe dar un nombre a la

ventana que se mostrara para requerir el valor de la variable o parametro

creado antes de efectuar la ejecucion de la secuencia.

Una vez que hemos creado todos los parámetros que utilizaremos daremos click

en Finalizar y ya tendremos a disposición un grupo Context para usar.

Si deseamos crear un nuevo parametro en este grupo o modificar algun valor de

un parametro ya creado debemos ir al context group y dar click derecho

escogiendo la opcion Edit Context Group:

Configurar parámetro en una secuencia

Una vez configurado un grupo de parámetros y teniendo una secuencia creada

donde haremos uso de uno o más parámetros debemos configurar a la misma para

que reciba el valor del parametro al ser ejecutado.

Dentro del área de trabajo de una secuencia creada, en la pestaña Context,

buscaremos el context group que tenga el o los parámetros que deseamos

configurar en el job.

121 Anexos

En el area inferior de este recuadro, se debe buscar el context group que

necesitamos haciendo click en el boton:

Se nos desplegara un listado de context group creado y los parametros que

pertenenezcan a cada uno de estos grupos:

En ese momento podremos escoger los parametros que utilizaremos en el job

creado y nos mostrara en la pestaña Context de la secuencia diseñada.

Uso de un parámetro

Para poder hacer uso de un parametro se debe conocer que se puede aplicar

parametros a:

Stage de Conexión

Rutas

Querys en Stages de Bases de Datos

122 Anexos

Usar Parámetros en Query de Stage de Bases de Datos

Haciendo uso de un Stage de tipo Base de Datos indiferentemente de que base de datos

utilice. En la sección Query del Stage:

Debemos proporcionar un query que necesite un parametro en su ejecucion, el

formato del parametro en la sentencia dependera si es de tipo carácter o de tipo

numerico ambos formatos son detallados a continuacion:

Formato Parámetro Carácter:

’”+context.<NombreParametro>+”’

Formato Parámetro Numérico:

”+context.<NombreParametro>+”

Ejemplo de Query con Parámetro de tipo Carácter:

123 Anexos

Ejemplo de Query con Parámetro de tipo Numérico:

Paso de Parametros entre job Child and TRun_Job

Cuando tenemos un escenario donde hemos creado una secuencia que se ejecutara

como parte de una secuencia principal la llamaremos: Child (Hijo), y la secuencia

que ejecutan las secuencias Child se llaman: Trun_Job.

Las secuencias de tipo Trun_Job, deben ser configuradas para transmitir los

parámetros con dos pasos:

El primer paso es configurar desde la Pestaña Context la variable que

necesita recibir, para esto volveremos a realizar los pasos de la sección

10.1

El segundo paso es escoger el Trun_Job de la secuencia que se ejecuta con

parámetro y dar click derecho sobre la misma, escogiendo la opción

Settings

124 Anexos

Se nos presentara una pestaña en la cual configuraremos el paso de los

parametros desde la secuencia global a la secuencia hijo.

Se debe configurar el Job Padre para que transmita los parametros que

necesitamos al Job hijo, llenando los campos del Context Param:

o Parametros: se especifica el nombre del o los parametros que

utilizara el Job Child en la ejecucion de la secuencia.

o Valores: se define el valor por default del parámetro o la llamada al

context del parámetro creado. En formato

context.nombre_parametro

Debemos recordar activar los casilleros:

Die on child error: el casillero es activado para detener el proceso principal

en el caso que uno de los hijos del proceso presente un error y no se haya

ejecutado.

Transmit whole context: esta opcion se activa para que el valor del

parametro sea transmitido desde la secuencia principal hacia la secuencia

hijo.

125 Anexos

Tipos de Stage en Talend Open Studio

Los stages que se han utilizado dentro del proceso ETL son:

Conector Oracle Input: Este componente realiza una consulta de base de

datos que debe corresponder a la definición del esquema, luego se pasa a

la lista de campos hasta el siguiente componente a través de un enlace

principal de fila (Row).

Conector Oracle Output: Ejecuta la acción definida en el componente

(escribir, actualizar, hacer cambios o suprimir entradas en la base de

datos), basándose en el flujo de entrada desde el componente anterior en el

job.

Tmap: transforma datos procedentes de uno o varios repositorios hacia uno

o varios destinos.

TWarn: Este componente proporciona un mensaje de prioridad para el

stage que lo utilice, se lo configura para generar alertas en la ejecución de

una secuencia de manera individual por componente.

TLogCatcher: Este componente permite realizar un registro de ejecución

provocada por tres instancias que son: excepción de java, TDIE o TWarn,

de esta manera concentra el registro en un log definido por el usuario.

126 Anexos

TStatCatcher: Este componente obtiene la información del procesamiento

tanto a nivel del Job como a nivel del componente, para lo cual se debe

activar la opción tStatCatcher Statisticsen la configuración de los mismos.

TRunJob: Lanza a ejecución un job que este configurado en este

componente y envía parámetros que necesite el job haciendo uso del

context.

TAggregateRow: Este componente recibe un flujo de datos que recibirán

una función (sum, min, max, count, etc) específica transformando cada

uno de las líneas de salida en base a una o varias columnas de agrupación

o keys.

TConvertType: Este componente ayuda a convertir un tipo de datos de una

columna de entrada en un tipo de datos distinto para la columna de salida,

invocando función java para la conversión de manera automática para

evitar una compilación con errores.

TReplace: Este componente realiza una búsqueda – reemplazo de

caracteres o información a los registros de una o más columnas definidas

por el usuario.

127 Anexos

Tips del Uso de Stage en Casos Específicos

A continuación se describen configuraciones adicionales en componentes

específicos de los expuestos en la sección 11.

Los componentes de los cuales expondremos un tip, son:

TOracleInput

TOracleOutput

TMap

TRunJob

TOracleInput

TOracleInput - Cursor

Cuando hacemos uso de este componente con un Query que va a traer a memoria

una cantidad superior a los 2000000 de registros es considerable trabajar con

cursores al no disponer de una memoria adecuada para operar con este tamaño de

información.

Para configurar el uso de un cursor, se debe acceder a la pestaña componente y

ubicarnos en la sección Configuración Avanzada del componente que estamos

utilizando.

Activar la casilla Usar Cursor y de manera numerica llenar el campo del tamaño

del cursor que se desea configurar.

TOracleOutput

TOracleOutput - Commit

Al realizar inserción con información de gran tamaño es necesario cambiar la

cantidad por default (10000) del commit en este componente en una tabla por una

cantidad más baja (1000 preferible), de esa manera la ejecución no quedara

corrupta por una excepción java del tipo Array.

Para editar la cantidad de commit por registro, se debe acceder a la pestaña

componente y ubicarnos en la sección Configuración Avanzada del componente

que estamos utilizando.

128 Anexos

TMap

El componente TMap realiza transformaciones de acuerdo a la información que se

desee manipular, se hace uso de funciones en java, si hay más de un input se

realizan joins por medio de una columna clave y se generan los outputs necesarios

por el usuario.

TMap – Inputs

Se puede conectar uno o varios inputs al componente TMap de acuerdo a la

necesidad de la solución.

Si es el caso de tener más de un input el primer enlace al componente se

establecerá como un input principal que se reflejara como Main de manera

automática al unirse al TMap, el resto de inputs al unirse con el componente se

reflejaran como Lookup de manera automática. Es indispensable saber que el

repositorio que se establezca como Main será el flujo principal y que en los demás

repositorios se establecerán como flujos de información adicionales que formaran

uno o varios flujos de salida.

TMap – Key Principal

Entre las configuraciones importantes al disponer de varios inputs enlazados al

Tmap, se debe realizar el enlace de la tabla principal por medio de una columna

129 Anexos

key hacia una columna que corresponda con la misma información en los inputs

secundarios.

TMap – Join y Tipos de Joins

Al tener enlazados los inputs del tmap, se necesita configurar el join que se

realizara en el proceso de carga de datos. Por tal motivo se debe acceder a la

configuración del join por cada uno de los inputs, dando click en el botón de

la cabecera del input:

Se desplegaran las configuraciones del input, que a continuacion se detalla:

Lookup Model: la forma en que se realizara la carga de los datos para el

input se define en esta seccion, dando click en el campo Value podremos

verificar las opciones de carga en una ventana que se nos mostrara en

pantalla.

o Load Once: se carga toda la informacion que provenga del input.

o Reload at each row: se carga una línea cada vez que se encuentre

coincidencia con el input principal.

130 Anexos

o Reload at each row (cache): se carga una línea cada vez que se

encuentre coincidencia con el input principal en memoria.

Match Model: el tipo de coincidencia que se configurara para la carga de

los datos del input se define en esta seccion, dando click en el campo

Value podremos verificar las opciones de coincidencia en una ventana que

se nos mostrara en pantalla.

o Unique Match: el join se ejecutara con una unica coincidencia por

lo tanto si el flujo principal multiplica los registros la coincidencia

se realizara por la ultima coincidencia encontrada del flujo

o Primera Coincidencia: esta configuracion es lo contrario del

Unique Match, si se establece el valor como la primera

coincidencia sera la primera coincidencia que se tome del flujo

principal.

o Todas las Coincidencias: con este valor todas las coincidencias

encontraradas seran el flujo de salida del join.

Join Model: el tipo de join que se puede configurar dependera del tipo de

proceso que realicemos para la carga de los datos lo cual se definira en

131 Anexos

esta seccion, dando click en el campo Value podremos verificar las

opciones de join en una ventana que se nos mostrara en pantalla:

o Inner Join: el join se ejecutara siempre y cuando haya una

coincidencia en el input principal y el secundario para generar un

flujo de salida.

o Left Outer Join: el join se ejecutara a pesar de no encontrar una

coincidencia en el input secundario enviando el registro de la

izquierda al flujo de salida.

Store temp data: Cuando se esta procesando gran volumen de informacion

y no se dispone de un equipo con las cualidades necesarias para cargar esta

informacion en memoria, se habilita la opcion de almacenar en una ruta

especifica la informacion que se esta procesando y trasformando desde el

componente TMap.

132 Anexos

TRunJob

El componente TRunJob invoca la ejecución de Job de tipo Child, manteniendo

una distribución organizada de los procesos que se van a ejecutar.

Hay dos maneras de ejecutar una secuencia con componentes TRunJob:

o Secuencial: se ejecutan los jobs en forma ordenada esperando que

finalice el primer jobs en ejecucion para continuar con el siguiente

sucesivamente con todos los jobs de la secuencia.

Para lo cual se hace uso del link OnSubJobOk para configurar la

ejecución secuencial.

o Paralelo: los jobs se inicializan al mismo tiempo y la secuencia se

da por terminada cuando todos los jobs han finalizado, las

ejecuciones de los jobs se maneja de forma independiente.

Para lo cual desde la pestaña TRABAJO se debe acceder a la

opción EXTRA y activar el casillero MULTI THREAD

EXECUTION para configurar la ejecución paralela.

Configuración de Logs en Ambiente Talend Open Studio

Para poder contar con archivos donde podamos visualizar la ejecución de los

procesos y secuencias creadas en T.O.S. se debe configurar de manera gráfica en

donde se crearan los archivos y el nombre de los mismos.

Para lo cual se debe acceder a la pestaña TRABAJO y ubicar la opción STATS &

LOGS. Podremos visualizar la configuración por default del proyecto, por lo cual

se desactivara el check de USE PROJECT SETTINGS:

133 Anexos

Al desactivar la casilla se habilitaran los casilleros para el uso del TStatCatcher,

TLogCatcher y TFlowMeterCatcher, por lo cual se activaran las dos primeras

casillas donde podremos observar los parametros a configurar:

Entre las opciones para visualizar los logs de las ejecuciones, tenemos:

o ON CONSOLE: los logs se visualizaran en un prompt de

visualizacion dentro del ETL o de donde se lo ejecute.

o ON FILE: los logs se guardaran en archivos: Esta opción debe ser

configurada activando la casilla.

o ON DATABASES: los logs se guardaran en un repositorio de

almacenamiento. Esta opción debe ser configurada activando la

casilla.

134 Anexos

Una vez activado el uso de las estadisticas de ejecucion y los logs, se debe

configurar los parametros:

o RUTA ARCHIVO: hace referencia a la ruta donde se alojara el

logs de la secuencia creada.

o STATS FILE NAME: Nombre del archivo de las estadísticas de

ejecución de la secuencia.

o LOGS FILE NAME: Nombre del archivo log de la ejecución de la

secuencia.

135 Anexos

ANEXO 9

CUADRATURA DE DIMENSIONES

Dimensiones

Empresa

Contiene la jerarquía de las empresas que se consolidan en ECUAQUIMICA

DIMENSION CANTIDAD DE

REGISTROS ORIGEN

CANTIDAD DE

REGISTROS DESTINO

DIM_EMPRESA 1 1

Query de Cuadratura:

selectemp.id,emp.codigo,emp.descripcion,emp.ruc

from

ecortempresaemp

whereemp.id=1

union

select

0asID,'0' ASCODIGO,'NO-APLICA' ASDESCRIPCION,'0' ASRUC

fromdual

Establecimiento

Contiene la información de los clientes que conforman la cartera de ECUAQUIMICA


REGISTROS

ORIGEN

CANTIDAD DE

REGISTROS DESTINO

DIM_ESTABLECIMIENTO 44092 44092


select

estab.id,

estab.codigo,

pers.negocio,

corp.codigo,

pers.nombre,

pers.apellidopaterno,

pers.apellidomaterno,

pers.tipoidentificacion,

pers.identificacion,

pers.direcciondomicilio,

pers.telefono,

calif.codigo

from

ecortestablecimientoestab

innerjoinecortempresa_personaempers

onempers.id=estab.empresapersona_id

136 Anexos

joinecortpersonapers

onpers.id=empers.persona_id

leftouterjoinecortcorporacioncorp

oncorp.id=pers.corporacion_id

innerjoinecortcalificacionescalif

oncalif.id=estab.calificacion_id

whereestab.estadoin('A', 'I')

andestab.empresa_id=1

union

select

0asID,'0' ASCODIGO,'NO-APLICA' ASnegocio,'0' ASCODIGO,'NO-APLICA' ASnombre,

'NO-APLICA' ASapellidopaterno,'' ASapellidomaterno,'0' AStipoidentificacion,

'0' ASidentificacion,'NO-APLICA' ASdirecciondomicilio,'0' AStelefono,'0' ASCODIGO

fromdual

orderbyid

Periodos

Es la fecha en la que se realiza el corte y se puede analizar de la siguiente manera:

Jerarquía Año, Semestre, Trimestre, Mes, Día.


REGISTROS ORIGEN

CANTIDAD DE

REGISTROS DESTINO

DIM_PERIODOS 2023 2023


SELECT

UNIQUE(TO_CHAR(fechacreacion, 'DD/MM/YYYY')),

to_number(TO_CHAR(fechacreacion, 'YYYY')),

casewhento_number(to_char(to_date(fechacreacion,'dd/mm/yyyy'),'mm'))<=6

then 'PrimerSemestre'

else 'SegundoSemestre'

end,

casewhento_number(to_char(to_date(fechacreacion,'dd/mm/yyyy'),'mm'))<=3

then 'PrimerTrimestre'

elsecasewhento_number(to_char(to_date(fechacreacion,'dd/mm/yyyy'),'mm'))<=6

then 'SegundoTrimestre'

elsecasewhento_number(to_char(to_date(fechacreacion,'dd/mm/yyyy'),'mm'))<=9

then 'TercerTrimestre'

else

'CuartoTrimestre'

end

end

endAS,

to_number(TO_CHAR(fechacreacion, 'MM')),

to_number(TO_CHAR(fechacreacion, 'dd' ))

FROMECARTCARTERA

wherefechacreacion>=to_date('01/01/2009','dd/mm/yyyy')

137 Anexos

Vendedor

Contiene la información de los vendedores que trabajan en ECUAQUIMICA


REGISTROS ORIGEN

CANTIDAD DE

REGISTROS DESTINO

DIM_VENDEDOR 531 531


select

pers.id,

pers.sms,

pe.identificacion,

pe.razonsocialnombres,

pers.vendedor

fromecortempresaemp

joinecortempresa_personapers

onemp.id=pers.empresa_id

andemp.id=1

innerjoinecortpersonape

onpe.id=pers.persona_id

wherepers.vendedorin( 'S','I')

union

select

0asid,'0' ASsms,'0' ASidentificacion,'NO-APLICA' ASnombres,'0' ASvendedor

fromdual

orderbysms

Zona

Contiene la información de las zonas donde se realizan las ventas de acuerdo a su

situación geográfica y comercial.


REGISTROS ORIGEN

CANTIDAD DE REGISTROS

DESTINO

DIM_ZONA 1823 1823


SELECT

zo.idasZO_ZONA_ID,

zo.PADRE_IDasZO_PADRE_ID,

zo.nivelasZO_NIVEL,

zo.tipoasZONA_COMERCIAL,

(selectz.descripcionfromecortzonazwherez.id=zo.idandzo.nivel= '1'

andzo.tipo='C')asZO_ZONA_COM,


andzo.tipo='C')asZO_SUBZONA_COM,

138 Anexos

zo.oficialcredito_id,

ofp.razonsocialnombre_oficial,

epv.idvendedor_id,

zo.puntoventa_id,

zo.tipo,


andtipo='G')asZO_ZONA_GEO,


andtipo='G')asZO_SUBZONA_GEO

fromECORTZONAzo

joinecortempresaemp

onemp.id=zo.empresa_id

andemp.id=1

leftjoinecortempresa_personaep

onep.id=zo.oficialcredito_id

leftjoinecortpersonaofp

onofp.id=ep.persona_id

leftjoinecortempresa_personaepv

onepv.id=zo.vendedor_id

leftjoinecortpersonape

onpe.id=epv.persona_id

wherezo.tipoin('G','C')

union

select

0asZO_ZONA_ID,0ASZO_PADRE_ID,0ASZO_NIVEL,

'0' ASZONA_COMERCIAL,'NO-APLICA' ASZO_ZONA_COM,

'NO-APLICA' ASZO_SUBZONA_COM,0asoficialcredito_id,

'NO-APLICA' ASnombre_oficial,0asvendedor_id,

0aspuntoventa_id,'0' AStipo,'NO-APLICA' ASZO_ZONA_GEO,

'NO-APLICA' ASZO_SUBZONA_GEO

fromdual

orderbyZONA_COMERCIAL,ZO_PADRE_ID,ZO_NIVEL

Punto de Venta

Contiene la información de los puntos de venta, donde se realizan las ventas de acuerdo a

la estructura regional de la organización.


REGISTROS ORIGEN

CANTIDAD DE

REGISTROS DESTINO

DIM_PUNTO_VENTA 26 26


selectpv.idptoventa_id,pv.CODIGOcod_ptoventa,pv.OFICINA_ID,ofi.codigocod_oficina,ofi.descr

ipciondesc_oficina,pv.DESCRIPCIONdesc_ptoventa,

pv.DIRECCIONdireccion_ptoventa

fromecortpunto_ventapv

joinecortoficinaofi

onpv.oficina_id=ofi.id

139 Anexos

whereofi.empresa_id=1

union

select

0asptoventa_id,'0' AScod_ptoventa,0ASOFICINA_ID,'0' AScod_oficina,'NO-APLICA'

ASdesc_oficina,'NO-APLICA' ASdesc_ptoventa,'NO-APLICA' ASdireccion_ptoventa

fromdual

orderbyptoventa_id

División

Contiene la jerarquía de las regiones actuales donde tiene flujo transaccional de ventas la

compañía.


REGISTROS ORIGEN

CANTIDAD DE

REGISTROS DESTINO

DIM_DIVISION 28 28


SELECTn.idasID,n.padre_idASPADRE_ID,n.nivelASNIVEL,

(selectdescripcionfromecortlinea_negociolnwhereln.id=n.idandn.nivel=1)asdivision,

(selectdescripcionfromecortlinea_negociolnwhereln.id=n.idandn.nivel=2)aslineanegocio,

(selectdescripcionfromecortlinea_negociolnwhereln.id=n.idandn.nivel=3)asunidad_negocio

FROMECORTLINEA_NEGOCIOn

WHEREn.EMPRESA_ID=1

union

select

0asID,0ASPADRE_ID,0ASNIVEL, 'NO-APLICA' ASDIVISION,'' ASlineanegocio, ''

ASunidad_negocio

fromdual

ORDERBYPADRE_ID,NIVEL

Documento

Contiene las descripciones de los distintos tipos de documentos transaccionales usados

por la compañía.


REGISTROS ORIGEN

CANTIDAD DE

REGISTROS DESTINO

DIM_DOCUMENTO 445 445


select

tip.id,tip.codigotipodoc,tip.descripciondesc_tipodoc,doc.codigodocumento,

doc.descripciondesc_documento

from

140 Anexos

ECORTTIPO_DOCUMENTOtip

joinECORTDOCUMENTOdoc

ontip.id=doc.tipodocumento_id

wheremodulonotin('I','O')andtip.cliente='S'

union

select

0asID,'0' ASCODIGO,'NO-APLICA' ASDESCRIPCION,'0' ASCODIGO,'NO-APLICA'

ASDESCRIPCION

fromdual

Forma de Pago

Contiene de información de las distintas formas de pago de los clientes de la

organización.


REGISTROS ORIGEN

CANTIDAD DE

REGISTROS DESTINO

DIM_FORMA_PAGO 40 40


SELECTdistinct

fp.ID,fp.CODIGO,fp.DESCRIPCION

FROMECARTFORMA_PAGOfp

leftjoinecartforma_pago_documentodoonfp.id=do.formapago_id

leftjoinecortdocumentodond.id=do.documento_id

leftjoinecorttipo_documentotpontp.id=d.tipodocumento_id

WHEREtp.modulonotin('I','O')andd.cliente='S'

union

select

0asID,'0' ASCODIGO,'NO-APLICA' ASDESCRIPCION

fromdual

orderbyid


Contiene los rangos para calcular los días vencidos de las ventas realizadas.


REGISTROS

CANTIDAD DE

REGISTROS

141 Anexos

ORIGEN DESTINO

DIM_RANGOS_DIAS_VENCIDOS 8 8


selectr.idasID,tr.codigoASCODIGO,tr.descripcionASDESCRIPCION,r.descripcionASDESCRIPC

ION,

r.inicioASINICIO,r.finASfin

fromecortrangor

joinecorttipo_rangotrontr.id=r.tiporango_id

wherer.tipo='OBI'

andtr.codigo= 'RV'

union

select

0asID,'0' ASCODIGO,'NO-APLICA' ASDESCRIPCION,'NO-APLICA'

ASDESCRIPCION,0ASINICIO,0ASFIN

fromdual

orderbyCODIGO

Rango de Días por Vencer

Contiene los rangos para calcular los días por vencer de las ventas realizadas.


REGISTROS

ORIGEN

CANTIDAD DE

REGISTROS

DESTINO

DIM_RANGOS_DIAS_X_VENCER 12 12



ION,


fromecortrangor


wherer.tipo='OBI'

andtr.codigo= 'RPV'

union

select



fromdual

orderbyCODIGO

142 Anexos

Rango Plazos de Crédito

Contiene los rangos de los plazos de crédito para las ventas realizadas.


REGISTROS

ORIGEN

CANTIDAD DE

REGISTROS

DESTINO

DIM_RANGO_PLAZO_CREDITO 8 8


selectr.id,tr.codigo,tr.descripcion,r.descripcion,r.inicio,r.fin

fromecortrangor


wherer.tipo='OBI'

andtr.codigo= 'RPC'

union

select



fromdual

orderbyCODIGO


Contiene los rangos para calcular la edad de la cartera.


REGISTROS

ORIGEN

CANTIDAD DE

REGISTROS

DESTINO

DIM_RANGO_EDAD_CARTERA 12 12



ION,


fromecortrangor


wherer.tipo='OBI'

andtr.codigo= 'REC'

union

select



fromdual

orderbyCODIGO

143 Anexos

ANEXO 10

CUADRATURA DE METRICAS

Métricas

VALOR CARTERA REAL

Sumatoria de toda la cartera.

Query Cuadratura – Origen:

select c.puntoventa_id, sum(d.valor) total_cartera

from ecartcartera c

join ecartcartera_detalle d on d.cartera_id=c.id

LEFTjoin ecortpunto_venta p on p.id=c.puntoventa_id

where c.puntoventa_id=&puntoventa_id and

p.empresa_id=1

and

c.fechacreacion <= TO_DATE('20150430','yyyymmdd')

and c.tipocartera = 'C'

groupby c.puntoventa_id;

Query Cuadratura – Destino:

selectsum(c.fc_val_cart_real)

from

fc_cartera c

where

c.pv_puntoventa_id = 1

CASOS DE CUADRE ORACLE

ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

1 -34098374,68 -34098374,68 0 0,00%

2 -19530152,96 -19530152,96 0 0,00%

3 23750687,39 23750687,39 0 0,00%

4 -3262790,002 -3262790,002 0 0,00%

5 4652924,765 4652924,765 0 0,00%

PROMEDIO DE VENTA DIARIO

Se calcula de la siguiente manera: las ventas acumuladas de los últimos 5 años por cliente

/ (3600*5)


select v.establecimiento_id,sum(v.valor_neto)/(trunc(TO_DATE('20150430','yyyymmdd'))-

add_months(trunc(TO_DATE('20150430','yyyymmdd')),-60)) venta_promedio_diaria

from swissebi.eebivventas_netas v

join ecortpunto_venta p on p.id=v.puntoventa_id

where V.puntoventa_id=&puntoventa_id and

v.fecha between add_months(trunc(TO_DATE('20150430','yyyymmdd')),-60)

andtrunc(TO_DATE('20150430','yyyymmdd')) --and

144 Anexos

and p.empresa_id=1

groupby v.establecimiento_id


select

distinct(c.es_establecimiento_id),

c.fc_pond_dias_ventas ponderado

from

fc_cartera c

where


and c.es_establecimiento_id = 32147


ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

32147 92,12894852 92,12894852 0 0,00%

29043 1,379983571 1,379983571 0 0,00%

25670 239,1904852 239,1904852 0 0,00%

27605 0,38745345 0,38745345 0 0,00%

26847 9,988466594 9,988466594 0 0,00%

25581 51,92031911 51,92031911 0 0,00%

28500 0,517502738 0,517502738 0 0,00%

29061 3,849003286 3,849003286 0 0,00%

25220 11,33105137 11,33105137 0 0,00%

28498 47,500908 47,500908 0 0,00%

VENTA MENSUAL PROMEDIO

Se calcula de la siguiente manera: Sumatoria de Venta Bruta – Sumatoria de Notas de

Credito

Se considera ventas brutas a las ventas antes de impuesto

No se considera si la nota de crédito esta cruzada o no con la venta.


select v.establecimiento_id,(sum(v.valor_neto)/(trunc(TO_DATE('20150430','yyyymmdd'))-

add_months(trunc(TO_DATE('20150430','yyyymmdd')),-60)))*30 venta_promedio_mensual



where V.puntoventa_id=&puntoventa_id

and v.fecha between add_months(trunc(TO_DATE('20150430','yyyymmdd')),-60)

and p.empresa_id=1


145 Anexos


select


c.fc_venta_mens promedio

from

fc_cartera c

where




ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

24765 133,6314348 133,6314348 0 0,00%

24689 85,97267251 85,97267251 0 0,00%

24937 516,9182366 516,9182366 0 0,00%

27685 976,5584655 976,5584655 0 0,00%

28885 936,5909639 936,5909639 0 0,00%

29692 1929,645016 1929,645016 0 0,00%

25624 1556,045619 1556,045619 0 0,00%

26030 3748,877192 3748,877192 0 0,00%

27294 2875,064093 2875,064093 0 0,00%

27374 1551,255148 1551,255148 0 0,00%

VALOR DE CARTERA ELIMINADA

Sumatoria de la cartera eliminada



from ecartcartera c


join ecortpunto_venta p on p.id=c.puntoventa_id


c.estado='E'and

p.empresa_id=1


and c.fechacreacion <= TO_DATE('20150430','yyyymmdd')



selectsum(c.fc_val_cart_elim)

from

fc_cartera c

where


146 Anexos


ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

1 1165585,44 1165585,44 0 0,00%

2 685529,62 685529,62 0 0,00%

3 299349,14 299349,14 0 0,00%

4 150251,43 150251,43 0 0,00%

5 313397,445 313397,445 0 0,00%

VALOR DE CARTERA DUDOSA

Sumatoria de la cartera con estatus dudosa.



from ecartcartera c




c.estado='D'and

p.empresa_id=1





selectsum(c.fc_val_cart_dudosa)

from

fc_cartera c

where



ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

1 772251,13 772251,13 0 0,00%

2 591499,05 591499,05 0 0,00%

3 1268356,62 1268356,62 0 0,00%

4 124740,46 124740,46 0 0,00%

5 454483,05 454483,05 0 0,00%

VALOR DE CARTERA NORMAL

Sumatoria de la cartera con estatus normal.

147 Anexos



from ecartcartera c




c.estado='N'and

p.empresa_id=1





selectsum(c.fc_val_cart_normal)

from

fc_cartera c

where



ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

1 -36085881,51 -36085881,51 0 0,00%

2 -20899249,3 -20899249,3 0 0,00%

3 22181083,79 22181083,79 0 0,00%

4 -3540768,852 -3540768,852 0 0,00%

5 3872334,57 3872334,57 0 0,00%

VALOR CARTERA POR VENCER

Sumatoria de la cartera con estatus por vencer.



from ecartcartera c




p.empresa_id=1and

d.fechavencimiento>=trunc(TO_DATE('20150430','yyyymmdd'))




selectsum(c.fc_val_cart_vencer)

148 Anexos

from

fc_cartera c

where



ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

1 2886426,11 2886426,11 0 0,00%

2 3281650,93 3281650,93 0 0,00%

3 7760090,12 7760090,12 0 0,00%

4 783416,0676 783416,0676 0 0,00%

5 1539857,55 1539857,55 0 0,00%

VALOR DE CARTERA VENCIDA

Sumatoria de la cartera con estatus vencida.



from ecartcartera c




p.empresa_id=1and

d.fechavencimiento<trunc(TO_DATE('20150430','yyyymmdd')) and

d.saldo<>0




selectsum(c.fc_val_cart_venc)

from

fc_cartera c

where



ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

1 9657036,22 9657036,22 0 0,00%

2 3656971,9 3656971,9 0 0,00%

3 8810130,95 8810130,95 0 0,00%

4 1412046,03 1412046,03 0 0,00%

5 4517268,14 4517268,14 0 0,00%

VALOR DE LOS CHEQUES PROTESTADOS

149 Anexos

Sumatoria de valor de cheques protestados.


select c.puntoventa_id, nvl(sum(d.valor),0) valor_cheques_protestados

from ecartcartera c




p.empresa_id=1and

d.documento_id in(180,294) --and --de NDB y DID




selectsum(c.fc_val_chq_prot)

from

fc_cartera c

where



ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

1 3449403,91 3449403,91 0 0,00%

2 2804619,54 2804619,54 0 0,00%

3 1321863,75 1321863,75 0 0,00%

4 761454,73 761454,73 0 0,00%

5 1386569,32 1386569,32 0 0,00%

CANTIDAD DE CHEQUES PROTESTADOS

Cantidad de cheques protestados.


select c.puntoventa_id, count(c.id) cantidad_cheques_protestados

from ecartcartera c




p.empresa_id=1and

d.documento_id in(180,294) --and --de NDB y DID




select

sum(c.fc_cant_chq_prot)

from

fc_cartera c

150 Anexos

where



ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

1 4315 4315 0 0,00%

2 2629 2629 0 0,00%

3 640 640 0 0,00%

4 889 889 0 0,00%

5 1513 1513 0 0,00%

CANTIDAD DE COBROS

Cantidad de cobros.


select c.establecimiento_id, count(c.id) cantidad_cobro

from ecartcartera c


where c.puntoventa_id=&puntoventa_id

and p.empresa_id=1and

c.tipodocumento_id in(31,81)


groupby c.establecimiento_id;


select


c.Fc_cantidad_Cobros cobros

from

fc_cartera c

where



151 Anexos


ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

28402 76 76 0 0,00%

27315 52 52 0 0,00%

25290 395 395 0 0,00%

27783 45 45 0 0,00%

24765 127 127 0 0,00%

28029 233 233 0 0,00%

25581 1519 1519 0 0,00%

27489 11 11 0 0,00%

27775 307 307 0 0,00%

25834 206 206 0 0,00%

CANTIDAD DE COBROS ACUMULADOS

Sumatoria de cobros acumulados por mes.


select c.establecimiento_id, sum(d.valor) cobro_acumulado

from ecartcartera c



where c.puntoventa_id=&puntoventa_id

and p.empresa_id=1and

c.tipodocumento_id in(31,81) --and --RPG y TPT


and c.fechacreacion between add_months(trunc(TO_DATE('20150430','yyyymmdd')),-60)

andtrunc(TO_DATE('20150430','yyyymmdd'))

and c.puntoventa_id = 1

groupby c.establecimiento_id;


select

distinct (c.es_establecimiento_id),

c.fc_cobros_acum cobros_acumulados

from

fc_cartera c

where



152 Anexos


ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

28180 -15611,15 -15611,15 0 0,00%

25581 -347456,8 -347456,8 0 0,00%

25421 -13102,41 -13102,41 0 0,00%

30034 -5902,56 -5902,56 0 0,00%

26452 -2806,68 -2806,68 0 0,00%

24707 -13928,04 -13928,04 0 0,00%

27661 -12614,78 -12614,78 0 0,00%

24434 -116891,68 -116891,68 0 0,00%

24524 -86904,22 -86904,22 0 0,00%

30588 -99,38 -99,38 0 0,00%

DIAS DE VENTA EN CARTERA – ROTACION

Cuantos días de labor de venta se requiere para la cartera actual. Su cálculo es Total de Cartera /

Promedio de Ventas Diaria.


select esta,abs(round(sum(total_cartera)/sum(venta_promedio_diaria),4))

dias_venta_cartera_rotacion

from(

select c.establecimiento_id esta,sum(d.valor) total_cartera, 0 venta_promedio_diaria

from ecartcartera c

join ecartcartera_detalle d on d.cartera_id = c.id


where c.puntoventa_id = &puntoventa_id and

p.empresa_id=1

groupby c.establecimiento_id

union

select v.establecimiento_id esta,0 total_cartera,

sum(v.valor_neto) / (trunc(TO_DATE('20150430','yyyymmdd')) -

add_months(trunc(TO_DATE('20150430','yyyymmdd')), -60)) venta_promedio_diaria



where v.puntoventa_id = &puntoventa_id

and fecha between add_months(trunc(TO_DATE('20150430','yyyymmdd')), -60)

andtrunc(TO_DATE('20150430','yyyymmdd')) and

p.empresa_id=1


)

where esta = 24434

groupby esta;

153 Anexos


select


c.fc_rot_cart cobros_acumulados

from

fc_cartera c

where




ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

28180 10250,628 10250,63 0,002 0,00%

25581 7760,8177 7760,818 0,0003 0,00%

25421 59,1459 59,14591 1E-05 0,00%

30034 174638,3121 174638,3 -0,0121 0,00%

26452 12,6951 12,69511 1E-05 0,00%

24707 13398,1835 13398,18 -0,0035 0,00%

27661 1618,6579 1618,658 1E-04 0,00%

24434 199,5708 199,5708 0 0,00%

24524 166,1757 166,1757 0 0,00%

30588 12,007 12,00699 -1E-05 0,00%

FACTOR PONDERADO DIAS DE PAGO

(Sumatoria de ( valor del pago * días desde la fecha de emisión a la fecha de pago ) de cada recibo

)/ ( sumatoria del valor de las deudas )

No se consideran cheques postfechados . No se consideran Notas de crédito


select y.establecimiento_id, e.nombre, round(sum(y.sumatoria)/sum(y.pago)) pdp

from (

select x.establecimiento_id, sum(x.pago*x.dias_cobro) sumatoria, 0 pago

from(

select c.establecimiento_id, c.id credito_id, c.puntoventa_id, d.fechavencimiento fecha_cobro,

cd.id debito_id, db.fechacartera fecha_emision,

(casewhen (decode(d.documento_id,312, d.fechacartera, d.fechavencimiento)-

db.fechacartera)<0then0

else (decode(d.documento_id,312, d.fechacartera, d.fechavencimiento)-db.fechacartera) end)

dias_cobro,

abs(sum(a.valor)) pago

from ecartcartera c



join ecartafecta a on a.detallecredito_id=d.id

join ecartcartera_detalle db on db.id=a.detalledebito_id

join ecartcartera cd on cd.id=db.cartera_id


154 Anexos

p.empresa_id=1and

c.tipodocumento_id in(31,81) and--RPG y TPT

c.fechacreacion between add_months(trunc(TO_DATE('20150430','yyyymmdd')),-60)


groupby c.establecimiento_id, c.id , c.puntoventa_id, d.fechavencimiento, cd.id , db.fechacartera,

(casewhen (decode(d.documento_id,312, d.fechacartera, d.fechavencimiento)-

db.fechacartera)<0then0

else (decode(d.documento_id,312, d.fechacartera, d.fechavencimiento)-db.fechacartera) end)

) x

groupby x.establecimiento_id

union

select c.establecimiento_id, 0 sumatoria, abs(sum(a.valor)) pago

from ecartcartera c



join ecartafecta a on a.detallecredito_id=d.id

join ecartcartera_detalle db on db.id=a.detalledebito_id

join ecartcartera cd on cd.id=db.cartera_id


p.empresa_id=1and

c.tipodocumento_id in(31,81) and--RPG y TPT




) y

join ecortestablecimiento e on e.id=y.establecimiento_id

groupby y.establecimiento_id, e.nombre

havinground(sum(y.sumatoria)/sum(y.pago))>0

orderby e.nombre;


select


c.Fc_Pond_Dias_Cob PDP

from

fc_cartera c

where


and

c.es_establecimiento_id = 27527

155 Anexos


ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

29240 16 16 0 0,00%

18799 25 25 0 0,00%

29415 66 66 0 0,00%

29825 82 82 0 0,00%

30090 2 2 0 0,00%

36161 85 85 0 0,00%

19622 12 12 0 0,00%

29682 52 52 0 0,00%

28679 39 39 0 0,00%

27527 110 110 0 0,00%

FACTOR PONDERADO DIAS VENCIDOS

(Sumatoria de (valor del pago * días desde la fecha de emisión a la fecha de vencimiento) de cada

recibo )/ (sumatoria del valor de las deudas )

No se consideran cheques postfechados . No se consideran Notas de crédito


select y.establecimiento_id, e.nombre, round(sum(y.sumatoria)/sum(y.totalvencido)) pdv

from(

select x.establecimiento_id, sum(sumatoria) sumatoria, 0 totalvencido

from (

select c.establecimiento_id, c.id, c.puntoventa_id, d.fechavencimiento fechavencimiento,

d.fechavencimiento-trunc(TO_DATE('20150430','yyyymmdd')) dias_vencidos, abs((

d.fechavencimiento-trunc(TO_DATE('20150430','yyyymmdd')))*sum(d.saldo)) sumatoria,

sum(d.saldo) saldo

from ecartcartera c




p.empresa_id=1and

c.tipodocumento_id =1and--FAC



(d.fechavencimiento-trunc(TO_DATE('20150430','yyyymmdd')))<0

groupby c.establecimiento_id, c.id, c.puntoventa_id, d.fechavencimiento

havingsum(d.saldo)>0

) x groupby x.establecimiento_id

union

select c.establecimiento_id, 0 sumatoria, sum(d.saldo) totalvencido

from ecartcartera c




p.empresa_id=1and

c.tipodocumento_id =1and--FAC



156 Anexos

(d.fechavencimiento-trunc(TO_DATE('20150430','yyyymmdd')))<0


havingsum(d.saldo)>0

) y

join ecortestablecimiento e on e.id=y.establecimiento_id

groupby y.establecimiento_id, e.nombre

orderby e.nombre

;


select


c.fc_pond_dias_venc vencidos

from

fc_cartera c

where


and

c.es_establecimiento_id = 22366


ORIGEN

(NACIONAL)

ORACLE

DESTINO

(OBI)

DIFERENCIAS % DE

DIFERENCIAS # DE

ESTABLECIMIENTO

/PUNTO DE VENTA

29825 113 113 0 0,00%

30090 1364 1364 0 0,00%

36161 347 347 0 0,00%

28679 64 64 0 0,00%

29346 712 712 0 0,00%

29973 18 18 0 0,00%

30395 223 223 0 0,00%

27119 1783 1783 0 0,00%

27661 1076 1076 0 0,00%

30017 1476 1476 0 0,00%

BIBLIOGRAFÍA

ETL-TOOLS.INF. (s.f.).ETL-TOOLS.INF. Obtenido de http://etl-

tools.info/es/bi/proceso_etl.htm

GESTIOPOLIS. (s.f.).GESTIOPOLIS. Obtenido de

http://www.gestiopolis.com/canales8/ger/olap-online-analytic-processing.htm

Gracia, L. M. (21 de junio de 2010).Un poco de Java. Obtenido de

https://unpocodejava.wordpress.com/2010/06/21/talend-open-studio-

herramienta-para-transformaciones-de-datos/

Howard, P. (2009).TALEND. Obtenido de http://www.talend.com

Marco, A. (1 de noviembre de 2011).El Mundo es Open Source. Obtenido de

http://blogs.antartec.com/opensource/2011/11/primeros-pasos-en-talend/

Rouse, M. (noviembre de 2012).TECHTARGET. Obtenido de

http://searchdatacenter.techtarget.com/es/definicion/OLTP-Procesamiento-de-

Transacciones-En-Linea

SINNEXUS. (s.f.).SINNEXUS. Obtenido de

http://www.sinnexus.com/business_intelligence/datawarehouse.aspx

SINNEXUS. (s.f.).SINNEXUS. Obtenido de

http://www.sinnexus.com/business_intelligence/datamart.aspx

universidad de guayaquil facultad de ingenieria...

Documents