1
© A. Illarramendi UPV/EHU
Aspectos de Administración
? Seguridad
? Concurrencia
? Recuperación
2
Hasta ahora: Entorno Centralizado
En adelante: Entorno Distribuido
© A. Illarramendi UPV/EHU3
Gestión Distribuida de los Datos
Bases de Datos Distribuidas
Arquitecturas Cliente/Servidor
Aspectos sobre Paralelismo y Movilidad
© A. Illarramendi UPV/EHU4
Entornos Distribuidos
? Bases de Datos Distribuidas. Precisan al menos dos servidores de Bases de Datos
? Cliente/Servidor. Separan el rol del servidor del rol del cliente.
? Base de Datos Paralelas. Usan máquinas multiprocesadores y varios dispositivos de almacenamiento de datos.
? Computación Móvil. Se trabaja con dispositivos fijos y móviles.
5
Bases de Datos Distribuidas
© A. Illarramendi UPV/EHU6
Bibliografía
? Elmasri, NavatheFundamentals of Database Systems (4.edición 2004).Fundamentos de Sistemas de Bases de Datos (3.edición, 2002)Addisson Wesley
? Ozu, ValduriezPrinciples of Distributed Database Systems (2. edici ón)Prentice Hall International Inc.
? T. Connolly, C. BeggSistemas de Bases de Datos. Un enfoque práctico para diseño, implementación y gestión. (4. edici ón, 2005) Addison-Wesley
2
© A. Illarramendi UPV/EHU7
Índice
? 1. Motivación? 2. Nociones generales de las BDD? 3. Organización de los sistemas de BDD? 4. Objetivo de las BDD? 5. Ventajas y Desventajas de BDD? 6. Componentes de un SBDD? 7. Diseño en las BDD? 8. Procesamiento de Preguntas? 9. Modelo de Transacciones Distribuidas y Control de Concurrencia? 10. RESTRICCIONES DE INTEGRIDAD en Bases de Datos Distribuidas? 11. SEGURIDAD en Bases de Datos Distribuidas? 12. Clasificación de SBDD? 13. BDD en ORACLE
© A. Illarramendi UPV/EHU8
1. Motivación
Reggie comentó: “Pienso que estamos haciendo un buen trabajo. Nosotros tenemos en casa laúltima tecnología relacional, hemos educado a los usuarios en cada área funcional del negocio y hay evidencias de que nuestros sistemas de información se usan cada vez más para apoyar la toma de decisiones en todas partes dentro de la compañía.”
“En general, estoy de acuerdo contigo”, respondió Cordelia. ‘Pero siento que aún hay mucho por hacer. Muchos de nuestros jefes se encuentran en sitios remotos en todas partes del país y he oído rumores de que a ellos les gustaría tener control sobre las partes del sistema de base de datos que tienen que ver con sus operaciones. De hecho, una de l as jefas me comentó que no entendía por qué los datos deben mantenerse en la base de datos colectiva cuando era principalmente actualizada y usada por ella.”
“Suena como si nosotros debi éramos examinar la distribuci ón de nuestra base de datos,’ sugirióReggie. ¿Qué tipo de cambios habría que hacer si nos movemos en esa dirección?”
? “Bueno”, dijo Cordelia, “Como primera medida, tendríamos que decidir qué datos pueden mantenerse localmente y qué datos deberían hacerse centralmente. Y si aún quisiéramos hacer que ciertos datos corporativos estén disponibles en sitios remotos, nuestros sistemas para controlar el acceso a los datos tendrían que ser más sofisticados para permitir que sean ejecutadas consultas que requieran datos de más de un sitio.
© A. Illarramendi UPV/EHU9
1. BD Distribuidas: Motivación
Tecnología de Bases de Datos (tradicional)Centralización de datos
Varios Ficheros Una Base de DatosRedes de Computadores
Distribución/Compartición de recursosBD centralizada BD distribuida (¿varias BDs?)
BD Distribuidas: unión de estas dos aproximaciones (aparentemente opuestas)
La tecnología de BD busca la INTEGRACIÓN de los datos y no la CENTRALIZACIÓN
© A. Illarramendi UPV/EHU10
1. BD Distribuidas v.s BD Centralizadas
? La diferencia principal entre los sistemas de bases de datos centralizados y los distribuidos es que en los primeros los datos residen en una sola ubicación, mientras que en los últimos los datos residen en varias ubicaciones.
Esta distribuci ón de los datos es causa de muchas dificultades en el procesamiento de transacciones y preguntas
© A. Illarramendi UPV/EHU11
2. Definición de BD Distribuida
? BD que no esta almacenada en una única posición física, sino que esta repartida en distintos lugares geográficamente dispersos y conectados vía enlaces de comunicación, pudiendo los usuarios de cada nodo acceder a todos los datos.
? Colección de datos que pertenecen l ógicamente al mismo sistema
pero físicamente están dispersos en distintos lugares de una red.
© A. Illarramendi UPV/EHU12
Ejemplo de BDD (fragmentación y asignación)
Red deComunicaciones
BARCELONAEMPLEADOS (Barcelona)PROYECTOS (Barcelona)
SEVILLAEMPLEADOS (Sevilla)PROYECTOS (Sevilla)
MADRID (sede central)EMPLEADOS (todos)PROYECTOS (todos)
BILBAOEMPLEADOS (Bilbao)PROYECTOS (Bilbao)
3
© A. Illarramendi UPV/EHU13
DB LINK. ORACLE (enlace)
? Un DB LINK define un camino desde una BD ORACLE a otra BD (pero no viceversa). Se almacena en el catálogo
(SELECT db_link FROM user_db_links;)? ¿Por qué usar un links?
– Un usuario local puede acceder a trav és de un link a una BD remota sin ser usuario de dicha base remota.
– Permiten a los usuarios acceder a las BDs como si se tratara de una única BD lógica.
– Permite limitar el acceso a base de datos remotas a usuarios locales
? Es transparente para los usuarios.
© A. Illarramendi UPV/EHU14
2. SGBDD
? Un sistema de gestión de bases de datos distribuidas (SGBDD) es el software que permite el manejo de bases de datos distribuidas y que hace dicha distribución transparente al usuario.
Transparente significa: las aplicaciones trabajaran, desde un punto de vista l ógico, como sí un solo SGBD ejecutado en una sola máquina, administrara esos datos.
© A. Illarramendi UPV/EHU15
Formulación de Preguntas
SELECT *FROM TABLA@NOMBREDB LINK
del usuario que hace la preguntaSELECT *FROM Usuario.tabla@NOMBREDBLINK
de otro usuario© A. Illarramendi UPV/EHU16
2. Arquitectura de un Sistema de BDD
? Conjunto de nodos que operan con SBD locales que pueden participar en la ejecución de transacciones que acceden a datos de varios nodos
? Cada servidor tiene capacidad para manejar las aplicaciones independientemente.
? PA. Procesador de Aplicaciones. Software encargado de las funciones de distribución.
?SBDD = BDD + SGBDD
SGBDPABD
SGBDPABD
SGBDPABD NODO
RED DE COMUNICACIONES
© A. Illarramendi UPV/EHU17
Configuraciones en Red
© A. Illarramendi UPV/EHU18
2. Configuraciones de la red
? Las configuraciones pueden compararse entre si basándose en los siguientes criterios :
– Coste de instalaci ón: el costo de enlazar físicamente los nodos del sistema
– Coste de comunicaciones: coste en tiempo y dinero de enviar un mensaje desde el nodo A al B
– Disponibilidad : grado en que se puede tener acceso a los datos a pesar del fallo de algunos enlaces o nodos.
4
© A. Illarramendi UPV/EHU19
2. Nodos de la arquitectura
? En los nodos pueden existir:– Usuarios locales. Solo acceden a datos de su nodo
– Usuarios globales. Necesitan acceder a datos almacenados en distintos nodos.
© A. Illarramendi UPV/EHU20
2. BD remotas vs BD distribuidas
? BD remotas: El usuario especifica los comandos de comunicación
? BD distribuidas: Proporcionan transparencia de la distribución. Los usuarios formulan las preguntas como si se tratara de una BD centralizada.
© A. Illarramendi UPV/EHU21
3. Organización de los sistemas de BDD
Tradicionalmente se ha clasificado la organización de los sistemas de bases de datos distribuidos sobre tres dimensiones: el nivel de compartición, las características de acceso a los datos y el nivel de conocimiento de esas características de acceso
© A. Illarramendi UPV/EHU22
3. Organización de los sistemas de BDD
? El nivel de compartición presenta tres alternativas: – 1. Inexistencia, cada aplicación y sus datos se ejecutan en un
ordenador con ausencia total de comunicación con otros programas u otros datos;
– 2. Se comparten sólo los datos y no los programas, en tal caso existe una réplica de las aplicaciones en cada máquina y los datos viajan por la red (BDD)
– 3. Se reparten datos y programas , dado un programa ubicado en un determinado sitio, éste puede solicitar un servicio a otro programa localizado en un segundo lugar, el cual podrá acceder a los datos situados en un tercer emplazamiento.
© A. Illarramendi UPV/EHU23
3. Organización de los sistemas de BDD
? Respecto a las características de accesoa los datos existen dos alternativas principalmente:
– 1. Estático, el modo de acceso a los datos que solicitan los usuarios es estático, es decir, no cambiará a lo largo del tiempo
– 2. Dinámico (BDD)
Resulta dif ícil encontrar sistemas distribuidos reales que puedan clasificarse como estáticos. Sin embargo, lo realmente importante radica, estableciendo el dinamismo como base, cómo de dinámico es, cuántas variaciones sufre a lo largo del tiempo. Esta dimensión establece la relación entre el diseño de bases de datos distribuidas y el procesamiento de consultas.
© A. Illarramendi UPV/EHU24
3. Organización de los sistemas de BDD
? El nivel de conocimiento de las características de accesopresenta dos alternativas:
– 1. Los diseñadores carecen de información alguna sobre cómo los usuarios acceden a la base de datos. Es una posibilidad teórica, pero sería muy laborioso abordar el diseño de la base de datos con tal ausencia de información.
– 2. Los diseñadores conocen con detenimiento la forma de acceso de los usuarios o, en el caso una información parcial de ésta. (BDD)
5
© A. Illarramendi UPV/EHU25
4. Objetivo de las BD Distribuidas
? Transparencia: Separación del nivel semántico del sistema (nivel alto) de los aspectos de implementación (bajo nivel)
Proporcionar INDEPENDENCIA DE DATOS
? Tipos de transparencia:– en la distribución (o en la red)– en las copias– en la fragmentación
© A. Illarramendi UPV/EHU26
4. Transparencia en la distribución
? El usuario no debe conocer detalles operacionales de la red. Se divide en:
– Transparencia en la localización: El comando usado para realizar la tarea es independiente de la localización de los datos y del lugar donde se escriba el comando.
– Transparencia en los nombres. Cuando se asignan nombres a los objetos, estos se pueden acceder de forma no ambigua.
? Un esquema de localización describe el lugar donde está almacenados los datos (fragmentos)
© A. Illarramendi UPV/EHU27
4. Transparencia en las copias
? Todos los detalles para localizar y mantener copias deben ser tratados por el sistema. Se duplican los fragmentos.
– Ventajas: Seguridad (disponibilidad), menor nº de comunicaciones (aumento de paralelismo )
– Inconvenientes: Modificaciones, mas espacio de almacenamiento
© A. Illarramendi UPV/EHU28
4. Copias de los Datos
? Diferentes situaciones:a) Copiar toda la BD en cada nodo. Se crea una
BDD totalmente repetida.? Ventajas: El sistema funciona mientras funciona alguno de
los nodos (Disponibilidad). Paralelismo Incrementado.Las recuperaciones de los datos son más rápidas para las preguntas globales.
? Desventajas: Modificaciones mas costosas. Mecanismos de control de concurrencia y recuperaci ón ante fallos mas complejas.
© A. Illarramendi UPV/EHU29
4. Copias de los Datos
b) No tener ninguna copia de los datos, solo los originales. Cada fragmento está en un solo sitio. Distribución no redundante.
© A. Illarramendi UPV/EHU30
4. Copias de los datos
c) Repeticiones parciales. Algunos fragmentos se duplican y otros no.Se duplican en un nodo, dos,... o en tantos como existan.Una descripción de los fragmentos duplicados se denomina esquema de duplicación.
La selección de los lugares y el grado de duplicación depende:de los objetivos deseados en cuanto a rendimiento y disponibilidad del sistema y de los tipos y frecuencias de las preguntas enviadas a cada nodo
6
© A. Illarramendi UPV/EHU31
4. Tipos de fragmentación
? Fragmento: Unidad lógica de BD (ejemplo relación)
? Tipos de Fragmentación:– Horizontal– Vertical– Mixta
© A. Illarramendi UPV/EHU32
Fragmentación
? La fragmentación de una relación R es correcta si son válidas las siguientes propiedades:– Completitud: cada elemento de R debe aparecer
en alguno de los fragmentos Ri.– Restauración: el contenido de R se debe poder
obtener a partir de los fragmentos de Ri.
© A. Illarramendi UPV/EHU33
¿Por qué Fragmentar?
? Ventajas:– Mejorar el rendimiento de las aplicaciones al trabajar con
subconjuntos de relaciones– Poder dar una respuesta eficiente a aplicaciones que trabajan
con los mismos datos (subconjuntos de relación) en diferentes nodos
– Los fragmentos permiten aumentar el número de ejecuciones concurrentes.
? Desventajas :– Disminuye la eficiencia en las aplicaciones que trabajan con
varios fragmentos– La comprobación de las restricciones de integridad puede ser
más costosa.© A. Illarramendi UPV/EHU34
4. Fragmentación Horizontal
? Una fragmentación horizontal de una relación lo constituyen un subconjunto de tuplas de dicha relación. Las tuplas que pertenecen al fragmento horizontal se especifican por una condición en uno o más atributos de la relación.
? Operador: Selección. (Condición de guardia)
© A. Illarramendi UPV/EHU35
4. Fragmentación Horizontal
? Propiedades:– Completa. Cada tupla de la relación original R está
en alguno de los fragmentos (C1 or C2 or Cn)– Disjunta.Para cualquier i # j ninguna tupla esta en
Ci and Cj
Si es completa y disjunta se puede utilizar laoperación UNION para reconstruir la relación original.
© A. Illarramendi UPV/EHU36
4. Fragmentación Vertical
? Un fragmento vertical de una relación contiene solo ciertos atributos de la relación que están relacionados entre si de alguna forma.
? Operador: Proyección
? Es necesario incluir en cada fragmento el atributo clave primaria.
7
© A. Illarramendi UPV/EHU37
4. Fragmentación Vertical
? La fragmentaci ón vertical es completa si se cumple que:el conjunto de fragmentos verticales incluyen todos los atributos
de la relaci ón original y comparten el atributo clave primaria.L1 U L2 ....U Ln = Atributos (R) yLi and Lj = Pk(R) para todo i # j
clave primaria de R
Para reconstruir la relaci ón original se debe aplicar la operaci ón OUTER UNION.
© A. Illarramendi UPV/EHU38
4. Fragmentación
Fragmentación vertical: basada en encontrar conjuntos de atributos a proyectar
Fragmentación horizontal: basada en encontrar condiciones de selección
© A. Illarramendi UPV/EHU39
4. Fragmentación Mixta
? Combinación de los tipos de fragmentación Horizontal y Vertical.
© A. Illarramendi UPV/EHU40
4. Fragmentación
? En general un fragmento de relación se puede especificar por la combinación de las operaciones SELECT-PROJECT.
Si C = true and L # ATR(R) Fragmento verticalSi C # true and L =ATR(R) Fragmento horizontalSi C #true and L # ATR(R) Fragmento MixtoSi C =true and L = ATR(R) Relación Original
© A. Illarramendi UPV/EHU41
4. Fragmentación
? Un esquema de fragmentación de una BD contiene la definición del conjunto de fragmentos que incluyen todos los atributos y tuplas de la BD y que cumple la condición de que toda la BD puede ser reconstruida a partir de los fragmentos mediante alguna secuencia de operaciones
© A. Illarramendi UPV/EHU42
4. Objetivos
Transparencia en la localización + Transparencia en las copias +Trasparencia en la fragmentación
? Permiten que el sistema distribuido parezca al usuario un sistema centralizado
8
© A. Illarramendi UPV/EHU43
4. Objetivos
Además,? la transparencia en la localización permite desplazar
relaciones entre nodos sin alterar las aplicaciones? la transparencia en las copias permite incrementar el
factor de disponibilidad de los datos y el del rendimiento del sistema
? la transparencia en la fragmentación también permite incrementar el factor de rendimiento del sistema.
© A. Illarramendi UPV/EHU44
Ejemplo
? EMPLEADO (DNI, ENombre,Apellido, FechaNac,Dir,Sexo,Salario,DNIJefe,Ndpto.)? DEPARTAMENTO (NDpto, Dnombre, DNIJefe,FechaIniJefe)? LUGARES_DPTOS (NDpto, LugarDpto)? PROYECTO (NPro, Pnombre,Plugar,NDpto)? TRABAJA_EN (DNI,Npro,Horas)? DEPENDIENTE (DNI,Dnombre,Sexo,FechaNac,Parentesco)
Tres nodos. Nodo 1: Oficina Central. Acceso con regularidad a todos los datos de EMPLEADO y PROYECTO, además de utilizar la información de DEPENDIENTE para cuestiones relacionadas con el seguro.Nodo 2: Departamento 5Nodo 3: Departamento 4
? En los nodos 2 y 3 existe un acceso frecuente a los datos EMPLEA DO (sobre los atributos ENombre, DNI, Salario, DNIJefe) Y PROYECTO ( de los empleados que trabajan en ese departamento y sobre los proyectos controlados por ese departamento).
© A. Illarramendi UPV/EHU45
5.Ventajas
? Manejo de datos distribuidos con diferentes niveles de transparencia.
? Mejorar la seguridad y disponibilidad de los datos.? Permitir la expansión incremental con el m ínimo
impacto en las aplicaciones? Incrementar el rendimiento del sistema.? Permitir compartir datos manteniendo al mismo tiempo
un control local de los datos utilizados mas frecuentemente en el nodo.
© A. Illarramendi UPV/EHU46
5. Ventajas y Desventajas de BDD
? Ventajas– Autonomía local (establecer políticas locales de acceso a datos)– Más eficiencia al acceder a los datos localmente (en cada nodo)– Mayor fiabilidad / disponibilidad de datos (hay datos replicados )– Economía (mejor varios PC en red que un mainframe) – Más posibilidades de expansión (añadir más recursos a la red)– Compartición de datos (debido a que se encuentran en red)
? Desventajas– Falta de experiencia (al diseñar SBDD)– Complejidad (todos los problemas de las BD centralizadas y otros)– Costo (se necesita hardware / software de comunicaciones)– Distribución de control (también era ventaja: autonomía) – Seguridad (se añaden los problemas de seguridad en redes)– Dificultad de cambio (las empresas ya tienen BD centralizadas)
© A. Illarramendi UPV/EHU47
6. Componentes de un SBDD
? Elemento de Comunicación de Datos? SGBD locales de cada nodo? SGBDD
© A. Illarramendi UPV/EHU48
6. Nuevas funciones del SGBDD
? Manejar un catálogo global que contiene los esquemas de localización, duplicación y fragmentación.
? Obtener estrategias de ejecución para preguntas globales.
? Transmitir preguntas y datos entre varios nodos a través de la red.
? Decidir a qué copia duplicada acceder? Mantener la consistencia entre copias duplicadas.? Recuperación ante fallos en los nodos o en la red.
9
© A. Illarramendi UPV/EHU49
7. Diseño de BDs Distribuidas
Hay que decidir en qué nodos deben residir1) los datos Diseño de BD Distribuidas
No si las BD ya existen (SBDF). En ese caso hay que integrarlas para obtener el esquema global.En otro caso (SBDD), tras obtener el esquema conceptual global se debe fragmentar y asignar
2) las aplicaciones que trabajan con los datosEs necesario un sistema de gestión de BD Distribuidas que realice lo siguiente:
procesamiento de preguntas, mantenimiento de la consistencia si hay replicación de datos, control de transacciones, etc.
en algunos casos (determinados SBDD) se podrá comprar pero no todos (la mayoría de SBDI/F)
© A. Illarramendi UPV/EHU50
Diseño
© A. Illarramendi UPV/EHU51
Diseño de BD Distribuidas
? ¿Cómo distribuir los datos entre diferentes sitios?? Objetivos del Diseño:
– Procesamiento Local– Distribuci ón de la carga de trabajo– Costo de almacenamiento y disponibilidad
? Problemas:– Fragmentación– Asignación
© A. Illarramendi UPV/EHU52
7. Diseño top-down de BDD (Rel.)Esquema Global Información de Acceso
(transacciones)
Esquema Local 1 Esquema Local N
Esquema Físico 1 Esquema Físico N
DISEÑO FÍSICODISEÑO FÍSICO
ASIGNACIÓN
Esquema Global Fragmentado
FRAGMENTACION
© A. Illarramendi UPV/EHU53
Diseño Bottom-Up de BDD
Esquema Local 1 Esquema Local N
Esquema Local 1 en un modelo canónico
TRADUCCI ÓN TRADUCCI ÓN
Esquema Local N en un modelo canónico
INTEGRACI ÓN
Esquema Global en un modelo canónico
© A. Illarramendi UPV/EHU54
7. Diseño top-down de BDD (Rel.). Etapas
1. Diseño Esquema Global2. Fragmentar y Asignar3. Diseños Físicos
10
© A. Illarramendi UPV/EHU55
7. Diseño Top-Down
El problema de obtener los esquemas locales a partir del global se divide en dos:
Fragmentación: partir las tablas en fragmentos.Asignación: distribuir los fragmentos entre los esquemas locales.
El fragmento es la unidad a distribuirventaja: incrementa el nivel de concurrencia de transacciones.desventaja: algunas transacciones se degradarán si tienen que trabajar con varios fragmentos.
© A. Illarramendi UPV/EHU56
7. Fragmentación
? Con el fin de realizar una fragmentación adecuada es necesario trabajar con la siguiente información:– Sobre el significado de los datos– Sobre las aplicaciones que los usan– Acerca de la red de comunicaciones
© A. Illarramendi UPV/EHU57
7. Diseño. Asignación
? ¿Cómo asignar los fragmentos a los nodos?La elección de los lugares y el grado de
repetición de los datos dependerá:– del rendimiento que se quiera obtener del sistema– del grado de disponibilidad de los datos que se
desee y – del tipo y frecuencia de las transacciones en cada
nodo.
© A. Illarramendi UPV/EHU58
7. Asignación
? En la fase de asignación se necesita conocer información cuantitativa relativa a:– la BD, – las aplicaciones que se usaran, – la red de comunicación,– las capacidades de procesamiento y de
almacenamiento de cada nodo en la red.
© A. Illarramendi UPV/EHU59
7. Asignación
Asignar fragmentos a los esquemas locales Sin replicación: todo fragmento reside en un único nodo
bueno para actualizaciones, malo para preguntasCon replicación total: todos los fragmentos residen en todos los nodos bueno para preguntas, malo para actualizacionesCon replicación parcial: algunos fragmentos pueden residir en más de un nodo
compromiso entre actualizaciones y preguntas
Si hay más actualizaciones que preguntasentonces la replicación será menos ventajosa
© A. Illarramendi UPV/EHU60
7. Formulación del problemaAsignación
Dados N fragmentos y M nodos, encontrar la matriz X(Xij = true) el fragmento i se aloja en el nodo j
tal que minimiza el costo totalsuma de los costos de procesamiento de todas las preguntas, actualizaciones (multiplicando cada costo por el n º de veces que se pregunta / actualiza) y costos de almacenar todos los fragmentos.sujeto a las siguientes restricciones:
tiempo de respuesta máximo para cada preguntaexiste un almacenamiento máximo en cada nodono superar la carga de procesamiento en cada nodo
El problema es NP-completo. Pero se pueden usar heurísticos: problema de la mochila, técnicas de ramificar y
acotar, etc...
11
© A. Illarramendi UPV/EHU61
7. Asignación
PROCESAMIENTODE PREGUNTAS
CONTROL DECONCURRENCIA
DISPONIBILIDADDE LOS DATOS
REPLICACIÓNCOMPLETA
REPLICACIÓNPARCIAL
SINREPLICACIÓN
Más fácil Más Difícil Más difícil
Difícil Más Difícil Más fácil
Muy alta Alta Baja
© A. Illarramendi UPV/EHU62
7. Diseño
? ¿Donde almacenar el catálogo global?a) Centralizado. En un único nodob) Totalmente repetido. En cada nodoc) Distribuido. En cada nodo se almacena la información necesaria para el nodo.
Combinación de a y c.
© A. Illarramendi UPV/EHU63
8. Procesamiento de Preguntas
? El sistema debe:– descomponer la pregunta original en
subpreguntas que se puedan ejecutar en nodos individuales.
– generar la estrategia que combine los resultados de las subpreguntas para obtener la respuesta final.
Maneja los esquemas de localización, copias y fragmentación.
© A. Illarramendi UPV/EHU64
8. Procesamiento de Preguntas
? El álgebra relacional no es suficiente para expresar la ejecución de estrategias. Debe ser completada con operaciones para intercambio de datos entre nodos diferentes.
? Además de elegir el orden de las operaciones del álgebra relacional, el procesador de consultas distribuidas debe seleccionar los mejores sitios para procesar los datos.
© A. Illarramendi UPV/EHU65
8. Procesamiento de Preguntas
? Transformar la pregunta formulada por el usuario en un conjunto de operaciones sobre las bases de datos locales (se deben transferir ficheros intermedios entre nodos)
? Es necesario trabajar con técnicas de optimización.
© A. Illarramendi UPV/EHU66
8. Procesamiento de Preguntas
Regla: Seleccionar el nodo que envía la mayor cantidad de datos al nodo de operación como lugar para ejecutar la operación
? Costo Total = E/S+CPU+Comunicaciones
? Objetivo más extendido: Minimizar los costos de comunicación. (sobre todo en WAN)
12
© A. Illarramendi UPV/EHU67
8. Procesamiento de preguntas utilizando la operación Semi-Join
? Idea: Reducir el nº de tuplas en una relación antes de transferirla a otro nodo.
Enviar los atributos de una relación R necesarios para hacer el join al nodo donde este almacenada la relación S. Hacer el join. Proyectar los atributos necesarios para el resultado y enviar al nodo donde este R.
© A. Illarramendi UPV/EHU68
8. Procesamiento de pregs. en BDDPregunta inicial
DESCOMPOSICIÓN DE CONSULTAS
Pregunta inicial en álgebra relacional
LOCALIZACIÓN DE DATOS
Pregunta sobre fragmentos
OPTIMIZACIÓN GLOBAL
OPTIMIZACIÓN LOCAL
Pregunta sobre fragmentos y operaciones de comunicación
Preguntas locales optimizadas
Esquema Global
Esquema de Fragmentos
Estadísticas sobreFragmentos
Esquema Local
© A. Illarramendi UPV/EHU69
Descomposición de Preguntas
? Transforma la pregunta en otra pregunta en álgebra relacional que opera sobre relaciones globales. Consiste de cuatro partes:
– Normalización: transformar una consulta a una forma normalizada (conjuntiva o disyuntiva) para facilitar su procesamiento posterior. También verifica la validez de la expresi ón (análisis sintáctico)
– Análisis . Se detectan y rechazan consultas incorrectas– Simplificación. Elimina predicados redundantes aplicando
reglas de idempotencia (p and p ? p)– Reestructuración.Rescribe la pregunta en el álgebra
relacional para mejorar la eficiencia (transformar productos cartesianos en joins)
© A. Illarramendi UPV/EHU70
Análisis. Ejemplo
? Si el predicado de selección se contradice con la definición de un fragmento, el resultado es una relación intermedia vacía y la operación se puede eliminar.
© A. Illarramendi UPV/EHU71
Reestructuración. Ejemplo
? Staff (DNI,Nom,Apel,cargo,sexo,salario)
? Obtener los nombres y apellidos de todos los miembros del staff
SELECT Nom, ApelFROM Staff
© A. Illarramendi UPV/EHU72
Reestructuración. Ejemplo
? S1: Proyección [DNI,cargo,sexo,salario]? S2: Proyección [DNI,Nom,Apel]
Proyección(Nom,Apel) Proyección(Nom,Apel)
Join DNI S2
S1 S2 (Se eliminan los fragmentos verticales que no contienen los atributos proyectados)
13
© A. Illarramendi UPV/EHU73
Localización de Datos
? Localiza los datos de la consulta usando la información sobre la distribución de datos. Determina que fragmentos están involucrados en la consulta y transforma la consulta distribuida en consulta sobre fragmentos.(E se ha dividido en tres fragmentos, E1, E2 y E3)
Ejemplo: SELECT * FROM E WHERE ENO = “E5”
Se transforma en: SELECT * FROM E2 WHERE ENO =“E5”
© A. Illarramendi UPV/EHU74
Optimización Global
? Calcula una estrategia de ejecución para la consulta cercana a la óptima.
? La salida es una consulta algebraica optimizada con primitivas de comunicación para transferir datos entre nodos.
? El factor principal que afecta la eficiencia de la ejecución de una estrategia es el tamaño de las relaciones intermedias que son producidas durante la ejecución. (las relaciones intermedias se deben transmitir por la red)
© A. Illarramendi UPV/EHU75
Optimización Local
? Se efectúa en todos los nodos con fragmentos involucrados en la consulta.
? La optimización local usa los algoritmos de sistemas centralizados.
© A. Illarramendi UPV/EHU76
9. Modelo de Transacciones Distribuidas
? Las transacciones deben conservar las propiedades ACID
? Tipos de transacciones:– locales: tienen acceso y actualizan datos s ólo en
una BD local.– globales: tienen acceso y actualizan datos en varias
BD locales.
© A. Illarramendi UPV/EHU77
Propiedades de la Transacción
Principio ACID (su cumplimiento debe estar asegurado por el SGBD)? Se ejecuta como unidad (Atomicity) Gestor de transacciones, Gestor de
recuperación
? Preserva la consistencia(Consistency) Gestor de Rest. de integridad
? Una transacción no muestra los cambios que produce hasta que finaliza (Isolation) Gestor de Control de Concurrencia
? Si termina correctamente, sus cambios permanecen (Durability) Gestor de Recuperaciones
© A. Illarramendi UPV/EHU78
9. Modelo de Transacciones Distribuidas. Arquitectura del sistema
? Cada nodo del sistema contiene dos elementos:? Gestor de transacciones: gestiona la ejecución de
las transacciones que tienen acceso a datos almacenados en un nodo local.
? Coordinador de transacciones: coordina la ejecución de las diferentes transacciones iniciadas en ese nodo.
14
© A. Illarramendi UPV/EHU79
9. Coordinador de transacciones
? Responsable de :
– Iniciar la ejecución de la transacción– Dividir la transacción en una serie de
subtransacciones y distribuir estas subtransacciones para su ejecución en los nodos adecuados
– Coordinar la terminación de la transacción
© A. Illarramendi UPV/EHU80
9. Protocolos
? Si hay que asegurar la atomicidad, todos los nodos en los que se ejecutó la transacción T deben ponerse de acuerdo sobre el resultado final de la ejecución:– COMMIT en todos los nodos donde se ejecute T o
se debe abortar en todos.Para asegurar esta propiedad, el coordinador de
transacciones de T debe ejecutar un protocoloProtocolos: de dos fases, de tres fases.
© A. Illarramendi UPV/EHU81
9. Protocolo de COMMIT en dos fases
? FASE 1(VOTACION)El coordinador de transacciones del nodo Ci envía un mensaje a todos los nodos donde se ejecuta T. Al recibir ese mensaje, el gestor de transacciones de cada nodo determina si está dispuesto a comprometer su parte de T (no hace el COMMIT). Puede enviar ABORTAR o COMMIT.
? FASE 2 (DECISION)Cuando Ci recibe la respuesta de todos los nodos, o cuando ha transcurrido un intervalo de tiempo predeterminado desde su env ío, Ci determina si puede hacer COMMIT o ABORTAR la transacción T. COMMIT si recibe COMMIT de todos los nodos. Una vez tomada la decisión Ci env ía un mensaje a todos los nodos participantes para que ejecuten el COMMIT o el ROLLBACK
© A. Illarramendi UPV/EHU82
Protocolo de 2 fases
© A. Illarramendi UPV/EHU83
Protocolo de 2 fases
? La estructura de comunicaciones para el protocolo de dos fases puede ser:
– Centralizada . Comunicaci ón entre el coordinador y los participantes.
– Lineal. Los participantes se pueden comunicar unos con otros. Existe un ordenamiento entre los nodos del sistema.
– Distribuida . Comunicaci ón entre todos los participantes durante la primera fase del protocolo. Esta versi ón no requiere la segunda fase. Cada participante envía su decisión a todos los otros participantes.
© A. Illarramendi UPV/EHU84
Protocolo de 2 fases
C
P
P
P
C
P
P
P
C Centralizada
Preparado VC/VA GC/GA COMMIT/ABORT
15
© A. Illarramendi UPV/EHU85
Protocolo de 2 fases
1 2 3 N Lineal
Preparado VC/VA VC/VA
GC/GA GC/GA GC/GA
© A. Illarramendi UPV/EHU86
Protocolo de 2 fases
P P
P P
DistribuidaC
Preparado VC/VAGC/GA
© A. Illarramendi UPV/EHU87
Protocolo de dos fases. Tratamiento de los fallos
? Fallo de un sitio participante. Si el sitio falla antes de responder al coordinador C, el coordinador da por supuesto que ha respondido con el mensaje ABORTAR. Si el sitio falla después de que el coordinador haya recibido el mensaje COMMIT, el coordinador ejecuta el resto del protocolo de manera normal, ignorando el fallo.
? Fallo del coordinador. Si el coordinador falla durante la ejecución del protocolo para la transacción T, los sitios participantes deben decidir el destino de T. Si no pueden decidir sobre T deben esperar a la recuperación del coordinador.
© A. Illarramendi UPV/EHU88
9. Elección de un nuevo sitio coordinador en caso de fallo
? Algoritmo de elección:Cualquier sitio Y que trata de contactar con el coordinador varias veces y falla, asume que el coordinador esta inactivo e inicia el proceso de elección enviando un mensaje a todos los sitios activos en el cual propone que Y se convierta en el nuevo coordinador. Tan pronto como Y reciba una mayoría de votos afirmativos, puede declarar que es el nuevo coordinador.
© A. Illarramendi UPV/EHU89
9. Control de concurrencia.Nuevos problemas que no se encuentran en los entornos de SGBD centralizados.
? Trabajar con múltiples copias– El mecanismo de control de concurrencia
responsable de mantener la consistencia entre copias.
– El mecanismo de recuperación ante fallos debe cuidar que una copia sea consistente con todas las demás si el sitio en el que la copia estaba almacenada falla y se recupera posteriormente.
© A. Illarramendi UPV/EHU90
9. Control de concurrencia. Nuevos problemas..
? Fallos en los nodos– El SGBDD debe continuar trabajando con los nodos
activos cuando fallen uno o mas nodos individuales.– Cuando un nodo se recupere, su BD local se
deberá poner al día con los dem ás nodos antes de que se reincorpore al sistema.
16
© A. Illarramendi UPV/EHU91
9. Control de Concurrencia. Nuevos problemas...
? Fallos en los enlaces de comunicación.– El sistema deberá ser capaz de trabajar cuando fallen algunos
en laces de comunicaci ón
? COMMIT Distribuido.– Pueden aparecer problemas al realizar el COMMIT de una
transacción que accede a BD almacenadas en distintos nodos, si alguno de ellos falla al hacer el COMMIT
? DEADLOCK Distribuido. Pueden ocurrir bloqueos entre varios nodos.
© A. Illarramendi UPV/EHU92
Deadlock Distribuido
? Tres transacciones:– T1 se inicia en el nodo S1– T2 se inicia en el nodo S2– T3 se inicia en el nodo S3
Time S1 S2 S3t1 read(T1,x1) write(T2,y2) read(T3,z3)t2 write(T1,y1) write(T2,z2)t3 write(T3,x1) write(T1,y2) write(T2,z3)
© A. Illarramendi UPV/EHU93
Deadlock Distribuido
T3 T1 T1 T2 T2 T3
T1 T2
T3
Para detectar un Deadlock NO basta con construir un grafo de precedencia en cada nodo
s1 s2 s3
© A. Illarramendi UPV/EHU94
9. Control de concurrencia Distribuido basado en una copia distinguida de un elemento de información
? Métodos que se basan en la extensión de las técnicas de control de concurrencia en las BD centralizadas.
? Idea: Designar una copia determinada de cada elemento de información como copia distinguida.
? Las reservas para ese elemento de información se asocian a la copia distinguida y todas las solicitudes de reservas y liberaciones se envían al nodo que contiene esa copia.
© A. Illarramendi UPV/EHU95
9. Control de concurrencia Distribuido basado en una copia distinguida de un elemento de información
? Los métodos difieren en la forma en la que escogen las copias distinguidas:– Sitio Primario– Sitio Primario con Sitio Respaldo– Copia Primaria
Un sitio que incluye una copia distinguida de unelemento de informaci ón actúa como sitio coordinadorpara el control de concurrencia de ese elemento
© A. Illarramendi UPV/EHU96
9. Sitio Primario
? Se designa un solo sitio primario como sitio coordinador para todos los elementos de la BD.
? Todos las reservas se mantienen en ese sitio y todas las solicitudes de bloqueo y desbloqueo se envían a ese sitio.
17
© A. Illarramendi UPV/EHU97
9. Sitio Primario
? Ventaja: Extensión del enfoque centralizado? Desventaja: Se origina un cuello de botella en el
sistema (se sobrecarga el sitio). Un fallo del sitio primario paraliza el sistema.
? Aunque el acceso a todos las reservas es en el sitio primario, el acceso a los elementos puede realizarse en cualquier nodo en el que residan.
© A. Illarramendi UPV/EHU98
9. Sitio Primario con Sitio de Reserva
? Objetivo: Eliminar segunda desventaja del método de Sitio Primario.
? Idea: Se designa un segundo sitio como sitio de respaldo.
? Toda la información de bloqueo se mantiene tanto en el sitio primario como en el de respaldo.
© A. Illarramendi UPV/EHU99
9. Sitio Primario con Sitio de Reserva
? Ventaja: En el caso de fallar el sitio primario, el de respaldo puede asumir las funciones de sitio primario y se puede escoger un nuevo sitio de respaldo.
? Desventaja: Proceso de adquisición de reservas más lento. El sistema se hace mas lento (sitios sobrecargados)
© A. Illarramendi UPV/EHU
100
9. Copia Primaria
? Idea: Almacenar las copias distinguidas de diferentes elementos de información en distintos sitios.
? El fallo de un sitio afecta a las transacciones que accedan a reservas sobre elementos cuyas copias primarias residan en ese sitio pero las demás transacciones no resultan afectadas.
© A. Illarramendi UPV/EHU
101
9. Control de Concurrencia Distribuido basado en Votación
? Idea: No hay copia distinguida. Cada solicitud de reserva se envía a todos los sitios que incluyan una copia del elemento de información.
© A. Illarramendi UPV/EHU
102
9. Control de Concurrencia Distribuido basado en Votación
? Cada copia mantiene su propia reserva y puede conceder o rechazar la solicitud. Si la mayoría de las copias otorgan una reserva a la transacción que lo solicita, ésta poseerá la reserva e informará a todas las copias que le ha sido concedido. Si una transacción no recibe la mayoría de los votos de concesión de la reserva durante un cierto periodo de tiempo predefinido, cancelará su solicitud e informaráde ello a todos los sitios.
? Trafico alto de mensajes
18
© A. Illarramendi UPV/EHU
103
9. Marcas Temporales
? Idea en los sistemas centralizados: se da a cada transacción una marca temporal única que el sistema utiliza para decidir el orden de secuenciación.
? Para generalizar a un entorno distribuido hay que desarrollar un esquema para generar marcas temporales únicas.
© A. Illarramendi UPV/EHU
104
9. Marcas temporales
? Existen dos métodos para generar marcas temporales únicas:– Esquema centralizado: se escoge un único nodo
para distribuir las marcas temporales– Esquema distribuido: cada nodo genera una
marca temporal local única. La marca temporal global única se obtiene concatenando la marca temporal local única con el identificador de nodo (que también debe ser único)
© A. Illarramendi UPV/EHU
105
10. RESTRICCIONES DE INTEGRIDAD en Bases de Datos Distribuidas
? Un estado de la BD es consistente si la BD satisface las restricciones de integridad.
? Problemas a solucionar al diseñar un subsistema de integridad:– 1. Definición y almacenamiento de restricciones– 2. Comprobación
© A. Illarramendi UPV/EHU
106
10. Definición de restricciones de Integridad Distribuidas
? Se distinguen tres tipos de restricciones:– Restricciones individuales (una relación- una variable)
La definici ón se envía a todos los nodos que contienen fragmentos de la relaci ón. (ej. Salario .Empleados < 10.000).
– Orientadas a Objetos (una relación- varias variables, varias relaciones-varias variables)
La definici ón se envía a todos los nodos que almacenan fragmentos relacionados con las variables.(ej una relaci ón- varias variables dependencia funcional)
– Contienen funciones agregadas.
© A. Illarramendi UPV/EHU
107
10. Comprobación de las Restricciones
? Hay que decidir DONDE comprobar las restricciones. La elección depende del:– Tipo de restricción– Tipo de modificación– De la naturaleza del nodo donde se produce la
modificación (nodo master)
Objetivo: disminuir el costo de transferencia de mensajes y el costo de procesamiento.
© A. Illarramendi UPV/EHU
108
10. Comprobación de las Restricciones
? Ejemplo (restricción individual):
– insertar tuplas proporcionadas por el usuario.– Las restricciones individuales se verifican en los
nodos donde tienen lugar las insercciones .
19
© A. Illarramendi UPV/EHU
109
10. Comprobación de las restricciones de Integridad Distribuidas
? Las comprobaciones de las Restricciones de Integridad pueden comenzar en cualquier nodo que contenga relaciones que participan en la restricción.
La restricción se verifica globalmente.
© A. Illarramendi UPV/EHU
110
11. SEGURIDAD en Bases de Datos Distribuidas
? La seguridad incluye dos aspectos:
– Protección de datos (encriptación)– Control de autorizaciones (sólo personas
autorizadas realizan operaciones permitidas en la BD)
© A. Illarramendi UPV/EHU
111
11.Control de autorizaciones distribuido
? Problemas adicionales en el entorno distribuido:– Autentificación de usuarios remotos– Manejo de las reglas de autorización distribuidas– Manejo de vistas– Manejo de grupos de usuarios
© A. Illarramendi UPV/EHU
112
11.Control de autorizaciones distribuido
? Autentificación de usuarios remotos. Es necesario porque cualquier nodo puede aceptar transacciones iniciadas en otros nodos.
? Soluciones:– 1.La información sobre la autentificación de los usuarios se
almacena en todos los nodos. (las transacciones deben indicar el usuario y password)
– 2. Se identifican y autentifican los nodos.Se usan password de nodo.
La primera soluci ón es más costosa en términos de gestión del directorio pero los usuarios pueden acceder de cualquier nodo.
© A. Illarramendi UPV/EHU
113
11.Control de autorizaciones distribuido
– Manejo de las reglas de autorización distribuidasSe expresan de la misma forma que las centralizadas. Se pueden almacenar en cada nodo o en los nodos de los objetos referenciados.
– Manejo de vistasPermitir el acceso a una vista se traduce en permitir el acceso a los objetos subyacentes. Sencillo cuando las definiciones de las vistas y las reglas de autorización están replicadas.
– Manejo de grupos de usuariosCorresponde a la noción de role de los sistemas centralizados.Si la información de roles y las reglas de autorizaci ón se duplican en todos los nodos se pueden usar las técnicas del sistema centralizado.
© A. Illarramendi UPV/EHU
114
12. Clasificación de SBDD
? Grado de Homogeneidad– HOMOGENEAS. Si todos los SGBD locales son del
mismo tipo.– HETEROGENEAS. En caso contrario
20
© A. Illarramendi UPV/EHU
115
12. Clasificación de SBDD
? Grado de Autonomía– a) Sin autonom ía local. Todas las preguntas sobre
el esquema global– b)Con autonom ía local.
? FEDERADOS (fuertemente acoplados). Existe un esquema global único y todas las preguntas globales se realizan sobre este esquema. Existe autonomía local.
? FEDERADOS (débilmente acoplados). No existe un esquema global pero si un lenguaje que permite hacer preguntas sobre datos de otros nodos.
© A. Illarramendi UPV/EHU
116
12. Clasificación de SBDD
? Grado de transparencia en la distribución.– a)Transparencia en la localización. Los usuarios
ven un esquema global sin información sobre fragmentación, duplicación ó distribución.
– b) Sin transparencia en la localización. El usuario ve la información sobre fragmentación, duplicación y distribución y es responsable de su manejo.
© A. Illarramendi UPV/EHU
117
12. Factores que influyen en las arquitecturas de Bases de Datos
? Distribuci ón– Una BD (o varias) es distribuida si se encuentra en más de un
nodo. (No si hay varias BDs en el mismo nodo)? Heterogeneidad:
– Distinto hardware, SO, software comunicaciones. – Distinto modelo de datos (relac., jerárquico, red, OO,..) – Distintos SGBDs (aunque sean del mismo modelo)– Heterogeneidad semántica (aun con el mismo SGBD)
? sinonimia: elementos iguales con distintos nombres? homonimia: elementos distintos con igual nombre? el mismo elemento del mundo real puede ser representado como
entidad / atributo / tabla / clase / con tipo diferente,...
© A. Illarramendi UPV/EHU
118
12. Factores que influyen en las arquitecturas de BDs
? Autonomía– Se refiere al control que los SGBD tienen sobre cada BD local
(en cada nodo)? Autonomía de diseño: existe si los administradores de la BD
(ABD) pueden cambiar el esquema conceptual de sus BDsindependientemente de si forman parte del sistema distribuido.
? Autonomía de comunicaci ón: si puede decidir cuándo comunicarse con los otros SGBD locales.
? Autonomía de ejecuci ón: si puede ejecutar transacciones globales y locales en el orden en que quiera.
? Autonomía de participaci ón: si pueden decidir cómo participar en el sistema distribuido.
© A. Illarramendi UPV/EHU
119
12. Factores que influyen en las arquitecturas de BDs
? Existencia o no de esquema global– Si se proporciona un esquema global entonces es como si
se trabajara con una única base de datos. Las preguntas se realizan sobre dicho esquema global:
? SELECT *? FROM VUELOREAL, BILLETES? WHERE VUELOREAL.ID=BILLETES.ID
? En el esquema global aparecerá que VUELOREAL está en BD1 y BILLETES en BD2 pero es transparente al usuario.
– Si no, se necesita un lenguaje de acceso a distintas BDs.? SELECT *? FROM BD1@VUELOREAL, BD2@BILLETES? WHERE VUELOREAL.ID=BILLETES.ID
© A. Illarramendi UPV/EHU
120
12. Arquitecturas de BD distribuidas
? Sistemas de Bases de Datos Distribuidas (SBDD)– Formados por BDs no autónomas.– Proporcionan un esquema global .– El esquema global se obtiene de arriba a abajo : primero se define el
esquema conceptual global y luego se fragmenta en varias BDs.? Sistemas de Bases de Datos Interoperantes (SBDI)
– Formados por BDs autónomas.– No proporcionan esquema global sino lenguajes de acceso a BDs.– El usuario es consciente de que trabaja con varias BDs.
? Sistemas de Bases de Datos Federadas (SBDF)– Formados por BDs autónomas.– Proporcionan un esquema global.– El esquema global se obtiene de abajo a arriba: los esquemas locales son
pre-existentes y se integran en un esquema global. No se decide fragmentar: la redundancia probablemente ya existe.
21
© A. Illarramendi UPV/EHU
121
Conclusiones
Sólo falta que determinadas multinacionales decidan apostar más fuerte por este enfoque a través de sus famosos sistemas gestores de bases de datos y que se produzca la consolidación de la resolución de los problemas que el enfoque distribuido acarrea.
© A. Illarramendi UPV/EHU
122
BD Distribuidas y ORACLE
? Cada BD en una BDD es diferente del resto de BDs y tiene su propio nombre global.
nombreBD.Nombredominio Ej. ORCL.LABLSISI.JI.EHU.ES
Todas las BD Oracle de un SBDD utilizan el software de red OracleNet8 para la comunicación entre las Bases de Datos.
© A. Illarramendi UPV/EHU
123
DB LINK. ORACLE
? Un DB LINK define un camino desde una BD ORACLE a otra BD (pero no viceversa). Se almacena en el catálogo
(SELECT db_link FROM user_db_links;)? ¿Por qué usar un links?
– Un usuario local puede acceder a través de un link a una BD remota sin ser usuario de dicha base remota.
– Permite limitar el acceso a base de datos remotas a usuarios locales.– Permiten a los usuarios acceder a las BDs como si se tratara de una única BD
lógica.
? Es transparente para los usuarios.
? Cuando GLOBAL_NAMES= true el nombre del LINK debe coincidir con el nombre de la BD a la que señala el link.
? Si GLOBAL_NAMES = false el DB LINK puede tener otro nombre© A. Illarramendi UPV/EHU
124
Sintaxis de DB LINK
? CREATE [SHARED][PUBLIC]DATABASE LINK nombre [CONNECT TO {CURRENT USER | usuario IDENTIFIED BY password}] [USING nombre-conexión]
Se obtiene ORACLE/ADMIN/NETWORK/TNSNAMES.ORA
© A. Illarramendi UPV/EHU
125
Servicio (service)
? ERREALA =? (DESCRIPTION =? (ADDRESS_LIST =? (ADDRESS = (PROTOCOL = TCP)(HOST =
jipla0)(PORT = 1521))? )? (CONNECT_DATA = (SERVICE_NAME =
erreala.lablsisi.ji.ehu.es))? )
© A. Illarramendi UPV/EHU
126
TIPOS DE DB LINK
? Private. Sólo lo puede usar el que lo crea– (CREATE DATABASE LINK ....)
? Public. Lo podrán usar todos los usuarios de la BD– (CREATE PUBLIC DATABASE LINK ....)
? Global. Lo podrán usar todos los usuarios de cualquier BD en la red ORACLE
– Se deben definir en ORACLE NAME SERVER
22
© A. Illarramendi UPV/EHU
127
TIPOS DE USUARIOS
? Fixed. Hay que indicar en la definición el usuario y el password
? Connected User (sin CONNECT). Válido para el usuario conectado. Debe tener en la BD remota una cuenta con el mismo nombre de usuario que en la cuenta de la base de datos local.
? Current User. Un usuario local se puede conectar como usuario global a través de un procedimiento almacenado.
© A. Illarramendi UPV/EHU
128
Formulación de Preguntas
SELECT *FROM TABLA@NOMBREDB LINK
del usuario que hace la preguntaSELECT *FROM Usuario.tabla@NOMBREDBLINK
de otro usuario
© A. Illarramendi UPV/EHU
129
Sinónimos
? CREATE [PUBLIC] SYNONYM nombre FOR [esquema.] nombreobjecto@nombreDBlink
© A. Illarramendi UPV/EHU
130
Replicación en Oracle
? Replicación: proceso que consiste en copiar y mantener objetos de bases de datos, tales como tablas, en m últiples bases de datos que pertenecen a un sistema de bases de datos distribuido.
? Algunas razones para usar la replicación:– Disponibilidad. Proporciona opciones alternativas de acceso
a los datos– Rendimiento. Accesos locales más rápidos. Algunos usuarios
acceden a un servidor y otros a otro servidor.– Desconexiones . Se puede trabajar con copias (snapshot)
aunque se desconecte el servidor.– Distribución de los datos entre distintos servidores.
© A. Illarramendi UPV/EHU
131
REPLICACION. Objetos, Grupos y Nodos (Sites)
? Replication Object. Objeto de la BD que existe en múltiples servidores de un sistema distribuido – Tablas, Índices, Vistas,Sinónimos, etc.
© A. Illarramendi UPV/EHU
132
REPLICACION. Grupos
? Replication Group. Colección de objetos replicados que están lógicamente relacionados. Todos los objetos se administran conjuntamente.
? Un replication group puede contener objetos de diferentes esquemas y un esquema puede tener objetos en distintos replication groups.
? Sin embargo, un replication object sólo puede ser miembro de un replication group.
23
© A. Illarramendi UPV/EHU
133
REPLICACION. Nodos (Sites)
? Un replication group puede existir en diferentes nodos de replication.
? Tipos de nodos: nodos masters y nodos snapshot. Un nodo puede ser al mismo tiempo master y snapshot.– Master Site (Nodo primario)– Snaphot Site –Materialized View-(Nodo copia) Sólo
soporta snaphot de datos asociados a un master.
© A. Illarramendi UPV/EHU
134
Diferencias entre nodos master y nodos snapshot
? A un grupo de replicaci ón de un nodo master se le denomina grupo master. A un grupo de replicación de un nodo snapshot se le denomina grupo snapshot.
? Un nodo master mantiene una copia completa de todos los objetos de un grupo de replicación. Los snapshot de los nodos snapshot pueden contener todo o parte de los datos de un grupo master de replicación.
? Entre los nodos master se comunican los cambios continuamente. Los nodos snapshot se referescan peri ódicamente para sincronizarlos con los nodos master.
© A. Illarramendi UPV/EHU
135
Replicación. Tipos
? Mustimaster, Snapshot e Híbrida.? Replica Multimaster. Todos los nodos son de tipo
master. Permite las actualizaciones en cualquier réplica de los elementos de datos y se propagan de manera autom ática a todas las réplicas(sincronamente, o asíncronamente –cada cierto tiempo)
? A veces los sistemas actualizan en un sitio, con propagación perezosa de las actualizaciones a los demás sitios.
© A. Illarramendi UPV/EHU
136
Replicación en general. Tipos
? Replica Snapshot. Un nodo es master y otro snapshot.
? Tipos:– Read only (sólo lectura)– Updatable (actualizaciones)
© A. Illarramendi UPV/EHU
137
Snapshot Read Only
? Sólo se permiten lecturas de la tabla (las modificaciones se deben realizar en el nodo master)
? Ventajas– Eliminan la posibilidad de inconsistencias– Soportan snapshot complejos
© A. Illarramendi UPV/EHU
138
Snapshot Actualizable
? Permite a los usuarios insertar, modificar y borrar tuplas de las tablas del nodo master a través del nodo snapshot.
? Sólo se pueden basar en una única tabla.? Se pueden refrescar del mismo modo que las de tipo
read only? Ventajas:
– Permite a los usuarios preguntar y modificar localmente.