Sistemas de Bases de Datos Federadas para la Gesti´on de la Informaci´on Marvin Mat´ıas Ag¨ uero Torales Universidad Aut´onoma de Asunci´on Asunci´on, Paraguay
[email protected] Mario Rub´ en Canto, Universidad Aut´onoma de Asunci´on, Asunci´on, Paraguay
[email protected] Jos´ e Luis V´ azquez Noguera, Universidad Nacional de Asunci´on, Asunci´on, Paraguay
[email protected] 19 de junio de 2016 Resumen La investigaci´on en este trabajo pretende exponer una perspectiva clara del modo en que una Base de Datos Federada puede ser implementada y los conjuntos de t´ecnicas disponibles para este prop´osito. Un Sistema de Base de Datos Federada es una elecci´on v´alida, si se necesita formular consultas simples (´ unicas), y recibir respuestas simples (´ unicas), pero que en la preparaci´on de la misma intervengan datos de varias fuentes. Se implementa un Sistema de Base de Datos Federadas por sobre otras soluciones, como un almac´en de datos por ejemplo, para la gesti´ on y la integraci´on de diversas fuentes de datos heterog´eneas, dispersas en una organizaci´on gubernamental, de tal forma que toda esa informaci´ on, en base a ciertos par´ametros, se pueda integrar totalmente y que, al mismo tiempo, permita la incorporaci´on de futuras fuentes de datos. El resultado obtenido es un Sistema de Base de Datos Federada fuertemente acoplado, de Modelo Objeto/Relacional, que permite el acceso integrado a las fuentes de datos componentes utilizando la tecnolog´ıa de compuertas o enlaces de datos. Palabras Claves: bases de datos federadas, fuentes de datos heterog´eneas, integraci´ on de informaci´ on
1
1.
Introducci´ on
La creciente necesidad de cooperaci´on entre entidades independientes requiere el acceso integrado a m´ ultiples bases de datos aut´onomas y heterog´eneas, es decir, acceder a los datos como si de una sola fuente de datos se tratase. Esta colecci´ on de bases de datos cooperativas, conocidas como Sistemas de Bases de Datos (SBD) componentes, forman una federaci´on y el software encargado de gestionarlas recibe el nombre de Sistema de Bases de Datos Federadas (SBDF). Algunas organizaciones como la Direcci´on General de Informaci´on Estrat´egica en Salud (DIGIES), ´ organo dependiente del Ministerio de Salud P´ ublica y Bienestar Social (MSPyBS), se identifican por su heterogeneidad, ya que se componen de diferentes fuentes de datos, las cuales est´an planteadas de forma independiente y operan de manera aut´onoma empleando distintos esquemas. De esta manera debido a las diferencias tecnol´ogicas, 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´on de las transacciones y se preserva la autonom´ıa de cada fuente de datos, frente al sistema completo. La implementaci´on de un SBDF suministra a los usuarios la posibilidad de acceso a informaci´on m´ ultiple, localizada en diferentes fuentes de datos heterog´eneas (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´on. 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´ on para el usuario. Esta tecnolog´ıa es de un aprendizaje e implementaci´ on viable, por lo cual requiere mayor difusi´on en el ´ambito inform´atico local. Implementar un SBDF en una organizaci´on, como la DIGIES, no demanda una gran inversi´ on, ya que se estar´ıan utilizando recursos disponibles para gestionarlas. Para el trabajo, seg´ un los planteamientos previos, se identifican los siguientes objetivos: Justificar el paradigma de los SBDFs para instaurar la interoperabilidad de fuentes de datos heterog´eneas e implementar un SBDF en un organismo p´ ublico, como caso de estudio para exponer el uso de esta tecnolog´ıa, permitiendo la integraci´on e interacci´on de fuentes de datos dispersas y heterog´eneas. En los dos siguientes apartados se despliegan los fundamentos de un SBDF y el estado del arte del trabajo, el cual contiene los contenidos relacionados con la propuesta de una forma simple y profunda. Asimismo se realiza un estudio de otras propuestas, en donde se han aplicado t´ecnicas y metodolog´ıas de integraci´ on, un an´ alisis de la situaci´on del caso de estudio, la presentaci´on de la problem´ atica existente y las posibles soluciones. La soluci´on propuesta y la herramienta seleccionada para llevarla a cabo se exponen en los posteriores apartados, resultante de un an´alisis previo, la metodolog´ıa utilizada y los resultados esperados en el caso de estudio. Los u ´ltimos apartados se centran en los resultados alcanzados, como tambi´en en las conclusiones obtenidas a lo largo del desarrollo del trabajo.
2
2.
Fundamentos de un SBDF
Un SBDF es una colecci´ on de SBDs componentes cooperativos y aut´onomos que poseen diversos grados de integraci´on [1]. Estos componentes o nodos de la federaci´ on, son manejados por un tipo de software espec´ıfico. El software que proporciona la manipulaci´ on controlada y coordinada de los SBDs componentes se llama sistema de gesti´ on de base de datos federada (SGBDF). Los SGBDFs poseen ciertas diferencias frente a un SGBD, adem´as de puntos desafiantes, tales como las ejecuciones de transacciones y el control de concurrencia, salvaguardando la consistencia de la base de datos. Uno de los aspectos m´as significativos de un SBDF, ´el que un SBD componente puede continuar sus operaciones locales sin afectar su participaci´ on en una federaci´on, incluso en simult´aneo. Los sistemas conformados por m´ ultiples SBDs, siendo los SBDFs un tipo espec´ıfico de ´estos, pueden ser determinados mediante tres dimensiones ortogonales: la distribuci´ on, la heterogeneidad y la autonom´ıa. Los datos pueden distribuirse entre varias bases de datos de diferentes maneras, inclusive en particiones de base de datos verticales y horizontales, del mismo modo, se pueden mantener varias copias de algunos o todos los datos y estas copias no necesitan ser estructuradas id´enticas. Una empresa puede tener m´ ultiples SGBDs. Diferentes organizaciones dentro de la empresa pueden tener requisitos dispares y seleccionar diversos SGBDs; los SGBDs adquiridos durante un per´ıodo pueden variar debido a cambios en la tecnolog´ıa. Heterogeneidades debidas a diferencias en los SGBDs, resultan de las pluralidades en los modelos de datos y las diversidades a nivel de sistema. Cada SGBD tiene un modelo de datos subyacente, utilizado para definir restricciones y estructuras de datos. Las representaciones (estructura y limitaciones) y aspectos del lenguaje pueden conducir a la heterogeneidad. Los SBDFs se constituyen de SBDs componentes heterog´eneos en la totalidad de los entornos y pueden clasificarse como: d´ebilmente acoplados o fuertemente acoplados, en funci´on de qui´en administra la federaci´ on y c´ omo se integran los componentes . Un SBDF d´ebilmente acoplado, sistema de base de datos interoperables o sistema multibase de datos, se da cuando la responsabilidad de crear y mantener la federaci´on es del usuario y si adem´ as no existe ning´ un control impuesto por el sistema federado y sus administradores. Si la federaci´ on y su administrador (o administradores) tienen la responsabilidad de crear y mantener la misma, por ende, controlar activamente el acceso a los SBDs componentes, indica que la federaci´on est´a fuertemente acoplada. Las personas que controlan una base de datos est´an, a menudo, dispuestos a compartir con otros los datos, s´olo si pueden mantener cierto control sobre esos datos; adem´ as una organizaci´on, habitualmente, gestiona diferentes SBDs, los cuales son frecuentemente aut´onomos y est´an com´ unmente bajo un control separado e independiente ejercido por los administradores de cada SBDs. Un SBDF es un caso especial de los SBDDs. La diferencia entre estos dos SBDs, reside en que en los SBDFs intervienen diferentes propietarios aut´onomos que comparten un esquema conceptual en com´ un (aunque tengan distintos tipos de fuentes de datos), mientras que en los SBDDs se espera cumplir una fragmentaci´ on de los datos en esquemas equivalentes. 3
2.1.
Metodolog´ıa para el desarrollo de un SBDF
La metodolog´ıa para el desarollo de un SBDF, principalmente, consiste en integrar bases de datos componentes existentes y a˜ nadir nuevas bases de datos componentes a un SBDF. Generalmente se sigue un proceso de desarrollo de SBDF bottom-up para este prop´osito, sin embargo, cuando nuevas aplicaciones se desarrollan sobre un SBDF existente, es necesario determinar si los requisitos de datos de la aplicaci´on son compatibles con un esquema federado; de no serlo, es preciso extender un esquema federado o crear uno nuevo, as´ı como tambi´en ampliar una base de datos componente existente o crear una nueva: proceso conocido como el proceso de desarrollo de SBDF top-down, el cual es una extensi´ on del proceso de dise˜ no de base de datos distribuida tradicional.
2.2.
Problemas no resueltos
Con el correcto funcionamiento se avala la consistencia de la base de datos federada, si bien es importante referir que existe otro reto: la concurrencia, en donde se debe garantizar la ejecuci´on serial de las transacciones, tanto local como globalmente. El procesamiento de consultas en un SGBDF presenta un costo desigual de realizar una operaci´on en diferentes SBDs componentes, en contrapartida a la autonom´ıa de un SBD componente, donde el costo de realizar una operaci´ on en el mismo no puede ser conocido o s´olo puede serlo aproximadamente, a lo que se suma que estos costos pueden variar de vez en cuando, como los cambios en la carga del sistema local. Un esquema federado podr´ıa generarse para cada usuario de federaci´on diferente, esto provoca que los esquemas externos puedan considerarse como redundantes con los esquemas federados [2].
2.3.
Posibles soluciones
El principal reto trazado al inicio del trabajo, radica en la integraci´on de informaci´ on heterog´enea dispersa en diferentes fuentes de datos dentro de las organizaciones. Para resolver parte de este problema, existe una tendencia a la unificaci´ on de las fuentes de datos heterog´eneas. Seguidamente, se despliegan propuestas que trataron sobre la problem´atica expuesta. Indistintamente, se ver´ an las potenciales soluciones a la heterogeneidad de la informaci´on dentro de las organizaciones. A continuaci´on, se presentan y comparan las posibles soluciones. 2.3.1.
Acceso separado e integraci´ on manual (sin esquema global)
Un acceso separado supone consultar separadamente cada fuente de datos, e integrar manualmente las respuestas. Para llevar a cabo esta soluci´on 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´e 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 4
y por sobre todo, el saber c´ omo integrar los resultados parciales obtenidos para producir el resultado final esperado [3]. En [4, 5, 6] sustentan que un esquema global es dif´ıcil de mantener debido a la heterogeneidad de las fuentes de datos locales, por consiguiente, la heterogeneidad sem´ antica se resuelve mediante un lenguaje manejador de fuentes de datos m´ ultiples, este lenguaje es el sustituto del esquema global. Para lograr la integraci´ on mediante ´el mismo, se debe crear un esquema conceptual utilizando las sentencias de dicho lenguaje (por ejemplo; Multibase, Ingres, SYBASE, Pegasus), asimismo el lenguaje para manejar fuentes de datos m´ ultiples debe dar soporte para ejecutar operaciones SQL en este esquema, tales operaciones pueden ser, tanto de definici´on del esquema conceptual, como de manipulaci´on de datos [7]. Las ventajas de realizar un acceso separado y una posterior integraci´on manual, sin contar con un esquema global, son las siguientes: No requiere el mantenimiento de un esquema global. Respeta la autonom´ıa de las fuentes de datos locales. Flexibilidad para trabajar con un n´ umero variable de fuentes de datos (es posible a˜ nadir o quitar fuentes de datos, utilizando el lenguaje para manejar fuentes de datos m´ ultiples). Apta para integrar fuentes de datos en Internet (ya que la informaci´on que se encuentra en esta red var´ıa constantemente) Las desventajas de esta soluci´on, son las siguientes: Los lenguajes para trabajar con fuentes de datos m´ ultiples comerciales que se han creado, son muy limitados. La creaci´ on de un lenguaje para manejar fuentes de datos m´ ultiples, es una actividad m´ as compleja que la creaci´on de un esquema global (Mu˜ noz Garc´ıa, 2008). 2.3.2.
Integraci´ on de datos (esquema global f´ısico)
La integraci´ on de datos en un esquema global u ´nico, adem´as de representar el conjunto de esquemas de las fuentes de datos a integrar, tiene la capacidad de almacenar sus datos. Sin embargo, establecer una nueva fuente de datos, que contenga la totalidad de los datos de las preexistentes, obliga a dise˜ nar una nueva fuente de datos (eventualmente un SBDD), convertir todos los programas implicados, migrar la totalidad de los datos de las fuentes anteriores a la creada y preparar e instruir en los nuevos modos de trabajar a los usuarios Las principales ventajas de integrar con un esquema global f´ısico todas las fuentes de datos heterog´eneas son las siguientes: El esquema global f´ısico representa una vista integrada del conjunto de fuentes de datos. 5
Contiene a los datos de las fuentes de datos (significa que cada registro de datos de las fuentes de datos locales, es almacenado redundantemente en este esquema, proporcionando el acceso directo a los datos). El acceso a los datos es m´as r´apido debido a que los mismos residen en dicho esquema. No es necesario desarrollar componentes adicionales para el acceso a los datos (ya que los datos se almacenan en este esquema). Las desventajas de esta soluci´on, son las siguientes: El costo de actualizar los datos de las fuentes de datos (se requiere que los datos sean replicados o enviados desde las fuentes de datos a este esquema). La necesidad de un mecanismo de actualizaci´on (las operaciones se realizan directamente en el esquema f´ısico, siendo probable que los usuarios no obtengan resultados vigentes porque los datos podr´ıan no estar actualizados). El mantenimiento del esquema (los cambios en las estructuras de los esquemas de las bases de datos locales deben ser reflejados en este esquema). 2.3.3.
Almac´ en de datos o Data Warehouse
Un almac´en de datos es una colecci´on de datos orientadas a un dominio, integrado, no vol´ atil, y variable en el tiempo, que ayuda a la toma de decisiones de la empresa u organizaci´ on. Es posible integrar las fuentes de datos por medio. de un Data Warehouse, pero ´este no proporciona herramientas para la soluci´on de la heterogeneidad sem´ antica, puesto que permite solamente el almacenamiento y la extracci´ on de un n´ umero determinado de informaci´on de las fuentes de datos locales: una de las caracter´ısticas del Data Warehouse es que los datos que existen en su repositorio pueden ser consultados, pero no modificados [8, 9]. Un almac´en de datos puede coexistir con un SBDF, ya que se pueden federar las bases de datos de tiempo real con el Data Warehouse, permitiendo a los usuarios un an´ alisis de los datos con contexto y actualidad, integrando datos hist´ oricos con datos en tiempo real bajo un sistema cooperativo. Las ventajas de un Data Warehouse, desde una perspectiva general son: los datos est´ an f´ısicamente integrados (aunque para ello se requiera una ardua labor). existe una confidencialidad en el uso de los dato. Mientras que su principal desventaja de un Data Warehouse es: Los datos almacenados en el almac´en deben ser analizados para detectar redundancias. En un acceso integrado en cambio, la informaci´on se obtiene online, los datos siempre son actuales y no se tildan como redundantes, sino como complementarios. 6
2.3.4.
Acceso integrado (esquema global l´ ogico)
Construir un SBDF en el que las fuentes de datos interoperen, constituye una integraci´ on del acceso. En el acceso integrado, el esquema global l´ogico es una vista virtual del conjunto de esquemas de las fuentes de datos a integrar, lo cual significa que no almacena datos f´ısicamente pero si permite el acceso a estos [10]. Un acceso integrado satisface una interoperabilidad entre las fuentes de datos, esta soluci´ on presenta dos tipos de usuarios: un usuario administrador que distingue la totalidad de las fuentes y otro, que s´olo diferencia una sola, la misma est´ a compuesta de dos niveles como m´ınimo: un nivel componente o local y otro federado o global, donde el primero incorpora a las fuentes de datos (o SBDs componentes) y el segundo al conjunto de fuentes que interoperan (SBDF). Las ventajas de integrar fuentes de datos mediante un esquema global l´ogico son las siguientes: Facilita transparencia sem´antica a los usuarios (dichos usuarios no tienen la necesidad de conocer las estructuras de los esquemas de las fases de datos locales). Los conflictos entre n-esquemas son reducidos a conflictos entre 2-esquemas (el esquema global y el esquema de la fuente de datos local). Consiente el acceso a los datos (un usuario global pueda hacer actualizaciones en las fuentes de datos por medio de este esquema). Respeta la autonom´ıa de las fuentes de datos. Las desventajas en el uso de un esquema global l´ogico son las siguientes: Su actualizaci´ on y mantenimiento es una actividad a realizar mon´otonamente (los cambios en las estructuras de los esquemas de las fuentes de datos locales deben ser reflejados en este esquema). Para dar soluci´ on a la heterogeneidad de los datos, es necesario agregar componentes al esquema global (por ejemplo, procedimientos para hacer conversiones de datos, tipos de datos o expresiones)
3.
Soluci´ on 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 expuestas, posibles soluciones, cualesquiera de ellas debe superar dificultades t´ecnicas significativas. Esta autonom´ıa que se perder´ıa por completo en la integraci´on de datos, se conserva completamente en la integraci´on manual y se puede hablar de estados intermedios, en una implementaci´on de un almac´en de datos. Un acceso integrado preserva la autonom´ıa de cada fuente de datos, permite la evoluci´on de la soluci´ on instaurada, presenta gran flexibilidad y posee una alta viabilidad 7
de efectuarse eficientemente [3]. El acceso separado a las fuentes de datos y su posterior integraci´ on manual, es factible, pero s´olo muy excepcionalmente por la complejidad que implica. En la integraci´on de datos, se crea una nueva fuente de datos conteniendo a todas las originales, lo que supone una labor gigantesca [3].
3.1.
Integraci´ on de fuentes de datos heterog´ eneas
La b´ usqueda de la integraci´on de fuentes de datos heterog´eneas son motivadas por la descentralizaci´on de la informaci´on organizacional, la fusi´on de empresas, la necesidad de acceso a informaci´on externa para toma de decisiones y la migraci´ on o actualizaci´ on de sistemas de informaci´on heredados; ellos refieren que la integraci´ on de fuentes de datos requiere la comprensi´on clara del significado (sem´ antica de dominio) de cada fuente, conocimiento adquirido en un proceso de ingenier´ıa inversa a trav´es de los esquemas de implementaci´on [11]. La integraci´ on de fuentes de datos heterog´eneas es posible si los dominios de los datos de las fuentes a integrar son similares y que debe darse en cinco niveles: sem´ antico, conceptual, l´ ogico, de consulta y de instancia; cada uno de los cuales enfrenta diferentes tipos de problemas, emplean diferentes tipos de conocimiento y sem´ antica de dominio y representan a la fuente de datos integrada en sus distintos niveles de abstracci´on [11]. El nivel sem´ antico requiere un conocimiento general de la realidad a la que pertenece un objeto en las fuentes de datos a integrar para poder representarlo y modelarlo, en el nivel conceptual, se logra obtener un esquema conceptual global a partir de los locales del subconjunto de datos que, de cada fuente, se pondr´a a disposici´ on del usuario de la fuente de datos integrada (expresados en un modelo conceptual com´ un como el ER), en el nivel l´ogico, al igual que en el conceptual, se obtiene un esquema l´ ogico global a partir de los locales (expresados tambi´en en un modelo l´ ogico com´ un como el relacional) pero adem´as se afirma en los mapeos entre el esquema conceptual global y los locales, en el nivel de consultas, se integran las instancias contenidas en los resultados de las consultas locales, as´ı que si representan a los mismos objetos se igualan, y por u ´ltimo, el nivel de instancia es responsable de la forma en que ser´an consultadas, obtenidas y organizadas las instancias en la fuente de datos integrada, para lo cual se plantean dos soluciones: un SBDF, en la que las instancias son integradas en el momento en que el usuario de la aplicaci´on global realiza la consulta y el data warehousing, en el que las instancias son tomadas e integradas en un repositorio central antes de la consulta global [11]. Teniendo en cuenta lo anteriormente expuesto, las mejores soluciones y m´as factibles de realizar para logar la integraci´on de la informaci´on heterog´enea, son un SBDF o un almac´en de datos.
8
3.2.
Enfoque federado versus almac´ en de datos
Seg´ un lo antes expuesto, en la Figura 1 se elabora un cuadro comparativo de un enfoque federado y un almac´en de datos, justificando al primero por sobre el segundo como una soluci´ on m´as acertada para el caso de estudio.
3.3.
La soluci´ on
La implementaci´ on de un SBDF suministrar´a a los usuarios la posibilidad de acceso a informaci´ on m´ ultiple, localizada en diferentes fuentes de datos heterog´eneas, para obtenerla cuando se requiera. Presenta a los usuarios una vista, como si fuera una sola base de datos, que contiene toda la informaci´on. 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´on para el usuario.
3.4.
El gestor de la federaci´ on
Las herramientas de federaci´on de IBM, Oracle Data Service Integrator, Sybase Data Federation, Informatica Data Services, SAP BusinessObjects Data Federator y SAS Federation Server, entre otras, por no satisfacer las pol´ıticas de software del organismo fueron excluidas para el caso de estudio, pese a su calidad y avances. Seg´ un nuestro caso de estudio, Kettle, Teiid y DBI-Link, son las herramientas de software m´as adecuadas para implementar un SBDF; debido a su gratuidad, su pol´ıtica open source y la capacidad de admitir varias fuentes de datos heterog´eneas para el intercambio de datos. La Figura 2 muestra, como un sumario, los aspectos claves evaluados en cada herramienta de federaci´ on de datos. As´ı como en [12], el rendimiento no se pudo evaluar en ninguna de las herramientas porque es dif´ıcil contar con un entorno real donde probar la concurrencia y la capacidad de respuesta de cada una al integrar un conjunto determinado de datos, por eso no se incluy´o en la tabla comparativa, sin embargo, se reflej´o como punto importante a tener en cuenta para evaluar cualquier herramienta de federaci´on de datos.
3.5.
Modelo de Integraci´ on Federado Aplicado al Caso de Estudio
La arquitectura del modelo de integraci´on federado se fundamenta en un conjunto de capas, las que se van estableciendo, hasta alcanzar la integraci´on final (ver Figura 3 ) y est´ a fundamentado principalmente en la arquitectura de esquema de cinco niveles [1]:. Nivel 1: toma a los esquemas locales de datos. Nivel 2: negociaci´ on entre el DBA componente y el DBA de federaci´on. Nivel 3: estructuras disponibles de una fuente de dato en particular.
9
Figura 1: Enfoque federado versus almac´en de datos.
10
Figura 2: Comparativo de gestores de federaci´on aplicables al caso de estudio. Nivel 4: estructuras de los datos para integrar y conceder acceso sobre ellos. Nivel 5: vistas que referencian a los SBDs componentes seg´ un su rol en la federaci´ on. Estas capas est´ an distribuidas seg´ un la Figura 4, donde el nivel 1 toma a los esquemas locales de datos, el cual contiene todos los esquemas y modelos de datos de las distintas fuentes de datos, recuperadas realizando alg´ un tipo de ingenier´ıa inversa al conjunto existente para obtener el modelo de datos l´ ogico nativo. En el nivel 2, correspondiente a los esquemas componentes, se tiene el resultado de aplicar de las pol´ıticas y restricciones de acceso dadas para los perfiles de usuarios espec´ıficos de la integraci´on, las cuales est´an basadas en la negociaci´ on entre el DBA componente y el DBA de federaci´on. Al nivel 3, relativo a los esquemas de exportaci´on, ata˜ ne todo lo relacionado con las estructuras disponibles de una fuente de dato en particular, mientras que en el nivel 4 se tienen las estructuras de todos los datos para integrar y conceder acceso sobre ellos, es el esquema federado, responsabilidad del DBA de federaci´on. Finalmente, en el nivel 5 se albergan las vistas de usuario; en esta capa se muestran todas las vistas que se referencian de los SBDs componentes, cada uno en un esquema distinto seg´ un su rol en la federaci´on (esquemas externos).
3.6.
Prototipo
Finalmente mediante un diagrama de componentes UML (Lenguaje Unificado de Modelado), se puede apreciar el SBDF implementado como prototipo (Ver Figura 5 y 6). Para demostrar la aplicaci´on pr´actica de las herramientas propuestas en un caso de estudio real, se ha establecido una propuesta de SBDF en la DIGIES. 11
Figura 3: Propuesta de modelo de integraci´on federado aplicado al caso de estudio.
12
Figura 4: Propuesta de modelo de integraci´on federado aplicado al caso de estudio.
13
Figura 5: Diagrama de componentes del SBDF implementado como prototipo.
14
Figura 6: Diagrama de despliegue del SBDF implementado como prototipo. En el Ministerio de Salud P´ ublica y Bienestar Social, Direcci´on General de Informaci´ on Estrat´egica en Salud (DIGIES) (2013), se menciona de la existencia de 15 sistemas inform´ aticos funcionando y administrados por la DIGIES, adem´as de otros en proceso de implementaci´on, como tambi´en de 19 portales Web activos y tres en etapa de construcci´on. Seg´ un 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 y MySQL en su mayor´ıa, adem´as de Microsoft SQL Server, Oracle Database, Microsoft Access, dBase y algunos archivos de datos como Microsoft Excel o CSV. Estas fuentes de datos est´an asentadas sobre sistemas operativos Linux en su mayor´ıa, aunque tambi´en las hay sobre Windows y FreeBSD (en resumen, todas corriendo en diversas plataformas) (Ministerio de Salud P´ ublica y Bienestar Social, 2009).
3.7.
Modelo de Integraci´ on Federado Aplicado al Caso de Estudio
La implementaci´ on del SBDF para la gesti´on de la informaci´on disponible en la DIGIES, fue una tarea conjunta y apoyada por la Direcci´on de Tecnolog´ıa e Inform´ atica de dicho organismo, puntualmente con el DBA y el administrador de redes. En la Figura 7, se observa la propuesta de implementaci´on del SBDF. El servidor de la federaci´ on corre sobre Linux, Debian para ser claros. Para realizar la instalaci´ on del SGBDF, fue necesario replicar exactamente todo lo expuesto anteriormente, en el apartado de Sistemas de Bases de Datos Federadas
15
para la Gesti´ on de la Informaci´on, en la secci´on de Implementaci´on del SGBDF. Es necesario aclarar, que solamente es preciso replicar lo referente al SGBDF, no as´ı lo relativo a los SBDs componentes, puesto que ´estos, hoy existen y son operados diariamente (por supuesto, este caso es diferente al del prototipo implementado, donde si fue necesaria la virtualizaci´on). El fin de federar las fuentes de datos, en principio, fue porque existen varias bases de datos con tablas replicadas entre las mismas, principalmente las concernientes a datos de regiones sanitarias, distritos, establecimientos y profesionales de salud, as´ı como tambi´en a datos b´ asicos de personas (documento de identidad, nombre, apellido, fecha de nacimiento, etc.). Estos datos deber´ıan formar una sola gran fuente, feder´ andola con las dem´as, con el prop´osito de normalizar los datos y reducir o eliminar la potencial redundancia y dependencias incoherentes dentro del esquema, logrando una integraci´on de los datos.
Figura 7: SBDF implementado parcialmente en la DIGIES. En cuanto a los SBDs componentes, de todas las fuentes de datos administradas por la DIGIES, se optaron tres por el DBA para realizar su implementaci´ on: ´ Sub-Sistema de Informaci´on de Servicios de Salud Area Ambulatoria (SAA), ´este gestiona los datos de la ficha e historia cl´ınica de los pacientes. Sub-Sistema de Informaci´on de Estad´ısticas Vitales (SSIEV), ´este tramita los certificados de nacidos vivos y certificados de defunciones. 16
Sistema Inform´ atico de Registro de Profesionales de la Salud (SIREPRO), ´este facilita los registros de profesionales de salud (m´edicos, enfermeras, odont´ ologos, entre otros). Se instruy´ o al DBA con los procedimientos y m´etodos necesarios para la implementaci´ on de otros SGBDF y para la gesti´on del ya existente (adhesi´on, actualizaci´ on y eliminaci´ on de SBDs componentes). La heterogeneidad de los SBDs componentes adheridos al SGBDF (conjuntamente con el DBA), est´an fundamentados sobre motores de BDs de PostgreSQL y de MySQL (ver Figura 8 y 9 ).
Figura 8: Diagrama de componentes del SBDF implementado parcialmente en la DIGIES.
4.
Resultados
Como corolario de la implementaci´on de la propuesta y su aplicaci´on mediante el caso de estudio, detallada en los apartados anteriores, se exhiben los resultados logrados. Se ha podido observar que la misma, logra lo siguiente: 1. La concepci´ on de un SBDF requiere solamente escasas especificaciones y requerimientos, tanto del SBDF como de los SBDs componentes. 2. La simplificaci´ on en la integraci´on de datos, desde diversas fuentes heterog´eneas a partir de un acceso compuesto. 3. La adopci´ on de tecnolog´ıas que permiten la gesti´on de informaci´on dispersa y heterog´enea. 17
Figura 9: Diagrama de despliegue del SBDF implementado parcialmente en la DIGIES. 4. Un uso no circunscrito a expertos del ´area de bases de datos; incluso los usuarios finales, distinguen una sola fuente de datos. 5. La demanda de requerimientos para su construcci´on se asientan en software gratuito, ampliamente utilizado y en su mayor´ıa de c´odigo libre. 6. Una administraci´ on 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´on 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´on u ´til, identificando datos relacionados dentro de la federaci´on.
5.
Conclusiones Se implement´ o un SBDF para gestionar la informaci´on heterog´enea en la DIGIES. Antes, se realiz´o un prototipo de SGBDF. La herramienta utilizada para construir la federaci´on permite realizar consultas de datos sobre todos los SBDs componentes, tambi´en inserciones, actualizaciones y eliminaciones de registros. Permite el alta, la baja y la eliminaci´ on de los SBDs componentes del SBDF. Adem´as cuenta con una interfaz gr´ afica de administraci´on para gestionar el SBDF.
18
La cantidad de recursos y tareas en una integraci´on de fuentes de datos heterog´eneas se reduce ejecutando un acceso integrado a toda la informaci´ on. El nivel de conocimientos necesarios para implantar un SBDF, var´ıa seg´ un la diversidad y la complejidad de las fuentes de datos a integrar, mientras que su administraci´ on, obedece en gran parte de los profesionales que la gestionen.
6.
Trabajos Futuros Desarrollar algoritmos adecuados de administraci´on de transacciones, que suministre un nivel puntual de consistencia y tolerancia en un rendimiento admisible, dentro de las restricciones que presentan la heterogeneidad y la autonom´ıa en un SBDF. Elaborar estad´ısticas del rendimiento y eficacia de las herramientas implementadas en la propuesta, contra otras herramientas y soluciones comerciales existentes (obviando la limitaci´on del caso de estudio). Difundir y promover entre las entidades gubernamentales del pa´ıs o empresas de gran porte, la posibilidad de integrar la gesti´on de informaci´on gracias a la implementaci´on de un SBDF. Implantar un software integrado, es decir un SGBDF, que contemple de una manera autom´ atica y amigable la implementaci´on de un SBDF.
Referencias [1] A. P. Sheth and J. A. Larson, “Federated database systems for managing distributed, heterogeneous, and autonomous databases,” ACM Computing Surveys (CSUR), vol. 22, no. 3, pp. 183–236, 1990. [2] R. King and D. McLeod, “A database design methodology and tool for information systems,” ACM Transactions on Information Systems (TOIS), vol. 3, no. 1, pp. 2–21, 1985. [3] F. Saltor and E. Rodr´ıguez, “On semantic issues in federated information systems,” in EFIS, 1999, pp. 1–4. [4] W. Litwin, “An overview of the multidatabase system mrdsm,” in Proceedings of the 1985 ACM annual conference on The range of computing: mid-80’s perspective: mid-80’s perspective. ACM, 1985, pp. 524–533. [5] W. Litwin, L. Mark, and N. Roussopoulos, “Interoperability of multiple autonomous databases,” ACM Computing Surveys (CSUR), vol. 22, no. 3, pp. 267–293, 1990.
19
[6] W. Litwin and A. Abdellatif, “Multidatabase interoperability,” Computer, vol. 19, no. 12, pp. 10–18, 1986. [7] A. Mu˜ noz, “Ontolog´ıa para bases de datos orientadas a objetos y multimedia ontolo gy for obj ectˆaoriented and multimedia databases,” Avances en Sistemas e Inform´ atica, vol. 6, no. 2, pp. 167–184, 2009. [8] R. Obermarck and M. H. Johnson, “Method and apparatus for reapplying changes to a database,” Oct. 26 1999, uS Patent 5,974,425. [9] S. Anahory and D. Murray, Data warehousing in the real world: a practical guide for building decision support systems. Addison-Wesley Longman Publishing Co., Inc., 1997. [10] C. Batini, M. Lenzerini, and S. B. Navathe, “A comparative analysis of methodologies for database schema integration,” ACM computing surveys (CSUR), vol. 18, no. 4, pp. 323–364, 1986. [11] R. H. Chiang, E.-P. Lim, and V. C. Storey, “Framework and knowledge for database integration,” in Managing Information Technology Resources and Applications in the World Economy: Proceedings of the 1997 Information Resources Management Association International Conference Vancouver, BC, Canada. IGI Global, 1997, p. 218. [12] D. O. Alfonso, T. P. Alfonso, D. K. Castro, and J. C. Iznaga, “Propuesta de herramientas para la integraci´on de datos,” Revista Cubana de Ingenier´ıa, vol. 3, no. 1, pp. 5–13, 2012.
20
