1 Sistemas de Bases de Datos Federadas para la Gestión de la Información

Transcripción

1 1 Sistemas de Bases de Datos Federadas para la Gestión de la Información La creciente necesidad de cooperación entre entidades independientes requiere el acceso integrado a múltiples bases de datos autónomas y heterogéneas, es decir, acceder a los datos como si de una sola fuente de datos se tratase. Esta colección de bases de datos cooperativas, conocidas como Sistemas de Bases de Datos (SBD) componentes, forman una federación y el software encargado de gestionarlas recibe el nombre de Sistema de Bases de Datos Federadas (SBDF) (Sheth & Larson, 1990). El trabajo de grado trata acerca del estudio, investigación y comprensión del paradigma del SBDF, además de la arquitectura subyacente, los enfoques de gestión de datos y la implementación en un caso de estudio real. 1.1 Alcance y Delimitación El trabajo presenta los diferentes elementos implicados para implantar y poner en marcha un SBDF para la gestión de la información. Para ello, se espera implementar un SBDF en un caso de estudio real y evaluar los resultados obtenidos. 1.2 Antecedentes En la década del 90 surgió la necesidad de acceder a diversas fuentes de datos, para gestionar la información almacenada en las mismas. A partir de entonces, se ha buscado poder acceder con una perspectiva única a todas las fuentes. El acceso a la información de todas las fuentes de datos, se logra de las siguientes maneras: accediendo separadamente a cada fuente de datos e integrando manualmente la información creando una nueva fuente de datos que integre las preexistentes implantando un Data Warehouse construyendo un SBDF en el que las bases de datos interoperen. De todas las especificadas, ésta última es la solución propuesta en este trabajo de grado y las demás sólo serán referidas a lo largo del mismo.

2 2 Justificación Un SBDF es capaz de gestionar información almacenada en diversas fuentes de datos heterogéneas, sobre distintas plataformas y en varias ubicaciones. Conforme a lo indicado anteriormente, se aprecia la importancia de llevar a cabo la exposición y la implementación de un SBDF. El trabajo contribuirá con fundamentos útiles sobre todo lo relativo a la implementación de un SBDF y su recepción en el ámbito local. 3 Planteamiento Algunas organizaciones como la Dirección General de Información Estratégica en Salud (DIGIES), órgano dependiente del Ministerio de Salud Pública y Bienestar Social (MSPyBS), se identifican por su heterogeneidad, ya que se componen de diferentes fuentes de datos, las cuales están planteadas de forma independiente y operan de manera autónoma empleando distintos esquemas. De esta manera debido a las diferencias tecnológicas, existe una gran diversidad en cuanto a hardware, a software y a sistemas operativos. Estas organizaciones constituyen un claro ejemplo de SBDF, en el que se garantiza la gestión de las transacciones y se preserva la autonomía de cada fuente de datos, frente al sistema completo. La implementación de un SBDF suministrará a los usuarios la posibilidad de acceso a información múltiple, localizada en diferentes fuentes de datos heterogéneas (bases de datos, archivos indexados, etc.), para obtenerla cuando se requiera. Presenta a los usuarios una vista, como si fuera una sola base de datos, que contiene toda la información. Un SBDF posee la capacidad de atender consultas globales, al mismo tiempo permite que el SBD componente siga atendiendo a sus aplicaciones locales, transparentando las operaciones de distribución para el usuario. Esta tecnología es de un aprendizaje e implementación viable, por lo cual requiere mayor difusión en el ámbito informático local. Implementar un SBDF en una organización, como la DIGIES, no demanda una gran inversión, ya que se estarían utilizando recursos disponibles para gestionarlas. 4 Marco Operativo Pregunta de investigación Cómo gestionar y recoger información con una respuesta única, de modo que en la preparación de la misma, intervengan datos de múltiples fuentes autónomas?

3 4.1.2 Experimentación El trabajo de grado se realizará en fases para la mejor recepción de resultados: 1. Recopilación de información sobre los SBDF. 2. Relevamiento de la heterogeneidad presentada en el caso de estudio. 3. Construcción del SBDF. 4. Ejecución de pruebas del SBDF hasta el desempeño esperado del mismo. 5. Evaluación de resultados. 6. Conclusiones Recursos necesarios Se necesitan recursos humanos que apoyen la implementación del SBDF en la DIGIES, ideal un DBA de la entidad. En cuanto a hardware, es necesario contar con un equipo informático donde realizar un prototipo del SBDF, además de otro donde montarlo para el caso de estudio. Igualmente es imprescindible tener acceso a internet, para poder recoger información necesaria acerca de los SBDFs y su implementación Cronograma de trabajo Primera fase: reunir toda la información posible a través de sitios web, libros de autores, artículos científicos, etc. para lograr un conocimiento más amplio acerca de un SBDF. Segunda fase: recopilar información minuciosa acerca de las distintas fuentes de datos disponibles en el caso de estudio y del hardware, software y sistemas operativos relacionados con cada una. Tercera fase: proceder a la implementación del SBDF, aplicando las herramientas de software escogidas. Cuarta fase: emplear el SBDF construido para comprobar su funcionamiento en el contexto real. Quinta fase: elaborar y presentar una sinopsis con todos los resultados logrados en la construcción del SBDF. Sexta fase: ejecutar las mejoras necesarias al trabajo de grado y generar un resumen de todo lo estudiado en el mismo.

4 5 Estado del Arte El principal reto trazado al inicio del trabajo, radica en la integración de información heterogénea dispersa en diferentes fuentes de datos, dentro de las organizaciones. Para resolver parte de este problema, existe una tendencia a la unificación de las fuentes de datos heterogéneas. Seguidamente, se verán las potenciales soluciones a la heterogeneidad de la información dentro de las organizaciones. 5.1 Posibles Soluciones La idea de un SBDF nace de una consulta, cuya respuesta demanda acceder a diversas fuentes de datos, no obstante, para la gestión de la información integrada existen otras soluciones. A continuación, se manifiestan y comparan las posibles soluciones Acceso separado e integración manual El acceso separado a las fuentes de datos y su posterior integración manual, es factible, pero sólo muy excepcionalmente. Para llevar a cabo esta solución existen varios puntos muy indispensables a tener en cuenta, como los son: el poseer conocimientos sobre la accesibilidad de las fuentes de datos el reconocer qué datos hay en cada fuente de datos el saber descomponer la consulta, en consultas parciales a cada fuente de datos el conocer el modelo de cada fuente de datos el estar al corriente, perfectamente, del lenguaje de cada fuente de datos el saber cómo integrar los resultados parciales obtenidos, para producir el resultado final esperado Integración de datos En la integración de datos, en aras de una gestión única, la gestión autónoma de cada fuente de datos se pierde. Establecer una nueva fuente de datos, que contenga la totalidad de los datos de las preexistentes, obliga a: diseñar una nueva fuente de datos (eventualmente un SBDD) convertir todos los programas implicados

5 migrar la totalidad de los datos de las fuentes anteriores, a la creada preparar e instruir en los nuevos modos de trabajar, a los usuarios Acceso integrado Lograr que las fuentes de datos interoperen (consiguiendo un acceso integrado) obliga superponer un sistema nuevo sobre los SBDs existentes e incluso, sobre datos estructurados como los almacenados en archivos de texto, XML, etc. Este nuevo sistema es ideal para nuestra propuesta, ya que: acepta la consulta y devuelve la respuesta: generando internamente las consultas parciales e integrando sus respuestas es transparente al usuario, así los programas y usuarios previos no se ven afectados logra la integración y preserva la autonomía de cada fuente de datos es flexible, puesto que la flexibilidad es análoga a la autonomía con respecto a la posibilidad de añadir más fuentes de datos (una vez concebida la solución). 6 Solución Propuesta El grado en que se conserva la autonomía de las fuentes de datos precedentes, es una de las principales diferencias entre las soluciones, cualquiera de ellas, debe superar dificultades técnicas significativas. Esta autonomía se pierde por completo en la integración de datos, se protege enteramente en la integración manual y se puede hablar de estados intermedios, en una implementación de un almacén de datos. En el acceso integrado se satisface una interoperabilidad entre las fuentes de datos. Esta solución presenta dos tipos de usuarios: un usuario administrador, que distingue la totalidad de las fuentes y otro, que sólo diferencia una sola. La misma está compuesta de dos niveles como mínimo: un nivel componente y otro federado, donde el primero incorpora a las fuentes de datos (o SBDs componentes) y el segundo al conjunto de fuentes que interoperan (SBDF). Un acceso compuesto preserva la autonomía de cada fuente de datos, permite la evolución de la solución instaurada, presenta gran flexibilidad y posee una alta viabilidad de efectuarse eficientemente.

6 6.1 Acceso integrado mediante un SBDF El acceso integrado se origina cuando los componentes se federan para dar lugar a un SBDF. Actualmente existe una necesidad de acceder a información integrada, desde varias fuentes de datos y en tiempo real. Una analogía, entre la situación actual y la situación de los años 60 s en adelante sobre las necesidades de gestión de la información, se expresa en la Tabla 1. Tabla 1. Comparativo de necesidades tecnológicas en la organizaciones. Demanda 60 s en adelante 90 s a la actualidad Fuentes de Proliferación de ficheros en Propagación de SBDs en datos una organización múltiples organizaciones Necesidad La integración de ficheros Una federación de SBDs Resultado SBDs SBDFs Tecnología BDs Interoperabilidad Tabla 1. Comparativo de necesidades tecnológicas en la organizaciones. En la actualidad varios modelos de federación están presentes en nuestro entorno (como la ONU, la Unión Europea, los Estados Unidos de América, entre otros) y no existe un modelo ideal. Éstos difieren en el poder del cuerpo de la federación, en la autonomía de sus componentes y su heterogeneidad. Dentro del área de BDs, también coexisten diversos enfoques y arquitecturas (ver Figura 1). 6.2 Implementaciones de SBDFs IBM Federated Database Haas & Lin (2002) detallan las capacidades de federación de IBM (International Business Machines), disponibles a través de una variedad de productos como: DB2 UDB, DB2 DataJoiner, DB2 Discovery, entre otros. Las herramientas mencionadas proporcionan facilidades para combinar la información de múltiples fuentes de datos, implementando así un SBDF. Señalan ciertas características principales y de las cuales se destacan: la transparencia, la heterogeneidad, el alto grado de función, la extensibilidad, la autonomía, el rendimiento optimizado, entre otros SQL Server Desde la versión de SQL Server 2005, existe la posibilidad de implementar un servidor de BDs federadas, a través de particiones horizontales. Esta práctica es empleada para grandes BDs que suponen una federación, como la forma de balancear el procesamiento aprovechando diferentes servidores. Cabe destacar que su construcción demanda de SBDs componentes marchando sobre SQL Server o servidores de SBDs que implementen la partición horizontal. Además, se muestra una capa de servidor federado que suministra ciertas diferencias internas a comparación con los servidores centralizados, como: la existencia de una instancia de SQL Server, ejecutándose en cada servidor miembro

7 un servidor miembro, con una BD miembro y datos propagados a través de las diferentes BD tablas de la BD original, particionada de manera horizontal en tablas miembro (consta de una tabla miembro por cada BD, las vistas particionadas y distribuidas son operadas para aparentar emplear una copia total de la tabla original en cada servidor) una capa de aplicación, concedida para encontrar sentencias SQL en el servidor miembro que contengan la mayoría de datos referenciados por la sentencia (Microsoft Corporation, 2013). En Microsoft Corporation (2013), expresan como diseñar servidores de BDs federadas. Se explayan, desde como estructurar las particiones y configurarlas para una alta disponibilidad, hasta cómo implementar servidores de BDs federadas (con vistas particionadas distribuidas o como modificar datos y realizar operaciones de copia de seguridad y restauración) MySQL, El motor de almacenamiento FEDERATED En MySQL, existe un motor de almacenamiento federado disponible desde la versión 5.0.3, el mismo permite acceder a datos en tablas de BDs remotas o locales en MySQL. Precisamente, se pueden implantar tanto para tablas federadas o remotas con la extensión.frm, como para tablas locales con la extensión.myd. La lectura de datos se efectúa mediante el aprovechamiento de una API cliente de MySQL, la cual recurre a un formato de esquema para la conexión entre tablas. El motor de almacenamiento federado de MySQL presenta algunas restricciones en su implementación: primeramente todos los servidores remotos deben ser MySQL, además no soporta transacciones, índices, ni cache de consultas o un ALTER TABLE y los BULK INSERT son muy lentos (Oracle Corporation, 2011) Oracle Buch (2002) expone que Oracle recurre a la arquitectura de clúster de disco compartido, por ende, no a las de BDs federadas. Explica que esta arquitectura se compone de servidores de un clúster interconectado, de un subsistema de disco compartido y que opera con una instancia de la BD ejecutada en cada componente. Además, afirma que las transacciones se ejecutan en cada instancia pudiendo leer y actualizar cualquier parte de la BD. Esta arquitectura es implementada en la solución llamada Oracle Real Application Cluster (Oracle RAC). En lo habitual, la comparación se asienta en que Oracle RAC manipula una manera sobresaliente las aplicaciones OLTP (Online Transaction Processing), mientras que los SBDFs presentan deficiencias con respecto al desarrollo de aplicaciones, la escalabilidad, la disponibilidad y la administración; estas características puntualmente son las que originalmente no se fían en cierto grado para SBDFs (Buch, 2002).

8 6.2.5 PostgreSQL SQL/MED (SQL/Management of External Data) es la gestión de datos externos a PostgreSQL y se vale de una parte del estándar SQL, el cual se ocupa de cómo un SGBD puede integrar datos almacenados fuera de una BD. La implementación de esta especificación se inició en PostgreSQL 8.4, con el tiempo se introdujo nuevas y potentes funciones dentro de PostgreSQL. Conjuntamente, varias características básicas como el soporte a tablas externas se han agregado en PostgreSQL 9.1. En SQL/MED existen dos tipos de componentes: tabla externa, un método de acceso transparente para datos externos enlace de datos o DATALINK, un tipo especial de SQL que pretende almacenar direcciones URL (Uniform Resource Locator) en una BD (PostgreSQL wiki, 2012). Datalink permite almacenar direcciones URL y funciones en columnas de BD (explotadas en las consultas SQL). Cabe enfatizar, que no existen muchos SGBD relacionales que implementen enlaces de datos SQL/MED (aunque IBM DB2 es uno, por ejemplo) y gran parte de ella se delimita por el estándar SQL para una implementación específica. Tampoco se halla un número considerable de software que demande el uso de enlaces SQL/MED, no obstante, existen funcionalidades sobre archivos, direcciones URL y web que frecuentemente son deseadas en aplicaciones concretas: como por ejemplo, las que exijan vincular diversas fuentes de datos (PostgreSQL wiki, 2010). DBI-Link es una implementación parcial de la porción SQL/MED (DATALINK particularmente) de la especificación SQL:2008, escrita en lenguaje PL/PerlU (valiéndose de Perl para enlazar datos externos) (PgFoundry, 2013). DBI-Link es puntualizada más adelante detalladamente, pues es la implementación empleada en el caso de estudio Otros Remote Exchange Fang, Hammer & McLeod (1992) presentaron un enfoque de frameworks, denominado Remote Exchange, que expone una perspectiva y un mecanismo para sobrellevar el intercambio del comportamiento entre los SBDs en una federación. Mencionan que el mismo, opera tres diferentes tipos de funciones: las funciones de almacenamiento, las funciones derivadas y las funciones computadas. Aseveran que la importancia de esta representación radica en la separación de la ubicación de los datos y de la ubicación de la ejecución de los métodos.

9 PEER Afsarmanesh, Wiedijk & Hertzberger, en el año 1994, desarrollaron un sistema federado de gestión de información orientado a objetos y lo denominaron PEER. Éste tolera el intercambio de información a través de componentes cooperativos, autónomos y heterogéneos, siendo su rasgo significativo la transparencia física y la lógica de la distribución de información de los SBDs componentes, por medio del procesamiento de consultas federadas. Manifiestan a su vez, que cada componente constituye su arquitectura en el esquema local (LOC), el esquema de importación (IMP), el esquema de exportación (EXP) y el esquema integrado (INT) Myraid Lim, Hwang, Srivastava, Clements & Ganesh (1995) realizaron un prototipo de SBDF, desarrollado por la Universidad de Minnesota, para satisfacer las fuentes de datos heterogéneos, las incompatibilidades a nivel de sistema y la falta de integración. Myraid, despliega una arquitectura flexible que consiente la gestión de transacciones y el procesamiento de consultas. 6.3 Gestor de la federación Según nuestro caso de estudio, DBI-Link es la herramienta de software más adecuada para implementar este SBDF, pues se ajusta al mismo, facilitando además, la integración a otros tipos de fuentes de datos no contempladas anteriormente. Éste permite el acceso a las siguientes fuentes de datos: DB2 e Informix Firebird Microsoft SQL Server Mimer SQL MySQL Oracle Database Sybase Microsoft Excel memoria caché CSV (Valores Separados por Comas) PostgreSQL (Fetter, 2010). DBI-Link, como lo implica su nombre, se vale de un módulo del lenguaje de programación Perl, denominando DBI (DataBase Interface), para vincular fuentes de datos y desplegarlas como tablas de PostgreSQL (Fetter, 2010).

10 Figura 1. Arquitectura de BDs según el contexto de un SBDF. Dentro de PostgreSQL existe un lenguaje procedural, denominado PL/Perl, que permite escribir ciertas funciones de PostgreSQL en el lenguaje de programación Perl, recurriendo así, a los múltiples operadores y muchas funciones disponibles en dicho lenguaje. PL/Perl puede ser instalado como un lenguaje de confianza, denominado PL/PerlU y de esta manera, el lenguaje Perl está disponible completamente en PostgreSQL (The PostgreSQL Global Development Group, 2013). DBI-Link utiliza PL/PerlU para aprovechar el total de funcionalidades ofrecidas por Perl, de esta manera logra enlazar los datos de otras fuentes de datos remotas, formando así un SBDF. Para establecer un SBDF, DBI-Link crea una BD con un esquema subyacente (a partir de un script de inicialización), nombrado dbi_link, conteniendo tablas, vistas de datos y funciones utilitarias. Las fuentes de datos remotas se integran en dicho esquema creado; para ello, se debe invocar a una función de inicialización llamada make_accessor_functions, encargada de crear un esquema diferente para cada fuente de datos vinculada. Esta función establece algunos objetos para cada tabla remota, como: una variable de una fila, relativa a una tabla ( rowtype ) una vista de datos ( view ), compuesta a su vez de: o una consulta ( select ) de la anterior variable de fila o reglas del DML (Lenguaje de Manipulación de Datos) escritas en una shadow table, mediante un disparador

11 6.4 Implementación del SGBDF ( trigger ) (el cual, efectúa las operaciones de escritura en las tablas remotas) (Fetter, 2010) Servidores para construir el SBDF Para comprobar las herramientas de software, precisamente DBI-Link, fue preciso montar servidores, emulando al caso de estudio propuesto (antes de implementar el SBDF, como tal). Con este fin, se apeló a la virtualización de los servidores necesarios, tanto él de federación como los de los SBDs componentes. La virtualización consiste en ejecutar múltiples sistemas operativos en máquinas virtuales establecidas sobre una máquina física, denominada anfitrión. Una máquina virtual se comporta, exactamente, igual a un equipo físico, contiene sus propios CPU, RAM (Random Access Memory), disco duro de almacenamiento y tarjetas de interfaz de red (todas ellas virtuales, por supuesto). A estas máquinas se las puede definir como contenedores de software, cuidadosamente aislados, capaces de implantar su propio sistema operativo y aplicaciones, como si fueran un equipo físico. Justamente, un sistema operativo no puede distinguir diferencia alguna entre una máquina virtual y una máquina física, ni tampoco lo pueden hacer las aplicaciones u otros ordenadores de una red (Oracle Corporation, 2013). Partiendo de estos conceptos, montaremos los servidores de SBDs (para los SBDs componentes) y el servidor del SBDF. Así, la virtualización resulta excelente para aplicarla al caso de estudio y para ello, se emplea Oracle VM VirtualBox. Oracle VM VirtualBox es una aplicación de virtualización, disponible para variadas plataformas. Su instalación es posible en equipos informáticos asentados en procesadores Intel o AMD. Los únicos límites prácticos que se presentan al emplear esta aplicación, son el espacio en disco duro de almacenamiento y la memoria RAM del equipo anfitrión. Puede funcionar en pequeños sistemas embebidos o máquinas de escritorio de cualquier tipo, hasta implementaciones de centros de datos e incluso entornos de nube. Esta aplicación se ejecuta en los sistemas operativos: Windows, Linux, Macintosh y Solaris (Oracle Corporation, 2013) Instalación y configuración de servidores virtuales En el caso de estudio se utiliza como sistema operativo anfitrión, un Windows 8, de 64 bits, sobre un equipo físico asentado en Intel. Este equipo cuenta con ocho GB de memoria RAM y 700 GB de capacidad en disco duro. Mediante Oracle VM VirtualBox, se montaron cuatro sistemas operativos invitados, donde los primeros albergan los SBDs componentes y el último al SBDF (ver Figura 2): Microsoft Windows Server 2003 Enterprise Edition

12 Ubuntu Fedora 15 CentOS 6. En líneas generales, la instalación de las máquinas virtuales, tanto como las del entorno Linux como la de Windows, resultaron muy posibles, excluyendo al CentOS 6. Esta máquina aloja al SBDF, la instalación tomó un poco más de tiempo que las demás, porque se instalaron y configuraron las bibliotecas involucradas para establecer sobre ella el gestor de la federación. A la par, se procedió a nombrar cada máquina virtual, a fin de identificarlas más simplemente (ver Tabla 2). Figura 1. Máquinas virtuales empleadas para la implementación del SBDF Figura 2. Máquinas virtuales empleadas para la implementación del SBDF. La razón de montar estas máquinas virtuales en particular, se basa en que, en el caso de estudio existe una gran variedad de sistemas operativos, ejecutándose sobre diversos equipos informáticos, con distintas configuraciones de hardware y software Instalación y configuración de motores de BDs SGBDs componentes En tres de las cuatro máquinas virtuales, se llevaron a cabo, la instalación y configuración de los SGBDs componentes. En MV1, se establecen dos SGBDs componentes; el primero, se trata de PostgreSQL en su versión 9.0, creada a partir del esquema físico de la siciap (provisto por la organización favorecida por el caso de estudio). La base de datos creada cuenta con 58 tablas, 30 secuencias y una vista en el esquema public. Para el segundo, se creó una

13 base de datos sobre Microsoft SQL Server Express 2008 R2, denominada server2003bd, compuesta por una sola tabla. Tabla 2. Máquinas virtuales utilizadas en el prototipo. Sistema Operativ o Windows Server 2003 Enterpris e Edition Ubuntu Fedora 15 CentOS 6.0 Plataform a Windows Linux Denominació n Windows Server 2003 Enterprise Edition o MV1 Ubuntu 11 o MV2 Linux Fedora 15 o MV3 Linux Centos 6 o MV4 Tabla 2. Máquinas virtuales utilizadas en el prototipo Alias Máquin a gris Máquin a violeta Máquin a verde Máquin a azul Memori a base 512 MB 20 GB 256 MB 10 GB 256 MB 15 GB 512 MB 8 GB Almacenamient o En MV2, se emplea la versión 9.0 de PostgreSQL y se crea la base de datos saa. La misma cuenta con 61 tablas y tres secuencias, bajo el esquema public (esto, de acuerdo al esquema proporcionado por la DIGIES). Por último, en MV3 se establece una base de datos llamada webdb, sobre MySQL 5.5, con una sola tabla de datos SGBDF El SGBDF utilizado en el caso de estudio, está basado sobre PostgreSQL en su versión 8.4, implementándose mediante la ejecución de DBI-Link. El SGBDF, se ejecuta sobre MV4. PostgreSQL es un SGBD objeto/relacional, es decir, tanto relacional como orientado a objeto, distribuido bajo licencia BSD (Berkeley Software Distribution) y con código fuente libre. Sus principales características son su robustez y potencia, se vale de un modelo cliente/servidor y emplea multiprocesos, en vez de múltiples hilos, para garantizar la estabilidad y consistencia del sistema (Martínez Guerrero, 2010) Instalación del SGBDF DBI-Link para poder construir un SBDF, requiere de PostgreSQL (por supuesto, instalado y en funcionamiento) en su versión o posterior. Además, es necesario poseer el lenguaje PL/PerlU montado sobre PostgreSQL y contar con un súper usuario ( postgres por default) o algún otro usuario, con los privilegios necesarios. Previo a esto, Perl (desde su versión 5.8) debe estar instalado en el servidor de la federación con los módulos: DBI, DBD y YAML (Fetter, 2010).

14 Perl DBI funciona con DBI-Link a partir de la versión DBI es el módulo de interfaz de base de datos estándar para Perl. Éste, define un conjunto de métodos, variables y convenciones proporcionando una interfaz de BD consistente e independiente de la real que se utiliza (Perl.org, 2013). DBD es exigido para cada tipo de fuente de datos remota a acoplar. Según nuestro caso de estudio, son necesarios los siguientes: DBD::Pg, trabaja con el módulo DBI para proporcionar acceso a BDs PostgreSQL DBD::Sybase, ligado al módulo DBI, suministra acceso a BDs Microsoft SQL Server y Sybase Database DBD::Mysql, combinado con el módulo DBI, facilita el acceso a BDs MySQL (Leffler, Wiedmann, Goeldner & Bunce, 2013). YAML es requisito para enlazar BDs con DBI-Link. YAML no es otro lenguaje de marcado, por su siglas en inglés YAML Ain't Markup Language, es una contribución internacional para crear un lenguaje de serialización de datos, explícito y de gran alcance de cómputo (Ben Kiki, Evans & döt Net, 2009). Una vez instalados todos los prerrequisitos, se puede proceder a la construcción del SBDF. Primero, se crea una BD donde DBI-Link operará, el nombre de la BD es alcance y para el resto de este documento, luego, como súper usuario se instala el lenguaje PL/PerlU, en alcance y por último, se ejecuta el fichero de instalación ( Dbi_link.sql ) para establecer los métodos subyacentes disponibles (escritos como funciones de PostgreSQL) (Fetter, 2010) Acoplar SBDs componentes al SBDF Cuestiones a tener en cuenta La conexión entre MV1 y MV4, se hace mediante SSL (Secure Sockets Layer) para acoplar el SBD componente establecido sobre PostgreSQL. Como no se puede realizar una conexión directa entre ambos servidores, debido a las medidas de seguridad aplicadas en plataformas Windows, se implementa SSL para compensar este inconveniente. Esta capa de sockets seguros o SSL, es un protocolo propuesto por Netscape, que permite la transmisión segura de información a través de computadoras (Shostack, 1995). Para Crall, Danseglio & Mowers (2003), los beneficios que SSL y TLS (Transport Layer Security) ofrecen para los clientes y los servidores, se basan en una autenticación fuerte, además de la privacidad e integridad de los datos, la interoperabilidad entre aplicaciones, la flexibilidad de algoritmos y una fácil implementación y uso. Sin embargo, indican que existen algunas desventajas de

15 emplear SSL y TLS, como el aumento de la carga del procesador y los gastos administrativos que involucra su gerencia. Se emplea OpenSSL (versión 0.9.8) en MV1, éste es un conjunto de herramientas de criptografía, que se vale de los protocolos de red SSL y TLS, como también de los estándares relacionados con la criptografía (The OpenSSL Project, 2009). Según Martínez Guerrero (2009), luego de la instalación de OpenSSL, para activar el soporte SSL en PostgreSQL, se deben realizar las siguientes tareas: definir el parámetro ssl en on, en el archivo postgresql.conf instalar el certificado del servidor, la clave privada correspondiente y el certificado de solicitud en el directorio de datos PGDATA, de MV1 reiniciar el servidor PostgreSQL configurar en el archivo pg_hba.conf, las conexiones que van a utilizar SSL, para cifrar el tráfico y autentificarse con un certificado digital (Ver Figura 3). Figura 2. Configuración de PostgreSQL para permitir conexiones SSL hostssl all all /0 trust Figura 3. Configuración de PostgreSQL para permitir conexiones SSL. En MV1, de igual manera es preciso configurar el otro SBD componente (montado sobre Microsoft SQL Server) para que pueda admitir conexiones desde MV4. Se deben configurar las conexiones TCP/IP (Protocolo de Control de Transmisión/Protocolo de Internet), desde el Administrador de configuración de SQL Server. Aquí, se indican las conexiones admitidas y el puerto donde se conectarán. En MV2, no es necesario utilizar SSL y TLS para establecer la conexión con MV4. Este servidor aloja al SBD componente establecido sobre PostgreSQL, sólo es preciso editar los archivos de configuración postgresql.conf y pg_hba.conf : en el primero, permitiendo la conexión remota al SBD y en el segundo, admitiendo las conexiones desde MV4. Al igual que en MV2, en MV3 solamente se requiere configurar los permisos necesarios para efectuar una conexión al SBD componente (el cual, está montado sobre MySQL). Para ello, se modifica el archivo my.cnf, específicamente en la sección [mysqld], en el parámetro bin-address, accediendo a las conexiones desde MV4. Aparte de lo anterior, se precisa configurar un usuario con permisos de conexión necesarios al SBD componente.

16 Cabe manifestar que en el trabajo se hace referencia a motores de base de datos que en su totalidad son transaccionales y relacionales, aunque es importante igualmente analizar otros tipos de fuentes, principalmente las arquitecturas emergentes, como las bases de datos en memoria o las orientadas a objetos. La integración de información, a través de las distintas fuentes de datos presentadas, es viable por medio de DBI-Link sin mucho apremio. Ahora bien para otras fuentes, como las emergentes mencionadas recientemente, ésta no tiene soporte para aquellas. Según lo expuesto, PL/Perlu permite extender o agregar nuevas funciones a DBI-Link para dar un soporte completo a otras fuentes de datos no contempladas por ella. Leffler et al. (2013) indican que por lo general, un controlador ya está disponible para casi todas las fuentes existentes. De la misma forma refieren que muy a menudo, la fuente de datos proporcionará una interfaz de controlador para ODBC, por lo que se puede emplear DBD::ODBC para accederla. Resaltan que esto es menos conveniente en una máquina Unix que en una de Microsoft Windows, pero que hay numerosas opciones para administradores de controladores ODBC en Unix también, y muy frecuentemente el controlador ODBC es proporcionado por el proveedor de base de datos. Según Leffler et al. (2013), no se recomienda la creación de un nuevo controlador de base de datos para DBI. Sin embargo, reconocen que existen ocasiones en que es necesario escribir un nuevo controlador, como por ejemplo para reducir el tiempo de acceso a la fuente o cuando la fuente no tiene soporte para OBDC Agregar fuentes de datos al SBDF Fetter (2010) define una serie de parámetros ajustados al motor de BD o de la aplicación gestora de la misma (por ejemplo Microsoft Excel, para archivos Excel), para poder acoplar un SBD componente al SBDF, mediante una función ( make_accessor_functions() ). Seguidamente, se detallan dichos parámetros necesarios para integrar un SBD componente a la federación: origen de datos, aquí se define la cadena de conexión a la fuente de datos a acoplar usuario de autenticación, se ingresa un usuario con los permisos necesarios para operar los datos remotos (obligatorio, sí se trata de un motor de BD) contraseña de autenticación, es la contraseña del usuario de autenticación atributos del manejador de la fuente de datos, aquí van atributos del SBD componente (por ejemplo, sí se van a imprimir o no, los errores generados por operaciones sobre ese SBD componente)

17 entorno del manejador de la fuente de datos, puede incluir diversos datos del entorno del SBD componente (como la plataforma, el sistema operativo, la red, la memoria RAM, la capacidad de disco duro de almacenamiento, entre otros) esquema remoto de la fuente de datos, es el esquema donde está definido el SBD componente (sólo incumbe a motores de BD) catálogo remoto de la fuente de datos, es el catálogo relativo al SBD componente (únicamente de poseer uno el motor de BD) esquema local del SBD componente, es la denominación única que recibirá esa fuente de datos dentro del SBDF. Para una mejor comprensión, se ejemplifica lo antes expuesto con un script, en la Figura 4, él mismo debe ser ejecutado en el SGBDF (en nuestro caso PostgreSQL + DBI-Link), sobre el SBDF (alcance, para el caso de estudio) Ejecutar operaciones sobre los SBDs componentes Las operaciones de acceso a datos en el SGBDF, emplean el lenguaje declarativo SQL. Estas operaciones son efectuadas para manipular los datos o actualizar la definición del SBD componente DML Para ejecutar una consulta, a un SBD componente, se utiliza la instrucción select, refiriéndose al esquema deseado y a las tablas implicadas. Esta misma consulta también puede incluir a otros SBDs componentes, mediante la relación de algún campo en común (como el número de identificación personal de una persona, por ejemplo). En la Figura 5, se ilustra una consulta de ejemplo, en la misma se instancia la vista consumidor, en el esquema siciap (correspondiente a un SBD componente) del SBDF alcance. En cada view, correspondiente a cada tabla en la fuente de datos integrada, están los lineamientos de los comandos DML ( insert, update y delete ), los cuales se insertan en una shadow table. Cada shadow table, emplea un disparador del tipo before insert, que ejecuta los comandos DML en la tabla remota (aunque, no escribe los datos en la shadow table en sí misma) (Fetter, 2010). Fetter (2010) manifiesta que cada shadow table se corresponde a una tabla remota y que se compone de 2n + 1 columnas (donde n, es el número de columnas de la tabla remota). Indica que las shadow table están dispuestas de la siguiente manera:

18 una columna perteneciente a las acciones posibles que pueden tomarse en la tabla remota ( I para inserciones, U para actualizaciones y D para eliminaciones) un conjunto de columnas que corresponden a los antiguos valores en la tabla otro conjunto de columnas correspondientes a los nuevos valores de la tabla. Figura 3. Script para agregar un SBD componente al SBDF De lo anterior se deduce, que para las eliminaciones, ambos conjuntos de columnas contienen valores NULL, para las inserciones, el conjunto de nuevos valores es completado y para las actualizaciones, ambos conjuntos poseen valores. /*verificar catálogo del SBDF*/ UPDATE pg_catalog.pg_settings SET setting = CASE WHEN 'dbi_link' = ANY (string_to_array(setting, ',')) THEN setting ELSE 'dbi_link,' setting END WHERE name = 'search_path' ; /* * Data source: dbi:dbd_perl:dbname=nombre_bd;host=nombre_o_ip_host;port=nro_puerto * User: usuario * Password: contraseña_usuario * dbh attributes: ej.: {AutoCommit => 1, RaiseError => 1} * dbh environment: datos_entorno_bd * remote schema: ej.: public para PostgreSQL * remote catalog: ej.: pg_catalog para PostgreSQL * local schema: nombre_sbd_componente */ SELECT make_accessor_functions ( 'dbi:pg:dbname=siciap;host= ;port=5432', 'postgres', 'postgres9', '--- AutoCommit: 1 RaiseError: 1 ', NULL, 'public', NULL, 'siciap' ); Figura 4. Script para agregar un SBD componente al SBDF.

19 Figura /*consulta 4. Script para de ejecutar datos*/ una consulta a un SBD componente desde el SBDF SELECT * FROM alcance.siciap.consumidor; Figura 5. Script para ejecutar una consulta a un SBD componente desde el SBDF DDL El DDL (Lenguaje de Definición de Datos) se encarga de la definición de las BDs. Sí en cualquier momento, el DDL del SBD componente es modificado, para actualizarlo se debe eliminar el esquema local del SBDF e invocar la función dbi_link.refresh_schema (ver Figura 6), ésta recibe como parámetro el identificador de la fuente de datos involucrada (Fetter, 2010). /*borrar esquema local*/ Figura DROP 5. Script SCHEMA para actualizar siciap la definición CASCADE; de un SBD componente /*ejecutar función de actualización*/ SELECT dbi_link.refresh_schema(data_source_id) FROM dbi_link.dbi_connection WHERE local_schema = 'siciap'; Figura 6. Script para actualizar la definición de un SBD componente. DBI-link se puede desinstalar ejecutando simplemente una instrucción drop, sobre el esquema dbi_link, en la base de datos alcance (ver Figura 7). No obstante, los prerrequisitos de DBI-Link no se desinstalan con esta operación. Es decir, que la BD alcance, el lenguaje PL/PerlU, Perl, sus módulos y el motor de BD (PostgreSQL) exigen desinstalarse cada uno por separado (Fetter, 2010). /*borrar DBI-Link*/ DROP SCHEMA dbi_link CASCADE; Figura 6. Script de desinstalación de DBI-Link 6.5 Caso de Estudio de la DIGIES Sobre la DIGIES Figura 7. Script de desinstalación de DBI-Link. La DIGIES se motivó en la necesidad de integrar la información fragmentada de diversas fuentes de datos, diseminadas en diferentes dependencias y con pocas facilidades de acceso, mediante una integración manual. Es decir, es considerada el instrumento institucional para el desarrollo de un sistema integral de información y análisis situacional en salud pública. Así, ella está comprometida en brindar la información en salud, necesaria para facilitar la planeación estratégica del sector en todos los niveles administrativos. Asimismo, el Sistema Nacional de Información en Salud (SINAIS) se compone de todos los sistemas de información propios de cada organismo que conforman el Sistema Nacional de Salud (SNS) en el Paraguay. El MSPyBS es la máxima autoridad

20 ejecutiva del Consejo Nacional de Salud y asume la responsabilidad correspondiente en este ámbito, desde la DIGIES y ella sobre el SINAIS (Ministerio de Salud Pública y Bienestar Social, Dirección General de Información Estratégica en Salud (DIGIES), 2013). La DIGIES cuenta con acceso a todas las fuentes de información en salud, tanto primarias como secundarias. Cabe destacar que ella tiene como objeto, supeditar el conocimiento que surge de la prestación de servicios y de la investigación en salud pública, con los virtuales usuarios de la misma. Sus principales políticas institucionales son esencialmente las siguientes: ejercer una rectoría desde el MSPyBS sobre el SINAIS originar, instalar y resguardar todas las fuentes de datos del sector salud avalar la publicación de la información para los diferentes grupos de interés (Ministerio de Salud Pública y Bienestar Social, Dirección General de Información Estratégica en Salud (DIGIES), 2013) Sistemas informáticos existentes En Ministerio de Salud Pública y Bienestar Social, Dirección General de Información Estratégica en Salud (DIGIES) (2013), se menciona la existencia de 15 sistemas informáticos administrados por la DIGIES (ver Tabla 3), como también de 13 portales Web activos (ver Tabla 4). Tabla 3. Sistemas Informáticos administrados por la DIGIES. Fuente: Ministerio de Salud Pública y Bienestar Social, Dirección General de Información Estratégica en Salud (DIGIES), Sistemas Informáticos Sistema de Información Geográfica de Establecimientos de Salud Sub-Sistema de Información de Estadísticas Vitales Sub-Sistema de Información de Servicios de Salud Área Ambulatoria Sistema de Movimiento Hospitalario Sistema de Egresos Hospitalarios Sistema de Información y Control de Inventarios Automatizado del Paraguay Sistema Informático de la Dirección General de Vigilancia de la Salud Sistema Experto de la Unidad de Salud de la Familia Sistema Experto del Programa Nacional de Control de la Tuberculosis Sistema Experto del Programa Nacional de Control de VIH/SIDA/ITS Sistema Integrado de Monitoreo de Adquisiciones Sub-Secretaria de Salud Siglas SIGEESS SSIEV SAA SMH SEGHOSP SICIAP SIDGVS USF PNCT PRONASIDA SIMA