Business Intelligence adaptado a la migración masiva de ...bibing.us.es/proyectos/abreproy/92007/fichero/TFG... · Business Intelligence adaptado a la migración masiva de datos

Business Intelligence adaptado a la migración masiva de datos. Puesta en práctica con Powercenter. Página 1

Trabajo de Fin de Grado

Ingeniería de Organización Industrial

Business Intelligence adaptado a la migración masiva de datos. Puesta en práctica con Powercenter.

Autor: Lucía Martínez Morales

Tutor: José Miguel León Blanco

Dep. de Organización Industrial y Gestión de

Empresas I

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, Septiembre 2018


Trabajo de Fin de Grado

Ingeniería de Organización Industrial

Business Intelligence adaptado a la migración masiva de datos. Puesta en práctica con Powercenter.

Autor: Lucía Martínez Morales

Tutor: José Miguel León Blanco

Dep. de Organización Industrial y Gestión de Empresas I Escuela Técnica Superior de Ingeniería Universidad de

Sevilla



Tribunal nombrado para juzgar el Trabajo de fin de grado:


Miembros: Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:


El Secretario del Tribunal



“Si puedes controlar la información, puede controlar a la gente.” Tom Clancy, novelista.


Agradecimientos Todos mis agradecimientos no cabrían en una hoja de papel. Directa e indirectamente mi trabajo ha llegado a muchas personas y solo puedo decir gracias por el apoyo que me habéis dado. A mi familia con la constancia, fuerza y optimismo que se caracteriza. A mis compañeros de trabajo, por todas las preguntas infinitas que les he ido haciendo a cada uno, gracias a vosotros he podido poco a poco ir entendiendo este gigantesco proyecto. A mis amigos y amigas que han sido mi recarga de energía para continuar y ponerle empeño y ganas al trabajo. A mi tutor José Miguel por mostrarme la atención necesaria que supone un trabajo de este calibre. Aprecio y valoro mucho su interés, ayuda y dedicación, cualidades de un profesor que se esperan, pero no siempre se encuentran. Sin duda sin vuestro apoyo, ánimo y paciencia no lo hubiera conseguido.


Resumen Las nuevas tecnologías han generado un crecimiento masivo de los datos a disposición de las empresas. Business Intelligence (BI) engloba las herramientas y prácticas que permiten recopilar, integrar, analizar e informar de grandes volúmenes de datos y así optimizar la toma de decisiones empresariales. Las herramientas de trabajo de Business Intelligence están integradas en dos grupos, el grupo Back-end, constituido por herramientas encargadas de la lógica interna, en el que analizaremos los procedimientos ETL (Extract, Transformation and Loading), encargados de la extracción, traducción y volcado de la información que proviene de multitud de fuentes a una base de datos común llamada Data Warehouse. Por otro lado, tenemos el grupo de herramientas de tipo Front-end creadas para la elaboración de informes y la visibilidad de resultados finales facilitando a la empresa la obtención de datos claros y efectivos. Abordaremos un proyecto real de migración masiva de datos entre dos bancos, en el que se explicará el flujo de trabajo completo de trasmisión de la información desde su extracción hasta la presentación de los resultados finales. Detallaremos en profundidad el trabajo llevado a cabo por la herramienta ETL “Powercenter” (PWC) en el proyecto de migración, así como todas las aplicaciones que lo acompañan. Con este trabajo comprenderemos la estructura del Business Intelligence; conoceremos varias de las herramientas que forman parte del mismo y seguiremos desde cerca el tedioso trabajo de tratamiento de datos para conseguir como objetivo la explotación de toda la información para la toma óptima de decisiones.


Objeto y alcance Este trabajo final de grado comenzó con mi entrada en el Banco Popular como programadora junior. Tras un curso de formación previo, decidí especializarme en Big Data para entender el gigantesco mundo de los datos. El Banco Popular entró en quiebra y el Banco Santander tomó posesión de éste, dando comienzo a un colosal Proyecto de Migración. Este inmenso océano de información suscitó mi curiosidad por entender cómo fluían los datos, qué procedimientos se usaban y cómo se sacaba partido de todos ellos. Hoy en día la información es un factor clave. El tratamiento de grandes volúmenes de datos necesita ser codificado para que resulte provechoso y así poder tomar decisiones efectivas. De este modo se consiguen resultados óptimos dando lugar a beneficios económicos, prioridad empresarial. En este trabajo se plantea dar una visión más cercana y comprensible sobre el tratamiento masivo de datos exponiendo de una forma clara una serie de conceptos fundamentales y técnicos para llegar a comprender e introducirnos en el mundo de los datos. Por un lado, abordaremos el concepto de “Inteligencia de Negocio” (BI), el cual engloba las actuales herramientas informáticas que dan apoyo a proyectos de este calibre. Por otro lado, profundizaremos en la herramienta PWC, donde mi participación en el proyecto se ha visto muy involucrada desarrollando softwares con PWC. Uno de estos softwares queda expuesto más adelante en el trabajo. Además, abordaremos el proyecto de Migración de forma global para ubicar la funcionalidad de esta herramienta dentro de él. Tras leer el trabajo completo se conocerá el concepto de Business Intelligence, así como nueve de las herramientas que forman parte de él junto a sus ventajas e inconvenientes y el estudio en profundidad de una de ellas. Nos familiarizaremos también con el concepto de base de datos y su importante intervención en el mundo de los mismos, comprenderemos el flujo de trabajo dentro de la migración además de todos los pasos minuciosos que se llevan a cabo para conseguir la puesta en práctica con cero errores.


Índice

1 Introducción ............................................................................................................................................. 14

1.1 Recorrido Histórico ........................................................................................................................... 14

2 Componentes del Business Intelligence ................................................................................................... 15

2.1 Sistemas de información .................................................................................................................. 16

2.2 Back-end ........................................................................................................................................... 17

2.2.1 Estructura Técnica General ....................................................................................................... 18

2.2.2 Herramientas ............................................................................................................................ 19

2.3 Front-end .......................................................................................................................................... 25

2.3.1 Herramientas ............................................................................................................................ 25

3 Proyecto en Powercenter: Control de Gestión ......................................................................................... 28

3.1 Contexto ........................................................................................................................................... 28

3.2 Conceptos Generales ........................................................................................................................ 28

3.2.1 Herramientas que participan en el proceso .............................................................................. 30

3.2.2 Ventanas de trabajo de Powercenter ....................................................................................... 35

3.2.3 Transformaciones ..................................................................................................................... 42

3.2.4 Entornos y Pruebas ................................................................................................................... 52

4 Proyecto de Migración ............................................................................................................................. 54

4.1.1 Introducción ............................................................................................................................. 54

4.1.2 Caso práctico ............................................................................................................................ 54

4.1.3 Conclusión ................................................................................................................................ 80

5 Conclusión ................................................................................................................................................ 81

6 Bibliografía ............................................................................................................................................... 82


Glosario de términos específicos

• Base de datos (BBDD): Las bases de datos son softwares especializados en el almacenamiento de datos de las empresas, de forma ordenada y categorizada por diferentes temas. Estas herramientas, permiten almacenar, ordenar y clasificar grandes cantidades de información empresarial, guardándolas en un disco duro. En la mayoría de las ocasiones, se puede mantener la seguridad de estos datos, creando claves internas de seguridad.

• Base de datos distribuida: Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas entre sí. Los datos de estas bases de datos están almacenados en distintas máquinas que integran un sistema con conexión entre ellas.

• Data Warehouse: Base de datos corporativa donde se integra y depura información de una o varias fuentes distintas, que luego serán procesadas y analizadas desde distintos puntos de vista con afinidad de perspectivas y grandes velocidades de respuesta.

• Datos estructurados: Cuando hablamos de datos estructurados nos referimos a la información que se suele encontrar en la mayoría de bases de datos. Son archivos de tipo texto que se suelen mostrar en filas y columnas con títulos. Son datos que pueden ser ordenados y procesados fácilmente por todas las herramientas de minería de datos.

• Escalabilidad: es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad

para reaccionar y adaptarse sin perder calidad, o bien manejar el crecimiento continuo de trabajo de

manera fluida, o bien para estar preparado para hacerse más grande sin perder calidad en los

servicios ofrecidos.

• Framework, entorno de trabajo o marco de trabajo: es un conjunto estandarizado de conceptos,

prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para

enfrentar y resolver nuevos problemas de índole similar.

• Integración de datos: La integración de datos es la combinación de procesos técnicos y de negocio utilizados para combinar datos de orígenes dispares en una única información valiosa y con significado. Una solución completa de integración de datos presenta datos fiables procedentes de diversos orígenes.

• Interfaz: Al hablar de una interfaz en BBDD estamos refiriéndonos a una tabla de la misma. Las BBDD se estructuran en esquemas, en los que se insertan las distintas tablas en las que podemos encontrar la información dividida en campos.

Los datos no estructurados, generalmente son datos binarios que no tienen estructura interna

identificable. Es un conglomerado masivo y desorganizado de varios objetos que no tienen valor

hasta que se identifican y almacenan de manera organizada.

• Mappings Elemento de PWC. Un mapping se define como la representación visual de un proceso de carga escrito en lenguaje SQL. Un mapping se compone de una serie de fuentes (Sources), destinos (Targets) y transformaciones que indican al servidor cómo realizar la lectura, transformación y carga de los datos.


• Mapplets: Objeto de PWC y es reutilizable, es decir, que puede ser instanciado desde muchos mappings. Los Mapplets son objetos que agrupan en su interior un conjunto de transformaciones. Por ellos mismos no realizan nada, deben usarse desde dentro de un mapping. Cuando reconocemos un proceso que se va a repetir algunas veces, es entonces cuando en lugar de crear el mapping entero, crearemos un mapplet con esta parte que va a ser reutilizable. En este momento nos aparecerá en nuestra sub-carpeta de mapplets y lo podremos utilizar en todos los mappings de nuestra carpeta. Si vemos que ese objeto, además de interesante para otros muchos procesos, o lo que es lo mismo, estamos desarrollando un proceso que se utiliza a nivel corporativo, lo que haremos es crear el Mapplet en una carpeta compartida y realizar Shortcuts a él desde la nuestra.

• Query. Pregunta a la base de datos en lenguaje SQL. En PWC las queries van parametrizadas, su desarrollo se encuentra en la tabla Par_parent propia del proyecto de migración.

• Scripts: Archivo de comandos.

• SELECT: Comando SQL para acceder a los datos de las tablas de una base de datos.

• Servidores: Ordenadores principales en los que se aloja el software que da servicio a otros ordenadores.

• Session: Este objeto hace referencia a un conjunto de instrucciones que hacen posible la ejecución de los workflows o procesos, desarrollados en PWC. Elemento que se encuentra en la ventana del workflow monitor que veremos más adelante.

• Shortcuts (accesos directos): El uso de shortcuts incrementa tanto el rendimiento en desarrollo como sobre todo el mantenimiento posterior. Un shortcut es un enlace a un objeto compartido, de modo que existe un único objeto original y cualquier cambio se replica automáticamente a todas las instancias que tengamos de él. El uso típico de shortcuts es para definir corporativamente Sources y Targets o bien para compartir transformaciones reutilizables o mapplets desde carpetas compartidas

• STAGING: Se trata de las primeras cargas de datos de una herramienta ETL en el data warehouse en el que se validan los datos para una correcta carga de fichero.

• Tabla de base de datos; Par_parent: En PWC existe una tabla genérica de la base de datos donde se encuentran todos los parámetros de los procesos, divididos por el nombre del proceso o workflow, que se situará en el campo NO_ID_WKFETL. En el campo NO_ID_PARENTR se encuentra el nombre de los parámetros y en el campo VA_PARENTR el valor correspondiente. Estos son los campos principales. Otro campo también característico de esta tabla es PER_EJECPROETL y según la periodicidad de las ejecuciones puede tener el valor de 1 diario, 2 mensual o 3 esporádico.

Ilustración 1Tabla de base de datos PAR_PARENT_PROCETL


• Terminal: Aplicación que interactúa con una computadora por medio de comandos en el sistema operativo.

• Transformación: Objeto de Powercenter para la creación de procesos con lo que se manipula y traspasa el flujo de datos.


1 Introducción

Esta introducción se centra en mostrar el concepto de Business Intelligence desde una visión amplia, es importante conocer las raíces del concepto años atrás, como ha ido avanzando. Del mismo modo discutiremos sobre el valor del Business Intelligence actual, el porqué de su importancia y necesidad para muchas empresas.

1.1 Recorrido Histórico Haremos un breve resumen de la trayectoria que ha seguido el concepto de Business Intelligence junto a las definiciones de varios autores. Incluiremos algunos hitos de la historia de la tecnología que ayudó en el avance del BI. El término de Business Intelligence no es tan reciente como creemos. A finales de los años 50 Hans Peter Luhn, investigador de la gran consultora IBM, publicó un artículo enfocado al estudio de los datos llamado “A Business Intelligence System” [1] definiendo el término como “la habilidad de aprender las relaciones de hechos presentados de forma que guíen las acciones hacia una meta deseada”. Una descripción básica pero ya por entonces bastante dirigida a la idea actual. Una década después nace el concepto de base de datos de la mano de aplicaciones empresariales como SAP (Alemania, 1972) y JD Edwards (Denver, 1977). El desarrollo de estos softwares fue un paso muy importante en el desarrollo del BI. Estas aplicaciones hicieran posible que la carga de información en las BBDD aumentara exponencialmente. Aunque el acceso era aún complejo, tedioso y poco eficaz. La revolución de los ordenadores da un empujón gigantesco al mundo de la tecnología, las bases de datos toman un papel muy importante en el entorno técnico/informático, además el lenguaje SQL, lenguaje de acceso a las bases de datos, se estandariza. La creación del concepto de data warehouse y la aparición de los primeros reporting (informes de resultados) supone un avance para el BI pero aun así no basta con potentes bases de datos, continua la ausencia de aplicaciones de interpretación de datos. En esta época la empresa líder Microsoft pone a disposición de sus clientes la potente herramienta de análisis de datos, Excel (1985). A finales de los años 80 y todo el recorrido por los 90, vuelve a resurgir el BI, Business Intelligence. Época determinante en el desarrollo de las tecnologías actuales. Se crean múltiples aplicaciones de BI ofreciendo un mejor acceso a la base de datos, pero aun así todavía son incapaces de analizar grandes volúmenes de datos de forma rápida. Además, cuenta con limitaciones como el número de fuente de datos disponibles y un precio demasiado elevado. Por otra parte, toda la información descentralizada empieza a tomar forma y aparecen las BBDD distribuidas. Howard Dresner, analista de la empresa consultora Gartner añadió nuevos conceptos a la idea de BI para la mejora de la toma de decisiones de la empresa. Define BI como “conceptos y métodos para mejorar la toma de decisiones empresariales mediante el uso de sistemas de soporte basados en hechos”. [2] La segunda época de auge del BI, comienza con el nuevo milenio donde las empresas empiezan a consolidar las plataformas de BBDD agrupándose en algunas como Oracle, SAP, IBM, Microsoft, etc. Existe una capacidad de almacenamiento masivo y alta velocidad de respuesta. Las empresas comienzan a hacer un uso eficaz de toda la información almacenada ya que es indispensable analizarla y categorizarla de forma rápida y profunda. BI comienza a ser una pieza de valor en la toma de decisiones de las empresas. Hasta día de hoy ha sido una revolución el mundo de los datos y de manera rápida seguimos avanzando en la elaboración de herramientas inteligentes que sean capaces de sacar el mayor partido de ellos.


Hoy en día, la tendencia más importante de BI se refiere a los conceptos de Big Data. Big Data en sí se basa en la posibilidad de usar herramientas de BI y capacidades analíticas para extraer información de cantidades increíblemente enormes de datos que se generan cada día por nuestros empleados, clientes, usuarios de plataformas tales como redes sociales y de trabajo, foros, aplicaciones móviles, información de GPS, etc.

2 Componentes del Business Intelligence

Las metodologías usadas en el Business Intelligence están divididas en dos grandes grupos relacionados, Back-end y Front-end. Primero se encuentra el Back-end que dispone de las tecnologías de ETL (extracción, transformación y carga). Posteriormente, aunque en algunos casos hay tecnologías que unifican ambas fases, está el Front-end, aplicaciones de presentación de resultados para el usuario final, el cliente. Empezaremos describiendo la primera fase en la que definimos la estructura técnica general y nombraremos algunas de las herramientas junto a sus características. Haremos una comparativa utilizando las propiedades de las herramientas de Back-end más comunes. Veremos las tecnologías de reporting correspondientes a la fase de Front-end, dando al cliente una presentación de los resultados obtenidos en la fase anterior. Esta fase es menos compleja, pero de igual importancia, será un punto imprescindible para la toma de decisiones. La estructura que conocemos hoy en día del BI la forman 3 fases, la recopilación de toda la información generada por los usuarios de estudio, como son los clientes de un banco, a través de los sistemas de información que veremos a continuación. Aunque teóricamente no corresponda al cuadro BI, es indudablemente un requisito fundamental que debemos tener en cuenta y práctica. Posteriormente como punto principal en este proyecto es el proceso de tratamiento de los datos recibidos, las herramientas ETL nos ayudan al desarrollo de los procesos, al acceso de una gran variedad de distintas bases de datos, proporciona la gestión integrada del data warehouse junto al almacenamiento selectivo del data mart, etc. Finalizamos nuestro estudio con las aplicaciones de reporting. [3][8]

1958- Los principios del concepto de BI. Publicación de Peter Luhn “A Business Intelligence System”

70’s- Nace el concepto de Base de Datos y junto a él numerosas aplicaciones como SAP y JD Edwards

1985- Excel 1986- Se estandariza el lenguaje SQL. Creación del DWH y los reporting

90’s- Mejoras en las aplicaciones. Aparición de las BBDD distribuidas.

Siglo XXI- Se consolidan las plataformas de BBDD. La capacidad de almacenamiento masivo y la velocidad de búsqueda aumentan. Comienza la importancia del estudio de la información

Actualidad- Big Data, uno de los motores principales del BI

Ilustración 2 Línea en el tiempo del BI (elaboración propia)


Fuente 1 LOS SISTEMAS DE INTELIGENCIA DE NEGOCIO COMO SOPORTE A LOS PROCESOS DE TOMA DE DECISIONES EN LAS ORGANIZACIONES. Universidad de Sevilla

Ilustración 3 Estructura del BI.

2.1 Sistemas de información

La estructura del Business Intelligence tiene dos apartados claramente visibles, explicados anteriormente, Back-end y Front-end. Aunque teóricamente los sistemas de información no pertenezcan al entorno especifico de Business Intelligence si lo hacen en el global. Los sistemas de información juegan un papel muy importante en la organización y planificación de la información, es una pieza fundamental. Los SI se conocen como el conjunto de recursos de la empresa para hacer posible un objetivo concreto. Dichos elementos son, el Hardware, equipos físicos para almacenar y procesar datos y el Software, para el tratamiento y extracción de la información, el cual debe ser eficaz, devolviendo la información requerida y eficiente, usando los recursos mínimos. Además del personal de trabajo. Concretamente hablaremos de los softwares empresariales; elementos paralelos y complementarios a las herramientas de Back y Front-end. Su utilidad es diversa y sirven para multitud de tareas, pueden usarse en su totalidad o parcialmente según nuestros intereses. Vamos a comentar tres tipos de sistemas de información, los ERP, los CRM y HCM. [4][5] ERP: Los sistemas ERP son sistemas integrales de gestión, es decir, se caracterizan por trabajar con diferentes sectores de la empresa como producción, ventas, logística, contabilidad, etc, en una única aplicación informática. El objetivo principal del ERP es llevar a cabo una planificación óptima unificando toda la información de la empresa y tenerla disponible en cada momento, buscando la comunicación continua para


un buen desarrollo y una optimización en el manejo de la información. Además, también mantiene una unión con los clientes y proveedores favoreciendo la automatización de muchos procesos. Para conseguir un buen resultado de la aplicación es importante que la empresa disponga de una buena base de datos donde guardar toda la información, como Oracle, IBM, SAP o SQL Server. Los ERP permiten ser integrados con casi cualquier sistema existente, de modo que son capaces de obtener información de un Excel, Access o de devolverla de la misma forma. CRM:

El sistema CRM, Customer Relationship Management, o Gestión de las relaciones con clientes, es una aplicación dirigida a la gestión de las relaciones con los clientes que nos ayuda a gestionar y monitorizar toda la información que hay en nuestra empresa. Recopila los datos de las gestiones comerciales manteniendo un histórico detallado, agrupando en una única Base de Datos todas las interacciones entre los clientes y la empresa. CRM almacena información sobre todos sus clientes desde nombres, direcciones, números telefónicos, etc., hasta sus actividades y puntos de contacto con la empresa, que incluyen visitas a sitios web, llamadas telefónicas, correos electrónicos y más. De esta forma llegamos a entender sus necesidades y anticiparnos a ellas. Un CRM gestiona normalmente tres áreas básicas: la gestión comercial, el marketing y el servicio postventa o de atención al cliente. Ésta última potencia la fidelización, cualidad muy importante en términos de ventas. La herramienta CRM y la orientación al cliente proporcionan resultados demostrables, tanto por disponer de una gestión comercial estructurada y que potencia la productividad en las ventas como por ofrecer un conocimiento profundo del cliente que permite plantear campañas de marketing más efectivas. Unos de los softwares CRM más conocidos son Salesforce, Base, Microsoft Dynamics, Salesnet, Netsuite, AllProWebTools y Sugar.

HCM:

Human Capital Management es la aplicación que se encarga de los recursos humanos. Un HCM se encarga

de la gestión de talentos (personas a las que promocionar, o no), de controlar la productividad de los

empleados y de las habituales tareas de contratación, despido, etc. Una de las misiones principales del HCM

es la de automatizar en todo lo posible los procesos relacionados con el personal, para que el departamento

de recursos humanos tenga la mayor eficiencia posible.

2.2 Back-end

Actualmente, las compañías de gran tamaño se encuentran con grandes problemas de integración de datos por el creciente volumen de estos, el incremento de sistemas a interconectar, y la creciente necesidad de limpieza y transformación de datos. Por esta razón aparecieron las herramientas tipo ETL, que permiten integrar todos estos procesos bajo una única herramienta corporativa que además de realizar el trabajo de movimiento de datos, proporcionan otras muchas funcionalidades. Back-end hace referencia al código interno de las herramientas, a la funcionalidad. Para diseño web, páginas web, el Back-end es el código HTML que hace posible las interactuaciones entre el usuario y el pc, Front-end es la página física que vemos en nuestras búsquedas en internet. Con esto quiero decir que no es un término específico de esta tecnología, sino que es global. En nuestro caso Back-end es un conjunto de herramientas de tratamiento de datos a las que llamamos tecnologías ETL, (Extract, Transform & Load) extracción, transformación y carga de datos.

https://getbase.com/


Al final de este trabajo abordaremos un caso un caso real asociado al sector bancario con un de las herramientas ETL, Powercenter. Aunque no solo están destinadas a trabajar en este sector. Las tecnologías ETL abarcan muchos campos por no decir todos. El tratamiento de datos es válido para cualquier empresa que tenga grandes volúmenes de información. Estos procesos son automáticos y programables además contienen un riguroso control de errores para asegurar la fiabilidad de los datos cargados. Primero vamos a explicar el esqueleto de este tipo de herramientas, algunas siguen el esquema rigurosamente otras tienen algunas variaciones, pero la idea en general es muy parecida. Tras tener claro cómo funciona la estructura general de las herramientas de tratamiento de dato, ETL, hablaremos de alguna de ellas y haremos una comparativa con una serie de características comunes. [6][7]

2.2.1 Estructura Técnica General

Progreso de las herramientas ETL

Los Procesos ETL comenzaron codificándose a mano, herramientas ETL que se desarrollan internamente en Perl, COBOL, C y PL / SQL para extraer datos de múltiples archivos de origen, transformar los datos y cargar las bases de datos de destino. Los programas escritos con este método fueron largos y difíciles de documentar. Las herramientas ETL codificadas a mano tienen la ventaja de que los datos creados se pueden gestionar directamente y le dan flexibilidad al desarrollador para manipular las nuevas necesidades. Sin embargo, también existen limitaciones como atender los continuos cambios en los altos volúmenes de datos generados a través de diversas fuentes, los programas necesitan ser modificados frecuentemente lo que causa una carga en el proyecto en general. Además, los cambios realizados en los datos también necesitan tablas que se modifiquen, que se codifican a mano y que se almacenen por separado, por lo que los cambios se realizan de forma manual. Dado que las herramientas codificadas a mano implican gastos generales y su ejecución es lenta, muchos proveedores desarrollaron herramientas que comenzaron con extracciones simples a la base de datos de destino. Estas son las herramientas de ETL de hoy que proporcionan características de transformación, admiten múltiples bases de datos de entrada o salida o archivos planos, diseños multidimensionales, generación de claves sustitutas y varias funciones de transformación. Con el tiempo una de las grandes mejoras es la agilidad de aprendizaje que proporcionan las herramientas, permiten al desarrollador trabajar sin necesidad de capacitación. Estas herramientas también tienen características tales como monitoreo, programación, carga masiva, etc.

Estructura actual de las herramientas ETL

La estructura general de las distintas herramientas de ETL sigue un mismo esquema. El origen del proceso comienza con la recopilación de los datos provenientes de cualquier sistema o archivo proveniente de la fuente de datos que almacene o contenga datos de interés. El proceso de extracción, transformación y carga (ETL) representa todos los pasos necesarios para mover

datos desde diferentes fuentes de datos hasta una data warehouse integrado.


El primer paso es la extracción, o recuperación de la información de las fuentes de datos. Este proceso recupera los datos físicamente de las distintas fuentes de información. En este momento se cuenta con datos en bruto. El segundo paso es transformar los datos y prepararlos para cargarlos en el data warehouse. Los procedimientos de transformación incluyen la adaptación del tipo de dato y nombres de campos, la eliminación de datos erróneos, la corrección de errores tipográficos, el relleno de datos incompletos, etc. para la creación de tablas de agregación con mejor rendimiento.

El tercer y último paso es cargar los datos en el formato adecuado y de manera homogénea en el Data

warehouse.

Este proceso asegura la unificación de datos provenientes de diferentes orígenes en la base de datos, data

warehouse. Las herramientas ETL suelen guardas la información trasformada en tablas relacionales con

esquemas especiales.

2.2.2 Herramientas

Existen multitud de herramientas para desarrollar los procesos de la Fase I del Business Intelligence. Nombraremos varias junto a sus características más destacadas. Estas herramientas son imprescindibles en las empresas para poder traducir grandes volúmenes de datos en información efectiva.

Empresa Herramienta de trabajo

Enlaces

IBM Information Server

[11]Microsoft - SQL Server Integrated Services: https://www.ibm.com/analytics/information-server

Informatica Powercenter

[12]Informatica–Powercenter: https://www.informatica.com/es/products/data-integration/Powercenter.html

Talend Open Studio for Data Integration

[13]Talend - Open Studio for Data Integration: https://es.talend.com/products/talend-open-studio/

Oracle Data Integrator

[14]Oracle-Data Integrator: http://www.oracle.com/technetwork/middleware/data-integrator/overview/index.html

Microsoft SQL Server Integrated Services

[15]Microsoft. SQL Server 2012 Le Ofrece Características Más Avanzadas. 2012.

SAS Data Integration Studio

[16]SAS - Data Integration Studio: http://support.sas.com/software/products/etls/index.html [17]SAS. SAS Data Integration Studio 4.2 User’s Guide. ISBN 978-1-59047-960-5. 2009

Kettle Pentaho Data Integration

[18]Kettle - Pentaho Data Integration: https://www.hitachivantara.com/en-us/products/big-data-integration-analytics/pentaho-data-integration.html

https://www.ibm.com/analytics/information-server

https://es.talend.com/products/talend-open-studio/

http://www.oracle.com/technetwork/middleware/data-integrator/overview/index.html


http://support.sas.com/software/products/etls/index.html

https://www.hitachivantara.com/en-us/products/big-data-integration-analytics/pentaho-data-integration.html



CloverETL CloverETL

[19]Clover - CloverETL https://www.cloveretl.com/

Tabla 1 Herramientas de Back-end (elaboración propia)

Comenzaremos desarrollando brevemente cada herramienta, dando una idea general. Posteriormente haremos una comparativa siguiendo unas series de características concretas y comunes para la mayoría de las herramientas. Nos ayudará a entender mejor las relaciones y diferencias entre ellas. [9][10]

Information Server La herramienta de IBM, Information Server gestiona multitud de datos a través de distintas plataformas. [11] Sus principales características:

• Carece de una separación modular, desfavoreciendo la organización interna de los archivos de la herramienta.

• Trabaja a tiempo real, proporciona conexiones entre el origen de datos y sus aplicaciones.

• Transformar información en valor de forma rápida gracias a la implementación de una interfaz gráfica, amigable y fácil de usar.

• Sostiene una volumetría de datos considerable.

• Los usuarios no técnicos puedan consumir rápidamente datos, en modo autoservicio, cuando y donde lo necesiten, sin necesidad de recurrir a los perfiles más especializados de IT

Powercenter Powercenter es una de una de las herramientas líderes en este segmento del mercado, ETL, de la empresa Informática. Responde perfectamente a todas las funcionalidades requeridas. Respalda todo el ciclo de vida de integración de datos. Cuenta con un abanico de funcionalidades que hacen posible su desarrollo óptimo y eficaz. Es una herramienta muy segura, estable y con buen rendimiento, proporciona la información a tiempo real. [12] Sus principales características son:

• Aumenta la productividad con la gestión de meta-datos.

• Identifica proactivamente riegos de integración de datos.

• Carece de un sistema de corrección de sintaxis.

• Cuenta con un minucioso control de fallos.

• Refuerza las operaciones en tiempo real.

• Cabe recordar que exige un buen nivel de conocimiento de SQL para realizar desarrollos y perfiles experimentados para su correcta instalación.

• Precio muy elevado de licencias.

https://www.cloveretl.com/


Open Studio for Data Integration Open Studio es una herramienta de integración de datos open-Source de la compañía Talent. Creada en 2006, es menos popular que algunas otras como Pentaho aun así conocida y utilizada por un gran público. [13] Sus principales características son:

• Capaz de leer metadatos de forma sencilla gracias a los paquetes empresariales.

• Proporciona un número de conexiones nativas a las diversas bases de datos muy alto.

• Genera código Java que puede ser ejecutado en el servidor.

• Permite planificar tareas.

• A partir de su propia interfaz gráfica permite escribir consultas SQL personalizadas y Java.

Data Integrator (Oracle) Data Integrator es una herramienta de tratamiento de datos de la compañía Oracle. Maneja multitud de necesidades empresariales incluyendo las cargas masivas como se da en el caso de la migración. [14] Sus principales características son:

• Transferencia en masa de datos rápida y manejo de transformaciones complejas de datos

• No cuenta con una separación modular desfavoreciendo la organización de los procesos a ejecutar.

• Proporciona una accesibilidad fácilmente trabajable.

• Permite operar y desplegar componentes que no forman parte del entorno Oracle y sobre múltiples servidores de aplicaciones.

• Diseñado con XML. SQL Server Integrated Services SQL Server Integration Services, es una de las herramientas de Microsoft elaborada para el tratamiento e integración de datos. SQL Server proporciona tres tipos de componentes de flujo de datos: orígenes, transformaciones y destinos. Los orígenes extraen datos de almacenes de datos tales como tablas y vistas en bases de datos relacionales, archivos y bases de datos de Analysis Services. Las transformaciones modifican, resumen y limpian datos. Los destinos cargan datos en almacenes de datos o crean conjuntos de datos almacenados en la memoria. [15] Sus características principales son:

• Integration Services puede extraer y transformar datos de diversos orígenes como archivos de datos XML, archivos planos y orígenes de datos relacionales y, después, cargar los datos en uno o varios destinos.

• No cuenta con una corrección de sintaxis automática.

• A falta de separación modular.

• Se caracteriza por una usabilidad sencilla.

• Trabaja únicamente con un sistema operativo, Windows.

• Realiza operaciones de flujo de datos tales como operaciones de FTP.


• Incluye transformaciones para limpiar, agregar, combinar y copiar datos. Administrar la ejecución y almacenamiento de paquetes.

Data Integration Studio (SAS) Data Integration Studio proporciona, una poderosa herramienta de diseño visual para crear, implementar y gestionar procesos de integración de datos independientemente de las fuentes de datos, aplicaciones o plataformas. [16][17] Sus características principales son:

• Extrae, transforma y carga datos de toda la empresa para crear informes consistentes y precisos.

• Proporciona un acceso virtual a estructuras de bases de datos, aplicaciones ERP, archivos heredados, texto, XML, y una multitud de otras fuentes.

• Fácil acceso.

• Supervisa los datos para crear información consistente y confiable.

• Tiene la capacidad de migrar, sincronizar y replicar datos entre diferentes sistemas operativos y fuentes de datos.

• Consulta y usa datos en sistemas múltiples sin el movimiento físico de los datos de origen.

• Cuenta con un entorno de usuarios múltiples, fácil de administrar, permite la colaboración en grandes proyectos empresariales con procesos repetibles que se comparten fácilmente.

• Visualiza y comprende fácilmente los metadatos empresariales y sus procesos de integración de datos.

Pentaho Data Integration Es una herramienta de integración de datos open-Source comercial que dispone de un producto llamado Kettle especializado en integración de datos. Diseñado con una interface gráfica salida y fácil de usar. Lanzado en 2001, tiene una comunidad de 13.500 usuarios registrados. [10][18] Sus principales características son:

• Es un motor de Java autónomo que trata procesos y tareas para mover datos de entre varias bases de datos diferentes y ficheros.

• Permite integrar datos de múltiples fuentes.

• No cuenta con búsqueda de errores ni con un corrector automático.

• A falta de separación modular.

• Carece de la posibilidad de reutilizar elementos, aumentando el número de horas trabajadas.

• Proporciona una facilidad en comparación con el resto de las herramientas para integrar fuente de datos con base de datos.

• Permite programar la ejecución de tareas.

• A partir de su propia interfaz gráfica, permite escribir consultas SQL personalizadas y Javascript.


CloverETL CloverETL es un paquete de software de integración de datos puro que permite un desarrollo rápido y capacidades empresariales disponibles. Le permite desarrollar, implementar y automatizar de manera eficiente transformaciones de datos transparentes, desde cargas de archivos a bases de datos. [19] Sus principales características son:

• Combinan datos desde una variedad de fuentes a una o más aplicaciones de destino (informes, análisis, inteligencia comercial)

• Proporciona una combinación efectiva de diseño visual rápido de transformaciones y flujos de trabajo.

• No cuenta con un mecanismo de búsqueda de errores.

• No cuenta con la posibilidad de reutilizar elementos de la propia herramienta, ralentizando el trabajo.

• Fácil respuesta a los cambios en las estructuras de datos sin la necesidad de codificar.

• Cuenta con capacidades de personalización de codificación completa y automatización.

• Automatiza el movimiento entre datos de distintas bases de datos, archivos y API de servicios web.

• Interfaz de usuario sencilla y espacio reducido. Facilidad en su uso.

• No dispone de aplicaciones empresariales capaces de leer metadatos de forma sencilla y rápida. Características comunes Una vez visto una breve introducción de cada una de las herramientas vamos a describir un poco más al detalle las cualidades que caracterizan las herramientas propias de este sector, ETL. Dentro de cada definición puntualizaremos la herramienta correspondiente en caso de que sobresalga al resto.

Sistemas operativos: Los sistemas operativos hacen referencia a los distintos softwares, como Windows, Linux, Solaris, etc., que sostienen el hardware de los sistemas informáticos. SQL Server es la herramienta que menos se adapta a los distintos sistemas operativos, cuenta únicamente con Windows. Por otro lado, Data Integrator llega a sostener hasta ocho plataformas distintas, un punto muy a favor para la herramienta en esta comparativa. Facilidad de uso: La cercanía de la herramienta con el cliente es muy importante. La facilidad de aprendizaje reduce las horas invertidas en la enseñanza a nuevos usuarios, simplifica los errores futuros y existe mayor posibilidad de remplazos en caso de que se necesiten. La mayoría de las herramientas se intentar hacer sencillas y de fácil acceso. Data Integrator de Oracle y SAS además de SQL Server se caracterizan por ser de las más accesibles, aunque en general todas cuentan con esta cualidad. Reusabilidad: La posibilidad de reutilizar elementos de nuestra herramienta reduce horas de trabajo en acciones repetitivas. Todas cuentan con esta característica. Nuestra herramienta de uso, Powercenter, cuenta con elementos reutilizables como mapplets, sesiones, shortcuts, etc. Veremos más adelante las explicaciones de cada uno de ellos. Búsqueda de errores:


En el desarrollo se cometen fallos. La búsqueda de errores o debugging recorre todo el código interno hasta encontrar el fallo, facilitando la búsqueda independiente por parte de los usuarios. Únicamente Pentaho y CloverETL son los que no cuentan con la búsqueda de errores. Correcciones automáticas: Pentaho, SQL Server y Powercenter no cuentan con correcciones de sintaxis. En el caso de Powercenter solo corrige las sintaxis de estructuras propias de su lenguaje. El resto de las herramientas sí disponen de esta propiedad. Validación en la compilación: Otra característica en cuanto a los errores con la que cuentan todas y en especial la herramienta de Powercenter es la visibilidad de los errores en una pantalla, identificando en la compilación lo que ha ido mal y porque no ejecuta el proceso correctamente. Separación modular: La separación de la aplicación en distintos módulos ayuda a la organización. Informatica, Talend, SAS y CloverETL cuentan con ella mientras que Oracle Data Integrator, IBM Information center, SQL Server y Pentaho, no. Posteriormente veremos los distintos módulos de PWC. Mecanismo de datos:

Los datos cambian cuando se extrae y se transforma. Para reconocer los cambios modificados en una revisión comparativa de las herramientas de extracción, transformación y carga, IBM Information Center utiliza desencadenantes y los registros y las entradas de diario para reconocer los datos modificados, mientras que Informatica lo hace solo con los registros y diarios. Talend y CloverETL lo hacen con el encolamiento de mensajes y desencadenadores de bases de datos Oracle Data Integrator y SQL Server no deja opciones para descuidar tales cambios ya que incorpora las tres técnicas. Pentaho se destaca en este ya que no proporciona esta instalación. Unir las tablas como fuente:

Se pueden unir dos tablas de manera gráfica, permitiendo que la base de datos ejecute la unión en lugar de dejar que la herramienta ETL se una a las tablas. Informatica Powercenter, SQL Server Integration, Pentaho y CloverETL no proporcionan esto, que es un gran inconveniente. Ayuda mediante e-mail: Todas las herramientas proporcionan la información necesaria para mantener un contacto sobre cualquier asunto. Conexiones

Las herramientas admiten una serie de conexiones nativas, Informática Powercenter proporciona las conexiones nativas máximas a las diversas fuentes de bases de datos, por lo que la extracción de estas fuentes se vuelve mucho más eficiente. No faltan IBM Information Center y Talend Open Studio, ya que sigue de cerca a Informática. SQL Server se demora aquí ya que solo puede proporcionar cuatro tipos de conexiones nativas. Conexiones a tiempo real:

Como hemos visto en el punto anterior y puntualizando en conexiones a tiempo real, Powercenter vuelve a ser una de las más valoradas en este sentido. Programación: Todas las herramientas actuales soportan la funcionalidad de programación porque se considera una necesidad básica para que la herramienta ETL programe trabajos.


Transformación de los datos: Es posible transformar datos desnormalizados a normalizados y viceversa. Facilidad en todas las herramientas. Divisiones: Las divisiones pueden referirse a multitud de particiones en la herramienta, por ejemplo, en códigos de producto, para determinar en qué máquina o procesador deben procesarse los datos. Talend y Oracle no permiten que la partición tenga lugar, todos los demás lo hacen. Aplicaciones empresariales:

Esta cualidad hace referencia al número de paquetes /aplicaciones empresariales que tiene la herramienta y que son capaces de leer metadatos de forma sencilla y rápida. Talend puede leer 9 que es el máximo seguido por IBM Information Server y Oracle Data Integrator que puede leer 8, seguido de cerca por Informatica Powercenter que puede leer 7 y el más pobre de todos es CloverETL y que puede leer 0 paquetes de aplicaciones.

2.3 Front-end

El proceso final consta de una serie de aplicaciones para la presentación de la información obtenida. Diferentes formas que tendrán los usuarios finales de ver la información como por ejemplo en reportes, cuadros de mando, informes, entre otros.

2.3.1 Herramientas Las herramientas del Business Inteligence en referencia al tratamiento de datos pueden ser mixtas, es decir, abarcar ambos ámbitos el de desarrollo, back-end, y el de presentación del resultado, front-end. En nuestro caso en el Banco Popular debido a la masividad de datos con la que contamos tenemos a nuestra disposición la herramienta de Powercenter especialista en el tratamiento de datos, muy potente y líder en el mercado y por otro lado Microstrategy, para la elaboración de informes. MicroStrategy es una compañía fundada en Virginia, EEUU (1989) que nos ofrece un software llamado OLAP relacional o ROLAP de inteligencia de negocio y elaboración de informes. Trabaja con base de datos relacionales, se caracterizan por ser tablas de nombre único, formadas por campos (columnas) y registros (filas), la relación entre tablas es por medio de las claves primarias, clave principal de un registro que lo hace único. Este tipo de BBDD son las que nosotros usamos en el Banco y más comúnmente utilizadas por multitud de compañías. Parte de la fuerza de Microstrategy radica en que su producto está formado por una plataforma integrada de herramientas de Inteligencia de negocio, y no por diferentes productos aislados agregados. Este producto les aporta a los usuarios la capacidad de explorar los datos de forma intuitiva y totalmente visual, siendo en sí misma una herramienta orientada a facilitar la toma de decisiones y búsqueda de oportunidades de negocio. MicroStrategy es alimentada por nuestra base de datos data warehouse de los procesos ETL anteriormente ejecutados. Por otro lado, la herramienta MicroStrategy cuenta con su base de datos propia, repositorio que almacena la definición de los objetos de MicroStrategy y la información sobre el modelo de base de datos explotado. Un servidor analítico optimizado para el reporting empresarial y para el análisis OLAP. La aplicación de MicroStrategy Desktop, en entorno Windows, que proporciona un completo abanico de funciones analíticas diseñadas para facilitar el desarrollo de informes. Y finalmente con un entorno web

interactivo para la ejecución de informes y análisis.


Ilustración 4 Elementos de la herramienta MicroStrategy (elaboración propia)

MicroStrategy Desktop es la aplicación usada en el Banco Santander para la elaboración de informes. Entendemos informe como un objeto de MicroStrategy que representa una petición de un conjunto específico de datos con formato procedentes del data Warehouse. Los informes son la base y el objetivo de Business Intelligence. [20][21] Permiten a los usuarios recopilar conocimientos sobre el negocio mediante análisis de datos. Las distintas partes de un informe son:

• Los hechos son uno de los componentes esenciales para crear un proyecto. Un hecho tiene dos

características: es numérico y agregable. Los hechos son objetos creados por usuarios de MicroStrategy y compartidos entre ellos. Relacionan valores de datos numéricos del Data Warehouse con el entorno de informes. Se basan en columnas físicas del data Warehouse. Cuando se solicita información sobre hechos para un informe en MicroStrategy 7i, se accede a la columna en cuestión para recuperar los datos que se necesiten.

• Los atributos se utilizan principalmente para agrupar o agregar hechos. Representan entidades del modelo de negocio y normalmente vienen identificados por un ID de columna único en el Data Warehouse. El atributo actúa como un encabezado de columna y los datos que aparecen en la siguiente tabla son elementos. Un elemento es un valor único (una fila) que definen y componen el atributo. Por ejemplo, los elementos New York, Baltimore y Boston están agrupados bajo el atributo Población.

Fuente 2 Guía avanzada de elaboración de informes

Ilustración 5 Ejemplo de atributos, elementos y hechos


• Los filtros determinan la cantidad de datos que se utiliza para generar los informes. Un filtro especifica las condiciones que deben cumplir los datos para su inclusión en los resultados del informe. Es una manera sencilla de responder a preguntas de negocio simples o complejas.

• Los indicadores son componentes de informe que permiten realizar cálculos analíticos con los datos del Warehouse. Representan los cálculos que se deben llevar a cabo con los datos almacenados en la base de datos y se asemejan a las fórmulas de software de las hojas de cálculo.

Un ejemplo de informe elaborado con la herramienta MicroStrategy es:

Fuente 3 Microstrategy

Ilustración 6 Informe de cumplimiento


3 Proyecto en Powercenter: Control de Gestión

3.1 Contexto El 7 de junio de 2017 se clausuró la compra definitiva del Banco Popular por parte del Banco Santander. La decisión final fue tomada en Bruselas por la Comisión Europea dando como válido la compra sin riesgo alguno para la competencia al no superar las cuotas de mercado en un 25 %. Entra en acción el Proyecto de Migración. El objetivo es entregar al Banco Santander toda la información proveniente de los clientes del Banco Popular. La labor por seguir es conseguir tratar toda la información recibida por parte del Banco Popular para lograr presentar al Banco Santander una serie de ficheros que les ayuden a toma de decisiones futuras.

3.2 Conceptos Generales El colosal Proyecto de Migración cuenta con distintos flujos de trabajo que facilitan la tarea de migración. Nos situamos en el flujo de trabajo denominado Work Stream Control de Gestión (WSCDG). El objetivo de éste es migrar todos los datos de los clientes que tengan relación con la información requerida para construir la cuenta resultado, en resumidas cuentas, situación financiera del cliente. Nuestro flujo de trabajo está dividido en tres apartados principales, extracción, transformación y carga. Siguiendo el mismo procedimiento que las herramientas ETL vistas con anterioridad, a diferencia de que en este caso combinamos distintas herramientas. Powercenter participa en la parte de extracción del proceso ETL global generando a su vez procesos de tipo ETL internos. El esquema general que sigue el flujo de datos del proceso de migración es el siguiente:

HOST ARCCO El origen de nuestra información se encuentra en HOST, las principales funciones del equipo de HOST previas a la extracción son; recopilar todos los datos de los clientes, clasificarlos y almacenarlos en ficheros. Posteriormente estos ficheros son los que recoge el grupo de extracción a través de un FTP (movimiento de fichero). Gracias a la herramienta PWC estos ficheros son extraídos y almacenados en el data warehouse (DWH), en tablas, más manejable y adaptable que los ficheros. Asimismo, se generan una serie de transformaciones tales como: control de nulos, agregaciones, ordenaciones, simplificaciones, etc., para una clasificación más clara de los datos. Cuenta con multitud de ventajas externalizar el trabajo, usar una herramienta ETL como PWC en vez de HOST, evita sobrecargas, además de ser más barato, visual y práctico. Finalmente se procede a la carga, de nuevo volcamos toda la información de las tablas en formato fichero para ser enviadas al equipo de transformación.

Transformación HOST

Extracción PWC

Carga HOST


Estos ficheros pasan a transformación donde se volverán a manipular los datos, complementándolos con otras fuentes de origen. Los cambios generados en transformación se llevan a cabo en HOST. Los ficheros se presentan finalmente al equipo de Carga encargados de poner a disposición todos los ficheros para el Banco Santander en la Aplicación de Rentabilidad de Clientes y Centros Online, ARCCO. El día de la migración se mostrará la información conjunta de ambas entidades, Banco Popular y Banco Santander. El objetivo principal es la explotación de toda la información recogida en la herramienta ARCCO por parte del Área de Negocio de Banco Santander. Una vez que hemos visto la estructura general centraremos la atención en el desarrollo llevado a cabo internamente por PWC. Lo más importante y primario del Proyecto es construir una planificación. Los procesos están divididos por interfaces coordinadas por distintos delegados y todas deben seguir un orden de ejecución, el cual debe estar claro desde el principio. Una vez que finaliza el desarrollo y las pruebas, comienzan las oleadas de ejecución de todos los procesos siguiendo la planificación inicial con todas las dependencias incluidas. Las oleadas son simulacros de la migración con un volumen de datos menor para unas fechas determinadas. A continuación, da comienzo el análisis de los ficheros resultados, el estudio de la calidad del dato y los cambios oportunos para la mejora de los procesos. Los procesos que vamos a desarrollar siguen una trayectoria bastante tediosa y larga. A continuación, explicamos el ciclo de vida que siguen nuestros datos dentro de la herramienta ETL, Powercenter: 1. Comenzamos en HOST. Host es el corazón del Banco y se encarga de recopilar, ordenar y clasificar

absolutamente toda la información recogida por las distintas fuentes del banco. Cuenta con su propia base de datos y su propio lenguaje de programación, COBOL.

2. Empieza nuestra labor con la ayuda de la herramienta ETL, Powercenter, y otras que veremos a continuación.

- Comenzamos con la elaboración de los primeros procesos, LOAD, para transportar los ficheros desde

el entorno de HOST hasta nuestra base de datos data warehouse, clasificarlos y cargarlos en tablas concretas. Hay dos tipos de procesos de extracción dentro de los procesos LOAD (nomenclatura especifica del proyecto). Por un lado, están los procesos denominados staging, dónde decodificamos la información y volcamos los datos provenientes de host a un fichero legible y posteriormente seguidos de éstos creamos los procesos que cargarán los ficheros legibles en tablas. Estos segundos gestionan el control de nulos, es decir aseguran que aquellos campos que llegan con registros vacíos tienen una asignación y no generan problemas. Las tablas creadas en este procedimiento serán nuestros puntos de origen y desde donde obtendremos toda la información necesaria para elaborar el siguiente proceso de la cadena, los procesos de tipo CAL, de cálculo.

- Los procesos de tipo CAL, entran dentro de la fase de transformación, son donde modificaremos los datos para clasificarlos y organizarlos de una forma más clara y efectiva. En nuestro caso práctico de cálculo explicado más adelante, abordaremos todo tipo de tratamientos realizados para comprender mejor las transformaciones con las que se trabaja. Entraremos en detalle para entender la potencia de la herramienta.

- Posteriormente seguiremos el ciclo de vida del flujo de los registros que pasarán por otros dos procesos, el de VAL, validación, como método de prevención de errores y EXT, de extracción, para convertir las tablas resultado de los procesos de CAL de vuelta al formato de ficheros.


3. Finalmente, la labor de PWC termina con el envió de los ficheros al equipo de transformación, como hemos comentado anteriormente.

Una vez conocido el flujo a seguir vamos a detallar los elementos necesarios para llevar con efectividad todos los procesos nombrados anteriormente. Conoceremos las herramientas que ayudan a la ejecución del proceso, la herramienta de Powercenter en profundidad y sus distintas funcionalidades encargada del desarrollo (Designer), la ejecución (Monitor), la configuración (Workflow) y el almacenamiento (Repository). Posteriormente veremos los mapping, procesos desarrollados en PWC, cuyos elementos principales son las transformaciones las cuales abordaremos una por una detalladamente. Y terminaremos explicando las ejecuciones, pruebas y requisitos esenciales para finalizar correctamente con el desarrollo del proyecto.

3.2.1 Herramientas que participan en el proceso Las herramientas que participan en el proceso de migración son, MVS, Putty, Powercenter Designer (PWC) y SQL Developer.

• MVS, es un sistema operativo, comúnmente llamado HOST, “el corazón del banco”, trabaja con lenguaje COBOL. Tiene acceso a la base de datos del Banco Popular y es el puente de acceso desde Powercenter.

• Putty es un terminal que nos sirve para conectarnos al servidor donde se encuentra Powercenter Server. Los ordenadores propios de los trabajadores tienen instalado Powercenter como cliente y todos ellos se conectan con el servidor a Powercenter Server. Accedemos al servidor mediante su dirección IP y su puerto. La abreviatura que le damos a la dirección IP es lpmis para simplificaciones y claridad con los nombres. Según el entorno en el que queramos acceder la dirección IP será lpmisdes, lpmispre o lpmispro. Los comandos ejecutados en el Putty se denominan scripts.


Ilustración 7 Acceso a la aplicación Putty

• Powercenter es la herramienta principal que llevará a cabo el proceso de extracción, transformación y carga de datos. Fase de extracción:

Puede extraer información de dos fuentes: Ficheros y tablas.

En el caso de ficheros, comienza con la generación de éstos en HOST. Para poder leer estos ficheros desde PWC lanzamos un comando desde la aplicación de Putty al que se le llama FTP, que mueve ficheros entre ordenadores del servidor de HOST al servidor de Powercenter. La representación física de movimientos de ficheros, FTP, ejecutada interiormente por comandos, la podemos ver en la aplicación FileZilla cuando por ejemplo movemos el documento NORMATIVA de nuestro ordenador, sitio local, al servidor, sitio remoto.


Ilustración 8 Acceso Filezilla

Para el caso de extracción de datos proveniente de tablas, recurrimos a las queries para acceder a la información alojada en la base de datos del Banco Popular, por medio de la herramienta SQL Developer, trabajando con lenguaje SQL. Dentro del DWH del Banco Popular hay una serie de bases de datos que se acceden a ellas mediante distintas conexiones con el nombre de usuario y la contraseña. El acceso se distingue por su IP y puerto.


Ilustración 9 Acceso a las conexiones de BBDD

Fase de transformación Powercenter es protagonista en la fase de transformación, es la herramienta principal de nuestro proceso. Usaremos transformaciones para tratar y clasificar los datos recibidos. Veremos en nuestro caso práctico la fase de transformación con más detalle. Fase de Carga

Así mismo Powercenter también abarca la función de cargar los datos transformados en tablas o ficheros. Los datos finales cargados en ficheros pueden ser visibles desde la aplicación de FileZilla y la información de las tablas las podremos ver desde la aplicación SQL Developer. Más adelante desarrollaremos en qué consiste la ventana de trabajo Workflow Monitor detallando cómo conectar el fichero o la tabla con la aplicación de Filezilla o SQL Developer respectivamente.

• SQL Developer Es la herramienta que nos permite estar en contacto directo con la base de datos. Según el usuario con el que se conecte a la BBDD, este tendrá una serie de permisos para poder acceder a un determinado grupo de tablas y esquemas (donde se alojan las tablas). Cada conexión tiene unos permisos para ver distintos esquemas y cada esquema contiene un grupo de tablas.


Éstos pueden ser de lectura o de escritura. Powercenter en definitiva es la representación gráfica de un código interno de SQL. Todas las transformaciones generadas en Powercenter a su vez crean un código SQL que es el que realiza la acción. Así pues, todo el proceso podría reducirse a una “query” en lenguaje SQL, pero sería mucho más tedioso y dificultaría la labor de corrección.

Ilustración 10 Conexiones, Esquemas y Tablas


3.2.2 Ventanas de trabajo de Powercenter

Nuestra herramienta cuenta con cuatro ventanas de trabajo, Designer, Workflow Manager, Workflow Monitor y Repository Manager. Con la funcionalidad de estas 4 ventanas y las aplicaciones descritas anteriormente tenemos todos los utensilios necesarios para desarrollar un proceso completo en Powercenter.

1. Designer

La primera ventana de la que vamos a hablar es el Designer donde diseñamos los mappings, mapplets, Source y Target. Hay varios elementos en esta ilustración que debemos conocer, nos resultarán familiares posteriormente cuando hablemos en los siguientes puntos más detalladamente. Los comentaremos brevemente como introducción. Primero, en rojo, están las 4 ventanas de trabajo a las que podemos acceder, marcado en azul, elegimos el entorno o repositorio donde queremos trabajar, por último, antes de comenzar con la descripción detallada de estos puntos, resaltados en naranja los iconos que representan las transformaciones.

Ilustración 11 Ventana de trabajo Designer

Designer a su vez dispone de otras 5 sub-ventanas, en verde, de izquierda a derecha está,

• Source Analyzer

En esta ventana creamos la transformación Source Qualifier, transformación que da comienzo al proceso cargando datos en nuestro mapping. La transformación Source Qualifier se utiliza para extraer datos de fuentes relacionales o ficheros planos.


La información la podemos extraer a través de ficheros tales como, Flatfile, VSAM, XML, etc., o de tablas relacionales en base de datos accediendo mediante herramientas como, DB2, Oracle, Teradata, Salesforce, etc. Si una transformación Source Qualifier se asocia a una tabla relacional, la extracción de datos de dicha fuente se realizará a través de una consulta SQL. Powercenter generará una consulta SELECT predeterminada sobre la tabla asociada. Las propiedades de la transformación nos permitirán modificar la consulta generada. Una misma transformación Source Qualifier puede asociarse a múltiples tablas relacionales, siempre que éstas se encuentren en la misma base de datos, esquema. Si una transformación Source Qualifier se asocia a un fichero plano éste será procesado en su totalidad. Powercenter no genera SQL para extraer datos de ficheros planos. Si nuestro proceso de carga necesita filtrar parte de los datos del fichero plano a tratar se utilizará una transformación de tipo Filter.

• Target Designer

Los Targets son las tablas o ficheros que recogen los datos que se han tratado en el proceso, y contienen los campos que se van a extraer. En esta ventana de trabajo creamos la transformación para posteriormente adjuntarla al mapping.

Es importante saber que la creación de los Source y de los Targets va de la mano con la creación de los shortcuts. Tanto los Source como los Target se crean en estas pestañas dentro del Design y posteriormente se demanda al departamento de arquitectura de datos que los muevan a la carpeta compartida. La razón de mover los Target y los Source a la carpeta compartida es para crear un acceso directo, shortcuts, una forma de generar cambios automáticos en cualquiera de los procesos en los que están implicados. Una vez que los tengamos en la carpeta compartida ya los podemos insertar en el Mapping Designer.

• Mapplet Designer

Ventana donde generamos los mapplet, definidos en el glosario anteriormente. En nuestro proceso no usamos ninguno, no es un elemento muy común.

• Mapping Designer

Es la unidad donde se diseña el programa que necesariamente extrae, transforma y carga los datos. Ventana principal donde desarrollaremos todo nuestro proceso. En él formarán parte las dos transformaciones nombradas anteriormente, Source Qualifier y Target. Además de una serie de transformaciones que definiremos más adelante.


Ilustración 12 Elementos que constituyen la ventana Designer

Source Analyzer

Mapping Designer

Carpetas compartidas, para todos los proyectos

Targer Designer


2. Workflow Manager Una vez creado el mapping en la ventana del Designer pasamos al Workflow Manager donde comenzamos con la construcción del workflow, cuya funcionalidad es ejecutar nuestro proceso según unas propiedades concretas las cuales están definidas en las sesiones. En nuestro proyecto del Banco Popular, cada Workflow contiene una sesión y esta sesión está asociada únicamente a un mapping. Un worklet es un objeto que representa un conjunto de tareas creadas para reutilizar un conjunto de lógica de flujo de trabajo en múltiples flujos de trabajo. Puede crear un worklet en Worklet Designer. El flujo de trabajo que contiene el worklet se llama flujo de trabajo principal.

Ilustración 13 Ventana de trabajo Workflow Designer

En las propiedades del workflow hay varias cosas que tenemos que tener en cuenta sobre los Source y los Target. Como hemos comentado, el workflow es el elemento que ejecuta el proceso. Las querys tienen que estar recogidas en las propiedades de cada Source Qualifier. De este modo accederá a la tabla par_parent para leer el desarrollo de la query. El nombre de la query tiene que ser el mismo tanto en la tabla como en el workflow. Como podemos ver en la ilustración las conexiones también van parametrizadas, cada proceso necesita una conexión específica para poder acceder a un conjunto de tablas.


Ilustración 14 Propiedades del workflow asociadas a la transformación Source

Los Target también cuentan con una conexión específica. Esto es debido a que cuando el proceso es lanzado el workflow es el encargado de escribir y leer de cada una de las tablas y para ello necesita una conexión. Como hemos comentado antes, el acceso a las tablas depende de las conexiones. También añadimos los parámetros $$PREPOST Y $$POSTSQL así al acceder a la tabla PAR_PARENT_PROCETL poder leerlos de ella y asociarles un valor. La funcionalidad de todos estos parámetros está explicada en el caso práctico.

Ilustración 15 Propiedades del workflow asociadas a las trasformaciones Target


3. Workflow Monitor El Workflow Monitor proporciona opciones para visualizar información de las ejecuciones de los workflows. Para poder visualizar la información es necesario conectarse al repositorio y contar con el servicio de integración activo. La herramienta permite personalizar la visualización de las ejecuciones configurando desde el día actual hasta un valor determinado o mostrar solamente aquellos procesos que se están ejecutando. Además, la herramienta permite la visualización de la interfaz gráfica en modo de vista de tareas o diagrama de Gantt. En el Workflow Monitor podemos acceder a 3 entornos diferentes. Dentro de cada entorno están las distintas carpetas de proyectos y dentro de cada carpeta el proceso lanzado. El monitor calcula el tiempo de ejecución y en caso de fallo, nos proporciona una ventana externa con los posibles errores. Al comienzo del trabajo hablamos sobre las características generales de las herramientas de Back-end y uno de los puntos que comentamos es la validación en la compilación. Este es el caso en el que Powercenter nos muestra las validaciones y los fallos que existen en el proceso.

Ilustración 16 Ventana explicativa y detallada de los fallos cometidos al lanzar el proceso

Los procesos los lanzamos desde la aplicación de Putty, aunque también es posible hacerlo directamente desde Powercenter, desde la ventana del workflow monitor, nosotros usaremos la otra alternativa, Putty. La ejecución de los workflows creados en Powercenter se realiza ejecutando un script con la nomenclatura “LanzaWorkflow{codigo_proyecto}.sh”, por ejemplo: sh LanzaWorkflowWSCDG.sh wf_WSCDG_CAL_TMIG__INT_SDO_CONT '' '' 1 180329 WSCDG. Este script está ubicado en el entorno de Unix ubicado en el directorio de scripts de cada proyecto (“/opt/Powercenter/infa85/server/Scripts/{codigo_proyecto}/ visible desde Filezilla.


Ilustración 17 Aplicación Filezilla. Carpeta de Scripts

4. Repository Manager Es el almacén central de Powercenter. El uso particular que le damos es de intermediario entre el proceso en el entorno de desarrollo y el de Producción. En esta ventana es donde movemos los procesos entre carpetas, para ello y como norma general necesitamos permisos de acceso. Como modo de prevención los proceso antes de pasar del entorno de DES a PRE son depositados en la carpeta p_, es el paso anterior de la subida definitiva al entorno de PREproducción. En nuestro caso práctico, como hemos comentado trabajamos en el sector de Control de Gestión, WSCDG, la carpeta intermedia antes de la subida a pre es p_WSCDG.

Ilustración 18 Carpetas pertenecientes al Repository


3.2.3 Transformaciones

Las Transformaciones son nuestras herramientas principales para la construcción de los mappings. Como ya hemos comentado un mapping comienza con un Source y finaliza con un Target. Source La creación de un Source la hemos visto anteriormente en la ventana de Designer. Una vez que arquitectura de datos mueve el Source a la carpeta compartida, al arrastrarla a la ventana del mapping se crea automáticamente el shortcut, la transformación que siempre acompaña al Source para extracciones en tablas y a la que llamamos Source Qualifier. Esta transformación es modificable a diferencia de la estructura del Source inicial.

• Para el caso de extracción en tablas, una misma transformación Source Qualifier puede asociarse a múltiples tablas relacionales, siempre que éstas se encuentren en la misma base de datos. El cruce de ambos sources, filtros o cualquier transformación que queramos hacer al inicio se creara en la query que introducimos en el Source Qualifier. Powercenter generará una consulta SELECT predeterminada sobre la tabla asociada.

Ilustración 19 Transformación SQ

• Para la extracción de datos asociados a ficheros como, Flatfile, VSAM, XML… extraemos toda la información que contienen, es decir no hay posibilidad de crear una consulta SQL (query) a la BBDD para cruzar, agregar o cualquier transformación posible para las tablas relacionales. Si nuestro proceso de carga necesita filtrar parte de los datos del fichero plano a tratar se utilizará una transformación de tipo filter.


Normalizer La transformación Normalizer se utiliza para descodificar los ficheros provenientes de host de tipo VSAM, estos ficheros se denominan copies. Estas decodificaciones se hacen en los procesos staging, para traducir todos los ficheros provenientes de Host a otro fichero legible.

Ilustración 20 Transformación Normalizer

Expression La transformación Expression se utiliza para realizar cálculos a nivel de registro, un registro está formado por una serie de datos clasificados por campos. Este tipo de transformación permite realizar cualquier operación no agregada sobre los datos. Si se necesitara realizar cálculos agregados, utilizaríamos la transformación Aggregator, que explicaremos próximamente. Esta transformación permite manipular los datos de entrada en los puertos de tipo Variable u Output utilizando cualquier combinación de los siguientes elementos:

• Puertos de tipo Input o Input/Output

• Puertos de tipo Variable

• Variables y parámetros del mapping

• Variables predefinidas (SESSSTARTTIME y SYSDATE)

• Operadores (+,-,*,/,%,=, >, <, >=, <=, <>, !=, ^=, AND, OR, NOT, ||)

• Dentro de la transformación tenemos una librería de funciones que nos facilitará el trabajo. Alguna de ellas son:

- Funciones de conversión, para convertir la estructura de un campo en una específica como en cadena de caracteres TO_CHAR o en fecha TO_DATE.

- Funciones de testeo como (ISNULL, IS_DATE) - Funciones específicas para el tratamiento de fechas como GET_DATE_PART, selecciona y

guarda una parte de la fecha, en el caso de la ilustración guarda únicamente los días, ‘DD’.

Es importante saber que los campos que tienen cálculos en función de otros campos deben ir siempre al final, ya que todas las variables que formen parte de la expresión tienen que estar por encima, sino no la localizará.


Ilustración 21 Ejemplo de una transformación dentro de la transformación Expression

Los valores inputs (I) son únicamente campos de entrada que pueden ser o no utilizados por otros campos para sus cálculos. Los campos outputs (O) son los campos de salida, pueden haber sido calculados en función de otros campos o mapeados directamente a la siguiente transformación (marcados como I y O). Y los campos variables (V) son aquellos que creamos dentro de la transformación, son campos auxiliares que nos sirven para el cálculo de otros campos. Sorter La transformación Sorter se utiliza para ordenar los datos dentro del flujo de datos. Su ordenación se puede realizar por un campo o por varios y de manera ascendente o descendente. El campo de ordenación se denomina key. El Sorter tiene varios usos:

• Cuando cargamos datos en el fichero la transformación Sorter es una ventaja para obtener los datos en el fichero ordenados.

• Uso conjunto con una transformación Aggregator o Joiner para mejora del rendimiento del mapping. Ambas transformaciones tienen la opción de Sorter Input, que avisa a la transformación de que los registros llegan ordenados para optimizar la búsqueda de registros


Ilustración 22 Campos clave de la ordenación en la transformación Sorter

Aggregator La transformación Aggregator se utiliza para realizar cálculos agregados. Mientras que la transformación Expression nos permite realizar cálculos únicamente a nivel de registro, mediante la transformación Aggregator podemos realizar cálculos sobre grupos de registros. La transformación Aggregator funciona de una manera equivalente a la cláusula GROUP BY en lenguaje SQL. En el caso práctico traduciremos la funcionalidad de las transformaciones a lenguaje SQL. La transformación Aggregator permite el uso de expresiones condicionales en las funciones de agregación para limitar el número de registros a utilizar en cada caso. Agregamos por un campo clave que se marca en la expresión en la casilla de “GroupBy”.

Ilustración 23 Ejemplo expresión de la transformación Aggregator


En el caso del lenguaje SQL se traduciría a

Select SUM(SALDO_MEDIO)

from d1bpeww.TPROD_INF_SDO_FRARGO group by n_itn_pers_idv;

n_itn_pers_idv saldos Agregación

1 20

1 12 44

1 12

2 34 34

3 12

3 36 48

4 23 23

5 45

5 21 66

Tabla 2 Puesta en práctica de la funcionalidad de la transformación Aggregator

Joiner La transformación Joiner se utiliza para cruzar flujos de datos heterogéneos. A diferencia de la transformación Source Qualifier que también podía unir flujos de dos o más tablas, pero de una misma base de datos, la transformación Joiner hace posible cruzar dos flujos de datos de cualquier tipo, como:

• Dos ficheros planos

• Un fichero plano y una tabla

• Una tabla en Oracle y otra en DB2

• Dos tablas en distintas instancias de base de datos Una transformación Joiner permite cruzar únicamente dos flujos de datos. Como hemos comentado antes tenemos la opción de indicarle al Joiner que los registros llegan ordenados por medio del Sorted Input. La utilización de esta propiedad puede mejorar considerablemente el rendimiento Uno de dichos flujos se definirá como Master (se escoge el flujo que tenga una menor volumetría de datos, para ayudar a Powercenter a escoger qué flujo se cruzará con otro) y el otro como Detail. Esta propiedad nos permitirá diferenciar el flujo del que proviene. Si es necesario cruzar más de dos flujos de datos se utilizará una serie de transformaciones Joiner en cascada. La transformación Joiner permite realizar los siguientes tipos de cruces:

• Normal Join: Este tipo de cruce nos permite seleccionar únicamente los registros de ambos flujos que cumplen la condición de cruce especificada. Los registros que no cumplen la condición de cruce se eliminan

• Master Outer: Este tipo de cruce nos permite seleccionar todos los registros del flujo de datos definido como Detail más los registros del flujo definido como Master que cumplen la condición de


cruce. Los registros del flujo definido como Master que no cumplen la condición de cruce se eliminan. Los registros del flujo definido como Detail para los que no haya una correspondencia en el flujo definido como Master aparecerán con un valor de NULL en los campos de este último.

• Detail Outer: Este tipo de cruce nos permite seleccionar todos los registros del flujo de datos definido como Master más los registros del flujo definido como Detail que cumplen la condición de cruce. Los registros del flujo definido como Detail que no cumplen la condición de cruce se eliminan. Los registros del flujo definido como Master para los que no haya una correspondencia en el flujo definido como Detail aparecerán con un valor de NULL en los campos de este último.

• Full Outer Join: Este tipo de cruce nos permite seleccionar todos los registros de ambos flujos, independientemente de que cumplan o no la condición de cruce especificada. Los registros que no cumplan la condición de cruce aparecerán con un valor de NULL en aquellos campos de uno u otro flujo.

Ilustración 24 Tipos de Joiners

La parte coloreada hace referencia a los registros que cruzan. Veamos un ejemplo sencillo: Tenemos tres campos que provienen de la tabla, la cual hemos denominado Master y cuatro de la tabla Detail. El ejemplo siguiente es un Joiner de tipo Detail Outer Join con campo de cruce n_itn_pers, es decir todos los registros de la tabla Master pasan y de la tabla Detail únicamente los que crucen. Por lo tanto, si el campo de cruce n_itn_pers de la tabla Detail también está registrado en la tabla Master significa que éste cruzará. Como es el caso del primer registro. Sin embargo, el número interno de persona, n_itn_pers, de la tabla Master no se encuentra en los registros de la tabla Detail por lo tanto este registro no cruzará, quedan sin informar los campos de la tabla Detail y se rellenan con null.


Tabla Master Tabla Detail

F_DATOS N_ITN_PERS

N_ITN_PERS IN_CLI_MIGRT

REF_EXT_CIMTO F_CLI_MIGRT

C_SIT_MCONTO

F_SIT_MCONT

Tabla 3 Ejemplo cruce de registros

Look up La transformación Lookup se utiliza para realizar búsquedas sobre ficheros planos y fuentes relacionales. Las propiedades de la transformación nos permiten definir una condición de búsqueda que específica como han de compararse los registros proporcionados a la transformación desde el flujo de datos con los registros del fichero o tabla de referencia al realizar una operación de búsqueda. Si una transformación Lookup se asocia a una tabla relacional, la extracción de datos de dicha fuente se realizará a través de una consulta SQL. Powercenter generará una consulta SELECT por defecto sobre la tabla asociada. Una transformación Lookup puede utilizarse en modo conectado o desconectado. Una Lookup desconectada se usa del mismo modo que una función, permitiéndonos definir para el mismo, uno o más parámetros de entrada y un único parámetro de salida. Para este modo, la operación de búsqueda se invoca de forma explícita desde una expresión.

M M M D D D D

campos F_DATOS N_ITN_PERS REF_EXT_CLIMTO IN_CLI_MIGRT F_CLI_MIGRT C_SIT_MCONTO F_SIT_MCONTO

registros 11/06/2018 1254877 5 658 15/02/2016 L 16/03/2016

29/03/2018 5487945 7 null null null null


Tabla 4 Transformación Look-up

Router La transformación Router se utiliza para aplicar múltiples condiciones de filtrado sobre un flujo de datos, permitiéndonos particionar el mismo en base a que los registros cumplan una condición u otra. Este tipo de transformación nos permite definir una serie de grupos y asociar a cada grupo una expresión condicional que será evaluada para cada registro a procesar. La transformación dirigirá cada registro a uno u otro grupo dependiendo de si cumple o no la condición de filtrado asociada al mismo. Una vez definidos dichos grupos comprobaremos que en la trasformación se crean de forma automática dos grupos adicionales:

- Input: Grupo de entrada utilizado para proporcionar registros a la transformación. - Default: Grupo de salida al cual pertenecerán todos los registros que no cumplan la

condición de filtrado de ningún otro grupo.

La transformación Router funciona de una manera equivalente a un conjunto de transformaciones de tipo Filter y con la cualidad que es mucho más eficiente. Por ejemplo, cuando un registro no lleva informado algún campo puede ser la condición para realizar la división. Para la asignación de registros a un grupo debe haber una condición por ejemplo, en lenguaje PWC se escribiría IIF(ISNULL TABLA_A.CAMPO_1,1,0). Los registros que apliquen a esta condición pertenecerán al grupo de los registros que tiene el campo_1 nulo, la afirmación queda señalada por el 1. Y en caso contrario 0, irá a DEFAULT. Los valores de Inputs son todos los registros de entrada sin excepción.


Tabla 5 Transformación Router. Divisiones por registros según condición.

Union La transformación Union se utiliza para unir registros de orígenes distintos en un único flujo de datos. La transformación Union funciona de una manera equivalente a la cláusula UNION ALL en lenguaje SQL, con la excepción de que los datos a unir pueden tener su origen en fuentes de distinto tipo. Al igual que la cláusula UNION ALL, la transformación Union no elimina aquellos registros duplicados que puedan resultar una vez unidos los distintos orígenes de datos. En esta transformación se puede definir el número de grupos de entrada, pero todos tendrán los mismos campos. En definitiva, esta transformación aumenta la volumetría de forma vertical, es decir mismos campos, más registros.


Tabla 6 Transformación Union

Target Como comentamos en las descripciones de las ventanas de trabajo, en concreto en el Target Designer, una transformación Target recoge los registros finales ya tratados. Los Target no tienen la capacidad de tratar los datos, única y exclusivamente los agrupa. En el ejemplo a continuación podemos observar que nuestra trasformación Target genera ficheros (Flat File), no tablas.

Ilustración 25 Transformación Target


3.2.4 Entornos y Pruebas

El proceso que llevamos a cabo pasa por tres entornos diferentes, Desarrollo (DES), PreProducción (PRE) y Producción (PRO). Sigue un riguroso control de errores para asegurar la fiabilidad de los datos cargados. En el entorno de desarrollo es donde construimos toda la estructura de nuestro proceso. Todos los mapping comienzan desarrollándose en este entorno ejecutando con datos de prueba, datos ficticios. Probamos la funcionalidad del proceso en sí. La ruta que siguen nuestros datos comienza en los ficheros de HOST. Estos datos se traspasan al entorno de staging (Stg control de nulos), contiene su propia base de datos temporal, identificada con el esquema d1bpesw…. Su funcionalidad consiste en convertir todos los ficheros en tablas para que el DHW recoja toda la información en dicho formato. Cada entorno cuenta con una base de datos propia, para el caso del Data warehouse es un conjunto de base de datos que se acceden a cada una de ellas por distintas conexiones. El esquema del Data Warehouse es d1bpeww, pero dentro del DHW hay muchas otras BBDD que llevan otro esquema asociado. Cada conexión accede a un conjunto de esquemas (BBD). Finalmente, en el datamart se clasifica la información de una forma más detallada. En nuestro proyecto los procesos se denominan según a que apartado de este ciclo de vida pertenezcan. La nomenclatura de los procesos de tipos Stagging se clasifican como LOAD, los procesos de cálculo en el DWH como CAL y los de extracción dirigida a la entrega final como EXT. Además, existen los procesos de validación, VAL, entran dentro de la política de control de fallo para prevenir futuros errores.

Ilustración 26 Curso de vida de los procesos

En Desarrollo probamos los procesos con datos ficticios. Para poder probar en PRE con datos reales es necesario que el proceso cumpla unas series de normas que serán evaluadas de manera automática. La petición de Revisión de la Normativa para los desarrollos en Powercenter se realiza de la siguiente manera:

1. Se creará un fichero plano en el entorno de desarrollo de Powercenter (lpmisdes). Los registros que tendrá este fichero serán las peticiones que se pretenden evaluar con el siguiente formato: {Nombre_Workflow};{Carpeta};{Usuario} Ej.: wf_WSCDG_CAL_TMIG_INT_SDO_CONT ; p_WSCDG ; LMM2749B

2. Ejecución del Script. Como comentamos en el punto 3.2.1 Herramientas de Trabajo, por medio de la herramienta de Filezilla podemos modificar el fichero de normativa donde están escritos los parámetros descritos anteriormente. La ruta donde se encuentra este fichero es “/opt/Powercenter/infa85/server/Scripts/{CódigoProyecto}/Scripts”. La ejecución del Script en la aplicación del Putty sería el mismo añadiendo cd /:

cd /opt/Powercenter/infa9/server/Scripts/WSCDG/Scripts y la estructura del script para la petición de la normativa es:

Peticion_Normativa_WSCDG.sh /opt/Powercenter/infa9/server/Scripts/WSCDG/Scripts/NORMATIVA.txt WSCDG


3. El usuario que se ha incluido en el fichero de peticiones recibirá un correo indicándole el resultado de la revisión del desarrollo. Este correo indicará un resultado “CORRECTO” o “ERROR”, en este último se adjuntarán los puntos que no cumplen normativa.

Problemas comunes de incumplimiento de la normativa:

• Todas las transformaciones deben tener una nomenclatura concreta:

Source Qualifier = sq_NombreOrigen(es)

Normalizer = nrm_NombreOperaciónNormalizer

Expression = exp_NombreOperaciónExpresión

Filter = fil_NombreOperaciónFiltro

Sorter = srt_NombreOperaciónSorter

Aggregator = agg_NombreOperaciónAggregator

Joiner = jnr_NombreOperaciónJoiner

Look-up= lkp_NombreOperaciónLookup

Router = rtr_NombreOperaciónRouter

Union = un_NombreOperaciónUnión

• Las descripciones de las transformaciones tienen que superar los 15 caracteres

• Todos los campos tienen que estar mapeados, es decir debe haber un link desde el origen hasta en final.

• Tanto el mapping como el workflow deben estar en check_in. Para poder modificar un proceso debemos hacer check_out y para cerrarlo check_in.

• El nombre del proceso debe estar señalizado en muchos de los ajustes del workflow, es importante revisarlo.

• Los parámetros tienen que estar diseñados tanto en el par_parent como definido en nuestro mapping.

Todos los procesos tienen que ser ejecutados. Para ello lanzamos un script en la aplicación Putty, primero tenemos que acceder a la ruta de los Scripts cd /opt/Powercenter/infa9/server/Scripts/WSCDG/Scripts y posteriormente debemos ejecutar el workflow que lo haremos con su Script correspondiente sh LanzaWorkflowWSCDG.sh wf_WSCDG_EXT_TMIG_INT_SDO_CONT '' '' 1 120131 u_WSCDG en él se indica el nombre del workflow que queremos ejecutar, la carpeta donde se encuentra y la fecha que queremos los registros que recogerá de la base de datos. Los procesos se lanzan en los tres entornos DES, PRE y PRO. El Scrips de los procesos de PREproducción el Scripts es : sh LanzaWorkflowWSCDG.sh wf_WSCDG_EXT_TMIG_INT_SDO_CONT '' '' 1 120131 WSCDG. Además, la aplicación de Putty debe estar en el entorno de PRE o PRO. Para subir un proceso de DES a PRE debemos acceder al Repository, ventana de Powercenter definida anteriormente. Una vez ejecutado y pasado la normativa copiamos nuestro proceso en la carpeta previa a la subida al entorno de PRE. Este procedimiento requiere un usuario con permisos. Todos los procedimientos en los distintos entornos normalmente siempre necesitan el acceso por medio de unas credenciales por temas de seguridad y confidencialidad. [22] Las pruebas finales del proyecto se ejecutan en el entorno de PRO con valores reales. Las ejecuciones de esta fase se hacen por oleadas (intervalos de fechas) y ejecutando toda la malla (planificación del orden en el que tienen que ejecutarse los procesos ya que unos dependen de otros), de tal forma que se hacen simulacros para asegurarnos de que nuestros procesos funcionan correctamente.


4 Proyecto de Migración

4.1.1 Introducción

Como comentamos en un principio el Proyecto de Migración lo forman alrededor de 70 procesos. En este caso práctico explicaremos el proceso en el que me he visto implicada y he sido responsable de su desarrollo. Estudiaremos paso por paso todas las trasformaciones y veremos cuáles son sus funcionalidades con casos reales. Nos familiarizaremos con una de las herramientas más usadas para el tratamiento de datos entendiendo cómo son manipulados todos los datos recibidos para obtener unos resultados simplificados y útiles para la toma de decisiones posterior.

4.1.2 Caso práctico Comenzamos el caso práctico con la estructura general del mapping y conceptos elementales que nos facilitará el posterior entendimiento. Explicaremos primeramente una de las tablas de la Base de datos más popular e importante, la tabla Par_parent donde almacenamos todos los datos que queremos parametrizar. También en éste primer punto haremos una similitud entre las transformaciones usadas y su traducción a lenguaje SQL. Las trasformaciones es un método simplificado y mucho más visible para entender el código SQL que internamente ejecutan.

Estructura Global – Conceptos Básicos

Nuestro mapping recoge información de 10 tablas distintas, las transformaciones Source alimentan nuestro proceso. Posteriormente para toda transformación Source interviene el Source Qualifier donde se incluirá la query encargada por medio de lenguaje SQL de acceder a las bases de datos a la tabla en concreto y extraer los campos seleccionados. Una vez que ya tenemos los campos que clasifican los registros comenzamos el tratamiento de éstos. Finalmente, los registros son recogidos en las transformaciones Targets, donde se encuentra la tabla destino con la información valida y de utilidad posterior y otras dos trasformaciones Targets pero de tipo fichero que recogen aquellos registros que no han cumplido con algunas de las condiciones pedidas a lo largo de las transformaciones intermedias. Estos ficheros son de mucha utilidad ya que cualquier error que haya habido a lo largo del proceso es fácilmente detectable. La siguiente imagen nos muestra la estructura al completo del mapping de cálculo.


Ilustración 27 Estructura global del mapping

Los mapping de tipo CAL consisten en recuperar los campos que nos interesen de las tablas origen y mediante las transformaciones hacer unas serie de cálculos y análisis hasta conseguir reducir la información recogida en datos interesantes para la posterior toma de decisiones. Además existen unas serie de parámetros que no son visibles a simple vista pero su presencia es de vital importancia como cualquier otro elemento del mapping. Parametrizados en la tabla PAR_PARENT_PROCETL. Muchos de los parámetros son comunes para todos mapping adaptando su valor a cada uno de ellos. En nuestro caso los parámetros son los sigueintes; Parámetros: $$SQL_QUERY: Las queries son preguntas en lenguaje SQL para acceder a la base de datos. Su desarrollo está en la tabla de parámetros PAR_PARENT_PROCETL en la base de datos visible desde la herramienta SQL Developer y la llamada al parámetro la hacemos desde la transformación Source Qualifier (SQ) en Powercenter. Existe una única query para cada SQ.


Ilustración 28 Query parametrizada en el SQ. Powercenter

Ilustración 29 Query parametrizada en la PAR_PARENT. SQL Developer

Todo nuestro mapping se podría reducir en un Source, un Source Qualifier y un Target ya que el proceso entero puede ser traducido en lenguaje SQL introducido en una única query si el volumen de datos lo permitiese. Este procedimiento nunca se sigue por varias razones, las consultas hacia la BBDD extraen volumetrías de millones de registros por lo que la BBDD se atoraría si tuviera que sacar todos estos datos calculados, por lo compleja que podría llegar a ser esta query y por la dificultad de encontrar los errores al no desgranarla. Aun así, es bastante común introducir una query para reducir primeros cálculos. La traducción de transformación a lenguaje SQL son:


Transformación SQL

Joiner LEFT JOIN

RIGHT JOIN

INNER JOIN

Aggregator SUM

MAX GROUP BY

MIN

AVG

Sorter ORDER BY

Expression WHERE

AND

Router

Look Up NORMAL JOIN

Tabla 7 Traducción de transformaciones a lenguaje SQL

Suele ser muy habitual simplificar los primeros cruces, veremos más adelante en nuestro ejemplo práctico las dos posibles formas de desarrollo. Los parámetros del proceso son:

• Pre SQL: Disponible únicamente si una transformación Source Qualifier se asocia a una o múltiples tablas relacionales. Comando SQL que Powercenter ejecutará en la base de datos origen antes de empezar a leer registros.

• Post SQL: Disponible únicamente si una transformación Source Qualifier se asocia a una o múltiples tablas relacionales. Comando SQL que Powercenter ejecutará en los destinos.

• $ParamTableName: nombre de la tabla que vamos a cargar en nuestro proceso.

• $OutputFileName1: nombre del fichero.

• $OutputFileName: nombre de otro fichero.

• $$N_FACNAC: factoring nacional.

• $$N_FACINT: factoring internacional.

• $$MONEDA: contiene la moneda con la que vamos a trabajar, en este caso ‘EUR’.

• $$F_NULA: contiene el valor de fecha nula ‘01/01/1900’

• $$F_CARGA_INF: contiene el valor de la fecha de ejecución.

• $DBConnection_Target: contiene el valor de la conexión a BBDD del Target.

• $DBConnection_Source: contiene el valor de la conexión a BBDD del Source.

• $DBConnection_Lkp: contiene el valor de la conexión a BBDD de la lookup. Los parámetros se declaran tanto en la tabla Par_Parent como en el propio mapping. La restricción de longitud de estos es de hasta un máximo de 2000 caracteres, por lo que en algunas ocasiones hay que dividir las querys parametrizadas en varios parámetros.


Ilustración 30 Tabla de parámetros dentro de PWC (Mapping Designer)

Comienzo del Mapping

Para hacer más sencillo el seguimiento del mapping lo abordaremos según la funcionalidad que se este siguiendo. Primero las transformaciones los cruces referentes a los saldos, posteriormente las facturas y finalmente la agragación de ambas.

1. Saldos de las personas que migran

En este apartado describiremos tres cruces para recuperar información de 4 tablas diferentes. La finalidad es recuperar los saldos de los clientes que van a migrar. El primer cruce será para recuperar los contratos que van a migrar, el segundo para recuperar los saldos de los clientes del Banco Popular y el cruce de estos dos anteriores será para filtrar y recuperar únicamente aquellos saldos de los contratos que van a migrar.


Ilustración 31 Cruces iniciales para obtener el saldo medio

I. Primer cruce CONTRATO_MIGRACIÓN (jnr_CONT_CONTRATO)

Lo primero que haremos será recuperar los contratos que van a migrar del Banco Popular al Banco Santander. Para ello recurrimos a las tablas:

• CONT_CONTRATO: Contiene todos los contratos de la base de datos del Banco Popular y campos

informativos sobre éstos.

Campos recuperados de la CONT_CONTRATO:

- N_ITN_CONT: Número interno de contrato.

- COD_ENT_GR: Código de entidad del grupo.

- COD_OF_GRU: Código de oficina del grupo.

- C_PRODUCTO: Código de producto.

- C_MOD_PROD: Código asignado a cada modalidad permitida en un producto.

• TCONT_PER_CONTMIGR: Contiene los contratos de los clientes del Banco Popular que van a migrar

al Banco Santander, además de otros campos informativos.

Campos recuperados de la TCONT_PER_CONTMIGR: - F_DATOS: Fecha a la que hace referencia la información censada.

- N_ITN_CONT: Número interno de contro.

- F_ALTA: Fecha de alta en la base de datos.

- REF_ITN_COMIG: Referencia interna contrato migración.

- C_SIT_CONT: Indicativo situación contrato.

- F_SIT_CONT: Fecha situación contrato


- C_SIT_MIGCONT: Código para identificar la situación en la que se encuentra la migración del

contrato.

- F_SIT_MIGCONT: Fecha de situación correspondiente a la situación indicada por el atributo

de código se situación del contrato migrado

- REF_ITN_PROMI: Referencia interna del producto en destino.

- C_ORIMODIN: Código de origen de la modificación de la información.

- CO_INAGORM: Contenido de la información. Agregación del origen de información.

- MST_MOD_INF: Fecha y hora de modificación de información en la tabla en formato

Timestamp.

- F_ACTZ: Fecha de actualización en la base de datos.

Como ya sabemos las transformaciones pueden ser traducidas a lenguaje SQL e incluirlas en un parámetro que incluimos en la transformación inicial Source Qualifier, obtenemos el mismo resultado simplificando el número de transformaciones, pero incrementado la complejidad de la query. Para poder ir viendo los resultados que vamos obteniendo a medida que avanzamos en el proceso podemos utilizar dos procedimientos:

- Si usamos transformaciones la única manera de ver los registros obtenidos es incorporando un Target que apunte a un fichero tras cada una de ellas de tal forma que podemos comprobar los datos que se han calculado hasta ese punto del mapping.

- Por otro lado, si traducimos las transformaciones de nuestro proceso de Powercenter en lenguaje SQL, podremos introducir la query en la herramienta SQL Developer y ver los registros correspondientes.

A continuación, vamos a traducir el Joiner (jnr_CONT_CONTRATO) a lenguaje SQL así tendremos una visión clara y directa de los registros obtenidos. En este caso la transformación Joiner es de tipo Normal que traducido a SQL queda como INNER JOIN. Generaremos una nueva query que unificará la query preveniente del SQ CONT_CONTRATO, la del SQ_TCONT_PER_CONTMIGR y el Joiner traducido en lenguaje SQL. Así podremos ejecutar la query en el SQL Developer para obtener los registros deseados. La primera parte de la query que comienza con una SELECT engloba todos los campos que queremos recuperar de ambas tablas. El cruce es entre las dos subSELECT posteriores. La primera subSELECT selecciona los campos de la tabla CONT_CONTRATO que queremos recuperar y filtramos los registros a fecha del 1 de enero del 2018. La siguiente subSELECT recupera los campos deseados de la tabla TCONT_PER_CONTMIGR, aplica el mismo filtro de fechas que la anterior y además asigna un valor fijo al campo C_SIT_MIGCONT. Este campo identifica la situación en la que se encuentra la migración del contrato. En nuestro caso añadiremos un filtro en el que exclusivamente pasaran aquellos contratos que estén identificados con ‘S’, es decir, son contratos que van a migrar y aun no lo han hecho. Las migraciones van en distintas batidas y la manera de distinguir si los contratos han migrado o lo van a hacer es gracias a este campo. Los registros son ordenados por número de contrato. Es importante saber que para una buena optimización del tiempo de ejecución necesitamos ordenar los registros, de este modo la búsqueda será más rápida.


Ilustración 32 Query global CONTRATO_MIGRACIÓN

Vamos a ver un ejemplo de los registros obtenidos para cada apartado de la query y para la query completa. Los registros obtenidos de la query que encontrábamos en el Source Qualifier de la tabla de contratos (SQ_CONT_CONTRATO) son:

Campos recuperados de las dos tablas

Ordenamos por el campo N_ITN_CONT

Subselect proveniente del Source Qualifier de la tabla CONT_CONTRATO.

Normal Join. Sustitución de la transformación Joiner.

Subselect proveniente del Source Qualifier de la tabla TCONT_PER_CONTMIGR.

Cruzamos por el campo N_ITN_CONT


Ilustración 33 SQ Contrato

Tabla 8 Resultado de los registros lanzada por la query

Los registros obtenidos de la query correspondiente al Source Qualifier de la tabla de migración (SQ_TCONT_PER_CONTMIGR) son:

Ilustración 34 SQ Tabla migración

Ilustración 35 Registros obtenidos de la query introducida en el SQ de la tabla de migración

Tras el cruce jnr_CONT_CONTRATO obtenemos todos los campos de ambas tablas (aunque solo veamos algunos) y los registros solo tenemos aquellos que comparten el mismo número de contrato. El resultado del cruce de las dos tablas anteriores es:


Ilustración 36 Cruce CONTRATO_MIGRACIÓN

Ilustración 37 resgistros contrato_migración

II. Segundo cruce Saldos jnr_IDV_SDO_MEDIO

El segundo cruce es para recuperar los saldos de los clientes del Banco Popular para ello recurrimos a las tablas TDGES_IDV_DETCONT y TCONT_SDO_MEDIO_DIAR. A continuación, describimos la tabla y el campo recuperado principal de cada una.

Descripción de la tabla IDV: DETALLE IDV (informe diario de variación) - CONTRATO BCO OF GBP Y BCO PASTOR

- El saldo diario SDO_CTA_DIA es el dinero que tiene la cuenta a final del día

Descripción de la tabla TCONT: SDO MEDIOS DIARIOS DE LOS CONTRATOS

- El saldo medio SDO_MDIA_CONT es el saldo medio al día desde el primer día hasta el último

calculado.

Ilustración 38 Cruce de SALDOS


Con la tabla IDV tendríamos toda la información ya que a raíz del SDO_CTA_DIA se calcula el SDO_MDIA_CONT. Para ahorrar cálculos recuperamos el campo ya existente de la tabla TCONT_SDO_MEDIO_DIAR.

Días SDO_CTA_DIA SDO_MDIA_CONT

1 10 10

2 5 7,5

3 20 (20+5+10)/3= 11,6

4 5 10

5 10 10

Tabla 9 Ejemplo cálculo Saldos

Las queries para cada SQ son las siguientes: La estructura de la query de la tabla TDGES_IDV_DETCONT en lenguaje SQL selecciona los campos que queremos recuperar de la tabla TDGES_IDV_DETCONT para una fecha concreta, en este caso nuestra fecha está en formato de parámetro, su valor lo encontramos en la tabla PAR_PARENT. Los operadores SUM y MAX, sacan la suma de todos los registros del campo SDO_CTA_DIA y el máximo de los registros del campo C_ORIG_INFIDV, respectivamente. Agrupando estas operaciones según los campos que se encuentran en el operador GROUP BY. Solemos ordenar los registros casi siempre por los campos de cruce. Asignamos un valor fijo al campo C_ORIG_INFIDV.

Ilustración 39 SQ TDEG_IDV_DETCONT

Por otro lado, la SELECT que encontramos en la query perteneciente a la tabla TCONT_SDO_MEDIO_DIAR calcula la media de los saldos medios


Ilustración 40 Query SQ TONT_SDO_DIAR

Una vez más podemos convertir la transformación Joiner, jnr_IDV_SALDOMEDIO, a lenguaje SQL, unificar las dos queries anteriores y nos quedaría como resultado una única transformación SQ con la siguiente query que englobaría a todo.

Ilustración 41 Transformación Joiner en lenguaje SQL


III. Tercer cruce CONTRATO_MIGRACIÓN

Por último, haremos el cruce por contrato mediante la transformación Joiner, jnr_TCONT_SDO_MEDIO_DIAR, recuperando los contratos únicamente que van a migrar. La transformación Joiner es de tipo master, es decir pasarán todos los registros de la tabla Detail, la tabla de Contratos a migrar, y cruzarán exclusivamente de la tabla de Saldos aquellos contratos que coincidan con los de migración. De este modo conseguimos agrupar únicamente los clientes que migran y sus datos respectos a saldos.

Ilustración 42Tercer cruce CONTRATO_SALDO

2. Factoring Nacional & Internacional

En la siguiente parte del mapping hablaremos de las facturas del Factoring. El Factoring es un contrato mediante el cual una empresa traspasa las facturas que ha emitido y a cambio obtiene de manera inmediata el dinero Las facturas del Factoring Nacional están vinculadas tanto al número de contrato, N_ITN_CONT como al número de interno a la persona N_ITN_PERS, El Factoring Internacional solo y exclusivamente está relacionado con el número interno de persona, N_ITN_PERS.


Ilustración 43 Factoring Nacional

I. Factoring Nacional

Comenzaremos explicando la query parametrizada en el SQ del Factoring Nacional. Las tablas de cruce del Factoring Nacional son: TPROD_INF_CONTNA_CLI: Información sobre las facturas.

- N_ITN_PERS: número identificativo de la persona.

- N_ITN_CONT: número identificativo del contrato

- F_ALTA_CONTRAT: Fecha en la que se crea el contrato

- F_VTO_CONT: Fecha en la que vence el contrato.

- C_ENTGR_IMPRGO: Entidad del Banco (Banco Popular = 75, Banco Santander = 49)

- C_OF_GRCOEVRG: Oficinas de la Entidad.

- C_PRODUCTO: Productos del Banco. (Tarjeta =1)

- C_MOD_PRODCIR: Las distintas modalidades del producto. (Tarjeta de crédito = 7)

TPROD_INF_FRANAC_CAR: Información sobre la propia factura.

- C_ALF_IMON: Tipo de moneda (EUR)

- IM_SDO_FCION: Campo de cálculo.

- IM_DEU_TOCOFRA: Importe de la deuda total


Un contrato puede tener varias facturas asociadas, con varios importes (cantidad de dinero a deber). Dentro de la query hay un sumatorio de los importes que se agrupan por contrato, y de esta manera podemos obtener el saldo que tiene cada contrato. En el caso del sumatorio de importes renombramos el propio campo y pasa de valer un único importe a el importe total que sería el saldo, SUM (IM_DEU_TOCOFRA). Sin embargo también queremos calcular la media de esos importes pero el campo IM_DEU_TOCOFRA ya ha sido renombrado por SALDO. Necesitamos crear un nuevo campo para asignar el valor de la media de los importes, SALDO_MEDIO, pero contamos con un inconveniente y es que en el Source Qualifier todos los campos a la entrada tienen que estar conectados, es decir no podemos crear un nuevo campo que no conecte con la tabla origen, Source. Por lo tanto la única solución es elegir un campo de la tabla que no fuéramos a utilizar y conectarlo al SQ y renombrarlo, de este modo en la query ya podremos asignarle un campo a la media de los importes, AVG (IM_DEU_TOCOFRA) AS SALDO_MEDIO y que quede conectado con el origen por el campo de entrada IM_SDO_FCION

Ilustración 44Query SQ del F_N

Una vez que ya tenemos todos los campos recuperados de las tablas de origen y ya hemos calculado los saldos por medio de la query volvemos a unos de los puntos teóricos de los que hablábamos al principio. Las facturas del Factoring Nacional pueden estar vinculadas a los contratos y personas o exclusivamente a personas. Y las del Factoring Internacional únicamente personas. Por lo tanto, el siguiente paso del mapping será dividir las facturas según su pertenencia, por número de contrato N_ITN_CONT o número interno de persona N_ITN_PERS. A las facturas que estén asociadas a las personas y no tengan contratos, se les asigna el valor de 999999999 parametrizado con el nombre de $$N_FACINT ya que no podemos meter valores nulos a los campos de la BBDD. La transformación Router divide por un lado los registros con contratos distintos al parámetro, siendo los contratos reales y el resto, los registros que tienen las facturas asociadas a las personas.


Ilustración 45Condición del Router F_N

El Router divide el mapping en dos partes definitivas hasta las tablas intermedias. Primero veremos el flujo que siguen los registros con contrato del Factoring Nacional y luego describiremos el flujo de los registros del Factoring Nacional vinculados a las personas, que se unirán con el Factoring Internacional.

Ilustración 46 Flujo Factoring Nacional


Ilustración 47 Joiner Facturas_Contratos

El próximo paso es cruzar las tablas anteriores con las que habíamos identificado los saldos de los clientes que van a migrar del Banco Popular al Banco Santander con la tabla de Factoring Nacional. Consiguiendo exclusivamente aquellas facturas de los clientes que van a migrar. La transformación Joiner, jnr_factoring_nac es de tipo Master, los campos que proviene de la tabla de contratos/saldos a migrar son de tipo Detail y las facturas, Master, por lo tanto, según la teoría, cuando el Joiner es de tipo Master pasan todos los registros de la tabla Detail y de la tabla Master solo aquellos que cruzan, es decir solo pasarán de la tabla Factoring aquellos registros los cuales sus contratos estén contenidos en la tabla de contratos a migrar. Procedemos posteriormente a la ordenación de los registros por medio de la transformación joiner, srt_FACNACIONAL. Como hemos comentado en otras ocasiones, de este modo conseguiremos reducir el tiempo de búsqueda del Joiner, optimizando el proceso. Esta ordenación será por cuenta y código origen, ya que posteriormente el Joiner cruzará por dichos campos, pero antes de realizar el cruce se hace una comprobación, ya que el campo cuenta puede proceder de distintos orígenes, y nos cercioramos de que el que vaya a cruzar no sea nulo. Pueden provenir de 3 orígenes distintos, de la tabla IDV, de saldos y de Factoring, revisaremos los cruces estudiados anteriormente para entender mejor los cálculos aplicados en la expression. En el primer cruce Master Outer Join, jnr_IDV, cruzamos por cuenta y contrato y pasará todos los registros de la tabla IDV (Detail) y los de la tabla de saldos, solo pasarán si coincide el mismo valor del contrato y cuenta de ambos flujos.


Ilustración 48 Cruce jnr_IDV

En el próximo Master Outer Joiner, jnr_Contratos_IDV, se cruza por contrato con la tabla de saldos, la cuenta IDV puede ser nula ya que proviene de la tabla Detail y puede tener registros en los que los contratos no coincidan, por lo tanto CTA_IDV no cruzaría. El Joiner del factoring, jnr_factoring_nac, nacional vuelve a ser un Master pasando todos los registros anteriores (Detail) y únicamente aquellos del factoring que coincidan en número de contrato.

Por otro lado, si anteriormente en el Joiner, CONTRATO_IDV, algún registro de la tabla Master no ha cruzado, los campos CTA_IDV y C_ORIG_INFIDV (Codigo origen de la información), son nulos, por lo tanto en la expression CTA_CONTABLE, devolveremos el valor del código origen, asignándole el valor inicial “2” y

Ilustración 49 Tres cruce referentes a cuentas


Ilustración 50 Expression Cuentas y Código origen

asignaremos a el campo CTA_IDV el valor de la cuenta proveniente del factoring CTA_CONTAB_facnac, en caso de que esta sea nula.

Ilustración 51 Expresión para la cuenta IDV

Ilustración 52 Expresión para el código de origen

Tras las expresiones añadimos la transformación Sorter, srt_IDV, para tener los registros ordenados a la entrada del Joiner, jnr_CTAIDV. Recuperamos de la tabla de relaciones entre epígrafes y cuentas IDV, TDGES_EPIGIDV_CTAIDV, el campo C_IDCIGIDV_MIS. Cruzamos por cuenta y código origen


Ilustración 53 jnr_CTAIDV

Una vez visto los cruces de las distintas tablas involucradas en este flujo, pasaremos a calcular el punto principal de este mapping, los saldos de los clientes. Para ello emplearemos dos transformaciones, una expression para el cálculo principal donde emplearemos una formula prevista en el DDS y una Lookup para cálculos auxiliares.

Ilustración 54 Cálculo de saldos


Look-up DIA:

Ilustración 55 Transformación Look_up

Después del cruce del joiner hacemos otro cruce con una lookup con la dimensión DIM_DIA para saber en qué día de la semana estamos ejecutando (1-lunes, 2-martes…), ya que interferirá en los cálculos que se harán en la siguiente expression para obtener los saldos medios, porque estos son proyectados hasta el siguiente domingo de la fecha de ejecución. Una lookup es otra forma de cruzar datos con una tabla sin tener que añadir un Source de esta, y se suelen utilizar para cruzar con tablas paramétricas o con tablas con poca volumetría, de tal forma que insertamos el/los campos por los que queremos cruzar para que nos devuelva uno o varios campos de esa tabla, en este caso introduciremos el campo “F_DATOS” cruzándolo con el campo de la tabla paramétrica DIM_DIA “F_DIA” para que nos devuelva el campo N_DIA_SEMANA. Tabla DIM_DIA:

Ilustración 56 Tabla DIM_DIA provniente de la BBDD


Expression (exp_Campos_Calculados) En esta expression tenemos principalmente tres funcionalidades: diversos cálculos en función del campo que vamos a mapear, unas validaciones de campos que pueden llegar con el valor null por no haber cruzado, ya que estos no se pueden insertar en BBDD, y parametrizaremos algunos valores fijos para otros campos. 1.- Cálculo del saldo medio propagado hasta el domingo: en el campo SDO_MEDIO_DIA nos traemos el saldo medio a día de la ejecución para ese mes, en el campo SDO_CTA_DIA recogemos el saldo en cuenta a día de ejecución y DIA_SEMANA contiene el valor que nos devolvía la lookup como 1 en función de si la fecha de ejecución es lunes, hasta 7 para el domingo, de tal modo que la fórmula para calcular el saldo medio es la siguiente:

2.- Las siguientes expresiones subrayadas en amarillo podemos ver el control de nulos sobre algunos campos:

Ilustración 57 Control de nulos

Ej: IIF(ISNULL(COD_ENT_GR),0,COD_ENT_GR) 3.- La parametrización de algunos campos subrayado en amarillo:


Ilustración 58Parametrización en la transformación Expression

Ej: $$MONEDA En la siguiente transformación nos encontramos un router el cual divide los registros en varios flujos, en este caso en dos, se llevan a tabla si hay cruces con los contratos de la migración y a fichero de errores si no mediante la siguiente sentencia: “IIF((ISNULL(N_ITN_CONT_IDV) AND ISNULL(N_ITN_CONT_facnac)) OR ISNULL(SDO_MED_POSCV) OR ISNULL(C_IDCIGIDV_MIS),1,0)“

Ilustración 59 Condición para la división de los campos del Router

Después de este router nos encontramos con dos Targets, tablas de destino, uno que carga en BBDD a la tabla TMIG_INT_SDO_CONT con los registros que cruzaron previamente y que traen toda la información requerida para poder ser cargados y los que no cruzaron que irán a un fichero de errores para poder ser analizados posteriormente (ERRORES_TMIG_SDO_PER_CONT.dat)


Ilustración 60 Recogida final a los Target

II. Factoring Internacional

Comenzaremos a desarrollar la segunda parte del mapping referente a facturas. Como comentamos anteriormente las facturas del Factoring Nacional (F_N) quedan divididas en dos flujos, las relacionadas por contratos y las relacionadas por persona. Previamente hemos descrito el flujo de las facturas por contrato. Ahora unificaremos las facturas del Factoring Nacional vinculadas a personas con el Factoring Internacional (F_I). Éste únicamente identifica las facturas con el número interno de persona.

Ilustración 61 Unificación F_N y F_I


Volviendo a la unión del F_N y el F_I, el contrato no conecta del Router, rtr_FACNACIONAL, al Union, un_FACTORING, a partir de ahora relacionamos tablas por personas N_ITN_PERS. Los campos del F_N y del F_I son los mismos pero los nombres varían según la tabla de procedencia. Al final en el Union todos los campos se llamarán igual, como podemos ver con el campo COD_OFGRU_ENV pasa a llamarse C_OF_GRCOEVRG22 conservando el mismo valor.

Ilustración 62 Transformación Union para el Factoring Nacional

Anteriormente la tabla de facturas del F_N vinculada a contratos la cruzamos con la tabla de contratos a migrar, para poder filtrar y quedarnos únicamente con los contratos deseados. En este caso tenemos que hacer lo mismo, pero en vez de cruzar por contrato cruzamos por número interno de persona obteniendo así las facturas del Factoring Nacional e Internacional de las personas que van a migrar del Banco Popular al Banco Santander. El Joiner es de tipo Detail, la tabla personas es Master, por lo tanto, todos sus registros pasarán y solo aquellos del factoring que compartan el mismo número de personas también Como siempre para una mayor optimización del tiempo de búsqueda, ordenamos los registros que entran en el Joiner por medio de un Sorter.

Ilustración 63 Cruce Factoring con Personas a migrar


Posteriormente haremos un cruce para asignarle un segmento y para finalizar concluiremos con la agregación de los registros para ambos flujos de Factoring. Recogemos los datos tratados en una transformación Target en formato de fichero f_Shortcut_to_TMIG_INT_SDO_CONT. Por otro lado, los registros que no hayan cumplido la condición de paso del Router derivan en el fichero de errores de personas.

Ilustración 64 ase final Factoring Nacional

Tras acabar el mapping, ejecutamos el script ‘’lanzaworkflow’’ en la aplicación de Putty. La ventana de trabajo Monitor nos informa del resultado de la ejecución, “succeeded” en caso de que el proceso haya ido correctamente y “failed” en el caso opuesto. A continuación, lanzamos el script de normativa descrito en los conceptos generales. Una vez que hayamos finalizado con este tema estamos preparados para subir el proceso al entorno de PRE, donde repetiremos las ejecuciones con datos reales. Al proceso de CAL como comentamos le siguen el proceso de validación y extracción. En el proceso de validación nos cercioramos de los datos obtenidos y en el de extracción nos encargamos de convertir la tabla final en un fichero. Tras acabar el proceso y haber obtenido los datos demandados por el Banco, el próximo paso es hacérselos ver. Para ello hacemos un FTP (movimiento de archivos) del fichero final a una carpeta común, MFT, que sirve como puente entre la empresa externa de desarrolladores informáticos y el Banco Santander. Queda en elección del proyecto usar herramientas como MicroStrategy para informar de una manera más gráfica y comprensible. En nuestro caso no ha sido requerida por lo tanto la entrega es en formato de fichero plano.


4.1.3 Conclusión

En este caso práctico nos hemos centrado única y exclusivamente en la construcción y desarrollo de un proceso de cálculo con una herramienta ETL junto a todo el entorno de trabajo que lo hace posible. Hemos conseguido clasificar, reorganizar y tratar toda la información relacionada con los Saldos y Facturas de los clientes que migran del Banco Popular al Banco Santander. Posteriormente como se comentó al principio del proyecto tras el desarrollo del mapping de cálculo se lleva cabo el de validación y extracción. El fichero resultante generado por el mapping de extracción será trasladado por un FTP a Transformación. La elaboración de los mapping va acompañada de numerosas horas de pruebas, revisiones y cambios. Conlleva muchas horas de trabajo, paciencia y atención. El tratamiento de datos masivos con este tipo de herramientas es delicado y hay que ser minucioso a la hora de llevarlo a cabo. Gracias al control de errores con el que cuenta la herramienta de PWC nos reduce considerablemente los fallos futuros. Junto a este proceso de Saldos también he trabajado en las modificaciones de otros como Intereses y Comisiones.


5 Conclusión

Para las empresas no existe el destino ni las casualidades. Nos estudian y nos guían porque conocen nuestras necesidades e inquietudes, lo más sorprendente es que nos seguimos preguntando cómo pueden leer nuestra mente y tan solo están recopilando toda la información que vamos dejando desmigajada. Este proyecto me ha ayudado a entender una pequeña parte del gigantesco mundo de los datos. El trabajo que sigo diariamente me especializa en una herramienta concreta, pero haber estudiado más a fondo el Business Intelligence me ha hecho desarrollar una percepción y un conocimiento mucho más amplio. He aprendido el análisis interno de los Bancos, me he familiarizado con varias de las herramientas presentes hoy en día de tratamiento de datos y presentación de resultados. He podido comprender lo valioso que es tener información específica, concreta y útil para tomar ciertas decisiones. Trabajar en una empresa tan grande me ha hecho evolucionar mucho tanto en el ámbito laboral como en el intelectual. Además, gracias al ahínco que he prestado por desarrollar este proyecto he conocido mucho mejor la materia y sobre todo gracias al conocimiento he podido disfrutarla. Con la teoría aplicada y el caso práctico desarrollado logramos comprender el concepto de BI, la funcionalidad de la herramienta ETL Powercenter, las distintas aplicaciones que la acompañan, el flujo de datos de una migración y sobre todo el esfuerzo tan gigantesco que se lleva a cabo “simplemente” para clasificar a los clientes de un banco según su situación financiera.


6 Bibliografía

Business Intelligence

[1] Peter Luhn, H. A Business Intelligence System. Publicado por: IBM journal, pp 314-319, 1958. [2] Nogués, Albert & Valladares, Juan. Business Intelligence Tools for Small Companies: A Guide to Free and Low-Cost Solutions. s.l. : Apress, 2017. [3]. Roldán , José & Cepeda, Carrion & Galán, José. Los sistemas de inteligencia de negocio como soporte a los procesos de toma de decisiones en las organizaciones. Publicado por: Papeles de Economía Española, pp. 239-260, 2012. [4]. EOWC & EORN. eBusiness Tool Kit for Small and Medium-sized Enterprises (SMEs). 2016. [5] Parvatiyar, Atul & Sheth, Jagdish. Customer relationship management: Emerging practice, process, and discipline. Journal of Economic and Social Research. 3. Pag. 1-34. (2001). [6] Dayal, Umeshwar & Castellanos, Malu & Simitsis, Alkis & Wilkinson, Kevin. Data Integration Flows for Business Intelligence. Saint Petersburg, Russia, 2009. [7]Chaudhuri, Surajit & Dayal, Umeshwar & Narasayy Vivek . An Overview of Business Intelligence Technology. Publicado por: Communications of the ACM, Vol. 54. no. 8. pp 88-98, 2011 [8] Cano, Josep Lluís. BUSINESS INTELLIGENCE: COMPETIR CON INFORMACIÓN. Decano de ESADE Business School. Herramientas BI 9 KHAIRA, Dr. Jaiteg Singh. A comparative Review of Extraction, Transformation and Loading Tools. Publicado por: Database Systems Journal, Vol. IV. no. 2, 2013.

[10]. Runtuwene, J P A & Tangkawarow, I R H T & Manop, C T M. A Comparative Analysis of Extract, Transformation and Loading (ETL) Process. Publicado por: IOP Publishing. Materials Science and Engineering 306. Sulawesi Utara, Indonesia, 2018. Páginas webs oficiales de las compañia: [11] Microsoft - SQL Server Integrated Services: https://www.ibm.com/analytics/information-server. Último acceso: 24/6/2018 [12] Informatica – Powercenter: https://www.informatica.com/es/products/data-integration/Powercenter.html. Último accesso: 13/5/2018. [13] Talend - Open Studio for Data Integration: https://es.talend.com/products/talend-open-studio/ Último acceso : 30/6/2018 [14] Oracle - Data Integrator: http://www.oracle.com/technetwork/middleware/data-integrator/overview/index.html Último acceso: 24/6/2018 [15] Microsoft. SQL Server 2012 Le Ofrece Características Más Avanzadas. 2012. Último acceso: 30/6/2108 [16] SAS - Data Integration Studio: http://support.sas.com/software/products/etls/index.html. Útimo acceso: 30/6/2018 [17] SAS. SAS Data Integration Studio 4.2 User’s Guide. ISBN 978-1-59047-960-5. 2009 Útimo acceso: 30/6/2018 [18] Kettle - Pentaho Data Integration: https://www.hitachivantara.com/en-us/products/big-data-integration-analytics/pentaho-data-integration.html Útimo acceso: 24/6/2018



https://www.informatica.com/es/products/data-integration/Powercenter.html

https://www.informatica.com/es/products/data-integration/Powercenter.html











[19] Clover - CloverETL https://www.cloveretl.com/ Útimo acceso: 30/6/2018 [20]. MicroStrategy. Guía básica de elaboración de informes. Vigesimosegunda edición, Versión 9.2.1. Número de documento: 09490921, 2012 [21]. MicroStrategy. GUÍA AVANZADA DE ELABORACIÓN DE INFORMES. Segunda edición, versión 7.2.1, 2002. Normativa PWC Documento de regulación de procesos. Normas que seguir para trabajar con buenas prácticas. [22] POWERCENTER. Normativa de Desarrollo. ARQUITECTURA Y SOPORTE AL DESARROLLO. Desarrollo PWC Documento interno de la empresa. ST_DDS Integración Banco Popular CdG-Extracción – ODS_Saldos. Marzo 2018

ST_DDS Integracion Banco Popular_CdG_Extraccion_ODS_SALDOS_v1.6.docx

https://www.cloveretl.com/

Documents

Business Intelligence adaptado a la migración masiva de ...bibing.us.es/proyectos/abreproy/92007/fichero/TFG... · Business Intelligence adaptado a la migración masiva de datos