Análisis de Arquitecturas
description
Transcript of Análisis de Arquitecturas
Análisis de Arquitecturas
Sistemas Multifuentes
DBMS distribuídos y heterogéneos
DBMS Federados
DBMS Distribuídos y Heterogéneos
Esquema Global para Multiple-DBMS
DDBMS
Sistemas Interoperables
Lenguajes para Multiple-DBMS
Bases de Datos Distribuídas(DDBS)
DDBMS
BDD: Conjunto de datos lógicamente relacionados residentes en varias computadoras conectadas por una red de comunicación entre las que existe una aplicación global. [CP84]
Bases de Datos Distribuidas
• Los problemas más importantes a resolver desde el punto de vista del diseñador de bases de datos distribuidas son la definición de los fragmentos de datos y su ubicación teniendo en cuenta el control de redundancia. La definición de los fragmentos debe asegurar una adecuada concurrencia, las transacciones pueden ser divididas en varias subconsultas que operan sobre los fragmentos paralelamente, y una adecuada seguridad, ya que al separar los fragmentos se puede prohibir el acceso a fragmentos a usuarios no autorizados.
• La ubicación de los fragmentos debe intentar minimizar los costos de comunicación ubicando los fragmentos cerca de los lugares donde son más usados y usando redundancia controlada. Se puede disminuir la carga en las comunicaciones en la red haciendo réplicas de los fragmentos localmente, pero por otro lado, la necesidad de que todas las réplicas sean exactamente iguales en cada sitio dificulta el mantenimiento del sistema cuando las actualizaciones de estos fragmentos es una tarea muy frecuente. Por lo tanto, es conveniente el uso de redundancia cuando los fragmentos se leen frecuentemente y se actualizan poco.
• Notar que estos problemas no corresponden con los problemas relativos a bases de datos heterogéneas y autónomas, ya que en estas últimas la ubicación de los datos se encuentra predeterminada a priori.
Esquema Global
Esquema Global
Esquema local 1
Esquema local 2
Esquema local n
BD1 BD2 BDn
Ventajas:• Consistencia• Vista y acceso uniforme a datos• Distribución transparente al usuario.
Desventajas:• Pobre autonomía• Pobre automatización
Integración completa de varias DBS para proveer una vista única. [SP94]
Bases de Datos Federadas (FDBS)
FDBS: Una colección de sistemas de bases de datos independientes, cooperativos, posiblemente heterogéneos, que son autónomos y que permiten compartir todos o algunos de sus datos. [SL90]
FDBS
DBMS 1(centralizado)
BD1
Componente DBS 1
DBMS 2(distribuido)
BD2-1
Componente DBS 2
BD2-2
DBMS n(otro FDBS )
Componente DBS n
Bases de Datos Federadas (FDBS)(II)
Sistemas Integrados
Sistemas NO Federados Sistemas Federados
Sin autonomía de ejecución
Con autonomía de ejecución
Propiedad de los FDBS : Un DBS componente de un FDBS puede continuar sus operaciones locales y al mismo tiempo participar de la
federación (participar en la ejecución de una operación global)
Una sola federación Varias federaciones
Un esquema federado
Varios esq. federados
(Varias federaciones)
Fuertemente Acoplados Débilmente Acoplados
DBAs Usuarios
Esquema de Exportación 1
DB1
Esquema Local 1
Esquema Componente 1
Arquitectura de 5 Niveles FDBS
Esquema Federado
Esquema Externo Esquema Externo
DB2
Esquema Local 2
Esquema Componente 2
Esquema de Exportación 2
Common Data Model
Transforming processor Transforming
processor
Data Dictionary
Filtering processor Filtering processor
Arquitectura de 5 Niveles FDBS (II)
Esquema Federado
Esquema Externo Esquema ExternoVersion 1
Esquema de Exportación 1
CDBS1 DB1
Esquema Local 1
Esquema Componente 1
Esquema de Exportación 1 Esquema de Exportación 1
CDBS2 DB2
Esquema Local 2
Esquema Componente 2
Esquema de Exportación 2
Integración fuertemente acoplada
Carácterísticas:• DBA tiene control total sobre la creación y acceso a las DBS.
• Soporta uno o más esquemas federados.
Ventajas:• Actualizaciones pueden ser soportadas.
• Mantiene uniformidad en la interpretación de la semántica de múltiples datos integrados.
Desventajas:• Violación a autonomía (DBAs negocian lo que va en los esquemas de exportación).
• No soporta evolución dinámica de los esquemas de exportación o componentes.
Arquitectura de 5 Niveles FDBS (III)
Esquema Federado
Esquema Externo Esquema ExternoVersion 2
Esquema de Exportación 1
CDBS1 DB1
Esquema Local 1
Esquema Componente 1
Esquema de Exportación 2
CDBS2 DB2
Esquema Local 2
Esquema Componente 2
Integración débilmente acoplada
Carácterísticas:• Crear y mantener la federación es responsabilidad de los
usuarios a través de vistas.• Soporta DBS altamente autónomas
Ventajas:• Flexibilidad para mapear diferentes semánticas de mismos objetos en distintos export schemas.
• Mayor facilidad para manejar
evolución de los componentes.
Desventajas:• Dificultad en comprender grandes números de export schemas.
• Duplicación de esfuerzos.
• Problema de actualización de vistas.
FDBS con varios esquemas
Esquema de Exportación
Esquema Federado
Esquema Externo Esquema Externo
DB
Esquema Local
Esquema Componente
Esquema de Exportación
DB
Esquema Local
Esquema Componente
Esquema de Exportación
Esquema Federado
Esquema Externo
Múltiples Bases de Datos (MDBS)Integración basada en lenguajes
Query Mapping
Assistant
DB DB DB
Query mapper DB 1
Query mapper DB 2
Query mapper DB n
IntegratedQueryLanguage
Objetivo: Proveer constructores que realicen consultas envolviendo múltiples Bases de Datos a un mismo tiempo [Litwin94]
Múltiples Bases de Datos (MDBS)Integración basada en lenguajes(II)
Características:• BDs con intereses comunes son agrupadas con un nombre colectivo (ej. Restaurantes, Hoteles, etc.)
• Dependencias Inter-BD:– Dependencia de Equivalencia– Dependencia de Manipulación– Dependencias de Privacidad
• Consultas Inter-BD (copy and move datos •entre distintas BDs)
Múltiples Bases de Datos (MDBS)Integración basada en lenguajes(II)
Características:• BDs con intereses comunes son agrupadas con un nombre colectivo (ej. Restaurantes, Hoteles, etc.)• Dependencias Inter-BD:
– Dependencia de Equivalencia– Dependencia de Manipulación– Dependencias de Privacidad
• Consultas Inter-BD (copy and move datos entre distintas BDs)
Ventajas:
• No usan un esquema integrado.
• Son débilmente acoplados
Desventajas:• Falta de transparencia en la distribución y localización de los datos.
• Alto grado de responsabilidad del usuario
Multidatabases
• Algunos ejemplos de propuestas de lenguajes para múltiples bases de datos son: SchemaSQL [LSS96], MQL [WWG01] y nD-SQL [GL98].
• En [WWG01] se define el lenguaje declarativo Meta-Query Language como extensión de SQL, el cual posibilita reestructurar dinámicamente las consultas.
• Un elemento clave de la sintaxis de MQL es derivado de SchemaSQL, y es la posibilidad de incluir meta-variables en la cláusula FROM, para cada una de las cuales se recorre un rango de valores.
• Sintaxis MQL
<query> ::= SELECT <col_decls> INTO <name_term> WITHIN <name_term> FROM <variable_decl> {, <variable_decl>}* [WHERE <condition> {AND <condition>}*] | ( <query> ) UNION ( <query> ) | ( <query> ) MINUS ( <query> ) <col_decls> ::= <col_decl> {,<col_decl>}* <col_decl> ::= <name_term> AS <string> <variable_decl> ::= -> <varname(db)> | ( <query> ) -> <varname(db)> | <meta_atom(db)> -> <varname(rel)> | <meta_atom(db)> :: <varname(rel)> -> <varname(att)> | <meta_atom(db)> :: <varname(rel)> AS <varname(tup)> | <meta_atom(db)> -> <varname(rel)> <condition> ::= ( <condition> ) | <name_term> <cond_operator> <name_term> | [NOT] EXISTS ( <query> ) <cond_operator> ::= = |! = |<= | < | > | >= <name_term> ::= <string> | <varname(tup)>.<meta_atom(att)> | <var-name(_)> <meta_atom(X)> ::= <metaname> | <varname(X)> <metaname> ::= a-z{(a-z|A-Z|0-9|-|_)}* <varname(X)> ::= A-Z{(a-z|A-Z|0-9|-|_)}*
Semántica MQL
Las palabras claves INTO y WITHIN de la cláusula SELECT indican en qué relación y dentro de qué base de datos respectivamente se almacena el resultado de la consulta. Como permite incluir variables en INTO y WITHIN, la relación y base de datos de almacenamiento se determinan en tiempo de ejecución. Según la forma en que se declaran las variables, éstas tienen un dominio.
Ejemplo: ? d1::R1 -> A1, indica que la variable R1 es interpretada como el nombre de una relación
en la base de datos d1, y que la variable A1 es interpretada como el nombre de un atributo del esquema de esta relación.
? D2::r2 AS T2, indica que T2 varía sobre las tuplas de las relaciones llamadas r2 de cualquier base de datos participante. Debido a que en las arquitecturas de lenguaje para múltiples bases de datos es necesario conocer la estructura de los participantes para establecer el mapeamiento de las consultas, el grado de transparencia en la distribución de los datos se ve muy reducido. Asimismo requieren un alto grado de responsabilidad del usuario para lograr sus objetivos con éxito.
Sistemas Interoperables
Componente DBS 1
Sistemas legadosDBMS 1(centralizado)
BD1
DBMS 2(otro FDBS )
Componente DBS 2
Componente n
Sistema Interoperable
Características:• Componentes locales son cualquier tipo de datos.• Son los sistemas más débilmente acoplados• No soportan todas las funciones de DBMS
DBMS distribuidos y heterogéneos
distribución
heterogeneidad
autonomía
DBMS Federados
DBMS Distribuidos y Heterogéneos
Esquema Global para Multiple-DBMS
DDBMS
Sistemas Interoperables
Lenguajes para Multiple-DBMS
Niveles de integración de bases de datos
Autonomía
Control global
Lenguajes para Multi-Databases
BDFederadas
Esquema Global deMultiples DB
Bases de Datos Distribuidas
SistemasInteroperables
Integración de datos
• Traductors/Adaptadores (Wrappers): Convierten datos de las fuentes para el Modelo de Datos Común y convierten consultas de aplicaciones globales en consultas específicasde las fuentes de información.
• Mediadores: Sistema que soporta vistas integradas sobre múltiples fuentes de información.Integración de vistas solo para lectura (read-only).Integración de vistas para lectura y escritura (read-write).
• Enfoque Virtual vs. Materializado
Arquitectura de Mediadores
Mediador
Wrapper Wrapper WrapperWrapper
Mediador
Aplicación
Mediador
Wrapper
AplicaciónAplicación
Nivel I: Composición
ObjectsUnivDB
ObjectsLibDB
ObjectsStudDB
ObjectsUnivDB
Books Customers Students Employees
• UnivDB
titulo author
lent
name address
LibDB
name faculty name bdate dept
StudDB EmplDB
Nivel II: Integración Virtual
ObjectsLibDB
ObjectsStudDB
ObjectsUnivDB
Books Customers
Students Employees
• UnivDB
titulo author
lent
name address
LibDB
name faculty name bdate dept
StudDB EmplDB
same
Person
ObjectsUnivDB
Nivel III: Integración Real
ObjectsLibDB
ObjectsStudDB
ObjectsEmpDB
Books Customers
Students Employees
• UnivDB
titulo author
lent
name address
LibDB
name faculty name bdate dept
StudDB EmplDB
same
Personfavorite
ObjectsUnivDB
Comparación de los niveles de integración
Multi-db Federación BDD
Nivel 0 Nivel I Nivel II Nivel III Nivel IV Integración NO Compuestos Virtual Real Completa
esquemas
Unificacion Conj. de objetos disjuntos Funciones Funciones Unico
de objetos derivadas almacenadas conj. objetos
Consultas Transacciones Trans.Globales Queries con Actualiz. con Como en actualiz. Globales Restringidas OID Global OID Global BD centralizadas
Diccionario NO Solo para “instance-independent También para NO disponiblefederación information” “inst.-dependent”
Bibliografía
[CP84] Ceri S. and Pelagatti C. Distributed Databases, Principles and Systems McGraw-Hill, 1984
[Litwin94] Litwin, W. Multidatabase Systems.
Prentice Hall: Englewood Cliffs, N.Y., 1994.
[SL90] Sheth A.P. and Larson, J. A. Federated Database Systems and managing distributed,
heterogeneous, and autonomous databases. ACM Computing Surveys, 22(3):183-226, 1990.
[SP94] S. Spaccapietra and C. ParentView Integration: A step forward in solving structural
conflicts. IEEE Transactions on Knowledge and Data
Engineering, 6(2), 1994.