Propuesta metodológica para la implementación de un almacén de datos operacionales-ODS

Texto completo

(1)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.

(2) 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.

(3) 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.

(4) 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.. iv.

(5) 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.. v.

(6) MISC-03-1-9. TABLA DE CONTENIDO. INTRODUCCIÓN ............................................................................................................. 11 1. OBJETIVOS ............................................................................................................. 13 1.1 1.2. 2. OBJETIVO GENERAL ....................................................................................... 13 OBJETIVOS ESPECIFICOS.............................................................................. 13. HETEROGENEIDAD DE BASES DE DATOS........................................................... 14 2.1 2.2 2.3. ¿POR QUÉ SE DEBE INTEGRAR LAS DISTINTAS BASES DE DATOS?........ 14 INTEROPERABILIDAD Y FALTA DE INTEGRACION ....................................... 16 DEFINICIÓN DEL PROBLEMA ......................................................................... 19. 3. ALCANCE................................................................................................................. 21. 4. ESTADO DEL ARTE................................................................................................. 22 4.1 POSIBLES SOLUCIONES AL PROBLEMA DE LA INTEGRACIÓN DE DATOS 22 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 5.2. 6. COMPARACIONES ENTRE TECNOLOGÍAS PROPUESTAS .......................... 40 CONCLUSIONES DE LAS SOLUCIONES PROPUESTAS ............................... 41. ¿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 vi.

(7) MISC-03-1-9. 7.1.1 7.1.2 7.1.3 7.1.4 8. Metodología de Minería de Datos: El ciclo virtuoso.................................... 53 Metodología de Modelamiento Dot ............................................................. 57 Metodología de Desarrollo de un ODS ....................................................... 66 Análisis de Metodologías relacionadas con DW y Minerías de Datos ......... 68. PROPUESTA METODOLÓGICA PARA LA IMPLEMENTACION DE UN ODS......... 71 8.1 8.2 8.3. ANALISIS Y DISEÑO......................................................................................... 72 DESARROLLO ................................................................................................ 108 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. vii.

(8) MISC-03-1-9. 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 -. 133. Integración de Servicios en una empresa de Telecomunicaciones.. viii.

(9) MISC-03-1-9. 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. Figura No. 12 : Grafo de Flujo de Procesos para el Cargue Inicial de Tablas de Hechos en un ODS. Figura No. 13 : Diagrama de Flujo de Procesos para el Cargue Inicial de Tablas Maestras en un ODS. Figura No. 14 : Grafo de Flujo de Procesos para el Cargue Incremental de Tablas Maestras en un ODS.. 90. 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. ix. 93 93 96.

(10) MISC-03-1-9. LISTA DE TABLAS Pág.. Tabla No. 1. Cuadro comparativo entre Tecnologías Propuestas para solucionar 41 la Integración de Información. Tabla No. 2. Análisis de distintas metodologías relacionadas con Bodegas de. 69. Datos y Minería de datos. 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. x.

(11) MISC-03-1-9. 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.. xi.

(12) MISC-03-1-9. 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. 11. La.

(13) MISC-03-1-9. 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.. 12.

(14) MISC-03-1-9. 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. 9. 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.. 9. 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.. 9. Establecer una interfaz grafica al usuario que le permita realizar la consulta de información sobre el Almacén de Datos Operacionales.. 13.

(15) MISC-03-1-9. 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.. 14.

(16) MISC-03-1-9. 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 15.

(17) MISC-03-1-9. 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 16.

(18) MISC-03-1-9. 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 17.

(19) MISC-03-1-9. 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.. 18.

(20) MISC-03-1-9. 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.. 19.

(21) MISC-03-1-9. •. 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.. 20.

(22) MISC-03-1-9. 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.. 21.

(23) MISC-03-1-9. 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). 22.

(24) MISC-03-1-9 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 varias federaciones.. Sistemas de una sola federación. 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. componentes puede ser distintos o no entre sí.. Cada uno de estos sistemas. 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. heterogeneidad.. 23. Esto obviamente crea un problema de.

(25) MISC-03-1-9. 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). 24.

(26) MISC-03-1-9. 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]. 25.

(27) MISC-03-1-9. 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. continuación se realizará un resumen correspondiente a cada uno de estos trabajos.. 26. A.

(28) MISC-03-1-9. 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.. 27.

(29) MISC-03-1-9. 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.. 28.

(30) MISC-03-1-9. 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.. 29.

(31) MISC-03-1-9. 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. 30.

(32) MISC-03-1-9. ¾ 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.. 31.

(33) MISC-03-1-9. 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 32.

(34) MISC-03-1-9. 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. 33.

(35) MISC-03-1-9. 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. 34.

(36) MISC-03-1-9. 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. 35.

(37) MISC-03-1-9. 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 36.

(38) MISC-03-1-9. 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:. 37.

(39) MISC-03-1-9. ¾ 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.. Integration Transformation. Aplications. Data marts. Enterprise DW. ODS. Figura No. 6 : Flujo de Información desde Sistemas Operacionales hacia Repositorios Corporativos. Tomado de Inmon (1999). 38.

(40) MISC-03-1-9. 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.. 39.

(41) MISC-03-1-9. 5.1 COMPARACIONES ENTRE TECNOLOGÍAS PROPUESTAS Sistemas a Analizar Multibases de • Datos. Características. 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. Data Warehouse - • Orientada al Sujeto • Bodega de datos • 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. ODS – Almacén • Orientada al Sujeto • de Datos • Integrada Operacionales • Volátil, cada vez • que hay cambio se debe reflejar en el ODS. • Datos actuales, de •. Ventajas 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.. Desventajas •. • • •. •. 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.. 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. 40. 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. 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.. Se debe tener en cuenta el costo de implementar un ODS y ver sus ventajas corporativas en la organización..

(42) MISC-03-1-9. • •. 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 41.

(43) MISC-03-1-9. 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.. 42.

(44) MISC-03-1-9. 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.. 43.

(45) MISC-03-1-9. 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.. 44.

(46) MISC-03-1-9. 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. 45.

(47) MISC-03-1-9. 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.. 46.

(48) MISC-03-1-9. 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.. 47.