PreprintPDF Available

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

Authors:
Preprints and early-stage research may not have been peer reviewed yet.

Abstract and Figures

La investigacion en este trabajo pretende exponer una perspectiva clara del modo en que una Base de Datos Federada puede ser implementada y los conjuntos de tecnicas disponibles para este proposito. Un Sistema de Base de Datos Federada es una eleccion valida, si se necesita formular consultas simples (unicas), y recibir respuestas simples (unicas), pero que en la preparacion de la misma intervengan datos de varias fuentes. Se implementa un Sistema de Base de Datos Federadas por sobre otras soluciones, como un almacen de datos por ejemplo, para la gestion y la integracion de diversas fuentes de datos heterogeneas, dispersas en una organizacion gubernamental, de tal forma que toda esa informacion, en base a ciertos parametros, se pueda integrar totalmente y que, al mismo tiempo, permita la incorporacion 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 tecnologia de compuertas o enlaces de datos.
Content may be subject to copyright.
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
marvinanha@gmail.com
Mario Rub´en Canto,
Universidad Aut´onoma de Asunci´on,
Asunci´on, Paraguay
mario.canto@gmail.com
Jos´e Luis V´azquez Noguera,
Universidad Nacional de Asunci´on,
Asunci´on, Paraguay
jlvazquez@pol.una.py
19 de junio de 2016
Resumen La investigaci´on en este trabajo pretende exponer una perspecti-
va 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 sim-
ples (´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 het-
erog´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 re-
quiere 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´egi-
ca 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 compo-
nente siga atendiendo a sus aplicaciones locales, transparentando las operaciones
de distribuci´on para el usuario. Esta tecnolog´ıa es de un aprendiza je e imple-
mentaci´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 deman-
da 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 tec-
nolog´ı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 es-
tudio 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 resul-
tados esperados en el caso de estudio. Los ´ultimos 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, salvaguardan-
do 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 ortogo-
nales: la distribuci´on, la heterogeneidad y la autonom´ıa.
Los datos pueden distribuirse entre varias bases de datos de diferentes man-
eras, 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
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´ebil-
mente 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 acopla-
do, 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 ad-
ministradores. 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, dis-
puestos 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 frag-
mentaci´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 requi-
sitos 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 co-
mo globalmente. El procesamiento de consultas en un SGBDF presenta un costo
desigual de realizar una operaci´on en diferentes SBDs componentes, en contra-
partida 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 aproximada-
mente, 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 gener-
arse 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 exis-
ten 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 con-
sultas 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 hetero-
geneidad 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 utilizan-
do 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 man-
ual, 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 ´unico, 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 real-
izan directamente en el esquema f´ısico, siendo probable que los usuarios
no obtengan resultados vigentes porque los datos podr´ıan no estar actu-
alizados).
El mantenimiento del esquema (los cambios en las estructuras de los es-
quemas 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 almacenamien-
to 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 actualiza-
ciones 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´otona-
mente (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 significati-
vas. 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 es-
tados 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 mo-
tivadas 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 re-
fieren 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 ´ultimo, 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 het-
erog´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
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 Unifi-
cado 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 es-
tudio.
12
Figura 4: Propuesta de modelo de integraci´on federado aplicado al caso de es-
tudio.
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 soft-
ware 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 sis-
temas 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 admin-
istradas por la DIGIES, se optaron tres por el DBA para realizar su imple-
mentaci´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 me-
diante 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 het-
erog´eneas a partir de un acceso compuesto.
3. La adopci´on de tecnolog´ıas que permiten la gesti´on de informaci´on disper-
sa 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 soft-
ware gratuito, ampliamente utilizado y en su mayor´ıa de c´odigo libre.
6. Una administraci´on establecida sobre un motor de base de datos obje-
to/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
´util, 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 con-
sultas 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 informa-
ci´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 imple-
mentadas en la propuesta, contra otras herramientas y soluciones comer-
ciales existentes (obviando la limitaci´on del caso de estudio).
Difundir y promover entre las entidades gubernamentales del pa´ıs o em-
presas 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 Pro-
ceedings 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 multime-
dia 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
ResearchGate has not been able to resolve any citations for this publication.
Full-text available
Article
Las bases de datos multimedia han tenido un gran desarrollo en los últimos años. El uso efectivo de metadatos multimedia requiere de bases de datos para administrar, almacenar, buscar y entregar metadatos. Estas bases de datos necesitan tener conocimientos acerca de la ubicación de los datos media y de los metadatos y debe enlazar descripciones de uso con los requerimientos de recursos media. Todo esto implica una serie de manipulaciones a través de parámetros muy específicos que contemplen su semántica, es decir sus conceptos, operaciones y restricciones. En este artículo se muestra una ontología para representar los conceptos, operaciones y restricciones que tienen las bases de datos multimedia. Adicionalmente como las bases de datos orientadas a objetos describen el comportamiento de las bases de datos multimedia, también se presenta su descripción ontológica. Finalmente se validan dichas ontologías a través de un caso de estudio y utilizando Protégé.
Full-text available
Article
A federated database system (FDBS) is a collection of cooperating database systems that are autonomous and possibly heterogeneous. In this paper, we define a reference architecture for distributed database management systems from system and schema viewpoints and show how various FDBS architectures can be developed. We then define a methodology for developing one of the popular architectures of an FDBS. Finally, we discuss critical issues related to developing and operating an FDBS.
Article
Database systems were a solution to the problem of shared access to heterogeneous files created by multiple autonomous applications in a centralized environment. To make data usage easier, the files were replaced by a globally integrated database. To a large extent, the idea was successful, and many databases are now accessible through local and long-haul networks. Unavoidably, users now need shared access to multiple autonomous databases. The question is what the corresponding methodology should be. Should one reapply the database approach to create globally integrated distributed database systems or should a new approach be introduced? We argue for a new approach to solving such data management system problems, called multidatabase or federated systems. These systems make databases interoperable, that is, usable without a globally integrated schema. They preserve the autonomy of each database yet support shared access. Systems of this type will be of major importance in the future. This paper first discusses why this is the case. Then, it presents methodologies for their design. It further shows that major commerical relational database systems are evolving toward multidatabase systems. The paper discusses their capabilities and limitations, presents and discusses a set of prototypes, and, finally, presents some current research issues.
Article
A model and methodology for describing the information objects in an office information system and how such objects flow among the components of such a system are presented. The model and methodology support the specification of information objects at multiple levels of abstraction. An interactive prototype design tool based on the methodology and model has been designed and experimentally implemented.
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
  • W Litwin
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.