Análisis de Arquitecturas

Presentación del tema: "Análisis de Arquitecturas"— Transcripción de la presentación:

1 Análisis de Arquitecturas
Sistemas Multifuentes Análisis de Arquitecturas

2 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

3 Bases de Datos Distribuídas(DDBS)
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] DDBMS

4 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.

5 Esquema Global Integración completa de varias DBS para
proveer una vista única. [SP94] 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

6 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 Componente DBS 2 Componente DBS n DBMS 2 (distribuido) DBMS n (otro FDBS ) BD2-1 BD2-2

7 Bases de Datos Federadas (FDBS)(II)
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) Sistemas Integrados Sistemas NO Federados Sistemas Federados Sin autonomía de ejecución Con autonomía Fuertemente Acoplados Débilmente Acoplados DBAs Usuarios Una sola federación Varias federaciones Un esquema federado Varios esq. federados (Varias federaciones)

8 Arquitectura de 5 Niveles FDBS
Data Dictionary Esquema Externo Esquema Externo Esquema Federado Esquema de Exportación 1 Esquema de Exportación 2 Filtering processor Common Data Model Esquema Componente 1 Esquema Componente 2 Transforming processor Esquema Local 1 Esquema Local 2 DB1 DB2

9 Arquitectura de 5 Niveles FDBS (II)
Version 1 Esquema Externo Esquema Externo Esquema Federado Esquema de Exportación 1 CDBS1 DB1 Esquema Local 1 Esquema Componente 1 Esquema de Exportación 1 CDBS2 DB2 Esquema Local 2 Esquema Componente 2 Esquema de Exportación 2

10 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.

11 Arquitectura de 5 Niveles FDBS (III)
Version 2 Esquema Externo Esquema Externo Esquema Federado 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

12 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.

13 FDBS con varios esquemas
Esquema Externo Esquema Externo Esquema Externo Esquema Federado Esquema Federado Esquema de Exportación Esquema de Exportación Esquema de Exportación Esquema Componente Esquema Componente Esquema Local Esquema Local DB DB

14 Múltiples Bases de Datos (MDBS) Integración basada en lenguajes
Objetivo: Proveer constructores que realicen consultas envolviendo múltiples Bases de Datos a un mismo tiempo [Litwin94] Integrated Query Language Query mapper DB 1 Query mapper DB 2 Query mapper DB n Query Mapping Assistant DB DB DB

15 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)

16 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

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

18 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.

19 Sistemas Interoperables
Características: Componentes locales son cualquier tipo de datos. Son los sistemas más débilmente acoplados No soportan todas las funciones de DBMS Sistema Interoperable Componente DBS 1 DBMS 2 (otro FDBS ) Componente DBS 2 Componente n DBMS 1 (centralizado) Sistemas legados BD1

20 DBMS distribuidos y heterogéneos
DBMS Federados DBMS Distribuidos y Heterogéneos Esquema Global para Multiple-DBMS DDBMS Sistemas Interoperables Lenguajes para Multiple-DBMS distribución heterogeneidad autonomía

21 Niveles de integración de bases de datos
Control global Lenguajes para Multi- Databases BD Federadas Esquema Global de Multiples DB Bases de Datos Distribuidas Sistemas Interoperables Autonomía

22 Integración de datos 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). 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. Enfoque Virtual vs. Materializado

23 Arquitectura de Mediadores
Aplicación Aplicación Aplicación Mediador Mediador Wrapper Mediador Wrapper Wrapper Wrapper Wrapper

24 Nivel I: Composición Objects UnivDB Objects LibDB Objects StudDB
EmplDB Objects LibDB Objects StudDB Objects UnivDB Books Customers Students Employees lent titulo author name address name faculty name bdate dept

25 Nivel II: Integración Virtual
Objects UnivDB UnivDB LibDB StudDB EmplDB Objects LibDB Objects StudDB Objects UnivDB Person same Books Customers Students Employees lent titulo author name address name faculty name bdate dept

26 Nivel III: Integración Real
Objects UnivDB UnivDB LibDB StudDB EmplDB Objects LibDB Objects StudDB Objects EmpDB favorite Person same Books Customers Students Employees lent titulo author name address name faculty name bdate dept

27 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 disponible federación information” “inst.-dependent”

28 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): , 1990. [SP94] S. Spaccapietra and C. Parent View Integration: A step forward in solving structural conflicts. IEEE Transactions on Knowledge and Data Engineering, 6(2), 1994.