Arquitecturas de las BDD

1
Arquitecturas de las BDD

• Lic. Bárbara da Silva

Sistemas de Bases de Datos Distribuidas - UCV
2
Esquema de la Clase

• Arquitectura de las BDD
• Transparencia
• Niveles de Transparencia
• Quién debe proveer la transparencia?
• Modelo de Referencia
• Arquitectura ANSI/SPARC
• Ejemplo de la Arquitectura ANSI/SPARC
• Arquitectura de un SMBDD

3
Arquitectura de las BDD

• La Arquitectura define la estructura de un
  sistema.
• Componentes
• Funciones de los componentes
• Interrelaciones entre los componentes
• El propósito de establecer una arquitectura para
  un sistema de bases de datos distribuidas es
  ofrecer un nivel de transparencia adecuado para
  el manejo de la información.

4
Transparencia

• El término transparente significa que la
  aplicación trabajaría, desde un punto de vista
  lógico, como si un solo Sistema Manejador de
  Bases de Datos (SMBD) ejecutado en una sola
  máquina, administrara esos datos.
• La transparencia se puede entender como la
  separación de la semántica de alto nivel de un
  sistema de los aspectos de bajo nivel
  relacionados a la implementación del mismo.

5
Niveles de Transparencia
Transparencia del Lenguaje
Transparencia de Fragmentación
Transparencia de Replicación
Transparencia de Red
Independencia de Datos
Datos
6
Independencia de Datos

• La independencia de datos es la inmunidad de las
  aplicaciones de usuario a los cambios en la
  definición y/u organización de los datos y
  viceversa.
• Se puede dar en dos aspectos
• Independencia lógica de datos Se refiere a la
  inmunidad de las aplicaciones de usuario a los
  cambios en la estructura lógica (cambios en la
  definición del esquema) de la base de datos.
• Independencia física de datos Se refiere al
  ocultamiento de los detalles sobre las
  estructuras de almacenamiento a las aplicaciones
  de usuario.

7
Transparencia de Red

• La transparencia de red se refiere a que los
  datos en un SBDD se accedan sobre una red de
  computadoras sin que las aplicaciones noten su
  existencia.
• La transparencia al nivel de red conlleva a dos
  cosas
• Transparencia sobre la localización de datos El
  comando que se usa es independiente de la
  ubicación de los datos en la red y del lugar en
  donde la operación se lleve a cabo.
• Transparencia sobre el esquema de nombramiento
  Lo anterior se logra proporcionando un nombre
  único a cada objeto en el sistema distribuido.

8
Transparencia de Replicación

• La transparencia sobre replicación de datos se
  refiere a que si existen réplicas de objetos de
  la base de datos, su existencia debe ser
  controlada por el SMBDD, no por el usuario.

9
Transparencia de Fragmentación

• La transparencia a nivel de fragmentación de
  datos permite
• El sistema maneje la conversión de consultas de
  usuario definidas sobre relaciones globales a
  consultas definidas sobre fragmentos.
• Las respuestas a consultas fragmentadas para
  obtener una sola respuesta a una consulta global.
  

Query sobre Fragmentos
Query Global
Query sobre Fragmentos
Query sobre Fragmentos
10
Transparencia del Lenguaje

• Permite la transparencia de acceso por medio del
  DML (Lenguaje de Manipulación de Datos).
• Forma en que el usuario accede a la data
• Lenguajes de Programación
• Interfaces gráficas
• Sistemas de voz
• Otros.

11
Quién debe proveer la transparencia?

• La responsabilidad sobre el manejo de
  transparencia debe estar compartida por
• El sistema operativo
• El sistema de manejo de bases de datos y
• El lenguaje de acceso a la base de datos
  distribuida.

12
Modelo de Referencia

• Para definir una arquitectura se sigue un modelo
  de referencia. A partir del modelo de referencia
  se puede llegar a una estandarización.
• Un modelo de referencia permite dividir el
  trabajo de estandarización en partes y mostrar
  como esas partes se relacionan unas con otras.
• Existen tres enfoques para describir un modelo de
  referencia
• Componentes
• Funciones
• Datos -gt ANSI/SPARC

13
Arquitectura ANSI/SPARC

• La arquitectura ANSI/SPARC es un framework
  propuesto debido a la necesidad de estandarizar
  la arquitectura de los SMBD. Dicho framework se
  basa en la organización de la data.
• Divide al sistema en tres vistas
• Externa -gt Usuario
• Conceptual -gt Negocio
• Interna -gt Sistema ó Máquina

14
Arquitectura ANSI/SPARC
Usuarios
Vista Externa
Vista Externa
Vista Externa
Esquema Externo
Vista Conceptual
Esquema Conceptual
Vista Interna
Esquema Interno
15
Ejemplo de Arquitectura ANSI/SPARC

• Para los ejemplos
• Nos basamos en el modelo relacional.
• La sintaxis no es parte de un lenguaje
  específico.
• Las vistas externas serán descritas en SQL.
• Ejemplo de Vista Conceptual
• Empleado (numEmpleado, nombre, cargo)
• Sueldo (titulo, salario)
• Proyecto (numProyecto, nombre, presupuesto)
• Asignación (numEmpleado, numProyecto,
  responsabilidad, duración)

16
Ejemplo de Arquitectura ANSI/SPARC

• Ejemplo de Vista Interna
• Rel_Interna Empleado (
• INDEX ON E CALL EMINX
• CAMPOS HEADER BYTE(1)
• E BYTE(9)
• ENOMBRE BYTE(15)
• TIT BYTE(10)
• )

17
Ejemplo de Arquitectura ANSI/SPARC

• Ejemplo de Vista Externa
• CREATE VIEW nomina AS
• SELECT Empleado.NumEmpleado, Empleado.Nombre,
  Sueldo.Salario
• FROM Empleado, Sueldo
• WHERE Empleado.Cargo Sueldo.Cargo
• CREATE VIEW presupuestos AS
• SELECT Proyecto.Nombre, presupuesto
• FROM Proyectos

18
Tarea

• Características de distribución en los SMBD
  Comerciales
• Tipos de Distribución en los SMBD Comerciales.
• Transparencia en los SMBD comerciales.
• Recuperar el nombre del proveedor de un producto.
  Se asume que
• El número del producto es dado por el usuario.
• Un producto es suplido por un solo proveedor.
• Escriba la consulta para cada uno de los niveles
  de transparencia

19
Arquitectura de un SMBDD

• La arquitectura se puede especificar de acuerdo
  a
• Autonomía se refiere al grado de operación
  independiente de un SMBD. Se refiere a la
  distribución del control.
• Distribución se refiere a la distribución de la
  data.
• Heterogeneidad se refiere a las diferencias en
  cuanto a hardware, protocolos de red y SMBD
  (modelos de datos, lenguajes para realizar las
  consultas y el manejo de transacciones).

20
Arquitectura de un SMBDD

• Los requerimientos que debe cumplir un sistema
  autónomo
• Las operaciones locales no se ven afectadas por
  la participación en el sistema de multi base de
  datos.
• El procesamiento de querys local no afecta la
  ejecución de los querys globales.
• Se debe mantener la consistencia cuando los
  SMBD locales se unan para la multi base de datos.

21
Arquitectura de un SMBDD

• Las dimensiones de la autonomía
• Autonomía en el Diseño -gt modelo de datos y
  manejo de transacciones.
• Autonomía de Comunicación -gt información a
  proveer a otros SMBD.
• Autonomía de Ejecución -gt ejecución de las
  transacciones

22
Arquitectura de un SMBDD
Nombre Descripción
Autonomía Integración Fuerte A0 Uno de los nodos es el que controla las peticiones de los usuarios, incluso si la petición incluye
Autonomía Semi-autónomo A1 Cada SMBD determina que parte de su propia BD va a compartir. No es totalmente autónomo porque necesita modificar su esquema para compartir la data.
Autonomía Aislamiento total A2 SMBD que no saben de la existencia de otros DBMS ni cómo comunicarse entre sí.
Distribución Cliente/Servidor D1 Se diferencias los nodos como clientes (vista al usuario) o servidores (manejo de la data).
Distribución Peer to Peer D2 Todos los nodos tienen igualdad de funciones
Heterogeneidad Homogéneos H0 Hardware Red SMBD
Heterogeneidad Heterogéneos H1 Hardware Red SMBD
23
Arquitectura Cliente/Servidor

• (Ax, D1, Hy)
• Servidores -gt procesamiento y optimizacion de
  querys, manejo de transacciones y almacenamiento
  de la data.
• Clientes -gt interfaz al usuario, manejo de data
  en cache y manejo de bloqueos de transacciones de
  la cache.

SO
User interface
SMBD Cliente
Software de Comunicación
Queries SQL
Relación Resultado
BD
24
Arquitectura Peer to Peer

• (A0, D2, H0)
• Esquema Interno Local definición interna de los
  data en cada nodo.
• Esquema Conceptual Global modela la información
  contenida en una colección de BD.
• Esquema Conceptual Local organización lógica de
  la data local.
• Esquema Externo vista a los usuarios de los
  datos.

25
Arquitectura Peer to Peer
Usuarios
Vista Externa
Vista Externa
Esquema Externo
Esquema Conceptual Global
Esquema Global
Esquema de Fragmentación
Esquema de Asignación
Esquemas Conceptuales Locales
Vista Conceptual Local 1
Vista Conceptual Local n
Esquemas Internos Locales
Vista Interna Local 1
Vista Interna Local n
26
Arquitectura Multi-Base de Datos

• (A2, Dx, Hy)
• La principal diferencia entre una arquitectura
  peer to peer (arquitectura de BDD) con una
  arquitectura de multi base de datos es la
  definición de un esquema global.
• BDD -gt El Esquema Conceptual Global define la
  vista conceptual de toda la BD.
• Multi-BD -gt El Esquema Conceptual Global
  representa la colección de BD locales que cada
  SMBD local quiera compartir.

27
Arquitectura Multi-Base de Datos

• Arquitectura de Multi Bases de Datos con un
  Esquema Conceptual Global

VEG1
VEG2
VEG3
ECG
VEL11
VEL12
VEL13
VELn1
VELn2
VELnm
...
ECL1
ECLn
...
EIL1
EILn
28
Arquitectura Multi-Base de Datos

• Arquitectura de Multi Bases de Datos sin un
  Esquema Conceptual Global

VE1
VE2
VE3
Capa de Multi BD
Capa de Sistemas Locales
ECL1
ECLn
ECL2
EIL1
EILn
EIL2
29
Arquitectura Multi-Base de Datos

• BD Federadas
• No usan un Esquema Conceptual Global sino que
  cada SMBD define un esquema export el cual indica
  cual es la data que va a compartir con los otros
  SMBD.
• Cada aplicación que accede a la BD Federada
  define un esquema import (es como una vista
  externa global)
• En Conclusión
• BDD -gt Existen verdaderos SMBDs cada uno
  manejando una BD diferente
• MBD -gt Provee una capa de software que corre
  sobre un SMBD individual que le provee al usuario
  acceder a varias BD.

30
Tarea

1. Relacionar los conceptos presentados con los SMBD
   Comerciales.
2. En que arquitectura ubican los SMBD Comerciales?