propuesta metodolÓgica para la implementaciÓn de un
TRANSCRIPT
PROPUESTA METODOLÓGICA PARA LA IMPLEMENTACIÓN DE UN ALMACÉN DE DATOS OPERACIONALES - ODS
José Antonio Rodríguez Niebles
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA DE SISTEMAS MAGÍSTER EN INGENIERA DE SISTEMAS Y COMPUTACIÓN
BOGOTA, 2003
PROPUESTA METODOLÓGICA PARA LA IMPLEMENTACIÓN DE UN ALMACÉN DE DATOS OPERACIONALES - ODS
José Antonio Rodríguez Niebles
Tesis para optar al título de Magíster en Ingeniería de Sistemas y Computación
Asesor : José Abásolo
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA DE SISTEMAS MAGÍSTER EN INGENIERA DE SISTEMAS Y COMPUTACIÓN
BOGOTA, 2003
PROPUESTA METODOLÓGICA PARA LA IMPLEMENTACIÓN DE UN ALMACÉN DE DATOS OPERACIONALES - ODS
José Antonio Rodríguez Niebles
Tesis para optar al título de Magíster en Ingeniería de Sistemas y Computación
Asesor : José Abásolo
I.S., D.E.A. Informática, Univ. de Paris Dauphine
Jurados : Olga Lucía Giraldo
I.S., D.E.A. en Informática, Univ. Joseph Fourier, Grenoble
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA DE SISTEMAS MAGÍSTER EN INGENIERA DE SISTEMAS Y COMPUTACIÓN
BOGOTA, 2003
iv
En la vida siempre se encuentran obstáculos, pero con mucha fé se pueden vencer. Este trabajo es fruto de la persistencia, no hubiese podido ser concluido sin el apoyo brindado por mi familia y mi novia, Olga. Me siento muy orgullosos de estar rodeado de ellos.
v
AGRADECIMIENTOS
El autor expresa sus agradecimientos a:
José Abásolo, Ingeniero de Sistemas y Computación, Universidad de los Andes (Colombia). Doctor de 3er Ciclo en Informática, Universidad de Paris Dauphine (Francia). Por su colaboración y Orientación. Olga Lucia Giraldo, Ingeniera de Sistemas y Computación, Universidad de los Andes, 1975. D.E.A. en Informática, Universidad Científica y Médica Joseph Fourier, Grenoble, Francia,1978. Por su colaboración. Angela Carrillo, Ingeniera de Sistemas y Computación, Universidad de los Andes, 1996. Magíster en Ingeniería de Sistemas y Computación, Universidad de los Andes, 1998. Por su colaboración y consejos. Silvia Takahashi, Ingeniera de Sistemas y Computación, Universidad de los Andes, 1987.M.Sc., Tulane University (EUA)1991 Phd , Tulane University (EUA)1994. Por su colaboración.
Nelson Darío Mora, Ingeniero de Sistemas, Universidad Nacional de Colombia, 1997. Gerencia de Empresas de Telecomunicaciones, Universidad de los Andes , 2002. Por su colaboración.
MISC-03-1-9
vi
TABLA DE CONTENIDO
INTRODUCCIÓN............................................................................................................. 11 1 OBJETIVOS ............................................................................................................. 13
1.1 OBJETIVO GENERAL....................................................................................... 13 1.2 OBJETIVOS ESPECIFICOS.............................................................................. 13
2 HETEROGENEIDAD DE BASES DE DATOS........................................................... 14 2.1 ¿POR QUÉ SE DEBE INTEGRAR LAS DISTINTAS BASES DE DATOS?........ 14 2.2 INTEROPERABILIDAD Y FALTA DE INTEGRACION....................................... 16 2.3 DEFINICIÓN DEL PROBLEMA ......................................................................... 19
3 ALCANCE................................................................................................................. 21 4 ESTADO DEL ARTE................................................................................................. 22
4.1 POSIBLES SOLUCIONES AL PROBLEMA DE LA INTEGRACIÓN DE DATOS22 4.1.1 SISTEMAS MULTIBASES DE DATOS....................................................... 22 4.1.2 DATA WAREHOUSE o BODEGA DE DATOS (DW) .................................. 34 4.1.3 ODS ( Almacén de Datos Operacionales)................................................... 36
5 RESUMEN DEL ESTADO DEL ARTE...................................................................... 39 5.1 COMPARACIONES ENTRE TECNOLOGÍAS PROPUESTAS .......................... 40 5.2 CONCLUSIONES DE LAS SOLUCIONES PROPUESTAS ............................... 41
6 ¿QUÉ SE DEBE HACER PARA IMPLEMENTAR LA SOLUCIÓN ESCOGIDA?....... 43 6.1 TEMAS A SOLUCIONAR EN LA PROPUESTA DE CONSTRUIR UN ODS...... 44
6.1.1 Metadatos................................................................................................... 44 6.1.2 ¿Qué clase de ODS se va a Implementar?................................................. 45 6.1.3 ¿Cómo se deben capturar las modificaciones? .......................................... 46 6.1.4 ¿Cómo se cargaran los datos?................................................................... 46 6.1.5 ¿Cómo se va definir el registro del sistema? .............................................. 47 6.1.6 ¿Cómo se van a mover los datos al ambiente ODS?.................................. 47 6.1.7 ¿Qué sucede cuando no este activa una fuente de datos o el ODS? ......... 48 6.1.8 ¿ Costos de implementar un ODS? ............................................................ 48 6.1.9 ¿ODS centralizado o distribuido? ............................................................... 49 6.1.10 ¿Volumen de datos del ODS? .................................................................... 49
6.2 ¿CÓMO SABER SI ES NECESARIO LA IMPLEMENTACIÓN DE UN ODS?.... 49 6.3 HERRAMIENTAS DISEÑO E IMPLEMENTACIÓN............................................ 50
6.3.1 WORKFLOWS............................................................................................ 50 7 ANALISIS DE DIFERENTES METODOLOGIAS ENFOCADAS AL ANALISIS DE INFORMACION ............................................................................................................... 53
MISC-03-1-9
vii
7.1.1 Metodología de Minería de Datos: El ciclo virtuoso.................................... 53 7.1.2 Metodología de Modelamiento Dot ............................................................. 57 7.1.3 Metodología de Desarrollo de un ODS ....................................................... 66 7.1.4 Análisis de Metodologías relacionadas con DW y Minerías de Datos ......... 68
8 PROPUESTA METODOLÓGICA PARA LA IMPLEMENTACION DE UN ODS......... 71 8.1 ANALISIS Y DISEÑO......................................................................................... 72 8.2 DESARROLLO ................................................................................................ 108 8.3 APROBACION................................................................................................. 110
9 CASO DE ESTUDIO – INTEGRACION DE SERVICIOS EN UNA EMPRESA DE TELECOMUNICACIONES............................................................................................. 112
9.1 ANÁLISIS ........................................................................................................ 112 9.2 AMBIENTE DE IMPLEMENTACION Y RESTRICCIONES DEL PROTOTIPO. 114 9.3 ETAPAS DE DESARROLLO ........................................................................... 115
9.3.1 Escogencia de la Herramienta de Workflow.............................................. 116 10 RESULTADOS ESPERADOS............................................................................. 117 CONCLUSIONES.......................................................................................................... 119 TRABAJO FUTURO ...................................................................................................... 121 BIBLIOGRAFIA.............................................................................................................. 122
MISC-03-1-9
viii
LISTA DE ANEXOS Pág.
Anexo 1. Formato propuesto de Requerimiento Funcional. 124
Anexo 2. Modelo de datos de las fuentes. 125
Anexo 3. Modelo de datos del ODS. 126
Anexo 4. Definición de Transformaciones 127
Anexo 5. Diseño de los Metadatos del ODS. 128
Anexo 6. Formato Documento de Flujos de Trabajo. 129
Anexo 7. Diseño Físico del ODS y sus Metadatos. 130
Anexo 8. Diseño de la Interfaz para acceso al ODS y a los Metadatos. 131
Anexo 9. Formato de Chequeo de Pruebas. 132
Anexo 10. Análisis, Diseño e Implementación del prototipo en el Caso de Estudio -
Integración de Servicios en una empresa de Telecomunicaciones.
133
MISC-03-1-9
ix
LISTA DE FIGURAS
Pág. Figura No. 1 : Clasificación de los Sistemas Multibases de Datos [Ga2001] 23
Figura No. 2. Componentes de una base de datos federadas [Ga2001] 24
Figura No. 3 : Consulta de Información en una Multibase de Datos [Ro1999] 25
Figura No. 4 : Arquitectura del Sistema CORDS [At1995] 31
Figura No. 5 : Arquitectura de un DataWarehouse [B&D] 35
Figura No. 6 : Flujo de Información desde Sistemas Operacionales hacia Repositorios Corporativos. [In1999].
39
Figura No. 7 : El ciclo virtuoso de la Minería de Datos. [Be2002] 54
Figura No. 8 : Flujo de Implementación de un ODS. 72
Figura No. 9 : Cargue y Actualización en un ODS. 85
Figura No. 10 : Diagrama de Flujo de procesos para el cargue de un ODS. 88
Figura No. 11 : Grafo de Flujo de Procesos para el Cargue Inicial de Tablas Maestras en un ODS.
90
Figura No. 12 : Grafo de Flujo de Procesos para el Cargue Inicial de Tablas de Hechos en un ODS.
93
Figura No. 13 : Diagrama de Flujo de Procesos para el Cargue Inicial de Tablas Maestras en un ODS.
93
Figura No. 14 : Grafo de Flujo de Procesos para el Cargue Incremental de Tablas Maestras en un ODS.
96
Figura No. 15 : Grafo de Flujo de Procesos para el Cargue Incremental de Tablas de Hechos en un ODS.
98
Figura No. 16 : Diagrama de Flujo de Procesos para la Integración de Tablas sobre el Esquema Global.
99
Figura No. 17 : Grafo de Flujo de Procesos para la Integración de Tablas en el Cargue Inicial en un ODS.
102
Figura No. 18 : Grafo de Flujo de Procesos para la Integración de Tablas en el Cargue Incremental en un ODS.
104
MISC-03-1-9
x
LISTA DE TABLAS
Pág. Tabla No. 1. Cuadro comparativo entre Tecnologías Propuestas para solucionar
la Integración de Información.
41
Tabla No. 2. Análisis de distintas metodologías relacionadas con Bodegas de
Datos y Minería de datos.
69
Tabla No. 3. Completitud de Entidades. 77 Tabla No. 4. Completitud de Campos. 78 Tabla No. 5. Paso Directo de Fuentes a tablas del ODS. 80 Tabla No. 6. Paso Directo de Fuentes a tablas temporales del ODS. 81 Tabla No. 7. Transformaciones entre Entidades. 81 Tabla No. 8. Tabla de Variables del ODS. 85 Tabla No. 9. Tabla de Logs de los procesos en el ODS. 107 Tabla No. 10. Tabla de los Metadatos en el ODS. 107 Tabla No. 11. Cuadro comparativo entre dos herramientas de Workflow. 117
MISC-03-1-9
xi
GLOSARIO
Esquema de la Base de Datos
Estructura lógica de los datos que se encuentra en una Base de datos, el esquema de la
base de datos representa la descripción de los datos de la base de datos
Metadatos
Los metadatos o la metadata son datos acerca de los datos. Se trata del conjunto de
informaciones que permite identificar ciertas características de los datos cargados en
Repositorio como un ODS o DW.
OLAP
Los sistemas OLAP (On-Line Analytical Processing) se han concebido para responder
explícitamente a las necesidades de soporte a la toma de decisiones.
OLTP
Los sistemas OLTP (On-Line Transaction Processing) corresponden a los sistemas de
producción de una organización.
Sistema Manejador de Base de datos (SMBD)
Es el software encargado de administrar la base de datos, controla la creación,
determinar, permitir consultas, soportar el almacenamiento y controlar la seguridad.
Workflow
Permite el control de los procesos administrativos para la automatización, el control y el
seguimiento de la información. El workflow es la gestión electrónica de los procesos, la
automatización de los flujos y, en su caso, la instalación de sistemas de validación.
MISC-03-1-9
11
INTRODUCCIÓN Las compañías grandes y medianas, que adicionalmente disponen de un tipo de negocio
que es muy cambiante, generalmente poseen múltiples aplicaciones que son
heterogéneas tanto en su SW, HW, estructuras de datos, etc. Esto surge porque las
mismas empresas ante el crecimiento rápido del mercado y la presión por no quedarse
atrás dan soluciones rápidas y no del todo organizadas. Así mismo las diferentes
operaciones entre empresas como fusiones ó adquisiciones origina que los sistemas
propios de estas empresas sean integrados rápidamente. Obviamente esto crea un
imprevisto en los departamentos de sistemas, que debe ser sorteado con la mayor
prontitud. Las interfaces deben ser creadas rápidamente para comunicar los sistemas.
Ante este tema de heterogeneidad surgen dentro de la compañía elementos que se
encargan de velar que los datos sean consistentes entre los sistemas y que además se
vean de manera integrada. Viendo a todos los sistemas como uno solo, ya que hacia el
exterior de la compañía no se puede percibir este ambiente dividido. Existen distintas
soluciones que dependen de la funcionalidad y eficiencia que se requiera. La necesidad
de la organización puede ser de sólo consulta para toma de decisiones o todo un manejo
transaccional. Las soluciones mas avanzadas pueden requerir establecer Interfaces por
medio de Multibase de datos, ODS ( Almacén de Datos Operacionales ), Ontologías,
Sistemas Middleware como CORBA ( Common Object Request Broker Architecture ) entre
otros. Cada uno de estos puede ser una solución pero se debe ser muy cuidadoso en
escoger la apropiada en cada caso, ya que al equivocarse en la elección podría estar
subutilizado y se estaría incurriendo en gastos muy altos.
Con este proyecto de Tesis se realiza una propuesta metodológica que permita analizar,
diseñar, desarrollar e implementar un ODS para la integración operacional de distintas
bases de datos heterogéneas que poseen un dominio común. La metodología se trabaja
sobre la premisa que estas bases de datos soportan sistemas operacionales. La
MISC-03-1-9
12
propuesta esta enfocada a establecer una serie de procedimientos a seguir que permitirán
levantar fácilmente los programas ETL necesarios para la correcta integración y cargue de
esta información en el ODS. Se aprovechara la documentación existente sobre Sistemas
de Flujos de Trabajos o Workflows. Ya que según el análisis hecho muchas de las
características presentes en el cargue de la información en repositorios como un DW o un
ODS son similares a sistemas Workflow.
MISC-03-1-9
13
1 OBJETIVOS
1.1 OBJETIVO GENERAL
Exponer una propuesta metodológica que permita la consulta de información sobre un
ambiente de Múltiples Bases de Datos Operacionales, permitiendo con ello la integración
de estos bancos de información, implementándose con la ayuda de un ODS.
Desarrollar y Validar esta propuesta metodológica que permita la implementación de
Almacenes de Datos Operacionales (ODS)
1.2 OBJETIVOS ESPECIFICOS
Establecer los pasos necesarios para la obtención de la información entre múltiples
bases de datos heterogéneas operacionales con un dominio común de información.
Aplicar la propuesta metodológica implementándola en el desarrollo de un prototipo
que permita la solución a un inconveniente de falta de información operacional,
integrada y casi en línea en una empresa de Telecomunicaciones.
Establecer una interfaz grafica al usuario que le permita realizar la consulta de
información sobre el Almacén de Datos Operacionales.
MISC-03-1-9
14
2 HETEROGENEIDAD DE BASES DE DATOS
La heterogeneidad en una organización puede ocurrir a nivel del hardware y sistema
operativo, al nivel de comunicación, al nivel de DBMS y en el ámbito semántico. El
problema que estamos abordando en esta tesis aquí corresponde a un problema de
Bases de Datos Heterogéneas que poseen un dominio común.
Se ha discutido durante muchos años el tema de heterogeneidad así como la distribución
de Base de Datos. La información puede estar distribuida por muchos motivos entre ellos
están los siguientes:
• Disponibilidad de la información. Al tener distribuida la información es menos
probable que se caiga todo el sistema en caso de una falla.
• Plataformas de servicios a usuarios. Por ejemplo, Una empresa de servicios de
telecomunicaciones donde los servicios de Short Message (Mensajes de Texto),
VoiceMail (Mensajes de Voz) se encuentran en sistemas diferentes ofreciendo
servicios a un mismo conjunto de clientes.
• Crecimiento debido a fusiones. Dos o más empresas que se fusionan pueden
tener sistemas distintos, que deben ser integrados rápidamente para atender las
necesidades de los usuarios.
• Razones organizacionales. Una empresa u organización que se encuentra
dividida entre diferentes puntos regionales. Por ejemplo Una central de
operaciones y diferentes sucursales.
2.1 ¿POR QUÉ SE DEBE INTEGRAR LAS DISTINTAS BASES DE DATOS?
Cuando se disponen de diferentes sistemas de BD e interpretación diferentes no es
posible hablar un mismo lenguaje. Esto complica la situación en una comunicación tanto
al nivel interno a la compañía como al nivel externo.
MISC-03-1-9
15
Recopilar la información que proviene de diferentes BDs y almacenarla en un repositorio
no es fácil, ya que generalmente se debe realizar aplicaciones a la medida para
conseguir los datos. La transmisión de los datos entre BD es compleja. Además si se
tienen bases de datos heterogéneas se complica mucho más esta función. ¿Cuál es la
razón de esto? La razón es que se manejan diferentes SMBD ( Sistema Manejador de
Base de Datos), el rendimiento de cada uno de ellos es distinto, así mismo los formatos
de datos que se manejan en una BD pueden interpretarse de manera distinta en otra.
Generalizando el problema aquí planteado hacia diferentes tipos de empresas que
manejan bases de datos heterogéneas, con dominios de información similar y que tienen
la necesidad de una visión integrada de la información operacional, se busca establecer
una estrategia de acceso a esta información, causando un mínimo impacto en las fuentes
originales.
Ejemplos
Supongamos el caso en que una compañía de servicios de telecomunicaciones dispone
de diferentes sistemas de información con sus respectivas bases de datos, siendo estas
heterogéneas. Cada uno de estos sistemas soporta y posee los datos necesarios para
brindar un servicio en particular al cliente. Un cliente puede tener uno o más servicios de
los que se brindan en las diferentes plataformas. Adicionalmente cada uno de estos
sistemas tiene que comunicarse con los otros para establecer si al cliente se le debe
brindar el servicio o no. Ya que en casos como falta de pago, fraude o robo, el servicio
debería ser suspendido.
Otro ejemplo que se puede vislumbrar es al nivel de bases de datos médicas, donde es
posible establecer un sistema único (virtual) de historial de los pacientes de un país.
Supongamos que una persona accidentada en determinada ciudad es remitida a un
hospital, siendo esta persona originaria de otro lugar. Su historia médica reside en la
base de datos de la EPS (Entidad Promotora de Salud) a la cual pertenece el usuario. Al
permitir la comunicación entre los distintos hospitales es posible acceder a información
MISC-03-1-9
16
médica del paciente remitido. Si esto no sucediese es probable que al paciente se le
suministre una droga de la cual pudiera ser alérgico, lo cual sería algo muy peligroso. Sin
embargo al permitir la consulta en este sistema único de historias médicas es posible
evitar este y otros problemas similares.
Nótese que se ha abordado dos tipos de Interoperabilidad: una Interoperabilidad Interna –
Primer ejemplo – a la compañía y otra Interoperabilidad Externa – Segundo ejemplo –
concerniente a la comunicación entre dos empresas u organizaciones.
Este problema general de interoperabilidad entre bases de datos que manejan un dominio
de información común puede ser analizado y atacado usando una serie de estándares de
software.
2.2 INTEROPERABILIDAD Y FALTA DE INTEGRACION
Las empresas del sector de las telecomunicaciones que manejan un tipo de dominio en
particular, representan y almacenan la información de manera similar. Al interior de cada
empresa es posible que se maneje un problema de interoperabilidad, ¿Por qué? Con el
crecimiento y evolución de los sistemas de Telecomunicaciones, el negocio soportado
sobre la prestación de un servicio de transmisión de voz como en el caso de telefonía, se
va desplazando poco a poco por el auge y la necesidad de tener servicios de valor
agregado (Por ejemplo envío de Datos, Mensajería, entre otros), que establezcan una
estrategia competitiva frente a otra empresa. Sin embargo aquí existe el problema de
que como el negocio es tan cambiante, a medida que se intenta prestar un nuevo servicio
es posible que se vayan añadiendo plataformas (Hardware y Software) que lo soporte.
Las comunicaciones entre estos sistemas se realiza por medio de interfaces que se van
implementando en la medida que surgen.
En estas empresas existen departamentos (Auditoria, Aseguramiento del Ingreso, etc.)
encargados de velar que los servicios que presta la compañía se hagan de manera
adecuada a los clientes y en ningún caso deben verse afectados tanto la empresa (los
MISC-03-1-9
17
usuarios utilizan servicios sin estar pagando) o el usuario (se le esté cobrando un servicio
del cual no dispone)
Estos departamentos deben conciliar la información entre los diferentes sistemas para
garantizar el equilibrio entre un buen servicio al cliente y maximización del ingreso.
Así mismo como surge dentro de la compañía una necesidad del negocio para tener la
información integrada, también nace una necesidad de obtener información actualizada y
confiable, los cuales permitan a los usuarios soportar la toma de decisiones.
Dentro de una Organización con sistemas que poseen un gran soporte operacional, las
restricciones para el acceso a la información son grandes, existen grupos especializados
que se encargan de velar porque el comportamiento de estos sistemas sea el óptimo.
Con tal fin se restringen los accesos directos a estos sistemas. Se manejan políticas
como tiempos de conexión, número máximo de usuarios permitidos, horas permitidas
para las consultas. Esto sucede para los usuarios de primer nivel (usuarios que tienen un
rol definido dentro de la organización y que realizan tareas periódicas donde requieren
acceder a estos sistemas permanentemente) los cuales son los mas favorecidos, los
usuarios de segundo nivel, con estos me refiero a las áreas como Ventas, Servicio al
Cliente, Facturación que solicitan constantemente información se ven limitados en sus
operaciones ya que dependen de los usuarios de primer nivel y de su disponibilidad de
tiempo para entregar la información. Cuando estos usuarios por necesidad requieran
información precisa sobre el comportamiento del negocio al día de hoy. Pueden
encontrar que esta solicitud no sea atendida inmediatamente, sino después de unos
cuantos días. ¿Por qué? Por tres razones: primero, porque generalmente se les solicita a
los usuarios que tramiten requerimientos formales justificando la necesidad de tal petición.
Estas solicitudes originan que los tiempos de entrega de esta información sean muy
extensos. Segundo, los usuarios de primer nivel tienen otras actividades que les impide
muchas veces satisfacer los requerimientos a los usuarios de segundo nivel. Tercero, la
razón principal de esta limitante es el acceso directo a los sistemas en línea.
La transmisión de los datos entre BDs ( Bases de Datos) es compleja. Además si se
tienen bases de datos heterogéneas se complica mucho más esta función. Porque se
MISC-03-1-9
18
manejan diferentes SMBD, el rendimiento de cada uno de ellos es distinto. Los formatos
de datos que se manejan en una BD pueden interpretarse de manera diferente en otra.
Generalizando estos problemas de Interoperabilidad aquí planteados hacia diferentes
tipos de empresas que manejan bases de datos heterogéneas con un dominio común, se
puede atacar el inconveniente estableciendo una serie de pasos que consiste en
establecer consensos en el modelamiento y representación de la información.
Nótese que estos escenarios planteados son similares para el caso de dominios de
información como Finanzas, Cartera, Historiales Médicos, etc. En ellos se podría
presentar fácilmente este mismo Inconveniente.
Este problema general de interoperabilidad entre bases de datos que manejan un dominio
de información común puede ser analizado y atacado usando una serie de estándares de
software y hardware que se han creando a largo de los últimos años. Sin embargo aquí
cabe recalcar la idea de que debemos organizarnos para establecer coherencia y claridad
en la información.
Con esta tesis se busca dar solución al tema de la obtención de la información entre
diferentes bases de datos heterogéneas que tienen un dominio común. Centrándonos en
el dominio de las Empresas de Telecomunicaciones; pero sin dejar de lado que este tipo
de solución podrá ser implementada a otro sector organizacional.
MISC-03-1-9
19
2.3 DEFINICIÓN DEL PROBLEMA
La mayoría de las organizaciones enfrentan un problema de integración de datos donde
las aplicaciones requieren acceder a información almacenada en fuentes de datos
variadas, posiblemente distribuidas sobre múltiples plataformas.
Si se pueden agrupar de cierta manera las bases de datos de diferentes organizaciones (
tratando de integrar distintas empresas) o de distintos sistemas operacionales ( al interior
de una misma compañía) en un solo dominio, es posible atacar el problema de
Interoperabilidad que poseen estas diferentes fuentes de almacenamiento, permitiendo
que puedan ser accedidas.
Determinemos los elementos del problema de la Falta de Integración en una organización
que posee muchos sistemas Operacionales.
• Los datos no se encuentran integrados. Esto dificulta ver los sistemas como uno
solo. Se complica la tarea de realizar consultas sobre estos.
• Toma de decisiones sin soporte. Muchas veces al no poder realizar consultas
sobre los sistemas se deben tomar decisiones con base en consultas sesgadas
sobre un sistema de información y no viendo a la organización como un todo.
• La obtención de la información es demorada, ya que muchas veces los accesos a
los sistemas en línea son restringidos.
• Existe dependencia por parte de los usuarios hacia el área de IT, ya que estos
últimos son los que podrán informar cuando estas consultas se puedan realizar.
• La elaboración de consultas Ad Hoc, muchas veces va en contra de los procesos
organizacionales en los cuales se busca que los requerimientos de los usuarios
sigan un orden. El tiempo en que se solicita esta consulta y la respuesta que se
envía al usuario puede variar entre 24 horas hasta mas de una semana.
• Muchas veces cuando la información es enviada ya no es actual o es irrelevante
para los requerimientos de los usuarios.
MISC-03-1-9
20
• Se ejerce un control muy estricto sobre los accesos a las bases de datos
operativas, este control surge por dos causas: seguridad y desempeño. Estos
controles impiden al acceso permanente a la información.
MISC-03-1-9
21
3 ALCANCE
Con esta tesis se propone exponer una propuesta metodológica que permita abordar el
problema de falta de integración de bases de datos operacionales en una organización
que tenga necesidad de esta solución. Se indicarán una serie de pasos dentro de la
metodología con el fin de establecer unas pautas que se sugieren seguir para
implementar una solución a distintos tipos de usuarios.
• La propuesta metodológica esta enfocada a Almacenes de datos operacionales
• Esta basado en bases de datos relacionales
• No se tiene en cuenta actualizaciones sobre el ODS
• Se utilizará una herramienta de Workflow que permita modelar los grafos de los
procesos ETL.
• Solo se permitirán consultas sobre el ODS.
• Para el cargue de la información se asumen que se generan mediante archivos
planos, los cuales son cargados posteriormente mediante procesos ETL.
• Para el desarrollo del prototipo se realizará una análisis de un caso asociado a una
empresa de telecomunicaciones. Dirigido especialmente al tema de los Servicios
Suplementarios ofrece a sus usuarios.
MISC-03-1-9
22
4 ESTADO DEL ARTE
4.1 POSIBLES SOLUCIONES AL PROBLEMA DE LA INTEGRACIÓN DE DATOS
Teniendo en cuenta que estamos abordando el tema de Consultas sobre sistemas de Bis
heterogéneas, se deben seguir los pasos similares al procesamiento de consultas
distribuidas, con una complejidad adicional mas y es el de la heterogeneidad de las Bis,
eso ocasiona problemas ya que cada BD posee una autonomía, un esquema propio, y un
tiempo de respuesta determinado.
Existen distintas formas de atacar el problema de Consulta de datos sobre Sistemas de
Información heterogéneos con un dominio común de información. Obviamente se debe
establecer la mejor estrategia en cada caso.
A continuación se describen una serie de propuestas para integrar distintas bases de
datos operacionales.
4.1.1 SISTEMAS MULTIBASES DE DATOS
Un sistema multibase de datos esta conformado por bases de datos componentes locales.
Cada una de estas bases de datos componentes es administrada por su SMBD (Sistema
Manejador de Base de Datos)
MISC-03-1-9
23
Figura No. 1 : Clasificación de los Sistemas Multibases de Datos
Tomado de: [Ga2001]
4.1.1.1 Clasificación de las MultiBase de Datos
Sistema Base de Datos Federada
Una Federación consiste de un conjunto de bases de datos componentes autónomas, que
comparten en forma parcial y controlada sus datos. Cada uno de estos sistemas
componentes puede ser distintos o no entre sí. Se distinguen dos tipos de operaciones
en la Federación: Operaciones Locales ( las que se ejecutan en cada BD componente) y
Operaciones Globales ( las que se ejecutan sobre toda la federación) (Romero, 1999,
Sistema de Base de Datos Federada, Párr.1.
Las dificultades que surgen en una federación son que los componentes de un sistema de
base de datos federado, han sido definidos usando distintos lenguajes de base de datos,
diferentes modelos de datos, distinta semántica de los datos, técnicas de acceso de
consultas y diferente manejo de transacciones. Esto obviamente crea un problema de
heterogeneidad.
Sistemas multibases de datos
Sistemas de bases de datos federadas Sistemas de bases de datos no
federadas
Sistemas débilmente acoplados
Sistemas fuertemente acoplados
Sistemas de una sola federación
Sistemas de varias federaciones.
MISC-03-1-9
24
Figura No. 2. Componentes de una base de datos federadas
Tomado de: [Ga2001]
Componentes de una Base de Datos Federada
Los sistemas de bases de datos federadas pueden ser clasificados dependiendo de su
nivel de acoplamiento.
Sistema BDs Federada débilmente acopladas
En estos tipos de sistemas no hay un esquema global, los usuarios necesitan acceder
múltiples datos. Las bases de datos componentes son consultadas por medio de un
lenguaje Multibase de datos. En el usuario recae la responsabilidad de crear y mantener
la federación (Romero, 1999, Sistema de Base de Datos Federada, Párr.4.
Sistema BDs Federada fuertemente acopladas
Las bases de datos componentes son integradas en uno o más esquemas globales. Es
responsabilidad de la federación y sus administradores la creación y mantenimiento de la
federación y el control del acceso a los componentes SBDs (Romero, 1999, Sistema de
Base de Datos Federada, Párr.6)
MISC-03-1-9
25
Estos sistemas a su vez son clasificados dependiendo del tipo de federación.
Sistema BDs Federada de Federación sencilla
Permite la creación y manejo de solamente un esquema federado.
Sistema BDs Federada de Federación múltiple
Permite la creación y manejo de múltiples federaciones.
El siguiente grafico explica la forma de utilizar un sistema de Multibase de datos para
consultar la información.
Figura No. 3 : Consulta de Información en una Multibase de Datos
Tomado de: [Ro1999]
MISC-03-1-9
26
4.1.1.2 Lenguajes Multibases de datos
Aquí el usuario conoce la Heterogeneidad de los datos y los sistemas. El usuario esta en
capacidad de establecer una selección estructurada con una condición de búsqueda
adecuada que permita extraer los datos. Este es usado en Federaciones de Bases de
datos débilmente acopladas
Romero (1999) en su tesis “Lenguaje de Consultas para una Multibase de Datos"
estructura un trabajo interesante sobre un lenguaje que puede permitir acceder a la
información de una Multibase de datos.
4.1.1.2.1 Procesamiento de consultas distribuidas
El procesamiento de consultas distribuidas se caracteriza por cuatro pasos:
Descomposición de la consulta, localización de los datos, optimización global y
optimización local. “Esta es una generalización de los pasos de procesamiento de
consultas locales en DBMS centralizados, los cuales incluyen descomposición,
optimización y ejecución.” (Özsu & Valduriez, 1991, p.537)
Una base de datos auxiliar contiene información que describe como es el mapeo entre
esquemas participantes y esquema global. “Habilita las conversiones entre componentes
de la base de datos en diferentes maneras.” (Özsu & Valduriez, 1991, p.540)
4.1.1.3 Ejemplos de Sistemas Multibase de Datos
Attaluri (1995), y Ahmed (1991), en sus obras explican dos grandes proyectos de
Multibases de datos, los cuales son CORDS y PEGASUS respectivamente. A
continuación se realizará un resumen correspondiente a cada uno de estos trabajos.
MISC-03-1-9
27
4.1.1.3.1 PEGASUS
El proyecto Pegasus permite la integración de múltiples fuentes de datos heterogéneas.
Consiste en una extensión del prototipo OODBMS Iris y su lenguaje OSQL ( Object SQL)
y fue implementado en los laboratorios Hewlett-Packard.
Pegasus enfrenta el problema de la heterogeneidad definiendo un modelo de datos de
objetos y un lenguaje de datos común. El lenguaje de definición y manipulación de datos
de Pegasus, llamado HOSQL (Heterogeneous Object SQL) es un lenguaje funcional para
manipular bases de datos.
Arquitectura de PEGASUS
Las capas principales del sistema Pegasus son: Intelligent Information Access (IIA),
Cooperative Information Management (CIM) y Foreign Data Access (FDA)
1. Intelligent Information Access (IIA)
Provee servicios tales como Minería y exploración de esquemas.
2. Cooperative Information Management (CIM)
CIM es responsable por la integración de los Esquemas, además realiza el
procesamiento de sentencias HOSQL y de la coordinación de transacciones Multibase de
datos. Las peticiones de los usuarios son pasadas al RM (Request Manager) a través de
varias interfaces. RM chequea las peticiones y las envía a los administradores
operacionales apropiados los cuales son SM (Schema Manager), QM (Query Manager) y
TM (Transaction Manager).
SM implementa las operaciones de definiciones de datos, administración del catalogo y
los servicios de integración de esquemas. La información de los mapeos de los
esquemas definidos en un FS ( Sistema Externo) será almacenada en él catalogo y será
usado en los procesos de traducción y procesamiento de consultas.
MISC-03-1-9
28
QM genera los planes de ejecución eficientes para las consultas y coordina la ejecución
de las consultas y la manipulación de los datos.
TM maneja todos los medios relacionados a transacciones.
3. Foreign Data Access (FDA)
Las funciones del FDA son las siguientes: mapeo de los esquemas, consulta y traducción
de comandos, comunicaciones de red, invocación de sistemas extranjeros, conversión de
datos y enrutamiento.
El acceso a los sistemas externos es implementado por medio de módulos Mapper y
Translator y P-shells. Un Mapper soporta el mapeo de un esquema externo a un
esquema Pegasus. Un Translator traduce una sentencia HOSQL en una petición a un
FS.
Para respetar la autonomía de los FS, el P-shell esta diseñado para ser un stub que
puede ejecutar aquellas funciones que no pueden ser ejecutadas eficientemente por
FSs. Un P-shell provee servicios tales como invocación al FS, comunicaciones de red,
conversiones de formato de datos, bloqueo / desbloqueo de datos y enrutamiento de
datos a Pegasus.
Modelo de Datos de PEGASUS
Pegasus provee un modelo orientado a objetos el cual sirve como un framework para la
operación entre múltiples fuentes de datos con diferentes sistemas de administración de
datos. El modelo Pegasus contiene tres estructuras fundamentales: Tipos, funciones y
objetos.
Lenguaje de Datos de PEGASUS
Pegasus provee una definición de datos unificada y un lenguaje de manipulación de datos
llamado HOSQL (Heterogeneous Object SQL). HOSQL provee sentencias para crear
tipos, funciones y objetos tanto en Pegasus como en las bases de datos subyacentes.
MISC-03-1-9
29
Mapeos
El mapeo genera un esquema Pegasus para una fuente de datos extranjera, este mapeo
permite:
Dar a la fuente de datos la apariencia de una base de datos Pegasus.
Definir los datos y operaciones disponibles de la fuente de datos.
Las capacidades de mapeo son proporcionadas en forma modular, con un módulo
separado por cada modelo de datos objetivo. Cada módulo provee:
Un mecanismo para especificar mapeos entre el modelo de datos de la fuente de
datos y el modelo de Pegasus.
Un mecanismo para traducir peticiones expresadas en LDD/LMD Pegasus al
lenguaje del sistema de datos.
Procesamiento de consultas en PEGASUS
La consulta del usuario es formulada en HOSQL basada en un esquema Pegasus. QM
chequea la consulta en una estructura intermedia llamada un F-tree, los nodos de este
árbol incluyen llamadas a funciones, variables y objetos. Los F-trees son transformados
en árboles B-trees a los cuales se les añade información del catalogo. Una consulta
contra un sencillo FS se volará el proceso de optimización de Pegasus e irá directamente
al FS.
Las porciones de la consulta referentes a los datos de un mismo FS se identificarán y se
agruparán con el fin de reducir el número de invocaciones a cada FS. Por cada
agrupamiento de los nodos de datos en los B-tree correspondiente al mismo grupo se
mezclaran y llega a ser un nodo de datos sencillo, llamado un nodo de datos virtual. Los
árboles Pegasus producidos por cada agrupamiento son llamados D-trees.
MISC-03-1-9
30
Basado en los datos estadísticos disponibles, QM iniciará un proceso de optimización
basada en costos para el árbol D-tree. Esta incluye escoger un orden de Join, métodos
de Joins, sitios de los Joins, enrutamiento de datos intermedio, etc.
Una vez el plan de ejecución esta determinado, QM traducirá las peticiones de acceso a
los FS representado por un nodo de datos virtual en los lenguajes de interfase de
programas de aplicación específicos al FS y preparara otras estructuras para facilitar el
proceso en tiempo de ejecución.
QM distribuye los pasos de ejecución relevantes por cada P-shell asociado con los FSs
involucrados y coordina toda la ejecución.
Pegasus tiene información estadísticas limitada para los datos residentes en los FSs. No
tiene control sobre la optimización de las subconsultas enviadas a cada FS. Pegasus se
enfatiza en la optimización global y trata de encontrar la mejor descomposición posible y
agrupamiento de consultas.
4.1.1.3.2 CORDS
Es un proyecto de investigación enfocado en aplicaciones distribuidas, desarrollado por
IBM y un conjunto de Universidades. CORDS provee un integrada vista relacional de
múltiples sistemas de bases de datos heterogéneas. Cinco fuentes de datos son
soportadas: Tres sistemas de bases de datos relacionales: ORACLE, DB2/6000 y
EMPRESS; todas corriendo sobre AIX (Sistema Operativo Unix) Un sistema de base de
datos de red: VAX/DBMS sobre VMS ( Sistema Operativo para computadores VAX y
ALPHA) y un sistema de base de datos jerárquico IMS sobre MVS.
Las características de CORDS se enfocan en tratar los siguientes puntos:
Optimización de consultas
Administración de Transacción
MISC-03-1-9
31
Integración de esquemas
Seguridad
Catalogo de la Multibase de datos
Arquitectura de CORDS
El sistema fue desarrollado sobre AIX y Open Software Foundation (OSF) Distribuited
Computing Environment (DCE). Para su desarrollo se necesitaron mas de 200.000
líneas de código.
La siguiente figura muestra los componentes principales del prototipo CORDS
Figura No. 4 : Arquitectura del Sistema CORDS
Tomada de [At1995]
A continuación se describen los componentes que hace parte del prototipo.
MISC-03-1-9
32
Comunicación
Este proceso se soporta mediante librerías MDBS Cliente y Servidor. Este módulo
permite atender las solicitudes hechas en ODBC usando para ello llamadas RPC (Remote
Procedure Call)
Integración del Esquema
Es un ambiente que permite tareas que se refiere al proceso de integración, en especial
los relacionados a traducción de esquemas entre diferentes fuentes de datos, resolución
de conflictos y mezcla de esquemas.
El modelo de datos dado durante la integración es una extensión del modelo relacional.
Se disponen de dos tipos de tablas: tablas export y vistas MDBS. Las primeras
presentan la información disponible de una CDS (Fuente de datos Componente) en forma
relacional y la segunda se extiende a bases de datos heterogéneas múltiples. El modelo
de datos también incluye funciones de transformación, que permiten resolver conflictos,
estas funciones son aplicadas a los atributos de las tablas export que participan en una
vista MDBS.
Interfase Motif
Es una interfase gráfica de usuario, en la cual este puede realizar consultas y
actualizaciones contra las tablas. Los resultados son recuperados del servidor y
desplegados en forma gráfica.
Coordinador de Peticiones
Se encarga de coordinar los diferentes procesos involucrados en la atención de las
solicitudes hechas por el usuario. Varios módulos pueden estar relacionados en la
coordinación: Parser, Integrador de vistas, Descomposición y optimización de la consulta,
motor de ejecución y administrador de transacciones. El coordinador permite múltiples
conexiones simultaneas pero solo puede ser atendida una a la vez.
Catálogo
Tiene como objetivo proporcionar información de los datos tanto estructurales
(Descripción de los datos y las relaciones en el sistema) como estadísticos (estadísticas
MISC-03-1-9
33
de las fuentes de datos componentes) La localización de los datos en la red, los
esquemas que definen las BD y los usuarios son parte de la información contenida en el
catálogo.
El módulo Catálogo esta implementado sobre un Directorio X.500, se utilizó esto porque
permitía tener un esquema de nombramiento global único de los objetos en la CDS.
Este modulo interactúa con el Directory X.500 por medio del Agente Usuario del Directorio
(DUA) el cual realiza las consultas al directorio. Así mismo el Directorio también esta
distribuido físicamente por medio de entidades llamadas Agentes del Sistema de
Directorio (DSA)
Parser
Este módulo consiste en un parser SQL que fue construido usando YACC.
Integración de vistas
Las consultas del usuario son mezcladas con las definiciones de las relaciones las cuales
son almacenadas en el catalogo. La salida de este módulo es la representación de un
árbol que es la mezcla de un árbol de consulta y los árboles de definición de las
relaciones.
Descomposición y Optimización de la Consulta
Se utilizan heurísticas para realizar la descomposición y la optimización.
Motor de Ejecución
Recibe un plan de ejecución global, enruta las consultas a las fuentes de bases de datos
componentes y luego realiza la integración de los resultados.
Subsistema de Administración de Transacciones
El administrador de transacciones mantiene identificadores de transacciones para permitir
una seriabilidad y un commit global. CORDS emplea para las transacciones distribuidas
Encina, el protocolo XA de X/Open, DCE (Distribuited Computing Environment) y el
protocolo DRDA (Distribuited Relational Database Architecture) de IBM.
MISC-03-1-9
34
Agentes MDBS
Los agentes proveen una interfase estándar a la CDS. Cada agente esta ligado a la
librería del servidor MDBS (Sistema Multibase de Datos) permitiendo con ello la
comunicación con el Motor de ejecución. Una interfase ODBC es provista al agente y
este devuelve los datos en un formato estándar.
El principal objetivo de CORDS es aparecer como un sistema de base de datos relacional
simple. Permitiendo con ello ser un sistema escalable y expandible.
4.1.2 DATA WAREHOUSE o BODEGA DE DATOS (DW)
Un Data Warehouse o bodega de datos es una colección de información corporativa
derivada directamente de los sistemas operacionales (DB) y de algunos datos externos.
Que tiene como finalidad soportar la toma de decisiones. Una bodega de datos tiene las
siguientes características:
• Orientada al sujeto, esta orientada hacia las entidades más grandes de la
organización, como por ejemplo: Clientes, Productos, Servicios, etc.
• Integrada, porque se tiene una visión agregada y detallada de los datos. Esto
sucede mediante un proceso de extracción y transformación de los datos desde
las fuentes orígenes.
• No Volátil, los datos permanecen durante mucho tiempo en la bodega de datos,
este rango de tiempo puede ser desde unos días hasta unos años.
• Variante en el Tiempo, esto significa que los datos históricos son guardados.
Para la implementación del DW se inicia con el proceso de recolección, transformación y
agregación de los datos. Se almacenan los metadatos (datos acerca de los datos) en lo
que se conoce como repositorio y a partir de ahí se permite que la información sea
analizada y presentada en la forma que necesita el usuario. Generalmente los datos son
MISC-03-1-9
35
transformados ( reformateados o agregados) antes de ser colocados en la bodega de
Datos.
La bodega de datos puede ser implantada a través de una base de datos relacional o
puede ser un conjunto de Data Marts. Es así como la bodega de datos también se puede
definir como la agregación de Data Marts que a su vez pueden ser implantados como
pequeñas bodegas de datos. El propósito es el mismo y es el de dar acceso completo a
los usuarios a datos históricos y actuales que han sido extraídos de diferentes fuentes con
información operacional.
Arquitectura
Figura No. 5 : Arquitectura de un DataWarehouse
Tomado de [B&D]
1. Bases de Datos operacionales: los datos pueden provenir de diferentes sistemas de
información especializados, que son OLTP.
2. Extracción de datos: un programa se encarga de extraer la información desde las
bases de datos externas con el fin de seleccionar, depurar, formatear y consignar los
datos en el dispositivo de almacenamiento de la bodega de datos.
MISC-03-1-9
36
3. Herramientas de acceso al componente de almacenamiento físico: son aquellas que
permiten el acceso a la información mediante el diseño de consultas e informes,
desarrollo de aplicaciones, data mining, entre otras
4. Data Marts: son pequeñas bodegas de datos específicas para algunas dependencias
de la organización.
Implementación
En la concepción, desarrollo y alimentación de la bodega de datos se requiere seleccionar
y validar la información que se desea tener disponible. Ya que es peligroso no contar con
toda la información y tomar decisiones basados en el supuesto conocimiento de la
situación.
Para la implementación de una Bodega de Datos es necesario estudiar las necesidades
en el ámbito de comunicación, flujo y estructuración de la información de la organización.
Posteriormente se debe estructurar y organizar la información recopilada con el propósito
de definir la estructura de la base de datos. Una vez se ha elaborado el esquema y se
crea la estructura que soporta el sistema, se procede a cargar la información y se entra en
un proceso de afinamiento con el fin de optimizar el funcionamiento y rendimiento del
sistema.
4.1.3 ODS ( Almacén de Datos Operacionales)
Según Kimball (1998) existen dos posibles definiciones de ODS. La primera indica que un
ODS sirve como el punto de integración de sistemas operacionales, esto fue muy útil para
sistemas legacy que crecieron independiente uno de otra. La segunda definición, indica
que el propósito del ODS ha cambiado para enfocarse para la toma de decisiones, esto
porque el ODS tienen datos integrados a un nivel detallado, donde el ODS debería ser
construido para soportar la capa mas baja de un DW.
Sin embargo Kimball en su libro se orienta a definir lo siguiente: “El original ODS es
verdaderamente un sistema operacional, separado del DW, con diferentes niveles de
MISC-03-1-9
37
servicios y requerimientos de desempeño que debe satisfacer” así mismo añade “Si se
trabaja en un rol operacional y de tiempo real, entonces se esta hablando verdaderamente
que un ODS debe tener su sitio en el mundo de los sistemas. Por otro lado si se desea
un soporte a la toma de decisiones se propone dejar de lado el ODS y satisfacer todas
esta necesidades directamente en el nivel detallado del DW”.
Por otra parte Inmon (1999) propone que el ODS si cumple con las dos características de
integración operacional y soporte a la toma de decisiones. Indica en su prefacio del libro
[In2nd] “Los ODS son interesantes porque posee un pie en el mundo operacional, con
procesamiento transaccional y otro pie en el mundo del procesamiento DSS (Sistemas de
Soporte a la toma de decisiones) Ellos son verdaderamente una estructura híbrida”
(Inmon, 1999, Prefacio XVI)
Después de encontrar este tipo de definiciones correspondientes a un ODS nos
orientamos por definir los ODS como Repositorios de información Operacionales que
permiten ver integradamente los datos de distintos sistemas operacionales. Así mismo
con un enfoque que permite el soporte a la Toma de decisiones.
Estos son almacenes de datos operacionales utilizados frecuentemente para obtener
información casi en línea de los productos / servicios que maneja la organización.
Generalmente empresas grandes, prestadoras de servicios requieren este tipo de apoyo.
Cuando se desea tener una visión de la información en forma colectiva, operacional e
integrada es una buena opción. Cuando se maneja un volumen alto de datos, es poco
eficiente permitir que los reportes o consultas que requieran los usuarios sean hechas
directamente a los sistemas en línea. La idea con el ODS es establecer un repositorio
de información donde se definen unas políticas de actualización de la información y que
permite ver todas las fuentes de información integradas. Así mismo es una herramienta
que puede ayudar a la toma de decisiones de la Organización.
Según Inmon (1999) un ODS tiene las siguientes características:
MISC-03-1-9
38
Orientada al sujeto, al igual que el DW el ODS se centra en entidades grandes de
la organización, sobre la cual se desea un mayor control de la información.
Integrada, los datos en el ODS se ven de manera integrada aunque provengan de
diferentes fuentes de información.
Volátil, cada vez que un cambio se da en las fuentes de información, esto se debe
reflejar en el ODS.
4.1.3.1 Tipos de ODS
Inmon (1999) en su libro identifica básicamente dos tipos de ODS, los comerciales que
surgieron como necesidad para integrar distintas aplicaciones viejas en las empresas
porque era mucho más fácil integrarlas que reemplazarlas. Por esta razón se crearon
ODS que se alimentaban de los datos de las viejas aplicaciones. Los otros tipos de ODS
son los hechos a la medida, cuando la empresa no compra un paquete sino que se
encarga de diseñar, programar, implementar y instalar el ODS. En los hechos a la medida
se enfrenta al gran reto de diseñar el ODS.
Entre los ODS comerciales se pueden encontrar muchos paquetes de software como
SAP, Oracle Financials, Peoplesoft. De estos SAP es el más conocido, SAP comenzó
como un paquete de aplicación financiera principalmente para empresas manufactureras.
El núcleo de SAP es un ODS con interfaces a otras entidades arquitecturales tales como
DW y Datamarts. Uno de los retos de SAP como ODS es importar y exportar datos.
Figura No. 6 : Flujo de Información desde Sistemas Operacionales
hacia Repositorios Corporativos. Tomado de Inmon (1999).
Apl
icat
ions
Inte
grat
ion
Tran
sfor
mat
ion
Enterprise DW
ODS
Data marts
MISC-03-1-9
39
5 RESUMEN DEL ESTADO DEL ARTE
Entre las soluciones propuestas para la integración de BDs existen muchas mas que las
descritas en los puntos anteriores, se tiene sistemas como Wrappers ( Mediadores),
Plataformas de Objetos, Sistemas Middleware. Pero, casi siempre este tipo de soluciones
se vuelven complejos ya que manejan diferentes características de estándares de
software y hardware. A continuación se indican las razones de este análisis.
Las propuestas como Plataformas de Componentes y Middleware para comunicar las
distintas bases de datos son adecuadas si se hacen lo suficientemente escalables. Sin
embargo, el problema que se tiene aquí es que se están afectando las fuentes de datos
orígenes. Cuando lo que se desea realizar son consultas no se debe incurrir en una
cantidad de gastos, de procesamiento en línea, utilización de la red, entre otras.
La investigación se dirigirá por lo tanto a soluciones que estén soportadas sobre las
mismas bases de datos, es decir que su solución involucre un soporte de un sistema
manejador de BD, la razón de esto es su robustez, eficiencia y gran capacidad de
procesamiento.
A continuación se presenta una análisis entre los distintos tipos de propuestas, las cuales
están soportadas sobre una BD.
MISC-03-1-9
40
5.1 COMPARACIONES ENTRE TECNOLOGÍAS PROPUESTAS
Sistemas a Analizar
Características Ventajas Desventajas
Multibases de Datos
• Transacciones y Consultas tanto Globales como Locales.
• Lenguaje de Consultas.
• Visión Integrada, debido al esquema global que se defina.
En algunos sistemas se pueden procesar consultas únicamente sobre el modelo de datos global, pero la arquitectura de referencia está diseñada para permitir consultas sobre una fuente particular y obtener resultados adicionales de otras fuentes locales.
• Permite resolver conflictos esquemáticos de manera detallada cuando se integra una pequeña cantidad de fuentes predefinidas.
• Se pueden realizar consultas en línea sobre cada fuente local o sobre el esquema local.
• Información Detallada. • Permite acceso en línea a
cada uno de los sistemas que componen la Multibase de datos.
• No es escalable. Presenta gran dificultad para integrar nuevas fuentes debido a la gran cantidad de esquemas.
• Costosa en Red y Procesamiento, hardware y software.
• Es complejo mantener la federación debido a los innumerables cambios.
• Afecta el desempeño de los sistemas orígenes. Las consultas muy grandes no serian permitidas.
• En el ámbito de seguridad representa un riesgo el acceso a estos sistemas, los controles, permisos y administración de perfiles se convierte en una tarea de mucho cuidado.
Data Warehouse - Bodega de datos
• Orientada al Sujeto • Integrada. • Datos no volátiles,
se actualizan mediante Snapshot.
• Contiene datos que son ricos en historia
• El refrescamiento de datos es realizado en un estado muy relajado.
• Se manejan datos resumidos.
• Los datos se ven de manera integrada debido al proceso de transformación que sufren cuando son pasados desde las fuentes originales de información hacia el DW.
• Debido a sus características de Integración permite observar información corporativa de la empresa.
• Se ve en forma integrada la información.
• Orientada a la información de una entidad de la corporación.
• Datos entre 24 horas y más de 5 años.
• Tiene como finalidad la toma de decisiones y no el soporte de las operaciones en línea.
• El cargue de los datos se hace generalmente cada 24 horas, por lo que no sería una buena herramienta, para buscar información casi en línea.
• Las consultas en este tipo de sistemas son pesadas, debido a que se maneja gran volumen de datos históricos.
ODS – Almacén de Datos Operacionales
• Orientada al Sujeto • Integrada • Volátil, cada vez
que hay cambio se debe reflejar en el ODS.
• Datos actuales, de
• Menos costosa que un DW o una Multibase de datos.
• Dependiendo del tipo de ODS se puede tener información relativamente fresca.
• Las consultas son mucho
• Se debe tener en cuenta el costo de implementar un ODS y ver sus ventajas corporativas en la organización.
MISC-03-1-9
41
menos de 24 horas de antigüedad.
• Refrescamiento rápido.
• Datos detallados
más rápidas que en un DW, ya que a pesar de tener unos datos detallados no se maneja un volumen histórico.
• Debido a que el ODS es una B.D. que se encuentra aparte de los sistemas en línea y estableciendo privilegios de sólo lectura sobre esta, estaríamos ejerciendo un mejor control y sin tantos problemas de seguridad como en una Multibase de datos.
• El enfoque del ODS es la Integración Operacional.
Tabla No. 1. Cuadro comparativo entre Tecnologías Propuestas para solucionar la
Integración de Información 5.2 CONCLUSIONES DE LAS SOLUCIONES PROPUESTAS
Al revisar las ventajas y desventajas de cada uno de estos sistemas, se puede identificar
que cada una de ellas esta enfocada a una necesidad de las empresas u organizaciones
que las implementan. Se debe ser muy preciso en escoger la herramienta mas adecuada
en cada caso. Por ejemplo, Una Bodega de datos ( Data Warehouse) obviamente podría
cumplir con la función de presentar la información integrada, Sin embargo, los datos no
se encuentran recientemente actualizados, existe una gran diferencia entre los datos de
los sistemas en línea y los datos en el D.W. ya que la diferencia entre la transferencia
entre un sistema origen y el D.W. es muy grande. Sé esta hablando de aproximadamente
24 horas o incluso mas tiempo. Además la función de un D.W. no es operacional, su
propósito fundamental es la de servir como Herramienta en la Toma de Decisiones, este
tipo de sistemas permite ver el comportamiento del negocio a través del tiempo.
Un sistema Multibase de Datos permite la integración entre los sistemas de bases de
datos heterogéneos. Pero, se debe establecer el criterio de mantenimiento y
administración para cada una de ellas. Dentro de la gama de Multibases de datos existe
una gran variedad de sistemas a implementar, dependiendo de la escogida se deben
definir el lenguaje a usar, los responsables, si es sólo para consultas o también se
MISC-03-1-9
42
permitirán transacciones. Lo difícil aquí es que al establecer una comunicación directa
con todas las bases de datos, se tiene riesgos de desempeño sobre las BDs
componentes. Por ejemplo una consulta Multibase de datos si no es óptima puede
ocasionar problemas de utilización de memoria y recursos de los sistemas locales.
Una empresa siempre busca una solución efectiva y que este balanceada entre Costo /
Beneficio. Si observamos detenidamente, a pesar de que existen diferentes soluciones
para la consulta de información operacional integrada. La mejor propuesta es el ODS
¿Por qué? Porque el impacto no es directo sobre los sistemas en línea como ocurre en
una Multibase de datos. En una Multibase de datos cuando se lanza una consulta, el
procesamiento afecta los sistemas locales. Dependiendo de cómo se realicen estas
consultas es posible que se presenten bloqueos en los sistemas orígenes. Además en
caso de una falla en una base de datos, se imposibilita la realización de la consulta. Por
el contrario un ODS no es mas que un Repositorio, que al igual que un DW tiene datos
integrados, pero a diferencia de este permite un soporte Operativo. Las consultas son
mucho más rápidas que un DW, ya que se maneja un volumen menor de datos.
Al implementar el ODS el impacto que se refleja en los sistemas locales es por la tarea de
replicación de datos locales hacia el ODS y este tipo de replicación se debe hacer según
las necesidades del negocio.
Un ODS es un SMBD independiente, que maneja sus políticas de Mantenimiento,
Administración y Soporte. Pero, la ventaja aquí es que se tiene disponibilidad de la
información cada cierto tiempo. El usuario cuando desea acceder a una información
realiza una consulta sobre una sola base de datos y no tiene que estar afectando en
desempeño a los Sistemas Locales.
Nótese que en cada una de estas soluciones propuestas se debe resolver el problema de
establecer el lenguaje común, es decir definir un conjunto de términos que sean
entendibles y traducibles para poder realizar una mejor comunicación. En cada una de
ellas debe haber una capa que se encargue de integrar / transformar la información entre
los sistemas locales y la base de datos consultada por el usuario.
MISC-03-1-9
43
6 ¿QUÉ SE DEBE HACER PARA IMPLEMENTAR LA SOLUCIÓN ESCOGIDA?
De lo concluido anteriormente se puede determinar que el ODS, es la mejor solución para
el problema de integrar Bases de Datos Heterogéneas, con información operacional y con
un dominio común. Esta solución establece un balance entre costo y complejidad.
Según Inmon (1999) un ODS tiene las siguientes características:
Orientada al Sujeto
Un ODS es diseñado y organizado alrededor de los principales sujetos de la corporación.
Por esto cuando se tiene un dominio común de información es la solución apropiada.
Integrada
Los datos encontrados en el ODS corresponden a una agregación de datos detallados
encontrados en los sistemas orígenes de los que se alimenta. La transformación de datos
en el ODS es muy similar a la Transformación e Integración de datos que ocurren como
flujo de datos originales en el DW.
Volátil
Los datos en el ODS son actualizados periódicamente. Cada vez que los datos cambian
en los sistemas orígenes, el ODS necesita ser actualizado.
Valores Actuales
Los datos en el ODS están casi en línea, además no se tiene el problema de estar
accediendo los sistemas originales, afectando tanto el desempeño de la Red como el de
cada uno de las BD's
Detallada
Los datos en el ODS sirven la comunidad operacional y como tal es mantenida a un nivel
detallado.
MISC-03-1-9
44
6.1 TEMAS A SOLUCIONAR EN LA PROPUESTA DE CONSTRUIR UN ODS
Ahora que se ha definido que el ODS es la mejor decisión, cuando se desea una
herramienta que permita observar la información detallada, integrada y casi en línea. Es
necesario analizar ciertas características de la base de datos a implementar:
6.1.1 Metadatos
Los Metadatos son datos acerca de los datos, los cuales permiten conocer
Descripciones de Tablas y Columnas
Definiciones de Tablas y Atributos
Definiciones de Áreas de Sujetos
Definiciones de entidades de negocios
Programación del Refrescamiento de Datos
Estructuras de índices
Relaciones entre tablas
Fecha de Actualización de datos en el ODS ( Inmon, 1999, p. 45)
Los metadatos permiten al usuario final entender cuáles son los datos disponibles para
análisis. Adicionalmente, los metadatos del ODS permiten al usuario ver las diferencias
entre los tipos de datos encontrados allí.
Toda esta información debe ser compartida tanto al administrador del ODS como también
al usuario en cierto modo. Es posible que para el usuario final no sea necesaria toda la
información de los metadatos, tal vez necesite cierta información como por ejemplo la
última actualización del ODS. Así mismo es preferible guardar estos metadatos en la
misma base de datos donde esta el ODS, con el fin de tener la información fácilmente
accesible.
MISC-03-1-9
45
6.1.2 ¿Qué clase de ODS se va a Implementar?
Inmon (1999) en su libro indica que los ODS se pueden clasificar dependiendo de la forma
en que son actualizados los datos en el ODS.
CLASE I
Actualización sincrónica, este tipo de ODS es usado en sistemas de alto desempeño, en
ambientes dominados por las transacciones. Las actualizaciones se realizan cada 3 o 4
minutos, con el fin de tener la información lo mas actualizada posible.
CLASE II
Es cuando la actualización del ODS es manejada por medio de técnicas de
almacenamiento y envío, Son actualizaciones realizadas aproximadamente cada cierto
tiempo medido en horas. Existe una pequeña cantidad de integración y transformación.
CLASE III
Se realiza una actualización asíncrona, los datos son actualizados cada 24 horas.
Generalmente se crea un registro integrado de diferentes aplicaciones. Se utiliza cuando
la organización no requiere inmediatez en la integración de los registros.
CLASE IV
Proviene de datos analizados en la Bodega de Datos. El paso de la información del DW
hacia el ODS no esta programado, no existe una periodicidad determinada.
Entonces ¿Qué clase de ODS se debe usar? Teniendo en cuenta que se busca la
solución sobre una organización que necesita alta disponibilidad de la información, es
apropiado usar una Clase II o Clase III. La razón de esto es que como se maneja un gran
volumen de información, no es apropiado realizar una actualización cada 3 o 4 minutos (
Como sería el caso de un ODS Clase I) porque el costo e impacto sobre los sistemas
orígenes es muy grande. Y entre la Clase II y Clase III, sería preferible tener una clase II.
Ya que no tiene el problema de la Clase I y tampoco tiene una gran diferencia de tiempo
de actualización como en la clase III. Pero, si se piensa que la información satisficiera
un conjunto de áreas de usuarios que anteriormente no disponían de los medios o
mecanismos para acceder a información en línea una Clase III sería de mucha ayuda.
MISC-03-1-9
46
6.1.3 ¿Cómo se deben capturar las modificaciones?
Inmon (1999) indica que existen distintas formas de atrapar las modificaciones, entre
estas tenemos las siguientes:
• Directa, actualización inmediata Costosa y muy ineficiente.
• Utilización de los archivos delta Atrapan los cambios realizados en las Bases
de Datos. Usualmente son escritos en las aplicaciones para auditar los sistemas.
Por ejemplo: Tablas de modificaciones.
• Atrapar los cambios en el ámbito de la BD El inconveniente es que puede
generar mucho impacto en el desempeño porque se utilizan muchas entradas y
salidas. Es una buena opción cuando el DBMS es muy tratable.
• Uso de log tapes de aplicación en línea Una utilidad se encarga de seleccionar
los datos del log tape y los prepara para llevarlos al ODS. La ventaja es que no se
afecta las entradas y salidas ni tampoco el código del programa.
Mientras se tenga en las aplicaciones la posibilidad de identificar en el ámbito de bases de
datos las modificaciones que han sufrido las entidades de la organización, pues será
mucho más fácil encontrar estos cambios y realizar posteriormente el traslado de los
datos hacia el ODS. Durante el desarrollo de esta tesis se asumen que estas
modificaciones son registradas en tablas que permiten a los usuarios hacer auditorias a
los sistemas. A partir de allí se buscaran los registros con estos cambios y
posteriormente se transferirán al ODS.
6.1.4 ¿Cómo se cargaran los datos?
Al igual que ocurre en un DW la primera carga en el sistema ODS consiste en una copia
total de los datos, teniendo en cuenta la operación de Transformación e Integración.
MISC-03-1-9
47
Posteriormente se deberán realizar cargas de datos periódicas, con el fin de refrescar los
datos con las actualizaciones que se sufran en los sistemas de origen.
6.1.5 ¿Cómo se va definir el registro del sistema?
“El Registro del Sistema es la definición de exactamente que datos operacionales son
necesarios para soportar el ambiente ODS” (Inmon, 1999, p. 66). Muchas veces lo que
sucede es que se parte de un tipo de información que se carga al ODS, posteriormente
este tipo de información se va cambiando a medida que las interacciones con los usuarios
permita establecer los datos que verdaderamente son valiosos para la organización. El
establecimiento del ODS es un proceso iterativo.
El proceso inicial de la selección del registro consiste en definir las entidades más
importantes para las áreas usuarias mediante un consenso. Una forma de identificar esto
es clasificando las consultas o reportes mas frecuentes en la organización.
Posteriormente se elegirá de cada una de estas entidades los datos o columnas más
significativos a guardar.
6.1.6 ¿Cómo se van a mover los datos al ambiente ODS?
Según Inmon (1999) existen cinco posibles maneras de hacerlo
• Inserción simple de registros
• Inserción / reemplazo del registro
• Reemplazo de campo, es similar al reemplazo de registro sólo que la
actualización se maneja en el ámbito de campo en lugar de todo el registro.
• Acumulación de campos, donde los campos de un registro sencillo son
acumulados en el ODS.
• Conteo de campos, donde los campos de un registro sencillo son contados en el
ODS.
MISC-03-1-9
48
Se propone como muy buena opción la Inserción / reemplazo de los registros. Esto
porque permitirá cambiar solo aquellos registros que han cambiado y adicionar los
nuevos. En algunas otras ocasiones se necesitará transferir datos resumidos mediante
operaciones de conteo, sumas, etc.
6.1.7 ¿Qué sucede cuando no este activa una fuente de datos o el ODS?
Cuando una base de datos no este activa, la replicación de datos desde las fuentes
orígenes hacia el ODS, no se realizará esto para evitar que establezcan problemas de
diferencias en cuanto a registros que están en un sistema y no en otro. El usuario deberá
ser informado mediante la interfaz con la cual se comunica con el ODS, la última fecha de
actualización de los datos. Esto le permitirá a él conocer si los datos son lo
suficientemente exactos, o si es preferible esperar hasta que se repliquen nuevamente los
datos.
6.1.8 ¿ Costos de implementar un ODS?
Básicamente, implementar un ODS es crear una B.D. lo suficiente robusta para recibir la
cantidad de datos detallados, así mismo debe estar comunicada con las B.D.
Operacionales para poder extraer los datos, realizando con ellos un proceso de extracción
y transformación.
Si se analiza el costo de implementar este sistema es mucho menor que el necesario para
establecer un D.W. ya que el volumen de procesamiento no es tan grande como este, el
D.W. necesita mucha mas capacidad de almacenamiento y procesamiento. Por el
contrario las Multibases de datos poseen problemas con las comunicaciones y con la
escalabilidad. Además cuando se habla de una empresa que presta servicios a una gran
cantidad de usuarios, la cual siempre debe estar en la vanguardia de su sector, el costo
de mantenimiento de un muy buen sistema de Almacén de Datos Operacionales será bajo
comparado con el nivel de satisfacción de los usuarios de obtener información muy
oportuna.
MISC-03-1-9
49
6.1.9 ¿ODS centralizado o distribuido?
Esto es básicamente el problema que existe entre B.D. Centralizada y B.D. Distribuida,
debido a que el problema que se esta tratando de solucionar es la integración de la
información operacional de las diferentes fuentes de datos, no seria conveniente crear
una mayor complejidad en desarrollo y mantenimiento implementando un ODS distribuida,
lo mejor es trabajar con un ODS centralizado, ya que con este existe un mejor control.
6.1.10 ¿Volumen de datos del ODS?
El volumen de datos que se almacenan en el ODS depende del tamaño de las entidades
en los sistemas orígenes. Por ejemplo en una base de datos de una empresa de
Telecomunicaciones, este número es seguramente superior de 100.000 registros para el
caso de usuarios. Cuando se trata de servicios este número sería igual a la cantidad de
abonados por los distintos servicios que tiene contratado cada usuario.
Según Inmon (1999) el tamaño del registro estimado para el ODS es determinado por
medio de la siguiente fórmula:
Entidad X Número de ocurrencias de la entidad X Tamaño del registro de la entidad X
Cantidad de Historia = tamaño estimado de los datos para el ODS.
6.2 ¿CÓMO SABER SI ES NECESARIO LA IMPLEMENTACIÓN DE UN ODS?
Para saber si lo que se requiere implementar es un ODS dentro de la empresa, se deben
realizar una serie de cuestionamientos al interior de la organización. Los cuales
permitirán una orientación de las necesidades y dar la mejor solución al problema. Entre
este conjunto de preguntas tenemos las siguientes:
¿La empresa dispone de sistemas grandes?
¿Los usuarios requieren información periódica de estos sistemas?
¿La información requerida esta concentrada en ciertas entidades de la Organización?
MISC-03-1-9
50
¿Se desea tener información integrada y no es fácilmente obtenida?
¿Esta la empresa dedicada a la prestación de los servicios?
¿Depende en gran parte su imagen al área de servicio al cliente?
¿Existen restricciones de acceso de los usuarios a estos sistemas?
¿Existen quejas por parte de los usuarios referente a la no entrega oportuna de la
información o reportes?
¿Existen quejas por ejecutar reportes sobre las bases de datos operacionales?
¿Se desea tomar una decisión organizacional dependiendo del comportamiento del
negocio a la fecha y no se disponen de las herramientas para ello?
Si dentro de la organización existen muchas respuestas afirmativas a estas preguntas, la
empresa se encuentra en un punto donde requiere integrar la información de las Bases de
Datos Operacionales con el fin de presentarlo casi en línea. El ODS se presenta como
una buena alternativa puesto que es relativamente económica en tiempo de desarrollo,
soporte, escalamiento y porque al tener la restricción de los accesos a los sistemas, se
requiere una forma de pasar la información a un repositorio. Las conexiones directas
para consultas distribuidas seguramente no serán permitidas.
6.3 HERRAMIENTAS DISEÑO E IMPLEMENTACIÓN 6.3.1 WORKFLOWS
Según Lewis, Bernstein & Kifer (2002) un Workflow es un modelo de un proceso complejo
en una empresa, consiste en un grupo de tareas que deben ser ejecutadas en un orden
parcial especifico. Una tarea en el modelo de Workflow no necesariamente es una
transacción en la base de datos.
Los agentes son los encargados de ejecutar cada tarea en un workflow, estos agentes
pueden ser un programa de software, una máquina o una persona. El Workflow es
ejecutado en un periodo de tiempo por un grupo de agentes ejecutando las tareas.
El workflow es especialmente útil en plataformas heterogéneas y ambientes de
computación distribuida.
MISC-03-1-9
51
Tareas Cada tarea en el workflow tiene un estado físico, tal como en ejecución,
committed o abortado. Adicionalmente, la completitud de una tarea debe generar algún
estado lógico indicando éxito o falla. Las tareas en el Workflow deben ser coordinadas.
Una falla de una tarea puede presentarse debido a condiciones externas, es decir cuando
falla la conexión al servidor. Una manera de manejar las fallas es con compensaciones,
en cuyo caso una tarea de compensación es especificada por cada tarea en el Workflow.
En caso de una falla en tiempo de ejecución, se ejecutan tareas de compensación por
cada una de las tareas completadas en el orden reverso.
Los resultados de una tarea frecuentemente son suministrados como entradas a otra
tarea, sin embargo este flujo no necesariamente es igual al flujo de control.
La generalidad del workflow sigue parcialmente del hecho que no todas las tareas
son computacionalmente y no todos los agentes son sistemas de software. Pero
aún si las tareas son computacionales, el modelo de workflow no necesariamente
sigue las propiedades ACID ( Atomicity Consistent Isolation Durability) de las
transacciones, considere la propiedad Isolation. Cuando un Workflow es
ejecutado, las tareas individuales deben liberar recursos que han sido accedidos,
haciéndolos disponibles a tareas en otros Workflows (Lewis et al.,2002, p. 711)
6.3.1.1 Sistemas Manejadores de Workflows
Según Lewis et al. (2002) un sistema manejador de Workflow (WfMS) provee soporte para
la especificación de un Workflow (en tiempo de diseño) y programación y monitoreo de la
ejecución.
La especificación de un Workflow esta relacionada con la secuenciación de las tareas y
con el flujo de datos entre estas tareas. Un WfMS debe proveer una interfaz grafica de
usuario (GUI) a través de la cual el diseñador del Workflow puede dibujar figuras que
representen las tareas del Workflow o puede soportar un lenguaje en el cual las reglas
para la coordinación de tareas pueden ser expresadas. Para un controlador de un
MISC-03-1-9
52
Workflow de un sistema de procesamiento de transacciones, la especificación debe
permitir al diseñador indicar la ejecución secuencial o paralela de transacciones, el uso de
colas entre otras cosas.
Cada agente tiene un atributo indicando un conjunto de roles que debe asumir. Un role
describe una tarea que el agente puede ejecutar, a su vez cada tarea tiene un role
asociado. Los roles son usados por lo operadores del Workflow para identificar que
agente puede ejecutar una tarea.
Los monitores del WfMS verifican los estados de cada tarea, si ha ocurrido un cambio en
estado, así mismo verifica que las precondiciones para iniciar una tarea se hayan
cumplido.
La especificación de una actividad como un Workflow es particularmente importante
cuando la actividad es compleja y debe satisfacer un conjunto especifico de reglas de
negocio.
MISC-03-1-9
53
7 ANALISIS DE DIFERENTES METODOLOGIAS ENFOCADAS AL ANALISIS DE INFORMACION
A continuación se va a realizar un análisis sobre distintas Metodologías en diferentes
aplicaciones de Sistemas de Información como levantamiento de un Data Warehouse, la
primera metodología conocida sobre un ODS y otra enfocada a la Minería de Datos.
Este análisis se hace con el fin de encontrar puntos atractivos que permitan desarrollar
una propuesta metodológica lo mas completa posible y que esté muy bien estructurada y
nos permita solucionar la problemática planteada en esta Tesis.
7.1.1 Metodología de Minería de Datos: El ciclo virtuoso
Esta es la primera metodología que se va a analizar. Esta se encuentra documentada en
el libro Mastering Data Mining – The Art and Science of Customer Relationship
Management de los autores Berry & Linoff.
Esta metodología fue introducida inicialmente en Data Mining Techniques (Jhon Wiley &
Sons, 1997). Esta se construye alrededor del ciclo de la Minería de Datos la cual resalta
los aspectos comerciales de la Minería de Datos mientras se reconoce la interacción entre
el negocio y la parte técnica.
La metodología se puede resumir en las cuatro etapas que se visualizan en el siguiente
dibujo:
MISC-03-1-9
54
Figura No. 7 : El ciclo virtuoso de la Minería de Datos.
Tomado de (Berry & Linoff, 2002, p. 43)
El ciclo virtuoso de la Minería de Datos se enfoca en el uso de la minería de datos para
derivar en beneficios en el negocio. El ciclo virtuoso es un proceso compuesto de las
siguientes etapas:
• Identificar el problema de negocios correcto. Esta etapa utiliza a expertos de dominios para identificar los problemas de negocio más
importantes y los datos necesarios para resolverlos. Sin embargo, es importante verificar
las suposiciones hechas por los expertos de dominios.
Una parte necesaria de todo proyecto de minería de datos es hablar con las personas que
entienden el negocio. Trabajar con los expertos permitirá responder ciertas preguntas
como
¿ Es el esfuerzo de la minería de datos realmente necesaria?
¿ Hay un segmento particular o un subgrupo que es más interesante?
¿ Cuales son las reglas de negocio relevantes? Entre otras.
MISC-03-1-9
55
Las respuestas a estas preguntas requiere de una combinación de habilidades para
trabajar con los expertos de dominios así como entender la tecnología y los datos.
• Transformar los datos en resultados procesables. La construcción de modelos es un proceso iterativo que necesita enfocarse en como los
resultados serán usados. Esta es la etapa principal en la Minería de Datos.
Esta etapa principal se subdivide en las siguientes:
Identificar y obtener los datos, es importante verificar que los datos se ajusten a los
requerimientos para solucionar el problema comercial. Es necesario que estos datos
sean lo mas completo posible.
Debido a que el propósito de la minería de datos es poder identificar segmentos de
clientes, quizás con el propósito de anunciar dirigir o comprar listas de clientes probables.
Por esa razón es necesario que los datos tengan campos apropiados que permitan lo
anteriormente descrito.
Validar, explorar y limpiar los datos, el resultado de la minería de datos depende
críticamente de los datos. Por lo tanto es necesario revisar la exactitud de estos datos
tanto los que son críticos como los que no lo son.
Colocar los datos a la granularidad correcta, la granularidad se refiere al nivel de los
datos que están siendo modelados. En la minería de datos se trabaja sobre los registros
individuales de los datos.
Añadir variables derivadas, las variables derivadas tienen valores basados en
combinaciones de otros valores dentro de los datos. Algunas variables provienen de
datos dentro de una misma fila sencilla, otros provienen de combinaciones de filas
relativas.
MISC-03-1-9
56
Preparar el conjunto modelo, el conjunto modelo son los datos que son usados para
actualmente construir los modelos de minería de datos. El conjunto modelo se divide en
los conjuntos de entrenamiento, prueba y evaluación. Solamente algunos datos son
usados para crear el modelo inicialmente, otros son mantenidos para refinar el modelo y
predecir como trabajará.
Escoger la técnica de modelamiento y entrenar el modelo, las herramientas de
minería de datos han eliminado la mayoría de los detalles incómodos en la construcción
de modelos, además se ofrecen interfaces graficas para trabajar. Existen distintas
técnicas de minería de datos para escoger.
El modelo de entrenamiento especifico para el conjunto modelo, depende de la
escogencia del algoritmo y de las herramientas usadas.
Chequear el desempeño de los modelos, existen distintas técnicas de minería de
datos, las cuales tienen distintas maneras de medir los resultados.
• Actuar en los resultados.
El propósito de la minería de datos es actuar en los resultados, y esto puede pasar de
diferentes maneras. A veces, los resultados son visiones sobre el negocio y los clientes
los cuales deben ser comunicados; a veces los resultados sólo se usan una vez, cuando
por ejemplo están enfocados en una campaña de mercadeo. En otros momentos, ellos
pueden recordarse y pueden ponerse en un DW. Cuando los resultados no son los
esperados se tiene la necesidad de datos más ricos y más limpios.
• Medir los Resultados. La etapa final es la medida de los resultados de las acciones. Estas medidas alimentan el
ciclo virtuoso en una forma cíclica con el fin de proveer mas preguntas y más datos.
MISC-03-1-9
57
7.1.2 Metodología de Modelamiento Dot
Esta metodología se basa en el libro “Designing a data Warehouse Supporting Customer
Relationship Management” de Chris Todman.
Esta Metodología esta enfocada en el desarrollo de Modelos Conceptuales con el apoyo
de una metodología de Modelamiento Dot.
Según el análisis de Todman (2001) un Modelo Conceptual debe proveer lo siguiente:
• Ser simple de entender y usar por personas no técnicas
• Soportar el Modelo Conceptual General
• Soportar el Tiempo
Las personas de negocios deben estar habilitadas para construir, validar, modificar o aun
remplazar el modelo ellos mismos. Sin embargo, adicionalmente, el modelo debe ser
poderoso para habilitar los requerimientos técnicos de cada objeto a ser especificado para
que los diseñadores del DW puedan ir a desarrollar el modelo lógico.
El modelamiento dot es un modelo para capturar requerimientos de información en una
manera en que la gente de negocios pueden entender.
Dentro de esta Metodología se utiliza una variable denominada Retrospección la cual nos
indicará la manera en que los valores del pasado son guardados. Ese tipo de variable es
aplicada a distintos componentes como Entidad, Relación y Atributo.
• Retrospección verdadera significa que el objeto reflejará el pasado fielmente.
• Retrospección falsa significa que la visión de la historia será alterada cuando el
valor del objeto cambie.
• Retrospección permanentemente significa que el valor del objeto no cambiará
sobre el tiempo.
MISC-03-1-9
58
Modelamiento DOT
El modelamiento Dot provee una manera estructurada para la construcción de un modelo
lógico a partir del modelo conceptual. El nombre viene de la característica que el centro
de la parte de comportamiento del modelo, los hechos, son representados por un dot. El
método fue desarrollado como una clase de evolución de conceptos dimensionales y han
sido evolucionando para adaptar los requerimientos del Modelo General Conceptual
centrado en el cliente.
En esta metodología el dot es colocado en el centro del diagrama y las dimensiones son
colocadas alrededor.
El modelo tiene una similitud con el esquema Estrella dimensional.
Los componentes de un Modelo Dot de Comportamiento.
Los tres componentes básicos de un diagrama de un modelo dot son:
• Dot. Representa los hechos
• Nombres de dimensiones. Cada una de las dimensiones son mostradas en el
modelo.
• Conectores. Son colocados entre los hechos y las dimensiones para mostrar las
dimensiones de primer nivel. Así mismo, son colocadas entre dimensiones y
agrupamiento para mostrar la estructura jerárquica.
La metodología usa un conjunto de hojas de trabajo. Algunas de estas hojas son
completadas durante la etapa de diseño conceptual y otras son completadas durante la
etapa de diseño lógico.
La primera hoja es la Hoja de Trabajo del Modelo de Datos, la cual contiene
• Nombre de la aplicación
• Diagrama
• Lista de atributos de hechos.
MISC-03-1-9
59
Por cada atributo de hecho, se almacena la información describiendo el hecho, lo cual es
comúnmente conocido como metadatos. Con el fin de documentar la definición de
negocios del atributo.
Una segunda hoja de trabajo, la Hoja de Trabajo de entidades, es utilizada para registrar
lo siguiente:
• Dimensiones de comportamiento
• Circunstancias del Cliente
• Segmentos derivados
Esta parte del modelo mantiene alguna de la información más compleja en el modelo.
El propósito de esta hoja es ayudar a los diseñadores del sistema a entender los
requerimientos con el fin de asistirlos en el diseño lógico.
Por cada entidad se almacenan los siguientes datos:
Nombre de la dimensión, Retrospección de la entidad, Atributo de existencia para la
entidad, Frecuencia de captura de los cambios de la existencia de la dimensión.
Por cada dimensión un conjunto de atributos es también definido en una Hoja de Trabajo
separada. El atributo de existencia debe haber sido descrito. Por cada atributo se guarda
la siguiente información: Nombre de la dimensión a la que pertenece, Nombre del atributo,
Retrospección, Frecuencia, Metadatos, Fuente, Transformaciones y Tipos de datos entre
otros.
La información acerca de las jerarquías dimensionales es capturada en la Hoja de Trabajo
de Jerarquías. La Hoja muestra los nombres de componentes de los mas altos a los más
bajos de la jerarquía, La siguiente información también es capturada:
Retrospección de la jerarquía
Frecuencia de Captura
Metadatos que describen la naturaleza de la jerarquía.
MISC-03-1-9
60
Los WorkShops de Modelamiento DOT
La etapa de diseño conceptual consiste del desarrollo de un modelo de datos usando el
método de modelamiento Dot. El modelo lógico es desarrollado como una extensión del
método de modelamiento Dot.
Metodología de Modelamiento Dot
Los procesos de construcción de un modelo Dot pueden ser conducidos a través del uso
de dos Workshop altamente estructurados. Cada Workshops puede ser completado en
dos días.
El Workshop de Estrategia de Información
Este es el primer Workshop, los objetivos es que las personas de negocios dentro de la
organización, desarrollen su propio modelo dot que refleje su percepción del negocio.
Este workshop requiere una mezcla de personas del negocio y personas de IT. La
proporción ideal es que las dos terceras partes de las personas correspondan a personas
del negocio y una tercera parte de IT. Este primer Workshop se subdivide en una serie
de etapas:
• Introducción al Workshop
Se explica el objetivo del Workshop: Construir un modelo conceptual de los
requerimientos de la información necesarios para soportar la dirección de negocios de la
organización.
• Objetivo del Negocio
Se preguntan los objetivos de la Organización.
• Pensamiento acerca de la Estrategia de Negocios
Se dividen en grupos de tres a cuatro personas. El objetivo del ejercicio es
Decidir los Objetivos del negocio.
Pensar en la estrategia para alcanzar estos objetivos y
Los pasos necesarios para colocar esta estrategia en operación.
MISC-03-1-9
61
Los grupos deben guardar sus decisiones y posteriormente serán presentadas a los otros.
• Modelo Dot Inicial
En esta etapa se explica como se usa la metodología dot.
• Comportamiento
Se enseña cual es el significado del Dot, es decir, el comportamiento. Estos son los
atributos del dot mismo y representan el enfoque del modelo. Cada atributo de los
hechos debe tener las siguientes propiedades: Numérico y que sea sumable.
Cada hecho medible debe ocupar su lugar en la bodega de datos. Por cada atributo de
hecho, los metadatos soportan el atributo que también debería ser almacenado. Esto
permite una descripción precisa en términos de negocios.
• Las Dimensiones
Se describe el significado de las dimensiones.
• Creando el Modelo Dot Inicial
Tomando en cuenta los objetivos del negocio, la estrategia y los pasos previos los grupos
tienen que hacer lo siguiente:
Usar su estrategia más prioritaria, decidir cual es la información que ellos
necesitan.
Formular algunas preguntas que les gustaría poder preguntar.
Crear un modelo dot que puede contestar esas preguntas
Las personas de Tecnología ya podrían estar pensando en los siguientes
puntos:
Disponibilidad de datos de los sistemas fuente
Arquitecturas de las Base de Datos destino
Problemas de calidad de datos, etc.
MISC-03-1-9
62
• Presentaciones de Grupo
Los grupos deben presentar a los otros grupos, los siguientes ítems:
Objetivos del negocio
Pasos en su estrategia
Información necesaria para soportar los pasos
Modelo Dot para soportar los requerimientos de información
Algunos preguntas de ejemplo que el modelo soporte e indicando como cada pregunta es
relevante a su estrategia
• Proceso de Refinamiento
Se explican los siguientes puntos:
Combinación de dimensiones
Jerarquías dimensionales
Inclusión de otras sugerencias
Los grupos deberían ser reconformados para refinar los modelos.
• Presentación de los modelos refinados
Los modelos refinados son presentados a los otros grupos, explicando como el modelo ha
evolucionado del modelo original como resultado del proceso de revisión.
• Documentación de los modelos
Los modelos son documentados, en su estado refinado, usando un modelo de datos y su
primera parte de las Hojas de Trabajo de Entidades y Segmentación. Las entidades
incluyen las circunstancias de los clientes y las dimensiones de los modelos de
comportamiento. La segmentación se refiere a los segmentos derivados.
• Workshop Wrap-Up
La ultima etapa de este primer Workshop es resumir el proceso que ha sido realizado en
estos dos días y agradecer a los participantes que llevaron a la realización del modelo de
negocios.
MISC-03-1-9
63
El Workshop de Análisis de Componentes
El segundo WorkShop tiene como objetivo principal trabajar en el modelo creado en el
Workshop anterior. Ahora se invierte la proporción de personas utilizadas, es decir dos
terceras parte de IT estaría bien. Es vital que estén algunas personas de negocios. Este
Workshop se subdivide en los siguientes puntos:
• Revisión del modelo previo
El propósito del primer ejercicio es refrescar las mentes de los participantes así como del
estado del modelo Dot al final del primer workshop.
• Definición de Atributos
El objetivo es construir la lista de atributos para cada dimensión en el modelo. Las Hojas
de Trabajo de las Entidades deberían ser usadas en este ejercicio.
Por cada atributo, los metadatos que soportan el atributo son almacenados. A este nivel
estamos buscando una descripción precisa de los atributos en términos de negocio.
• Análisis dimensional de los hechos
Por cada atributo de hecho medible, se examina por cada dimensión para determinar
hasta que punto las funciones de la aritmética ( Suma, Conteo, Promedio, Mínimo,
Máximo) normales pueden aplicarse.
La hoja de trabajo usada para ejecutar este ejercicio es llamada Fact Usage ( Uso de
hecho)
• Jerarquías y Agrupamientos
Este ejercicio es simplemente para proveer algunos metadatos que describan las
relaciones entre los diferentes niveles en la jerarquía dimensional.
La hoja de trabajo usada para capturar esta información es llamada Hoja de Jerarquías y
Agrupamientos.
MISC-03-1-9
64
• Retrospección
Se debe examinar cada dimensión, atributo dimensional, y jerarquía para establecer cual
valor de retrospección debería ser aplicado.
• Como determinar el valor de la Retrospección
Se debe investigar el uso del objeto dentro de la organización con el fin de otorgar el valor
de retrospección adecuado a cada objeto.
• Granularidad y la tabla de Tiempo Dot
Se discute la granularidad del tiempo en las dimensiones, jerarquías y atributos. Para
estos elementos la granularidad se refiere a la frecuencia con la cual cambian los valores,
cambian las existencias y son notificados y aplicados al DW.
Se utiliza una hoja de trabajo Dot_Time que no es mas que una lista de títulos,
relacionados con el tiempo, por medio del cual los usuarios podrán agrupar sus consultas.
Es importante establecer cuanta historia se almacenará con el fin de determinar el tamaño
final de la BD.
• Workshop Wrap-up
En esta etapa se tienen todos los componentes del modelo conceptual y muchos de los
datos instructivos que ayudaran en la construcción del modelo lógico.
Posteriormente a la etapa del desarrollo del modelo Conceptual se debe observar la
implementación de las soluciones en un modelo Lógico. Para esto existen dos
requerimientos principales que deben ser satisfechos:
MISC-03-1-9
65
1. Exactitud en el reporte de los hechos. Es muy importante que, en un modelo
dimensional, siempre que un hecho de entrada se une con una dimensión de entrada, el
hecho debe unirse a una dimensión correcta en el tiempo.
2. El grabado exacto de cambios en entidades para apoyar consultas que involucran
circunstancias del cliente y vistas de la dimensión.
Según el libro indicado el Modelo Lógico se basa mucho en la aplicación de retrospección.
Observando los diferentes tipos de aplicación mediante el uso de atributos de existencia (
esto se podría hacer mediante el uso de una fecha de efectividad) o también puede
utilizarse la dimensión tiempo con el fin de unir las circunstancias y las dimensiones.
El atributo de existencia podría ser implementado usando una sencilla fecha de
efectividad. Esta tienen la ventaja que nosotros podemos determinar cuando un cambio
ha ocurrido.
El propósito de la dimensión tiempo es proveer un mecanismo de agrupamiento de los
hechos, así como se hace con las otras dimensiones en el modelo. La dimensión de
tiempo provee una interfase simple a usuarios cuando se formulan consultas.
Reconociendo el hecho que los DW´s son bases de datos temporales, la inclusión
explicita de la dimensión tiempo podría considerarse como innecesaria, ya que el soporte
para el tiempo es implícito en la solución.
Esto significa que el diagrama no necesita modelar la dimensión tiempo explícitamente.
Sin embargo, causa un problema con la metodología de modelamiento ER en que se
estaría desviando para tener entidades implícitas que se juzgan para existir pero se
excluyen del diagrama. La metodología de modelamiento dot no tiene esta limitación.
Adicionalmente en el diseño Lógico además de la aplicación de la Retrospección debe
analizarse los siguientes temas:
MISC-03-1-9
66
Consideraciones de Desempeño
Frecuencia de captura de datos cambiados
Constraints
Constraint de Borrado
7.1.3 Metodología de Desarrollo de un ODS
En Inmon (1999) se plantea la primera metodología para trabajar en un ODS, según
Inmon para la implementación de un ODS se debe dividir en las siguientes secciones:
Pasos de Administración del proyecto. Estos pasos son para la planeación general del
proyecto, dimensionamiento y fases del proyecto, evaluación del proyecto y
mantenimiento del ODS.
Los pasos que constituyen esta primera etapa son:
Lanzar del Proyecto
Determinar el Tamaño General
Desarrollar las Fases del Proyecto
Evaluar el proyecto
Convertir el prototipo a Producción.
Planear la próxima fase del ODS
Ejecutar el mantenimiento de las aplicaciones del ODS
Realizar el mantenimiento de la Base de Datos
Ejecutar el mantenimiento del ambiente del usuario final
Pasos de Prerrequisitos. Para asegurar que el ambiente técnico esta establecido y esta
establecido cuando se requiere.
Los pasos son los siguientes:
Desarrollo de la Arquitectura del ODS
Seleccionar el Hardware y Software
MISC-03-1-9
67
Construir el Ambiente Técnico
Estimar los Requisitos de Capacidad
Documentar los Requerimientos del ODS para la fase I
Pasos del Diseño del Proceso. Estos pasos son enfocados hacia el desarrollo del
proceso operacional del ODS. Entre estos se incluye el desarrollo de un Modelo de
proceso de Alto nivel, Generación de requerimientos de procesos detallados, análisis de
código operacional existente para ser reutilizado, generación de pseudo código, y
aplicación del código de aplicación para la primera fase del proyecto.
Los pasos que componen la etapa de Diseño son las siguientes:
Desarrollar el Modelo de Función de Alto Nivel
Generar los procesos de Descomposición
Generar Requerimientos de Aplicación Detallados
Usar y Re usar tanto código como datos existentes
Generar Código y Pseudo código para las Aplicaciones
Generar Código de la Aplicación del ODS
Pasos del Diseño de Datos. En esta parte se crea la Base de Datos del ODS. Esta
incluye la creación del diagrama del área de sujetos, los modelos de datos lógicos y
físicos, el mapeo del registro del sistema fuente y la población de la base de datos del
ODS.
Los pasos que hacen parte de esta etapa son
Crear el Diagrama Corporativo de área de sujetos
Crear el Modelo de Datos Lógico
Crear el Modelo Físico del ODS
Convertir los Datos Históricos
Construir la Base de Datos Física
Identificar el Registro del Sistema
MISC-03-1-9
68
Crear los programas de Extracción y Transformación
Poblar la Base de Datos
Pasos de Pruebas del Sistema. Estos son los pasos usados para probar la interacción
entre las aplicaciones del ODS y la Base de Datos. Entre estas pruebas se tiene en
cuenta las pruebas de Unidad, del Sistema, Aceptación y pruebas de estrés para las
aplicaciones del ODS, calidad de datos del ODS, pruebas de aceptación para la Base de
Datos del ODS. Los pasos son los siguientes:
Desarrollar los Scripts de pruebas y el ambiente de pruebas
Ejecutar las pruebas de las aplicaciones del sistema
Ejecutar las pruebas de Extracción y Transformación de Datos
Pasos de Ambiente del Usuario Final. Estos pasos son usados para crear el ambiente de
usuario final y repositorio de los metadatos. El ambiente contiene la habilidad de generar
consultas analíticas así como reportes estándares e interfaces para los datos.
Los pasos que hacen parte de esta etapa son los siguientes:
Desarrollar el Repositorio de Metadatos y su acceso
Seleccionar las herramientas de usuario final
Crear los Reportes estándares
Desarrollar la Documentación para el usuario final
Desarrollar el entrenamiento inicial
7.1.4 Análisis de Metodologías relacionadas con DW y Minerías de Datos
Se desea mediante el análisis establecer los puntos débiles y fuertes de cada una de las
metodologías explicadas. Con ello se buscará obtener lo mejor de ellas para extraer y
MISC-03-1-9
69
proponer una metodología sencilla con objetivos claros y prácticos que permita el
desarrollo de un ODS.
Metodologías Características Ventajas Desventajas Puntos
Destacados Ciclo Virtuoso del Data Mining
Enfocada a la Minería de Datos Sencilla, Cuatro etapas claras para identificar y trabajar en la minería de datos
Hace énfasis en la necesidad de trabajar con los usuarios, así como también en obtener una buena calidad de datos con el fin de tener una base sólida sobre la cual obtener resultados que puedan ser medidos.
Salvo algunas etapas es propia del desarrollo de Data Mining y por tanto no es posible generalizarla hacia el desarrollo de otras aplicaciones de datos.
El apoyo en los usuarios. La necesidad de datos limpios.
Desarrollo de un ODS - Inmon
Enfocada a la implementación de un ODS.
La primera y única Metodología al respecto.
Sin formatos. Es rígida. Es la única que existe. Como explica el propio autor el libro se convierte a la vez en el mejor y el peor enfoque hacia el desarrollo de un ODS. Se necesita otra visión sobre como implementar un ODS.
Contiene información detallada de los pasos a seguir.
Metodología Dot Integra usuarios con IT. El modelo conceptual es simplificado, lo cual hace que los usuarios puedan entenderlos fácilmente.
Formatos claros y detallados.
Esta centrada en el desarrollo del modelo Conceptual y parte del modelo lógico. Pero, descuida de alguna manera la implementación del modelo al momento de desarrollarlo.
Hace un uso participativo de las personas de negocio. Integra correctamente a IT con los usuarios. Tiene unos formatos explícitos que soportan de manera adecuada el desarrollo del modelo conceptual.
Tabla No. 2. Análisis de distintas metodologías relacionadas con Bodegas de Datos y
Minería de datos
Revisando cada una de estas metodologías se encuentran fortalezas y deficiencias. Con
la metodología propuesta se toman aquellos aspectos que son fundamentales en todo
MISC-03-1-9
70
ciclo como es el levantamiento de Requerimientos; pero, se busca añadir puntos clave
que permiten diferenciarla y hacerla más apta para un proceso de implementación de un
ODS. De las metodologías vistas anteriormente se puede indicar que es destacable de
una la necesidad de la interacción con los usuarios, de la otra que es bastante explicita en
sus pasos y de la otra que hace énfasis en la exactitud de los datos.
La Metodología que se propone a continuación posee partes esenciales de una etapa de
diseño e implementación. Pero hace énfasis en la parte de los procesos ETL que son
necesarios en el cargue de la información. Estableciendo precondiciones propias a cada
una de las etapas correspondiente a este proceso en general. La idea con ello es que al
realizar el diseño se facilite mucho la tarea de la implementación y las posteriores
pruebas.
MISC-03-1-9
71
8 PROPUESTA METODOLÓGICA PARA LA IMPLEMENTACION DE UN ODS
Antes de comenzar a utilizar la propuesta metodológica propuesta se debe analizar si el
problema que se tiene en la Organización puede ser solucionado mediante la
implementación de un ODS. El punto 6.2 nos da unas pistas sobre este análisis.
La propuesta metodológica esta conformada por una serie de pasos resumidas en tres
grandes etapas: Análisis y Diseño, Desarrollo y Aprobación. Los pasos en cada etapa
deben desarrollarse en forma secuencial, para poder pasar a la etapa siguiente. Así
mismo las tres se encuentran unidas en un ciclo que permite el mantenimiento del ODS
cuando este se ha implementado. Las modificaciones a las definiciones del Modelo de
Datos son hechas posteriormente, puesto que el negocio cambia con el tiempo y las
necesidades para obtener la información que soporten la estrategia planteada también.
La metodología ayuda en el proceso de identificar la información a cargar, así como todo
el proceso subsiguiente de extraer, transformar y cargar la información hacia el ODS.
Esta basada en la utilización de Sistemas Manejadores de Flujos de Trabajo. Lo cual
permitirá que el diseño de los procesos de ETL sean fácilmente desarrollados, seguidos y
puestos en marcha.
Existen otras etapas entre las cuales se destacan el desarrollo del modelo Global,
establecimiento de las equivalencias y toda la parte de identificación de las herramientas
de HW y SW sobre la cual se implantará el ODS.
Se propone una distribución de tiempo para la aplicación de la propuesta metodológica de
la siguiente manera:
Análisis y Diseño 40 - 50%
Desarrollo 40 - 30%
Aprobación 20%
MISC-03-1-9
72
Figura No. 8 : Flujo de Implementación de un ODS
8.1 ANALISIS Y DISEÑO
En esta etapa de implementación del ODS se da inicio al proyecto. Se debe reunir un
grupo de personas encargadas de la puesta en marcha del proyecto, se deben identificar
un conjunto de personas que colaboren en la implementación. Entre estas personas se
debe disponer de un Patrocinador del Proyecto, un Líder del proyecto por parte de IT, un
líder usuario ( que represente las necesidades de los usuarios), un conjunto de ingenieros
y analistas del negocio que trabajen en el diseño del ODS a implementar.
Todo este grupo de personas se convertirán en un equipo de trabajo que se encargaran
de realizar el lanzamiento del proyecto, liderarlo y ponerlo en marcha.
La etapa de Diseño se divide a su vez en una serie de pasos que deberán realizarse.
Requerimientos Funcionales
• Defin ición del Modelo de Datos • Requerim ientos de Usuarios • Grafos de F lujos de Datos • P lataformas de Software y Hardware • Especificación de Metadatos y ODS • Periodicidad de Transm isión de Datos• Defin ición de Metadatos • Defin ición de la Base de Datos que
soporta el ODS • Defin ición de la Interfase
• Pruebas de Cargue • Documentación de Pruebas • Aseguram iento de puntos de chequeo• Puesta en m archa • Reprocesos
• Desarrollo de Metadatos • Desarrollo de Bases de Datos que soportan el ODS • Generación de program as ETL • Creac ión de Interfase
DISEÑO
DESARROLLO APROBACION
MISC-03-1-9
73
Determinar el Enfoque del ODS. Se establece una reunión inicial entre el Patrocinador, el
líder de IT, el líder usuario donde se firma el compromiso para comenzar a trabajar en la
etapa de análisis de requerimientos y diseño del sistema:
El soporte en esta etapa es un documento de Requerimiento Funcional (Anexo 1), para
este primer paso se definen los siguientes ítems:
Objetivo : Se establece el Objetivo general del proyecto
Alcance : aquí se definen los limites que se abarcarán en el desarrollo del ODS
Necesidades : se plantean los puntos que hacen necesario el desarrollo del sistema
propuesto.
Áreas usuarias y Representante: se definen las áreas usuarias implicadas, por cada una
de ellas se define un representante.
Glosario de Términos: se definen los conceptos propios referentes al proyecto, con el fin
de hablar en las reuniones siguientes en un solo lenguaje común.
Se establecen reuniones periódicas ( no más de cinco) donde un grupo de analistas del
negocio ( cada uno de los representantes de las áreas usuarias) y un grupo de ingenieros
elaboran conjuntamente los Requerimientos Funcionales. Estas reuniones dependen de
la disponibilidad de los usuarios, es importante que exista el compromiso por parte de
todos los implicados en el desarrollo. Para ello es necesario reservar unas horas en el
calendario de cada uno para que estén presentes. Es importante que las reuniones sean
continuas y con las mismas personas en cada sesión. Se sugiere esto porque si las
reuniones son muy distantes en tiempo es posible que se pierda la idea inicial del
proyecto. Así mismo deben estar las mismas personas porque al haber un reemplazo de
un usuario por otro, generalmente lo que ocurre es un choque de ideas entre lo que pide
originalmente el primero y lo que podría solicitar el segundo.
En este paso se complementa el documento inicial con la siguiente información:
Modelo Actual: se dibuja gráficamente lo que se dispone actualmente.
Situación actual: se describe en palabras el inconveniente actual.
Modelo Propuesto: se dibuja gráficamente que es lo que se requiere.
MISC-03-1-9
74
Situación Propuesta: se describe en palabras los beneficios que conllevaría el desarrollo
de un ODS.
Definición de las Consultas o Reportes. Dentro del documento se define un ítem
correspondiente a consultas. En este ítem correspondiente a Consultas se llena cada uno
de los reportes solicitados. En este paso se coloca la información correspondiente a
Periodicidad Se explica con que periodicidad se ejecuta el reporte que puede ser a
solicitud, diario, semanal, o mensual.
Día de ejecución Se indica que día calendario debe ser entregada la información o el
día de la semana. Por ejemplo: lunes, martes o el día 5 de cada mes.
Lista de Campos Es un listado de los campos o columnas con su descripción, esta
información hace parte de los metadatos.
Campos de Agrupamiento campos por los cuales se puede agrupar la información del
reporte
Campos Sumables campos sobre los cuales se realiza alguna operación de computo
como Sumas, Formulas.
Tipo de presentación Como se presentará este archivo a los usuarios, en que formato.
Por ejemplo puede ser archivo plano *.txt, *.lst, o un *xls (MS Excel)
Parámetros de ejecución se indican los parámetros de ejecución necesarios para
ejecutar el reporte. Entre estos parámetros están los rangos de fechas, con su formato
establecido.
Ejemplo del reporte Se describe como es la extracción de la información y como se
visualizaría este.
Es decir los reportes son definidos de esta manera permitiendo que las personas de IT
identifiquen posteriormente con estas consultas las dimensiones de las cuales se requiere
mayor numero de información.
Modelo de Datos de las Fuentes Se recolecta la información de las fuentes desde las cuales se extrae la información, es
decir se busca el modelo de datos parcial de lo que se desea integrar en el ODS. Este es
un buen punto de referencia para establecer el Modelo de Datos del ODS. Se requiere
de las fuentes la siguiente información:
MISC-03-1-9
75
Modelo de las Entidades Originales se considera las entidades que se tendrán en
cuenta para representarlas en el ODS.
Listado y Descripción de las Entidades se describe por cada una de las entidades las
características que presentan. Por cada una de las entidades se lista los campos.
Notas Generales Se anexa información concerniente a las características generales
del sistema que se representa.
Esta información es recopilada en un formato de Modelo de Datos de las Fuentes (Anexo
2)
Escogencia del Tipo de ODS Las clases de ODS se explicaron anteriormente en el punto 6.1.2. Y se realiza un breve
resumen aquí:
Tipo I – Actualización sincrónica.
Tipo II – Se realiza una actualización cada 3 o 4 horas.
Tipo II – Se actualiza la información cada 24 horas aproximadamente.
Tipo IV – la información se carga de un DW y generalmente no es programable su
actualización.
Teniendo en cuenta estos tipos de ODS, la propuesta metodológica plantea una serie de
pasos y Grafos de cargue y actualización de información que se ajustan mas a los tipos II
y III. Sin embargo es posible extenderla de cierta manera a los otros tipos si se definen la
forma de capturar las modificaciones.
Diseño del Modelo de Datos del ODS Teniendo en cuenta las consultas que se deben disponer en el ODS se debe crear un
Modelo de Datos que cumpla con ellas. La escogencia del modelo es muy flexible en este
punto, la metodología no pretende proponer un sistema propio de modelamiento, se
pueden utilizar los métodos de modelamiento tanto Relacional como Dimensional. La
MISC-03-1-9
76
diferencia entre la utilización de uno u otro es determinada por el tipo de información que
se desea reflejar en el ODS.
Las tablas, campos, periodicidad, datos sumables determinara que modelo de datos será
mas apropiado a aplicar entre ellos están los siguientes: Relacional, Dimensional o
Híbridos.
Relacional : Si la información que se requiere tiene una precondición de integridad
referencial debe utilizarse este tipo de modelo.
Dimensional : Si lo que se requiere es un sistema con información agrupada y muchos
datos resumidos. Este tipo modelo es el adecuado.
Si requiere una información híbrida pues es posible instalar en el ODS un modelo de
datos relacional intercalado con algún conjunto de tablas que agrupen los datos.
Se debe tener en cuenta que en un ODS los datos están detallados, en un DW los datos
son una mezcla de resumidos y detallados.
Este modelo de datos debe ser documentado en un formato de Diseño de Modelo de
Datos (Anexo 3). Dentro de este formato se colocara la siguiente información:
Lista de Entidades del ODS se enumera las entidades participantes en el modelo de
datos
Un diseño de modelo de datos representa gráficamente el modelo a implementar
Descripción del modelo se coloca una breve descripción escrita del modelo a
implementar.
Por cada una de las entidades implicadas en el modelo se coloca la información
necesaria:
MISC-03-1-9
77
Descripción de la entidad se describe las características de esta entidad y su
importancia dentro del modelo de datos.
Fuente de Origen Se indica cual es la Base de Datos origen, indicando que sistema
representa.
Nombre de la Entidad fuente se explica cual es la entidad o entidades originales de
las cuales esta compuesta esta entidad destino.
Proceso de Transformación se indica si la entidad sufrió algún proceso de
transformación.
Periodicidad de cargue se debe definir por cada una de las entidades cada cuanto
tiempo se cargará la información.
Lista de campos por cada uno de los campos se debe describir su información y al lado
de cada uno el tipo.
Llave Primaria se define la llave primaria de la entidad en referencia.
Se debe tener especial cuidado que el Modelo de Datos propuesto sea elaborado
cumpliendo los requerimientos y sobre todo las consultas o reportes solicitados. Para ello
se debe evaluar el Modelo de Datos con cada uno de los reportes solicitados, una forma
de hacer esta evaluación es haciendo una validación de completitud de entidades y
completitud de campos.
Completitud de Entidades
El procedimiento permita cruzar las entidades del Modelo contra las consultas o Reportes
solicitados en el requerimiento funcional, esto permitirá evaluar la consistencia del Modelo
de Datos Propuesto.
Entidades
Consultas
Entidad 1 Entidad 2 Entidad 3 Entidad m
Completitud de Entidades ( Completa o Incompleta)
Consulta 1 X X Completa Consulta 2 X X X Completa
... ... Consulta n X X Completa o Incompleta
Tabla No. 3. Completitud de Entidades.
MISC-03-1-9
78
Un valor completo indica que en el modelo de datos están todas las entidades necesarias
en la consulta. Un valor incompleto indica que en el modelo de datos no están todas las
entidades requeridas.
El valor de completitud permitirá saber si la consulta i requerida en el modelo esta
satisfecha completamente.
El porcentaje de Completitud permitirá definir si el modelo cumple con todas las consultas
que los usuarios requieren
Completitud del Modelo ODS = (completas) / n * 100
N : Al número de consulta requeridas.
Completitud de Campos
Dependiendo del análisis realizado en el punto anterior se organizan de mayor a menor
las entidades con sus respectivos campos, determinando por cada uno de ellos los que
son requeridos y lo que no lo son. Entidad Campos Consulta 1 Consulta 2 ... Consulta n Entidad 1 Campo 1 X X Entidad 1 Campo 2 X X Entidad 1 Campo n X X Entidad 2 Entidad 2 X X Entidad 2 Campo 1 X X Entidad 2 Campo 2 X X
... Entidad m Campo n X X
Tabla No. 4. Completitud de Campos. Para el cargue inicial es indispensable identificar aquellos que son prioritarios para
implementarlos en el ODS, aquellos campos que tiene importancia baja deben ser
MISC-03-1-9
79
negociados con los usuarios para identificar si se deben cargar inmediatamente o si
pueden ser cargados posteriormente en una segunda etapa del ODS.
• Al escoger el sistema de almacenamiento de los metadatos es recomendable que
esta se encuentre en el mismo sitio donde esta el ODS, con el fin de facilitar su
acceso.
Definición de equivalencias entre el esquema global y cada esquema local
• En las multibases de datos los conflictos se deben manejar en tiempo de
ejecución, es decir que al momento de realizar la consulta esta se divide en
subconsultas en las cuales se debe analizar los tipos de conflictos,
transformaciones y fragmentaciones. Por el contrario en una ODS toda esta tarea
se realiza al momento de cargar la información al ODS. Es decir es manejado con
los programas ETL.
Existen distintos tipos de conflictos, entre los cuales se destacan los siguientes:
Problemas de Fragmentación Horizontal: Cuando una estructura de tabla es dividida
lógicamente en dos o más bases de datos. La fragmentación particiona una tabla en
diferentes tuplas (filas o registros)Cada fragmento tiene un subconjunto de las tuplas de la
tabla. Este tipo de problemas se soluciona con una operación de unión entre los distintos
fragmentos.
Problemas de Fragmentación Vertical: Cuando una tabla R esta dividida en dos o más
componentes donde cada una de ellas contiene atributos de las tablas y una llave
primaria de la tabla R. Este inconveniente se soluciona con una operación de reunión
entre los elementos fragmentados.
MISC-03-1-9
80
Problemas de Tipos de Atributos Distintos: Cuando un atributo en una base de datos
tiene una representación distinta en otra tabla. Se maneja con conversiones en el ámbito
de columnas. Se deben establecer equivalencias en el ámbito de columnas.
Problemas de Nombramiento: Cuando un mismo atributo posee dos nombres distintos
en dos tablas. Se maneja con equivalencia y transformaciones simples referentes a
columnas.
Todas estas equivalencias se pueden manejar de dos maneras por medio de codificación
en los programas ETL o usando tablas de equivalencias que indicarán las relaciones de
conflictos entre distintas bases de datos.
Paso Directo de las Fuentes al ODS
Cuando las tablas de las Bases de datos locales tienen una representación directa en el
ODS debe reflejarse esta equivalencia en un documento de Definición de
Transformaciones (Anexo4) Si ocurre algún tipo de transformación referente columnas
escribirse a cual se refiere. Las Transformaciones en columnas se refieren
generalmente a conversiones entre un campo de la fuente y un campo de la tabla destino.
Esquema Local –
BD 1 Esquema Global -
ODS Transformación de columnas
(Copiar, Substring, Formateo de fechas, etc) Tabla 1 Tabla 1 Tabla 1 – Campo 1 Tabla 1 – Campo 1 Copiar Tabla 1 – Campo 2 Tabla 1 – Campo 2 Substring Tabla 1 – Campo 3 Tabla 1 – Campo 3 Formateo de Fechas Tabla 2 Tabla 2 Tabla 2 – Campo 1 Tabla 2 – Campo 1 Copiar Tabla 2 – Campo 2 Tabla 2 – Campo 2 Substring
Esquema Local – BD 2
Esquema Global - ODS
Transformación de columnas (Copiar, Substring, Formateo de fechas, etc)
Tabla 1 Tabla 1 Tabla 1 – Campo 1 Tabla 1 – Campo 1 Copiar Tabla 1 – Campo 2 Tabla 1 – Campo 2 Substring Tabla 1 – Campo 3 Tabla 1 – Campo 3 Formateo de Fechas
Tabla No. 5. Paso Directo de Fuentes a tablas del ODS
MISC-03-1-9
81
Así mismo si en el proceso de cargue de la información al ODS es necesario cargar
inicialmente las tablas de las fuentes a tablas temporales del ODS, estas deben también
ser documentadas aquí.
Esquema Local –
BD 1 Esquema Local – ODS Transformación
(Copiar, Substring, Formateo de fechas, etc)
Tabla 1 Tabla Temporal 1 Tabla 1 – Campo 1 Tabla Temp 1 – Campo 1 Copiar Tabla 1 – Campo 2 Tabla Temp 1 – Campo 2 Substring Tabla 1 – Campo 3 Tabla Temp 1 – Campo 3 Formateo de Fechas
Tabla No. 6. Paso Directo de Fuentes a tablas temporales del ODS
Transformaciones entre Entidades
Cuando la información de las fuentes originales no puede ser cargada en el ODS
directamente, sino que surge como un proceso de integración entre dos o más tablas,
debe documentarse esta información en un documento de Definición de
Transformaciones (Anexo 4), que permita identificar claramente las operaciones que se
realizan entre las tablas del ODS, para establecer una visión integrada de la información.
Objetos Tablas Iniciales del ODS Tabla Destino
del ODS Operación ( Unión, Intersección,
Extracción, etc.) Tablas Tabla 1 Tabla 2 Tabla 3 Intersección ( Tabla 1 y Tabla 2) Campos Relacionados
Campo 1 Campo 1 Donde Tabla1.Campo1 = Tabla2.Campo1
... ... ... ... ...
Tabla No. 7. Transformaciones entre Entidades
Definición de Captura de Modificaciones Las modificaciones deben ser fácilmente identificables en los sistemas en línea. Las
Modificaciones en las BD´s de los sistemas en línea pueden ser identificadas mediante
log generados en la Base de datos, así como modificaciones en las tablas registradas en
tablas de auditoria o por medio de consultas directas a las tablas de hechos validando
mediante fechas de cambios estas transformaciones. Dependiendo de esta clase de
MISC-03-1-9
82
identificación de modificaciones se podrá realizar el paso de la información de las BD
fuentes hacia el ODS. Se pueden acceder a estos cambios de tres maneras:
Consultando directamente la información en las BD´s Transaccionales por medio de
conexión establecida entre el ODS y estas BD´s. Esto es poco probable que esto sea
permitido debido al impacto generado sobre estos sistemas debido a su alta
transacionalidad.
Las otras dos maneras consisten en generar tablas temporales dentro de las BD`s
transaccionales que contengan los cambios hechos en las tablas originales. La otra
posibilidad y la que menos impacto tiene sobre los sistemas es crear archivos planos que
poseen los registros que han cambiado.
Periodicidad Los ODS están clasificados según su periodicidad de paso de información de los sistemas
operacionales hacia el ODS. En esta etapa se define esta periodicidad.
• Determinar la periodicidad del paso de la información de las fuentes orígenes
hasta el destino. Esto se hace con una conciliación entre las partes usuarias y los
administradores de las Bases de Operacionales, ya que puede que el usuario
requiera la información con cierta periodicidad, pero este grupo de expertos
indiquen que no es posible extraer la información a ese ritmo.
• Se debe tener en cuenta que a medida que se desee que el tiempo de transmisión
entre la fuente origen y destino sea más pequeño se aumentará la complejidad de
tal tarea, puesto que cuando se desea transferir casi en línea se gasta mucho en
procesamiento de máquina y el impacto en los sistemas operacionales es grande.
Por lo tanto esto casi nunca se debería hacer a menos que su beneficio sea muy
alto comparado con el costo que representa.
• Así como existe un tiempo de paso de los sistemas en Línea hacia el sistema
ODS, también debe existir un tiempo de borrado de esta información. Antes de
que la información sea borrada es buena practica realizar una transferencia de
estos datos hacia un Datamart o hacia un DW corporativo, por supuesto haciendo
MISC-03-1-9
83
previamente una depuración y transformación de información si es necesaria.
Este paso de un sistema ODS hacia otro repositorio se podría realizar en Línea o
mediante el almacenamiento de la información en archivos planos que
posteriormente serán cargados al Datamart o DW.
Revisar si las necesidades del proyecto requieren de la utilización de una Herramienta
ETL o si es suficiente con programas hechos a la medida. Aquí es importante destacar el
costo de las dos propuestas.
La Variable periodicidad deber ser de público conocimiento y debe ser de tipo Hora.
Variables de Tiempo
El tiempo determina el orden a cargar. Las tablas maestras se cargan inicialmente para
evitar inconvenientes con las tablas de modificaciones, debido a la integridad referencial
que pueda existir entre ellas. Dependiendo del tiempo se establece una identificación de
la información a cargar, si es a partir de una tabla origen al momento de extraer la
información se pueden crear vistas con una nomenclatura que indique que la tabla fue
generada a cierto momento del día. Si el origen es un archivo plano debe indicarse por
nomenclatura estos archivos.
Usando vistas temporales se pueden identificar mediante una nomenclatura como
NOMBRETABLA_DDMMYYYYHH24MISS
donde
NOMBRETABLA = Nombre de la tabla en la Base de Datos
DDMMYYYYHH24MISS = Hora de generación de la información
por ejemplo SERVICIOS_01022003120000
Utilizando archivos planos se pueden identificar mediante una nomenclatura como
NOMBRETABLA_DDMMYYYYHH24MISS.EXT
Donde
NOMBRETABLA = Nombre de la tabla en la Base de Datos
MISC-03-1-9
84
DDMMYYYYHH24MISS = Hora de generación de la información
EXT = Extensión que indique que es un archivo plano, esta extensión puede ser LIS,
TXT, CSV, etc.
Un ejemplo de un archivo de estos es SERVICIOS_01022003120000.lis
Si la obtención de la información es a partir de un archivo plano es necesario definir un
delimitador de columnas para la información, este delimitador puede ser “|” ó “,” ó “;”.
Además de la variable Tiempo existen otras variables en el ODS.
Tiempo Inicial (Ti) Indica la primera fecha de la cual se extrajo la información de las
BD´s para cargarlas al ODS. Esta variable es de tipo fecha: DD/MM/YYYYHH24MISSS
Periodicidad (Per) Como se menciono en el punto anterior es una variable Hora que
indica por ejemplo que la información se carga cada 8 o 12 horas.
Tiempo de Extracción (Te) Refleja la fecha a la cual se tomará la fotografía por así
decirlo de las BDs de los sistemas transaccionales. Esta variable es de tipo fecha:
DD/MM/YYYYHH24MISSS
La primera vez que se extrae la información del ODS Te = Ti. Posteriormente en los
cargues subsiguientes el nuevo Te es determinado por la siguiente fórmula: Te = Te +
Per
Fecha Primer Cargue (Fp) Indica la fecha en la cual fue cargado por primera vez el
ODS. Esta variable es de tipo fecha: DD/MM/YYYYHH24MISSS
Tiempo de Cargue (Tx) Debido a que las bases de datos no extraen las tablas en la
misma fecha a la que pertenecen los datos, se define un tiempo X de espera para cargar
la información al ODS. Por ejemplo la extracción de las BD´s es a las 27/07/2003
08:00:00 pero el generar esta información y colocarla en un archivo plano se demora 2
minutos. Es decir el archivo se generó a las 27/07/2003 08:02:00. El tiempo x permite
MISC-03-1-9
85
dar este lapso de espera para que posteriormente se cargue el archivo al ODS. El Tx
para este ejemplo podría estar determinado como 5 minutos de espera: 00:05:00.
Fecha del ultimo Cargue (Fu) Indica la fecha en la cual fue cargado por primera vez el
ODS. Esta variable es de tipo fecha: DD/MM/YYYYHH24MISSS
De las variables descritas anteriormente son parametrizables al inicio del ODS las
variables Tiempo Inicial (Ti), Tiempo de cargue (TX) y Periodicidad (Per). Las demás
variables solo son de consulta y son actualizadas mediante la ejecución de cada uno de
los procesos de ETL. Estas variables deben poder ser consultadas en el ODS, por lo
tanto lo más recomendable es establecer una tabla de Variables Tiempo.
TABLA DE VARIABLES Campo Tipo Tiempo inicial Fecha (DD/MM/YYYY HH24:MI:SS) Periodicidad Hora (HH24:MI:SS) Tiempo de Extracción Fecha (DD/MM/YYYY HH24:MI:SS) Fecha de primer cargue Fecha ( DD/MM/YYYY HH24:MI:SS) Tiempo de cargue Hora (HH24:MI:SS) Fecha del ultimo cargue Fecha (DD/MM/YYYY HH24:MI:SS)
Tabla No. 8. Tabla de Variables del ODS Para entender mejor el funcionamiento de estas variables se expondrán a continuación en un ejemplo:
Figura No. 9 : Cargue y Actualización de información en un ODS.
MISC-03-1-9
86
Los datos se extraen de las fuentes de datos en el Te (Tiempo de Extracción), que en su
primera ejecución es igual al Ti (Tiempo Inicial). Es decir se genera información
correspondiente a la fecha Te, es como una fotografía de las fuentes en el tiempo Te.
Después de cierto tiempo (T’) se extrae completamente la información de las fuentes.
Se establece un Tiempo de Cargue (Tx) que corresponde al verdadero tiempo en cual se
realizara el cargue de la información al ODS. Después de realizar todo el proceso de
cargue y transformación se posee todos los datos completos en el ODS. Es aquí donde
se define el tiempo Fp ( fecha del primer cargue), el cual es igual en su primera ejecución
es igual al Fu ( Fecha del ultimo cargue). El Te (Tiempo de Extracción) es actualizado
según la Per (periodicidad) definida en el sistema, es decir Te = Te + Per. Esto significa
que el próximo cargue se realizara cuando la fecha del sistema sea nuevamente igual a
Te.
Desarrollo de Grafos de Flujo de Datos Se deben desarrollar Grafos que permitan identificar los pasos necesarios para la
obtención de la información pasándola al ODS. Estos grafos son manejados al nivel de
diseño, pero ayudarán en la programación y monitoreo durante la ejecución. Estos grafos
deberían ser documentados en un formato de Flujo de Trabajo (Anexo 6) Es necesario
establecer reglas de coordinación: Dependencias entre tareas y referencias al nivel de
tiempo. Aquí la variable tiempo es muy importante ya que se manejarán precondiciones
al nivel de esta variable para ejecutar procesos, por ejemplo para realizar el cargue se
tendrá una variable tiempo que se comparará contra la nomenclatura del archivo o tabla
de la fuente original y a partir de allí se valida si existe o no esta entidad.
Los pasos de cada uno de los grafos se resumirían en lo siguiente:
Grafos de Cargue Inicial
Existen una serie de grafos que se realizan al momento del cargue inicial, con ciertas
precondiciones
MISC-03-1-9
87
C AR G U E IN IC IAL
C argue del S itio 1 C argue del S it io 2 C argue de l S itio n
C hequearC onexiones
V alida rIn fo rm ación
La in fo rm ación esconsistente ?
R eportarIncons is tenac ia
Integ rar tab las segúnEsquem a Global
Figura No. 10 : Diagrama de Flujo de Procesos para el Cargue de información en un ODS.
Grafos de Cargue Inicial - Cargue de Tablas Maestras
Las tablas maestras se convierten en precondición para el cargue de las demás
entidades. Por cada Tabla maestra se establece un grafo de flujo de datos. Que indica la
conexión entre el Origen y el Destino y el proceso de cargue. Como precondición para
este cargue se deben haber cargado las tablas maestras. Así mismo deben estar creadas
las tablas de hechos en el ODS con su estructura pero sin ningún registro.
Establecer el Grafo que indica el Levantamiento de los requerimientos y aceptación por
parte de los usuarios del modelo levantado.
MISC-03-1-9
88
1. Escoger la fuente Origen. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente
origen con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
2. Seleccionar la entidad origen a cargar. Dependiendo de la conexión directa o
indirecta. Una conexión directa indica que la entidad se encuentra en una
Base de Datos del sistema en Línea. Cuando existe una conexión indirecta se
debe buscar la información generada en un archivo plano.
Agente : Un programa de software
Chequeo : Validación de la entidad origen.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
3. Verificar la fuente destino. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente
origen con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
MISC-03-1-9
89
4. Seleccionar la entidad destino donde se cargará la información. Dependiendo
de la conexión directa o indirecta se accede a una tabla si se encuentra en una
Base de Datos o un archivo plano si la conexión es indirecta.
Agente : Un programa de software.
Chequeo : Validación de la entidad destino.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
5. Borrar los registros que posea la tabla destino. Se borran los registros mas no
la estructura de la entidad fuente donde se cargará la información. Esta tarea
se realiza porque es posible que se haya cargado previamente registros en
estas tablas, los cuales podrían ocasionar problemas al momento de la carga.
Agente : Un programa de software.
Chequeo : Que se borren los datos de la tabla destino si los hay.
Estado : Exitoso o No Exitoso
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = No exitoso se informa y se detiene el proceso.
6. Establecer el proceso de Extracción, Transformación y Cargue. En este paso
se realiza la extracción de los atributos de la fuente original con la fuente
destino, si es necesario un proceso de transformación al nivel de columnas se
realizará en esta etapa. Se indica si es necesario porque puede darse el caso
en que los campos Origen y destino sean iguales y no halla necesidad de
realizar alguna conversión. Posteriormente a esto se realizará una correlación
para realizar el cargue en la entidad destino.
Agente : Un programa de software
Chequeo : Validación acerca del proceso ETL.
Estado : ETL Exitosa o ETL Fallida
Si Estado = ETL Exitosa se continua con el siguiente paso
Si Estado = ETL Fallida se informa y se detiene el proceso.
MISC-03-1-9
90
7. Validación de la información cargada. En este paso se realiza la revisión
previa de la información cargada, se establecen una serie de chequeos al nivel
de datos, estructuras, formatos, en fin son unos pasos de chequeo
Agente : Un analista de la información.
Chequeo : Validación acerca del proceso ETL.
Estado : ETL Exitosa o ETL Fallida
Si Estado = ETL Exitosa se continua con el siguiente paso
Si Estado = ETL Fallida se informa y se detiene el proceso.
Figura No. 11 : Grafo de Flujo de Procesos para el Cargue Inicial de
Tablas Maestras en un ODS.
Grafos de Cargue Inicial - Cargue de Tablas de Hechos
Como precondición para este cargue se deben haber cargado las tablas maestras. Así
mismo deben estar creadas las tablas de hechos en el ODS con su estructura pero sin
ningún registro. Es posible que exista un proceso de integración de distintas tablas que
no es posible realizar en una sola pasada, en cuyo caso los datos serán cargados a una
tabla temporal sobre la cual se realizarán operaciones para integrar la información con
respecto al Esquema Global.
1. Escoger la fuente Origen. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente
origen con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
1. Validar laConexion
2. Seleccionarentidad origen a
cargar3. Verificar la fuente
destino
4 Seleccionar laentidad destino
donde se cargará lainformación
7. Validarinformación cargada.
6. Establecer elproceso de ETL
5. Borrar losregistros que posea
la tabla destino
MISC-03-1-9
91
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
2. Validar que se hayan cargado las tablas Maestras. Se debe realizar una
consulta garantizando que estas tablas se encuentren cargadas. La consulta
puede ser hecha sobre la Base de datos o revisando un Archivo de Log.
Agente : Un programa de software
Chequeo : Validación de la existencia de las Tablas.
Estado : Existente o No existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
3. Seleccionar la entidad origen a cargar. Dependiendo de la conexión directa
o indirecta. Una conexión directa indica que la entidad se encuentra en una Base
de Datos del sistema en Línea. Cuando existe una conexión indirecta se debe
buscar la información generada en un archivo plano.
Agente : Un programa de software
Chequeo : Validación de la entidad origen.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
4. Verificar la fuente destino. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente
origen con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
MISC-03-1-9
92
5. Seleccionar la entidad fuente donde se cargará la información. Dependiendo
de la conexión directa o indirecta se accede a una tabla si se encuentra en una
Base de Datos o un archivo plano si la conexión es indirecta.
Agente : Un programa de software.
Chequeo : Validación de la entidad destino.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
6. Borrar los registros que posea la tabla destino. Se borran los registros mas no
la estructura de la entidad fuente donde se cargará la información. Esta tarea
se realiza porque es posible que se haya cargado previamente registros en
estas tablas, los cuales podrían ocasionar problemas al momento de la carga.
Agente : Un programa de software.
Chequeo : Que se borren los datos de la tabla destino si los hay.
Estado : Exitoso o No Exitoso
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = No exitoso se informa y se detiene el proceso.
7. Establecer el proceso de Extracción, Transformación y Cargue. En este paso
se realiza la extracción de los atributos de la fuente original con la fuente
destino, si es necesario un proceso de transformación al nivel de columnas se
realizará en esta etapa. Se indica si es necesario porque puede darse el caso
en que los campos Origen y destino sean iguales y no halla necesidad de
realizar alguna conversión. Posteriormente a esto se realizará una correlación
para realizar el cargue en la entidad destino.
Agente : Un programa de software
Chequeo : Validación acerca del proceso ETL.
Estado : ETL Exitosa o ETL Fallida
Si Estado = ETL Exitosa se continua con el siguiente paso
Si Estado = ETL Fallida se informa y se detiene el proceso.
MISC-03-1-9
93
8. Validar la información cargada. En este paso se realiza la revisión previa de
la información cargada, se establecen una serie de chequeos al nivel de datos,
estructuras, formatos, en fin son unos pasos de chequeo
Agente : Un analista de la información.
Chequeo : Validación acerca del proceso ETL.
Estado : ETL Exitosa o ETL Fallida
Si Estado = ETL Exitosa se continua con el siguiente paso
Si Estado = ETL Fallida se informa y se detiene el proceso.
Figura No. 12 : Grafo de Flujo de Procesos para el Cargue Inicial de
Tablas de Hechos en un ODS.
Grafos de Cargue Incremental
En el cargue incremental es muy poco frecuente que se carguen tablas maestras pero si
estas han cambiado en su estructura deberán cargarse.
Figura No. 13 : Diagrama de Flujo de Procesos para el Cargue Inicial de
Validar Existenciatabla de Origen Consistente ?
Proceso deTransformación Borrar Tabla
DestinoCargar Tabla
Destino
ReportarInconsistenacia
Consistente ?
ReportarInconsistenacia
Consistente ?
ReportarInconsistenacia
1. Escoger lafuente Origen
2. Seleccionarentidad origen a
cargar3. Verificar la fuente
destino
4 Seleccionar laentidad fuente donde
se cargará lainformación
7. Validarinformación cargada.
6. Establecer elproceso de ETL
5. Borrar losregistros que posea
la tabla destino
MISC-03-1-9
94
Tablas Maestras en un ODS.
Grafos de Cargue Incremental - Grafos de Cargue de Tablas Maestras
1. Escoger la fuente Origen. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente origen
con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
2. Seleccionar la entidad origen a cargar. Dependiendo de la conexión directa o
indirecta. Una conexión directa indica que la entidad se encuentra en una Base de
Datos del sistema en Línea. Cuando existe una conexión indirecta se debe buscar
la información generada en un archivo plano.
Agente : Un programa de software
Chequeo : Validación de la entidad origen.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
3. Verificar la fuente destino. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente origen
con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
MISC-03-1-9
95
Si Estado = Fallida se informa y se detiene el proceso.
4. Seleccionar la entidad fuente donde se cargará la información. Dependiendo de
la conexión directa o indirecta se accede a una tabla si se encuentra en una Base
de Datos o un archivo plano si la conexión es indirecta. La validación se realiza
dependiendo de la variable tiempo, si la entidad o archivo no coincide con la
variable, el proceso fallará.
Agente : Un programa de software.
Chequeo : Validación de la entidad destino con respecto a la variable tiempo.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
5. Establecer el proceso de Extracción, Transformación y Cargue. En este paso
se realiza la extracción de los atributos de la fuente original con la fuente destino,
si es necesario un proceso de transformación al nivel de columnas se realizará en
esta etapa. Se indica si es necesario porque puede darse el caso en que los
campos Origen y destino sean iguales y no halla necesidad de realizar alguna
conversión. Posteriormente a esto se realizará una correlación para realizar el
cargue en la entidad destino.
Agente : Un programa de software
Chequeo : Validación acerca del proceso ETL.
Estado : ETL Existosa o ETL Fallida
Si Estado = ETL Existosa se continua con el siguiente paso
Si Estado = ETL Fallida se informa y se detiene el proceso.
6. Validación de la información cargada. En este paso se realiza la revisión
previa de la información cargada, se establecen una serie de chequeos al nivel de
datos, estructuras, formatos, en fin son unos pasos de chequeo
Agente : Un analista de la información.
Chequeo : Validación acerca del proceso ETL.
Estado : ETL Existosa o ETL Fallida
Si Estado = ETL Existosa se continua con el siguiente paso
MISC-03-1-9
96
Si Estado = ETL Fallida se informa y se detiene el proceso.
Figura No. 14 : Grafo de Flujo de Procesos para el Cargue Incremental de
Tablas Maestras en un ODS.
Grafos de Cargue Incremental - Grafos de Cargue de Tablas de Hechos
Como precondición para este cargue se deben haber cargado datos en las tablas de
hechos. Posteriormente dependiendo de la variable fecha se establecen las entidades o
archivos a cargar.
1. Escoger la fuente Origen. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente
origen con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
2. Validar que se hayan cargado las tablas Maestras. Se debe realizar una
consulta garantizando que esta tablas se encuentren cargadas. La consulta
puede ser hecha sobre la Base de datos o revisando un Archivo de Log.
Agente : Un programa de software
Chequeo : Validación de la existencia de las Tablas.
Estado : Existente o No existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
1. Escoger lafuente Origen
2. Seleccionarentidad origen a
cargar3. Verificar la fuente
destino
4 Seleccionar laentidad fuente donde
se cargará lainformación
6. Validarinformación cargada.
5. Establecer elproceso de ETL
MISC-03-1-9
97
3. Seleccionar la entidad origen a cargar. Dependiendo de la conexión directa o
indirecta. Una conexión directa indica que la entidad se encuentra en una Base de
Datos del sistema en Línea. Cuando existe una conexión indirecta se debe buscar
la información generada en un archivo plano.
Agente : Un programa de software
Chequeo : Validación de la entidad origen.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
4. Verificar la fuente destino. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente origen
con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
5. Seleccionar la entidad fuente donde se cargará la información. Dependiendo de
la conexión directa o indirecta se accede a una tabla si se encuentra en una Base
de Datos o un archivo plano si la conexión es indirecta. La validación se realiza
dependiendo de la variable tiempo, si la entidad o archivo no coincide con la
variable, el proceso fallará.
Agente : Un programa de software.
Chequeo : Validación de la entidad destino con respecto a la variable tiempo.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
6. Establecer el proceso de Extracción, Transformación y Cargue. En este paso
se realiza la extracción de los atributos de la fuente original con la fuente destino,
si es necesario un proceso de transformación al nivel de columnas se realizará en
MISC-03-1-9
98
esta etapa. Se indica si es necesario porque puede darse el caso en que los
campos Origen y destino sean iguales y no halla necesidad de realizar alguna
conversión. Posteriormente a esto se realizará una correlación para realizar el
cargue en la entidad destino.
Agente : Un programa de software
Chequeo : Validación acerca del proceso ETL.
Estado : ETL Exitosa o ETL Fallida
Si Estado = ETL Exitosa se continua con el siguiente paso
Si Estado = ETL Fallida se informa y se detiene el proceso.
7. Validar la información cargada. En este paso se realiza la revisión previa de la
información cargada, se establecen una serie de chequeos al nivel de datos,
estructuras, formatos, en fin son unos pasos de chequeo
Agente : Un analista de la información.
Chequeo : Validación acerca del proceso ETL.
Estado : ETL Exitosa o ETL Fallida
Si Estado = ETL Exitosa se continua con el siguiente paso
Si Estado = ETL Fallida se informa y se detiene el proceso.
Figura No. 15 : Grafo de Flujo de Procesos para el Cargue Incremental de
Tablas de Hechos en un ODS.
Cargue Inicial - Grafos del Proceso de Transformación para Integración de Tablas
Cuando existe necesidad de integrar distintas tablas según un esquema global, la
información se cargará en tablas temporales que luego serán integradas dependiendo de
unas equivalencias definidas en el esquema global.
1. Escoger lafuente Origen
2. Seleccionarentidad origen a
cargar3. Verificar la fuente
destino
4 Seleccionar laentidad fuente donde
se cargará lainformación
6. Validarinformación cargada.
5. Establecer elproceso de ETL
MISC-03-1-9
99
Validar ExistenciaTablas
TemporalesConsistente ?
RevisiónEquivalencias con
los Metadatos
Proceso deTransformación
ReportarInconsistenacia
Consistente ?
ReportarInconsistenacia
Consistente ?
ReportarInconsistenacia
Insertar yActualizar
Registros enTabla
Figura No. 16 : Diagrama de Flujo de Procesos para la Integración de
Tablas sobre el Esquema Global.
Básicamente los pasos a seguir son los siguientes:
1. Escoger la fuente Origen. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente origen
con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
2. Validación de tablas temporales existentes. Se debe validar que todos los sitios
han cargado. Si no se han cargado completamente no se puede continuar, esto
porque no es consistente integrar una tabla con información de una fecha con otra
tabla que posee una fecha de extracción distinta. ¿Cuál es la causa de esto? Si
esto se hiciese de esta manera se estaría integrando y presentando información
no consistente al usuario.
Agente : Un programa de Software.
Chequeo : Validación de existencias de tablas temporales.
Estado : Tablas Existentes o Tablas No Existentes
Si Estado = Tablas Existentes se continua con el siguiente paso
Si Estado = Tablas No Existentes se informa y se detiene el proceso.
MISC-03-1-9
100
3. Verificar la fuente destino. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente origen
con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
4. Seleccionar la entidad fuente donde se cargará la información. Dependiendo de
la conexión directa o indirecta se accede a una tabla si se encuentra en una Base
de Datos o un archivo plano si la conexión es indirecta. La validación se realiza
dependiendo de la variable tiempo, si la entidad o archivo no coincide con la
variable, el proceso fallará.
Agente : Un programa de software.
Chequeo : Validación de la entidad destino con respecto a la variable tiempo.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
1. Revisión de equivalencias con los metadatos. Los datos de las tablas
temporales son chequeados en las tablas de equivalencias de los metadatos,
en estas tablas existirá la transformación y las expresiones que indiquen la
manera de realizar la integración.
Agente : Un programa de Software o Un analista de la información.
Chequeo : Validación de las equivalencias en los metadatos.
Estado : Tablas Existentes o Tablas No Existentes
Si Estado = Tablas Existentes se continua con el siguiente paso
Si Estado = Tablas No Existentes se informa y se detiene el proceso.
MISC-03-1-9
101
6. Proceso de transformación e integración. Según las equivalencias
encontradas y según los programas de ETL se realizan las operaciones que
permiten las conversiones e integración de tablas.
Agente : Un programa de Software.
Chequeo : Proceso de transformación efectuado.
Estado : Exitoso o No Exitoso.
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = No Exitoso se informa y se detiene el proceso.
7. Borrar los registros que posea la tabla destino. Se borran los registros mas no
la estructura de la entidad fuente donde se cargará la información. Esta tarea se
realiza porque es posible que se haya cargado previamente registros en estas
tablas, los cuales podrían ocasionar problemas al momento de la carga.
Agente : Un programa de software.
Chequeo : Que se borren los datos de la tabla destino si los hay.
Estado : Exitoso o No Exitoso
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = No exitoso se informa y se detiene el proceso.
8. Insertar o actualizar datos en la tabla destino. En esta etapa se realiza un
proceso de inserción de los registros en la tabla definitiva del esquema global.
Agente : Un programa de Software.
Chequeo : Proceso de transformación efectuado.
Estado : Exitoso o No Exitoso.
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = No Exitoso se informa y se detiene el proceso.
MISC-03-1-9
102
1. Escoger lafuente Origen
2. Validar tablastemporalesexistentes
3. Verificar la fuentedestino
4 Seleccionar laentidad fuente donde
se cargará lainformación
8. Insertar oactualizar datos enlas tabla destino.
6. Proceso detransformación e
integración
5. Revisarequivalencias con
los metadatos
7. Borrar losregistros que posea
la tabla destino
Figura No. 17 : Grafo de Flujo de Procesos para la Integración de
Tablas en el Cargue Inicial en un ODS.
Cargue Incremental - Grafos del Proceso de Transformación para Integración de Tablas
En proceso es similar al efectuado en el cargue inicial, básicamente los pasos a seguir
son los siguientes:
1. Escoger la fuente Origen. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente origen
con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
2. Validación de tablas temporales existentes. Se debe validar que todos los sitios
han cargado. Si no se han cargado completamente no se puede continuar, esto
porque no es consistente integrar una tabla con información de una fecha con otra
tabla que posee una fecha de extracción distinta. ¿Cuál es la causa de esto? Si
esto se hiciese de esta manera se estaría integrando y presentando información
no consistente al usuario.
Agente : Un programa de Software.
Chequeo : Validación de existencia de tablas temporales.
Estado : Tablas Existentes o Tablas No Existentes
Si Estado = Tablas Existentes se continua con el siguiente paso
Si Estado = Tablas No Existentes se informa y se detiene el proceso.
MISC-03-1-9
103
3. Verificar la fuente destino. Se determina la manera de realizar la conexión a
esta fuente, directa o indirecta. Se valida el tipo de conexión con la fuente origen
con el fin de que esta se encuentre activa.
Agente : Un programa de software
Chequeo : Validación de la conexión.
Estado : Exitoso o Fallida
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = Fallida se informa y se detiene el proceso.
4. Seleccionar la entidad fuente donde se cargará la información. Dependiendo de
la conexión directa o indirecta se accede a una tabla si se encuentra en una Base
de Datos o un archivo plano si la conexión es indirecta. La validación se realiza
dependiendo de la variable tiempo, si la entidad o archivo no coincide con la
variable, el proceso fallará.
Agente : Un programa de software.
Chequeo : Validación de la entidad destino con respecto a la variable tiempo.
Estado : Existente o No Existente
Si Estado = Existente se continua con el siguiente paso
Si Estado = No existente se informa y se detiene el proceso.
2. Revisión de equivalencias con los metadatos. Los datos de las tablas
temporales son chequeados en las tablas de equivalencias de los metadatos,
en estas tablas existirá la transformación y las expresiones que indiquen la
manera de realizar la integración.
Agente : Un programa de Software o Un analista de la información.
Chequeo : Validación de las equivalencias en los metadatos.
Estado : Tablas Existentes o Tablas No Existentes
Si Estado = Tablas Existentes se continua con el siguiente paso
Si Estado = Tablas No Existentes se informa y se detiene el proceso.
MISC-03-1-9
104
6. Proceso de transformación e integración. Según las equivalencias encontradas
y según los programas de ETL se realizan las operaciones que permiten las
conversiones e integración de tablas.
Agente : Un programa de Software.
Chequeo : Proceso de transformación efectuado.
Estado : Exitoso o No Exitoso.
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = No Exitoso se informa y se detiene el proceso.
7. Insertar o actualizar datos en la tabla destino. En esta etapa se realiza un
proceso de inserción de los registros en la tabla definitiva del esquema global.
Agente : Un programa de Software.
Chequeo : Proceso de transformación efectuado.
Estado : Exitoso o No Exitoso.
Si Estado = Exitoso se continua con el siguiente paso
Si Estado = No Exitoso se informa y se detiene el proceso.
1. Escoger lafuente Origen
2. Validar tablastemporalesexistentes
3. Verificar la fuentedestino
4 Seleccionar laentidad fuente donde
se cargará lainformación
7. Insertar oactualizar datos enlas tabla destino.
6. Proceso detransformación e
integración
5. Revisarequivalencias con
los metadatos
Figura No. 18 : Grafo de Flujo de Procesos para la Integración de
Tablas en el Cargue Incremental en un ODS.
Cada uno de estos grafos ayudarán a hacer el pseudo código que permitirá
posteriormente desarrollarlos en una herramienta de software.
Escogencia de la Plataforma de Desarrollo Para esta etapa es necesario reunirse con las personas encargadas del área de soporte
de los sistemas operacionales. Ellos podrán indicar con mayor exactitud cuales son las
plataformas mas adecuadas según los requerimientos. En esta etapa se determinan los
siguientes puntos:
MISC-03-1-9
105
• Escogencia de la Plataforma de SW y HW, esta selección debe estar alineada con
la plataforma de desarrollo de la cual disponga la empresa para trabajar.
• Tipo de Sistema Manejador de Base de Datos, se analiza las necesidades de la
organización
• El número de Procesadores con el cual debe disponer el servidor que soporte el
ODS
• Requerimientos de Espacio en Disco, este valor depende del volumen de datos a
cargar. Para este caso se pueden aplicar las formulas de espacio utilizadas en la
asignación de los espacios de trabajo.
• Número de usuarios, el número de usuarios es una cifra que deberá ser reportada
por el líder usuario.
• Tiempo de respuesta promedio por consulta, en consenso común se determina
este tiempo el cual permitirá medir periódicamente si el sistema se comporta
según las expectativas planteadas.
Dependiendo de las características del proyecto a realizar, se evalúan herramientas que
estén acordes a la problemática, así mismo se compara características de Robustez,
facilidad de uso y mantenimiento, costo y negociaciones de la empresa con algún
proveedor. Este ultimo punto es importante puesto que pueden evaluarse herramientas
que sean muy efectivas; pero que no sean posibles de implementar en la empresa puesto
que esta tiene una relación directa con un proveedor de la competencia.
Debido a que los grafos representan un proceso de Workflow es bueno buscar una
herramienta de SW que permita manejar esto. ¿Por qué? Porque cada una de las etapas
que se reflejan en los grafos debe ser controladas y si esto se hiciese con simple
codificación se está aumentando en la complejidad. La idea es facilitar el trabajo y no
hacerlo más complejo.
Documentación de la Fase de Diseño Toda esta etapa de Diseño se debe soportar por medio de la utilización de una serie de
formatos. Es bueno utilizar formatos que hagan de la etapa de levantamiento de
MISC-03-1-9
106
requerimientos una tarea formal, donde se identifiquen claramente las necesidades. Los
formatos definidos para esta etapa son los siguientes:
Formato Requerimiento Funcional (Anexo 1)
Modelo de Datos de las Fuentes (Anexo 2)
Diseño del Modelo de Datos del ODS (Anexo 3)
Definición de Transformaciones (Anexo 4)
Documento de Flujos de Trabajo (Anexo 6)
Validación de la Información Se debe establecer en esta etapa los puntos de chequeo y validaciones que se harán en
cada uno de los pasos desde la Extracción, Transformación y Cargue de información
desde las fuentes orígenes hasta el destino. Así mismo en las etapas anteriores y
posteriores al cargue se debe determinar los puntos de chequeo, estos chequeos se
pueden manejar de dos maneras por medio de tareas automáticas o mediante la
intervención de usuarios que harán una labor de aseguramiento de la información
cargada. Los puntos de chequeo se pueden controlar mediante la generación de Logs
que podrán ser guardados en tablas de la Base de Datos o en Archivos. Los chequeos o
validaciones de que los procesos se hayan ejecutado correctamente corresponden a
Operadores que podrán detectar si un proceso se ejecuta o no. Mientras que por el
contrario la validación de la información es una tarea de analistas, personas que poseen
un perfil más alto y un conocimiento más profundo de la información y de su utilidad.
Un Log de cada uno de los pasos del ETL debe poseer como mínimo la siguiente
información:
LOGS Campo Tipo Numero Proceso Un numero único Nombre del Proceso Nombre que describa el proceso, por ejemplo: Cargar_tabla_servicios Fecha de inicio Fecha (DD/MM/YYYY HH24:MI:SS)
MISC-03-1-9
107
Fecha de Fin Fecha (DD/MM/YYYY HH24:MI:SS) Estado Exitoso, Fallido, en ejecución Registros procesados Indica el número de registros procesados
Tabla No. 9. Tabla de Logs de los procesos en el ODS
Definición de los Metadatos Dentro de esta parte se define por parte del grupo que trabaja en el proyecto sobre que
plataforma estará soportada los Metadatos, cual es su tamaño, usuarios, perfiles. Se
determina la manera de realizar las actualizaciones, definiendo las personas encargadas
de la administración.
Para almacenar la información en la metadatos, se debe documentar por cada uno de los
atributos la siguiente información:
Nombre del Metadato Nombre del metadato.
Que representa Explicación de su necesidad en el modelo de datos del ODS.
Tipo de Dato Tipo Carácter, Tipo Numérico, ...
Nombre de Tabla Nombre de la tabla que almacenará al metadato
Por ejemplo:
CONVERSION Campo Tipo Nombre del metadato Conversión Que representa Es la representación de un campo como la integración de otros dos Campo Cod_servsupl = Tcos + Status
Tabla No. 10. Tabla de los metadatos en el ODS.
Definición de la Interfaz de Acceso al ODS y la Metadata (Herramientas de acceso de datos) Según las necesidades de los usuarios se define la manera en que será accedida la
información al ODS y los mismos Metadatos. Inicialmente es suficiente con la conexión
por medio de SQL. Se define una serie de pantallas que permitirán la comunicación
MISC-03-1-9
108
entre los usuarios y la Base de Datos. Estas interfaces son hechas en forma grafica y
presentadas a los usuarios con el fin de obtener por parte de ellos su aprobación.
Estas interfaces deberían ser documentadas en un formato de Diseño de la Interfaz para
acceso al ODS y a los Metadatos (Anexo 8)
Diseño del Modelo Físico del ODS En esta etapa se determina en forma detallada lo definido en el diseño el modelo de datos
del ODS, es decir todo aquello que tiene que ver con Espacio en la Base de Datos,
Tablas, Campos, Columnas, Índices, Número de usuarios, perfiles, entre otros. Se debe
desarrollar un Documento del Modelo Físico (Anexo 7) con características que permitirán
a un administrador realizar la creación de la Base de Datos en la etapa de Desarrollo.
8.2 DESARROLLO
Esta etapa consta de una serie de pasos que se realizan con el fin de implementar lo que
se definió en el diseño del ODS y de los Metadatos.
Implementación de la Base de Datos que soporta el ODS Dependiendo de lo definido en la etapa de Diseño se crea la Base de Datos que tendrá
todas las tablas del sistema. Así mismo se tiene en cuenta la integridad referencial entre
las tablas del modelo, se crean los sinónimos.
Se crean las tablas con sus campos
Se define la llave primaria de cada tabla
Se crea las llaves de integridad referencial
Se establecen los índices sobre las tablas
Se crean los sinónimos sobre las tablas
Se reserva el espacio de cada entidad en la BD
Se establece el protocolo de comunicación con la base de datos.
MISC-03-1-9
109
Implementación de las Metadatos Dependiendo de lo definido en la etapa de Diseño se crean los Metadatos
almacenándolos en un Repositorio, generalmente estos Metadatos son colocados en el
mismo lugar donde reside el ODS.
Se crea una estructura soporte el modelo Lógico y físico de las tablas que contendrán la
información correspondiente a los Metadatos. Se siguen prácticamente los mismos
pasos de la implementación de la BD del ODS es decir creación de tablas, llaves
primarias, llaves foráneas, índices, sinónimos.
Generación de los Programas ETL Basado en cada uno de los grafos de cargue descritos en la fase de diseño se van
transcribiendo en una herramienta ETL o Workflow que facilite la tarea del seguimiento y
monitoreo de la ejecución de cargue del sistema.
• Generar los programas de ETL ( Extracción Transformación y Carga) que se
pasan desde las fuentes de Origen al repositorio ODS.
• Desarrollo de la interfaz que permita revisar el comportamiento de los programas
ETL.
• Pruebas de cargue de la información
• Pruebas de generación de puntos de chequeos para tareas fallidas y exitosas.
Creación de la Interfaz Se desarrolla una interfaz que permita el acceso de los usuarios a la Metadata y al ODS.
Esta interfaz depende de la plataforma de trabajo que se disponga en la empresa. En
esta interfaz se debe permitir al usuario la consulta de la información con los parámetros
definidos en el ODS, es decir Tiempo de Cargue, Periodicidad entre otros valores. Se
deben realizar pruebas de conexiones desde la interfaz desarrollada al ODS. Consulta
de valores de los Metadatos.
MISC-03-1-9
110
8.3 APROBACION
Durante esta etapa se plantean una serie de actividades que permitirán realizar pruebas
con el fin de dar el visto bueno al desarrollo del ODS y ponerlo en marcha en producción
Pruebas de Cargue El proyecto y posteriormente cuando sea colocado en producción el Almacén de Datos
Operativos debe poseer un dueño no sólo al nivel tecnológico, sino al nivel de usuarios.
Si dentro de la organización existe una base de datos con ciertas características a un
ODS, pero no existe un líder usuario que se apropie de las necesidades del negocio y de
la utilidad de esta información, fácilmente este ODS puede llegar a un punto en que la
información se desactualice con respecto al negocio. Porque la empresa es cambiante y
las reglas del negocio pueden variar, lo cual origina desconfianza en la información
generada. Los usuarios son necesarios al momento del cargue de información inicial,
cargue incremental ya que ellos son los dueños de esta información. El área de IT es un
facilitador que ayudará en la tarea de colocar en este repositorio la información que deseé
el usuario.
En estas pruebas de cargue se generan vistas temporales o archivos planos que
contengan un 10% de la información de las tablas originales y con ellas se cargan los
registros en las tablas del ODS. Utilizando para ello los programas de ETL. En este
punto se valida inicialmente que los programas corran y que se carguen los registros al
ODS.
Documentación de Pruebas Para las pruebas es bueno establecer un proceso que establezca la serie de pasos
necesario para dar aprobación a los datos cargados. El formato de Chequeo de Pruebas
(Anexo9) debe ser generado al momento de la etapa de diseño. Existen dos tipos de
chequeo. Un Chequeo Técnico y un Chequeo Funcional. El chequeo técnico se encarga
de que los procesos de ETL se ejecuten en manera correcta y que en caso de falla sean
controlables y el chequeo a escala funcional es la validación de los usuarios con respecto
a los datos generados o cargados en el ODS.
MISC-03-1-9
111
Este análisis al nivel funcional también se establece al nivel de reportes o las consultas
solicitadas.
Aseguramiento de los Puntos de Chequeo Validar que en momentos de equivocaciones, problemas se disparen estas alarmas para
que sean tomadas por ciertos agentes con el fin de validar que en momentos de fallas
exista el control para poder detectarlos y poder tomar una decisión como es el caso de
reprocesos o cancelación en caso extremo.
Puesta en marcha La puesta en marcha se puede dar porque en las pruebas realizadas se cumplió con las
expectativas de la etapa de levantamiento de requerimientos. Esta etapa se divide en un
Cargue total de Tablas Maestras, Cargue inicial de tablas de modificaciones, cargue
incremental de tablas de modificaciones. Se debe hacer una tarea de seguimiento
posterior a la puesta en marcha puesto que pueden presentarse ciertos inconvenientes
que pueden ser ajustados en la marcha. Estos inconvenientes deben ser documentados,
arreglados y puesto en producción cuanto antes. Con el fin de evitar que queden en el
olvido y se desactualice toda la información en el ODS.
Reprocesos Debido a que en un ODS la información es cambiante y el negocio también es necesario
establecer una serie de pautas que ayudarán a la puesta en marcha de este Repositorio,
la información cambia y negocio también. Por lo tanto un ODS es dinámico siempre
existirán requerimientos para ser cargados o modificados en el ODS. Estas etapas
originan un ciclo hacia la fase Análisis y Diseño. Es necesario indicar aquí que si ya se ha
iniciado la fase de desarrollo o si ya se a adelantado en gran parte el Diseño y se desean
corrección a última Hora se debe establecer criterios conjuntos entre el área de IT y el
área usuaria para evitar caer en un Circulo de modificaciones permanentes a las
especificaciones. Se deben establecer criterios como por ejemplo un máximo de
reuniones para la definición de Requerimientos, si por algún motivo existe un
MISC-03-1-9
112
requerimiento que no fue informado a tiempo, este deberá ser trabajo en una etapa
posterior.
ANALISIS Y DISEÑO DESARROLLO APROBACIÓN ANALISIS Y DISEÑO
9 CASO DE ESTUDIO – INTEGRACION DE SERVICIOS EN UNA EMPRESA DE TELECOMUNICACIONES
De acuerdo a cada uno de los pasos descritos en la propuesta metodológica se realizará
un análisis de un caso de estudio, para la aplicación de la metodología descrita.
9.1 ANÁLISIS
Se refiere a la implementación de una solución para una empresa del sector de las
telecomunicaciones que tiene actualmente un requerimiento de visión integrada de la
información, así como la intención de satisfacer las necesidades de los usuarios para
obtener información oportuna.
Estado actual
Actualmente se ejerce un control muy fuerte sobre los accesos a las bases de datos
operativas. Dentro de una organización existen grupos de personas que se encargan de
velar por el desempeño de las bases de datos operativas. Sin embargo, este mismo
control de alguna manera va en contra de las necesidades del negocio de obtener
información al día.
MISC-03-1-9
113
Los usuarios acceden mediante algunos privilegios a los sistemas, algunos pueden
realizar consultas directas, con restricciones de tiempo. Después de un cierto tiempo de
inactividad, estos accesos son cortados. Incluso se habilitan conexiones a los sistemas
mediante dblinks, pero estos dblinks son restringidos por tiempo y son limitados para el
gran número de usuarios que existen en la compañía.
Muchas veces se ha visto afectado el desempeño de los sistemas porque un usuario
inexperto envía una consulta poco eficiente sobre una tabla muy transaccional, esto
ocasiona que procesos masivos se vean afectados en sus tiempos.
Áreas usuarias como por ejemplo Ventas, Servicio al Cliente y Facturación requieren
información cada cierto tiempo; para establecer políticas y determinar el comportamiento
de los productos lanzados recientemente al mercado.
Los requerimientos de los usuarios por información, se manejan de dos formas diferentes.
Una consulta Ad hoc que es solicitada al área de tecnología, la cual muchas veces por
falta de tiempo, esta información no puede ser entregada oportunamente al usuario.
Se crean consultas después de un cierto espacio de tiempo para implementarlas
mediante reportes o procedimientos almacenados que se ejecutan periódicamente y que
afectan directamente los sistemas en línea.
Estado nuevo
Para atacar el problema se parte de la premisa que las bases de datos pertenecen a un
dominio común de información, aunque sus SMBD sean distintas entre sí. ¿Qué debería
hacer la solución que desea implementarse?.
Básicamente debe definirse un esquema global que represente este dominio de
información. Esta definición es de común acuerdo entre los entes participantes. Este
esquema global deberá permanecer almacenado en un repositorio, y deberá ser
habilitado para su consulta. Los administradores de cada sistema local deben determinar
MISC-03-1-9
114
las relaciones entre el Esquema Global y los Esquemas Locales. Se debe establecer una
estrategia de transformación, los datos serán actualizados periódicamente sobre un
repositorio que se convertirá en el ODS de la Organización.
Los accesos a las bases de datos operativas son muy restringidos, este control se debe a
la necesidad de controlar el rendimiento de estas consultas que se realizan sobre las
tablas de las bases de datos operativas. Un grupo de personas revisa periódicamente el
desempeño de estos sistemas. Al definir un ODS estas personas encargadas del
monitoreo, están consistentes y seguros del volumen de información que se extraerá de
los sistemas en línea. Pueden establecer los horarios oportunos para realizar las
operaciones.
El número de usuarios que desea acceder a la información del ODS es relativamente
pequeño, se manejan en promedio de 50 a 60 usuarios con perfiles de consulta.
En el alcance de esta tesis se enfocará en el trabajo sobre bases de datos relaciónales.
Es necesario pues, determinar: Las entidades a las cuales se les hará seguimiento, el
proceso de transformación e Integración, las políticas de actualización de datos, la interfaz
grafica que permitirá al usuario ver al ODS de una manera integrada.
9.2 AMBIENTE DE IMPLEMENTACION Y RESTRICCIONES DEL PROTOTIPO
Se establecerá un prototipo que este enfocado al sector de las telecomunicaciones y en
especial dirigido hacia las Entidades y Servicios Suplementarios que se ofrecen a los
usuarios de una empresa en particular.
Se utilizará una Base de datos Oracle versión 8i.
Se crearán programas de ETL desarrollados como PL/SQLs en Oracle para cargar al
ODS la información de las bases de datos operativas.
Se utilizará como herramienta de WorkFlow el aplicativo Oracle Workflow. El cual
consta de los siguientes componentes:
MISC-03-1-9
115
WorkFlow Builder donde se crean los grafos de Flujos de procesos.
Workflow Server que es la máquina donde corren los paquetes y procedimientos
almacenados de los cuales consta el grafo.
Workflow Monitor que es la interfaz gráfica para gestión de procesos, la cual es
visualizada en un servidor que contenga la suite de aplicaciones Oracle
9iAplication Server.
Restricciones
Dentro de las restricciones establecidas para el prototipo a desarrollar están las
siguientes:
Se trabajará sólo con bases de datos relacionales.
En esta etapa no se trabajará sobre el aspecto relacionado a la optimización de las
consultas sobre el modelo del ODS. Se guardaran los metadatos en el mismo ODS.
Se utilizaran tablas de modificaciones en los sistemas orígenes para usarlas como
referencia en la captura de las modificaciones de los datos.
Para cargar la información en el ODS se validará la información de los archivos planos
generados en cada Base de Datos Transaccional.
El ODS sólo será enfocado a Consultas.
9.3 ETAPAS DE DESARROLLO
Basados en la propuesta metodológica se realizará cada uno de los pasos seguidos en
las tres grandes etapas: Análisis y Diseño, Desarrollo Y Aprobación.
En cada una de las etapas se documentará mediante los formatos propuestos en las
Sección de Anexos ( Anexo 1 – Anexo 9 ). Toda la documentación que soporta las
etapas de Implementación del ODS en el caso de estudio se encuentra descrita en los
anexos 10.1. al 10.9.
Los requerimientos funcionales apuntan hacia un tipo de ODS de Tipo II o Tipo III, ya que
las características implican que no se pueden realizar consultas directas a las bases de
MISC-03-1-9
116
datos de los sistemas operacionales. Un ODS Tipo I no podría ser implementado puesto
que el manejo de actualización mediante Triggers en las tablas transaccionales,
ocasionaría un impacto negativo en el Desempeño. Y esto de primera parte esta
descartado porque las bases de datos de los sistemas operacionales son muy
custodiadas.
Se descarta un tipo de ODS clase IV porque su fuente de alimentación no proviene de un
Datamart o un Datawarehouse. Además, se desea programar periódicamente esta
actualización del ODS, con el fin de tener actualizada la información. La mejor opción por
tanto es un ODS de Clase II. Debido a que los sistemas operacionales ( Sistema de
Facturación, Plataforma Mensajería – SMS y Plataforma de Buzones de Voz - Voice) son
muy restrictivos en cuanto a sus consultas. Se propone la generación de archivos
planos, con una nomenclatura propia que identifique el nombre de la tabla del cual
provienen. Estos archivos se cargarán a tablas temporales, sobre las que posteriormente
se realizarán procesos de integración y transformación para actualizar en forma
consistente el Modelo de Datos del ODS.
9.3.1 Escogencia de la Herramienta de Workflow
Se realizó un pequeño análisis entre dos herramientas de Workflow como son MS Sql
Server DTS y Oracle Workflow.
HERRAMIENTA MS SQL Server
Data Transformation Services Oracle Workflow
CARACTERISTICAS COM, Visual Basic
Desarrollo de procesos en java o Pl/sqls
VENTAJAS del motor de transformación
Visual Basic y C DTS ( Data Transformation Services )
• Workflow Builder constructor de procesos bajo ambiente Windows
• Workflow Monitor Interfaz para gestionar los procesos.
La base de datos es más robusta
DESVENTAJAS Transformaciones Simples. Es limitado
Solo con Oracle
Plataforma de Diseño
Win 2000 Server, WinNT Win95, Win98, Win 2000, WinNT
MISC-03-1-9
117
Tabla No. 11. Cuadro comparativo entre dos herramientas de Workflow.
Debido a consideraciones de desempeño y eficiencia se decidió utilizar Oracle Workflow.
Puesto que tiene todas las características para poder implementar correctamente grafos
de flujos de trabajo, con envío de notificaciones si así son solicitadas.
Los flujos de trabajo se desarrollaran en Workflow, cada una de las funciones se
realizaran como procedimientos almacenados los cuales devolverán valores
correspondientes a los resultados esperados por cada función. Es decir, estas funciones
permitirán encadenar los procedimientos y las precondiciones existentes entre uno y otro
proceso.
10 RESULTADOS ESPERADOS
Esta Tesis tiene un enfoque hacia el sector de las Telecomunicaciones, lo que se busca
es determinar una manera de obtener la información de diferentes fuentes de la manera
más transparente y adecuada utilizando para ello una implementación de un ODS -
Almacén de Datos Operacionales.
Definir una serie de programas de ETL (Extracción Transformación y Cargue) que
permitan obtener la información de las bases de datos operativas. En cuanto al SMBD se
utilizará Oracle. Como se va a permitir la consulta con múltiples fuentes de información
es necesario establecer un esquema global y un proceso de transformación de los datos
originales para que se vean de manera integrada en el ODS. Este diseño se
documentará en un Modelo de Datos del ODS.
Mediante una herramienta gráfica de gestión de procesos se podrá realizar el seguimiento
de cada uno de los procesos de ETL que permiten cargar la información desde diferentes
archivos planos integrándolos en un ODS:
MISC-03-1-9
118
El prototipo permitirá realizar consultas sobre una base de datos global mediante una
interfaz grafica. Para el usuario es transparente la distribución de los datos entre las
distintas bases de datos.
El objetivo principal con esta tesis es establecer un punto de referencia desde el cual se
puedan desarrollar una serie de etapas permitiendo un ambiente de consultas sobre
diversos sistemas de información que se encuentren dentro de un dominio común.
En etapas posteriores se podría abordar temas como la optimización de procesos de ETL,
minería de datos, entre otros.
MISC-03-1-9
119
CONCLUSIONES
En el problema de la falta de integración de bases de datos operativas y la necesidad que
surge de obtener información actualizada permanentemente, surgen distintas soluciones
basadas tanto en construcción de herramientas de software, así como también enfocadas
hacia un soporte de Sistemas Manejadores de Base de Datos.
El tipo de solución escogida debe acomodarse a diferentes características, costos,
mantenimiento, utilidad y facilidad de uso de los sistemas que se están tratando de
integrar. Es de notar que para cada una de estas soluciones existen ventajas y
desventajas que son necesarias evaluar al momento de tomar una decisión. Las
soluciones pueden ser tan complejas o sencillas como se quieran. Lo importante es
satisfacer la necesidad inicial de obtención de información integrada. El colocar la
información en un repositorio para que pueda ser accedida, viendo los datos de una
manera integrada y actualizada es la solución más razonable al problema planteado.
Las diferentes metodologías existentes están enfocadas en su mayoría a soportar la
implementación de Bodegas de Datos o Datamart. Dentro del marco teórica de esta tesis
se estudiaron tres metodologías, todos ellas con un trasfondo de Sistemas Manejadores
de Bases de Datos. Con la propuesta metodológica se plantea una alternativa de trabajo
que crea una llave estrecha entre el Diseño y el Desarrollo, esto sucede porque se
plantea que los ODS y en general cualquier repositorio puede ser trabajado mediante
sistemas Workflow, se establece de esta manera un control preciso sobre las tareas,
ejecutores, precondiciones, resultados que llevan a los procesos de ETL a implementar y
mantener la información actualizada. El aporte de esta propuesta metodológica es la
facilidad de la implementación de los grafos de flujos que permiten conocer de manera
precisa la información a cargar y que permiten a su vez a los usuarios mediante unas
estructuras sencillas conocer cuando esta actualizada la información.
La propuesta metodológica en si misma permite debido a sus características de enfoque
hacia diseño de procesos de ETL, soportar la implementación de otro tipo de Repositorios
como es el caso de Bodegas de Datos o en su defecto de Datamart. Esto sucede
simplemente porque estos dos sistemas al igual que un ODS, son Repositorios de
MISC-03-1-9
120
Información cada uno de ellos con un enfoque distinto de volumen de datos, periodicidad
e interfaces de acceso a los datos. Pero, todos ellos con un valor común, la información
que soporta a los usuarios permitiéndoles a sus negocios ser mas eficientes y
productivos.
MISC-03-1-9
121
TRABAJO FUTURO
En esta etapa se ha planteado un punto de partida sobre el cual se puede trabajar mas
adelante en propuestas de explotación del repositorio ODS mediante consulta de la
información almacenada. Entre los puntos que se podrían trabajar mas adelante están
los siguientes:
Implementación de otros modelos de diseño orientados a Almacenes de datos
operacionales.
Análisis de Sistemas de ODS de Clase I o Clase IV, ya que estos son más
complejos de Implementar, el primero por restricciones de desempeño y costos y
el último porque rara vez es extraída información de Datamart o DataWarehouse
para ser llevadas a un ODS.
Propuesta de trabajo en desarrollo de análisis OLAP y de Minería de datos sobre
el ODS.
Optimización de procesos Extracción, Transformación y Cargue de información en
el ODS, con un origen que sea tanto de los archivos planos como también tablas
temporales.
Mantenimiento de almacenes de datos operacionales. Realizar análisis sobre
desempeño de estos sistemas.
MISC-03-1-9
122
BIBLIOGRAFIA [Li1994] Lim, E., Hwang, S., Srivastava, J., Clements, D. y Ganesh, M. 1994. Myriad: design and implementation of a federated database prototype. Articulo 4-192 EE/CS. Department of Computer Science, University of Minnesota. [At1995] Attaluri, G. K., Bradshaw, D. P., Coburn, N., Larson, P. A., Martin, P., Silberschatz, A., Slonim, J. y Zhu, Q. 1995. The CORDS Multidatabase Project. IBM Toronto Laboratory y Natural Sciences and Engineering Research Council of Canada. [OV1991] Özsu, M. T. y Valduriez, P. 1991. Principles of Distributed Database Systems. Prentice-Hall, Englewood Cliffs, New Jersey. [Ah1991] Ahmed, R., Smedt, P., Du, W., Kent, W., Ketabchi, M. A., Litwin W. A., Raffi, A. y Shan, M. 1991. Using an Object Model in Pegausus to Integrate Heterogeneous Data. Database Technology Department. Hewlett-Packard Laboratories. Palo Alto, California. 1991 [CP1984] Ceri, S., Pelagatti, G. “Distribuited Databases Principles and Systems”, Mc GrawHill, 1984. [Da1993] Date, C. J., “Introducción a los Sistemas de Bases de Datos” Vol 1, sa ed. Addison-Wesley, 1993. Object-Oriented Aplication Analysis and Design for Java(TM) Technology (UML) OO-226. Student Guide Volume 1 y 2. Copyrigth 2001 Sun Microsystems, Inc. Enterprise Services. April 2001, Revision B.2. [Vo] Vogel, A. Building Enterprise Applications for the Net with EJB, CORBA, and XML. Inprise Corporation [Ga2001] García López, Isamary. Integración de bases de datos heterogéneas utilizando XML, Ontologías y Corba. Tesis (Magister en Ingeniería de Sistemas y Computación). Universidad de los Andes. 2001. [Ro1999] Romero Martínez, M. (1999). Lenguaje de Consultas para una Multibase de Datos. Tesis Maestría. Ciencias con Especialidad en Ingeniería en Sistemas Computacionales. Departamento de Ingeniería en Sistemas Computacionales, Escuela de Ingeniería, Universidad de las Américas-Puebla. Mayo 1999, Universidad de las Américas-Puebla. Recuperado el 20 de abril de 2002, del sitio Web de la Universidad de Puebla: http://mailweb.udlap.mx/~tesis/msp/romero_m_m/index.html
MISC-03-1-9
123
[In2nd] Inmon William. H. Building the Operational Data Store, 2nd Edition. Publicado en Mayo del 1999, 320 páginas. [Ki1998] Kimball, Ralph. 1998. The data warehouse lifecycle toolkit : expert methods for designing, developing, and deploying data warehouses. [Ki1996] Kimball, Ralph. 1996. The data warehouse toolkit : practical techniques for building dimensional data warehouses. [Le2002] Lewis, Philip, Bernstein, Arthur, Kifer, Michael. "Databases and Transaction Processing: An Application-Oriented Approach". Addison-Wesley, 2002 [B&D] B&D Business and Decision Recuperado el 23 de abril del 2003, de http://www.businessdecision.com/esp/Decouvrir/DataWarehouse.htm [Be] Berry, Michael, Linoff, Gordon. Mastering Data Mining – The Art and Science of Customer Relationship Management. [To2001] Todman, Chris. 2001. ”Designing a data Warehouse Supporting Customer Relationship Management”.
MISC-03-1-9
124
ANEXO 1. FORMATO PROPUESTO DE REQUERIMIENTO FUNCIONAL
ID del Documento : EF-001 Nombre del documento : Nombre del Proyecto : Áreas o Sistemas Afectados : Responsables : Nombres de los Responsables Prioridad x Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial Documento de Requerimientos
DOCUMENTO REQUERIMIENTOS FUNCIONALES Tabla de Contenido
1. Objetivo 2. Alcance 3. Necesidades 4. Áreas usuarias y repesentante 5. Glosario de Términos 6. Modelo Actual 7. Situación Actual 8. Modelo Propuesto 9. Situación Propuesta 10. Definición de Consultas
MISC-03-1-9
125
ANEXO 2
MODELO DE DATOS DE LAS FUENTES ID del Documento : MDFO-001 Nombre del documento : Nombre del Proyecto : Áreas o Sistemas Afectados : Responsables : Nombres de los responsables Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial del Modelo de Datos de las BDs Fuentes
MODELO DE DATOS DE LAS FUENTES Tabla de Contenido
1. Modelo de datos de las entidades originales
a. Sistema 1 b. Sistema 2 c. ... d. Sistema n
2. Listado y Descripción de las Entidades Originales
a. Sistema 1 i. Tabla 1 ii. ... iii. Tablan
b. Sistema 2 c. ... d. Sistema n
3. Notas Generales
MISC-03-1-9
126
ANEXO 3 MODELO DE DATOS DEL ODS
ID del Documento : MDODS-001 Nombre del documento : Nombre del Proyecto : Áreas o Sistemas Afectados : Responsables : Nombre de Líder de IT
Nombres de los Analistas de Información Nombres de los Ingenieros de IT
Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial del Modelo de Datos del ODS
MODELO DE DATOS DEL ODS Tabla de Contenido
1. Modelo de Dtaos propuesto para el ODS 2. Descripción del Modelo 3. Diseño del Modelo de Datos 4. Listado Y descripción de las entidades del Modelo de datos 5. Tabla 1
a. Descripción b. Fuente de Origen c. Proceso de Transformación d. Periodicidad de cargue e. Lista de Campos y llave primaria
6. Tabla 2 7. ... 8. Tabla n
MISC-03-1-9
127
ANEXO 4. DEFINICIÓN DE TRANSFORMACIONES
ID del Documento : DT-001 Nombre del documento : Nombre del Proyecto : Áreas o Sistemas Afectados : Responsables : Nombres de los Responsables Prioridad x Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial Definición de Transformaciones.
DEFINICIÓN DE TRANSFORMACIONES Tabla de Contenido
1. Objetivo 2. Paso Directo entre tablas
a. Sistema 1 i. Tabla 1 ii. Tabla 2 iii. ... iv. Tabla n
b. Sistema 2 c. ... d. Sistema n
3. Transformación entre entidades
a. Tabla 1 b. Tabla 2 c. ... d. Tabla n
MISC-03-1-9
128
ANEXO 5 DISEÑO DE LOS METADATOS DEL ODS
ID del Documento : DMDODS-001 Nombre del documento : Nombre del Proyecto : Áreas o Sistemas Afectados : Responsables : Nombres de los Responsables Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Diseño de Meta Datos del ODS
DISEÑO DE LOS METADATOS DEL ODS Tabla de Contenido
1. Modelo de datos propuesto para el ODS
a. Descripción del Modelo b. Diseño del modelo de datos
2. Listado y Descripción de las Entidades del Modelo de Datos a. Tabla 1
i. Descripción ii. Lista de campos y Llave Primaria
b. Tabla 2 c. .... d. Tabla n
MISC-03-1-9
129
ANEXO 6. FORMATO DOCUMENTO DE FLUJO DE TRABAJO
ID del Documento : FT-001 Nombre del documento : Especificación de Requerimientos Funcionales Agente : Quien lo ejecuta Prioridad Alta Media Baja Precondición:
Validación o Chequeo : Qué se valida para determinar la correcta terminación ? Grafo de Flujo de Datos Precede a :
Antecede a :
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
130
ANEXO 7 DISEÑO FÍSICO DEL ODS Y SUS METADATOS
ID del Documento : DF-001 Nombre del documento : Nombre del Proyecto : Áreas o Sistemas Afectados : Responsables : Nombres de los Responsables Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial del Diseño Físico del ODS
DISEÑO FÍSICO DEL ODS Y SUS METADATOS Tabla de Contenido
1. Arquitectura del Sistema 2. Descripción Global de la Arquitectura 3. Esquema de Trabajo 4. Listado de las Entidades del Modelo de Datos
a. Tablas Definitivas de los Metadatos i. Tabla 1 ii. ... iii. Tabla n
b. Tablas Definitivas del ODS i. Tabla 1 ii. ... iii. Tabla n
c. Tablas Temporales del ODS i. Tabla 1 ii. ... iii. Tabla n
5. Listado de paquetes Necesarios para el Cargue y Actualización de Información a. Listado de Paquetes b. Descripción Genérica c. Encabezado del Paquete d. Cuerpo del Paquete
6. Flujos de Trabajos a. Flujo de Cargue Inicial
i. Cargue inicial de tabla ii. División de una tabla según la condición de Filtro
b. Flujo de Trabajo de Actualización i. Proceso de Actualización
MISC-03-1-9
131
ANEXO 8. DISEÑO DE LA INTERFAZ PARA ACCESO AL ODS Y A LOS
METADATOS ID del Documento : DI-001 Nombre del documento : Nombre del Proyecto : Áreas o Sistemas Afectados : Responsables : Nombres de los Responsables Prioridad x Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial Diseño de la Interfaz para acceder al ODS y a los Metadatos
DISEÑO DE LA INTERFAZ PARA ACCESO AL ODS Y A LOS
METADATOS Tabla de Contenido
1. Objetivo 2. Pantallas Propuestas
a. Menú de Interface del ODS b. Parámetros de Configuración del ODS c. Consulta de la tabla de Logs d. Ejecución de Consultas al ODS e. Interfaz para ejecución de Procesos de cargues al ODS a través de Oracle
Workflow i. Pantalla para acceder al Workflow Monitor
f. Pantalla para buscar un proceso g. Pantalla para verificar la ejecución de un proceso en forma grafica
MISC-03-1-9
132
ANEXO 9. FORMATO CHEQUEO DE PRUEBAS
ID del Documento : CHKPR-001 Nombre del documento : Nombre del Proyecto : Áreas o Sistemas Afectados : Responsable : Nombres de los Responsables Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión inicial del Documento de Chequeo de Pruebas
FORMATO CHEQUEO DE PRUEBAS Tabla de Contenido
1. Datos Generales 2. Completitud De Entidades 3. Completitud De campos 4. Lista de Chequeo
a. Cargue de las tablas Maestras b. Actualización de las tablas c. Verificación de las Interfaces
MISC-03-1-9
133
ANEXO 10.1 FORMATO PROPUESTO DE REQUERIMIENTO FUNCIONAL
ID del Documento: EF-001 Nombre del documento: Especificación de Requerimientos Funcionales Nombre del Proyecto: Integración de los Servicios de Abonados Áreas o Sistemas Afectados: Servicio al Cliente y Ventas Responsables: Nombre del Patrocinador del proyecto
Nombre del Líder Usuario Nombre del Líder de IT Nombres de los Ingenieros de IT Nombres de los Analistas de Información
Prioridad x Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial Documento de Requerimientos
DOCUMENTO REQUERIMIENTOS FUNCIONALES
Tabla de Contenido Objetivo...............................................................................................................................................134
Alcance ...............................................................................................................................................134
Necesidades ......................................................................................................................................134
Áreas usuarias y Representante..................................................................................................134
Glosario de Términos .....................................................................................................................135
Modelo Actual ...................................................................................................................................135
Situación Actual...............................................................................................................................135
Modelo Propuesto............................................................................................................................135
Situación Propuesta........................................................................................................................136
Definición de Consultas.................................................................................................................136
MISC-03-1-9
134
Objetivo Tener una base de datos integrada de los diferentes bancos de información correspondientes a Servicios del abonado en un solo repositorio, permitiendo la consulta de la información al usuario final de una forma transparente.
Alcance El proyecto incluye bases de datos de tres sistemas: el sistema de Facturación, el Sistema de Servicios de VOICE y el sistema de Servicios de Mensajería. El Almacén de Datos Operacionales deberá poder ser consultado por usuarios de los tres sistemas.
Necesidades La mayoría de las organizaciones enfrentan un problema de integración de datos donde las aplicaciones requieren acceder a información almacenada en fuentes de datos variadas, posiblemente distribuidas sobre múltiples plataformas. Si se pueden agrupar de cierta manera las bases de datos de diferentes organizaciones ( tratando de integrar distintas empresas) o de distintos sistemas operacionales (al interior de una misma compañía) en un solo dominio, es posible atacar el problema de Interoperabilidad que poseen estas diferentes fuentes de almacenamiento, permitiendo que puedan ser accedidas. • Los datos no se encuentran integrados. Esto dificulta ver los sistemas como uno solo. Se
complica la tarea de realizar consultas sobre estos. • Toma de decisiones sin soporte. Muchas veces al no poder realizar consultas sobre los
sistemas se deben tomar decisiones con base en consultas sesgadas sobre un sistema de información y no viendo a la organización como un todo.
• La obtención de la información es demorada, ya que muchas veces los accesos a los sistemas en línea son restringidos.
• Existe dependencia por parte de los usuarios hacia el área de IT, ya que estos últimos son los que podrán informar cuando estas consultas se puedan realizar.
• La elaboración de consultas Ad Hoc, muchas veces va en contra de los procesos organizacionales en los cuales se busca que los requerimientos de los usuarios sigan un orden. El tiempo en que se solicita esta consulta y la respuesta que se envía al usuario puede variar entre 24 horas hasta mas de una semana.
• Muchas veces cuando la información es enviada ya no es actual o es irrelevante para los requerimientos de los usuarios.
• Se ejerce un control muy estricto sobre los accesos a las bases de datos operativas, este control surge por dos causas: seguridad y desempeño. Estos controles impiden al acceso permanente a la información.
Áreas usuarias y Representante El Almacén de Datos Operacionales, podrá ser consultado por usuarios de los tres sistemas integrados: el sistema de Facturación, el Sistema de Servicios de VOICE y el sistema de Servicios de Mensajería.
Dichos usuarios deben tener conocimientos de SQL, para formular en forma correcta las consultas del sistema.
Los usuarios corresponden a las áreas de Servicio al Cliente y Ventas.
MISC-03-1-9
135
Glosario de Términos ODS : Almacén de Datos Operacionales VOICE: Se refiere a los servicios correspondientes a Buzones de Voz.
Modelo Actual Actualmente se dispone de Tres bases de datos. La base de datos de Facturación se encarga de soportar todo lo referente al cobro de los servicios activados por los abonados en un determinado tiempo. Las otras dos bases Buzón de Voz (VOICE) y Mensajería (SMS) soportan tecnológicamente los servicios a los abonados. El primer sistema permite brindarle el servicio de Buzón de voz y el segundo de Mensajería permite soportar todo el envío de mensajes de texto.
Situación Actual Los tres sistemas y sus bases de datos que son lo más importante se encuentran separadas, esto significa que para los usuarios pueden realizar una conciliación entre los tres sistemas deben poder acceder a los tres sistemas, con el fin de poder extraer reportes y luego analizar los servicios que tiene contratado un abonado en los tres sistemas.
Modelo Propuesto Se desea unificar las tres bases de datos en un solo repositorio con el fin de que los usuarios solo tengan que acceder a una sola base de datos. La idea es refrescar a información en el repositorio cada 4 horas, que es el tiempo que se propone como adecuado para la actualización de los datos.
Facturación Voice Mensajería Buzón de Voz
Mensajería
MISC-03-1-9
136
S i s t e m a d e S e r v i c i o s S M S
S i s te m a d e S e r v i c i o s E L I T E
O D S
M D D a t a
E T L E x t r a c c ió n
T r a n s f o r m a c ió n In te g r a c ió n
E s q u e m a G l o b a l
S i s t e m a d e S e r v i c i o s V O I C E
Situación Propuesta Se propone unificar las tres bases de datos en una sola BD, con el fin de los usuarios deban acceder a uno solo sistema y sobre el cual puedan realizar sus consultas. Con ello se evita impactar las bases de datos operacionales.
Definición de Consultas A continuación se describen las consultas necesarias que deben poder ser satisfechas en el Repositorio. El sistema debe estar en capacidad de permitir a los usuarios realizar tales consultas. Nombre de Consulta CO-001 Justificación Se requiere para extraer los servicios activados por los
abonados en cierto momento del día Periodicidad Diaria Día de ejecución N/A Lista de campos Código del abonado, Código Servicio, Fecha Alta Campos de agrupamiento Fecha Alta Campos Sumables N/A Tipos de presentación Texto Parámetros de ejecución Fecha Alta Nombre de Consulta CO-002 Justificación Se requiere para extraer el numero de servicios cancelados
por los abonados en un rango de fechas Periodicidad A petición Día de ejecución N/A Lista de campos Fecha Cancelación, Código del Servicio Campos de agrupamiento Fecha Cancelación Campos Sumables Conteo de los distintos Código de Servicio Tipos de presentación Texto Parámetros de ejecución Fecha cancelación
MISC-03-1-9
137
ANEXO 10.2 MODELO DE DATOS DE LAS FUENTES
ID del Documento: MDFO-001 Nombre del documento: Modelo de Datos de las Fuentes Originales Nombre del Proyecto: Integración de los Servicios de Abonados Áreas o Sistemas Afectados: Servicio al Cliente y Ventas Responsables: Nombre de Líder de IT
Nombres de los Analistas de Información Nombres de los Ingenieros de IT
Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial del Modelo de Datos de las BDs Fuentes
MODELO DE DATOS DE LAS FUENTES Tabla de Contenido
Modelo de datos de las entidades originales...........................................................................138
Sistema de Facturación................................................................................................................138 Sistema de Servicios de VOICE .................................................................................................138 Sistema de Servicios de Mensajería..........................................................................................139
Listado y Descripción de las Entidades Originales................................................................139
Sistema de Facturación................................................................................................................139 Tabla Servsupl ..........................................................................................................................139 Tabla Planserv ..........................................................................................................................140 Tabla Plantarif ...........................................................................................................................140 Tabla Ptarif_pservicios.............................................................................................................140 Tabla Servsuplps ......................................................................................................................140 Tabla Abonado..........................................................................................................................141 Tabla Servsuplabo....................................................................................................................141
Sistema de Voice...........................................................................................................................142 Tabla Voice Mail .......................................................................................................................142
Sistema de Mensajería.................................................................................................................142 Tabla SMS .................................................................................................................................142
Notas generales................................................................................................................................142
MISC-03-1-9
138
Modelo de datos de las entidades originales Existen tres bases de datos pertenecientes a los tres sistemas descritos en la Especificación Funcional, estos se desean integrar en un solo repositorio. A continuación se describirá cada uno de estos modelos.
Sistema de Facturación El sistema de facturación contiene toda la información concerniente a los abonados (usuarios de la empresa). Estos a su vez tiene un plan tarifario (conjunto de características que asocia el cobro de las tarifas). El plan tarifario esta asociado a un plan de servicios (conjunto de servicios). Los planes tarifarios pueden tener uno o más planes de servicios lo cual permite el cambio de estos estando dentro del mismo patrón tarifario.
Sistema de Servicios de VOICE En esta plataforma se soporta todo el servicio de buzones de voz a los usuarios de la empresa de telefonía celular. Esta tabla contiene la información necesaria para determinar si un abonado posee un servicio de buzón de voz activo.
MISC-03-1-9
139
Sistema de Servicios de Mensajería En esta plataforma se implementa todo los servicios de mensajería a los usuarios. Esta tabla determina que tipo de servicio pose el suscriptor, esto se maneja mediante una combinación de las variables Status y Tcos.
Listado y Descripción de las Entidades Originales
Sistema de Facturación A continuación se describen las entidades que conforma el sistema de facturación y que son necesarias para realizar la replicación de la información en el otro Repositorio. Tabla Servsupl Esta tabla contiene los distintos servicios suplementarios que puede contratar un abonado. NOMBRE TIPO DESCRIPCION COD_SERVSUPL NOT NULL VARCHAR2(3) Código del servicio suplementario.
DES_SERVSUPL NOT NULL VARCHAR2(50) Corresponde al nombre del servicio suplementario.
COD_SERVICIO NOT NULL NUMBER(3) Código del servicio técnico COD_NIVEL NOT NULL NUMBER(4) Código del nivel de servicio
TIP_FACTURACION NOT NULL NUMBER(1) Indica el tipo de facturación que aplica sobre el servicio
FEC_INICIO NOT NULL DATE Fecha desde la cual aplica el servicio suplementario
FEC_FIN NOT NULL DATE
Fecha en la cual termina de aplicar el servicio suplementario para la venta.
MISC-03-1-9
140
Tabla Planserv
Esta tabla contiene los planes de servicios que asocia los diferentes servicios suplementarios. NOMBRE TIPO DESCRIPCION COD_PLANSERV NOT NULL VARCHAR2(8)Código del plan de servicios. COD_PRODUCTONOT NULL NUMBER(1) Indica el tipo de producto del plan de servicios
DES_PLANSERV NOT NULL VARCHAR2(50)
Nombre del plan de servicios
FEC_DESDE NOT NULL DATE Fecha desde la cual se puede vender el plan de servicios
FEC_HASTA NOT NULL DATE Fecha hasta la cual se puede vender el plan de servicios
Tabla Plantarif
Tabla que contiene los distintos planes tarifarios que contiene las tarifas para el cobro de los servicios del abonado. NOMBRE TIPO DESCRIPCION COD_PRODUCTO NOT NULL NUMBER(1) Código del producto COD_PLANTARIF NOT NULL VARCHAR2(8)Código del patrón tarifario DES_PLANTARIF NOT NULL VARCHAR2(3)Nombre del patrón tarifario
COD_CARGOBASICO NOT NULL VARCHAR(3) Código del cargo básico del patrón tarifario
FEC_DESDE NOT NULL DATE Fecha desde la cual se puede vender el patrón tarifario
FEC_HASTA NOT NULL DATE Fecha hasta la cual se puede vender el patrón tarifario
Tabla Ptarif_pservicios
Tabla que asocia los planes tarifarios con los planes de servicios. NOMBRE TIPO DESCRIPCION COD_PLANTARIF NOT NULL VARCHAR2(3) Código del Patrón Tarifario COD_PLANSERV NOT NULL VARCHAR2(3) Código del Patrón de Servicios
Tabla Servsuplps
Tabla que asocia los servicios suplementarios con los patrones de servicios. NOMBRE TIPO DESCRIPCION COD_PLANSERV NOT NULL VARCHAR2(3) Código del Patrón de Servicios COD_SERVSUPL NOT NULL VARCHAR2(3) Código del servicio suplementario
MISC-03-1-9
141
Tabla Abonado
Tabla que contiene los abonados o suscriptores que posee la empresa
NOMBRE TIPO DESCRIPCION COD_ABONADO NOT NULL NUMBER(8) Codigo abonado COD_CLIENTE NOT NULL NUMBER(8) Codigo abonado FEC_ALTA NOT NULL DATE Fecha de Alta FEC_ALTACEN DATE Fecha de alta en central COD_CENTRAL NOT NULL NUMBER(3) Código de la central en que se crea NUM_NPA NOT NULL NUMBER(3) Numero de NPA NUM_CELULAR NOT NULL NUMBER(7) Numero celular FEC_BAJA DATE Fecha de Baja FEC_BAJACEN DATE Fecha de Baja en central NSR_ELECTRONICO VARCHAR2(14) Numero seria electrónico NSR_HEXADECIMAL VARCHAR2(8) Numero serial hexadecimal COD_PLANTARIF NOT NULL VARCHAR2(3) Código del plan tarifario COD_SITUACION NOT NULL VARCHAR2(3) Código de situación COD_ESTCOBROS VARCHAR2(2) Código de estado en cobros COD_PLANSERV NOT NULL VARCHAR2(3) Código plan de servicios COD_ARTICULO NOT NULL NUMBER(6) Código artículo Tabla Servsuplabo
Tabla que indica los servicios que ha tenido un abonado durante cierto tiempo, indica tanto los activos como los cancelados. NOMBRE TIPO DESCRIPCION COD_ABONADO NOT NULL VARCHAR2(8) Código del abonado COD_SERVSUPL NOT NULL VARCHAR2(3) Código del servicio suplementario,
corresponde con la matricula de activos FEC_ALTABD NOT NULL DATE Fecha alta BD del servicio COD_SERVICIO NOT NULL NUMBER(3) Código del servicio COD_NIVEL NOT NULL NUMBER(4) Código del nivel de servicio NUM_TERMINAL NOT NULL NUMBER(10) Numero del Celular con NPA NOM_USUARORA NOT NULL VARCHAR2(30) Nombre del usuario que activo el servicio IND_ESTADO NOT NULL NUMBER(1) Indicador de estado del servicio FEC_ALTACEN DATE Fecha de alta del servicio en central FEC_BAJABD DATE Fecha de baja del servicio en Base de datos FEC_BAJACEN DATE Fecha de baja del servicio en central COD_PLANSERV NOT NULL VARCHAR2(3) Código del plan de servicios
MISC-03-1-9
142
Sistema de Voice Se explicará a continuación la estructura del sistema de buzones de voz. Tabla Voice Mail La tabla de Voice indica si un numero celular en particular tiene activado los servicios de buzón de voz y en que central se encuentra.
CAMPO TIPO DESCRIPCION NUM_CELULAR NOT NULL NUMBER(7) Número celular NPA_CELULAR NOT NULL VARCHAR(10) Número celular + 315
CENTRAL NOT NULL VARCHAR2 (3)
Central o Switch donde se encuentra activo el servicio de buzón de voz
Sistema de Mensajería A continuación se explicará la tabla de Mensajería.
Tabla SMS Esta tabla contiene los Número Celulares que tiene activados los servicios de mensajería y que tipo de servicio contienen. CAMPO TIPO DESCRIPCION
NPAMIN NOT NULL VARCHAR(10) Numero npa + número celular NPA NOT NULL VARCHAR(3) Número npa CELULAR NOT NULL NUMBER(7) Número celular STATUS NOT NULL NUMBER(1) Status TCOS NOT NULL NUMBER(2) Nivel de servicio ORIGEN NOT NULL VARCHAR2(30) Dirección
Notas generales Los tres sistemas corresponden a bases de datos relacionales, los tres sistemas deben estar consistentes puesto que de esto depende el buen nivel de soporte que sé sobre los usuarios de los sistemas. Los sistemas tienen restricciones de acceso para conexiones de usuario final.
MISC-03-1-9
143
ANEXO 10.3
MODELO DE DATOS DEL ODS ID del Documento: MDODS-001 Nombre del documento: Modelo de Datos del ODS Nombre del Proyecto: Integración de los Servicios de Abonados Áreas o Sistemas Afectados: Servicio al Cliente y Ventas Responsables: Nombre de Líder de IT
Nombres de los Analistas de Información Nombres de los Ingenieros de IT
Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial del Modelo de Datos del ODS
MODELO DE DATOS DEL ODS Tabla de Contenido
Modelo de datos propuesto para el ODS...................................................................................145
Descripción del Modelo ................................................................................................................145 Diseño del modelo de datos ........................................................................................................145
Listado y Descripción de las Entidades del Modelo de Datos ............................................146
Tabla ODS_Servsupl ....................................................................................................................146 Descripción................................................................................................................................146 Fuente de Origen......................................................................................................................146 Proceso de Transformación....................................................................................................146 Periodicidad de cargue............................................................................................................146 Lista de campos y Llave Primaria ..........................................................................................146
Tabla ODS_Planserv ....................................................................................................................146 Descripción................................................................................................................................146 Fuente de Origen......................................................................................................................146 Proceso de Transformación....................................................................................................147 Periodicidad de cargue............................................................................................................147 Lista de campos y Llave Primaria ..........................................................................................147
Tabla ODS_Plantarif .....................................................................................................................147 Descripción................................................................................................................................147 Fuente de Origen......................................................................................................................147 Proceso de Transformación....................................................................................................147 Periodicidad de cargue............................................................................................................147 Lista de campos y Llave Primaria ..........................................................................................147
Tabla ODS_Ptarif_pservicios ......................................................................................................148
MISC-03-1-9
144
Descripción................................................................................................................................148 Fuente de Origen......................................................................................................................148 Proceso de Transformación....................................................................................................148 Periodicidad de cargue............................................................................................................148 Lista de campos y Llave Primaria ..........................................................................................148
Tabla ODS_Servsuplps ................................................................................................................148 Descripción................................................................................................................................148 Fuente de Origen......................................................................................................................148 Proceso de Transformación....................................................................................................149 Periodicidad de cargue............................................................................................................149 Lista de campos y Llave Primaria ..........................................................................................149
Tabla Abonado...............................................................................................................................149 Descripción................................................................................................................................149 Fuente de Origen......................................................................................................................149 Proceso de Transformación....................................................................................................149 Periodicidad de cargue............................................................................................................149 Lista de campos y Llave Primaria ..........................................................................................149
Tabla ODS_Temp_serv................................................................................................................150 Descripción................................................................................................................................150 Fuente de Origen......................................................................................................................150 Proceso de Transformación....................................................................................................150 Periodicidad de cargue............................................................................................................150 Lista de campos y Llave Primaria ..........................................................................................150
Tabla ODS_Temp_voice..............................................................................................................151 Descripción................................................................................................................................151 Fuente de Origen......................................................................................................................151 Proceso de Transformación....................................................................................................151 Periodicidad de cargue............................................................................................................151 Lista de campos y Llave Primaria ..........................................................................................151
Tabla ODS_Temp_sms ................................................................................................................151 Descripción................................................................................................................................151 Fuente de Origen......................................................................................................................151 Proceso de Transformación....................................................................................................151 Periodicidad de cargue............................................................................................................152 Lista de campos y Llave Primaria ..........................................................................................152
Tabla ODS_Servicios_abo...........................................................................................................152 Descripción................................................................................................................................152 Fuente de Origen......................................................................................................................152 Proceso de Transformación....................................................................................................152 Periodicidad de cargue............................................................................................................152 Lista de campos y Llave Primaria ..........................................................................................152
Tabla ODS_Conversión_sms ......................................................................................................153 Descripción................................................................................................................................153 Fuente de Origen......................................................................................................................153 Proceso de Transformación....................................................................................................153 Periodicidad de cargue............................................................................................................153 Lista de campos y Llave Primaria ..........................................................................................153
MISC-03-1-9
145
Modelo de datos propuesto para el ODS
Descripción del Modelo El modelo se integrará en tablas que pertenecen al modelo de datos propuesto a continuación. Se utilizará como prefijo de las tablas el nombre ODS_, esto con el fin de identificar mas fácilmente las tablas pertenecientes al modelo. Cada una de las tablas de las fuentes originales fueron migradas hacia la nueva base de datos y tienen una nombre similar al original. Por ejemplo la tabla Abonado que pertenece originalmente al Sistema de Facturación se cargará al ODS con el nombre de Ods_Abonado.
Diseño del modelo de datos El sistema de facturación contiene toda la información concerniente a los abonados o suscriptores (Ods_abonado). Estos a su vez tiene un plan tarifario (Ods_Plantarif). El plan tarifario esta asociado a un plan de servicios (Ods_Planserv). Los planes tarifarios pueden tener uno o mas planes de servicios lo cual permite el cambio de estos estando dentro del mismo patrón tarifario, estos se representan en la relación Ods_ptarif_pservicios. Las tablas que contienen originalmente la información de los servicios (por ejemplo Sms_producción, Voice_mail, Servsuplabo) son cargadas a tablas temporales (Ods_Temp_sms, Ods_Temp_voice y Ods_Temp_serv) y posteriormente son integradas después de un proceso de Transformación en la tabla ods_servicios_abo. Esta ultima contiene toda la información consistente de servicios entre las tres bases de datos originales.
MISC-03-1-9
146
Listado y Descripción de las Entidades del Modelo de Datos A continuación se describen las entidades que conforma el modelo de datos propuesto pare el sistema integrado del ODS.
Tabla ODS_Servsupl Descripción
Esta tabla contiene los distintos servicios suplementarios que puede contratar un abonado.
Fuente de Origen
Sistema de Facturación. Tabla Origen: Servsupl
Proceso de Transformación
Se realiza una copia de los campos entre la tabla Servsupl y la tabla Ods_servsupl. Quitando el campo Tip_facturación ya que no se considera importante en el nuevo modelo.
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla es el campo Cod_servsupl. NOMBRE TIPO DESCRIPCION COD_SERVSUPL NOT NULL VARCHAR2(3) Código del servicio suplementario.
DES_SERVSUPL NOT NULL VARCHAR2(50) Corresponde al nombre del servicio Suplementario.
COD_SERVICIO NOT NULL NUMBER(3) Código del servicio técnico COD_NIVEL NOT NULL NUMBER(4) Código del nivel de servicio
FEC_INICIO NOT NULL DATE Fecha desde la cual aplica el servicio suplementario
FEC_FIN NOT NULL DATE
Fecha en la cual termina de aplicar el servicio suplementario para la venta.
Tabla ODS_Planserv Descripción
Esta tabla contiene los planes de servicios que asocia los diferentes servicios suplementarios.
Fuente de Origen
Sistema de Facturación. Tabla Origen: Planserv
MISC-03-1-9
147
Proceso de Transformación
Se realiza una copia de los campos entre la tabla Planserv y la tabla Ods_planserv. Quitando el campo Cod_producto ya que no se considera importante en el nuevo modelo.
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla es el campo Cod_planserv. NOMBRE TIPO DESCRIPCION COD_PLANSERV NOT NULL VARCHAR2(8)Código del plan de servicios. DES_PLANSERV NOT NULL
VARCHAR2(50) Nombre del plan de servicios
FEC_DESDE NOT NULL DATE Fecha desde la cual se puede vender el plan de servicios
FEC_HASTA NOT NULL DATE Fecha hasta la cual se puede vender el plan de servicios
Tabla ODS_Plantarif
Descripción
Tabla que contiene los distintos planes tarifarios que contiene las tarifas para el cobro de los servicios del abonado.
Fuente de Origen
Sistema de Facturación. Tabla Origen: Plantarif
Proceso de Transformación
Se realiza una copia de los campos entre la tabla Plantarif y la tabla Ods_plantarif. Quitando el campo Cod_producto ya que no se considera importante en el nuevo modelo de Datos.
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla es el campo Cod_plantarif.
MISC-03-1-9
148
NOMBRE TIPO DESCRIPCION COD_PLANTARIF NOT NULL VARCHAR2(8)Código del patrón tarifario DES_PLANTARIF NOT NULL VARCHAR2(3)Nombre del patrón tarifario
COD_CARGOBASICO NOT NULL VARCHAR(3) Código del cargo básico del patrón tarifario
FEC_DESDE NOT NULL DATE Fecha desde la cual se puede vender el patrón tarifario
FEC_HASTA NOT NULL DATE Fecha hasta la cual se puede vender el patrón tarifario
Tabla ODS_Ptarif_pservicios Descripción
Tabla que asocia los planes tarifarios con los planes de servicios.
Fuente de Origen
Sistema de Facturación. Tabla Origen: Ptarif_pservicios
Proceso de Transformación
Se realiza una copia de los campos entre la tabla Ptarif_pservicios y la tabla Ods_ptarif_pservicios.
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen los campos Cod_plantarif y Cod_planserv. NOMBRE TIPO DESCRIPCION COD_PLANTARIF NOT NULL VARCHAR2(3) Código del Patrón Tarifario COD_PLANSERV NOT NULL VARCHAR2(3) Código del Patrón de Servicios
Tabla ODS_Servsuplps
Descripción Tabla que asocia los servicios suplementarios con los patrones de servicios.
Fuente de Origen
Sistema de Facturación. Tabla Origen: Servsuplps
MISC-03-1-9
149
Proceso de Transformación
Se realiza una copia de los campos entre la tabla Servsuplps y la tabla Ods_servsuplps.
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen los campos Cod_planserv y Cod_servsupl. NOMBRE TIPO DESCRIPCION COD_PLANSERV NOT NULL VARCHAR2(3) Código del Patrón de Servicios COD_SERVSUPL NOT NULL VARCHAR2(3) Código del servicio suplementario
Tabla ODS_Abonado
Descripción
Tabla que contiene los abonados o suscriptores que posee la empresa
Fuente de Origen
Sistema de Facturación. Tabla Origen: Abonado
Proceso de Transformación Se realiza una copia de los campos entre la tabla Abonado y la tabla Ods_abonado. Eliminado los siguientes campos ya que no se consideran necesarios para el nuevo modelo de datos:
Fec_altacen Cod_central Fec_bajacen Nsr_electronico Nsr_hexadecimal Cod_estcobros Cod_articulo
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la compone el campo Cod_abonado.
MISC-03-1-9
150
NOMBRE TIPO DESCRIPCION COD_ABONADO NOT NULL NUMBER(8) Código abonado COD_CLIENTE NOT NULL NUMBER(8) Código abonado FEC_ALTA NOT NULL DATE Fecha de Alta NUM_NPA NOT NULL NUMBER(3) Numero de NPA NUM_CELULAR NOT NULL NUMBER(7) Numero celular FEC_BAJA DATE Fecha de Baja COD_PLANTARIF NOT NULL VARCHAR2(3) Código del plan tarifario COD_SITUACION NOT NULL VARCHAR2(3) Código de situación COD_PLANSERV NOT NULL VARCHAR2(3) Código plan de servicios
Tabla ODS_Temp_serv
Descripción
Tabla que indica los servicios que ha tenido un abonado durante cierto tiempo, indica tanto los activos como los cancelados. Esta tabla es temporal y solo contiene la Información correspondiente al sistema de Facturación.
Fuente de Origen Sistema de Facturación. Tabla Origen: Servsuplabo
Proceso de Transformación
Se realiza una copia de los campos entre la tabla Servsuplabo y la tabla Ods_Temp._serv. Eliminado los siguientes campos ya que no se consideran necesarios para el nuevo modelo de datos:
Nom_usuarora Fec_altacen Fec_bajacen
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen los campos Cod_abonado, Cod_servsupl, Fec_altabd. NOMBRE TIPO DESCRIPCION COD_ABONADO NOT NULL VARCHAR2(8) Código del abonado COD_SERVSUPL NOT NULL VARCHAR2(3) Código del servicio suplementario,
corresponde con la matricula de activos FEC_ALTABD NOT NULL DATE Fecha alta BD del servicio COD_SERVICIO NOT NULL NUMBER(3) Código del servicio COD_NIVEL NOT NULL NUMBER(4) Código del nivel de servicio NUM_TERMINAL NOT NULL NUMBER(10) Numero del Celular con NPA IND_ESTADO NOT NULL NUMBER(1) Indicador de estado del servicio FEC_BAJABD DATE Fecha de baja del servicio en Base de datos COD_PLANSERV NOT NULL VARCHAR2(3) Código del plan de servicios
MISC-03-1-9
151
Tabla ODS_Temp_voice Descripción La tabla de Ods_Temp_Voice indica si un numero celular en particular tiene activado los servicios de buzón de voz y en que central se encuentra. Esta tabla es temporal y solo contiene información de la plataforma de Buzones de Voz. Fuente de Origen Sistema de Voice Mail. La tabla Origen: Voice_mail
Proceso de Transformación
Se realiza una copia de los campos entre la tabla Voice_mail y la tabla Ods_Temp_voice.
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Num_celular.
CAMPO TIPO DESCRIPCION NUM_CELULAR NOT NULL NUMBER(7) Número celular NPA_CELULAR NOT NULL VARCHAR(10) Número celular + 315
CENTRAL
NOT NULL VARCHAR2 (3)
Central o Switch donde se encuentra activo el servicio de buzón de voz
Tabla ODS_Temp_sms Descripción
Esta tabla contiene los Número Celulares que tiene activados los servicios de mensajería y que tipo de servicio contienen.
Fuente de Origen Sistema de mensajería. Tabla Origen: Sms_produccion
Proceso de Transformación
Se realiza una copia de los campos de la tabla origen a la tabla destino. Cambiando los nombres de los siguientes campos. Sms_producción.Npamin Ods_Temp_sms.Npa_celular Sms_producción.Celular Ods_Temp_sms.Num_celular
MISC-03-1-9
152
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Npa_celular.
CAMPO TIPO DESCRIPCION NPA_CELULAR NOT NULL VARCHAR(10) Numero npa + número celular NPA NOT NULL VARCHAR(3) Número npa NUM_CELULARNOT NULL NUMBER(7) Número celular STATUS NOT NULL NUMBER(1) Status TCOS NOT NULL NUMBER(2) Nivel de servicio ORIGEN NOT NULL VARCHAR2(30)Dirección
Tabla ODS_Servicios_abo Descripción Tabla que indica los servicios que ha tenido un abonado durante cierto tiempo, indica tanto los activos como los cancelados. Integra completamente los servicios tanto activados en el Sistema de facturación como en los Otros dos sistemas, es decir Mensajería - Sms y Voice.
Fuente de Origen
Esta integrada por una serie de Tablas Temporales. Las cuales tienen su origen en las tablas Ods_temp_serv, Ods_Temp_sms y Ods_Temp_voice
Proceso de Transformación
Se realiza un proceso de Unión entre tres tablas temporales que contiene la información de los Servicios de los Sistemas de facturación, el Sistema de Mensajeria (Sms) y el servicio de Buzones de Voz (Voice).
Periodicidad de cargue
Se propone una periodicidad de cargue de 4 horas.
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Npa_celular.
MISC-03-1-9
153
NOMBRE TIPO DESCRIPCION COD_ABONADO NOT NULL VARCHAR2(8) Código del abonado COD_SERVSUPL NOT NULL VARCHAR2(3) Código del servicio suplementario,
corresponde con la matricula de activos FEC_ALTABD NOT NULL DATE Fecha alta BD del servicio COD_SERVICIO NOT NULL NUMBER(3) Código del servicio COD_NIVEL NOT NULL NUMBER(4) Código del nivel de servicio NUM_TERMINAL NOT NULL NUMBER(10) Numero del Celular con NPA IND_ESTADO NOT NULL NUMBER(1) Indicador de estado del servicio FEC_BAJABD DATE Fecha de baja del servicio en Base de datos COD_PLANSERV NOT NULL VARCHAR2(3) Código del plan de servicios
Tabla ODS_Conversión_sms Descripción
Tabla propia del Modelo ODS. Sirve para la conversión del servicio Sms en un servicio suplementario. Es decir permite definir los servicios de la tabla Sms_producción en términos de la tabla Sevsupl. Fuente de Origen
Esta información es propia del ODS y permite realizar un correcto mapeo de la tabla Sms_producción en la tabla Servsupl. Proceso de Transformación
N/A Periodicidad de cargue
N/A. Es una inserción propia del Sistema del ODS. Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Servsupl. NOMBRE TIPO DESCRIPCION COD_SERVSUPL NOT NULL VARCHAR2(3) Código del servicio suplementario,
corresponde con la matricula de activos STATUS NOT NULL NUMBER(1) Status TCOS NOT NULL NUMBER(2) Nivel de servicio
MISC-03-1-9
154
ANEXO 10.4 DEFINICIÓN DE TRANSFORMACIONES
ID del Documento: DT-001 Nombre del documento: Definición de Transformaciones Nombre del Proyecto: Integración de los Servicios de Abonados Áreas o Sistemas Afectados: Servicio al Cliente y Ventas Responsables: Nombre del Líder Usuario
Nombre del Líder de IT Nombres de los Ingenieros de IT Nombres de los Analistas de Información
Prioridad x Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial Definición de Transformaciones.
DEFINICIÓN DE TRANSFORMACIONES
Tabla de Contenido Objetivo...............................................................................................................................................155
Paso Directo entre Tablas .............................................................................................................155
Sistema de Facturación................................................................................................................155 Tabla Servsupl ..........................................................................................................................155 Tabla Planserv ..........................................................................................................................155 Tabla Plantarif ...........................................................................................................................155 Tabla Ptarif_pservicios.............................................................................................................156 Tabla Servsuplps ......................................................................................................................156 Tabla abonado ..........................................................................................................................156 Tabla servsuplabo ....................................................................................................................157
Sistema de Voice...........................................................................................................................157 Tabla Voice_mail ......................................................................................................................157
Sistema de Mensajería.................................................................................................................157 Tabla Sms_produccion............................................................................................................157
Transformaciones entre Entidades.............................................................................................158
Tabla ODS_Temp_abo_con_sms ..............................................................................................158 Tabla ODS_Temp_abo_con_voice ............................................................................................158 División tabla ODS_Temp_serv..................................................................................................158 Tabla ODS_temp_serv_abo_sms...............................................................................................160 Tabla ODS_temp_serv_abo_voice.............................................................................................160 Tabla ODS_servicios_abo ...........................................................................................................160
MISC-03-1-9
155
Objetivo En el presente documento se describen todas aquellas transformaciones que ocurren tanto al nivel de columnas como las Operaciones de Intersección, Unión entre cada una de las Entidades cargadas en el ODS. La idea con ello es facilitar la tarea de desarrollo.
Paso Directo entre Tablas A continuación se establecen las pantallas para acceder a la información del ODS.
Sistema de Facturación
Tabla Servsupl
Tabla Origen Abonado
Campo Origen
Tabla Destino Ods_abonado
Campo Destino T ipo de Transformación de Columna
COD_SERVSUPL COD_SERVSUPL Copiar DES_SERVSUPL N/A Descartar COD_SERVICIO COD_SERVICIO Copiar COD_NIVEL COD_NIVEL Copiar TIP_FACTURACION N/A Descartar FEC_INICIO FEC_INICIO Copiar FEC_FIN FEC_FIN Copiar
Tabla Planserv
Tabla Origen Abonado
Campo Origen
Tabla Destino Ods_abonado
Campo Destino T ipo de Transformación de Columna
COD_PLANSERV COD_PLANSERV Copiar COD_PRODUCTO N/A Descartar
DES_PLANSERV DES_PLANSERV Copiar
FEC_DESDE FEC_DESDE Copiar FEC_HASTA FEC_HASTA Copiar Tabla Plantarif
Tabla Origen Abonado
Campo Origen
Tabla Destino Ods_abonado
Campo Destino T ipo de Transformación de Columna
COD_PRODUCTO N/A Descartar COD_PLANTARIF COD_PLANTARIF Copiar DES_PLANTARIF DES_PLANTARIF Copiar COD_CARGOBASICO N/A Descartar FEC_DESDE FEC_DESDE Copiar FEC_HASTA FEC_HASTA Copiar
MISC-03-1-9
156
Tabla Ptarif_pservicios
Tabla Origen
Abonado
Campo Origen
Tabla Destino Ods_abonado
Campo Destino Tipo de Transformación de Columna
COD_PLANTARIF COD_PLANTARIF Copiar COD_PLANSERV COD_PLANSERV Copiar
Tabla Servsuplps
Tabla Origen
Abonado
Campo Origen
Tabla Destino Ods_abonado
Campo Destino Tipo de Transformación de Columna
COD_PLANSERV COD_PLANSERV Copiar COD_SERVSUPL COD_SERVSUPL Copiar
Tabla abonado
Tabla Origen
Abonado
Campo Origen
Tabla Destino Ods_abonado
Campo Destino Tipo de Transformación de Columna
COD_ABONADO COD_ABONADO Copiar COD_CLIENTE COD_CLIENTE Copiar FEC_ALTA FEC_ALTA Copiar FEC_ALTACEN N/A Descartar COD_CENTRAL N/A Descartar NUM_NPA NUM_NPA Copiar NUM_CELULAR NUM_CELULAR Copiar FEC_BAJA FEC_BAJA Copiar FEC_BAJACEN N/A Descartar NSR_ELECTRONICO N/A Descartar NSR_HEXADECIMAL N/A Descartar COD_PLANTARIF COD_PLANTARIF Copiar COD_SITUACION COD_SITUACION Copiar COD_ESTCOBROS N/A Descartar COD_PLANSERV COD_PLANSERV Copiar COD_ARTICULO N/A Descartar
MISC-03-1-9
157
Tabla servsuplabo
Tabla Origen Servsuplabo
Campo Origen
Tabla Destino Ods_Temp_serv
Campo Destino Tipo de Transformación de Columna
COD_ABONADO COD_ABONADO Copiar COD_SERVSUPL COD_SERVSUPL Copiar FEC_ALTABD FEC_ALTABD Copiar COD_SERVICIO COD_SERVICIO Copiar COD_NIVEL COD_NIVEL Copiar NUM_TERMINAL NUM_TERMINAL Copiar NOM_USUARORA N/A Descartar IND_ESTADO IND_ESTADO Copiar FEC_ALTACEN N/A Descartar FEC_BAJABD FEC_BAJABD Copiar FEC_BAJACEN N/A Descartar COD_PLANSERV COD_PLANSERV Copiar
Sistema de Voice Tabla Voice_mail
Tabla Origen
SMS_produccion
Campo Origen
Tabla Destino Ods_Temp_sms
Campo Destino Tipo de Transformación de Columna
NUM_CELULAR NUM_CELULAR Copiar NPA_CELULAR NPA_CELULAR Copiar CENTRAL CENTRAL Copiar
Sistema de Mensajería Tabla Sms_produccion
Tabla Origen
SMS_produccion
Campo Origen
Tabla Destino Ods_Temp_sms
Campo Destino Tipo de Transformación de Columna
NPAMIN NPA_CELULAR Copiar NPA NPA Copiar CELULAR NUM_CELULAR Copiar STATUS STATUS Copiar TCOS TCOS Copiar ORIGEN ORIGEN Copiar
MISC-03-1-9
158
Transformaciones entre Entidades Tabla ODS_Temp_abo_con_sms
Tablas Iniciales Tabla Destino
Operación entre Tablas Condición
Ods_abonado A
Ods_Temp_sms B
Ods_conversi
on_sms C Ods_Temp_abo_con_sms Join
Campos
Campo Destino ,COD_ABONADO ,COD_CLIENTE ,FEC_ALTA ,FEC_BAJA ,NUM_NPA ,NUM_CELULAR ,COD_PLANTARIF ,COD_PLANSERV ,COD_SITUACION
,COD_ABONADO ,COD_CLIENTE ,FEC_ALTA ,FEC_BAJA ,NUM_NPA ,NUM_CELULAR ,COD_PLANTARIF ,COD_PLANSERV ,COD_SITUACION
WHERE A.NUM_CELULAR = B.NUM_CELULAR AND B.TCOS = C.TCOS AND B.STATUS = C.STATUS;
Tabla ODS_Temp_abo_con_voice
Tablas Iniciales Tabla Destino
Operación entre Tablas Condición
Ods_abonado A Ods_Temp_voice B Ods_Temp_abo_con_voice Join
Campos
Campo Destino ,COD_ABONADO ,COD_CLIENTE ,FEC_ALTA ,FEC_BAJA ,NUM_NPA ,NUM_CELULAR ,COD_PLANTARIF ,COD_PLANSERV ,COD_SITUACION
,COD_ABONADO ,COD_CLIENTE ,FEC_ALTA ,FEC_BAJA ,NUM_NPA ,NUM_CELULAR ,COD_PLANTARIF ,COD_PLANSERV ,COD_SITUACION
WHERE A.NUM_CELULAR = B.NUM_CELULAR;
División tabla ODS_Temp_serv
MISC-03-1-9
159
Tablas Iniciales Tabla Destino
Operación
entre Tablas Condición
Ods_Temp_serv Ods_Temp_serv_sms Select
Campos
Campo Destino COD_ABONADO ,COD_SERVSUPL , FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL , ND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
,COD_ABONADO ,COD_SERVSUPL ,FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL ,IND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
WHERE COD_SERVSUPL IN ('SMI','PMO','PPO','MC1');
Ods_Temp_serv Ods_Temp_serv_voice Select
Campos
Campo Destino COD_ABONADO ,COD_SERVSUPL , FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL , IND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
,COD_ABONADO ,COD_SERVSUPL ,FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL ,IND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
WHERE COD_SERVICIO = 23;
Ods_Temp_serv
Ods_Temp_serv_no_sms_voice Select
Campos
Campo Destino COD_ABONADO ,COD_SERVSUPL , FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL , IND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
,COD_ABONADO ,COD_SERVSUPL ,FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL ,IND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
WHERE COD_SERVSUPL NOT IN ('SMI','PMO','PPO','MC1') AND COD_SERVICIO NOT IN (23);
MISC-03-1-9
160
Tabla ODS_temp_serv_abo_sms
Tablas Iniciales Tabla Destino
Operación entre Tablas Condición
Ods_Temp_abo_con_sms A
Ods_Temp_serv_abo_sms B
Ods_Temp_serv_abo_sms Join
Campos
Campo Destino COD_ABONADO ,
COD_SERVSUPL FEC_ALTABD , COD_SERVICIO, COD_NIVEL , NUM_TERMINAL , IND_ESTADO , FEC_BAJABD , COD_PLANSERV
COD_ABONADO , COD_SERVSUPL FEC_ALTABD , COD_SERVICIO, COD_NIVEL , NUM_TERMINAL , IND_ESTADO , FEC_BAJABD , COD_PLANSERV
WHERE A.COD_ABONADO = B.COD_ABONADO;
Tabla ODS_temp_serv_abo_voice
Tablas Iniciales Tabla Destino
Operación entre Tablas Condición
Ods_Temp_abo_con_voice A
Ods_Temp_serv_abo_voice B
Ods_Temp_serv_abo_voice Join
Campos
Campo Destino COD_ABONADO ,
COD_SERVSUPL FEC_ALTABD , COD_SERVICIO, COD_NIVEL , NUM_TERMINAL , IND_ESTADO , FEC_BAJABD , COD_PLANSERV
COD_ABONADO , COD_SERVSUPL FEC_ALTABD , COD_SERVICIO, COD_NIVEL , NUM_TERMINAL , IND_ESTADO , FEC_BAJABD , COD_PLANSERV
WHERE A.COD_ABONADO = B.COD_ABONADO;
Tabla ODS_servicios_abo
Tablas Iniciales Tabla Destino
Operación
entre Tablas
Condición
Ods_Temp_serv_abo_sms A
Ods_Temp_serv_abo_voice B
Ods_Temp_serv_n
o_sms_voice C Ods_Servicios_abo Union
Campos
Campo Destino
MISC-03-1-9
161
COD_ABONADO ,COD_SERVSUPL ,FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL ,IND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
COD_ABONADO ,COD_SERVSUPL ,FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL ,IND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
OD_ABONADO ,COD_SERVSUPL ,FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL ,IND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
COD_ABONADO ,COD_SERVSUPL ,FEC_ALTABD ,COD_SERVICIO ,COD_NIVEL ,NUM_TERMINAL ,IND_ESTADO ,FEC_BAJABD ,COD_PLANSERV
N/A
MISC-03-1-9
162
ANEXO 10.5
DISEÑO DE LOS METADATOS DEL ODS ID del Documento: DMDODS-001 Nombre del documento: Diseño de Meta Datos del ODS Nombre del Proyecto: Integración de los Servicios de Abonados Áreas o Sistemas Afectados: Servicio al Cliente y Ventas Responsables: Nombre de Líder de IT
Nombres de los Analistas de Información Nombres de los Ingenieros de IT
Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Diseño de Meta Datos del ODS
DISEÑO DE LOS METADATOS DEL ODS Tabla de Contenido
Modelo de datos propuesto para el ODS...................................................................................163
Descripción del Modelo ................................................................................................................163 Diseño del modelo de datos ........................................................................................................163
Listado y Descripción de las Entidades del Modelo de Datos ............................................163
Tabla ODS_Conversión_sms ......................................................................................................163 Descripción................................................................................................................................163 Lista de campos y Llave Primaria ..........................................................................................164
Tabla ODS_parametros................................................................................................................164 Descripción................................................................................................................................164 Lista de campos y Llave Primaria ..........................................................................................164
Tabla ODS_logproceso ................................................................................................................165 Descripción................................................................................................................................165 Lista de campos y Llave Primaria ..........................................................................................165
MISC-03-1-9
163
Modelo de datos propuesto para el ODS
Descripción del Modelo El modelo es pequeño pero muy importante porque ayuda a comprender el funcionamiento del ODS como tal, en las tablas que representan este se puede revisar las características propias del ODS, sus políticas de actualización. Este Modelo se propone sea cargado en el mismo Repositorio donde esta la Base de Datos del ODS, con el fin de permitir un fácil acceso.
Diseño del modelo de datos Dentro del modelo se incluyen tres tablas. La tabla de Conversión del SMS es una información propia del ODS y no se origina por medio del cargue de un archivo en particular. Las Otras dos tablas son muy importantes porque permiten conocer al usuario el estado de los procesos del cargue de la información al ODS. Le indican tanto la fecha de los cargues como el estado de cada uno de los subprocesos.
Listado y Descripción de las Entidades del Modelo de Datos A continuación se describen las entidades que conforma el modelo de datos propuesto para guardar la información de los metadatos del ODS.
Tabla ODS_Conversión_sms Descripción
Aunque esta tabla se explicó en el documento del Modelo de Datos del ODS. Esta incluida aquí porque corresponde a una información propia del sistema del ODS y que permite una interpretación propia del ODS. Sirve para la conversión del servicio Sms en un servicio suplementario. Es decir permite definir los servicios de la tabla Sms_producción en términos de la tabla Servsupl.
MISC-03-1-9
164
Lista de campos y Llave Primaria
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Servsupl. NOMBRE TIPO DESCRIPCION Cod_Servsupl Not Null Varchar2(3) Código del servicio suplementario,
corresponde con la matricula de activos Status Not Null Number(1) Status Tcos Not Null Number(2) Nivel de servicio
Tabla ODS_parametros Descripción
En esta tabla se definen los parámetros asociados al proceso de Cargue y Actualización de la Información en el Almacén de Datos Operacional. Se define la periodicidad de Cargue de los datos.
Lista de campos y Llave Primaria
La lista de campos se describe a continuación. No posee Llave primaria puesto que la tabla sólo contiene un solo registro. Este registro sirve de referencia para todos los procesos ejecutados sobre el ODS. Permite cambiar las características del cargue de información de las distintas tablas en el ODS. Campo Tipo Descripción Fecha_extraccion Date Fecha en que se extrajeron los archivos de las BD
Transaccionales periodicidad Number Indica cada cuanto se ejecutará el proceso de cargue. fecha_ultimo_cargue Date Fecha de Finalización del último cargue del ODS tiempo_iniciar_cargue Number Indica el Delta de Tiempo que se tendrá en cuenta para
iniciar el cargue. El sistema empezará a cargar en Fecha_extracción + Tiempo_iniciar_cargue.
unidad_tiempo Number Esta variable será usada para determinar cual es la unidad de tiempo asociada a la periodicidad 24: Horas;1440: Minutos; 86400: Segundos
directorio_ent Varchar2(100) Nombre del archivo de entrada. directorio_sal Varchar2(100) Fecha asociada al archivo de entrada Campo Tipo Descripción Fecha_extraccion Date Fecha en que se extrajeron los archivos de las BD
Transaccionales
MISC-03-1-9
165
Tabla ODS_logproceso
Descripción
Esta tabla permitirá informar a cada uno de los usuarios sean administradores o usuarios finales si los procesos asociados a cada uno de los cargues están finalizados, presentan algún error o finalizaron en forma correcta.
Lista de campos y Llave Primaria A continuación se listan los campos que constituyen la tabla. La llave primaria de esta tabla corresponde a la secuencia. Ya que un Proceso puede ejecutarse muchas veces, pero la secuencia lo hará único. Campo T ipo Descripción Secuencia Not Null Number Identificación única del proceso
Nom_proceso Not Null Varchar2(20) Nombre del proceso Fec_inicio Not Null Date Fecha de inicio del proceso Fec_fin Not Null Date Fecha de Finalización del proceso Estado Number(1) 0: En ejecución
1: Finalizado con éxito 2: Finalizado con error
Nom_archivo Varchar2(50) Nombre del archivo de entrada. Fec_proceso Date Fecha asociada al archivo de entrada Procesados Number Número de registros insertados Actualizados Number Número de registros actualizados
MISC-03-1-9
166
ANEXO 10.6. FORMATO DOCUMENTO DE FLUJO DE TRABAJO
ID del Documento: FT-001 Nombre del documento: Documento de Flujo de Trabajo Nombre del Proyecto: Integración de los Servicios de Abonados Áreas o Sistemas Afectados: Servicio al Cliente y Ventas Responsable: Líder Técnico IT
Nombres de Analistas de Información Nombres de Ingenieros de IT
Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión inicial del Documento de Chequeo de Pruebas
MISC-03-1-9
167
ID del Documento: FT-Plantarif-001 Nombre del documento: Cargue de la tabla Ods_plantarif Agente: Software Prioridad Alta Media Baja Precondición: Existencia del archivo plantarif_yyyymmddhh24miss.lis
Validación o Chequeo: ¿Qué se valida para determinar la correcta terminación? Se deben cargar todos los registros validos. Se debe registrar en la tabla de Logs la cantidad de Registros Correctos. Grafo de Flujo de Trabajo
Precede a: N/A
Antecede a: FT-Ptarif_pservicios-001
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
168
ID del Documento: FT-Ptarif_pservicios-001 Nombre del documento: Cargue de la tabla Ods_Ptarif_pservicios Agente: Software Prioridad Alta Media Baja Precondición: Existencia del archivo ptarif_pservicios_yyyymmddhh24miss.lis
Validación o Chequeo: ¿Qué se valida para determinar la correcta terminación? Se deben cargar todos los registros validos. Se debe registrar en la tabla de Logs la cantidad de Registros Correctos. Grafo de Flujo de Trabajo
Precede a: FT-Plantarif-001
Antecede a: FT-Planserv-001
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
169
ID del Documento: FT-Planserv-001 Nombre del documento: Cargue de la tabla Ods_Planserv Agente: Software Prioridad Alta Media Baja Precondición: Existencia del archivo planserv_yyyymmddhh24miss.lis
Validación o Chequeo: ¿Qué se valida para determinar la correcta terminación? Se deben cargar todos los registros validos. Se debe registrar en la tabla de Logs la cantidad de Registros Correctos. Grafo de Flujo de Trabajo
Precede a: FT-Ptarif_pservicios-001
Antecede a: FT-Servsupl-001
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
170
ID del Documento: FT-Servsupl-001 Nombre del documento: Cargue de la tabla Ods_Servsupl Agente: Software Prioridad Alta Media Baja Precondición: Existencia del archivo servsupl_yyyymmddhh24miss.lis
Validación o Chequeo: ¿Qué se valida para determinar la correcta terminación? Se deben cargar todos los registros validos. Se debe registrar en la tabla de Logs la cantidad de Registros Correctos. Grafo de Flujo de Trabajo
Precede a: FT-Planserv-001
Antecede a: FT-Servsulplps-001
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
171
ID del Documento: FT-Servsulplps-001 Nombre del documento: Cargue de la tabla Ods_Servsuplps Agente: Software Prioridad Alta Media Baja Precondición: Existencia del archivo servsuplps_yyyymmddhh24miss.lis
Validación o Chequeo: ¿Qué se valida para determinar la correcta terminación? Se deben cargar todos los registros validos. Se debe registrar en la tabla de Logs la cantidad de Registros Correctos. Grafo de Flujo de Trabajo
Precede a: FT-Servsupl-001
Antecede a: FT-Temp_serv-001
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
172
ID del Documento: FT-Temp_serv-001 Nombre del documento: Cargue de la tabla Ods_Temp_serv Agente: Software Prioridad Alta Media Baja Precondición: Existencia del archivo servsuplabo_yyyymmddhh24miss.lis
Validación o Chequeo: ¿Qué se valida para determinar la correcta terminación? Se deben cargar todos los registros validos. Se debe registrar en la tabla de Logs la cantidad de Registros Correctos. Grafo de Flujo de Trabajo
Precede a: FT-Servsulplps-001
Antecede a: FT-Div_Temp_serv-001
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
173
ID del Documento: FT-Temp_sms-001 Nombre del documento: Cargue de la tabla Ods_Temp_sms Agente: Software Prioridad Alta Media Baja Precondición: Existencia del archivo sms_yyyymmddhh24miss.lis
Validación o Chequeo: ¿Qué se valida para determinar la correcta terminación? Se deben cargar todos los registros validos. Se debe registrar en la tabla de Logs la cantidad de Registros Correctos. Grafo de Flujo de Trabajo
Precede a: N/A
Antecede a: FT-Temp_abo_con_sms-001
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
174
ID del Documento: FT-Temp_voice-001 Nombre del documento: Cargue de la tabla Ods_Temp_voice Agente: Software Prioridad Alta Media Baja Precondición: Existencia del archivo voice_yyyymmddhh24miss.lis
Validación o Chequeo: ¿Qué se valida para determinar la correcta terminación? Se deben cargar todos los registros validos. Se debe registrar en la tabla de Logs la cantidad de Registros Correctos. Grafo de Flujo de Trabajo
Precede a: N/A
Antecede a: FT-Temp_abo_con_voice-001
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
175
ID del Documento: FT-abonado-001 Nombre del documento: Cargue de la tabla Ods_abonado Agente: Software Prioridad Alta Media Baja Precondición: Existencia del archivo abonado_yyyymmddhh24miss.lis
Validación o Chequeo: ¿Qué se valida para determinar la correcta terminación? Se deben cargar todos los registros validos. Se debe registrar en la tabla de Logs la cantidad de Registros Correctos. Grafo de Flujo de Trabajo
Precede a: N/A
Antecede a: FT-Temp_abo_con_sms-001 FT-Temp_abo_con_voice-001
DESCRIPCIÓN OBSERVACIONES
MISC-03-1-9
176
ANEXO 10.7 DISEÑO FÍSICO DEL ODS Y SUS METADATOS
ID del Documento: DF-001 Nombre del documento: Diseño Físico del ODS y sus Metadatos Nombre del Proyecto: Integración de los Servicios de Abonados Áreas o Sistemas Afectados: Servicio al Cliente y Ventas Responsables: Nombre de Líder de IT
Nombres de los Analistas de Información Nombres de los Ingenieros de IT
Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial del Diseño Físico del ODS
DISEÑO FÍSICO DEL ODS Y SUS METADATOS Tabla de Contenido
Arquitectura del Sistema ...............................................................................................................178 Descripción Global de la Arquitectura.................................................................. 178 Esquema de Trabajo .............................................................................................. 179
Listado de las Entidades del Modelo de Datos........................................................................181 Tablas Definitivas de los Metadatos...................................................................... 181
Tabla ODS_Parámetros ..................................................................................... 181 Tabla ODS_Logproceso .................................................................................... 181
Tablas Definitivas del ODS................................................................................... 182 Tabla ODS_Servsupl......................................................................................... 182 Tabla ODS_Planserv ......................................................................................... 182 Tabla ODS_Plantarif ......................................................................................... 183 Tabla ODS_Ptarif_pservicios ............................................................................ 183 Tabla ODS_Servsuplps...................................................................................... 183 Tabla ODS_Abonado ........................................................................................ 184 Tabla ODS_Temp_serv ..................................................................................... 184 Tabla ODS_Temp_voice................................................................................... 185 Tabla ODS_Temp_sms...................................................................................... 185 Tabla ODS_Servicios_abo ................................................................................ 185 Tabla ODS_Conversión_sms ............................................................................ 186
Tablas Temporales del ODS.................................................................................. 186 Tabla ODS_T_Servsupl..................................................................................... 186
MISC-03-1-9
177
Tabla ODS_T_Planserv..................................................................................... 187 Tabla ODS_T_Plantarif..................................................................................... 187 Tabla ODS_T_Ptarif_pservicios........................................................................ 188 Tabla ODS_T_Servsuplps ................................................................................. 188 Tabla ODS_T_Abonado .................................................................................... 188 Tabla ODS_T_Temp_serv................................................................................. 189 Tabla ODS_T_Temp_voice............................................................................... 189 Tabla ODS_T_Temp_sms................................................................................. 190 Tabla ODS_T_Servicios_abo ............................................................................ 190 Tabla ODS_Temp_abo_con_sms...................................................................... 190 Tabla ODS_Temp_abo_con_voice.................................................................... 191 Tabla ODS_Temp_serv_sms............................................................................. 191 Tabla ODS_Temp_serv_voice .......................................................................... 192 Tabla ODS_Temp_serv_no_sms_voice ............................................................ 192 Tabla ODS_Temp_serv_abo_sms..................................................................... 192 Tabla ODS_Temp_serv_abo_voice................................................................... 193
Listado de paquetes Necesarios para el Cargue y Actualización de Información. .......193 Listado de Paquetes ............................................................................................... 194 Descripción Genérica ............................................................................................ 194 Encabezado del Paquete ........................................................................................ 195 Cuerpo del Paquete................................................................................................ 196
Flujos de Trabajos ...........................................................................................................................206 Flujo de Cargue Inicial .......................................................................................... 206
Cargue inicial de tabla ....................................................................................... 207 División de una tabla según la condición de Filtro ........................................... 208
Flujo de Trabajo de Actualización......................................................................... 209 Proceso de Actualización................................................................................... 210
MISC-03-1-9
178
Arquitectura del Sistema El Sistema para el que se diseña e implementa el prototipo es un ambiente de bases de datos heterogéneas y distribuidas en tres sistemas Elite, Servicios de Short Message y Servicios de VOICE. Para el dominio de las telecomunicaciones.
Sistema de Servicios SMS
Sistema de Servicios ELITE
ODS
MD Data
ETL Extracción
Transformación Integración
Esquema Global
Sistema de Servicios VOI CE
Descripción Global de la Arquitectura La arquitectura Global del Prototipo Funcional del Proyecto INTERDB, es una arquitectura MVC (Model View Controller), ya que se divide en el Modelo de Datos trabajado en un manejador de Bases de Datos como Oracle 8i, la Vista al Usuario la cual se representa mediante grafos, trabajados con una herramienta adicional de Oracle llamada WorkFlow, este software permite manejar los eventos haciendo llamados a funciones PL/SQL, entre los elementos del grafo.
MISC-03-1-9
179
Cada uno de los Procesos Graficados tiene un Estado que permite continuar o no dentro del Grafo de Flujos.
Esquema de Trabajo Todo el ambiente de trabajo se realizará sobre una base de datos Oracle 8i. Se realizará Los Scripts de creación de tablas según la definición realizada en el Modelo de datos propuesto para el ODS. Así mismo se tiene en cuenta las tablas solicitadas para llevar la información concerniente a los Metadatos.
ORACLE 8i
Manejador de Eventos. Llamadas entre elementos, llamadas a Funciones PL/SQL
MISC-03-1-9
180
Todas las tablas quedaran con el Prefijo ODS. Esto permitirá fácilmente su reconocimiento. Se crearan dentro de un mismo Esquema con el fin de facilitar su localización y mantenimiento. Las tablas se crearan con el usuario OWF_MGR. Los procesos de cargue y actualización de información del ODS estarán soportados en la herramienta Oracle Workflow. Para el cargue de los registros se utilizaran Paquetes desarrollados en PL/SQL. Cada una de las funciones de los paquetes como:
Validar_existencia Val_carga_tabla Cargar_taba Actual_tabla
Estará desarrollado como un Procedimiento almacenado, los cuales tiene códigos de retorno que indicará a cada una de las Funciones Subsiguiente que la tarea predecesora terminó correctamente. Se manejará Notificaciones Informativas que reflejará la completitud o no de la tarea del Flujo de Trabajo.
MISC-03-1-9
181
Listado de las Entidades del Modelo de Datos A continuación se describen las entidades que conforma el modelo de datos propuesto para el sistema integrado del ODS.
Tablas Definitivas de los Metadatos Tabla ODS_Parámetros
Descripción
En esta tabla se definen los parámetros asociados al proceso de Cargue y Actualización de la Información en el Almacén de Datos Operacional. Se define la periodicidad de Cargue de los datos.
Script de Creación
La lista de campos se describe a continuación. No posee Llave primaria puesto que la tabla sólo contiene un solo registro. Este registro sirve de referencia para todos los procesos ejecutados sobre el ODS. Permite cambiar las características del cargue de información de las distintas tablas en el ODS. CREATE TABLE ODS_PARAMETROS (FECHA_EXTRACCION DATE NOT NULL, PERIODICIDAD_MIN NUMBER, FECHA_ULTIMO_CARGUE DATE, TIEMPO_INICIAR_CARGUE NUMBER, UNIDAD_TIEMPO NUMBER, DIRECTORIO_ENT VARCHAR2(100), DIRECTORIO_SAL VARCHAR2(100), CONSTRAINT CK_UNIDAD_TIEMPO CHECK (UNIDAD_TIEMPO IN (24,1440,86400)), CONSTRAINT CONTROL_FECHAS CHECK (FECHA_EXTRACCION>FECHA_ULTIMO_CARGUE)) / Tabla ODS_Logproceso
Descripción
Esta tabla permitirá informar a cada uno de los usuarios sean administradores o usuarios finales si los procesos asociados a cada uno de los cargues están finalizados, presentan algún error o finalizaron en forma correcta.
Script de Creación
A continuación se listan los campos que constituyen la tabla. La llave primaria de esta tabla corresponde a la secuencia. Ya que un Proceso puede ejecutarse muchas veces, pero la secuencia lo hará único.
MISC-03-1-9
182
CREATE TABLE ODS_LOGPROCESO (SECUENCIA NUMBER NOT NULL, NOM_PROCESO VARCHAR2(50) NOT NULL, FEC_INICIO DATE NOT NULL, FEC_FIN DATE NOT NULL, ESTADO NUMBER(1), NOM_ARCHIVO VARCHAR2(50), FEC_PROCESO DATE, PROCESADOS NUMBER, ACTUALIZADOS NUMBER);
Tablas Definitivas del ODS Tabla ODS_Servsupl
Descripción
Esta tabla contiene los distintos servicios suplementarios que puede contratar un abonado.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla es el campo Cod_servsupl. CREATE TABLE ODS_SERVSUPL (COD_SERVSUPL VARCHAR2(3) NOT NULL, DES_SERVSUPL VARCHAR2(50), COD_SERVICIO NUMBER(3), COD_NIVEL NUMBER(4), FEC_INICIO DATE, FEC_FIN DATE); Tabla ODS_Planserv
Descripción
Esta tabla contiene los planes de servicios que asocia los diferentes servicios suplementarios.
Script de Creación
La lista de los campos de la tabla se describen a continuación. La llave primaria de esta tabla es el campo Cod_planserv. CREATE TABLE ODS_PLANSERV (COD_PLANSERV VARCHAR2(3) NOT NULL, DES_PLANSERV VARCHAR2(30), FEC_DESDE DATE, FEC_HASTA DATE);
MISC-03-1-9
183
Tabla ODS_Plantarif
Descripción
Tabla que contiene los distintos planes tarifarios que contiene las tarifas para el cobro de los servicios del abonado.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla es el campo Cod_plantarif. CREATE TABLE ODS_PLANTARIF (COD_PLANTARIF VARCHAR2(3) NOT NULL, DES_PLANTARIF VARCHAR2(30), COD_CARGOBASICO VARCHAR2(3), FEC_DESDE DATE, FEC_HASTA DATE); Tabla ODS_Ptarif_pservicios
Descripción
Tabla que asocia los planes tarifarios con los planes de servicios.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen los campos Cod_plantarif y Cod_planserv.
CREATE TABLE ODS_PTARIF_PSERVICIOS (COD_PLANTARIF VARCHAR2(3) NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL);
Tabla ODS_Servsuplps
Descripción
Tabla que asocia los servicios suplementarios con los patrones de servicios.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen los campos Cod_planserv y Cod_servsupl.
CREATE TABLE ODS_SERVSUPLPS (COD_PLANSERV VARCHAR2(3) NOT NULL,
MISC-03-1-9
184
COD_SERVSUPL VARCHAR2(3) NOT NULL);
Tabla ODS_Abonado
Descripción
Tabla que contiene los abonados o suscriptores que posee la empresa
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la compone el campo Cod_abonado. CREATE TABLE ODS_ABONADO (COD_ABONADO NUMBER(8) NOT NULL, COD_CLIENTE NUMBER(8) NOT NULL, FEC_ALTA DATE NOT NULL, FEC_BAJA DATE NOT NULL, NUM_NPA NUMBER(3) NOT NULL, NUM_CELULAR NUMBER(7) NOT NULL, COD_PLANTARIF VARCHAR2(3) NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL, COD_SITUACION VARCHAR2(3) NOT NULL);
Tabla ODS_Temp_serv
Descripción
Tabla que indica los servicios que ha tenido un abonado durante cierto tiempo, indica tanto los activos como los cancelados. Esta tabla es temporal y solo contiene la Información correspondiente al sistema de Facturación.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen los campos Cod_abonado, Cod_servsupl, Fec_altabd. CREATE TABLE ODS_TEMP_SERV (COD_ABONADO NUMBER(8) NOT NULL, COD_SERVSUPL VARCHAR2(50) NOT NULL, FEC_ALTABD DATE NOT NULL, COD_SERVICIO NUMBER(3) NOT NULL, COD_NIVEL NUMBER(4) NOT NULL, NUM_TERMINAL VARCHAR2(15) NOT NULL, IND_ESTADO NUMBER(1) NOT NULL, FEC_BAJABD DATE NOT NULL,
MISC-03-1-9
185
COD_PLANSERV VARCHAR2(3) NOT NULL); Tabla ODS_Temp_voice
Descripción
La tabla de Ods_Temp_Voice indica si un numero celular en particular tiene activado el servicio de buzón de voz y en que central se encuentra. Esta tabla es temporal y solo contiene información de la plataforma de Buzones de Voz.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Num_celular. CREATE TABLE ODS_TEMP_VOICE (NUM_CELULAR NUMBER(7) NOT NULL NPA_CELULAR NUMBER(10) NOT NULL CENTRAL VARCHAR2(5) NOT NULL); Tabla ODS_Temp_sms
Descripción
Esta tabla contiene los Número Celulares que tiene activados los servicios de mensajería y que tipo de servicio contienen.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Npa_celular. CREATE TABLE ODS_TEMP_SMS (NPA_CELULAR NUMBER(10) NOT NULL, NPA NUMBER(3) NOT NULL, NUM_CELULAR NUMBER(7) NOT NULL, STATUS NUMBER(1) NOT NULL, TCOS NUMBER(2) NOT NULL, ORIGEN VARCHAR2(30)); Tabla ODS_Servicios_abo
Descripción
Tabla que indica los servicios que ha tenido un abonado durante cierto tiempo, indica tanto los activos como los cancelados. Integra completamente los servicios tanto activados en el Sistema de facturación como en los Otros dos sistemas, es decir Mensajería - Sms y Voice.
MISC-03-1-9
186
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Cod_abonado, Cod_servsupl y Fec_altabd. CREATE TABLE ODS_SERVICIOS_ABO (COD_ABONADO NUMBER(8), COD_SERVSUPL VARCHAR2(50), FEC_ALTABD DATE, COD_SERVICIO NUMBER(3), COD_NIVEL NUMBER(4), NUM_TERMINAL VARCHAR2(15), IND_ESTADO NUMBER(1), FEC_BAJABD DATE, COD_PLANSERV VARCHAR2(3)); Tabla ODS_Conversión_sms
Descripción
Tabla propia del Modelo ODS. Sirve para la conversión del servicio Sms en un servicio suplementario. Es decir permite definir los servicios de la tabla Sms_producción en términos de la tabla Sevsupl. Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Servsupl. CREATE TABLE ODS_CONVERSION_SMS (COD_SERVSUPL VARCHAR2(3) NOT NULL, TCOS NUMBER(2) NOT NULL, STATUS NUMBER(1) NOT NULL);
Tablas Temporales del ODS Tabla ODS_T_Servsupl
Descripción
Similar a Ods_Servsupl. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla es el campo Cod_servsupl.
MISC-03-1-9
187
CREATE TABLE ODS_T_SERVSUPL (COD_SERVSUPL VARCHAR2(3) NOT NULL, DES_SERVSUPL VARCHAR2(50), COD_SERVICIO NUMBER(3), COD_NIVEL NUMBER(4), FEC_INICIO DATE, FEC_FIN DATE); Tabla ODS_T_Planserv
Descripción
Similar a Ods_Planserv. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla es el campo Cod_planserv. CREATE TABLE ODS_T_PLANSERV (COD_PLANSERV VARCHAR2(3) NOT NULL, DES_PLANSERV VARCHAR2(30), FEC_DESDE DATE, FEC_HASTA DATE);
Tabla ODS_T_Plantarif
Descripción
Similar a Ods_Plantarif. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla es el campo Cod_plantarif. CREATE TABLE ODS_T_PLANTARIF (COD_PLANTARIF VARCHAR2(3) NOT NULL, DES_PLANTARIF VARCHAR2(30), COD_CARGOBASICO VARCHAR2(3), FEC_DESDE DATE, FEC_HASTA DATE);
MISC-03-1-9
188
Tabla ODS_T_Ptarif_pservicios
Descripción
Similar a Ods_Ptarif_pservicios. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen los campos Cod_plantarif y Cod_planserv.
CREATE TABLE ODS_T_PTARIF_PSERVICIOS
( COD_PLANTARIF VARCHAR2(3) NOT NULL,
COD_PLANSERV VARCHAR2(3) NOT NULL); Tabla ODS_T_Servsuplps
Descripción
Similar a Ods_Servsuplps. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen los campos Cod_planserv y Cod_servsupl.
CREATE TABLE ODS_T_SERVSUPLPS (COD_PLANSERV VARCHAR2(3) NOT NULL, COD_SERVSUPL VARCHAR2(3) NOT NULL); Tabla ODS_T_Abonado
Descripción
Similar a Ods_abonado. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la compone el campo Cod_abonado.
MISC-03-1-9
189
CREATE TABLE ODS_T_ABONADO (COD_ABONADO NUMBER(8) NOT NULL, COD_CLIENTE NUMBER(8) NOT NULL, FEC_ALTA DATE NOT NULL, FEC_BAJA DATE NOT NULL, NUM_NPA NUMBER(3) NOT NULL, NUM_CELULAR NUMBER(7) NOT NULL, COD_PLANTARIF VARCHAR2(3) NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL, COD_SITUACION VARCHAR2(3) NOT NULL);
Tabla ODS_T_Temp_serv
Descripción
Similar a Ods_Temp_serv. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen los campos Cod_abonado, Cod_servsupl, Fec_altabd. CREATE TABLE ODS_T_TEMP_SERV (COD_ABONADO NUMBER(8) NOT NULL, COD_SERVSUPL VARCHAR2(50) NOT NULL, FEC_ALTABD DATE NOT NULL, COD_SERVICIO NUMBER(3) NOT NULL, COD_NIVEL NUMBER(4) NOT NULL, NUM_TERMINAL VARCHAR2(15) NOT NULL, IND_ESTADO NUMBER(1) NOT NULL, FEC_BAJABD DATE NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL); Tabla ODS_T_Temp_voice
Descripción
Similar a Ods_T_Temp_voice. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Num_celular. CREATE TABLE ODS_T_TEMP_VOICE (NUM_CELULAR NUMBER(7) NOT NULL NPA_CELULAR NUMBER(10) NOT NULL CENTRAL VARCHAR2(5) NOT NULL);
MISC-03-1-9
190
Tabla ODS_T_Temp_sms
Descripción
Similar a Ods_Temp_sms. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Npa_celular. CREATE TABLE ODS_T_TEMP_SMS (NPA_CELULAR NUMBER(10) NOT NULL, NPA NUMBER(3) NOT NULL, NUM_CELULAR NUMBER(7) NOT NULL, STATUS NUMBER(1) NOT NULL, TCOS NUMBER(2) NOT NULL, ORIGEN VARCHAR2(30)); Tabla ODS_T_Servicios_abo
Descripción
Similar a Ods_abonado. La tabla Temporal es utilizada en el proceso de actualización de registros de esta tabla.
Script de Creación
La lista de los campos de la tabla se describe a continuación. La llave primaria de esta tabla la componen el campo Cod_abonado, Cod_servsupl y Fec_altabd. CREATE TABLE ODS_T_SERVICIOS_ABO (COD_ABONADO NUMBER(8), COD_SERVSUPL VARCHAR2(50), FEC_ALTABD DATE, COD_SERVICIO NUMBER(3), COD_NIVEL NUMBER(4), NUM_TERMINAL VARCHAR2(15), IND_ESTADO NUMBER(1), FEC_BAJABD DATE, COD_PLANSERV VARCHAR2(3)); Tabla ODS_Temp_abo_con_sms
Descripción
Tabla originada del Join entre las tablas Ods_abonado, Ods_Temp_sms y Ods_conversión_sms.
MISC-03-1-9
191
Script de Creación
CREATE TABLE ODS_TEMP_ABO_CON_SMS (COD_ABONADO NUMBER(8) NOT NULL, COD_SERVSUPL VARCHAR2(50) NOT NULL, FEC_ALTABD DATE NOT NULL, COD_SERVICIO NUMBER(3) NOT NULL, COD_NIVEL NUMBER(4) NOT NULL, NUM_TERMINAL VARCHAR2(15) NOT NULL, IND_ESTADO NUMBER(1) NOT NULL, FEC_BAJABD DATE NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL); Tabla ODS_Temp_abo_con_voice
Descripción
Tabla originada del Join entre las tablas Ods_abonado, Ods_Temp_voice.
Script de Creación
CREATE TABLE ODS_TEMP_ABO_CON_VOICE (COD_ABONADO NUMBER(8) NOT NULL, COD_SERVSUPL VARCHAR2(50) NOT NULL, FEC_ALTABD DATE NOT NULL, COD_SERVICIO NUMBER(3) NOT NULL, COD_NIVEL NUMBER(4) NOT NULL, NUM_TERMINAL VARCHAR2(15) NOT NULL, IND_ESTADO NUMBER(1) NOT NULL, FEC_BAJABD DATE NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL); Tabla ODS_Temp_serv_sms
Descripción
Tabla originada de un filtro en la tabla ods_Temp_serv.
Script de Creación
CREATE TABLE ODS_TEMP_SERV_SMS (COD_ABONADO NUMBER(8) NOT NULL, COD_SERVSUPL VARCHAR2(50) NOT NULL, FEC_ALTABD DATE NOT NULL, COD_SERVICIO NUMBER(3) NOT NULL, COD_NIVEL NUMBER(4) NOT NULL, NUM_TERMINAL VARCHAR2(15) NOT NULL,
MISC-03-1-9
192
IND_ESTADO NUMBER(1) NOT NULL, FEC_BAJABD DATE NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL); Tabla ODS_Temp_serv_voice
Descripción
Tabla originada de un filtro en la tabla ods_Temp_serv.
Script de Creación
CREATE TABLE ODS_TEMP_SERV_VOICE (COD_ABONADO NUMBER(8) NOT NULL, COD_SERVSUPL VARCHAR2(50) NOT NULL, FEC_ALTABD DATE NOT NULL, COD_SERVICIO NUMBER(3) NOT NULL, COD_NIVEL NUMBER(4) NOT NULL, NUM_TERMINAL VARCHAR2(15) NOT NULL, IND_ESTADO NUMBER(1) NOT NULL, FEC_BAJABD DATE NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL);
Tabla ODS_Temp_serv_no_sms_voice
Descripción
Tabla originada de un filtro en la tabla ods_Temp_serv. Script de Creación
CREATE TABLE ODS_TEMP_SERV_NO_SMS_VOICE (COD_ABONADO NUMBER(8) NOT NULL, COD_SERVSUPL VARCHAR2(50) NOT NULL, FEC_ALTABD DATE NOT NULL, COD_SERVICIO NUMBER(3) NOT NULL, COD_NIVEL NUMBER(4) NOT NULL, NUM_TERMINAL VARCHAR2(15) NOT NULL, IND_ESTADO NUMBER(1) NOT NULL, FEC_BAJABD DATE NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL); Tabla ODS_Temp_serv_abo_sms
Descripción
Tabla originada de un Join entre las tablas Ods_Temp_abo_con_sms y Ods_Temp_serv_sms.
MISC-03-1-9
193
Script de Creación
CREATE TABLE ODS_TEMP_ABO_SMS (COD_ABONADO NUMBER(8) NOT NULL, COD_SERVSUPL VARCHAR2(50) NOT NULL, FEC_ALTABD DATE NOT NULL, COD_SERVICIO NUMBER(3) NOT NULL, COD_NIVEL NUMBER(4) NOT NULL, NUM_TERMINAL VARCHAR2(15) NOT NULL, IND_ESTADO NUMBER(1) NOT NULL, FEC_BAJABD DATE NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL);
Tabla ODS_Temp_serv_abo_voice
Descripción
Tabla originada de un Join entre las tablas Ods_Temp_abo_con_voice y Ods_Temp_serv_voice.
Script de Creación
CREATE TABLE ODS_TEMP_ABO_VOICE (COD_ABONADO NUMBER(8) NOT NULL, COD_SERVSUPL VARCHAR2(50) NOT NULL, FEC_ALTABD DATE NOT NULL, COD_SERVICIO NUMBER(3) NOT NULL, COD_NIVEL NUMBER(4) NOT NULL, NUM_TERMINAL VARCHAR2(15) NOT NULL, IND_ESTADO NUMBER(1) NOT NULL, FEC_BAJABD DATE NOT NULL, COD_PLANSERV VARCHAR2(3) NOT NULL);
Listado de paquetes Necesarios para el Cargue y Actualización de Información. Para el cargue de los registros hacia el ODS se utilizan Paquetes desarrollados en Oracle. Codificados en un editor de Textos genérico. Como se mencionó anteriormente los Paquetes serán reconocidos porque tienen como prefijo la palabra ODS. Por ejemplo: Ods_pac_servsupl. Los paquetes tienen una serie de procedimientos almacenados que devuelven valores de Aprobación o Desaprobación. Lo cual permitirá mas adelante enlazar cada una de las funciones del Cargue o Actualización de Información en los flujos de Trabajo que se diseñan en Oracle Workflow.
MISC-03-1-9
194
Listado de Paquetes Los paquetes que se utilizan son los siguientes: Nombre del Paquete Descripción
ODS_PAC_ABONADO Carga y actualiza la Información de la tabla Ods_abonado
ODS_PAC_DIV_ODS_TEMP_SERV Divide la tabla Ods_Temp_serv ODS_PAC_PLANSERV Carga y actualiza la Información de la
tabla Ods_planserv ODS_PAC_PLANTARIF Carga y actualiza la Información de la
tabla Ods_plantarif ODS_PAC_PTARIF_PSERVICIOS Carga y actualiza la Información de la
tabla Ods_ptarif_pservicios ODS_PAC_SERVICIOS_ABO Carga y actualiza la Información de la
tabla Ods_servicios_abo ODS_PAC_SERVSUPL Carga y actualiza la Información de la
tabla Ods_servsupl ODS_PAC_SERVSUPLPS Carga y actualiza la Información de la
tabla Ods_servsuplps ODS_PAC_TEMP_ABO_CON_SMS Carga y actualiza la Información de la
tabla Ods_Temp_abo_con_sms ODS_PAC_TEMP_ABO_CON_VOICE Carga y actualiza la Información de la
tabla Ods_Temp_abo_con_voice ODS_PAC_TEMP_ABO_VOICE Carga y actualiza la Información de la
tabla Ods_Temp_abo_voice ODS_PAC_TEMP_SERV Carga y actualiza la Información de la
tabla Ods_Temp_serv ODS_PAC_TEMP_SERV_ABO_SMS Carga y actualiza la Información de la
tabla Ods_Temp_serv_abo_sms ODS_PAC_TEMP_SERV_ABO_VOICE Carga y actualiza la Información de la
tabla Ods_Temp_serv_abo_voice ODS_PAC_TEMP_SMS Carga y actualiza la Información de la
tabla Ods_Tep_sms ODS_PAC_TEMP_VOICE Carga y actualiza la Información de la
tabla Ods_Temp_voice
Descripción Genérica Los paquetes tienen cada uno de los siguientes procedimientos genéricos. Nombre del Procedimiento
Descripción Respuesta
Val_existencia Verifica la existencia de la Fuente desde la cual cargará la información.
True / False
Val_carga_tabla Validar la carga de la tabla. True / False Cargar_tabla Cargar la tabla Destino a partir de la Fuente. Approve / Reject Borrar_tabla Borra los registros de la tabla destino. True / False Val_actual_tabla Validar la actualización de la tabla destino True / False Cargar_tabla_T Cargar la tabla temporal a partir de la Fuente. Approve / Reject Actual_tabla Actualización de la Tabla destino. Approve / Reject Borrar_Tabla_T Borrar la Tabla temporal True / False
MISC-03-1-9
195
En este ítem se muestra la estructura típica de un paquete utilizado en el grafo de flujo anterior. Para efectos de ilustración se utilizará el paquete asociado a la tabla Ods_servsupl
Encabezado del Paquete A continuación se describe el encabezo de un paquete genérico, en el cual se encuentran todos los procedimientos que realizan las distintas operaciones dentro del Grafo.
-- Desarrollado por: JARN -- Package ODS_PAC_SERVSUPL CREATE OR REPLACE package ODS_PAC_SERVSUPL as /* Este procedimiento devuelve un boolena true o false */ procedure VAL_EXISTENCIA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ); /* Este procedimiento devuelve un boolena true o false */ procedure VAL_CARGA_TABLA ( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ); /* Este procedimiento devuelve reject o aproval el resultado en la funcion debe ser approval */ procedure CARGAR_TABLA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ); /* Este procedimiento devuelve un boolena true o false */ procedure BORRAR_TABLA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ); /* Este procedimiento devuelve un boolena true o false */ procedure VAL_ACTUAL_TABLA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ); /* Este procedimiento devuelve reject o aproval el resultado en la funcion debe ser approval */ procedure CARGAR_TABLA_T( itemtype in varchar2,
MISC-03-1-9
196
itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ); /* Este procedimiento devuelve reject o aproval el resultado en la funcion debe ser approval */ procedure ACTUAL_TABLA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ); /* Este procedimiento devuelve un boolena true o false */ procedure BORRAR_TABLA_T( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ); end; / -- End of DDL script
Cuerpo del Paquete A continuación se describe el cuerpo de un paquete genérico, en el cual se encuentran todos los procedimientos (Cargue, Borrado, Actualización) que realizan las distintas operaciones dentro del Grafo. -- Desarrollado por: JARN -- Package ODS_PAC_SERVSUPL CREATE OR REPLACE package body ODS_PAC_SERVSUPL as /* Este procedimiento devuelve un boolean true o false */ procedure VAL_EXISTENCIA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ) is NombreArchivo1 VARCHAR2(50); Apuntador1 UTL_FILE.FILE_TYPE; Registro1 VARCHAR2(7); Cadena1 VARCHAR2(7); Directorio1 ODS_PARAMETROS.DIRECTORIO_ENT%TYPE; v_fecha DATE; I NUMBER(3); V_Fecha_Extraccion ODS_PARAMETROS.FECHA_EXTRACCION%TYPE; BEGIN BEGIN SELECT FECHA_EXTRACCION, DIRECTORIO_ENT INTO
MISC-03-1-9
197
V_FECHA_EXTRACCION, DIRECTORIO1 FROM ODS_PARAMETROS; EXCEPTION WHEN OTHERS THEN RESULTOUT:= 'COMPLETE:F'; END; NombreArchivo1:= 'SERVSUPL_'||TO_CHAR(V_FECHA_EXTRACCION,'YYYYMMDDHH24MISS')||'.list'; Apuntador1 := UTL_FILE.FOPEN(Directorio1,NombreArchivo1,'r'); UTL_FILE.FCLOSE(Apuntador1); resultout := 'COMPLETE:T'; EXCEPTION WHEN OTHERS THEN UTL_FILE.FCLOSE(Apuntador1); RESULTOUT := 'COMPLETE:F'; END; /* Este procedimiento devuelve reject o aproval el resultado en la funcion debe ser approval */ procedure CARGAR_TABLA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ) is NombreArchivo1 VARCHAR2(50); Apuntador1 UTL_FILE.FILE_TYPE; Registro1 VARCHAR2(500); Cadena VARCHAR2(150); Directorio1 ODS_PARAMETROS.DIRECTORIO_ENT%TYPE; v_fecha DATE; I NUMBER(3); V_FECHA_Extraccion ODS_PARAMETROS.FECHA_EXTRACCION%TYPE; V_COD_SERVSUPL ODS_SERVSUPL.COD_SERVSUPL%TYPE; V_DES_SERVSUPL ODS_SERVSUPL.DES_SERVSUPL%TYPE; V_COD_SERVICIO ODS_SERVSUPL.COD_SERVICIO%TYPE; V_COD_NIVEL ODS_SERVSUPL.COD_NIVEL %TYPE; V_FEC_INICIO ODS_SERVSUPL.FEC_INICIO%TYPE; V_FEC_FIN ODS_SERVSUPL.FEC_FIN%TYPE; --Parametros del archivo Log CONTADOR NUMBER := 0; LEIDOS NUMBER := 100000; BLOQUE NUMBER := 100000; NRO_PROCESO NUMBER(10):= 0; NOM_PROCESO ODS_LOGPROCESO.NOM_PROCESO%TYPE; BEGIN BEGIN SELECT FECHA_EXTRACCION, DIRECTORIO_ENT INTO V_FECHA_EXTRACCION, DIRECTORIO1 FROM ODS_PARAMETROS; EXCEPTION WHEN OTHERS THEN RESULTOUT := 'COMPLETE:REJECTED';
MISC-03-1-9
198
END; NombreArchivo1 := 'SERVSUPL_'||TO_CHAR(V_FECHA_EXTRACCION,'YYYYMMDDHH24MISS')||'.list'; Apuntador1 := UTL_FILE.FOPEN(Directorio1,NombreArchivo1,'r'); NOM_PROCESO := 'P01_CARGAR_ODS_SERVSUPL'; select ods_seq_procesos.nextval into NRO_PROCESO from dual; INSERT INTO ODS_LOGPROCESO VALUES ( NRO_PROCESO, NOM_PROCESO, SYSDATE, SYSDATE, 0, NombreArchivo1, V_FECHA_EXTRACCION, 0, 0 ); COMMIT; LOOP BEGIN UTL_FILE.GET_LINE(Apuntador1,Registro1); cadena := Registro1; i := INSTR ( cadena, ';' ) - 1; V_COD_SERVSUPL := SUBSTR (cadena, 1, i); cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_DES_SERVSUPL := SUBSTR (cadena, 1, i); cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_COD_SERVICIO := SUBSTR (cadena, 1, i); cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_COD_NIVEL := SUBSTR (cadena, 1, i); cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_FEC_INICIO := SUBSTR (cadena, 1, i); cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_FEC_FIN := SUBSTR (cadena, 1, i); INSERT INTO ODS_SERVSUPL (COD_SERVSUPL, DES_SERVSUPL, COD_SERVICIO, COD_NIVEL, FEC_INICIO, FEC_FIN) VALUES (V_COD_SERVSUPL, V_DES_SERVSUPL, V_COD_SERVICIO, V_COD_NIVEL, V_FEC_INICIO, V_FEC_FIN); COMMIT; EXCEPTION WHEN DUP_VAL_ON_INDEX THEN
MISC-03-1-9
199
UTL_FILE.FCLOSE(Apuntador1); RESULTOUT := 'COMPLETE:REJECTED'; EXIT; WHEN OTHERS THEN UTL_FILE.FCLOSE(Apuntador1); RESULTOUT := 'COMPLETE:REJECTED'; EXIT; END; END LOOP; UTL_FILE.FCLOSE(Apuntador1); resultout := 'COMPLETE:APPROVED'; UPDATE ODS_LOGPROCESO SET FEC_FIN = SYSDATE, ESTADO = 1, PROCESADOS = CONTADOR WHERE NOM_PROCESO = NOM_PROCESO AND SECUENCIA = NRO_PROCESO; COMMIT; EXCEPTION WHEN OTHERS THEN UPDATE ODS_LOGPROCESO SET FEC_FIN = SYSDATE, ESTADO = 2, PROCESADOS = CONTADOR WHERE NOM_PROCESO = NOM_PROCESO AND SECUENCIA = NRO_PROCESO; COMMIT; END; /* Este procedimiento devuelve un boolena true o false */ procedure VAL_CARGA_TABLA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ) is NombreArchivo1 VARCHAR2(50); V_FECHA_Extraccion ODS_PARAMETROS.FECHA_EXTRACCION%TYPE; NOM_PROCESO ODS_LOGPROCESO.NOM_PROCESO%TYPE; CONTEO NUMBER; BEGIN BEGIN SELECT FECHA_EXTRACCION INTO V_FECHA_EXTRACCION FROM ODS_PARAMETROS; EXCEPTION WHEN OTHERS THEN RESULTOUT := 'COMPLETE:F'; END; NombreArchivo1 := 'SERVSUPL_'||TO_CHAR(V_FECHA_EXTRACCION,'YYYYMMDDHH24MISS')||'.list'; NOM_PROCESO := 'P01_CARGAR_ODS_SERVSUPL'; BEGIN select SECUENCIA INTO CONTEO
MISC-03-1-9
200
from ods_logproceso where nom_proceso = NOM_PROCESO AND NOM_ARCHIVO = NombreArchivo1 AND ESTADO = 1; EXCEPTION WHEN NO_DATA_FOUND THEN RESULTOUT := 'COMPLETE:F'; WHEN TOO_MANY_ROWS THEN RESULTOUT := 'COMPLETE:T'; WHEN OTHERS THEN RESULTOUT := 'COMPLETE:F'; END; IF CONTEO IS NOT NULL THEN RESULTOUT := 'COMPLETE:T'; END IF; EXCEPTION WHEN OTHERS THEN RESULTOUT := 'COMPLETE:F'; END; /* Este procedimiento devuelve un boolena true o false */ procedure BORRAR_TABLA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ) is C NUMBER; N NUMBER; BEGIN c:= dbms_sql.open_cursor; dbms_sql.parse(c, 'Truncate Table ODS_SERVSUPL', dbms_sql.native); --dbms_sql.bind_variable(c, '1', amount); n := dbms_sql.execute(c); dbms_sql.close_cursor(c); RESULTOUT := 'COMPLETE:T'; EXCEPTION WHEN OTHERS THEN DBMS_SQL.CLOSE_CURSOR(c); RESULTOUT := 'COMPLETE:F'; END; /* Los siguientes son procedimientos para realizar actualizaciones */ /* Este procedimiento devuelve reject o aproval el resultado en la funcion debe ser approval */ procedure CARGAR_TABLA_T( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ) is NombreArchivo1 VARCHAR2(50); Apuntador1 UTL_FILE.FILE_TYPE; Registro1 VARCHAR2(500); Cadena VARCHAR2(150); Directorio1 ODS_PARAMETROS.DIRECTORIO_ENT%TYPE; v_fecha DATE; I NUMBER(3);
MISC-03-1-9
201
V_FECHA_Extraccion ODS_PARAMETROS.FECHA_EXTRACCION%TYPE; V_COD_SERVSUPL ODS_SERVSUPL.COD_SERVSUPL%TYPE; V_DES_SERVSUPL ODS_SERVSUPL.DES_SERVSUPL%TYPE; V_COD_SERVICIO ODS_SERVSUPL.COD_SERVICIO%TYPE; V_COD_NIVEL ODS_SERVSUPL.COD_NIVEL %TYPE; V_FEC_INICIO ODS_SERVSUPL.FEC_INICIO%TYPE; V_FEC_FIN ODS_SERVSUPL.FEC_FIN%TYPE; --Parametros del archivo Log CONTADOR NUMBER := 0; LEIDOS NUMBER := 100000; BLOQUE NUMBER := 100000; NRO_PROCESO NUMBER(10):= 0; NOM_PROCESO ODS_LOGPROCESO.NOM_PROCESO%TYPE; BEGIN BEGIN SELECT FECHA_EXTRACCION, DIRECTORIO_ENT INTO V_FECHA_EXTRACCION, DIRECTORIO1 FROM ODS_PARAMETROS; EXCEPTION WHEN OTHERS THEN RESULTOUT := 'COMPLETE:REJECTED'; END; NombreArchivo1 := 'SERVSUPL_'||TO_CHAR(V_FECHA_EXTRACCION,'YYYYMMDDHH24MISS')||'.list'; Apuntador1 := UTL_FILE.FOPEN(Directorio1,NombreArchivo1,'r'); NOM_PROCESO := 'P01_CARGAR_ODS_T_SERVSUPL'; select ods_seq_procesos.nextval into NRO_PROCESO from dual; INSERT INTO ODS_LOGPROCESO VALUES ( NRO_PROCESO, NOM_PROCESO, SYSDATE, SYSDATE, 0, NombreArchivo1, V_FECHA_EXTRACCION, 0, 0 ); COMMIT; LOOP BEGIN UTL_FILE.GET_LINE(Apuntador1,Registro1); cadena := Registro1; i := INSTR ( cadena, ';' ) - 1; V_COD_SERVSUPL := SUBSTR (cadena, 1, i); cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_DES_SERVSUPL := SUBSTR (cadena, 1, i); cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_COD_SERVICIO := SUBSTR (cadena, 1, i);
MISC-03-1-9
202
cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_COD_NIVEL := SUBSTR (cadena, 1, i); cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_FEC_INICIO := SUBSTR (cadena, 1, i); cadena := substr(cadena, i + 2, 110); i := INSTR ( cadena, ';' ) - 1; V_FEC_FIN := SUBSTR (cadena, 1, i); INSERT INTO ODS_T_SERVSUPL (COD_SERVSUPL, DES_SERVSUPL, COD_SERVICIO, COD_NIVEL, FEC_INICIO, FEC_FIN) VALUES (V_COD_SERVSUPL, V_DES_SERVSUPL, V_COD_SERVICIO, V_COD_NIVEL, V_FEC_INICIO, V_FEC_FIN); COMMIT; EXCEPTION WHEN DUP_VAL_ON_INDEX THEN UTL_FILE.FCLOSE(Apuntador1); RESULTOUT := 'COMPLETE:REJECTED'; EXIT; WHEN OTHERS THEN UTL_FILE.FCLOSE(Apuntador1); RESULTOUT := 'COMPLETE:REJECTED'; EXIT; END; END LOOP; UTL_FILE.FCLOSE(Apuntador1); resultout := 'COMPLETE:APPROVED'; UPDATE ODS_LOGPROCESO SET FEC_FIN = SYSDATE, ESTADO = 1, PROCESADOS = CONTADOR WHERE NOM_PROCESO = NOM_PROCESO AND SECUENCIA = NRO_PROCESO; COMMIT; EXCEPTION WHEN OTHERS THEN UPDATE ODS_LOGPROCESO SET FEC_FIN = SYSDATE, ESTADO = 2, PROCESADOS = CONTADOR WHERE NOM_PROCESO = NOM_PROCESO AND SECUENCIA = NRO_PROCESO; COMMIT;
MISC-03-1-9
203
END; /* Este procedimiento devuelve un boolena true o false */ procedure VAL_ACTUAL_TABLA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ) is NombreArchivo1 VARCHAR2(50); V_FECHA_Extraccion ODS_PARAMETROS.FECHA_EXTRACCION%TYPE; NOM_PROCESO ODS_LOGPROCESO.NOM_PROCESO%TYPE; CONTEO NUMBER; BEGIN BEGIN SELECT FECHA_EXTRACCION INTO V_FECHA_EXTRACCION FROM ODS_PARAMETROS; EXCEPTION WHEN OTHERS THEN RESULTOUT := 'COMPLETE:F'; END; --NombreArchivo1 := 'SERVSUPL_'||TO_CHAR(V_FECHA_EXTRACCION,'YYYYMMDDHH24MISS')||'.list'; NOM_PROCESO := 'P01_ACTUALIZAR_ODS_SERVSUPL'; BEGIN select SECUENCIA INTO CONTEO from ods_logproceso where nom_proceso = NOM_PROCESO AND FEC_PROCESO = V_FECHA_EXTRACCION AND ESTADO = 1; EXCEPTION WHEN NO_DATA_FOUND THEN RESULTOUT := 'COMPLETE:F'; WHEN TOO_MANY_ROWS THEN RESULTOUT := 'COMPLETE:T'; WHEN OTHERS THEN RESULTOUT := 'COMPLETE:F'; END; IF CONTEO IS NOT NULL THEN RESULTOUT := 'COMPLETE:T'; END IF; EXCEPTION WHEN OTHERS THEN RESULTOUT := 'COMPLETE:F'; END; /* Este procedimiento devuelve reject o aproval el resultado en la funcion debe ser approval */ procedure ACTUAL_TABLA( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ) is I NUMBER(3); V_FECHA_Extraccion ODS_PARAMETROS.FECHA_EXTRACCION%TYPE; V_COD_SERVSUPL ODS_SERVSUPL.COD_SERVSUPL%TYPE; V_DES_SERVSUPL ODS_SERVSUPL.DES_SERVSUPL%TYPE;
MISC-03-1-9
204
V_COD_SERVICIO ODS_SERVSUPL.COD_SERVICIO%TYPE; V_COD_NIVEL ODS_SERVSUPL.COD_NIVEL %TYPE; V_FEC_INICIO ODS_SERVSUPL.FEC_INICIO%TYPE; V_FEC_FIN ODS_SERVSUPL.FEC_FIN%TYPE; --Parametros del archivo Log CONTADOR NUMBER := 0; ACTUALIZADOS NUMBER := 0; LEIDOS NUMBER := 100000; BLOQUE NUMBER := 100000; NRO_PROCESO NUMBER(10):= 0; NOM_PROCESO ODS_LOGPROCESO.NOM_PROCESO%TYPE; CURSOR C1 IS SELECT cod_servsupl, des_servsupl, cod_servicio, cod_nivel, fec_inicio, fec_fin FROM ods_t_servsupl; BEGIN BEGIN SELECT FECHA_EXTRACCION INTO V_FECHA_EXTRACCION FROM ODS_PARAMETROS; EXCEPTION WHEN OTHERS THEN RESULTOUT := 'COMPLETE:REJECTED'; END; NOM_PROCESO := 'P01_ACTUALIZAR_ODS_SERVSUPL'; select ods_seq_procesos.nextval into NRO_PROCESO from dual; INSERT INTO ODS_LOGPROCESO VALUES ( NRO_PROCESO, NOM_PROCESO, SYSDATE, SYSDATE, 0, NULL, V_FECHA_EXTRACCION, 0, 0 ); COMMIT; FOR REG1 IN C1 LOOP BEGIN UPDATE ods_servsupl SET des_servsupl = REG1.des_servsupl , cod_servicio = REG1.cod_servicio , cod_nivel = REG1.cod_nivel ,
MISC-03-1-9
205
fec_inicio = REG1.fec_inicio , fec_fin = REG1.fec_fin WHERE cod_servsupl = REG1.cod_servsupl; commit; EXCEPTION WHEN NO_DATA_FOUND THEN RESULTOUT := 'COMPLETE:REJECTED'; EXIT; WHEN OTHERS THEN RESULTOUT := 'COMPLETE:REJECTED'; EXIT; END; CONTADOR := CONTADOR + 1; END LOOP; SELECT COUNT(1) INTO ACTUALIZADOS FROM ods_t_servsupl A WHERE 0 = (SELECT COUNT(1) FROM ods_servsupl WHERE cod_servsupl = A.cod_servsupl); BEGIN INSERT INTO ods_servsupl SELECT cod_servsupl, des_servsupl, cod_servicio, cod_nivel, fec_inicio, fec_fin FROM ods_t_servsupl A WHERE 0 = (SELECT COUNT(1) FROM ods_servsupl WHERE cod_servsupl = A.cod_servsupl); commit; EXCEPTION WHEN DUP_VAL_ON_INDEX THEN RESULTOUT := 'COMPLETE:REJECTED'; WHEN NO_DATA_FOUND THEN RESULTOUT := 'COMPLETE:REJECTED'; WHEN OTHERS THEN RESULTOUT := 'COMPLETE:REJECTED'; END; resultout := 'COMPLETE:APPROVED'; UPDATE ODS_LOGPROCESO SET FEC_FIN = SYSDATE, ESTADO = 1, PROCESADOS = CONTADOR, ACTUALIZADOS = ACTUALIZADOS WHERE NOM_PROCESO = NOM_PROCESO AND SECUENCIA = NRO_PROCESO; COMMIT;
MISC-03-1-9
206
EXCEPTION WHEN OTHERS THEN UPDATE ODS_LOGPROCESO SET FEC_FIN = SYSDATE, ESTADO = 2, PROCESADOS = CONTADOR, ACTUALIZADOS = ACTUALIZADOS WHERE NOM_PROCESO = NOM_PROCESO AND SECUENCIA = NRO_PROCESO; COMMIT; --END; END; /* Este procedimiento devuelve un boolena true o false */ procedure BORRAR_TABLA_T( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ) is C NUMBER; N NUMBER; BEGIN c:= dbms_sql.open_cursor; dbms_sql.parse(c, 'Truncate Table ODS_T_SERVSUPL', dbms_sql.native); --dbms_sql.bind_variable(c, '1', amount); n := dbms_sql.execute(c); dbms_sql.close_cursor(c); RESULTOUT := 'COMPLETE:T'; EXCEPTION WHEN OTHERS THEN DBMS_SQL.CLOSE_CURSOR(c); RESULTOUT := 'COMPLETE:F'; END; END; --FINAL DEL PACKAGE BODY /
Flujos de Trabajos Existen dos Grandes Flujos de Trabajo: Cargue Inicial y Actualización. Así mismo cada uno de ellos se subdivide en Flujos de Trabajos asociados a las pertenecientes al ODS.
Flujo de Cargue Inicial
MISC-03-1-9
207
El cargue inicial comprende cada uno de los subprocesos de cargue de las tablas sencillas. Posteriormente a ellas se ejecutan algunos procesos de Joins y Filtros sobre las tablas que permitirá enlazar los procedimientos. Cada uno de ellos tiene una respuesta de Aprobado o Rechazado. Lo cual permitirá que el cargue de la información sea totalmente consistente. En cada de alguna respuesta de Rechazo el sistema generará un fin del proceso principal.
Cargue inicial de tabla
En este proceso genérico de cargue de una tabla. Se realizan tareas de validación de la fuente desde la cual se cargará la información. Se realiza el proceso de cargue y posterior verificación del proceso. Solo existe una Respuesta de Aprobado y dos de Rechazo.
MISC-03-1-9
208
División de una tabla según la condición de Filtro
En este proceso genérico de filtro de una tabla. Se realizan tareas de validación de la fuente desde la cual se cargará la información. Se realiza tres subprocesos de filtro para la generación de tres tablas. Si alguno (Utilización del OR) de ellos falla se envía a la respuesta de Rechazo. Si los tres terminan (Utilización del AND) correctamente se envía una respuesta de Aprobación.
MISC-03-1-9
209
Flujo de Trabajo de Actualización Este flujo de Trabajo es similar al de cargue Inicial solo que cambian los primeros procedimientos asociados a la actualización. El proceso de actualización comprende cada uno de los subprocesos de actualización de las tablas sencillas. Posteriormente a ellas se ejecutan algunos procesos de Joins y Filtros sobre las tablas que permitirá enlazar los procedimientos. Cada uno de ellos tiene una respuesta de Aprobado o Rechazado. Lo cual permitirá que la actualización de la información sea totalmente consistente. En cada de alguna respuesta de Rechazo el sistema generará un fin del proceso principal.
MISC-03-1-9
210
Proceso de Actualización
En este proceso genérico de actualización de una tabla. Se realizan tareas de validación de la fuente desde la cual se cargará la información. Se realiza el proceso de actualización y posterior verificación del proceso. Solo existe una Respuesta de Aprobado y tres de Rechazo.
MISC-03-1-9
211
ANEXO 10.8 DISEÑO DE LA INTERFAZ PARA ACCESO AL ODS Y A LOS
METADATOS ID del Documento: DI-001 Nombre del documento: Diseño de la Interfaz para acceder al ODS y a los Metadatos Nombre del Proyecto: Integración de los Servicios de Abonados Áreas o Sistemas Afectados: Servicio al Cliente y Ventas Responsables: Nombre del Líder Usuario
Nombre del Líder de IT Nombres de los Ingenieros de IT Nombres de los Analistas de Información
Prioridad x Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión Inicial Diseño de la Interfaz para acceder al ODS y a los Metadatos
DISEÑO DE LA INTERFAZ PARA ACCESO AL ODS Y A LOS METADATOS
Tabla de Contenido Objetivo...............................................................................................................................................212
Pantallas Propuestas ......................................................................................................................212
Menú de Interface del ODS .........................................................................................................212 Parámetros de Configuración del ODS......................................................................................212 Consulta de la tabla de Logs.......................................................................................................213 Ejecución de Consultas al ODS..................................................................................................214 Interfaz para ejecución de Procesos de cargues al ODS a través de Oracle Workflow....215
Pantalla para acceder al Workflow Monitor..........................................................................215 Pantalla para buscar un proceso ...........................................................................................215 Pantalla para verificar la ejecución de un proceso en forma grafica................................216
MISC-03-1-9
212
Objetivo En el presente documento se describen las pantallas propuestas para las interfaces que permitirá a los usuarios del sistema ODS, ejecutar sus consultas y verificar los resultados. Así mismo permitirá conocer los parámetros propios del ODS.
Pantallas Propuestas A continuación se establecen las pantallas para acceder a la información del ODS.
Menú de Interface del ODS Esta es la pantalla del menú principal del ODS. En ella se establecen las opciones básicas para acceder a la Información del Repositorio.
Parámetros de Configuración del ODS En esta pantalla se establecen todos los parámetros asociados con el cargue de la Información hacia el ODS. Por medio de estos parámetros se puede cambiar la forma en que se actualiza la información. Es decir, de cierta manera el sistema es parametrico. Dentro de esta pantalla podrá saber el usuario la ultima fecha de cargue del ODS. Sabrá así mismo la próxima fecha de cargue del ODS. Puede tener información asociada a la periodicidad de cargue de información.
MISC-03-1-9
213
Consulta de la tabla de Logs Por medio de la siguiente pantalla el usuario podrá conocer en forma grafica el estado de los procesos ETL que se ejecutan periódicamente para actualizar la información del ODS. Tendrá acceso a los datos de cuantos registros fueron procesados. Si se desea una información correspondiente a las notificaciones o si se desea una visión grafica de estos procesos debe remitirse a las pantallas de Workflow Monitor, las cuales se describen posteriormente.
MISC-03-1-9
214
Ejecución de Consultas al ODS La siguiente pantalla permite la ejecución de las consultas ante el Repositorio. Para poder realizar estas consultas se debe poseer conocimientos básicos para ejecutar las consultas sobre el repositorio mediante sentencias SQL estándar.
MISC-03-1-9
215
Interfaz para ejecución de Procesos de cargues al ODS a través de Oracle Workflow A través de Workflow Monitor se permitirá acceder a todas las Interfaces para conocer las Estadísticas de Ejecución de los procesos de Cargues, así como de las actualizaciones. Dentro de esta interface se podrá conocer las Notificaciones y el Estado en forma Grafica de los procesos de ETL.
Pantalla para acceder al Workflow Monitor
Pantalla para buscar un proceso
Esta pantalla permitirá buscar un proceso de ETL particular, es decir permitirá acceder a cada uno de los procesos de las tablas simples, o a los procesos complejos de Integración de diferentes tablas e incluso poder visualizar todos el proceso de actualización en un solo gráfico.
MISC-03-1-9
216
Pantalla para verificar la ejecución de un proceso en forma grafica
La siguiente pantalla podrá visualizar los procesos escogidos en el punto anterior. Permite ver gráficamente el estado de un proceso en particular y su transcurrir dentro del flujo de trabajo.
MISC-03-1-9
217
ANEXO 10.9 FORMATO CHEQUEO DE PRUEBAS
ID del Documento: CHKPR-001 Nombre del documento: Documento de Chequeo de Pruebas Nombre del Proyecto: Integración de los Servicios de Abonados Áreas o Sistemas Afectados: Servicio al Cliente y Ventas Responsable: Nombre del Líder Usuario
Nombre del Líder de IT Nombres de los Ingenieros de IT Nombres de los Analistas de Información
Prioridad X Alta Media Baja Control de Versiones del Documento
Versión Fecha Descripción Cambio
1.0 dd/mm/yyyy Versión inicial del Documento de Chequeo de Pruebas
FORMATO CHEQUEO DE PRUEBAS Tabla de Contenido
Datos Generales........................................................................................................ 218 Completitud De Entidades........................................................................................ 218 Completitud De campos ........................................................................................... 218 Lista de Chequeo ...................................................................................................... 218
Cargue de las tablas Maestras............................................................................... 218 Actualización de las tablas ................................................................................... 219 Verificación de las Interfaces ............................................................................... 220
MISC-03-1-9
218
Datos Generales A continuación dentro del documentos se plantean una serie de puntos que deben revisarse para dar visto bueno sobre las Pruebas y posibilitar el paso a producción del Software propuesto.
Completitud De Entidades Se validan las Entidades cargadas versus sus consultas.
Entidades Consultas
Servicios Abo Abonados Entidad 3 Entidad m Completitud de Entidades ( Completa o Incompleta)
CO-001 X X Completa CO-002 X X Completa
Completitud De campos Se validan cada una las entidades y sus campos versus las consultas o Reportes solicitados.
Entidad Campos CO-001 CO-002 ... Consulta n Servicios Abo Campo 1 X X
Entidad 1 Campo 2 X X Entidad 1 Campo n X X Entidad 2 Entidad 2 X X Entidad 2 Campo 1 X X Entidad 2 Campo 2 X X
Entidad m Campo n X X
Lista de Chequeo Se realiza un chequeo de cada uno de los procesos de Cargues. Validando en cada uno de ellos si se realizaron correctamente las siguientes tareas:
• Validar Existencia de la Fuente sea Archivo o Tabla • Cargue de la tabla • Escritura en la tabla de Log
Cargue de las tablas Maestras
Entidad Valido
correctamente existencia de
Fuente Origen
S/N
Cargo todos
los datos que
debía cargar en la
Envío de Notificaciones
en caso de Fallas
S/N
Escritura en el Log
S/N
Aprobado
S/N
MISC-03-1-9
219
tabla destino
S/N
ODS_SERVSUPL S S S S S
ODS_PLANSERV S S S S S ODS_PLANTARIF S S S S S ODS_PTARIF_PSERVICIOS S S S S S ODS_SERVSULPLS S S S S S ODS_ABONADO S S S S S ODS_TEMP_SERV S S S S S
ODS_TEMP_SMS S S S S S
ODS_TEMP_ABO_CON_SMS S S S S S ODS_TEMP_ABO_CON_VOICE S S S S S ODS_TEMP_SERV_SMS S S S S S ODS_TEMP_SERV_VOICE S S S S S ODS_TEMP_SERV_ABO_SMS S S S S S ODS_TEMP_SERV_ABO_VOICE S S S S S ODS_SERVICIOS_ABO S S S S S Actualización de las tablas
Para cada una de las actualizaciones se revisa los procesos de actualización.
Entidad Valido correctamente existencia de
Fuente Origen
S/N
Cargo todos
los datos que
debía cargar en la tabla
destino S/N
Envío de Notificaciones
en caso de Fallas S/N
Escritura en el Log
S/N
Aprobado
S/N
ODS_SERVSUPL S S S S S
ODS_PLANSERV S S S S S ODS_PLANTARIF S S S S S ODS_PTARIF_PSERVICIOS S S S S S ODS_SERVSULPLS S S S S S ODS_ABONADO S S S S S ODS_TEMP_SERV S S S S S
ODS_TEMP_SMS S S S S S
ODS_TEMP_ABO_CON_SMS S S S S S ODS_TEMP_ABO_CON_VOICE S S S S S ODS_TEMP_SERV_SMS S S S S S ODS_TEMP_SERV_VOICE S S S S S ODS_TEMP_SERV_ABO_SMS S S S S S ODS_TEMP_SERV_ABO_VOICE S S S S S ODS_SERVICIOS_ABO S S S S S
MISC-03-1-9
220
Verificación de las Interfaces
Por cada una de las pantallas propuestas en el Diseño de las Interfaces, se realiza un chequeo de los siguientes puntos:
• Despliega la Información correctamente • Cumple con las características de la Interfaz solicitada
Interfaz Despliega la información
correctamente S/N
Cumple con las características de la
Interfaz solicitada S/N
Aprobado
S/N
Pantalla Ejecución de Consultas S S S
Pantalla Menú Principal S S S Pantalla Consultas de Logs S S S Pantalla Parámetros del ODS S S S
Puesta en producción Después que toda la etapa de Pruebas ha salido completamente exitosa, se procede a trabajar en la implementación del desarrollo, en este punto se debe tener en cuenta los nuevos objetos que se deben crear en las Bases de Datos, así como también el paso de los programas de Software. Posterior a la implementación se debe realizar una labor de seguimiento para revisar el desempeño de estos sistemas.