Análisis de Arquitecturas

28
Análisis de Arquitecturas Sistemas Multifuentes

description

Análisis de Arquitecturas. Sistemas Multifuentes. DBMS distribuídos y heterogéneos. Lenguajes para Multiple-DBMS. DBMS Federados. DDBMS. DBMS Distribuídos y Heterogéneos. Esquema Global para Multiple-DBMS. Sistemas Interoperables. DDBMS. Bases de Datos Distribuídas(DDBS). - PowerPoint PPT Presentation

Transcript of Análisis de Arquitecturas

Page 1: Análisis de Arquitecturas

Análisis de Arquitecturas

Sistemas Multifuentes

Page 2: Análisis de Arquitecturas

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

Page 3: Análisis de Arquitecturas

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]

Page 4: Análisis de Arquitecturas

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.

Page 5: Análisis de Arquitecturas

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]

Page 6: Análisis de Arquitecturas

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

Page 7: Análisis de Arquitecturas

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

Page 8: Análisis de Arquitecturas

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

Page 9: Análisis de Arquitecturas

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

Page 10: Análisis de Arquitecturas

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.

Page 11: Análisis de Arquitecturas

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

Page 12: Análisis de Arquitecturas

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.

Page 13: Análisis de Arquitecturas

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

Page 14: Análisis de Arquitecturas

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]

Page 15: Análisis de Arquitecturas

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)

Page 16: Análisis de Arquitecturas

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

Page 17: Análisis de Arquitecturas

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|-|_)}*

Page 18: Análisis de Arquitecturas

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.

Page 19: Análisis de Arquitecturas

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

Page 20: Análisis de Arquitecturas

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

Page 21: Análisis de Arquitecturas

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

Page 22: Análisis de Arquitecturas

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

Page 23: Análisis de Arquitecturas

Arquitectura de Mediadores

Mediador

Wrapper Wrapper WrapperWrapper

Mediador

Aplicación

Mediador

Wrapper

AplicaciónAplicación

Page 24: Análisis de Arquitecturas

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

Page 25: Análisis de Arquitecturas

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

Page 26: Análisis de Arquitecturas

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

Page 27: Análisis de Arquitecturas

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”

Page 28: Análisis de Arquitecturas

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.