Download [Product Name] Marketing Plan

Arquitecturas de las BDD
Lic. Bárbara da Silva
Sistemas de Bases de Datos Distribuidas - UCV
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
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.
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.
Niveles de Transparencia
Transparencia del Lenguaje
Transparencia de Fragmentación
Transparencia de Replicación
Transparencia de Red
Independencia de Datos
Datos
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.
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.
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.
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
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.
¿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.
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 -> ANSI/SPARC
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 -> Usuario
Conceptual -> Negocio
Interna -> Sistema ó Máquina
Arquitectura ANSI/SPARC
Usuarios
Esquema Externo
Vista
Externa
Vista
Externa
Esquema Conceptual
Vista
Conceptual
Esquema Interno
Vista
Interna
Vista
Externa
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)
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)
}
)
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
Tarea
1. Características de distribución en los SMBD Comerciales
2. Tipos de Distribución en los SMBD Comerciales.
3. Transparencia en los SMBD comerciales.
4. 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
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).
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.
Arquitectura de un SMBDD
Las dimensiones de la autonomía:
Autonomía en el Diseño -> modelo de datos y manejo de transacciones.
Autonomía de Comunicación -> información a proveer a otros SMBD.
Autonomía de Ejecución -> ejecución de las transacciones
Arquitectura de un SMBDD
Nombre
Integración Fuerte
Autonomía
A0 Uno de los nodos es el que controla las
peticiones de los usuarios, incluso si la
petición incluye
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.
Aislamiento total
A2 SMBD que no saben de la existencia de otros
DBMS ni cómo comunicarse entre sí.
Cliente/Servidor
D1 Se diferencias los nodos como clientes (vista
al usuario) o servidores (manejo de la data).
Peer to Peer
D2 Todos los nodos tienen igualdad de funciones
Homogéneos
H0 Hardware
Red
H1 SMBD
Distribución
Heterogeneidad
Descripción
Heterogéneos
Arquitectura Cliente/Servidor
(Ax, D1, Hy)
Servidores -> procesamiento y optimizacion de querys, manejo de
transacciones y almacenamiento de la data.
Clientes -> interfaz al usuario, manejo de data en cache y manejo de
bloqueos de transacciones de la cache.
User interface
SO
SMBD Cliente
Software de Comunicación
Queries SQL
Relación Resultado
Software de Comunicación
SO
SMBD Servidor
BD
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.
Arquitectura Peer to Peer
Usuarios
Esquema Externo
Vista
Externa
Esquema
Conceptual Global
Vista
Externa
Esquema
Global
Esquema de
Fragmentación
Esquema de
Asignación
Esquemas
Vista Conceptual
Conceptuales Locales
Local 1
Esquemas
Internos Locales
Vista Interna
Local 1
Vista Conceptual
Local n
Vista Interna
Local n
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 -> El Esquema Conceptual Global define la vista conceptual de toda
la BD.
Multi-BD -> El Esquema Conceptual Global representa la colección de BD
locales que cada SMBD local quiera compartir.
Arquitectura Multi-Base de Datos
Arquitectura de Multi Bases de Datos con un Esquema Conceptual Global
VEL11
VEL12
VEG1
VEG2
VEG3
VEL13
ECG
VELn1
VELn2
ECL1
...
ECLn
EIL1
...
EILn
VELnm
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
ECL2
ECLn
EIL1
EIL2
EILn
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 -> Existen verdaderos SMBDs cada uno manejando una BD diferente
MBD -> Provee una capa de software que corre sobre un SMBD individual
que le provee al usuario acceder a varias BD.
Tarea
1. Relacionar los conceptos presentados con los SMBD Comerciales.
2. ¿En que arquitectura ubican los SMBD Comerciales?