UNIVERSIDAD DE GUAYAQUIL FACULTAD DE INGENIERIA...
Transcript of 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
N° Descripción Pág.
Tema 2
Alcance de la investigación 2
Objeto de la investigación 3
Objetivos 4
CAPÍTULO I
MARCO TEÓRICO
N° Descripción Pág.
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
N° Descripción Pág.
2.1 Descripción de la Arquitectura 24
2.2 Análisis de los Repositorios Fuentes 26
2.3 Calidad de Datos 26
v
N° Descripción Pág.
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
N° Descripción Pág.
3.1 Titulo 59
3.2 Objetivos 59
vi
N° Descripción Pág.
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
N° Descripción Pág.
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
N° Descripción Pág.
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
N° Descripción Pág.
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
N° Descripción Pág.
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
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.
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Rango Días Vencidos
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
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Rango Edad de la 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
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
FIGURA N° 12
ESQUEMA DEL MODELO DE CARTERA VENCIDA
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
Metodología 38
FIGURA N° 13
ESQUEMA DEL MODELO DE CARTERA POR VENCER
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
La secuencia de extracción y carga DM_DIAS_X_VENCER, tomará la
información de las tablas ECORTRANGO Y ECORTTIPO_RANGO, para crear
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
La secuencia de extracción y carga DM_PLAZO_CRÉDITO, tomará la
información de las tablas ECORTRANGO Y ECORTTIPO_RANGO, para crear
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
Las secuencias de extracción y carga DM_EDAD_CARTERA, tomará la
información de las tablas ECORTRANGO Y ECORTTIPO_RANGO, para crear
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
Metodología 54
FIGURA N° 44
ESTRUCTURA DEL DATA MART
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
FIGURA N° 46
GRAFICAS DE CONSULTAS AL CUBO
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
Metodología 56
FIGURA N° 47
REPORTE DATAMART
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
FIGURA N° 48
GRAFICA DEL REPORTE
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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
Fuente: Investigación directa
Elaborado por: Panchana Jaramillo Gloria Stefania
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.
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.
Glosario de Términos 72
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
Glosario de Términos 73
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.
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
NO Cartera Mensual Mensual
Ponderado Días Vencidos BASICA NO Cartera Mensual Mensual
Cantidad de cheques
protestados
BASICA NO Cartera Mensual Mensual
Valor de los cheques
protestados
BASICA NO Cartera Mensual Mensual
Porcentaje de Cartera
Vencida
BASICA NO Cartera Mensual Mensual
Porcentaje de Cartera por
vencer
BASICA NO Cartera Mensual Mensual
Porcentaje de Cartera Normal BASICA NO Cartera Mensual Mensual
Porcentaje de Cartera Dudosa BASICA NO Cartera Mensual Mensual
Porcentaje de Cartera
Eliminada
BASICA NO Cartera Mensual Mensual
Porcentaje de Recuperación
de Cartera
BASICA NO Cartera Mensual Mensual
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
BASICA NO Cartera Mensual Mensual
cantidad de cobro (count
pagos) *
BASICA NO Cartera Mensual Mensual
cobro acumulado BASICA NO Cartera Mensual Mensual
factor ponderado cobro * DERIVA
DA
NO Cartera Mensual Mensual
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
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
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
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
/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, 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
El estado actual se lo puede comprobar leyendo los archivos
Ejecucion_Cubo_Cartera.txt y Logs_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, 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.
104 Anexos
Estado Correcto del Proceso de Creación de la tabla de hecho de Cartera
El estado actual se lo puede comprobar leyendo los archivos
Ejecucion_Cubo_Cartera.txt y Logs_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, 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.
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
El estado actual se lo puede comprobar leyendo los archivos
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.
Comportamiento Regular: Si la ejecución del proceso no tuvo inconveniente, el
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
DIMENSION CANTIDAD DE
REGISTROS
ORIGEN
CANTIDAD DE
REGISTROS DESTINO
DIM_ESTABLECIMIENTO 44092 44092
Query de Cuadratura:
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.
DIMENSION CANTIDAD DE
REGISTROS ORIGEN
CANTIDAD DE
REGISTROS DESTINO
DIM_PERIODOS 2023 2023
Query de Cuadratura:
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
DIMENSION CANTIDAD DE
REGISTROS ORIGEN
CANTIDAD DE
REGISTROS DESTINO
DIM_VENDEDOR 531 531
Query de Cuadratura:
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.
DIMENSION CANTIDAD DE
REGISTROS ORIGEN
CANTIDAD DE REGISTROS
DESTINO
DIM_ZONA 1823 1823
Query de Cuadratura:
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,
(selectz.descripcionfromecortzonazwherez.id=zo.idandzo.nivel= '2'
andzo.tipo='C')asZO_SUBZONA_COM,
138 Anexos
zo.oficialcredito_id,
ofp.razonsocialnombre_oficial,
epv.idvendedor_id,
zo.puntoventa_id,
zo.tipo,
(selectz.descripcionfromecortzonazwherez.id=zo.idandzo.nivel= '1'
andtipo='G')asZO_ZONA_GEO,
(selectz.descripcionfromecortzonazwherez.id=zo.idandzo.nivel= '2'
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.
DIMENSION CANTIDAD DE
REGISTROS ORIGEN
CANTIDAD DE
REGISTROS DESTINO
DIM_PUNTO_VENTA 26 26
Query de Cuadratura:
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.
DIMENSION CANTIDAD DE
REGISTROS ORIGEN
CANTIDAD DE
REGISTROS DESTINO
DIM_DIVISION 28 28
Query de Cuadratura:
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.
DIMENSION CANTIDAD DE
REGISTROS ORIGEN
CANTIDAD DE
REGISTROS DESTINO
DIM_DOCUMENTO 445 445
Query de Cuadratura:
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.
DIMENSION CANTIDAD DE
REGISTROS ORIGEN
CANTIDAD DE
REGISTROS DESTINO
DIM_FORMA_PAGO 40 40
Query de Cuadratura:
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
Rango Días Vencidos
Contiene los rangos para calcular los días vencidos de las ventas realizadas.
DIMENSION CANTIDAD DE
REGISTROS
CANTIDAD DE
REGISTROS
141 Anexos
ORIGEN DESTINO
DIM_RANGOS_DIAS_VENCIDOS 8 8
Query de Cuadratura:
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.
DIMENSION CANTIDAD DE
REGISTROS
ORIGEN
CANTIDAD DE
REGISTROS
DESTINO
DIM_RANGOS_DIAS_X_VENCER 12 12
Query de Cuadratura:
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= 'RPV'
union
select
0asID,'0' ASCODIGO,'NO-APLICA' ASDESCRIPCION,'NO-APLICA'
ASDESCRIPCION,0ASINICIO,0ASFIN
fromdual
orderbyCODIGO
142 Anexos
Rango Plazos de Crédito
Contiene los rangos de los plazos de crédito para las ventas realizadas.
DIMENSION CANTIDAD DE
REGISTROS
ORIGEN
CANTIDAD DE
REGISTROS
DESTINO
DIM_RANGO_PLAZO_CREDITO 8 8
Query de Cuadratura:
selectr.id,tr.codigo,tr.descripcion,r.descripcion,r.inicio,r.fin
fromecortrangor
joinecorttipo_rangotrontr.id=r.tiporango_id
wherer.tipo='OBI'
andtr.codigo= 'RPC'
union
select
0asID,'0' ASCODIGO,'NO-APLICA' ASDESCRIPCION,'NO-APLICA'
ASDESCRIPCION,0ASINICIO,0ASFIN
fromdual
orderbyCODIGO
Rango Edad de la Cartera
Contiene los rangos para calcular la edad de la cartera.
DIMENSION CANTIDAD DE
REGISTROS
ORIGEN
CANTIDAD DE
REGISTROS
DESTINO
DIM_RANGO_EDAD_CARTERA 12 12
Query de Cuadratura:
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= 'REC'
union
select
0asID,'0' ASCODIGO,'NO-APLICA' ASDESCRIPCION,'NO-APLICA'
ASDESCRIPCION,0ASINICIO,0ASFIN
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)
Query Cuadratura – Origen:
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
Query Cuadratura – Destino:
select
distinct(c.es_establecimiento_id),
c.fc_pond_dias_ventas ponderado
from
fc_cartera c
where
c.pv_puntoventa_id = 1
and c.es_establecimiento_id = 32147
CASOS DE CUADRE ORACLE
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.
Query Cuadratura – Origen:
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
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)
and p.empresa_id=1
groupby v.establecimiento_id
145 Anexos
Query Cuadratura – Destino:
select
distinct(c.es_establecimiento_id),
c.fc_venta_mens promedio
from
fc_cartera c
where
c.pv_puntoventa_id = 1
and c.es_establecimiento_id = 24765
CASOS DE CUADRE ORACLE
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
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
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id and
c.estado='E'and
p.empresa_id=1
and c.tipocartera = 'C'
and c.fechacreacion <= TO_DATE('20150430','yyyymmdd')
groupby c.puntoventa_id;
Query Cuadratura – Destino:
selectsum(c.fc_val_cart_elim)
from
fc_cartera c
where
c.pv_puntoventa_id = 1
146 Anexos
CASOS DE CUADRE ORACLE
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.
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
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id and
c.estado='D'and
p.empresa_id=1
and c.tipocartera = 'C'
and c.fechacreacion <= TO_DATE('20150430','yyyymmdd')
groupby c.puntoventa_id;
Query Cuadratura – Destino:
selectsum(c.fc_val_cart_dudosa)
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 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
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
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id and
c.estado='N'and
p.empresa_id=1
and c.tipocartera = 'C'
and c.fechacreacion <= TO_DATE('20150430','yyyymmdd')
groupby c.puntoventa_id;
Query Cuadratura – Destino:
selectsum(c.fc_val_cart_normal)
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 -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.
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
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id and
p.empresa_id=1and
d.fechavencimiento>=trunc(TO_DATE('20150430','yyyymmdd'))
and c.tipocartera = 'C'
groupby c.puntoventa_id;
Query Cuadratura – Destino:
selectsum(c.fc_val_cart_vencer)
148 Anexos
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 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.
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
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id and
p.empresa_id=1and
d.fechavencimiento<trunc(TO_DATE('20150430','yyyymmdd')) and
d.saldo<>0
and c.tipocartera = 'C'
groupby c.puntoventa_id;
Query Cuadratura – Destino:
selectsum(c.fc_val_cart_venc)
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 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.
Query Cuadratura – Origen:
select c.puntoventa_id, nvl(sum(d.valor),0) valor_cheques_protestados
from ecartcartera c
join ecartcartera_detalle d on d.cartera_id=c.id
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id and
p.empresa_id=1and
d.documento_id in(180,294) --and --de NDB y DID
and c.tipocartera = 'C'
groupby c.puntoventa_id;
Query Cuadratura – Destino:
selectsum(c.fc_val_chq_prot)
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 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.
Query Cuadratura – Origen:
select c.puntoventa_id, count(c.id) cantidad_cheques_protestados
from ecartcartera c
join ecartcartera_detalle d on d.cartera_id=c.id
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id and
p.empresa_id=1and
d.documento_id in(180,294) --and --de NDB y DID
and c.tipocartera = 'C'
groupby c.puntoventa_id;
Query Cuadratura – Destino:
select
sum(c.fc_cant_chq_prot)
from
fc_cartera c
150 Anexos
where
c.pv_puntoventa_id = 1
CASOS DE CUADRE ORACLE
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.
Query Cuadratura – Origen:
select c.establecimiento_id, count(c.id) cantidad_cobro
from ecartcartera c
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id
and p.empresa_id=1and
c.tipodocumento_id in(31,81)
and c.tipocartera = 'C'
groupby c.establecimiento_id;
Query Cuadratura – Destino:
select
distinct(c.es_establecimiento_id),
c.Fc_cantidad_Cobros cobros
from
fc_cartera c
where
c.pv_puntoventa_id = 1
and c.es_establecimiento_id = 25834
151 Anexos
CASOS DE CUADRE ORACLE
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.
Query Cuadratura – Origen:
select c.establecimiento_id, sum(d.valor) cobro_acumulado
from ecartcartera c
join ecartcartera_detalle d on d.cartera_id=c.id
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id
and p.empresa_id=1and
c.tipodocumento_id in(31,81) --and --RPG y TPT
and c.tipocartera = 'C'
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;
Query Cuadratura – Destino:
select
distinct (c.es_establecimiento_id),
c.fc_cobros_acum cobros_acumulados
from
fc_cartera c
where
c.pv_puntoventa_id = 1
and c.es_establecimiento_id = 28180
152 Anexos
CASOS DE CUADRE ORACLE
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.
Query Cuadratura – Origen:
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
join ecortpunto_venta p on p.id=c.puntoventa_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
from swissebi.eebivventas_netas v
join ecortpunto_venta p on p.id=v.puntoventa_id
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
groupby v.establecimiento_id
)
where esta = 24434
groupby esta;
153 Anexos
Query Cuadratura – Destino:
select
distinct (c.es_establecimiento_id),
c.fc_rot_cart cobros_acumulados
from
fc_cartera c
where
c.pv_puntoventa_id = 1
and c.es_establecimiento_id = 24434
CASOS DE CUADRE ORACLE
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
Query Cuadratura – Origen:
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 ecartcartera_detalle d on d.cartera_id=c.id
join ecortpunto_venta p on p.id=c.puntoventa_id
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
where c.puntoventa_id=&puntoventa_id and
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)
andtrunc(TO_DATE('20150430','yyyymmdd'))
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 ecartcartera_detalle d on d.cartera_id=c.id
join ecortpunto_venta p on p.id=c.puntoventa_id
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
where c.puntoventa_id=&puntoventa_id and
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)
andtrunc(TO_DATE('20150430','yyyymmdd'))
groupby c.establecimiento_id
) 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;
Query Cuadratura – Destino:
select
distinct (c.es_establecimiento_id),
c.Fc_Pond_Dias_Cob PDP
from
fc_cartera c
where
c.pv_puntoventa_id = 1
and
c.es_establecimiento_id = 27527
155 Anexos
CASOS DE CUADRE ORACLE
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
Query Cuadratura – Origen:
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
join ecartcartera_detalle d on d.cartera_id=c.id
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id and
p.empresa_id=1and
c.tipodocumento_id =1and--FAC
c.fechacreacion between add_months(trunc(TO_DATE('20150430','yyyymmdd')),-60)
andtrunc(TO_DATE('20150430','yyyymmdd')) and
(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
join ecartcartera_detalle d on d.cartera_id=c.id
join ecortpunto_venta p on p.id=c.puntoventa_id
where c.puntoventa_id=&puntoventa_id and
p.empresa_id=1and
c.tipodocumento_id =1and--FAC
c.fechacreacion between add_months(trunc(TO_DATE('20150430','yyyymmdd')),-60)
andtrunc(TO_DATE('20150430','yyyymmdd')) and
156 Anexos
(d.fechavencimiento-trunc(TO_DATE('20150430','yyyymmdd')))<0
groupby c.establecimiento_id
havingsum(d.saldo)>0
) y
join ecortestablecimiento e on e.id=y.establecimiento_id
groupby y.establecimiento_id, e.nombre
orderby e.nombre
;
Query Cuadratura – Destino:
select
distinct (c.es_establecimiento_id),
c.fc_pond_dias_venc vencidos
from
fc_cartera c
where
c.pv_puntoventa_id = 1
and
c.es_establecimiento_id = 22366
CASOS DE CUADRE ORACLE
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