Análisis Técnico

LANDING COLECTIVOS.
Product Owner Eduardo Pichipil
Responsable IT Evelyn Alvarez
Developer Célula Colectivos
Fecha de creación 2023/04/14
Fecha de actualización
Versión 1.0
1 CONTENIDO

1 Version..........................................................................................................................................................2
2 Identificación de la Iniciativa............................................................................................................2
3 Informacion General.....................................................................................................................................3
3.1 Descripcion del Proyecto....................................................................................................................3
3.2 Objetivo del Proyecto.........................................................................................................................3
4 Alcance del Análisis Técnico.........................................................................................................................4
5 Análisis Técnico............................................................................................................................................5
5.1 Diagrama ENTIDADES MODELO Stock de polizas...............................................................................5
5.2 anexos.................................................................................................................................................8
5.3 CONCIDERACIONES, SUPUESTOS Y RESTRICCIONES...........................................................................8
1 VERSION

Versión Descripción VoBo Fecha

1.0 Creación de Documento 2023-04-14

2 IDENTIFICACIÓN DE LA INICIATIVA.

EPICA Creación Landing Colectivos

Patrocinador(es) Eduardo Pichipil L.

Líder(es) de Iniciativa Eduardo Pichipil L.

Líder de Proyecto Vida Evelyn Álvarez

Líder Técnico Célula Juan Franco

Consultor de Proceso de Negocio

Líder Técnico Vida Diego Vicencio

Especialista de desarrollo Célula Colectivos

Responsable Célula (Lider

Carlos Fuentes
Agilidad)
3 INFORMACION GENERAL

3.1 OBJETIVO DEL PROYECTO

Este nuevo alcance se plantea para entregar una solución inmediata a la necesidad de DESAFIO 4, donde
el principal objetivo es crear un repositorio de datos, idéntico en estructura que el CORE de colectivos,
con el fin de que en el futuro este resuelva cualquier necesidad operacional del negocio, como
reportaría, incluso alimentar el DATALAKE. Inicialmente se planteó construirlo en el ON-PREMISE de vida,
pero en un futuro se evaluará colocar esta solución en la NUBE de VIDA. La célula está evaluando este
nuevo requerimiento y analizando matices técnicos para proponer las futuras historias de usuario en
cuanto a este nuevo objetivo.

4 ALCANCE DEL ANÁLISIS TÉCNICO

En este análisis participaron los siguientes actores:

 Evelyn Alvarez como Lider del área de TI de Vida.

 Diego Vicencio como Lider Técnico de Vida.
 Jorge Fernandez como arquitecto de la célula.
 Célula de colectivos.

En esta discusión se definieron y acordaron los siguientes puntos:

 Diseño de la BBDD Landing de Colectivos.

 Diseño del proceso de carga de la BBDD Landing Colectivos.
 Diseño de una BBDD dedicada para contener reglas particulares y universales de negocio y objetos
dedicados a resolver casos de usos.
 Diseño de solución a entregar al caso de uso Desafío 4.
5 ANÁLISIS TÉCNICO

5.1 DISEÑO BASE DE DATOS LANDING COLECTIVOS.

Hemos acordado con el área de TI de VIDA hacer un diseño de base de datos que cumpla con las
siguientes características:

 La base de datos contendrá todas las tablas de negocio de colectivos, de los CORE PEHUEN y
ACSEL, que están contenidas en la base de datos del STAGING de colectivos.
 La BBDD Landing de colectivos contendrá toda la historia de información existente, tal como se
encuentran en los CORE de PEHUEN y ACCSEL.
 El origen de los datos para esta BBDD LANDING será el STAGING de colectivos.
 Las tablas no sufrirán ningún tipo de transformación ni en estructura ni en datos, se
mantendrán tal como son sacadas del CORE y llevadas al STAGING.

5.2 DISEÑO DEL PROCESO DE CARGA DE LANDING COLECTIVOS.

Según los acuerdos con el área de TI, el proceso de carga de la base de datos del Landing de Colectivos
tendrá las siguientes características:

1. Sera desarrollado bajo la tecnología Microsoft SQL Server Integration Services.

2. Sera un proceso aislado que solo se encargue de alimentar la base de datos LANDING Colectivos.
3. El proceso no contemplará el llenado inicial de la base de datos, este proceso, debido a la gran
cantidad de información, se hará de manera manual y por partes (estrategia ya definida).
4. El objetivo del proceso será cargar la base de datos del LANDING, usando como fuente de
información el STG de colectivos.
5. Para las tablas transaccionales, el proceso ubicará en la base de datos de STAGING, el periodo de
información que se encuentra almacenado (utilizando la fecha ya predefinida) para posteriormente
eliminar ese bloque de datos del LANDING e insertarlo con la información actualizada.
6. Para las tablas maestras, el proceso truncara la tabla y la poblara nuevamente en cada ejecución.
7. El proceso registrará en una tabla de LOG, cada ejecución, identificándola con un ID, y nos informará
el estado de cada una de las tablas cargadas.
8. Con respecto al reproceso, este punto esta aun en discusión, ya que se esta evaluando la factibilidad
de esta funcionalidad, basándonos en cómo es la dinámica de carga de datos en el STAGING de
colectivos.
5.3 DISEÑO BASE DE DATOS REGLAS Y CASOS DE USO.

Esta base de datos nace debido a la necesidad de mantener la base de datos del LANDING libre de
elementos que no pertenezcan originalmente a la operación. Como premisa principal se plantea al
LANDING como una base de datos que contiene una estructura ORIGINAL en función a su origen, más
allá de las transformaciones requeridas por el cambio de tecnología entre ORACLE y SQL Server.

Partiendo de esta premisa se acordó:

1. Crear una base de datos (NOMBRE AUN NO DEFINIDO) que nos permita almacenar todas las
reglas de negocio particulares y universales que puedan ser necesarias para atender algún paso
de uso en particular.
2. Esta base de datos también almacenara todos los objetos (Vistas, SP, Funciones, etc.) creados
con la finalidad de cubrir necesidades particulares del negocio (casos de uso).
3. Esta base de datos se alimentará únicamente de la información almacenada en el LANDING de
colectivos, y hará referencia a todas las tablas a través de sinónimos.
4. Eventualmente, se podrán agrupar las distintas soluciones que residan en esta base de datos,
con objetivos distintos, utilizando esquemas, lo que permitirá aislar la permisología para utilizar
solo los objetos que la necesidad en particular demande.

5.4 DISEÑO SOLUCION CASOS DE USO DESAFIO 4.

Entendemos como equipo de trabajo que existe un proyecto en VIDA SECURITY que persigue la
optimización de los procesos operacionales, y para esto, hay un equipo de trabajo generando consultas
que van directo a recabar información en los CORE de colectivos.

Este proyecto nace de la necesidad de alivianar la carga del CORE yendo a hacer este tipo de consultas a
una fuente de datos alterna.

Cada una de estas queryes responden a un reporte en particular como fuente inicial de información a
analizar, por lo cual, tenemos el objetivo de adaptar cada una de estas consultas para que puedas
recabar la información en la base de datos del LANDING, pero residiendo en la base de datos de reglas y
casos de uso.

Dicho esto, el objetivo es construir en la base de datos de reglas y consumo, todos los objetos necesarios
para recoger esta información a demanda, utilizando como fuente de datos el LANDING de colectivos,
obteniendo los mismos resultados que nos entregaría el CORE, teniendo en cuenta el desface que
podamos tener debido a la periodicidad de carga.

5.5 CONCIDERACIONES, SUPUESTOS Y RESTRICCIONES.

Puntos a considerar:

1. Para el caso de reproceso, tenemos algunos casos de borde que ponen en riesgo la integridad
de la información. Este asunto será atendido por la célula en conjunto con el arquitecto, con el
fin de encontrar una solución y plantearla al área de TI.