I UNIDAD

BASES DE DATOS DISTRIBUIDAS

1.1 Conceptos bsicos.
1.2 Objetivos de las B.D.D.
1.3 Disciplinas de estudio.
1.4 Arquitectura de bases de datos distribuidas.
UNIDAD 2
DISEO DE BASES DE DATOS DISTRIBUIDAS

3
7
12
13

2.1 Consideraciones de diseo de bases de datos distribuidas.

2.2 Diccionario de datos.
2.3 Niveles de transparencia.
2.3.1 Transparencia de localizacin.
2.3.2 Transparencia de fragmentacin.
2.3.3 Transparencia de rplica.
2.4 Fragmentacin de datos.
2.4.1 Fragmentacin horizontal.
2.4.2 Fragmentacin vertical.
2.4.3 Fragmentacin hbrida.
2.5 Distribucin de datos.
2.5.1 Algoritmos de distribucin de datos no replicados.
2.5.2 Algoritmos de distribucin de datos replicados.
UNIDAD 3
PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

20
27
28
30
31
31
32
34
37
38
40
42
43

3.1 Metodologa del procesamiento de consultas distribuidas.

3.2 Estrategias de procesamiento de consultas distribuidas.
3.2.1 rboles de consultas.
3.2.2 Transformaciones equivalentes.
3.2.3 Mtodos de ejecucin del Join.
3.3 Optimizacin de consultas.
3.3.1 Optimizacin global de consultas.
3.3.2 Optimizacin local de consultas.

47
53
56
60
60
70
73
75

UNIDAD 4
MANEJO DE TRANSACCIONES
4.1 Transacciones
4.1.2 Ejecucin de transacciones centralizada y distribuida
4.1.3 Estructura de transacciones.
4.1.4 Ejecucin de transacciones centralizada y distribuida.

82
84
87
88

89
4.2 Control de concurrencia.
. 4.2.1 Serializacin de transacciones.
4.2.2 Algoritmos de control de concurrencia.
4.2.2.1 Basados en bloqueo.
4.2.2.2 Basados en estampas de tiempo.
4.2.2.3 Pruebas de validacin optimistas.
4.2.3 Disciplinas del Interbloqueo: prevencin,
eliminacin y recuperacin
4.3 Confiabilidad
4.3.1 Conceptos bsicos de confiabilidad.
4.3.2 Protocolos REDO/UNDO.
4.3.3 Puntos de verificacin (checkpoints).
4.3.4 Protocolo 2PC de confiabilidad distribuida.
BIBLIOGRAFIA

90
91
94
9
deteccin, 98
99
100
101
103
10

1 UNIDAD: FUNDAMENTOS DE BASE DE DATOS DISTRIBUIDAS

1.1

CONCEPTOS BASICOS

Una base de datos o banco de datos es un conjunto de datos pertenecientes a

un mismo contexto y almacenados sistemticamente para su posterior uso. En
este sentido, una biblioteca puede considerarse una base de datos compuesta en
su mayora por documentos y textos impresos en papel e indexados para su
consulta. En la actualidad, y debido al desarrollo tecnolgico de campos como la
informtica y la electrnica, la mayora de las bases de datos estn en formato
digital (electrnico), que ofrece un amplio rango de soluciones al problema de
almacenar datos.
Existen programas denominados sistemas gestores de bases de datos,
abreviados SGBD, que permiten almacenar y posteriormente acceder a los datos
de forma rpida y estructurada. Las propiedades de estos SGBD, as como su
utilizacin y administracin, se estudian dentro del mbito de la informtica.
Las aplicaciones ms usuales son para la gestin de empresas e instituciones
pblicas. Tambin son ampliamente utilizadas en entornos cientficos con el objeto
de almacenar la informacin experimental.
Aunque las bases de datos pueden contener muchos tipos de datos, algunos de
ellos se encuentran protegidos por las leyes de varios pases. Por ejemplo en
Espaa, los datos personales se encuentran protegidos por la (LOPD).
Base de datos distribuidas: Son un grupo de datos que pertenecen a un sistema
pero a su vez est repartido entre ordenadores de una misma red, ya sea a nivel
local o cada uno en una diferente localizacin geogrfica, cada sitio en la red es
autnomo en sus capacidades de procesamiento y es capaz de realizar
operaciones locales y en cada uno de estos ordenadores debe estar ejecutndose
una aplicacin a nivel global que permita la consulta de todos los datos como si se
tratase de uno solo. Es un conjunto de mltiples bases de datos lgicamente
relacionadas las cuales se encuentran distribuidas entre diferentes sitios
interconectados por una red de comunicaciones.
Caractersticas de la base de datos distribuidos:
Los datos deben estar fsicamente en ms de un ordenador (distintas
sedes)

 Las sedes deben estar interconectadas mediante una red (cada sede es un
nodo de la red)
Los datos han de estar lgicamente integrados (recuperacin y
actualizacin) tanto en local como remoto (esquema lgico global y nico)
En una nica operacin se puede acceder (recuperar o actualizar) datos
que se encuentran en ms de una sede (acceso a datos locales o remotos)
Todas las acciones que necesiten realizarse sobre ms de una sede sern
transparentes al usuario (transparencia de distribucin para el usuario)
Ventajas de la base de datos distribuidos:
Organizativas:
Econmicas:
Tcnicas:
Desventajas de la base de datos distribuidos
Complejidad del sistema, desarrollo de software ms costoso, problemas de
sincronizacin, dificultad para conocer la correccin de los algoritmos
paralelos, deteccin de cadas de nodos
Dependencia de la red de comunicaciones, sobrecarga de procesamiento
de mensajes
Dificultad de diseo, fases adicionales
Poca madurez de los productos comerciales, orientados a replicacin
Funciones de administracin compleja, sincronizacin y coordinacin
Dificultad de cambio, inexistencia de metodologas
Personal especializado

Diagrama con las relaciones entre los aspectos relevantes sobre las BDD.

Factores importantes en BDD.

Componentes de una base de datos

BD locales
SGBDD
Diccionario o directorio global
Sgbdd:

Es un software que administra y controla las bases de datos distribuidas de

manera transparente.
Las responsabilidades del sgbdd sern:
5

 Transparencia de red
Transparencia de fragmentacin
Transparencia de copias o duplicacin
Propagacin de actualizaciones
Procesamiento de consultas distribuidas, definicin de estrategias
Mantener un diccionario integrado
Control de concurrencia, integridad de la BDD, consistencia entre las
mltiples copias de los datos
Fiabilidad de los SGBDD, capaz de recuperar y devolver a las bases de
datos implicadas en el fallo un estado consistente y estable
Soporte de sistema operativo
Bases de datos heterogneas, mecanismos de traduccin
Sgbdd paralelo:

Este sistema gestor se ejecuta sobre mltiples procesadores y hace uso de

mltiples discos, se encuentra diseado para poder realizar operaciones en
paralelo, siempre que sea posible, con la finalidad de mejorar las prestaciones.

COMPARACION DE LAS BASES DE DATOS DISTRIBUIDAS CON LAS

CENTRALIZADAS.

CENTRALIZADO
Control centralizado:
un solo DBA

DISTRIBUIDO
Control jerrquico:
DBA global y DBA local

Independencia de Datos:
Transparencia en la Distribucin:
Organizacin de los datos es transparente Localizacin de los datos es un aspecto
para el programador
adicional de independencia de datos

Reduccin de redundancia:
Una sola copia de datos que se comparta

Replicacin de Datos:
Copias mltiples de datos que incrementa
la localidad y la disponibilidad de datos

Estructuras fsicas complejas para accesos No hay estructuras intersitios. Uso de

eficientes
optimizacin
global
para
reducir
transferencia de datos

Seguridad

Problemas de seguridad intrnsecos

1.2 OBJETIVOS DE LA BASE DE DATOS DISTRIBUIDAS

Objetivos de Implementacin
Al implementar una base de datos distribuida se tienen ciertos objetivos comunes:

Transparencia de ubicacin. Permite a los usuarios tener acceso a los

datos sin que tenga conocimiento de la ubicacin de stos. Se puede
conseguir este nivel de transparencia al utilizar los administradores de
transacciones distribuidas, los cuales son capaces de determinar la
localizacin de los datos y de emitir acciones a los calendarizadores
apropiados, lo cual puede ejecutarse cuando los administradores de
transacciones distribuidas poseen acceso a los directorios de localizaciones
de los datos.

Transparencia de duplicacin. Para que la transparencia de duplicacin

sea posible, los administradores de transacciones deben traducir las
solicitudes de procesamiento de transaccin en acciones para el
administrador de datos. Para las lecturas el administrador de transacciones
selecciona uno de los nodos que almacena los datos y ejecuta la lectura.
Para optimizar el proceso, el administrador de transacciones necesita
informacin sobre el rendimiento de varios nodos respecto al sitio de
consulta, as podr seleccionar el nodo de mejor rendimiento. La
actualizacin y escritura de datos duplicados suelen ser ms complicadas,
ya que el manejador de transacciones debe emitir una accin de escritura
para cada uno de los calendarizadores que almacena una copia de los
datos.
7

Transparencia de concurrencia. Cuando varias transacciones se ejecuten

al mismo tiempo, los resultados de las transacciones no debern afectarse.
La trasparencia de concurrencia se logra si los resultados de todas las
transacciones concurrentes son consistentes de manera lgica con los
resultados que se habran obtenido si las transacciones se hubieran
ejecutado una por una, en cualquier orden secuencial.

Transparencia de fallas. Significa que a pesar de fallas las transacciones

sean procesadas de un modo correcto. Frente a una falla, las transacciones
deben ser atmicas, significa que se procesen todas o ninguna de ellas.
Para este tipo de problemas es importante tener resguardo de la base de
datos, y as poder restaurarla cuando sea conveniente. El sistema debe
detectar cundo falla una localidad y tomar las medidas necesarias para
recuperarse del fallo. El sistema no debe seguir utilizando la localidad que
fall. Por ltimo, cuando se recupere o repare esta localidad, debe contarse
con mecanismos para reintegrarla al sistema con el mnimo de
complicaciones.

Localidad del procesamiento. Los datos se deben distribuir lo ms cerca

posible de las aplicaciones que los usan para maximizar la localidad del
procesamiento, este principio responde a minimizar el acceso remoto a los
datos. Disear una distribucin que maximice localidad del procesamiento
puede hacerse aadiendo la cantidad de referencias locales y remotas
correspondientes a cada fragmentacin candidata y asignar la
fragmentacin eligiendo la mejor solucin. Independencia de configuracin.
La independencia de configuracin permite aadir o reemplazar hardware
sin tener que cambiar componentes de software existentes en el sistema de
base de datos distribuida.

Particionamiento de la Base de Datos. La base de datos se distribuye de

modo que no haya solapamiento o duplicacin de los datos mantenidos en
las diferentes localidades, como no hay duplicaciones de los datos, se
evitan los costos asociados con el almacenamiento y mantenimiento de
datos redundantes. Si un mismo segmento de datos se usa en ms de una
localidad se ve limitada la disponibilidad de los datos. La fiabilidad tambin
puede verse limitada cuando se produce un fallo en el sistema de clculo
de una localidad se afecta la disponibilidad de los datos de esa localidad no
estn disponible para los usuarios en cualquier parte del sistema.

Fragmentacin de datos. Consiste en subdividir las relaciones y

distribuirlas entre los sitios de la red, tiene como objetivo buscar formas
alternativas de dividir una las instancias (tablas) de relaciones en otras ms
pequeas. La fragmentacin se puede realizar por tuplas individuales
(fragmentacin horizontal), por atributos individuales fragmentacin vertical)
o una combinacin de ambas (fragmentacin hbrida). El principal problema
de la fragmentacin radica en encontrar la unidad apropiada de distribucin.
8

Una relacin no es una buena unidad por muchas razones. Normalmente

las vistas de una relacin estn formadas por subconjuntos de relaciones.
Adems, las aplicaciones acceden localmente a subconjuntos de
relaciones. Por ello, es necesario considerar a los subconjuntos de
relaciones como unidad de distribucin. Al descomponer de una relacin en
fragmentos, tratados cada uno de ellos como una unidad de distribucin,
permite el proceso concurrente de las transacciones. El conjunto de estas
relaciones, provocar la ejecucin paralela de una consulta al ser dividida
en una serie de subconsultas que operar sobre los fragmentos. Cuando
las vistas definidas sobre una relacin son consideradas como unidad de
distribucin que se ubican en diferentes sitios de la red, podemos optar por
dos alternativas diferentes: La relacin no estar replicada y se almacena
en un nico sitio, o existe rplica en todos o algunos de los sitios en los
cuales reside la aplicacin. Las consecuencias de esta estrategia son la
generacin de un volumen de accesos remotos que pueden ser
innecesarios con un mal manejo de estas replicas. Adems, las rplicas
innecesarias pueden causar problemas en la ejecucin de las
actualizaciones y puede no ser deseable si el espacio de almacenamiento
est limitado. Los inconvenientes de la fragmentacin estn dados en que
si las pueden estar definidas por fragmentos mutuamente exclusivos y al
recuperar los datos de dos fragmentos situados en sitios diferentes es
necesario trasmitir los datos de un sitio a otro y realizar sobre ellos la
operacin de unin (Join), lo cual puede ser costoso. El control semntico
cuando los atributos implicados en una dependencia una relacin se
descompone en diferentes fragmentos y estos se ubican en sitios diferentes
puede ser muy costos porque es necesario hacer bsquedas en un gran
nmero de sitios.
Ventajas

Refleja una estructura organizacional - los fragmentos de la base de datos

se ubican en los departamentos a los que tienen relacin.
Autonoma local - un departamento puede controlar los datos que le
pertenecen.
Disponibilidad - un fallo en una parte del sistema solo afectar a un
fragmento, en lugar de a toda la base de datos.
Rendimiento - los datos generalmente se ubican cerca del sitio con mayor
demanda, tambin los sistemas trabajan en paralelo, lo cual permite
balancear la carga en los servidores.
Economa - es ms barato crear una red de muchas computadoras
pequeas, que tener una sola computadora muy poderosa.
Modularidad - se pueden modificar, agregar o quitar sistemas de la base de
datos distribuida sin afectar a los dems sistemas (mdulos).

Desventajas

Complejidad - Se debe asegurar que la base de datos sea transparente, se

debe lidiar con varios sistemas diferentes que pueden presentar dificultades
nicas. El diseo de la base de datos se tiene que trabajar tomando en
cuenta su naturaleza distribuida, por lo cual no podemos pensar en hacer
joins que afecten varios sistemas.
Economa - la complejidad y la infraestructura necesaria implica que se
necesitar una mayor mano de obra.
Seguridad - se debe trabajar en la seguridad de la infraestructura as como
cada uno de los sistemas.
Integridad - Se vuelve difcil mantener la integridad, aplicar las reglas de
integridad a travs de la red puede ser muy caro en trminos de transmisin
de datos.
Falta de experiencia - las bases de datos distribuidas son un campo
relativamente nuevo y poco comn por lo cual no existe mucho personal
con experiencia o conocimientos adecuados.
Carencia de estndares - an no existen herramientas o metodologas que
ayuden a los usuarios a convertir un DBMS centralizado en un DBMS
distribuido.

PRINCIPIO FUNDAMENTAL
ANTE EL USUARIO, UN SISTEMA DISTRIBUIDO DEBE LUCIR
EXACTAMENTE IGUAL QUE UN SISTEMA QUE NO ES DISTRIBUIDO
1.-AUTONOMA LOCAL
Los sitios en un sistema distribuido deben ser autnomos, la autonoma local
significa que todas las operaciones en un sitio dado estn controladas por ese
sitio; ningn sitio X debe depender de algn otro sitio Y para su operacin
satisfactoria.
La seguridad, integridad y representacin de almacenamiento de los datos locales
permanecen bajo el control y jurisdiccin del sitio local.
2.-NO DEPENDENCIA DE UN SITIO CENTRAL
La autonoma local implica que todos los sitios deben ser tratados como iguales.
Por lo tanto, no debe haber particularmente ninguna dependencia de un sitio
maestro central para algn servicio central, tal que todo el sistema dependa de
ese sitio central.
Razones por las cuales no debera haber un sitio central:

El sitio central puede ser un cuello de botella

El sistema sera vulnerable; es decir, si el sitio central falla, tambin fallar

todo el sistema

10

3.-OPERACIN CONTINUA
Una ventaja de los sistemas distribuidos es que deben proporcionar mayor
confiabilidad y mayor disponibilidad.
Confiabilidad. La probabilidad de que el sistema est listo y funcionando en
cualquier momento dado. Los SD no son una propuesta de todo o nada; pueden
continuar operando cuando hay alguna falla en algn componente independiente.
Disponibilidad. La probabilidad de que el sistema est listo y funcionando
continuamente a lo largo de un perodo especificado.
4.- INDEPENDENCIA DE UBICACIN.
Conocida tambin como transparencia de ubicacin, donde los usuarios no tienen
que saber dnde estn almacenados fsicamente los datos, sino que deben ser
capaces de comportarse como si todos los datos estuvieran almacenados en su
propio sitio local.
Esto simplifica los programas de los usuarios. En particular, permite que los datos
emigren de un sitio a otro sin invalidar ninguno de estos programas o actividades
5.- INDEPENDENCIA DE FRAGMENTACIN.
Un sistema soporta la fragmentacin de datos cuando puede ser dividida en o
partes o fragmentos, para efectos de almacenamiento fsico.
La fragmentacin es necesaria por razones de rendimiento: los datos pueden estar
almacenados en la ubicacin donde son usados ms frecuentemente para que la
mayora de las operaciones sean locales y se reduzca el trfico en la red.
Los usuarios deben comportarse como si los datos en realidad estuvieran sin
fragmentacin alguna.
6.- INDEPENDENCIA DE REPLICACIN.
El sistema soporta replicacin de datos cuando un fragmento puede ser
representado por muchas copias distintas, o rplicas, guardadas en muchos sitios
distintos.
Las rplicas son necesarias por dos razones principales:
Significan un mejor rendimiento (las aplicaciones pueden operar sobre las copias
locales en lugar de tener que comunicarse con sitios remotos)
Pueden significar una mejor disponibilidad (un objeto replicado permanece
disponible para su procesamiento, mientras est disponible al menos una copia).
Por supuesto, la principal desventaja de las rplicas es que al actualizarlas es
necesario actualizar todas: el problema de la propagacin de la actualizacin.
7.- PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS.
La optimizacin es importante en un sistema distribuido que en uno centralizado,
incluso mucho ms.
11

El punto bsico es que en una consulta que involucra a varios sitios, habr
muchas formas posibles de mover los datos en el sistema para satisfacer la
solicitud, y es crucialmente importante que se encuentre una estrategia eficiente.
8.- ADMINISTRACIN DE TRANSACCIONES DISTRIBUIDAS.
Existen dos aspectos principales en la administracin de transacciones: control de
recuperacin y control de la concurrencia.
Ambos aspectos requieren un tratamiento amplio en el ambiente distribuido.
Ya que una sola transaccin puede involucrar la ejecucin de cdigo en muchos
sitios. Puede involucrar actualizaciones en muchos sitios y se debe de cuidar que
la transaccin no caiga en un bloqueo mortal (basado en el bloqueo). Para el
control de la recuperacin, es necesario asegurarse que una transaccin dada sea
atmica en el ambiente distribuido, el sistema debe por lo tanto asegurarse de que
la transaccin sea confirmada o deshecha (se puede utilizar el protocolo de
confirmacin de dos fases).
9.- INDEPENDENCIA DE HARDWARE.
Soporte para un gran nmero de mquinas diferentes. Poder integrar todos los
datos de todos estos sistemas y presentar al usuario una imagen del sistema
nico.
10.- INDEPENDENCIA DE SISTEMA OPERATIVO.
Obviamente es necesario no slo tener la posibilidad de ejecutar el mismo DBMS
en diferentes plataformas de hardware, sino tambin ejecutarlo en diferentes
plataformas de sistema operativo.
11.- INDEPENDENCIA DE RED.
Si el sistema va a tener la posibilidad de soportar muchos sitios distintos es
obviamente necesario tener la posibilidad de soportar tambin una variedad de
redes de comunicacin distintas

1.3 DISCIPLINAS ESTUDIO BASES DE DATOS

DISTRIBUIDAS
Las disciplinas de estudio de las bases de datos distribuidas son muchas,
constan de estudiar en si cmo se comportan los datos mediante unas bases de
datos y como tener que procesarse esa informacin que se almacena, cabe
mencionar que cada base de datos tiene su propio fin y cada una de ellas varia su
funcionamiento como por ejemplo:

12

Multi Base de Datos Distribuida

Cuando una base de datos distribuida es muy homognea se dice que es
multi base de datos distribuida.
Base de Datos Federada
Cuando una base de datos distribuida tiene mucha autonoma local se dice que es
federada.
1.4 ARQUITECTURA DE BASE DE DATOS DISTRIBUIDAS
En un sistema de bases de datos distribuidas, existen varios factores que deben
tomar en consideracin que definen la arquitectura del sistema:
1. Distribucin: Los componentes del sistema estn localizados en la misma
computadora o no.
2. Heterogeneidad: Un sistema es heterogneo cuando existen en l
componentes que se ejecutan en diversos sistemas operativos, de
diferentes fuentes, etc.
3. Autonoma: Se puede presentar en diferentes niveles, los cuales se
describen a continuacin:

Autonoma de diseo: Habilidad de un componente del para decidir

cuestiones relacionadas a su propio diseo.
Autonoma de comunicacin: Habilidad de un componente del para decidir
cmo y cundo comunicarse con otros SMBD.
Autonoma de ejecucin: Habilidad de un componente del para ejecutar
operaciones locales como quiera.

Hay tres caractersticas importantes inherentes a los sistemas de bases de datos:

la separacin entre los programas de aplicacin y los datos, el manejo de mltiples
vistas por parte de los usuarios y el uso de un catlogo para almacenar el
esquema de la base de datos. En 1975, el comit ANSI-SPARC (American
National Standard Institute - Standards Planning and Requirements Committee)
propuso una arquitecturade tres niveles para los sistemas de bases de datos, que
resulta muy til a la hora de conseguir estas tres caractersticas.
La definicin de un sistema de informacin es la descripcin detallada de la
arquitectura del sistema. Las arquitecturas de bases de datos han evolucionado
mucho desde sus comienzos, aunque la considerada estndar hoy en da es la
descrita por el comit ANSI/X3/SPARC (Standard Planning and Requirements
Committee of the American National Standards Institute on Computers and
Information Processing), que data de finales de los aos setenta. Este comit
propuso una arquitectura general para DBMSs basada en tres niveles o
esquemas: el nivel fsico, o de mquina, el nivel externo, o de usuario, y el nivel
13

conceptual. As mismo describi las interacciones entre estos tres niveles y todos
los elementos que conforman cada uno de ellos.

Arquitectura ANSI
La arquitectura de sistemas de bases de datos de tres esquemas fue aprobado
por la ANSI-SPARC (American National Standard Institute - Standards Planning
and Requirements Committee) en 1975 como ayuda para conseguir la separacin
entre los programas de aplicacin y los datos, el manejo de mltiples vistas por
parte de los usuarios y el uso de un catlogo para almacenar el esquema de la
base de datos.

Nivel interno: Tiene un esquema interno que describe la estructura fsica

de almacenamiento de base de datos. Emplea un modelo fsico de datos y los
nicos datos que existen estn realmente en este nivel.

Nivel conceptual: tiene esquema conceptual. Describe la estructura de

toda la base de datos para una comunidad de usuarios. Oculta los detalles
fsicos de almacenamiento y trabaja con elementos lgicos como entidades,
atributos y relaciones.

Nivel externo o de vistas: tiene varios esquemas externos o vistas de

usuario. Cada esquema describe la visin que tiene de la base de datos a un
grupo de usuarios, ocultando el resto.

El objetivo de la arquitectura de tres niveles es el de separar los programas de

aplicacin de la base de datos fsica.
La mayora de los SGBD no distinguen del todo los tres niveles. Algunos incluyen
detalles del nivel fsico en el esquema conceptual. En casi todos los SGBD que se
manejan vistas de usuario, los esquemas externos se especifican con el mismo
modelo de datos que describe la informacin a nivel conceptual, aunque en
algunos se pueden utilizar diferentes modelos de datos en los niveles
conceptuales y externos.
Hay que destacar que los tres esquemas no son ms que descripciones de los
mismos datos pero con distintos niveles de abstraccin. Los nicos datos que
existen realmente estn a nivel fsico, almacenados en un dispositivo como puede
ser un disco. En un SGBD basado en la arquitectura de tres niveles, cada grupo
de usuarios hace referencia exclusivamente a su propio esquema externo. Por lo
tanto, el SGBD debe transformar cualquier peticin expresada en trminos de un
esquema externo a una peticin expresada en trminos del esquema conceptual,
y luego, a una peticin en el esquema interno, que se procesar sobre la base de
datos almacenada. Si la peticin es de una obtencin (consulta) de datos, ser
preciso modificar el formato de la informacin extrada de la base de datos
almacenada, para que coincida con la vista externa del usuario. El proceso de
transformar peticiones y resultados de un nivel a otro se denomina

14

correspondencia o transformacin. Estas correspondencias pueden requerir

bastante tiempo, por lo que algunos SGBD no cuentan con vistas externas.
La arquitectura de tres niveles es til para explicar el concepto de independencia
de datos que podemos definir como la capacidad para modificar el esquema en un
nivel del sistema sin tener que modificar el esquema del nivel inmediato superior.
Se pueden definir dos tipos de independencia de datos:
La independencia lgica es la capacidad de modificar el esquema conceptual sin
tener que alterar los esquemas externos ni los programas de aplicacin. Se puede
modificar el esquema conceptual para ampliar la base de datos o para reducirla.
Si, por ejemplo, se reduce la base de datos eliminando una entidad, los esquemas
externos que no se refieran a ella no debern verse afectados.
La independencia fsica es la capacidad de modificar el esquema interno sin tener
que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser
necesario reorganizar ciertos ficheros fsicos con el fin de mejorar el rendimiento
de las operaciones de consulta o de actualizacin de datos. Dado que la
independencia fsica se refiere slo a la separacin entre las aplicaciones y las
estructuras fsicas de almacenamiento, es ms fcil de conseguir que la
independencia lgica.
En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el
catlogo o diccionario, de modo que incluya informacin sobre cmo establecer la
correspondencia entre las peticiones de los usuarios y los datos, entre los diversos
niveles. El SGBD utiliza una serie de procedimientos adicionales para realizar
estas correspondencias haciendo referencia a la informacin de correspondencia
que se encuentra en el catlogo. La independencia de datos se consigue porque
al modificarse el esquema en algn nivel, el esquema del nivel inmediato superior
permanece sin cambios, slo se modifica la correspondencia entre los dos niveles.
No es preciso modificar los programas de aplicacin que hacen referencia al
esquema del nivel superior.
Por lo tanto, la arquitectura de tres niveles puede facilitar la obtencin de la
verdadera independencia de datos, tanto fsica como lgica. Sin embargo, los dos
niveles de correspondencia implican un gasto extra durante la ejecucin de una
consulta o de un programa, lo cual reduce la eficiencia del SGBD. Es por esto que
muy pocos SGBD han implementado esta arquitectura completa.
En el presente punto se mostrar la arquitectura general de un sistema de bases
de datos distribuida
La arquitectura define la estructura de un sistema. Al definir la arquitectura se
deben identificar las componentes de un sistema, las funciones que realiza cada
una de las componentes y las interrelaciones e interacciones entre cada
componente.

15

1.-Arquitecturas de memoria compartida

Consisten de diversos procesadores los cuales accesan una misma memoria y
una misma unidad de almacenamiento (uno o varios discos). Algunos ejemplos de
este tipo son las computadoras sequent encor y los mainframes IBM4090 y Bull
DPS8 (figura 1).

2.-Arquitectura de disco compartido

Consiste de diversos procesadores cada uno de ellos con su memoria local pero
compartiendo una misma unidad de almacenamiento (uno o varios). Ejemplo de
estas arquitecturas son los clster de digital, y los modelos IMS/VS data sharing
de IBM.

16

3. Arquitecturas de nada compartido

Consiste de diversos procesadores cada uno con su propia memoria y su propia
unidad de almacenamiento. Aqu se tienen los clsters de estaciones de trabajo,
las computadoras Intel paragn, NCR 3600 y 3700 e IBM SP2

17

TRMINOS DE REPASO

Sgbdd

Base de de datos centralizados

Base de datos distribuidos

Objetivos de la base de datos distribuidos

Independencia de replicacin

Autonoma local

Operacin continua

Complejidad del sistema

Dependencia de la red de comunicaciones

Control de concurrencia

Reduccin de redundancia

Procesamiento de consultas distribuidas.

Arquitectura de disco compartido

18

AUTO EVALUACION
1.- Explique la diferencia que existe entre la base de datos distribuido y uno
centralizado.
2.- Enliste los objetivos de la base de datos distribuidos.

3.- Mencione los tipos de arquitectura de la base de datos distribuidos.

4.-Menciona las caractersticas de la base de datos distribuidos

5.-La base de datos distribuidos posee ciertas ventajas, cules son:

6.-Menciona 4 desventajas de la base de datos distribuidos.
7.- Explique la diferencia de un Sgbdd y un Sgbdd en paralelo.
8.- A que objetivo se le conoce tambin como transparencia de ubicacin

9.- Existen dos aspectos principales en la administracin de transacciones, cuales

son:
10.-Las rplicas son necesarias por dos razones principales, mencinalas:

11.-Menciona una ventaja de los sistemas distribuidos

12.- Define que es una arquitectura de memoria compartida

13.-Mencione las responsabilidades del sgbdd.

19

2 UNIDAD: DISEO DE BASES DE DATOS DISTRIBUIDAS

2.1 CONSIDERACIONES DE DISEO DE BASES DE DATOS DISTRIBUIDAS
BASE DE DATOS DISTRIBUIDAS:
Una base de datos distribuidas (llamada tambin BDD),es una coleccin de
datos relacionados lgicamente ,pero dispersos sobre diferentes puntos de una
red de computadoras. Cada sitio en la red tiene la capacidad de procesamiento
autnomo y puede ejecutar aplicaciones locales.

Consideraciones al distribuir la base de datos

Existen varias razones para construir sistemas distribuidos de bases de
datos que incluyen compartir la informacin, fiabilidad y disponibilidad y agilizar el
procesamiento de las consultas. Pero tambin tiene sus desventajas, como
desarrollos de software ms costosos, mayor posibilidad de errores y costos
extras de procesamiento.
Ventajas de la distribucin de datos
La principal ventaja de los sistemas distribuidos es la capacidad de compartir y
acceder a la informacin de una forma fiable y eficaz.
Utilizacin compartida de los datos y distribucin del control
La ventaja principal de compartir los datos por medio de la distribucin es que
cada localidad pueda controlar hasta cierto punto los datos almacenados
localmente. En un sistema centralizado, el administrador de base de datos de
la localidad central controla la base de datos.
En un sistema distribuido existe un administrador global de la base de datos
que se encarga de todo el sistema. Parte de esta responsabilidad se delega al
administrador de base de datos de cada localidad. Dependiendo del diseo del

20

sistema distribuido, cada administrador local podr tener un grado de

autonoma diferente, que se conoce como autonoma local.
La posibilidad de contar con autonoma local es en muchos casos una ventaja
importante de las bases de datos distribuidas.
Fiabilidad y disponibilidad
Si se produce un fallo en una localidad de un sistema distribuido, es posible
que las dems localidades puedan seguir trabajando. En particular, si los datos se
repiten en varias localidades, una transaccin que requiere un dato especfico
puede encontrarlo en ms de una localidad. As, el fallo de una localidad no
implica necesariamente la desactivacin del sistema.
El sistema debe detectar cuando falla una localidad y tomar las medidas
necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la
localidad que fall. Por ltimo, cuando se recupere o repare esta localidad, debe
contarse con mecanismos para reintegrarla al sistema con el mnimo de
complicaciones.
La disponibilidad es fundamental para los sistemas de bases de datos que se
utilizan en aplicaciones de tiempo real. Por ejemplo, si una lnea area no puede
tener acceso a la informacin, es posible que pierda clientes a favor de la
competencia.
Agilizacin del procesamiento de consultas
Si una consulta comprende datos de varias localidades, puede ser posible dividir
la consulta en varias subconsultas que se ejecuten en paralelo en distintas
localidades. Sin embargo, en un sistema distribuido no se comparte la memoria
principal, as que no todas las estrategias de interseccin se pueden aplicar en
estos sistemas. En los casos en que hay repeticin de los datos, el sistema puede
pasar la consulta a las localidades ms ligeras de carga.
Desventajas de la distribucin de los datos
La desventaja principal de los sistemas distribuidos es la mayor complejidad
que se requiere para garantizar una coordinacin adecuada entre localidades.
El aumento de la complejidad se refleja en:
Coste del desarrollo de software: es ms difcil estructura un sistema de bases
de datos distribuidos y por tanto su coste es menor
Mayor posibilidad de errores: puesto que las localidades del sistema
distribuido operan en paralelo, es ms difcil garantizar que los algoritmos
sean correctos.
Mayor tiempo extra de procesamiento: el intercambio de mensajes y los
clculos adicionales son una forma de tiempo extra que no existe en los
sistemas centralizados.

21

Existen varios factores relacionados a la construccin de bases de datos

distribuidas que no se presentan en bases de datos centralizadas. Entre los ms
importantes se encuentran los siguientes:

Diseo de la base de datos distribuidas

Procesamiento de consultas
Control de concurrencia
Confiabilidad

En el diseo de bases de datos distribuidas se debe considerar el problema de

cmo distribuir la informacin entre diferentes sitios. Existen razones
organizacionales las cuales determinan en gran medida lo anterior. Sin embargo,
cuando se busca eficiencia en el acceso a la informacin, se deben abordar dos
problemas relacionados.
1.- Como fragmentar la informacin
2.- Como asignar cada fragmento entre los diferentes sitios de la red
En el diseo de la base de datos distribuidos tambin es importante considerar si
la informacin esta replicada, es decir, si existen copias mltiples del mismo dato
y, en caso, como mantener la consistencia de la informacin. Finalmente, una
parte importante en el diseo de una base de datos distribuidas se refiere al
manejo del directorio. Si existen nicamente usuarios globales, se debe manejar
un solo directorio global. Sin embargo, existen tambin usuarios locales, el
directorio combina informacin local con informacin global.
La organizacin de los sistemas de base de datos distribuidos se pude analizar en
3 dimensiones:

22

Nivel de comparticin

Inexistentes

Comparticin de datos

Comparticin de datos
y programas

Esttico

Cada aplicacin y sus datos se ejecutan en una

maquina sin comunicacin con otros programas o
datos

Cada mquina posee sus propias aplicaciones

locales pero se comparten los datos

Las aplicaciones locales en una maquina

pueden invocar servicios en otras y edemas
comparten los datos

El modelo de acceso a los datos no vara con el

tiempo

Caractersticas de
acceso
Dinmico

El modelo de acceso a los datos vara con el tiempo

23

Nivel de conocimiento

Sin informacin

Con informacin
parcial

Con informacin
total

Los diseadores no tienen informacin de cmo

acceden los usuarios a los datos

Los diseadores no poseen toda la informacin de

cmo acceden los usuarios a los datos

Los diseadores poseen toda la informacin de

cmo aceden los usuarios a los datos

A la hora de abordar el diseo de una base de datos distribuida podremos optar

principalmente por dos tipos de estrategias:
La estrategia ascendente (botton up).- En este caso se partir de los esquemas
conceptuales locales y se trabajara para llegar a conseguir el esquema
conceptual global. Despus se pasara al diseo de distribucin. Esta estrategia
suele ser utilizada para integrar varias bases de datos centralizadas existentes
La estrategia descendente (top - Dow).- Se parte de cero y se avanza en el
desarrollo del trabajo. Los pasos a realizar mediante esta estrategia son:

Anlisis de requisitos
Diseo de vistas
Diseo conceptual
Diseo de la distribucin
Fragmentacin
Asignacin
Diseo fsico
Monitorizacin y ajuste

24

Factores tomados en cuenta:

Repeticin.- El diseador debe considerar que ese sistema mantendr
varias copias idnticas. Cada copia se almacenara en una localidad
diferente lo que resulta en una repeticin de la informacin.
Fragmentacin.- Las relaciones de una base de datos distribuida se puede
dividir en varios fragmentos. Cada fragmento se almacenara en una
localidad diferente, es decir el diseador debe evaluar la propiedad de que
haya fragmentado en diferentes localidades.
Repeticin y fragmentacin.- Esta consideracin es de suma importancia
porque es la combinacin de los dos conceptos antes mencionados; es
decir, el sistema debe de ser capaz de mantener varias copias idnticas de
cada uno de los fragmentos.

25

26

2.2 DICCIONARIO DE DATOS

Es el lugar donde se deposita informacin acerca de todos los datos que forman la
base de datos. Es una gua en la que se describe la base de datos y los objetos
que la forman.
Los diccionarios de datos son el segundo componente del anlisis del flujo
de datos. En s mismos los diagramas de flujo de datos no describen por completo
el objeto de la investigacin. El diccionario de datos proporciona informacin
adicional sobre el sistema. Esta seccin analiza que es un diccionario de datos,
por qu se necesita en el anlisis de flujo de datos y como desarrollarlo. Se
utilizar el ejemplo del sistema de contabilidad para describir los diccionarios de
datos.
Un diccionario de datos es una lista de todos los elementos incluido en el
conjunto de los diagramas de flujo de datos que describen un sistema. Los
elementos principales en un sistema, estudiados en las secciones anteriores, son
el flujo de datos, el almacenamiento de datos y los procesos. El diccionario de
datos almacena detalles y descripciones de estos elementos.
El diccionario contiene las caractersticas lgicas de los sitios donde se almacenan
los datos del sistema, incluyendo nombre, descripcin, contenido y organizacin.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita
el acceso inmediato a la informacin.
Un diccionario de datos debe cumplir las siguientes caractersticas:
Debe soportar las descripciones de los modelos conceptual, lgico, interno
y externo de la dase de datos.
Debe estar integrado dentro del SGBD.
Debe apoyar la transferencia eficiente de informacin al SGBD. La conexin
entre los modelos internos y externo debe ser realizada en un tiempo de
ejecucin.
Debe comenzar con la reorganizacin de versiones de produccin de la
base de datos. Adems debe reflejar los cambios en la descripcin de la
BD. Cualquier cambio a la descripcin de programas ha de ser reflejado
automticamente en la librera de descripcin de programas con la ayuda
del diccionario de datos.
Debe estar almacenado en un medio de almacenamiento con acceso
directo para la fcil recuperacin de informacin

27

Ejemplo de diccionario de datos:

2.3 NIVELES DE TRANSPARENCIA

El propsito de establecer una arquitectura de un sistema de bases de datos
distribuidas es ofrecer un nivel de transparencia adecuado para el manejo de la
informacin.
La transparencia se puede entender como la separacin de la semntica de alto
nivel de un sistema de los aspectos de bajo nivel relacionados a la implementacin
del mismo. Un nivel de transparencia adecuado permite ocultar los detalles de
implementacin a las capas de alto nivel de un sistema y a otros usuarios.
En sistemas de bases de datos distribuidos el propsito fundamental de la
transparencia es proporcionar independencia de datos en el ambiente distribuido.
La independencia de datos es la inmunidad de las aplicaciones de usuario a los
cambios en la definicin y/u organizacin de los datos y viceversa. La
independencia de datos se puede dar en dos aspectos: lgica y fsica.
Independencia lgica de datos. Se refiere a la inmunidad de las aplicaciones de
usuario a los cambios en la estructura lgica de la base de datos. Esto permite
28

que un cambio en la definicin de un esquema no deba afectar a las aplicaciones

de usuario. Por ejemplo, el agregar un nuevo atributo a una relacin, la creacin
de una nueva relacin, el reordenamiento lgico de algunos atributos.
Independencia fsica de datos. Se refiere al ocultamiento de los detalles sobre
las estructuras de almacenamiento a las aplicaciones de usuario. Esto es, la
descripcin fsica de datos puede cambiar sin afectar a las aplicaciones de
usuario. Por ejemplo, los datos pueden ser movidos de un disco a otro, o la
organizacin de los datos puede cambiar.
Los diferentes niveles de transparencia se pueden organizar en capas como se
muestra en la figura siguiente. En el primer nivel se soporta la transparencia de
red. En el segundo nivel se permite la transparencia de replicacin de datos. En el
tercer nivel se permite la transparencia de la fragmentacin. Finalmente, en el
ltimo nivel se permite la transparencia de acceso (por medio de lenguaje de
manipulacin de datos).
La responsabilidad sobre el manejo de transparencia debe estar compartida tanto
por el sistema operativo, el sistema de manejo de bases de datos y el lenguaje de
acceso a la base de datos distribuida.

Segn el manual de referencia ANSA y el modelo de referencia para el

procesamiento distribuido abierto de la organizacin internacional de estndares,
el concepto se aplica a 8 aspectos diferentes:
Transparencia de acceso: oculta las diferencias entre la representacin de
los datos y la manera en que los recursos son accedidos.
Transparencia de ubicacin: oculta la localizacin de los recursos y permite
el acceso a los mismos sin la necesidad de conocer su localizacin.
Transparencia de migracin: oculta que un recurso o un cliente del sistema
sea reubicado, lo que permite hacer dichas reubicaciones sin afectar la
operacin de los usuarios y los servicios.
Transparencia de recolocacin: oculta que un recurso o cliente del sistema
pueda moverse a una ubicacin diferente mientras estn en uso.
Transparencia de replicacin: oculta la existencia de mltiples ejemplares
del mismo recurso.
Transparencia de concurrencia: oculta que un recurso sea compartido por
varios usuarios sin interferir entre ellos mismos.
Transparencia frente a fallos: oculta los fallos y recuperacin de un recurso
dentro del sistema, dejando que los usuarios terminen sus tareas a pesar
de los fallos de hardware o software que pudieran presentarse.
Transparencia de persistencia: oculta si un recurso de software est
almacenado en memoria o en disco.

29

Organizacin en Capas de los Niveles de Transparencia.

Se pueden encontrar diferentes aspectos

relacionados con la transparencia. Por
ejemplo, puede existir transparencia en el
manejo de copias repetidas o transparencia
en la distribucin o fragmentacin de la
informacin

2.3.1 TRANSPARENCIA DE LOCALIZACION

Transparencia sobre la localizacin de datos. Esto es, el comando que se usa
es independiente de la ubicacin de los datos en la red y del lugar en donde la
operacin se lleve a cabo. Por ejemplo, en Unix existen dos comandos para hacer
una copia de archivo. Se utiliza para copias locales y rcp se utiliza para copias
remotas. En este caso no existe transparencia sobre la localizacin.
Permite a los usuarios accesar a la informacin de un archivo cualquiera de la
base de datos sin necesidad de indicar en qu computadora se encuentra el
archivo.
La transparencia de localizacin busca que los usuarios no puedan distinguir la
localizacin de los recursos.
P.ej.: no usar nombres como: maq1:/src/prog.c

30

La transparencia de localizacin se logra creando un conjunto de seudnimos o

alias para cada usuario. As, el usuario puede referirse a los datos usando
nombres sencillos que el sistema traduce a nombres completos.
Con el uso de seudnimos, no ser necesario que el usuario conozca la
localizacin fsica de un dato. Adems, el administrador de la base de datos puede
cambiar un dato de una localidad a otra sin afectar a los usuarios.
2.3.2 TRANSPARENCIA DE FRAGMENTACION
La transparencia a nivel de fragmentacin de datos permite que cuando los
objetos de la bases de datos estn fragmentados, el sistema tiene que manejar la
conversin de consultas de usuario definidas sobre relaciones globales a
consultas definidas sobre fragmentos.
As tambin, ser necesario mezclar las respuestas a consultas fragmentadas
para obtener una sola respuesta a una consulta global. El acceso a una base de
datos distribuida debe hacerse en forma transparente.
Es el mayor nivel, el usuario o programador no necesita saber que una base de
datos esta en particiones. Ni los nombres, ni la ubicacin se especifican antes de
acceder a los datos.
Permite al usuario acceso a la informacin de un archivo fragmentado como si
todos los datos del archivo estuvieran en una misma computadora. Es decir,
cuando se crea transparencia de fragmentacin, el sistema crea la ilusin de que
los archivos no estn fragmentados
La transparencia a nivel de fragmentacin de datos permite que cuando los
objetos de las bases de datos estn fragmentados, el sistema tiene que manejar la
conversacin de consultas de usuarios definidas sobre relaciones globales a
consultas definidas sobre fragmentos.
As tambin, ser necesario mezclar las respuestas a consultas fragmentadas
para obtener una sola respuesta a una consulta global. El acceso a una base de
datos distribuida debe hacerse en forma transparente.
2.3.3 TRANSPARENCIA DE REPLICA
Los usuarios no pueden indicar el nmero de copias existentes.
La transparencia sobre la replicacin de datos se refiere a que si existen rplicas
de objetos de la base de datos, su existencia debe ser controlada por el sistema,
no por usuario, se debe tener en cuenta que cuando el sistema se encarga de
manejar las rplicas en un sistema, el trabajo de ste es mnimo por lo que se
puede obtener una eficiencia mayor.
Sin embargo, el usuario puede olvidarse de mantener la consistencia de las
rplicas teniendo as datos diferentes.
Por lo que se sugiere que las rplicas las haga el sistema en su totalidad sin que
el usuario se percate si est trabajando o no sobre una rplica.
31

Los usuarios ven cada objeto de datos como lgicamente nico. Puede que el
sistema distribuido replique los objetos para incrementar el rendimiento del
sistema o la disponibilidad de los datos.
Los usuarios no deben preocuparse por los objetos que se hayan replicado ni por
la ubicacin de esas rplicas.
El sistema conserva replicas (copias) idnticas de la relacin y guarda cada replica
en un sitio diferente. La alternativa a las rplicas es almacenar solo una copia de
la relacin r.
Si un archivo esta replicado, el usuario no distingue cual de las rplicas est
leyendo. Si un proceso realiza una actualizacin, el sistema operativo deber
actualizar todas las replica.
Ventajas:
Disponibilidad: El sistema sigue funcionando aun en caso de cada de uno de
los nodos
Aumento de paralelismo: Varios nodos pueden realizar consultas en paralelo
sobre la misma tabla. Cuantas ms replicas existan de la tabla, mayor ser la
posibilidad de que el dato buscado se encuentre en el nodo desde el que se
realiza la consulta, minimizando con ello el trfico de datos entre nodos.
2.4 FRAGMENTACION DE DATOS
La fragmentacin consiste en particionar la informacin para distribuir cada parte
en diferentes lugares de la red. De forma que cada relacin se divide en varios
fragmentos. Cada fragmento se guarda en una localizacin diferente.
Si la relacin r est fragmentada, se dividir en cierto nmero de fragmentos r1,
r2 rn. Estos fragmentos contendrn suficiente informacin como para permitir la
reconstruccin de la relacin original r.
La fragmentacin de la informacin se puede
llevar a cabo de tres formas:
Fragmentacin vertical.
Fragmentacin horizontal.
Fragmentacin mixta o hibrida.

32

El problema de fragmentacin se refiere al particionamiento de la informacin para

distribuir cada parte a los diferentes nodos y sitios de la red.
Grado de fragmentacin.

Cuando se va a fragmentar una base de datos deberamos sopesar qu grado de

fragmentacin va a alcanzar, ya que ste ser un factor que influir notablemente
en el desarrollo de la ejecucin de las consultas. El grado de fragmentacin puede
variar desde una ausencia de la divisin, considerando a las relaciones unidades
de fragmentacin; o bien, fragmentar a un grado en el que cada tupla o atributo
forme un fragmento. Ante estos dos casos extremos, evidentemente se ha de
buscar un compromiso intermedio, el cual debera establecerse sobre las
caractersticas de las aplicaciones que hacen uso de la base de datos.
1.- Completitud. Si una relacin R se descompone en una serie de fragmentos
R1, R2, ..., Rn, cada elemento de datos que pueda encontrarse en R deber poder
encontrarse en uno o varios fragmentos Ri. Esta propiedad extremadamente
importante asegura que los datos de la relacin global se proyectan sobre los
fragmentos sin prdida alguna.

2.- Reconstruccin. Si una relacin R se descompone en una serie de

fragmentos R1, R2, ..., Rn, puede definirse una operador relacional
tal que

El operador
ser diferente dependiendo de las diferentes formas de
fragmentacin. La reconstruccin de la relacin a partir de sus fragmentos asegura
la preservacin de las restricciones definidas sobre los datos en forma de
dependencias.
3.- Disyuncin. Si una relacin R se descompone horizontalmente en una serie
de fragmentos R1, R2, ..., Rn, y un elemento de datos di se encuentra en algn
fragmento Rj, entonces no se encuentra en otro fragmento Rk (k j). Esta regla
asegura que los fragmentos horizontales sean disjuntos. Si una relacin R se
descompone verticalmente, sus atributos primarios clave normalmente se repiten
en todos sus fragmentos.
2.4.1 FRAGMENTACION HORIZONTAL
La tabla T se divide en subconjuntos, T1, T2, ...Tn. Cada tupla de T debe
pertenecer al menos a uno de los fragmentos para poder reconstruir la tabla
original a partir de los fragmentos. Los fragmentos se definen a travs de una
operacin de seleccin y su reconstruccin se realizar en base a una operacin
de unin de los fragmentos componentes.

33

En el ejemplo siguiente, se ilustra una posible fragmentacin de la tabla Alumnos

de dos fragmentos: uno para el nodo de la EUI y otro para el nodo de la EUIT.
Nodos de las Escuelas:

La recuperacin de la relacin original se realizar a partir de la unin de cada uno

de los fragmentos: T= T1 T2... Tn
En nuestro caso: ALUMNOS=ALUMNOS_EUI ALUMNOS_EUIT

34

EJEMPLO 2
Considere la relacin J

La relacin J se puede fragmentar horizontalmente produciendo los siguientes

fragmentos

35

Fragmentacin horizontal primaria

Consiste del particionamiento en tuplas de una relacin global en subconjuntos,
donde cada subconjunto puede contener datos que tienen propiedades comunes y
se puede definir expresando cada fragmento como una operacin de seleccin
sobre la relacin global.
Ejemplo Considere la relacin global
SUPPLIER ( SNUM, NAME, CITY )
Entonces, la fragmentacin horizontal puede ser definida como:
SUPPLIER1 = SLcity == "SF"SUPPLIER
SUPPLIER1 = SLcity == "LA"SUPPLIER

1. Esta fragmentacin satisface la condicin de completes si "SF" y "LA" son

solamente los nicos valores posibles del atributo CITY.
2. La condicin de reconstruccin se logra con:
SUPPLIER = SUPPLIER1 unin SUPPLIER2
3. La condicin de disjuntos se cumple claramente en este ejemplo.
Fragmentacin horizontal derivada
La fragmentacin derivada horizontal se define partiendo de una fragmentacin
horizontal.
En esta operacin se requiere de Semi-junta (Semi-Join) el cual nos sirve para
derivar las tuplas o registros de dos relaciones.
Ejemplo Las siguientes relaciones definen una fragmentacin horizontal derivada
de la relacin SUPPLY.
SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1
SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2

36

2.4.2 FRAGMENTACION VERTICAL

La fragmentacin vertical, en cambio, se basa en los atributos de la relacin para

efectuar la divisin o fragmentacin.
Ejemplo:

La fragmentacin vertical es la subdivisin de atributos en grupos. Los fragmentos

se obtienen proyectando la relacin global sobre cada grupo. La fragmentacin es
correcta si cada atributo se mapea en al menos un atributo del fragmento.
Ejemplo Considere la siguiente relacin global:
EMP ( empnum, name, sal, tax, mgrnum, depnum )
Una fragmentacin vertical de esta relacin puede ser definida como:
EMP1 = PJempnum, name, mgrnum, depnum EMP
EMP2 = PJempnum, sal, tax EMP
la reconstruccin de la relacin EMP puede ser obtenida como:
EMP = EMP1 (JN empnum) EMP2 porque empnum es una clave de EMP
37

2.4.3 FRAGMENTACION MIXTA O HIBRIDA

Fragmentacin mixta o hibrida cuando el proceso de particin hace uso de los dos
tipos anteriores. La fragmentacin mixta puede llevarse a cabo de tres formas
diferentes:
1.- Desarrollando primero la fragmentacin vertical y posteriormente, aplicando
particin horizontal de los fragmentos verticales (denominada particin VH)
2.- Aplicando primero una divisin horizontal para luego, sobre los fragmentos
generados, desarrollar una fragmentacin vertical (llamada particin HV)
3.- De forma directa considerando la semntica de las transacciones.
Ejemplo de la fragmentacin mixta HV:
Ejemplo Considere la relacin global
EMP( empnum,
name, sal, tax,
mrgnum,
depnum )
Las siguientes
son
para
obtener
una
fragmentacin
mixta, aplicando
la
vertical
seguida de la
horizontal:
EMP1 = SL
depnum <= 10
PJempnum, name, mgrnum, depnum EMP
EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum EMP
EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum EMP
EMP4 = PJ empnum, name, sal, tax EMP
La reconstruccin de la relacin EMP es definida por la siguiente expresin:
EMP = UN(EMP1, EMP2, EMP3)JNempnum =
empnumPJempnum, sal, tax EMP4
Finalmente, como otro ejemplo considere el siguiente esquema global
EMP(EMPNUM, NAME, SAL, TAX, MGRNUM, DEPNUM)
38

DEP(DEPNUM, NAME, AREA, MGRNUM)

SUPPLIER(SNUM, NAME, CITY)
SUPPLY(SNUM, PNUM, DEPNUM, QUAN)

Despus de aplicar una fragmentacin mixta se obtiene el siguiente esquema

fragmentado
EMP1 = Sldepnum <= 10 PJempnum, name, mgrnum, depnum (EMP)
EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum
(EMP)
EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum (EMP)
EMP4 = PJ empnum, name, sal, tax (EMP)
DEP1 = SL depnum <= 10 (DEP)
DEP2 = SL 10 < depnum <= 20 (DEP)
DEP3 = SL depnum > 20 (DEP)
SUPPLIER1 = SL city == "SF" (SUPPLIER)
SUPPLIER2 = SL city == "LA" (SUPPLIER)
SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1
SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2

39

2.5 DISTRIBUCION DE DATOS

Describe el proceso de decidir donde localizar los datos.
Una de las decisiones ms importantes que el diseador de bases de datos
distribuidas debe tomar es el posicionamiento de los datos en el sistema y el
esquema bajo el cual lo desea hacer
Replicacin de datos
La replicacin de datos se refiere al almacenamiento de copias de datos en sitios
mltiples servidos por una red de computadoras. Pueden guardarse copias de
fragmento para satisfacer requerimientos de informacin especficos.
La replicacin en SQL Server consiste, en el transporte de datos entre dos o ms
instancias de servidores.
Base de datos totalmente replicada, guarda varias copias de cada
fragmento de la base de datos en varios sitios. No es prctica debido la
cantidad de carga impuesta al sistema.
Base de datos parcialmente replicada, guarda mltiples copias de
algunos fragmentos de la base de datos en mltiples sitios. Se tiene un
buen manejo
Base de datos no replicada, guarda cada fragmento de base de datos en
un solo sitio.
Suponga que la base de datos A esta dividida en fragmentos: A1 Y A2 dentro de
una base de datos distribuida replicada, es posible el escenario ilustrado en la
fig.10.20: el fragmento A1 se guarda en los sitios S1 y S2, mientras que el A2 se
guarda en los sitios S2y S3.

Los datos replicados requiere que todas las copias de fragmentos de datos sean
idntica, por consiguiente para mantener la consistencia de los datos entre las
replicas, el DDBMS debe garantizar que se realice una actualizacin de la base
de datos donde existen replicas.
La replicacin exige ms complejidad de procesamiento del DDBMS por que cada
copia de dato debe ser mantenida por el sistema.
40

 Si la base de datos est fragmentada el DDBMS debe decidir que copia

accesar
Una operacin read (lectura) selecciona la copia ms cercana para
satisfacer la transaccin.
Una operacin write (escritura) requiere que todas las copias se
seleccionen y se actualizan.
Tipos de replicacin
Los tipos bsicos de replicacin son:
replicacin de instantneas
replicacin transaccional
replicacin de mezcla
REPLICACIN DE INSTANTNEAS
En la replicacin de instantneas los datos se copian tal y como aparecen
exactamente en un momento determinado.
Por consiguiente, no requiere un control continuo de los cambios.
Las publicaciones de instantneas se suelen replicar con menos frecuencia que
otros tipos de publicaciones.
Puede llevar ms tiempo propagar las modificaciones de datos a los suscriptores.
Se recomienda utilizar: cuando la mayora de los datos no cambian con frecuencia
REPLICACIN TRANSACCIONAL
En este caso se propaga una instantnea inicial de datos a los suscriptores, y
despus, cuando se efectan las modificaciones en el publicador, las
transacciones individuales se propagan a los suscriptores
REPLICACIN DE MEZCLA
Permite que varios sitios funcionen en lnea o desconectados de manera
autnoma, y mezclar ms adelante las modificaciones de datos realizadas en un
resultado nico y uniforme.
TIPOS DE RELACIONES:
1.- RELACIONES BASE O REALES: Corresponde al concepto de Tabla es
decir una relacin autnoma cuya importancia est dada por el diseador para un
uso especifico dentro de una aplicacin
2.- RELACIONES VIRTUALES: (Relaciones de Vistas) Una vista es una
relacin derivada con nombre representada dentro del sistema exclusivamente
mediante su definicin en trmino de otras relaciones, no posee datos
41

almacenados propios, separados y distinguibles a diferencia de las relaciones

Bases, en si una VISTA.
3.- RELACIONES INSTANTANEAS: (Snap Shop) Es tambin una relacin
derivada con nombre como una vista pero a diferencia de esta ltima las
instantneas son reales no virtuales, es decir, estn representadas no solo por su
definicin, en trmino de otras relaciones con nombre, sino, tambin por sus
propios datos almacenados:
(Snap Shop = consulta rpida, corta)
Las estrategias que se tienen son:
Colocacin centralizada de los datos, toda la base de datos se guarda en
un sitio
Colocacin particionada de los datos, la base de datos se divide en varias
partes desarticuladas (fragmentos) y se guardan en varios sitios.
Colocacin replicada de los datos, se guardan copias de uno o ms
fragmentos de la base de datos en varios sitios.
La distribucin de los datos se logra mediante la particin de los datos,
replicados de los datos o mediante una combinacin de ambas.
La colocacin de los datos est estrechamente relacionada en como la BD
se divide o fragmenta. La colocacin de los datos ve que datos localizar y
en donde.
Los algoritmos de colocacin de los datos consideran varios factores,
incluidos:
Objetivos de desempeo y disponibilidad de los datos.
Tamao, numero de filas y el nmero de relaciones que una entidad
mantiene con otras entidades.
Tipos de transacciones a ser aplicadas a la base de datos.
2.5 1 ALGORITMOS DE DISTRIBUCION DE DATOS NO REPLICADOS
Permite maximizar el costo de comunicacin y al mismo tiempo maximizar el
tiempo de respuesta. El administrador de bases de datos debe de evaluar el modo
de operar de la base de datos, es decir como su nombre lo indica no podemos
realizar el algoritmo en aquellas copias, pero debe ser sobre la base de datos
original. La fragmentacin hibrida es de preferencia lo que debe de llevar este tipo
de algoritmos, porque estas utilizan las tres fragmentaciones y las ms
aconsejables.
Hablar de algoritmos implica sobre la Programacin
Hay gestores que son muy flexibles en cuestiones de programacin, mientras que
otros ofrecen ms rendimiento. As, al disear el algoritmo tendr que hacer toda
la informacin referente a la vida de la base de datos pero por otro lado deber
42

buscar siempre de darle soluciones al usuario, pues este ser el que al final de
cuentas interesa.
Existen en la actualidad infinidad de tecnologas en cuanto a los gestores de la
base de datos se refiere, el que utilizaremos (el ms actual) ser SQL SERVER,
este gestor comenz a crearse por la dcada de los 90s, ofrece muchas ventajas
sobre otros gestores, la nica desventaja que podramos encontrar en su
compatibilidad con los Windows ms comerciales como el 98, XP entre otros.
Se preguntaran que tiene que ver el gestor con los algoritmos de datos no
replicados, sin embargo la respuesta es muy sencilla, y esta es que este algoritmo
es fcil de implantar en SQL SERVER.
2.5.2 ALGORITMOS DE DISTRIBUCION DE DATOS REPLICADOS
Se refiere al almacenamiento de copias de datos en sitios mltiples, puede ser
para satisfacer requerimientos de informacin, adems de mejorar la
disponibilidad de los datos y el tiempo respuesta; finalmente estas copias reducen
los costos de comunicacin y de consulta total.
Los datos replicados se someten a la regla de consistencia mutua, la cual requiere
que todas las copias de fragmentos de datos sean idnticas, esto quiere decir que
cuando hay una actualizacin de la base de datos se realiza en todos los sitios
donde hay replicas.
El algoritmo de distribucin de datos replicados ser realizado principalmente para
los datos que ya tengan una copia aunque es muy til, lo cual podemos asegurar
que su utilizacin y programacin depender de un 100% del gestor que se
utilizando
SQL SERVER a pesar de su facilidad de utilizacin tambin incorpora
herramientas sofisticadas para aquellos usuarios de nivel avanzado. Entre algunas
de las novedades que trae SQL SERVER, es que integra un servidor completo y
un mdulo para la transformacin de datos.
Otras de las caractersticas que posee SQL SERVER es un bloqueo dinmico a
nivel de fila, paralelismo entre consultas; consultas distribuidas y permite aceptar
bases de datos de gran tamao.
Para crear una base de datos en SQL SERVER lo podemos hacer primeramente
usando el asistente de base de datos y la interfaz predefinida para la creacin de
base de datos.
Tabla en SQL SERVER
Columna Name Data Type
Lenght
Esta parte se debe Aqu se coloca el Tamao
colocar todos los tipo de dato que campo.
nombres de los lleva el campo
campos que tendr anteriormente
la tabla.
ubicado.

Allow Nulls
del Si se activa esta
opcin significara
que esta opcin
permitir
valores
nulos.

43

Propiedades de los campos de las tablas

Descripcin.- Esta propiedad es exclusiva para el diseador o bien para el
administrador.
Default value.- Se usa para especificar un valor predeterminado para la columna.
Precisin.- Se utiliza para campos numricos, por aqu se indica la cantidad de
dgitos que llevara un nmero.
Scale.- Indica el nmero de dgitos decimales.
Identify.- Si esta opcin se marca con un si estaremos indicando que el campo
tendr un nmero generado automticamente.
Identify Seed.- Indica el valor inicial para el primer registr.
Identify Increment.- Indica el valor del incremento.
Is Row Guid.- Esta propiedad creara un contenido global y nico. Cualquier tabla
puede tener este tipo de columna en el momento que se crea necesario por el
diseador.
Frmula.- Es una propiedad exclusiva y diseadas para aquellos campos que
necesitan alguna funcin.
Collation.- En este campo se debe de especificar a qu base de datos pertenece
la tabla que estamos generando se hace por default esta tabla pertenecer a la
base de datos desde donde fue fragmentada.

44

TRMINOS DE REPASO
Base de datos distribuidos
Nivel de comparticin
Botton up
Top-Dow
Fragmentacin
Monitorizacin y ajuste
Diccionario de datos
Niveles de transparencia
Independencia fsica
Independencia lgica
Transparencia de localizacin
Transparencia de fragmentacin
Transparencia de replica
Aumento de paralelismo
Fragmentacin vertical
Fragmentacin horizontal
Fragmentacin mixta o hibrida
Grado de fragmentacin
Completitud
Reconstruccin
Disyuncin
Algoritmos de colocacin de los datos
Algoritmos de distribucin de datos no replicados
Default value
Scale
Identify
Identify Seed
Is Row Guid

45

AUTO EVALUACION
1.- En el diseo de bases de datos distribuidas se debe considerar el problema de
cmo distribuir la informacin entre diferentes sitios, cuales son:
2.- Qu diferencia hay entre la estrategia ascendente (botton up) y la estrategia
descendente (top-Dow)
3.- Mencione los pasos para realizar la estrategia descendente (top-Dow):
4.- Cuales son las caractersticas que un diccionario de datos debe cumplir
5.- La independencia de datos se puede dar en dos aspectos, mencinelos:
6.- Cual es la diferencia entre la transparencia de localizacin y la transparencia
de fragmentacin.
7.- Menciona 2 ventajas de la transparencia de replica
8.-En que consiste la fragmentacin de datos
9.- La fragmentacin de la informacin se puede llevar a cabo de tres formas,
cuales son:
10.-Define la fragmentacin vertical y ejemplifique
11.- La fragmentacin mixta puede llevarse a cabo de tres formas diferentes,
cuales son y descrbalos
12.- Ejemplifique la fragmentacin mixta HV
13.-Mencione las estrategias que utiliza la distribucin de datos:
14.-En que consisten los algoritmos de distribucin de datos no replicados
15.-Que diferencia existe entre los algoritmos de distribucin de datos no
replicados y los algoritmos de distribucin de datos replicados.

46

3UNIDAD: PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

3.1 Metodologa del procesamiento de consultas distribuidas
Las consultas distribuidas obtienen acceso a datos de varios orgenes de datos
heterogneos. Estos orgenes de datos pueden estar almacenados en el mismo
equipo o en equipos diferentes. Microsoft SQL Serveradmite consultas distribuidas
utilizando OLE DB.
Los usuarios de SQL Server pueden utilizar consultas distribuidas para obtener
acceso a lo siguiente:
Datos distribuidos almacenados en varias instancias de SQL Server.
Datos heterogneos almacenados en varios orgenes de datos relacionales
y no relacionales a los que se obtiene acceso mediante un proveedor OLE
(Object Linking and Embedding (Incrustacin y Vinculacin de Objetos) DB.

47

Operaciones Aritmticas en Consultas

Dentro de un SELECT podemos mostrar resultados que provienen de uno o

varios campos de la base de datos utilizando operaciones matemticas.

Las operaciones bsicas son suma (+), resta (-), divisin (/) y multiplicacin
(*).

A continuacin vamos a mostrar algunos ejemplos:

Operaciones Aritmticas Mult.

Mostrar el nombre y el salario anual de los empleados. (asuma que el

atributo salario slo tiene el pago mensual)

SELECT emp_nombre, emp_salario * 12

FROM empleado;
48

Operaciones Aritmticas - SumaOperaciones Aritmticas Suma

A cunto subira el salario de cada empleado si le incluimos 300 dlares

de aumento? Mostrar el nombre y el salario incluyndole el aumento de
300 dlares.

SELECT emp_nombre, emp_salario + 300

FROM empleado;

Operaciones Aritmticas Varios

Mostrar el nombre y lo que gana el empleado en comisin para aquellos

que son vendedores.

SELECT emp_nombre, emp_commision * emp_salario / 100

FROM empleado

WHERE emp_titulo = Vendedores;

Operaciones Alfanumricas en Consultas

En estas operaciones se juega con el manejo de caracteres y string.

Permiten una mejor presentacin de los datos en pantalla y/o reportes.

Ayuda en la bsqueda de instancias en la tabla.

A continuacin mostramos algunos ejemplos

Operaciones Alfanumricas en Consultas Ejemplo 1

Mostrar el nombre y apellido (que no queden separados por espacios en

blanco)

SELECT emp_nombre || emp_apellidos

FROM empleado;
Operaciones Aritmticas con Fechas en Consultas

SQL permite ejecutar queries que incluyan operaciones aritmticas con

fechas.

Es til para manejar das, diferencias entre fechas y calcular estimados de

tiempo.

49

A continuacin mostramos algunos ejemplos:

Operaciones Aritmticas con Fechas en Consultas Ejemplo 1

Mostrar el nombre del empleado, la fecha que comenz y la fecha en que le

corresponde evaluarlo en la empresa ( La evaluacin se hace despus de
los primeros 6 meses de comenzar a trabajar)

SELECT
emp_nombre,
ADD_MONTHS(emp_fecha_inicio,6) AS Fecha

Evaluacin

FROM empleado;

emp_fecha_inicio,

La funcin principal de un procesador de consultas relacionales es transformar

una consulta en una especificacin de alto nivel, tpicamente en clculo relacional,
a una consulta equivalente en una especificacin de bajo nivel, tpicamente alguna
variacin del lgebra relacional. La consulta de bajo nivel implementa de hecho la
estrategia de ejecucin para la consulta. La transformacin debe ser correcta y
eficiente. Es correcta si la consulta de bajo nivel tiene la misma semntica que la
consulta original, esto es, si ambas consultas producen el mismo resultado.

50

Ejemplo:
E( ENO, ENOMBRE, TITULO )
G( ENO, JNO, RESPONSABLE, JORNADA )
y la siguiente consulta de usuario:
"Encuentre todos los nombres de empleados que manejan un proyecto"
La expresin de la consulta en SQL se puede ver como
SELECT ENOMBRE
FROM E, G
WHERE E.ENO = G.ENO AND RESPONSABLE = "ADMINISTRADOR"
Dos consultas equivalentes en el lgebra relacional que son transformaciones
correctas de la consulta en SQL son:

Como es intuitivamente obvio, la segunda estrategia que evita calcular el producto

cartesiano entre E y
G, consume mucho menos recursos que la primera y, por lo tanto, es mejor.

51

En el procesamiento distribuido de consultas se estudia el coste de las

comunicaciones.
Las consultas distribuidas se realizarn, ante todo, con la operacin de semijoin
para poder optimizar dichas consultas.
En un sistema distribuido hay varios factores adicionales que complican el proceso
de consulta en comparacin con los sistemas centralizados. El primero de estos
factores es el coste de transferencia de datos a travs de la red. Los datos son
enviados a ficheros intermedios que a su vez se envan a otros nodos para nuevos
procesos. Los ficheros resultantes deben enviarse de vuelta al nodo que lanz la
consulta. Los algoritmos de consulta deben, por tanto, tener como objetivo la
reduccin de la cantidad de datos transferidos.
Algunos de los problemas ms comunes que se presentan en los sistemas de
bases de datos distribuidas. En los entornos distribuidos de datos podemos
encontrar lo siguientes:
- Fallo de los nodos. Cuando un nodo falla, el sistema deber continuar trabajando
con los nodos que an funcionan. Si el nodo a recuperar es una base de datos
local, se debern separar los datos entre los nodos restantes antes de volver a
unir de nuevo el sistema.
- Copias mltiples de fragmentos de datos. El subsistema encargado del control de
concurrencia es el responsable de mantener la consistencia en todas las copias
que se realicen y el subsistema que realiza la recuperacin es el responsable de
hacer copias consistentes de los datos de los nodos que han fallado y que
despus se recuperarn.
- Transaccin distribuida correcta. Se pueden producir fallos durante la ejecucin
de una transaccin correcta si se plantea el caso de que al acceder a alguno de
los nodos que intervienen en la transaccin, dicho nodo falla.
- Fallo de las conexiones de comunicaciones. El sistema debe ser capaz de tratar
los posibles fallos que se produzcan en las comunicaciones entre nodos. El caso
ms extremo es el que se produce cuando se divide la red. Esto puede producir la
separacin de dos o ms particiones donde las particiones de cada nodo pueden
comunicarse entre s pero no con particiones de otros nodos.

52

3.2 ESTRATEGIAS DE PROCESAMIENTO DE CONSULTAS

DISTRIBUIDAS

En el procesamiento distribuido de consultas se estudia el coste de las

comunicaciones.
Objetivo: la reduccin de la cantidad de datos transferidos.
Optimizacin mediante operacin de semijoin.
En un sistema distribuido existen factores que complican el proceso de
consulta en comparacin con los sistemas centralizados.
Costo de transferencia de datos a travs de la red.
Ejemplos de consulta distribuida:

53

Tamao de la relacin EMPLEADO es 100 * 10.000 = 106 bytes

Tamao de la relacin DEPARTAMENTO es 35 * 100 = 3500 bytes.
Consideremos la consulta:
Por cada empleado, obtener el nombre del empleado y el nombre del
departamento al que pertenece.
La expresin de sta consulta en lgebra relacional ser:
El resultado de sta consulta constar de 10.000 tuplas. Cada tupla resultante
ser de una longitud de 40 bytes. El tamao del resultado ser por tanto de
400.000 bytes.

Q : elNombre
EMPLEADO
* DEPARTAMEN
TO ya que
Supongamos que
resultado
viaja al nodo
3, denominado
nodo respuesta
, Apellido, NombreDpto
ser el lugar donde se requiera el resultado de dicha consulta. Sin embargo, ni la
relacin EMPLEADO ni DEPARTAMENTO residen en dicho nodo.
Ejemplo de consulta distribuida:

Q : Nombre, Apellido, NombreDpto EMPLEADO * DEPARTAMENTO

Contador:
Nodo 2 departamento

40 * 10000

NombreDeppto

10

400000

Nodo empleado1

Resultado de la
consulta

Nombre 15
Apellido 15

54

Estrategias:
1. Transferir la relacin EMPLEADO y
DEPARTAMENTO al nodo
respuesta (nodo 3) y realizar all la operacin de join. En ste caso se
transfieren 1.000.000 + 3.500 = 1.003.500 bytes.

Contador:
1000000 + 3500
Nodo 240Departamento
* 10000
3500
1003500

Nodo 3 Resultado

1000000

2.
Transferir la relacin EMPLEADO al nodo 2, ejecutar el join en este
nodo y enviar el resultado al nodo 3. Esto implicara transferir 1.000.000
bytes de EMPLEADO + 400.000 bytes del resultado, es decir: 1.400.000
bytes.
Contador:
1000000 +
400000

Nodo 2 departamento

1400000

Nodo 3 Resultado

Nodo 1 empleado
1000000

55

3. Transferir la relacin DEPARTAMENTO al nodo 1, ejecutar el join en este nodo

y enviar el resultado al nodo 3. En este caso, los bytes transferidos sern: 3.500
de la relacin DEPARTAMENTO ms 400.000 del resultado. Es decir 403.500
bytes.
Contador:
3500 + 4000000
Nodo 2 departamento
3500

Nodo 3 Resultado

403500
Nodo 1 empleado
403500

Realizar las operaciones de seleccin lo antes posible

Combinar el producto cartesiano con una operacin de seleccin
subsiguiente cuyo predicado represente una condicin de combinacin,
para formar una operacin de combinacin
Utilizar la asociatividad de las operaciones binarias para reordenar los
nodos hoja de modo que los nodos hoja con las operaciones de seleccin
ms restrictivas se ejecuten primero
Realizar las operaciones de proyeccin lo antes posible
Calcular una nica vez las expresiones posibles.

3.2.1 RBOLES DE CONSULTAS.

rbol: En ciencias de la informtica, un rbol es una estructura de datos
ampliamente usada que imita la forma de un rbol (un conjunto de nodos
conectados). Un nodo es la unidad sobre la que se construye el rbol y puede
tener cero o ms nodos hijos conectados a l.
Se dice que un nodo a es padre de un nodo b si existe un enlace desde a hasta b
(en ese caso, tambin decimos que b es hijo de a). Slo puede haber un nico
nodo sin padres, que llamaremos raz. Un nodo que no tiene hijos se conoce como
hoja. Los dems nodos (tienen padre y uno o varios hijos) se les conoce como
rama.

56

Consulta: mtodo para acceder a los datos en la base de datos. Con las
consultas se puede modificar, mostrar agregar datos de una BD.
RBOL DE LA CONSULTA
SQL Es una representacin interna de una sentencia SQL donde las partes
individuales que la construy se almacenan por separado. Estos rboles de
consulta son visibles cuando se inicia el Postgre SQL y escribir consultas en la
interfaz de usuario interactivo.
Definicin de rbol de consulta
Un rbol de consulta es una estructura de rbol que corresponde a una expresin
del lgebra relacional, donde las relaciones iniciales son representadas a travs
de los nodos hojas del rbol y las operaciones son representadas en los nodos
internos.
Una ejecucin de un rbol de consulta consiste en la ejecucin de una operacin
de un nodo interno siempre que sus operadores estn disponibles y luego
sustituyendo este nodo por la relacin que resulte de ejecutar la operacin.
La ejecucin termina cuando el nodo raz es ejecutado y produce la relacin
resultante.
El bloque de consulta tiene la siguiente forma:
SELECT < lista de atributos >
FROM < lista de tablas>
WHERE < condicin >
La lista de atributos, es la lista de nombres de atributos cuyos valores sern
recuperados en la consulta.
La lista de tablas, es la lista de nombres de las tablas o relaciones necesarias para
procesar la consulta.
La condicin, es la expresin condicional (booleana) que identifica las tuplas que
sern recuperadas por la consulta.
Ejemplo de rbol de consulta
Listar los nombres de los empleados nacidos antes de 1960 que trabajen en un
proyecto llamado Gminis

57

SELECT enombre
FROM Empleado, Trabaja-en, Proyecto
WHERE pnombre = Gminis AND pnumero = pnum AND Empleado.c.i.=Trabajaen.c.i. AND fnac < 01/01/1960

58

Las partes de un rbol de consulta

SQL Al leer las representaciones de SQL de los rboles de consulta en este
documento es necesario para poder identificar las partes se divide el estado en
cuando se encuentra en la estructura del rbol de la consulta. Las partes de un
rbol de la consulta son:

El tipo de comando .- Este es un valor simple decir que comando

(SELECT, INSERT, UPDATE, DELETE) produjo el rbol de anlisis.

La tabla de rango
La tabla es una lista amplia de las relaciones que se utilizan en la consulta. En
una instruccin SELECT se trata de las relaciones dadas despus de la palabra
clave FROM.
Cada entrada de la tabla gama identifica una tabla o vista y le dice por qu
nombre se le llama en otras partes de la consulta. SQL En el rbol de consulta de
las entradas de tabla de la gama se hace referencia por el ndice en lugar de por
su nombre, as que aqu no importa si hay nombres duplicados ya que en una
sentencia SQL.

La relacin resultado
Este es un ndice en la tabla de rango que identifica la relacin donde van los
resultados de la consulta. Las consultas SELECT normalmente no tienen una
relacin de resultados.
En las consultas INSERT, UPDATE y DELETE la relacin resultado es la tabla
donde los cambios surtan efecto.

La lista de objetivos
La lista de objetivos es una lista de expresiones que definen el resultado de la
consulta. En el caso de una SELECT, las expresiones son las que se basa el
resultado final de la consulta.
DELETE no necesitan una lista de objetivos, ya que no producen ningn
resultado. CTID
En INSERT la lista objetivo describe las nuevas filas que deben entrar en la
relacin resultado.
En las consultas UPDATE, la lista de objetivos describe las nuevas filas que
deben sustituir a los antiguos
La calificacin
La consulta de calificacin es una expresin muy similar a uno de los que figuran
en la lista de entradas de destino. El valor del resultado de esta expresin es un
valor booleano que indica si la operacin (INSERT, UPDATE, DELETE o SELECT)

59

para la fila de resultado final debe ser ejecutado o no. SQL Es la clusula WHERE
de una instruccin SQL.
3.2.2 TRANSFORMACIONES EQUIVALENTES
Cuando una base de datos se encuentra en mltiples servidores y distribuye a un
nmero determinado de nodos tenemos:

El servidor recibe una peticin de un nodo.

El servidor es atacado por el acceso concurrente a la base de datos
cargada localmente.
El servidor muestra un resultado y le da un hilo a cada una de las
maquinas nodo de la red local.

Cuando una base de datos es acezada de esta manera la tcnica que se utiliza es
la de fragmentacin de datos que puede ser hibrida, horizontal y vertical.
En esta fragmentacin lo que no se quiere es perder la consistencia de los datos,
por lo tanto se respetan las formas normales de la base de datos.
Bueno para realizar una transformacin en la consulta primero desfragmentamos
siguiendo los estndares marcados por las reglas formales y posteriormente
realizamos el envi y la maquina que recibe es la que muestra el resultado
pertinente para el usuario, de esta se puede producir una copia que ser la
equivalente a la original.
3.2.3 MTODOS DE JOIN
La sentencia JOIN en SQL permite combinar registros de dos o ms tablas en una
base de datos relacional. En el Lenguaje de Consultas Estructurado (SQL), hay
tres tipos de JOIN: interno, externo, y cruzado.
Matemticamente, JOIN es composicin relacional, la operacin fundamental en el
lgebra relacional, y generalizando es una funcin de composicin.

60

Tablas de ejemplo
Todas las explicaciones que estn a continuacin utilizan las siguientes dos tablas
para ilustrar el efecto de diferentes clases de uniones JOIN.

Tabla Empleado

Apellido

IDDepartamento

Andrade

31

Jordn

33

Steinberg

33

Rbinson

34

Solano

34
36

NombreDepartamento IDDepartamento
Ventas

31

Ingeniera

33

Produccin

34

Mercadeo

35

La tabla Empleado contiene a los empleados con el nmero del departamento al

que pertenecen; mientras que la tabla Departamento, contiene el nombre de los
departamentos de la empresa, se puede notar que existe un empleado que tiene
asignado un nmero de departamento que no se encuentra en la tabla
Departamento (Gaspar), igualmente, en la tabla Departamento existe un
departamento al cual no pertenece empleado alguno (Mercadeo). Esto servir
para presentar algunos ejemplos ms adelante.

61

Combinacin interna (INNER JOIN)

Con esta operacin se calcula el producto cruzado de todos los registros; as cada
registro en la tabla A es combinado con cada registro de la tabla B; pero slo
permanecen aquellos registros en la tabla combinada que satisfacen las
condiciones que se especifiquen. Este es el tipo de JOIN ms utilizado por lo que
es considerado el tipo de combinacin predeterminado.
Sql especifica dos formas diferentes para expresar estas combinaciones. La
primera, conocida como explcita usa la palabra JOIN, mientras que la segunda es
implcita y usa ',' para separar las tablas a combinar en la sentencia FROM de la
declaracin SELECT. Entonces siempre se genera el producto cruzado del cual se
seleccionan las combinaciones que cumplan lo que indica la sentencia WHERE.
Es necesario tener especial cuidado cuando se combinan columnas con valores
nulos NULL ya que el valor nulo no se combina con otro valor o con otro nulo,
excepto cuando se le agregan predicados tales como IS NULL o IS NOT NULL.
Como ejemplo, la siguiente consulta toma todos los registros de la tabla Empleado
y encuentra todas las combinaciones en la tabla Departamento. La sentencia JOIN
compara los valores en la columna IDDepartamento en ambas tablas. Cuando no
existe esta correspondencia entre algunas combinaciones, stas no se muestran;
es decir que si el nmero de departamento de un empleado no coincide con los
nmeros de departamento de la tabla Departamento, no se mostrar el empleado
con su respectivo departamento en la tabla resultante.
Las dos consultas siguientes son similares, y se realizan de manera explcita (A) e
implcita (B).
A. Ejemplo de la sentencia INNER JOIN explcita:
SELECT *
FROM empleado
INNER JOIN departamento
ON empleado.IDdepartamento = departamento.IDdepartamento
B. Ejemplo de la sentencia INNER JOIN implcita:
SELECT *
FROM empleado, departamento
WHERE empleado.IDdepartamento = departamento.IDDepartamento

62

Resultados:

Empleado.A Empleado.Iddep departamento.Nombre departamento.IDDe

pellido
artamento
Departamento
partamento
Solano
34
Produccin
34
Jordn

33

Ingeniera

33

Rbinson

34

Produccin

34

Steinberg

33

Ingeniera

33

Andrade

31

Ventas

31

El empleado Gaspar y el departamento de Mercadeo no son presentados en los

resultados ya que ninguno de stos tiene registros correspondientes en la otra
tabla. No existe un departamento con nmero 36 ni existe un empleado con
nmero de departamento 35.
Combinacin externa (OUTER JOIN)
Mediante esta operacin no se requiere que cada registro en las tablas a tratar
tenga un registro equivalente en la otra tabla. El registro es mantenido en la tabla
combinada si no existe otro registro que le corresponda.
En sql no existe una notacin implcita para las combinaciones externas.
Este tipo de operacin se subdivide dependiendo de la tabla a la cual se le
admitirn los registros que no tienen correspondencia, ya sean de tabla izquierda,
de tabla derecha, o combinacin completa.
De tabla izquierda (LEFT OUTER JOIN o LEFT JOIN)
El resultado de esta operacin siempre contiene todos los registros de la tabla de
la izquierda (la primera tabla que se menciona en la consulta), aun cuando no
exista un registro correspondiente en la tabla de la derecha, para uno de la
izquierda.
La sentencia LEFT OUTER JOIN retorna la pareja de todos los valores de la tabla
izquierda con los valores de la tabla de la derecha correspondientes, o retorna un
valor nulo NULL en caso de no correspondencia.
A diferencia del resultado presentado en los ejemplos A y B (de combinacin
interna) donde no se mostraba el empleado cuyo departamento no exista; en el
63

siguiente ejemplo se presentarn los empleados con su respectivo departamento,

e inclusive se presentar el empleado, cuyo departamento no existe.
Ejemplo de tabla izquierda para la combinacin externa:
SELECT distinct *
FROM empleado
LEFT OUTER JOIN departamento
ON empleado.IDDepartamento = departamento.IDDepartamento
Empleado.
Apellido

Empleado.IDDep Departamento.Nombre Departamento.IDDe

artamento
Departamento
partamento

Jordn

33

Ingeniera

33

Andrade

31

Ventas

31

Rbinson

34

Produccin

34

Solano

34

Produccin

34

Gaspar

36

NULL

NULL

Steinberg

33

Ingeniera

33

De tabladerecha (RIGHT OUTER JOIN o RIGHT JOIN)

Esta operacin es inversa a la anterior; el resultado de esta operacin siempre
contiene todos los registros de la tabla de la derecha (la segunda tabla que se
menciona en la consulta), aun cuando no exista un registro correspondiente en la
tabla de la izquierda, para uno de la derecha.
La sentencia RIGHT OUTER JOIN retorna la pareja de todos los valores de la
tabla derecha con los valores de la tabla de la izquierda correspondientes, o
retorna un valor nulo NULL en caso de no correspondencia.

64

Ejemplo de tabla derecha para la combinacin externa:

SELECT *
FROM empleado
RIGHT OUTER JOIN departamento
ON empleado.IDDepartamento = departamento.IDDepartamento

Empleado.
Apellido

Empleado.IDDep Departamento.Nombre Departamento.IDDe

artamento
Departamento
partamento

Solano

34

Produccin

34

Jordn

33

Ingeniera

33

Rbinson

34

Produccin

34

Steinberg

33

Ingeniera

33

Andrade

31

Ventas

31

NULL

NULL

Mercadeo

35

En este caso el rea de Mercadeo fue presentada en los resultados, aunque an

no hay empleados registrados en dicha rea.
Combinacincompleta (FULL OUTER JOIN)
Esta operacin presenta los resultados de tabla izquierda y tabla derecha aunque
no tengan correspondencia en la otra tabla. La tabla combinada contendr,
entonces, todos los registros de ambas tablas y presentar valores nulos NULLs
para registros sin pareja.

65

Ejemplo de combinacin externa completa:

SELECT *
FROM empleado
FULL OUTER JOIN departamento
ON empleado.IDDepartamento = departamento.IDDepartamento
Empleado.
Apellido

Empleado.IDDep Departamento.Nombre Departamento.IDDe

artamento
Departamento
partamento

Solano

34

Produccin

34

Jordn

33

Ingeniera

33

Rbinson

34

Produccin

34

Gaspar

36

NULL

NULL

Steinberg

33

Ingeniera

33

Andrade

31

Ventas

31

NULL

NULL

Mercadeo

35

Como se puede notar, en este caso se encuentra el empleado Gaspar con valor
nulo en su rea correspondiente, y se muestra adems el departamento de
Mercadeo con valor nulo en los empleados de esa rea.
Algunos sistemas de bases de datos no soportan esta funcionalidad, pero esta
puede ser emulada a travs de las combinaciones de tabla izquierda, tabla
derecha y de la sentencia de unin.

66

K. El mismo ejemplo puede expresarse as:

SELECT *
FROM empleado
LEFT JOIN departamento
ON empleado.IDDepartamento = departamento.IDDepartamento
UNION
SELECT *
FROM empleado
RIGHT JOIN departamento
ON empleado.IDDepartamento = departamento.IDDepartamento
WHERE empleado.IDDepartamento IS NULL

Cruzada (Cross join)

Presenta el producto cartesiano de todos los registros de las dos tablas.
El cdigo SQL para realizar este producto cartesiano enuncia las tablas que sern
combinadas, pero no incluye algn predicado que filtre el resultado.
Ejemplo de combinacin cruzada explcita:
SELECT *
FROM empleado CROSS JOIN departamento
Ejemplo de combinacin cruzada implcita:
SELECT *
FROM empleado, departamento;

67

Empleado.
Apellido

Empleado.IDDep Departamento.Nombre Departamento.IDDe

artamento
Departamento
partamento

Andrade

31

Ventas

31

Jordn

33

Ventas

31

Steinberg

33

Ventas

31

Solano

34

Ventas

31

Rbinson

34

Ventas

31

Gaspar

36

Ventas

31

Andrade

31

Ingeniera

33

Jordn

33

Ingeniera

33

Steinberg

33

Ingeniera

33

Solano

34

Ingeniera

33

Rbinson

34

Ingeniera

33

Gaspar

36

Ingeniera

33

Andrade

31

Produccin

34

68

Jordn

33

Produccin

34

Steinberg

33

Produccin

34

Solano

34

Produccin

34

Rbinson

34

Produccin

34

Gaspar

36

Produccin

34

Andrade

31

Mercadeo

35

Jordn

33

Mercadeo

35

Steinberg

33

Mercadeo

35

Solano

34

Mercadeo

35

Rbinson

34

Mercadeo

35

Gaspar

36

Mercadeo

35

Esta clase de combinaciones son usadas pocas veces, generalmente se les

agregan condiciones de filtrado con la sentencia WHERE para hallar resultados
especficos.

69

3.3.- OPTIMIZACIN DE CONSULTAS

Cada da se necesita procesar mayor cantidad de datos y obtener de manera ms
rpida y precisa la informacin. Muchos de los problemas de rendimiento se deben
entre otras cosas al hardware, al software, al motor de base de datos y por sobre
todo al diseo, ndices y mala formulacin de consultas SQL.
Existe la posibilidad de encontrar algunas Consultas SQL, que al momento de
ejecutarse, generen problemas en el SBD, tales como: -Elevada carga del CPU Bloquean procesos de trabajo durante largo tiempo. -Leen muchos bloques de
datos a la memoria intermedia (Paginamiento) - Las Consultas SQL que generan
este tipo de problema, se las denomina COSTOSAS o INEFICIENTES.

La optimizacin de consultas es el proceso de la seleccin del plan de evaluacin

de las consultas ms eficiente entre las muchas estrategias generalmente
disponibles para el procesamiento de una consulta dada, especialmente si la
consulta es compleja. No se espera que los usuarios escriban las consultas de
modo que puedan procesarse de manera eficiente. Por el contrario se espera que
el sistema cree un plan de evaluacin de las consultas que minimice el coste de la
evaluacin de las consultas aqu es donde entra la optimizacin de consultas.
El procesamiento de consultas tiene varias etapas a seguir para resolver una
consulta SQL. Las caractersticas del modelo relacional permiten que cada motor
de base de datos elija su propia representacin que, comnmente, resulta ser el
lgebra relacional. Una de las etapas es:

70

>La optimizacin de consultas

Supone la utilizacin de una medida de costo que sea comn a lo largo del
proceso, esta medida debe representar el criterio de minimizacin en la utilizacin
de recursos del sistema. ). Este enfoque estima un costo que estar determinado
por formulas predefinidas y por la informacin del catalogo inherente a la consulta.
Sin embargo el optimizador no siempre escoge el plan ms ptimo, ya que una
bsqueda exhaustiva de la estrategia ptima puede consumir demasiado tiempo
de proceso.
El catlogo de la base de datos guarda informacin estadstica de cada una de las
relaciones como tambin de los ndices de cada una de la relaciones, estas
estadsticas permiten estimar los tamaos de los resultados de varias
operaciones.
Una mala administracin de la informacin que contiene el catlogo conducir
inevitablemente a una desafortunada eleccin del plan de ejecucin.
Consiste en la actualizacin automtica de las estadsticas que algunos motores
de base de datos incluyen como opcin. Otro enfoque es la opcin de guardar en
el catlogo planes de ejecucin precalculados que adems le ahorran al motor el
tiempo de clculo del plan.
Uno de los primeros optimizadores de consultas y el que se conoce como base
para la mayora de los optimizadores tradicionales es el optimizador de System R.
System R es un optimizador basado en costos pero que utiliza heursticas para
desplazar selecciones y proyecciones hacia abajo en el rbol de la consulta. El
primer paso de un optimizador de consultas es encontrar una expresin del
lgebra de relaciones que sea equivalente a la expresin dada y cuyo costo
estimado de ejecucin sea menor.
La optimizacin incide:

La optimizacin El coste de comunicacin de acceso a almacenamiento

secundario.
El coste de almacenamiento.
El coste de computacin.
El optimizador interviene tambin en las actualizaciones y borrados.

71

PASOS PARA GENERAR UNA OPTIMIZACIN:

1. Generar un Plan de Ejecucin
2. Escribir la consulta
3. Crear y gestionar ndices: los ndices se utilizan para agilizar las bsquedas
de informacin.
4. Aplicacin del plan
TIEMPO DE OPTIMIZACIN
Una consulta puede ser optimizada en tiempos diferentes con relacin a tiempo de
ejecucin de la consulta. La optimizacin se puede realizar de manera esttica
antes de ejecutar la consulta o de forma dinmica durante la ejecucin de la
consulta.
Optimizacin esttica se hace en tiempo de compilacin de la consulta.
As, el costo de la optimizacin puede ser amortizada sobre mltiples
ejecuciones de la misma consulta.
Optimizacin de consultas dinmica la eleccin de la mejor operacin
siguiente se puede hacer basado en el conocimiento exacto de los
resultados de las operaciones anteriores. Por tanto, se requiere tener
estadsticas acerca del tamao de los resultados intermedios para aplicar
esta estrategia.
Hbrido: utiliza bsicamente un enfoque esttico, pero se puede aplicar un
enfoque dinmico cuando los tamaos de las relaciones estimados estn
alejados de los tamaos actuales.
LA OPTIMIZACIN DE CONSULTAS se hace de dos maneras:
A nivel del lgebra relacional: es un lenguaje de consulta procedural.
Consta de un conjunto de operaciones que toman como entrada una o dos
relaciones y producen como resultado una nueva relacin; el sistema
intenta hallar una expresin que sea equivalente a la expresin dada, pero
de ejecucin ms eficiente. (utilizando el seleccin, proyeccin, producto
artesiano, unin). Este tipo de OPTIMIZACIN es para las consultas
globales.
Algoritmos de sistemas centralizados: estrategia detallada para el
procesamiento de las consultas para ejecutar la operacin, la seleccin de
los ndices concretos que se van a emplear, etc. Este tipo de
OPTIMIZACIN es para las consultas locales

72

3.3.1 OPTIMIZACIN GLOBAL DE CONSULTAS

Optimizacin se define desde un punto de vista informtico, como la bsqueda y el
hecho de mejorar el rendimiento de un sistema operativo, programa o dispositivo,
a partir de determinados cambios lgicos (software) o fsicos (hardware)
Cuando hablamos de optimizacin de consultas nos referimos a mejorar los
tiempos de respuesta en un sistema de gestin de bases de datos relacional, pues
la optimizacin es el proceso de modificar un sistema para mejorar su eficiencia o
tambin el uso de los recursos disponibles.
Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar
una estrategia de ejecucin para la consulta cercana a la ptima. La estrategia de
ejecucin para una consulta distribuida puede ser descrita con los operadores del
lgebra relacional y con primitivas de comunicacin para transferir datos entre
nodos. Para encontrar una buena transformacin se consideran las caractersticas
de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la
optimizacin de consultas es el ordenamiento de juntas, dado que algunas
permutaciones de juntas dentro de la consulta pueden conducir a un mejoramiento
de varios rdenes de magnitud. La salida de la capa de optimizacin global es una
consulta algebraica optimizada con operacin de comunicacin incluida sobre los
fragmentos.
La optimizacin global se da con respecto a todo el cdigo.
Este tipo de optimizacin es ms lenta pero mejora el desempeo general de
todo programa.
Las optimizaciones globales pueden depender de la arquitectura de la mquina.

73

Descomposicin de consultas
La primera capa descompone una consulta en el clculo relacional en una
consulta en el lgebra relacional que opera sobre relaciones globales. Consiste de
cuatro partes:
1. Normalizacin. Involucra la manipulacin de los cuantificadores de la
consulta y de los calificadores de la misma mediante la aplicacin de la
prioridad de los operadores lgicos.
2. Anlisis. Se detecta y rechazan consultas semnticamente incorrectas.
3. Simplificacin. Elimina predicados redundantes.
4. Reestructuracin. Mediante reglas de transformacin una consulta en el
clculo relacional se transforma a una en el lgebra relacional. Se sabe que
puede existir ms de una transformacin. Por tanto, el enfoque seguido
usualmente es empezar con una consulta algebraica y aplicar
transformaciones para mejorarla.
Localizacin de Datos
La entrada a esta capa es una consulta algebraica definida sobre relaciones
distribuidas. El objetivo de esta capa es localizar los datos de la consulta usando
la informacin sobre la distribucin de datos. Esta capa determina cuales
fragmentos estn involucrados en la consulta y transforma la consulta distribuida
en una consulta sobre fragmentos.
Optimizacin Global de Consultas
Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar
una estrategia de ejecucin para la consulta cercana a la ptima. La estrategia de
ejecucin para una consulta distribuida puede ser descrita con los operadores del
lgebra relacional y con primitivas de comunicacin para transferir datos entre
nodos. Para encontrar una buena transformacin se consideran las caractersticas
de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la
optimizacin de consultas es el ordenamiento de juntas, dado que algunas
permutaciones de juntas dentro de la consulta pueden conducir a un mejoramiento
de varios rdenes de magnitud. La salida de la capa de optimizacin global es una
consulta algebraica optimizada con operacin de comunicacin incluida sobre los
fragmentos.
Optimizacin Local de Consultas
El trabajo de la ltima capa se efecta en todos los nodos con fragmentos
involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada
consulta local, es optimizada usando el esquema local del nodo. Hasta este
momento, se pueden eligen los algoritmos para realizar las operaciones
relacionales. La optimizacin local utiliza los algoritmos de sistemas centralizados.
74

3.3.2 OPTIMIZACIN LOCAL DE CONSULTAS

Que se busca con la optimizacin local de consultas?
El programador al momento de disear sus bases de datos, busca mejorar los
siguientes dos criterios:

Tiempo de ejecucin
Espacio de memoria utilizado

Esto se realiza mediante operaciones, mtodos, que ayudan a reducir los costos
de comunicacin y el consumo de recursos de la CPU.
El manejo de los costos de comunicacin se define por las mtricas utilizadas,
para cada nodo, como las bases de datos distribuidas operan bajo una
arquitectura de red, se definen costos de comunicaciones.
Los diferentes factores pueden tener pesos diferentes dependiendo del ambiente
distribuido en el que se trabaje.
La optimizacin local se basa especficamente en condiciones locales dentro de
un programa fuente, y no se contempla el flujo de ejecucin del programa, para
este tipo de optimizacin lo que se contempla es particionar el cdigo en bloques
bsicos de cdigo (alto nivel) y sobre estos fragmentos se lleva a cabo la
optimizacin.
El trabajo de la ltima capa se efecta en todos los nodos con fragmentos
involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada
consulta local, es optimizada usando el esquema local del nodo. Hasta este
momento, se pueden eligen los algoritmos para realizar las operaciones
relacionales. La optimizacin local sirve cuando un bloque de programa o seccin
es crtico por ejemplo: la E/S, la concurrencia, la rapidez y confiabilidad de un
conjunto de instrucciones.
Caractersticas
La optimizacin local se realiza sobre mdulos del programa.
La optimizacin slo se ve reflejada en dichas secciones.
Como el espacio de soluciones es ms pequeo la optimizacin local es
ms rpida.

75

TRMINOS DE REPASO

Procesamiento distribuido de consultas

Estrategias para el procesamiento de las consultas
Arboles
Tiempos de ejecucin
Mtodo de join
Costos de comunicacin
Algoritmos de sistemas centralizados
Algoritmos de optimizacin
Hibrido
Tiempo de optimizacin
Optimizacin local y global.

76

AUTO EVALUACION

1.- Menciones los problemas ms comunes que se presentan en los sistemas de

bases de datos distribuidas?
2.- Qu es una consulta?
3.- Mencione las partes de un rbol de la consulta
4.- En qu consiste la combinacin interna (INNER JOIN)?
5.- Explique el mtodo de combinacin externa (OUTER JOIN)?
6.- En qu consiste la combinacin completa?
7.- Qu es la optimizacin?
8.- Qu es la optimizacin de consultas?
9.- Cules son los pasos para generar una optimizacin?
10.- Mencione los criterios a mejorar al momento de disear una base de datos.
11.- Escriba las caractersticas de la optimizacin global de consultas.
12.- Escriba las caractersticas de la optimizacin local de consultas.
13.- Explique las maneras para hacer la optimizacin de consultas.
14.- Explica las maneras en las que se puede realizar la optimizacin.
15.-Cul es la funcin principal de un procesador de consultas relacional
16.-Cuando es correcta y eficiente la transformacin
17.-Representa el procesador de consultas
18.-Las consultas distribuidas se realizarn con la operacin
19.-Menciona las estrategias de procesamiento de consultas distribuidas

77

UNIDAD 4.- MANEJO DE TRANSACCIONES

4.1 TRANSACCIONES
Concepto: Es una unidad de ejecucin en un programa que accede y
posiblemente actualiza varios elementos de datos.
Una transaccin es una coleccin de acciones que hacen transformaciones
consistentes de los estados de un sistema preservando la consistencia del
sistema. Se dice que una base de datos est en un estado consistente si obedece
todas las restricciones de integridad definidas sobre ella. Los cambios de estado
ocurren debido a actualizaciones, inserciones, y supresiones de informacin.
Una transaccin en un Sistema de Gestin de Bases de Datos (SGBD), es un
conjunto de rdenes que se ejecutan formando una unidad de trabajo, es decir, en
forma indivisible o atmica.
Es un conjunto de acciones llevadas a cabo por un usuario o un programa de
aplicacin, que acceden o cambian el contenido de la base de datos.
Una transaccin consiste en una serie de operaciones performed on a database.
Realizado en una base de datos. The important issue in La cuestin importante en
transaction management is that if a database was in a la gestin de transacciones
es que si una base de datos estaba en un consistent state prior to the initiation of
a transaction, estado coherente antes de la iniciacin de una transaccin, then the
database should return to a consistent state a continuacin, la base de datos debe
volver a un estado coherente after the transaction is completed. Despus de la
transaccin se ha completado. This should be done Esto se debe hacer
irrespective of the fact that transactions were independientemente del hecho de
que las transacciones se successfully executed simultaneously or there were
ejecutado con xito al mismo tiempo o hay failures during the execution, (Ozsu et
al., 1991). fallos durante la ejecucin.
Thus, a transaction is a unit of consistency and Por lo tanto, una transaccin es
una unidad de la coherencia y la reliability. fiabilidad.
Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro de
los sistemas de base de datos, donde se usaba para ayudar en el mantenimiento
de los datos de las aplicaciones y que dependan de la consistencia de la
informacin almacenada.
Las transacciones son mecanismos que ayudan a simplificar la construccin de
sistemas confiables mediante procesos que proporcionan soporte uniforme para
invocar y sincronizar operaciones como:
Operaciones de comparacin de datos
Aseguramiento de la seriabilidad de las transacciones con otras
Atomicidad en su comportamiento

78

 Recuperacin de fallas
La palabra transaccin describe una secuencia de operaciones con uno o ms
recursos que transforman su estado actual en un nuevo estado de consistencia.
Es un conjunto de operaciones sobre datos que son tratadas como una unidad.
Una transaccin puede terminar, haciendo sus cambios persistentes, o abortar
voluntaria o involuntariamente
Una transaccin es una coleccin de operaciones que hacen transformaciones
consistentes de los estados de un sistema conservando la consistencia del
sistema. Una base de datos est en estado consistente si cumple todas las
restricciones de integridad definidas sobre ella. Los cambios de estado se dan
debido a actualizacin, insercin y eliminacin de la informacin. Se quiere
asegurar que la base de datos no entre en un estado de inconsistencia, pero
durante la ejecucin de una transaccin, la base de datos puede estar
temporalmente en un estado inconsistente. Lo importante aqu es asegurar que la
base de datos vuelva a un estado consistente al concluir la ejecucin de una
transaccin (Figura A)

Figura A . Un modelo de transaccin.

Lo que se persigue con el uso de transacciones es por un lado contar con una
transparencia adecuada de las acciones concurrentes a una base de datos y por
el otro tener una transparencia adecuada en el manejo de las fallas que se pueden
presentar en una base de datos.

79

Instrucciones para el uso de transacciones

La programacin con uso de transacciones requiere de instrucciones especiales,
las cuales deben ser proporcionadas por el sistema operativo, por el compilador
del lenguaje o por el manejador de la base de datos, algunos son:
BEGIN _TRANSACCIN: Los comandos siguientes forman una transaccin
END _ TRANSACCIN: Termina la transaccin y se intenta un compromiso
ABORT_ TRANSACCIN: Se elimina la transaccin, se recuperan los valores
anteriores
READ: Se leen datos de un archivo
WRITE: Se escriben datos en un archivo
Las operaciones entre BEGIN y END integran el cuerpo de la transaccin y deben
ejecutarse todas o ninguna de ellas. La cantidad exacta de instrucciones
disponibles para manejar transacciones depende del tipo de objetos y operaciones
que deban ser procesadas.
Ejemplo 1: Considere la siguiente consulta en SQL para incrementar el 10% del
presupuesto del proyecto CAD/CAM de la base de datos de ejemplo.

UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"
Esta consulta puede ser especificada, usando la notacin de SQL, como una
transaccin otorgndole un nombre:
Begin_transaction ACTUALIZA_PRESUPUESTO
begin
UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"
end.

80

Ejemplo 2: Considere una agencia de reservaciones para lneas areas con las
siguientes relaciones:
FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP )
CUST( CNAME, ADDR, BAL )
FC( FNO, DATE, CNAME, SPECIAL )
Una versin simplificada de una reservacin tpica puede ser implementada
mediante la siguiente transaccin:
Begin_transaction Reservacin
begin
input( flight_no, date, customer_name );
EXEC SQL UPDATE FLIGHT
SET STSOLD = STSOLD + 1
WHERE FNO = flight_no
AND DATE = date
EXEC SQL INSERT
INTO FC( FNAME, DATE, CNAME,
SPECIAL )
VALUES (flight_no, date, customer_name,
null )
output("reservacin terminada");
end.
Las transacciones cuentan con las siguientes propiedades:
Atomicidad:
Una transaccin es tratada como una unidad de operacin. Por lo tanto todas las
acciones de la transaccin se llevan a cabo o ninguna de ellas se realiza .La
atomicidad requiere que si una transaccin se interrumpe por una falla, sus
resultados parciales deben ser deshechos. Se efectan todas las transacciones,
pero en caso de fallas no se realiza ninguna. Una transaccin debe concluir
81

comprometida o abortada. En el caso del compromiso se instalan todas las

actualizaciones y en el aborto se descartan todas las actualizaciones.
Consistencia :
Una transaccin es un programa correcto que lleva la base de datos de un estado
consistente a otro con la misma caracterstica. Gracias a esto, las transacciones
no violan las reglas de integridad de una base de datos.
Aislamiento :
Durante la ejecucin de una transaccin, esta no debe revelar sus resultados a
otras transacciones concurrentes antes de su compromiso. Si varias transacciones
se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se
hubieran ejecutado en forma secuencial (Seriabilidad). La seriabilidad consiste en
asegurarse que los cambios siguen un orden adecuado.
Durabilidad :
Es la propiedad de las transacciones que asegura que una vez que una
transaccin realiza su compromiso, sus resultados son permanentes y no pueden
ser borrados de la base de datos, se asegura que los resultados de una
transaccin sobrevivirn a fallas del sistema.
Las transacciones brindan una ejecucin atmica y confiable en presencia de
fallas, una ejecucin correcta en presencia de accesos de usuario mltiples y un
manejo correcto de replicas (en el caso que se soporten).
4.1.1 ESTRUCTURA DE TRANSACCIONES
La estructura de una transaccin usualmente viene dada segn el modelo de la
transaccin, estas pueden ser planas (simples) o anidadas.
Transacciones planas.- Consisten de una secuencia de operaciones primitivas
encerradas entre las palabras clave begin y end.
Por ejemplo:
Begin_transaction Reservacin

End
Transacciones anidadas.- Consiste en tener transacciones que pueden ser de
otras transacciones, estn incluidas dentro de otras de un nivel superior que se les
conoce como subtransacciones.
Por ejemplo:
Begin_transaction Reservacin
Begin_transaction Vuelo

82

End. (Vuelo)
Begin_transaction Hotel

End

End.
Una transaccin anidada da otra transaccin conserva las mismas propiedades
que la de sus padres, esto implica, que puede contener as mismo transacciones
dentro de ella.
Existen restricciones obvias en una transaccin anidada: debe empezar despus
que su padre y debe terminar antes que l. Ms an, el commit de una
subtransaccin es condicional al commit de su padre, en otras palabras, si el
padre de una o varias transacciones aborta, las subtransacciones hijas tambin
sern abortadas.
Las transacciones anidadas brindan un nivel ms alto de concurrencia entre
transacciones. Ya que una transaccin consiste de varias transacciones es posible
tener
mayor
concurrencia
dentro
de
una
sola
transaccin.
As tambin, es posible recuperarse de de fallas de forma independiente de cada
subtransaccion. Esto limita el dao a una parte ms pequea de la transaccin,
haciendo
que
el
costo
de
la
recuperacin
sea
el
menor.
Tambin se deben considerar el orden de las lecturas y escrituras. Si las acciones
de lectura y escritura pueden ser mezcladas sin ninguna restriccin, entonces, a
este tipo de transacciones se les conoce como Generales .Por el contrario, si se
restringe o impone que un dato debe ser ledo antes de que pueda ser escrito
entonces se tendrn transacciones Restringidas. Si las transacciones son
restringidas a que todas las acciones de lectura se realicen antes de las acciones
de escritura entonces se les conoce como de Dos Pasos. Finalmente existe un
modelo de accin para transacciones restringidas en donde se aplica aun ms la
restriccin de que cada par < read , write > tiene que ser ejecutado de manera
atmica.
4.1.2 EJECUCIN DE TRANSACCIONES CENTRALIZADA Y DISTRIBUIDA
Los siguientes son los aspectos ms importantes relacionados con el
procesamiento de transacciones
Modelo de estructura de transacciones.
Es importante considerar si las transacciones son planas o anidadas.
Consistencia de la base de datos interna.
Los algoritmos de control de datos tienen que satisfacer las restricciones de
integridad cuando una transaccin pretende hacer un compromiso.

83

Protocolos de confiabilidad
En transacciones distribuidas es necesario introducir medios de comunicacin
entre los diferentes nodos de una red para garantizar la atomicidad de las
transacciones.
Algoritmos de control de concurrencia
Deben sincronizar la ejecucin de transacciones concurrentes bajo el criterio de
correctitud. La consistencia entre transacciones se garantiza mediante el
aislamiento de las mismas.
Protocolos de control de replicas
Se refiere a cmo garantizar la consistencia mutua de datos replicados.
El procesamiento de transacciones bsicamente consiste en una serie de
modificaciones (transacciones) a un determinado recurso del sistema (por ejemplo
una base de datos) y en donde se define un punto de inicio y un punto de
terminacin que define un bloque entre el conjunto de operaciones que son
realizadas.
Dentro de este proceso en bloque los dems usuarios no pueden modificar nada
hasta que no se presente un estado estable de los datos, esto ocasiona
inconsistencia temporal y conflictos. Para evitar lo anterior se implementan dos
maneras diferentes:
1.- Ejecutar transacciones serializadas: Es un sistema que permite el

procesamiento de transacciones en forma secuencial o serializado dndole una

secuencia a cada transaccin, este proceso reduce el rendimiento del sistema,
pero tiene como ventaja que el proceso de sincronizacin es ms sencillo.

2- Ejecutar transacciones calendarizadas: Permite el proceso de transacciones

asignndoles tiempos de procesamiento el cual permite incrementar el rendimiento
del sistema ya que se ejecuta un mximo de procesos en forma concurrente y no
a travs de una serie. La ventaja es que a un mismo tiempo de reloj se pueden
hacer dos operaciones, aunque el proceso de sincronizacin es ms complicado.
84

Un aspecto muy importante en el manejo de transacciones es el de mantener y

aplicar algoritmos de control sobre los datos o recursos; para ese control tambin
se utilizan protocolos que proporcionen confiabilidad como lo siguientes:
Atomicidad
Protocolos de recuperacin total
Protocolos de compromiso global
Para llevar el control de concurrencia dentro de un proceso de transacciones se
manejan dos modos:
Ejecucin centralizada de transacciones
Ejecucin distribuida de transacciones
Ejecucion centralizada de transacciones

85

Ejecucin distribuida de transacciones

4.1.3 ESTRUCTURA DE TRANSACCIONES.

Las transacciones planas consisten de una secuencia de operaciones primitivas
encerradas entre las palabras clave begin y end. Por ejemplo,
Begin_transaction Reservacin
...
end.
La estructura de una transaccin usualmente viene dada segn el modelo de la
transaccin, estas pueden ser planas (simples) o anidadas.
Transacciones Anidadas:
Consiste en tener transacciones que dependen de otras, estas
transacciones estn incluidas dentro de otras de un nivel superior y se las conoce
como subtransacciones. La transaccin de nivel superior puede producir hijos
(subtransacciones) que hagan ms fcil la programacin del sistema y mejoras del
desempeo.
En las transacciones anidadas las operaciones de una transaccin pueden ser as
mismo otras transacciones.
Por ejemplo:
BEGIN _TRANSACTION Reservacin
..........
BEGIN _TRANSACTION Vuelo
........
86

END.( Vuelo ) ......

BEGIN _TRANSACTION Hotel
........
END
......
END.
En las transacciones anidadas las operaciones de una transaccin pueden ser as
mismo transacciones. Por ejemplo,
Begin_transaction Reservacin
...
Begin_transaction Vuelo
...
end. {Vuelo}
...
Begin_transaction Hotel
...
end.
Las transacciones anidadas proporcionan un nivel ms alto de concurrencia
entre transacciones. Ya que una transaccin consiste de varios transacciones, es
posible tener ms concurrencia dentro de una sola transaccin. As tambin, es
posible recuperarse de fallas de manera independiente de cada subtransaccin.
Esto limita el dao a un parte ms pequea de la transaccin, haciendo que costo
de la recuperacin sea menor.
Una transaccin anidada dentro de otra transaccin conserva las mismas
propiedades que la de sus padres, esto implica, que puede contener as mismo
transacciones dentro de ella. Existen restricciones obvias en una transaccin
anidada: debe empezar despus que su padre y debe terminar antes que l. Ms
an, el commit de una subtransaccin es condicional al commit de su padre, en
otras palabras, si el padre de una o varias transacciones aborta, las
subtransacciones hijas tambin sern abortadas

87

4.2 CONTROL DE CONCURRENCIA

El control de concurrencia trata con los problemas de aislamiento y consistencia
del procesamiento de transacciones. El control de concurrencia distribuido de una
DDBMS asegura que la consistencia de la base de datos se mantiene en un
ambiente distribuido multiusuario. Si las transacciones son internamente
consistentes, la manera ms simple de lograr este objetivo es ejecutar cada
transaccin sola, una despus de otra.
Un mtodo de control de concurrencia es correcto si es serializable, es decir existe
una secuencia equivalente en que las operaciones de cada transaccin aparecen
antes o despus de otra transaccin pero no entremezcladas. Una ejecucin serial
de transacciones es siempre correcta.
Si no se hace un adecuado control de concurrencia, se pueden presentar
dos anomalas.
En primer lugar, se pueden perder actualizaciones provocando que los
efectos de algunas transacciones no se reflejen en la base de datos.
En segundo trmino, pueden presentarse recuperaciones de informacin
inconsistentes.
El control de concurrencia es una actividad de coordinar accesos concurrentes a la
base de datos. El control de concurrencia permite a los usuarios accesar a la base
de datos. El control de concurrencia permite a los usuarios accesar a la base de
datos en una forma multi programada mientras se preserva la ilusin de que cada
usuario este utilizando solo en un sistema dedicado. El control de concurrencia
asegura que las transacciones multiples sometidos por usuarios diferentes no
interfieren unos con otros de forma que se produzca resultados incorrectos.
La finalidad del control de concurrencia es asegurar la consistencia de los datos al
ejecutar transacciones, y que cada accin atmica sea completada en un tiempo
finito. Uno de los problemas de concurrencia especficos de las bases de datos
distribuidas es la consistencia de copia mltiple, se produce cuando un mismo
dato esta en varias localizaciones. Adems se siguen dando los mismos
problemas para bases de datos centralizadas prdida de actualizaciones,
dependencia neutral uncommitted dependency y anlisis inconsistentes.

88

4.2.1 SERIALIZACIN DE TRANSACCIONES

Seriabilidad.
La seriabilidad consiste en asegurarse que los cambios siguen un orden
adecuado.
Teora de la serializad
Una canderilizacion ischedulel tambin llamado una historia se define un conjunto
de transacciones I= {T1,T2, TN} y especifican orden entrelazada de la ejecucin
de las operaciones de las transacciones. La canderilizacion puede ser
especificada como una orden parcial sobre T.
T1=read (x) T2=write(x) T3=read (x)
Write (x) write (y) read (y)
Commit read(z) read (z)
Comimit commit
Una candelizacion de las acciones de las tres transacciones de las tres
transacciones anteriores puede ser:
H1 = {W2 (x), R1(x), R3(x), W1(x), C1, W2 (y), R3(y), R2(z), C2, R3(z), C3 }
En bases de datos distribuidos es necesario considerar dos tipos de historia para
poder generar calendarizaciones serializables: la canderizacion de la ejecucin de
transacciones globales sern serializables se deben satisfacer las siguientes
condiciones:
Cada historia local debe ser serializable.
Dos operaciones en conflicto deben estar en el mismo orden relativo en
todas las historias locales donde las operaciones aparecen juntas.
Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que accesan el
mismo dato de la base de datos x se dice que estn en conflicto si al menos una
de ellas es una escritura. De esta manera, las operaciones de lectura no tienen
conflictos consigo mismas. Por tanto, existen dos tipos de conflictos readwrite (o write-read) y write-write. Las dos operaciones en conflicto pueden
pertenecer a la misma transaccin o a transacciones diferentes. En el ltimo caso,
se dice que las transacciones tienen conflicto. De manera intuitiva, la existencia de
un conflicto entre dos operaciones indica que su orden de ejecucin es importante.
El orden de dos operaciones de lectura es insignificante.
Una calendarizacin completa define el orden de ejecucin de todas las
operaciones
en
su
dominio.
Formalmente,
una
calendarizacin
c
completa ST definido sobre un conjunto de transacciones T = { T1, T2, ..., Tn } es
un orden parcial STc = { S T, <T } en donde

89

1. S T = U i S i , para todos los i = 1, 2, ..., n

2. <T i <i , para todos los i = 1, 2, ..., n
3. Para cualesquiera dos operaciones en conflicto Oij y Okl S T, Oij <T Okl
Okl <T Oij
La primera condicin establece simplemente que el dominio de la calendarizacin
es la unin de los dominios de las transacciones individuales. La segunda
condicin define la relacin de ordenamiento como un superconjunto de la relacin
de ordenamiento de transacciones individuales. Esto mantiene el ordenamiento de
las operaciones dentro de cada transaccin. La condicin final define el orden de
ejecucin entre dos operaciones en conflicto.
4.2.2 ALGORITMOS DE CONTROL DE CONCURRENCIA
Aquellos algoritmos que estn basados en acceso mutuamente exclusivo a datos
compartidos (candados o bloqueos) y aquellos que intentar ordenar la ejecucin
de las transacciones de acuerdo a un conjunto de reglas (protocolos). Sin
embargo, estas primitivas se pueden usar en algoritmos con dos puntos de vista
diferentes:
El punto de vista pesimista que considera que muchas transacciones tienen
conflictos con otras, o el punto de vista optimista que supone que no se presentan
muchos conflictos entre transacciones.
Los algoritmos pesimistas sincronizan la ejecucin concurrente de las
transacciones en su etapa inicial de su ciclo de ejecucin. Los
algoritmos optimistas retrasan la sincronizacin de las transacciones hasta su
terminacin. El grupo de algoritmos pesimistas consiste de algoritmos basados en
candados, algoritmos basados en ordenamiento por estampas de tiempo y
algoritmos hbridos.
Los algoritmos para el control de concurrencia son tiles cuando se ejecutan
varias transacciones al mismo tiempo

90

Clasificacin de algoritmos de control de concurrencia.

4.2.2.1 BASADOS EN BLOQUEO

En los algoritmos basados en candados, las transacciones indican sus intenciones
solicitando candados al despachador. Los candados son de lectura (rl), tambin
llamados compartidos, o de escritura (wl), tambin llamados exclusivos. Como se
aprecia en la tabla siguiente:
rl

wl

rl

si

no

wl

no

no

Los candados de lectura presentan conflictos con los candados de escritura, dado
que las operaciones de lectura y escritura son incompatibles.

91

Existen diversos enfoques para complementar el gestor de bloqueos, cada uno de

ellos con ventaja y desventaja se describen a continuacin los principales
enfoques.
Gestin nico de bloqueo.- El sistema conserva un nico de bloqueos que reside
en un nico emplazamiento a modo de todas las solicitudes de bloqueo y
desbloqueos se realizan sobre l.
Cada transaccin solicita a esta localidad los bloqueos que necesita y luego, en
caso de lectura.
La misma se realiza sobre cualquier copia, si es una escritura se debe resolver
sobre todas las copias.
Esta solucin tiene por ventaja una implementacin muy sencilla le exige dos
mensajes para tratar las solicitudes de bloqueo y una para tratar la de desbloqueo
y un tratamiento muy sencillo para desbloqueo (dado que todas las solicitudes de
bloque y desbloqueo se realiza en un mismo modo, se puede aplicar los mtodos).

Candados de dos fases (2PL)

En los candados de dos fases una transaccin le pone un candado a un objeto
antes de usarlo. Cuando un objeto es bloqueado con un candado por otra
transaccin, la transaccin solicitante debe esperar. Cuando una transaccin
libera un candado, ya no puede solicitar ms candados.
La importancia de los candados de dos fases es que se ha demostrado de manera
terica que todos las calendarizaciones generadas por algoritmos de control de
concurrencia que obedecen a los candados de dos fases son serializables.

Grfica del uso de los candados de dos fases

92

Comportamiento de los candados de dos fases estrictos.

Candados de dos fases centralizados
En sistemas distribuidos puede que la administracin de los candados se dedique
a un solo nodo del sistema, por lo tanto, se tiene un despachador central el cual
recibe todas las solicitudes de candados del sistema. Se presenta la estructura de
la comunicacin de un administrador centralizado de candados de dos fases. La
comunicacin se presenta entre el administrador de transacciones del nodo en
donde se origina la transaccin (llamado el coordinador TM), el administrador de
candados en el nodo central y los procesadores de datos (DP) de todos los nodos
participantes. Los nodos participantes son todos aquellos en donde la operacin
se va a llevar a cabo.

Comunicacin en un administrador centralizado de candados de dos fases

estrictos.

93

4.2.2.2

BASADOS EN ESTAMPAS DE TIEMPO

Los algoritmos basados en estampas de tiempo no pretenden mantener la

seriabilidad por exclusin mutua. En lugar de eso, ellos seleccionan un orden de
serializacin a prioridad y ejecutan las transacciones, de acuerdo a ellas. Para
establecer este ordenamiento, el administrador de transacciones le asigna a cada
transaccin T1 una estampa de tiempo nica t1 (T1) cuando sta inicia.
Una estampa de tiempo es un identificador simple que sirve para identificar cada
transaccin de manera nica.
Otra propiedad de las estampas de tiempo es la menoticidad, esto es, dos
estampas de tiempo generadas por el mismo administrador de transacciones
deben ser monofnicamente crecientes.

Existen varias formas en que las estampas de tiempo se pueden asignar. Un

mtodo es usar un contador global monotonicamente creciente. Sin embargo, el
mantenimiento de contadores globales es un problema en sistemas distribuidos.
Por lo tanto, es preferible que cada nodo asigne de manera autnoma las
estampas de tiempos basndose en un contador local.
Ordenamiento conservador por estampas de tiempo
El ordenamiento bsico por estampas de tiempo trata de ejecutar una operacin
tan pronto como se recibe una operacin. As, la ejecucin de las operaciones es
progresiva pero pueden presentar muchos reinicios de transacciones. El
ordenamiento conservador de estampas de tiempo retrasa cada operacin hasta
que exista la seguridad de que no ser reiniciada. La forma de asegurar lo anterior
es sabiendo que ninguna otra operacin con una estampa de tiempo menor puede
llegar al despachador. Un problema que se puede presentar al retrasar las
operaciones es que sto puede inducir la creacin de interbloqueos (deadlocks).

94

Ordenamiento por estampas de tiempo mltiples

Para prevenir la formacin de interbloqueos se puede seguir la estrategia
siguiente. Al hacer una operacin de escritura, no se modifican los valores
actuales sino se crean nuevos valores. As, puede haber copias mltiples de un
dato. Para crear copias nicas se siguen las siguientes estrategias de acuerdo al
tipo de operacin de que se trate:
1. Una operacin de lectura Ri(x) se traduce a una operacin de lectura
de x de una sola versin encontrando la versin de x, digamos xv, tal
que, ts(xv) es la estampa de tiempo ms grande que tiene un valor menor
a ts(Ti).
2. Una operacin de escritura Wi(x) se traduce en una sola version, Wi(xw), y
es aceptada si el despachador no ha procesado cualquier lectura Rj(xr), tal
que,
ts(Ti) < ts(xr) < ts(Tj)

4.2.2.3 PRUEBAS DE VALIDACIN OPTIMISTAS

El protocolo mas reciente propuesta es el denominado optimista (OPT) el cual
acenta la pertenencia general del sistema reduciendo el bloqueo proveniente de
aquellas transacciones que estn preparadas para terminar pero que aun no lo
hicieron.
Los mecanismos optimistas para el control de concurrencia fueron propuestos
originalmente con el uso de estampas de tiempo.
Sin embargo, en este tipo de mecanismos, no con los datos ms aun as con las
estampas de tiempo no se asignan al inicio de una transaccin sino justamente al
inicio de su fase de validacin. Esto se debe a que las estampas se requieren
nicamente durante la fase de validacin.
Los algoritmos optimistas, retrasan la fase de validacin justo antes de la fase de
escritura (ver Figura). De esta manera, una operacin sometida a un despachador
optimista nunca es retrasada. Las operaciones de lectura, cmputo y escrita de
cada transaccin se procesan libremente sin actualizar la base de datos corriente.
Cada transaccin inicialmente hace sus cambios en copias locales de los datos.
La fase de validacin consiste en verificar si esas actualizaciones conservan la
consistencia de la base de datos. Si la respuesta es positiva, los cambios se
hacen globales. De otra manera, la transaccin es abortada y tiene que reiniciar.

95

Cada transaccin Ti se subdivide en varias subtransacciones, cada una de las

cuales se puede ejecutar en nodos diferentes. Sea Tij una subtransaccin de Ti
que se ejecuta en el nodo j. Supongamos que las transacciones se ejecutan de
manera independiente y ellas alcanzan el fin de sus fases de lectura. A todas las
subtransacciones se les asigna una estampa de tiempo al final de su fase de
lectura. Durante la fase de validacin se realiza una prueba de validacin, si una
transaccin falla, todas las transacciones se rechazan.
La Prueba De Validacin Se Realiza Con Una De Las Siguientes Reglas:
1.- Si todas las transacciones Tk, tales que, ts( Tk ) < ts( Tij ), han terminado su
fase de escritura antes que Tij ha iniciado su fase de lectura entonces la validacin
tiene xito. En este caso la ejecucin de las transacciones es completamente
serial como se muestra en la Figura.
2.- Si existe alguna transaccin Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su
fase de escritura mientras Tij est en su fase de lectura, entonces, la validacin
tiene xito si WS(Tk ) RS(Tij ) = . En este caso, las fases de lectura y escritura
se traslapan, como se muestra en la Figura 6.7b, pero Tij no lee datos queson
escritos por Tk.
3.- Si existe alguna transaccin Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su
fase de lectura antes que Tij termine su fase de lectura, entonces, la validacin
tiene xito si WS(Tk ) RS(Tij ) = y WS(Tk ) WS(Tij ) = . En este caso, las
fases de lectura se traslapan, como se muestra en la Figura 6.7c, pero las
transacciones no accesan datos comunes.

96

Los mecanismos optimistas para control de concurrencia fueron propuestos

originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de
mecanismos las estampas de tiempo se asocian nicamente con las
transacciones, no con los datos.
Algoritmos optimistas

No realiza ninguna verificacin durante la ejecucin.

Los cambios se realizan sobre copias locales.
Al final de la ejecucin existe una fase de validacin que comprueba
que cualquiera de las actualizaciones violaba la seriabilidad.

97

4.2.3 DISCIPLINAS DEL INTERBLOQUEO: PREVENCIN, DETECCIN,

ELIMINACIN Y RECUPERACIN.
El interbloqueo.- Un esquema para resolver el interbloque en su detencin, es un
bloqueo permanente de un conjunto de procesos que compiten por los recursos
del sistema o bien se comunican unos con otros. A diferencia de otros problemas
de la gestin concurrente de procesos, no existe una solucin eficiente para el
caso general.
Formas de presentar el interbloqueo
Grafo de esperas.
Grafo de reservas.
Grafo de esperas.- Es un grafo en el cual los nodos son las transacciones y la
relacin de espera entrenada se define como sigue: Una transaccin y relacin de
espera a otra transaccin T9 si te ha solicitado el bloqueo de un granulo y esta
peticin no puede ser aceptada porque T9 lo tiene bloqueado.
Grafo de reservas.- Grafo con dos tipos de nodos, los de las transacciones y los
Correspondientes a grnulos.
Un nodo une un granulo G1 a una transaccin T10 si T9 tiene bloqueado el
granulo G1. Un arco une una transaccin T9 con un granulo G1 si T9 ha solicitado
un bloqueo del granulo pero no le ha conseguido.
Una condicin necesaria para que haya un interbloqueo es que Q1 exista con ciclo
en el grafo de reservas.
Detencin.- Existen diversos algoritmos para ello en la detencin de ciclos en el
grafo de esperas, entre ellos:
Algoritmo 1.- Comprueba la existencia de ciclos mediante la eliminacin de nodos
terminales.
Algoritmo 2.- Comprueba posibles ciclos desde la ltima transaccin bloqueada y
marcando los nodos por lo que pasa. Si pasa dos veces por el mismo nodo a
detectado un ciclo.
Prevencin.- Las tcnicas de interbloqueo utilizan el concepto de marca de
tiempo detransaccin existen dos esquemas que evitan el interbloqueo.
Recuperacin.- El objetivo de esta parte de la asignacin es conocer y entender
las distintas fallas que pueden ocurrir en un BMS y cmo es posible restaurar el
sistema despus de dichas fallas este tema se llama recuperacin de fallas.
La recuperacin de fallas esta internamente ligado Al procesamiento de las
transacciones tiene la cualidad de ser anotmica a pesar de que puede estar

98

compuesto de varias operaciones de atomicidad se controla como llegada al

commit. Si una transaccin no sufri ningn problema y se pudo ejecutar
completa, entonces el DBMS debe de comprometerse hacer permanentes los
cambios que la transaccin hizo sobre la base de datos y a que esta debido
quedar en un estado de conciencia.
4.3 CONFIABILIDAD
Un sistema de manejo de bases de datos confiable es aquel que puede continuar
procesando las solicitudes de usuario an cuando el sistema sobre el que opera
no es confiable. En otras palabras, aun cuando los componentes de un sistema
distribuido fallen, un DBMS confiable debe seguir ejecutando las solicitudes de
usuario sin violar la consistencia de la base de datos.
La confiabilidad de un DBMS se refiere a la atomicidad y durabilidad de las
transacciones. El sistema sobre el cual se ejecutan los mecanismos de control de
concurrencia debe de ser confiable.
PROPIEDADES:
ATOMICIDAD: Se refiere cuando las operaciones de una transaccin se ejecutan
todas o ninguna.
DURABILIDAD: Despus de que una transaccin se ejecut con xito, los
cambios en la BD persisten, ms all de las fallas del sistema.
La confiabilidad se refiere a la consistencia de los resultados.
La confiabilidad se busca que los resultados de un cuestionario concuerden con
los resultados del mismo cuestionario en otra ocasin. Si esto ocurre se puede
decir que hay un alto grado de confiabilidad.
Un sistema de manejo de base de datos confiables aquel que puede continuar
procesando las solicitudes de usuario aun cuando el sistema sobre el que opera
no es confiable en otras palabras, aun cuando los componentes de un sistema
distribuido fallen un DDMBS confiable debe seguir ejecutndose las solicitudes de
usuario sin violar la consistencia de la base de datos.

99

4.3.1 CONCEPTOS BSICOS DE CONFIABILIDAD

SISTEMA, ESTADO Y FALLA:
Un sistema se refiere a un mecanismo que consiste de una coleccin de
componentes y sus interacciones con el medio ambiente que responden a
estmulos que provienen del mismo con un patrn de comportamiento reconocible.
Un estado externo de un sistema se puede definir como la respuesta que un
sistema proporciona a un estmulo externo. Por lo tanto, es posible hablar de un
sistema que se mueve dentro de estados externos de acuerdo a un estmulo
proveniente del medio ambiente. Un estado interno es, por lo tanto, la respuesta
del sistema a un estmulo interno.
Cualquier desviacin de un sistema del comportamiento descrito en su
especificacin se considera como una falla.
Cualquier error en los estados internos de los componentes del sistema se le
conoce como una falta en el sistema. As, una falta causa un error lo que puede
inducir una falla del sistema.
La confiabilidad de un sistema, R(t), se define como la siguiente probabilidad
condicional:
R(t) = Pr{ 0 fallas en el tiempo [0,t] | no hubo fallas en t = 0 }
Si la ocurrencia de fallas sigue una distribucin de Poisson, entonces,
R(t) = Pr{ 0 fallas en el tiempo [0,t] }.
El clculo de la confiabilidad y disponibilidad puede ser tedioso. Por lo tanto, es
acostumbrado usar dos mtricas de un slo parmetro para modelar el
comportamiento del sistema. Las dos mtricas son el tiempo medio entre fallas
(MTBF por sus siglas en ingls) y el tiempo medio para reparaciones (MTTR). El
MTBF puede ser calculado a partir de datos empricos de la funcin de
confiabilidad.
La confiabilidad es una condicin necesaria, pero no suficiente para la validez. Las
evidencias de validez siempre han de ir de la mano con las evidencias de
Confiabilidad.
La confiabilidad indica el grado de consistencia, pero no dice si las inferencias que
Se hacen y las decisiones que se toman partiendo del cuestionario son
defendibles.

100

La confiabilidad tambin se refiere a la medida en la cual un instrumento de

recopilacin de datos producir los mismos resultados cada vez que se administra.
En la investigacin cualitativa, la confiabilidad significa hasta qu punto diferentes
investigadores, al exponerse a la misma situacin, llegaran a las mismas
conclusiones.
En trminos de confiabilidad lo que preocupa es la consistencia de los resultados.
Se necesita la confiabilidad para poder hablar de resultados vlidos, puesto que
no es posible evaluar algo que cambia continuamente.
4.3.2 PROTOCOLOS REDO/UNDO
En un protocolo con escritura previa en bitcora, las entradas en la bitcora se
dividen en dos tipos: las necesarias para operaciones REDO (entradas write_tem
conteniendo slo nuevos valores) y las necesarias para operaciones UNDO
(entradas write_tem conteniendo los valores viejo y nuevo, y entradas read_tem).
Cuando se produce un fallo, el esquema de recuperacin consulta a la bitcora
para determinar que transacciones deben deshacerse o rehacerse.
UNDO (T): cuando la bitcora contiene el registro <T,start> pero no contiene el
registro <T,commit>.
REDO (T): cuando la bitcora contiene tanto el registro <T,start> como el registro
<T,commit>.
El esquema de recuperacin usa la operacin REDO rehacer usando
informacin de la bitcora. En caso de que ocurra una cada o fallo de una
transaccin se debe recurrir a una operacin UNDO que deshace los cambios
hechos.
Undo (T): restaura todos los datos que T actualiza a los valores que tena
anteriormente. Redo (T): asigna los nuevos valores a todos los datos que actualiza
la transaccin T.
Es importante respetar el orden de ejecucin de las operaciones para la
recuperacin. Las operaciones UNDO deben realizarse antes que las operaciones
REDO. Las operaciones de UNDO se realizan recorriendo la bitcora desde abajo
hacia arriba, esto es, en orden inverso al que se ejecutaron. Las operaciones de
REDO se realizan recorriendo la bitcora desde arriba hacia abajo, esto es, en el
mismo orden en que se actualiz.

101

Ejemplo:
<Ti,A,10,20>
<Tj,A,20,30>
<Tj,commit> Ti aborta pero Tj comete
Si se realiza un REDO primero, A quedar en 30 y el posterior UNDO dejar a A
con 10. El valor final de A debera ser 30, y eso es posible de alcanzar si se realiza
primero el UNDO y luego el REDO.
La operacin redo utiliza la informacin del registro de la base de datos y realiza
de nuevo las acciones que pueden haber sido realizadas antes de la falla, la
operacin redo genera nueva imagen.

Es posible que el administrador del buffer haya realizado la escritura en la base de

datos estable de algunas de las pginas de la base de datos voltil
correspondientes a la transaccin T2. As, la informacin de recuperacin debe
incluir datos suficientes para permitir deshacer ciertas actualizaciones en el nuevo
estado de la base de datos y regresarla al estado anterior.

La operacin UNDO restablece un dato a su imagen anterior utilizando la

informacin del registro de bases de datos.

102

Independientemente de que la escritura del registro sea sncrona o asncrona, se

debe observar un protocolo importante para el mantenimiento del registro de la
base de datos. Considere el caso donde las actualizaciones a la base de datos
son escritas en el almacenamiento estable antes de que el registro sea modificado
en el registro estable para reflejar la actualizacin. Si una falla ocurre antes de que
el registro sea escrito, la base de datos permanecer en forma actualizada, pero el
registro no indicar la actualizacin lo que har imposible recuperar la base de
datos a un estado consistente antes de la actualizacin.
4.3.3 PUNTOS DE VERIFICACIN (CHECK POINTS)
Los checkpoints buscan reducir los tiempos extra en los procesos de bsqueda en
la bitcora. Al disparar un checkpoint el sistema realiza la siguiente secuencia de
acciones:

Grabar en memoria estable todos los registros de bitcora que estn en

memoria principal.

Grabar en disco los bloques modificados de los registros intermedios

(buffer).

Grabar un registro de bitcora <checkpoint> en memoria estable.

Cuando ocurre un fallo del sistema es necesario consultar la bitcora para ver
cules transacciones deben rehacerse y cules deshacerse.
PASOS A SEGUIR ANTE FALLOS:
1.- Para cada transaccin Ti tal que aparece en la bitcora el registro <Ti,commit>
antes del registro <checkpoint>, no es necesario ejecutar un REDO.
2.- Despus de un fallo, se examina la bitcora para determinar cul fue la ltima
transaccin Ti que comenz a ejecutarse antes del ltimo checkpoint. *Esto se
hace examinando la bitcora hacia atrs buscando el primer registro <checkpoint>
y cual es el registro <Ti,start> ms cercano. *Luego, se aplica REDO o UNDO
sobre Ti y todas las transacciones que le suceden.
Un punto de control (checkpoints). Es registrado en la bitcora peridicamente
en el momento en que el sistema ha grabado en la BD en disco los efectos de
todas las operaciones de escritura de las transacciones confirmadas.
En un esquema sin concurrencia, en el proceso de recuperacin solamente se
consideraban: *Aquellas transacciones que comenzaron despus del checkpoint
ms reciente. *La nica transaccin (si exista) que estaba activa al momento del
ms reciente checkpoint. En un esquema concurrente puede haber ms de una
transaccin activa al momento del checkpoint.
103

Las operaciones de recuperacin requieren recorrer todo el registro de la base de

datos. As, el buscar todas las transacciones a las cuales es necesario aplicarles
un UNDO o REDO puede tomar una cantidad de trabajo considerable. Para
reducir este trabajo se pueden poner puntos de verificacin (checkpoints) en el
registro de la base de datos para indicar que en esos puntos la base de datos est
actualizada y consistente. En este caso, un REDO tiene que iniciar desde un punto
de verificacin y un UNDO tiene que regresar al punto de verificacin ms
inmediato anterior. La colocacin de puntos de verificacin se realiza con las
siguientes acciones:
Se escribe un begin_checkpoint en el registro de la base de datos. Se recolectan
todos los datos verificados en la base de datos estable. Se escribe un
fin_de_checkpoint en el registro de la base de datos.
Estos puntos de verificacin nos ayudan para reducir el gasto de tiempo
consultando la bitcora. El punto de verificacin en un registro que se genera en la

104

bitcora para concluir en todo lo que se encuentra antes de ese punto esta
correcto y verificado.
Si el sistema se llega a caer se realiza la bitcora buscando del final al inicio el
primer registro check point ya encontrado se procesan los registros que se
encuentran despus del check point.
4.3.4 PROTOCOLOS 2PC DE CONFIABILIDAD DISTRIBUIDA
Es un protocolo que consume un gran volumen de tiempo en la ejecucin de una
Transferencia durante el procesamiento normal se puede eliminar accesos a disco
o el nmero de mensajes en el proceso de la transaccin la pertenencia 2pc
podra ser mejorado.
El 2pc es conocido tambin como el protocolo que no resume nada para que
trata todas las transacciones de la misma forma sin importar si las mismas
cometen o abortan.
En el protocolo de bloqueo de dos fases estricto cada subtransaccin debe
informar a las otras subtransacciones de que ha requerido todos los bloqueos.
Una transaccin T que fue iniciada en un sitio S y dividida en varias
subtransacciones ejecutndose en diferentes sitios.
Las subtransaccin se ordenan en un coordinador y las otras participantes.

Cada subtransaccin Ti decide si cometer o abortar, y enva al coordinador

un mensaje . El coordinador toma la decisin final en funcin de las
votaciones de todos los participantes.

Cuando se presentan fallas en la red, este protocolo puede llevar a estados

de bloqueo, esto es, una subtransaccin en un sitio que no fall no puede
cometer ni abortar hasta que se repare la falla en el sitio de origen.

PROTOCOLO DE COMPROMISO DE 2 FASES:

Mejora: Cada subtransaccin mide el tiempo mximo de espera por una

respuesta.

Un participante que alcanza el tiempo mximo pasa al estado de intentar

recuperarse.

Para ello enva un mensaje de ayuda help me a los otros participantes.

Ante el pedido de ayuda, otros participantes segn su estado contestan:

Si est en estado cometida, le enva un mensaje commit.

Si est en estado abortado, le enva un mensaje abort.

105

Si est en estado decidiendo (no vot an) decide abortar y enva abort T
al coordinador.

Si est en estado dispuesta a comenter, no puede ayudar.

En la siguiente figura se presentan las dos fases de comunicacin para realizar un

commit en sistemas distribuidos. El esquema presentado en la figura se conoce
como centralizado ya que la comunicacin es solo entre el coordinador y los
participantes; los participantes no se comunican entre ellos.

Replicacin nerge
Esta permite la replicacin de tablas y procedimientos almacenados. Las
modificaciones pueden hacerse en el Publisher o bien en las copias mantenidas
por los suscriptores.
Para mantener la integridad de los datos replicados el proceso de sincronizacin
se encarga de actualizar las modificaciones realizadas en las copias de los
suscriptores y viceversa.
106

EJERCICIOS DE ALGEBRA RELACIONAL

Ejercicio 1:
Resultados:
a) Obtener los nombres de las papeleras abastecidas por algn editorial
de Madrid
NOMP (PAPELERIAS *ELP( CIUDAD =MADRID(EDITORIALES))

b) Obtener los valores de E# para las editoriales que suministran alas

papelera P1 y P2 libros publicados en 1978.
NOME (EDITORIALES *E#( AO=1978(LIBROS)*P#=p1(ELP)) n
E#( AO =1978(LIBROS)* P# =P3(ELP))
c) obtener los valores de p# de las papeleras abastecidas completamente
por la editorial
NOMP (PAPELERIA *(P#(ELP) E# (ELP)))
d) Obtener los valores de L# para los libros suministrados para todas las
papeleras que no sean de Madrid.
TITULO (LIBRO ( CIUDAD MADRID)-L#(ELP)))

Ejercicio 2:
Se pide expresar en trminos de algebra relacional la secuencia de operaciones
necesaria para efectuar las siguientes consultas de base de datos:
A) Obtener los usuarios (U#) que usan al menos todos los programas del
distribuidor D1
U#(usuarios=distribuidor (programas)*( D1)
B) Obtener los programas (P#) que solo son usados por el usuario U5.
P# ( programas*(U#(usos)-U#( usuarios= 5(usos))

C) obtener los distribuidores que venden los programas P5 y P8

107

 p# (programas*P#=P5(distribuidor))n p# ( programas*P#=P8(distribuidor))

D) Obtener los modelos de los ordenadores que son usados por

personas mayores de 30 aos por ms de 3 horas.
O# ( edad 30(usuarios)*ordenadores* ( tiempo=3(usos)))

Ejercicio 3:
B) videoclubes que disponen de alguna pelcula que le guste a jos prez

videoclub, pelcula (videoclub, pelcula)=x= pelcula ( aficionado=jos Prez

(gusta ))
C) aficionados que son socios al menos de un videoclub que dispone de
alguna pelcula de su gusto

aficionado, videoclub (socio) u aficionado, pelcula (gusta)

D) aficionados que no son socios de ningn videoclub donde tengan
alguna pelcula de su gusto.

aficionado(gusta) - aficionado (socio)

Ejercicio 4:
A) obtener todo los valores de T# que usan todas la maquinas del tipo 1.
T#( maquina =tipo(matricula)*(tipo1)
A) Obtener todas los F# para aquellas fincas en la qu ean realizados
trabajos las maquinas M1 y M3
F#( fincas *(F#(maquinas =1(trabajos)-T#(maquina=3)(trabajos))))
B) Obtener el velor de M# para aquellas maquinas que no han sido
utilizadas nunca en ningn trabajo
M#(tipo=trabajo(maquinas) *(nombre))

108

C) Obtenr todos los nombres de todas las fincas en la que se a trabajado

mas de 5 horas con maquinas cuyo precio por hora sea superior a 200
pts.
M#(fincas*F#( horas 5 (trabajos) * precios = 200(fincas))))

Ejercicio 5:
A) obtener los nombres de los alumnos que an aprobados todas las
practicas del tercer curso
nombre( alumno*(A# (curso=tercero(practica))))
B) Obtener los nombres de los alumnos que han entregado todas las

practicas de tercer curso

nombre( alumno*(A#(curso=tercero(practica) *entrega))))
C) Obtener los alumnos que han entregados practicas de segundo y

tercer curso
alumnos ( practica * ((curso=segundo(entrega)-alumno))n(
practicas(curso=tercero(entrega)

D) Obtener los alumnos que solo han entregado practicas de segundo

curso
alumno ( curso = segundo (entrega) * practica)

E) Obtener los alumnos que solo han entregado practicas de segundo

curso y pertenecen al grupo

BD-11
alumnos (practica*P#(curso=segundo(A#) * grupo=BD-11(practica)))
F) Obtener los nombres de los alumnos que no han suspendido ninguna

practica de las que han entregado.

nombre ( alumno * (practica = curso (entrega)

109

Ejercicio 6:
A) Obtener los ciclistas que solo han participado en competiciones
inferior a 15 das.
C# (ciclistas * (duracin = 15 min(competiciones)))
B) Obtener los ciclistas de equipos espaoles que han competido en
todas las competiciones de Espaa.
C#(equipo * (M# ( pas = Espaa (competiciones))))
C) Obtener los ciclistas que han obtenido un primer y un segundo lugar
puestos en competicin con una duracin inferior a 15 das.
nombre ( competiciones * ( puesto = primer (clasificacin *
(competiciones *( puesto=segundo(clasificacin))))) n C#( ciclistas
*(duracin = = 15 das(competicin)))

Ejercicio 7:
A) Obtener el nombre e aquellos conductores que hallan sido
denunciados por todas las infracciones inferiores a 100000 ptas.
nombreC (denuncia-(C#( infraccin = 10000(infraccin )) * (conductor))
B) Obtener el cdigo de aquellos agentes que solo hayan denunciado
infracciones de estacionamiento.
A# (agentes * infraccin ( descrip= estacionamiento (denuncia)
C) Obtener el cdigo de aquellos conductores que no tengan ninguna
denuncia pendiente de pago.
C#(conductores * denuncia ( pagada = S o N)

110

TERMINOS DE REPASO

Ejecucin de transacciones
Concurrencia
Estructura de las transacciones
Transacciones centralizadas
Transacciones distribuidas
Algoritmos basados en concurrencia
Serializacion
Interbloqueo
Protocolos redo
Protocolos undo

111

AUTOEVALUACION
1.- Defina que es una transaccin
2.- Explique las propiedades de las bases de datos para asegurar la consistencia
de los datos.
3.- Mencione que son las transacciones planas.
4.- Explique que son las transacciones anidadas.
5.- Mencione los aspectos ms importantes relacionados con el procesamiento de
transacciones.
6.- En qu consiste ejecutar transacciones serializadas?
7.- Explique en qu consiste ejecutar transacciones calendarizadas.
8.- Cul es la finalidad del control de concurrencias?
9.- Explique que son los candados de dos fases (2PL).
10.- Qu son los algoritmos basados en estampas de tiempo?
11.- Mencione las caractersticas de los algoritmos optimistas.
12.- Qu es el interbloqueo?
13.- Explique las formas de presentar el interbloqueo.
14.- Explique que es la confiabilidad.
15.- Explique los protocolos REDO/UNDO.

112

Bibliografa
Fundamentos de Bases de Datos, (Tercera Edicin), Autores: Abraham
Silberschatz, Henry F. Korth, S. Sudarshan
Modelos avanzados de bases de datos, universidad de castilla-la mancha,
esc.superior de informtica.
Distributed Databases, School of Science & Technology, Bell College (Hamilton)
Silberschatz, Korth, y Sudarshan, Fundamentos de Bases de Datos, 4 ed. Mc
Graw Hill
CONNOLLY, Thomas M. y BEGG, Carolyn E., Sistemas de bases de datos:
diseo, implementacin y gestin. Pearson - Addison Wesley, 4 edicin.
Armes A. Elmasri y Shamkant B. Navathe, Fundamentos de Sistemas de Bases de
Datos. 3 ed. Addison Wesley.
http://www.fing.edu.uy/inco/cursos/interop/interPresencial/transparencias/queries.p
df
http://www.mitecnologico.com/Main/OptimizacionDeConsultasDistribuidas
http://sistemas-distribuidos-unerg.blogspot.com/2007/12/bases-dedatosdistribuidas.html
http://catarina.udlap.mx/u_dl_a/tales/documentos/msp/alvarez_c_g/capitulo1.pdf

113