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
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 4.1.1
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?
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. 4.1.3
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.
4.1.4
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.
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. 5.1.1
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.
5.1.2
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.1.3
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.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 Fuentes de datos Necesidad Resultado Tecnología
60’s en adelante 90’s a la actualidad Proliferación de ficheros en Propagación de SBDs una organización múltiples organizaciones La integración de ficheros Una federación de SBDs SBDs SBDFs BDs Interoperabilidad
en
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 6.2.1
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. 6.2.2
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
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). 6.2.3
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). 6.2.4
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).
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. 6.2.6
Otros
6.2.6.1 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.
6.2.6.2 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). 6.2.6.3 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).
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
(“trigger”) (el cual, efectúa las operaciones de escritura en las tablas remotas) (Fetter, 2010). 6.4 6.4.1
Implementación del SGBDF 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). 6.4.1.1 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”
“Ubuntu 11.04”
“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. 6.4.1.2 Instalación y configuración de motores de BDs 6.4.1.2.1 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
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 11.04
Plataform a
Denominació n
Alias
Memori a base
Almacenamient o
Windows
Windows Server 2003 Enterprise Edition o MV1 Ubuntu 11 o MV2
Máquin a gris
512 MB
20 GB
256 MB
10 GB
Fedora 15 CentOS 6.0
Linux
Máquin a violeta Fedora 15 o Máquin MV3 a verde Centos 6 o Máquin MV4 a azul
256 MB
15 GB
512 MB
8 GB
Linux
Linux
Tabla 2. Máquinas virtuales utilizadas en el prototipo
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. 6.4.1.2.2 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). 6.4.2
Instalación del SGBDF
DBI-Link para poder construir un SBDF, requiere de PostgreSQL (por supuesto, instalado y en funcionamiento) en su versión 8.1.19 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).
“Perl DBI” funciona con “DBI-Link” a partir de la versión 1.43. “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). 6.4.3
Acoplar SBDs componentes al SBDF
6.4.3.1 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
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.0.0.0/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.
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. 6.4.3.2 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)
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). 6.4.4
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. 6.4.4.1 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:
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=192.168.1.103;port=5432', 'postgres', 'postgres9', '--AutoCommit: 1 RaiseError: 1 ', NULL, 'public', NULL, 'siciap' );
Figura 4. Script para agregar un SBD componente al SBDF.
Figura 4. Script parade ejecutar una consulta a un SBD componente desde el SBDF /*consulta datos*/
SELECT * FROM alcance.siciap.consumidor; Figura 5. Script para ejecutar una consulta a un SBD componente desde el SBDF.
6.4.4.2 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*/ DROP SCHEMA siciap CASCADE; Figura 5. Script para actualizar la definición 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
Figura 7. Script de desinstalación de DBI-Link.
6.5 6.5.1
Caso de Estudio de la DIGIES Sobre la DIGIES
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
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).
6.5.2
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), 2013.
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
Sistema de Registros de Fondos de Equidad Sistema del Programa Nacional de Asistencia Alimentaria Nutricional Sistema Informático del Programa Ampliado de Inmunizaciones Sistema de Control de Profesionales de la Salud
SIRFE PROAN PAI SICPESSS
Tabla 3. Sistemas Informáticos administrados por la DIGIES
Según el relevamiento realizado en la DIGIES, la misma cuenta con una gran multiplicidad de fuentes de datos y una dilatada heterogeneidad de software y hardware. Exactamente, podemos encontrar diversos motores de bases de datos como PostgreSQL, MySQL o Microsoft SQL Server y algunos archivos de datos como Microsoft Excel o CSV. Estas fuentes de datos están asentadas sobre sistemas operativos Linux en su mayoría, aunque también las hay sobre Windows y FreeBSD (en resumen, todas corriendo en diversas plataformas). 6.5.3
Implementación del SGBDF
La implementación del SBDF para la gestión de la información disponible en la DIGIES, fue una tarea conjunta y apoyada por la Dirección de Tecnología e Informática de dicho organismo, puntualmente con el DBA. El servidor de la federación corre sobre Linux, Debian para ser claros. Para realizar la instalación del SGBDF, fue necesario replicar exactamente todo lo expuesto anteriormente, en el apartado de Solución Propuesta, en la sección de Implementación del SGBDF. Es necesario aclarar, que solamente es preciso replicar lo referente al SGBDF, no así lo relativo a los SBDs componentes, puesto que éstos, hoy existen y son operados diariamente (por supuesto, este caso es diferente al del prototipo implementado, donde si fue necesaria la virtualización). Tabla 4. Portales Web administrados por la DIGIES. Fuente: Ministerio de Salud Pública y Bienestar Social, Dirección General de Información Estratégica en Salud (DIGIES), 2013.
Portales Web Portal oficial del MSPyBS Correo oficial del MSPyBS Programa Nacional de Inmunizaciones (PAI) Estrategia de Gestión Integrada (EGI) Dengue Portal de Legislación en Salud (LEGISAPY) Atención Primaria de Salud Dirección General de Salud Ambiental (DIGESA) Dirección General de Información Estratégica en Salud (DIGIES) Dirección General de Vigilancia Sanitaria
Enlaces http://www.mspbs.gov.py http://correo.mspbs.gov.py http://www.mspbs.gov.py/pai http://dengue.mspbs.gov.py http://legisapy.mspbs.gov.py http://www.mspbs.gov.py/aps http://www.mspbs.gov.py/digesa http://www.mspbs.gov.py/digies
http://www.mspbs.gov.py/dinavisa
(DINAVISA) Comunicación Interna del MSPBS Modelo Estándar de Control Interno para Entidades Públicas del Paraguay (MECIP) Dirección General de Promoción de la Salud Red Integrada de Servicios de Salud (RISS)
http://www.mspbs.gov.py/intranetsalud http://www.mspbs.gov.py/mecip
http://www.mspbs.gov.py/promociondelasalud http://www.mspbs.gov.py/riss
Tabla 4. Portales Web administrados por la DIGIES
En cuanto a los SBDs componentes, de todas las fuentes de datos administradas por la DIGIES, se eligieron tres por el DBA para realizar su implementación. Se instruyó al DBA con los procedimientos y métodos necesarios para la implementación de otros SGBDF y para la gestión del ya existente (adhesión, actualización y eliminación de SBDs componentes). La heterogeneidad de los SBDs componentes adheridos al SGBDF (conjuntamente con el DBA), están fundamentados sobre motores de BDs de PostgreSQL y de MySQL.
7 7.1
Metodología
Herramientas
La elección de las herramientas aprovechadas para la implementación, se ha dado por una serie de motivos. Cabe enfatizar que Oracle VM VirtualBox, OpenVPN, PostgreSQL, DBI-Link, Perl, sus bibliotecas y módulos son software gratuito y además, los cuatro últimos son de código abierto. El hecho de que aquellas, sean de código abierto, permite manipular el código fuente de las mismas, lo cual resulta trascendental en muchos casos para tener una noción de cómo operan las funciones suministradas por ellas en la investigación. En segundo lugar, una herramienta clave en la implementación, como lo es PostgreSQL, es ampliamente aprovechada por la DIGIES y por ende, les resulta muy familiar. Por sobre todo, al ser la DIGIES un organismo gubernamental, apoya y promueve el uso de herramientas de código abierto y de software libre. En tercer lugar, estas herramientas son ampliamente populares; hecho comprobable por la existencia de diversos artículos de investigación y publicaciones relacionadas al tema, en su mayoría disponibles en la Web (véase, el apartado de Referencias). Dichas herramientas son estables, pues cuentan con varios años en el ambiente informático; además, sus desarrolladores y promotores continúan introduciendo nuevas versiones y mejoras de las mismas.
Por último, las herramientas seleccionadas cuentan con comunidades muy extendidas de desarrolladores y usuarios, algo muy valioso para la investigación, más aún, a la hora de implementar la propuesta. 7.2
Procedimiento
Para poder implementar la propuesta presentada en el trabajo, se ha recurrido al estudio de otras ya existentes, referentes a la gestión de información heterogénea y que mejor concuerden con el contexto de la región, siendo las más notables, las de Romero Martínez (1999) y Castro Salinas (2007). No obstante, la implementación en este trabajo no adopta la metodología utilizada en ninguna de las recientemente citadas, sino que se vale de otra. 7.2.1
Datos de la investigación
El tipo de estudio que se ha realizado en el trabajo, se podría definir como descriptivo. Un estudio descriptivo busca especificar las características, evalúa el fenómeno en cualquier dimensión e inclusive puede medir, con especificidad, cada parte por separado de la investigación; esta explicación parece concordar perfectamente, con las características del trabajo (Hernández Sampieri, Fernández Collado y Baptista Lucio, 1998). La estrategia utilizada para responder a la pregunta formulada en este trabajo, es pre-experimental; porque en Hernández Sampieri et al. (1998) se alega que una estrategia “pre-experimental”, se fundamenta en administrar un estímulo o tratamiento a un grupo, para aplicar una medición en una o más variables y así observar cuál es el nivel del grupo en estas variables. Siendo esta definición la que mejor representa al trabajo. Del mismo modo, esta investigación tiene un enfoque cuantitativo, es decir, existe un problema de estudio delimitado y concreto, las preguntas de investigación versan sobre cuestiones específicas, se realiza una revisión de la literatura y por sobre todo, las conclusiones derivadas contribuyen a la generación de conocimiento. Los fundamentos necesarios para plasmar el trabajo fueron logrados mediante el análisis de textos, artículos y publicaciones diversas, como lo son libros de académicos y profesionales, especialmente publicaciones en revistas especializadas en el área de BDs. Igualmente, fueron de gran importancia trabajos de grado, tesis, artículos de investigación y publicaciones Web relacionados al contenido investigado. Los instrumentos para la recolección de información, utilizados en el trabajo, son herramientas informáticas que permiten acceder a una gran cantidad de fuentes, como es el caso de libros electrónicos, como “Google Libros”, motores de búsquedas públicos, como “Google” y bibliotecas digitales enfocadas en publicaciones académicas y científicas, como “Google Académico” o “CiteSeer” primordialmente.
8
Resultados
Como corolario de la implementación de la propuesta y su aplicación mediante el caso de estudio, detallada en los apartados anteriores, se exhiben los resultados logrados. Se ha podido observar que la misma, ofrece lo siguiente: 1. La concepción de un SBDF requiere solamente escasas especificaciones y requerimientos, tanto del SBDF como de los SBDs componentes. 2. La simplificación en la integración de datos, desde diversas fuentes heterogéneas a partir de un acceso compuesto. 3. La adopción de tecnologías que permiten la gestión de información dispersa y heterogénea. 4. Un uso no circunscrito a expertos del área de bases de datos; incluso los usuarios finales, distinguen una sola fuente de datos. 5. La demanda de requerimientos para su construcción se asientan en software gratuito, ampliamente utilizado y en su mayoría de código libre. 6. Una administración establecida sobre un motor de base de datos objeto/relacional, con los beneficios que ello involucra. 7. La facilidad de ejecutar cualquier comando de manipulación de datos sobre los SBDs componentes (de acuerdo a los permisos otorgados sobre ellos) y de poder gestionarlos. 8. La posibilidad de aprovechar la minería de datos para obtener información útil, identificando datos relacionados dentro de la federación. Por medio de PostgreSQL y DBI-Link, se ha instaurado un SBDF. En definitiva, el resultado obtenido es un SBDF fuertemente acoplado, de modelo objeto/relacional que permite el acceso integrado a los SBDs componentes (ver Figura 8 y 9).
Figura 8. SBDF implementado como prototipo.
9
Conclusiones
Un SBDF es una colección cooperativa de SBDs autónomos y eventualmente heterogéneos. Para estudiar varias alternativas de arquitectura de SBDFs y sus implicaciones, se recurrió a una arquitectura de referencia. Del mismo modo, se discutió una metodología para el desarrollo de SBDFs, concretamente enfocándose en los SBDFs fuertemente acoplados. Así como también, se señalaron las tareas más importantes que deben cumplirse para desarrollar y operar SBDFs. En el trabajo se propuso la implementación de un SBDF para gestionar la información heterogénea, presente en la DIGIES. Antes, se realizó un prototipo de SGBDF, valiéndose de la técnica de virtualización de equipos informáticos para crear una federación de SBDs. La herramienta utilizada para construir la federación permite realizar tanto, consultas de datos sobre todos los SBDs componentes, como inserciones, actualizaciones y eliminaciones de registros. A su vez, permite el alta, la baja y la eliminación de los mismos SBDs componentes del SBDF. Lo ideal de ésta, es que recurre a las interfaces gráficas de administración disponibles para PostgreSQL y de esta manera, a más de administrar y gestionar el SBDF, ésta permite todas las funciones propias de este motor de BDs, siendo esto un plus para los DBA de federación.
Figura 9. SBDF implementado parcialmente en la DIGIES.
Se logra concluir que la cantidad de recursos y tareas a ser destinados en una integración de fuentes de datos heterogéneas, puede reducirse con el uso de las tecnologías apropiadas, ejecutando un acceso integrado a toda la información. En cambio, el nivel de conocimientos necesarios para llevarla a cabo, varía según la diversidad y la complejidad de las fuentes de datos a integrar. Finalmente, la capacidad de administración del SBDF, obedece en gran parte de los profesionales que la gestionen. Por lo tanto, se llega a fundamentar que el principal objeto del trabajo ha sido logrado: se ha realizado una propuesta, que permite la gestión de la información por medio de la implementación de un SBDF. 9.1
Recomendaciones para Trabajos Futuros
En una organización está la constante necesidad de acceder a la información, desde las distintas fuentes de datos existentes y de la manera más simple y posible. Esto hace que la integración de datos, mediante un acceso integrado o compuesto, sea la salida a la generalidad de los problemas de compatibilidad, conectividad y reutilización de sistemas informáticos. Sin embargo, varios inconvenientes precisan más investigación y desarrollo. Como propuesta de evolución, para trabajos futuros de implementación de un SBDF, sería recomendable cumplir con lo siguiente:
1. Algoritmos adecuados de administración de transacciones, que suministren un nivel puntual de consistencia (es decir, correctas con relación a un criterio de consistencia explícito) y tolerancia en un rendimiento admisible, dentro de las restricciones que presentan la heterogeneidad y la autonomía en un SBDF. 2. Estadísticas del rendimiento y eficacia de las herramientas implementadas en la propuesta, contra otras herramientas y soluciones comerciales existentes (obviando la limitación de costo), a fin de implementar la mejor opción. 3. Difundir y promover entre las entidades gubernamentales del país o empresas de gran porte, la posibilidad de integrar la gestión de información gracias a la implementación de un SBDF, como el presentado en este trabajo.
10 Referencias Afsarmanesh, H., Wiedijk, M. & Hertzberger, L. (1994). Flexible and Dynamic Integration of Multiple Information Bases. Trabajo pesentado en la Proceedings DEXA’94 - 5th IEEE International Conference on Databases and Expert Systems Applications. Setiembre, Atenas, Grecia. Aslan, G. & McLeod, D. (1999). Semantic heterogeneity resolution in federated databases by metadata implantation and stepwise evolution. The VLDB Journal - The International Journal on Very Large Data Bases archive, 8 (2), 120-132. Ben
Kiki, O., Evans, C. & döt Net, I. (2009, Octubre 1). YAML Ain’t Markup Language (YAML™) Version 1.2. Recuperado el 16 de Febrero de 2013, de http://www.yaml.org/spec/1.2/spec.html
Buch, V. (2002). Database Architecture: Federated vs. Clustered. Recuperado el 8 de Enero de 2013, de http://www.oracle.com/technetwork/database/windows/clustercomp134873.pdf Castro Salinas, D. (2007). Interoperabilidad e Integración de Sistemas Informáticos de la Iglesia Católica en Chile. Tesis de Grado. Disponible en Scribd.
Crall, C., Danseglio, M. & Mowers D. (2003, Julio 31). SSL/TLS in Windows Server 2003. Recuperado el 22 de Febrero 2013, de http://technet.microsoft.com/es-us/library/cc781800%28v=ws.10%29.aspx Fang, D., Hammer, J. & McLeod, D. (1992). An Approach to Behavior Sharing in Federated Database Systems. Trabajo presentado en la The International Workshop on Distributed Object Management (IWDOM 1992). Agosto, California, Estados Unidos de América. Fetter, D. (2010). DBI-Link. Recuperado el 2 de Febrero de 2013, de https://github.com/davidfetter/DBI-Link Haas, L. & Lin, E. (2002). IBM Federated Database Technology. Recuperado el 7 de Enero de 2013, de http://www.ibm.com/developerworks/data/library/techarticle/0203haas/0203 haas.html Hammer, M. & McLeod, D. (1979). On Database Management System Architecture (Publicación Tech. Rep. MIT/LCS/TM-141). Cambridge, Massachusetts: Massachusetts Inst. of Tech Cambridge Lab for Computer Science. Heimbigner, D. & McLeod, D. (1985). A Federated Architecture for Information Management. ACM Transactions on Office Information System, 3 (3), 253278. Hernández Sampieri, R., Fernández Collado, C. y Baptista Lucio, P. (1998). Metodología de la Investigación Científica (2da. ed.). México D.F.: McGraw-Hill. Hwang, S., Huang, J. & Srivastava, J. (1993). Concurrency Control in Federated Databases: A Dynamic Approach. Trabajo presentado en el Proceedings of the Second International Conference on Information and Knowledge Management (CIKM ‟93). Noviembre, Washington, DC, Estados Unidos de América. Leffler, J., Wiedmann, J., Goeldner, S. & Bunce, T. (2013). DBI::DBD. Recuperado el 16 de Febrero de 2013, de http://search.cpan.org/~timb/DBI1.623/lib/DBI/DBD.pm Lim P., Hwang S., Srivastava J., Clements D. & Ganesh M. (1995). Myriad: Design and Implementation of a Federated Database Prototype. SoftwarePractice and Experience, 25 (2), 533-562. Martínez Guerrero, R. (2009, Diciembre 1). PostgreSQL y el uso de SSL. Recuperado el 1 de Marzo de 2013, de http://www.postgresql.org.es/node/384 Martínez Guerrero, R. (2010, Octubre 10). Sobre PostgreSQL. Recuperado el 10 de Febrero de 2013, de http://www.postgresql.org.es/sobre_postgresql
Microsoft Corporation (2013). Servidores de bases de datos federadas. Recuperado el 7 de Enero de 2013, de http://msdn.microsoft.com/esus/library/ms190381.aspx Ministerio de Salud Pública y Bienestar Social, Dirección General de Información Estratégica en Salud (DIGIES) (2013). Enlaces a sistemas. Recuperado el 14 de Marzo de 2013, de http://www.mspbs.gov.py/digies/enlaces_sistemas/ Ministerio de Salud Pública y Bienestar Social, Dirección General de Información Estratégica en Salud (DIGIES) (2013). Institucional. Recuperado el 14 de Marzo de 2013, de http://www.mspbs.gov.py/digies/institucional/ Object Management Group Inc. (2013). ORB Basics. Recuperada el 14 de Febrero de 2013, de http://www.omg.org/gettingstarted/orb_basics.htm Odoñez, C., Chen, Z. & García-García, J. (2007). Metadata Management for Federated Databases. Trabajo presentado en la Proceedings of the ACM first workshop on CyberInfrastructure: information management in eScience (CIMS '07). Noviembre, Lisboa, Portugal. Oracle Corporation (2011). El motor de almacenamiento FEDERATED. Recuperado el 8 de Enero de 2013, de http://dev.mysql.com/doc/refman/5.0/es/federated-storage-engine.html Oracle Corporation (2013). Oracle VM VirtualBox User Manual. Recuperado el 9 de Febrero de 2013, de https://www.virtualbox.org/manual/ Perl.org (2013). Perl DBI. Recuperado el 16 de Febrero de 2013, de http://dbi.perl.org/ PgFoundry (2013). DBI-Link. Recuperado el 2 de Febrero de 2013, de http://pgfoundry.org/projects/dbi-link/ PostgreSQL wiki (2010, Mayo 10). DATALINK. Recuperado el 10 de Febrero de 2013, de http://wiki.postgresql.org/index.php?title=DATALINK&oldid=10721 PostgreSQL wiki (2012, Marzo 6). SQL/MED. Recuperado el 10 de Febrero de 2013, de http://wiki.postgresql.org/index.php?title=SQL/MED&oldid=16364 Rabelo, R. J., Afsarmanesh, H. & Camarinha Matos, L. M. (1999). Applying Federated Databases to Inter-Organizational Multi-Agent Scheduling. Trabajo presentado en la 1st International IFAC Workshop on Multi-Agent Systems in Production, Diciembre, Vienna, Austria. Romero Martínez, M. (1999). Lenguaje de Consultas para una Multibase de Datos. Tesis de Maestría. Recuperado de http://catarina.udlap.mx/u_dl_a/tales/documentos/msp/romero_m_m/ SELinux Wiki (2009, Octubre 16). FAQ. Recuperado el 29 de Marzo de 2013, de http://selinuxproject.org/w/?title=FAQ&oldid=729
Sheth, P. & Larson, J. A. (1990). Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases. ACM Computing Surverys, 22 (3), 183-236. Shostack, A. (1995). An Overview of SSL (version 2). Recuperado el 23 de Febrero de 2013, de http://www.homeport.org/~adam/ssl.html The OpenSSL Project (2009). About the OpenSSL Project. Recuperado el 20 de Febrero de 2013, de http://www.openssl.org/about/ The PostgreSQL Global Development Group (2013). Chapter 40. PL/Perl - Perl Procedural Language. Recuperado el 10 de Febrero 2013, de http:/www.postgresql.org/docs/8.4/static/plperl.html
UNIVERSIDAD AUTÓNOMA DE ASUNCIÓN FACULTAD DE CIENCIAS Y TECNOLOGÍA INGENIERÍA EN SISTEMAS INFORMÁTICOS
SISTEMAS DE BASES DE DATOS FEDERADAS PARA LA GESTIÓN DE LA INFORMACIÓN
Alumno: Marvin Matías Agüero Torales
[email protected] +595 961 814359
Tutor: Prof. Ing. Mario Rubén Canto
Asunción, Paraguay 2013
RESUMEN Un sistema de base de datos federada es una capa de abstracción de software que permite gestionar, como si se tratara de una única fuente, a una colección de sistemas de bases de datos componentes. La investigación encarada en este trabajo, abarca la revisión de la bibliografía sobre las teorías de las bases de datos federadas y de los componentes involucrados. En base a esta revisión, se realiza el análisis y la construcción de un prototipo para demostrar la tecnología. Finalmente, se efectúa la implementación del paradigma en un caso de estudio. Se pretende exponer una perspectiva clara del modo en que una base de datos federada puede ser implementada y los conjuntos de técnicas disponibles para este propósito. El caso de estudio se implementa mediante un sistema de base de datos federadas para la gestión y la integración de diversas fuentes de datos heterogéneas, dispersas en una organización gubernamental, de tal forma que toda esa información, en base a ciertos parámetros, se pueda integrar totalmente y que, al mismo tiempo, permita la incorporación de futuras fuentes de datos. Palabras-clave: Bases de datos federadas; Fuentes de datos heterogéneas; Implementación de software; Gestión de información; Integración de información. Área: Bases de datos.
