Sistemas de Bases de Datos Distribuidas

IT Superior de Lerdo
TÓPICOS DE BASES DE DATOS

Material Didáctico Oficial de la Asignatura.
SISTEMAS DE BASES DE
Tema 1 DATOS DISTRIBUIDAS
INTRODUCCIÓN
La evolución de los sistemas de información y el crecimiento no planeado de la

información dentro de las organizaciones, ha traído dispersión de los datos en sitios local
o geográficamente dispersos. La necesidad de integrar y compartir dicha información,
implica el nacimiento de una nueva tecnología capaz de conformar de manera
consistente la información de las organizaciones. Una de las tecnologías que trabaja en
el problema de integración de información, es la de Bases de Datos Distribuidas (BDD).
El presente capítulo ofrece, en primera instancia, un panorama global delas Bases de

Datos Distribuidas, sus funciones de operación, tipos de BDD y algunos conceptos tales
como autonomía, grado de homogeneidad y grado de heterogeneidad.
1.1. Conceptos de
base de datos 1
distribuidas.
1.2. Diseño de base
de datos 3
distribuidas.
1.3. Procesamiento
de operaciones de
22
actualización
distribuidas.
1.4. Procesamiento
de consultas 23
distribuidas.
1.5. Manejo de
29
transacciones.
Tema 1 - Sistemas de Bases de Datos Distribuidas
1.1 Conceptos de bases de datos distribuidas
Es una colección de datos que pertenecen lógicamente a un sólo sistema, pero

se encuentra físicamente esparcido en varios sitios de la red. Un sistema de base
de datos distribuidas se compone de un conjunto de sitios, conectados entre sí
mediante algún tipo de red de comunicaciones, en el cual:
Cada sitio es un sistema de base de datos en sí mismo. Los sitios han convenido
en trabajar juntos (si es necesario) con fin de que un usuario de cualquier sitio
pueda obtener acceso a los datos de cualquier punto de la red tal como si todos
los datos estuvieran almacenados en el sitio propio del usuario.
El procesamiento de bases de datos distribuidas es el proceso en el cual la

ejecución de transacciones y la recuperación y actualización de los datos
acontece a través de dos o más computadoras independientes, por lo general
separadas geográficamente.
Las Bases de Datos Distribuidas, no son simplemente implementaciones

distribuidas de bases de datos centralizadas, porque ellas permiten el diseño de
sistemas que representan diferentes características de las tradicionales, de
sistemas centralizados.
Esto es por lo tanto útil para ver las características típicas de BDD. Los rasgos
que caracterizan los BD tradicionales se aproximan al control centralizado,
independencia de datos, reducción de redundancia, estructuras físicas complejas
para acceso eficiente, integridad, recuperación control de concurrencia,
privacidad y seguridad.
Los principales factores que distinguen un SBDD de un sistema centralizado son

los siguientes:
 Hay múltiples computadores, llamados sitios o nodos.

 Estos sitios deben de estar comunicados por medio de algún tipo de red
de comunicaciones para transmitir datos y órdenes entre los sitios.
Las características de las bases de datos son las siguientes:
 Autonomía Local: Los sitios distribuido deben ser autónomos, es decir

que todas las operaciones en un sitio dado se controlan en ese sitio.
 No dependencia de un sitio central: No debe de haber dependencia de
un sitio central para obtener un servicio.
 Operación Continua: Nunca debería apagarse para que se pueda realizar
alguna función, como añadir un nuevo sitio.
1
 Independencia con respecto a la localización: No debe de ser necesario
que los usuarios sepan dónde están almacenados físicamente los datos, sino
que más el usuario lo debe de ver como si solo existiera un sitio local.
 Independencia con respecto a la fragmentación: La fragmentación es
deseable por razones de desempeño, los datos, pueden almacenarse en la
localidad donde se utilizan con mayor frecuencia de manera que la mayor
parte de las operaciones sean sólo locales y se reduzca el tráfico en la red.
 Independencia de réplica: Si una relación dada (es decir, un fragmento
dado de una relación) se puede presentar en el nivel físico mediante varias
copias almacenadas o réplicas, en muchos sitios distintos
Un medio ambiente distribuido para bases de datos.
2
1.2 Diseño de Bases de Datos Distribuidas
El problema de diseño de bases de datos distribuidos se refiere, en general, a

hacer decisiones acerca de la ubicación de datos y programas a través de los
diferentes sitios de una red de computadoras.
La decisión de donde colocar a las aplicaciones tiene que ver tanto con el
software del SMBDD como con las aplicaciones que se van a ejecutar sobre la
base de datos.
Los pasos a seguir para diseñar una base de datos distribuida:
 Diseño del “esquema conceptual” el cual describe la base de datos integrada

(esto es, todos los datos que son utilizados por las aplicaciones que tienen acceso
a las bases de datos).
 Diseño “físico de la base de datos”, esto es, mapear el esquema conceptual
a las áreas de almacenamiento y determinar los métodos de acceso a las bases
de datos.
 Diseño de la fragmentación, este se determina por la forma en que las
relaciones globales se subdividen en fragmentos horizontales, verticales o mixtos.
 Diseño de la asignación de los fragmentos, esto se determina en la forma en
que los fragmentos se mapean a las imágenes físicas, en esta forma, también se
determina la solicitud de fragmentos.
ARQUITECTURA DE BASE DE DATOS DISTRIBUIDA
Niveles de transparencia en sbdd
El propósito de establecer una arquitectura de un sistema de bases de datos

distribuidas es ofrecer un nivel de transparencia adecuado para el manejo
de la información. La transparencia se puede entender como la separación
de la semántica de alto nivel de un sistema de las aspectos de bajo nivel
relacionados a la implementación del mismo. Un nivel de transparencia
adecuado permite ocultar los detalles de implementación a las capas de alto
nivel de un sistema y a otros usuarios.
En sistemas de bases de datos distribuidos el propósito fundamental de la

transparencia es proporcionar independencia de datos en el ambiente
distribuido. Se pueden encontrar diferentes aspectos relacionados con la
transparencia. Por ejemplo, puede existir transparencia en el manejo de la
red de comunicación, transparencia en el manejo de copias repetidas o
transparencia en la distribución o fragmentación de la información.
3
La independencia de datos es la inmunidad de las aplicaciones de usuario
a los cambios en la definición y/u organización de los datos y viceversa. La
independencia de datos se puede dar en dos aspectos: lógica y física.
1. Independencia lógica de datos. Se refiere a la inmunidad de las

aplicaciones de usuario a los cambios en la estructura lógica de la base
de datos. Esto permite que un cambio en la definición de un esquema
no debe afectar a las aplicaciones de usuario. Por ejemplo, el agregar
un nuevo atributo a una relación, la creación de una nueva relación,
el reordenamiento lógico de algunos atributos.
2. Independencia física de datos. Se refiere al ocultamiento de los
detalles sobre las estructuras de almacenamiento a las aplicaciones de
usuario. Esto es, la descripción física 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 organización de los datos puede cambiar.
La transparencia al nivel de red se refiere a que los datos en un SBDD se

acceden sobre una red de computadoras, sin embargo, las aplicaciones no
deben notar su existencia. La transparencia al nivel de red conlleva a dos
cosas:
1. Transparencia sobre la localización de datos. Esto es, el comando que

se usa es independiente de la ubicación de los datos en la red y del lugar
en donde la operación se lleve a cabo. Por ejemplo, en Unix existen dos
comandos para hacer una copia de archivo. Cp se utiliza para copias
locales y rcp se utiliza para copias remotas. En este caso no existe
transparencia sobre la localización.
2. Transparencia sobre el esquema de nombramiento. Lo anterior se
logra proporcionando un nombre único a cada objeto en el sistema
distribuido. Así, no se debe mezclar la información de la localización
con en el nombre de un objeto.
La transparencia sobre replicación de datos se refiere a que si existen réplicas

de objetos de la base de datos, su existencia debe ser controlada por el
sistema no por el usuario. Se debe tener en cuenta que al cuando el usuario
se encarga de manejar las réplicas en un sistema, el trabajo de éste es
mínimo por lo que se puede obtener una eficiencia mayor. Sin embargo, el
usuario puede olvidarse de mantener la consistencia de las réplicas teniendo
así datos diferentes.
La transparencia a nivel de fragmentación de datos permite que cuando los

objetos de la bases de datos están fragmentados, el sistema tiene que manejar
la conversión de consultas de usuario definidas sobre relaciones globales a
consultas definidas sobre fragmentos. Así también, será necesario mezclar
4
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.
Ejemplo:
Como un ejemplo se utilizará a lo largo de estas notas una base de datos

que modela una compañía de ingeniería. Las entidades a ser modeladas son
ingenieros y proyectos. Para cada ingeniero, se desea conocer su número de
empleado (ENO), su nombre (ENOMBRE), el puesto ocupado en compañía
(TITULO), el salario (SAL), la identifiación de los nombres de proyectos en
los cuales está trabajando (JNO), la responsabilidad que tiene dentro del
proyecto (RESP) y la duración de su responsabilidad en meses (DUR).
Similarmente, para cada proyectose desea conocer el número de proyecto
(JNO), el nombre del proyecto (JNOMBRE), el presupuesto asignado al
proyecto (PRESUPUESTO) y el lugar en donde se desarrolla el proyecto
(LUGAR).
Un ingeniero puede participar en más de un proyecto pero su salario

corresponde únicamente al puesto que ocupa en la compañía. Así, después
de aplicar normalización se obtienen las relaciones E –para ingenieros, J
–para proyectos, S –para los salarios asignados a los puestos y G –para los
ingenieros asignados a cada proyecto.
5
G
Bases de datos de una empresa con cuatro relaciones.
Si se quisiera obtener todos los empleados y sus salarios en la corporación

quienes han trabajado más de 12 meses se haría la consulta siguiente en SQL:
6
SELECT ENOMBRE, SALARIO FROM E, G, S
WHERE JORNADA > 12 ANDE.ENO = G.ENO ANDE.TILE = S.TITLE
Se debe tener en cuenta que en cada sitio de la corporación puede haber

esquemas diferentes o repetidos.
Por ejemplo, en la siguiente figura se presentan esquemas diferentes para

el manejo de proyectos, empleados y puestos en cada sitio de la bases de
datos del ejemplo anterior.
Diferentes sitios de un corporación.
En resumen, la transparencia tiene como punto central la independencia de

datos. Los diferentes niveles de transparencia se puede organizar en capas
como se muestra en la figura siguiente.
Organización en capas de los niveles de transparencia.
7
En el primer nivel se soporta la transparencia de red. En el segundo nivel
se permite la transparencia de replicación de datos. En el tercer nivel se
permite la transparencia de la fragmentación. Finalmente, en el último nivel
se permite la transparencia de acceso (por medio de lenguaje de
manipulación 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. Entre estos tres módulos
se deben resolver los aspectos sobre el procesamiento distribuido de
consultas y sobre el manejo de nombres de objetos distribuidos.
El problema de diseño
El problema de diseño de bases de datos distribuidos se refiere, en general,

a hacer decisiones acerca de la ubicación de datos y programas a través de
los diferentes sitios de una red de computadoras. Este problema debería estar
relacionado al diseño de la misma red de computadoras. Sin embargo, en
estas notas únicamente el diseño de la base de datos se toma en cuenta. La
decisión de donde colocar a las aplicaciones tiene que ver tanto con el
software del SMBDD como con las aplicaciones que se van a ejecutar sobre
la base de datos.
El diseño de las bases de datos centralizadas contempla los dos puntos

siguientes:
1. Diseño del "esquema conceptual" el cual describe la base de datos

integrada (esto es, todos los datos que son utilizados por las aplicaciones
que tienen acceso a las bases de datos).
2. Diseño "físico de la base de datos", esto es, mapear el esquema
conceptual a las áreas de almacenamiento y determinar los métodos de
acceso a las bases de datos.
En el caso de las bases de datos distribuidas se tienen que considerar los

dos problemas siguientes:
1. Diseño de la fragmentación, este se determina por la forma en que

las relaciones globales se subdividen en fragmentos horizontales,
verticales o mixtos.
2. Diseño de la asignación de los fragmentos, esto se determina en la
forma en que los fragmentos se mapean a las imágenes físicas, en esta
forma, también se determina la solicitud de fragmentos.
Objetivos del Diseño de la Distribución de los Datos.
8
En el diseño de la distribución de los datos, se deben de tomar en cuenta
los siguientes objetivos:
Procesamiento local. La distribución de los datos, para maximizar el

procesamiento local corresponde al principio simple de colocar los datos tan
cerca como sea posible de las aplicaciones que los utilizan. Se puede realizar
el diseño de la distribución de los datos para maximizar el procesamiento
local agregando el número de referencias locales y remotas que le
corresponden a cada fragmentación candidata y la localización del
fragmento, que de esta forma se seleccione la mejor solución de ellas.
Distribución de la carga de trabajo. La distribución de la carga de trabajo

sobre los sitios, es una característica importante de los sistemas de cómputo
distribuidos. Esta distribución de la carga se realiza para tomar ventaja de
las diferentes características (potenciales) o utilizaciones de las
computadoras de cada sitio, y maximizar el grado de ejecución de
paralelismo de las aplicaciones. Sin embargo, la distribución de la carga de
trabajo podría afectar negativamente e procesamiento local deseado.
Costo de almacenamiento y disponibilidad. La distribución de la base de

datos refleja el costo y disponibilidad del almacenamiento en diferentes
sitios. Para esto, es posible tener sitios especializados en la red para el
almacenamiento de datos. Sin embargo el costo de almacenamiento de datos
no es tan relevante si éste se compara con el del CPU, I/O y costos de
transmisión de las aplicaciones.
Enfoques al problema de diseño de bases de datos distribuidas
Existen dos estrategias generales para abordar el problema de diseño de

bases de datos distribuidas:
1. El enfoque de arriba hacia abajo (top-down). Este enfoque es más

apropiado para aplicaciones nuevas y para sistemas homogéneos.
Consiste en partir desde el análisis de requerimientos para definir el
diseño conceptual y las vistas de usuario. A partir de ellas se define un
esquema conceptual global y los esquemas externos necesarios. Se
prosigue con el diseño de la fragmentación de la base de datos, y de
aquí se continúa con la localización de los fragmentos en los sitios,
creando las imágenes físicas. Esta aproximación se completa ejecutando,
en cada sitio, "el diseño físico" de los datos, que se localizan en éste.
En la figura se presenta un diagrama con la estructura general del
enfoque top-down.
2. El diseño de abajo hacia arriba (bottom-up). Se utiliza
particularmente a partir de bases de datos existentes, generando con
9
esto bases de datos distribuidas. En forma resumida, el diseño
bottom-up de una base de datos distribuida requiere de la selección de
un modelo de bases de datos común para describir el esquema global
de la base de datos. Esto se debe es posible que se utilicen diferentes
SMBD. Después se hace la traducción de cada esquema local en el
modelo de datos común y finalmente se hace la integración del esquema
local en un esquema global común.
El enfoque top-down para el diseño de bases de datos distribuidas.
El diseño de una base de datos distribuida, cualquiera sea el enfoque que

se siga, debe responder satisfactoriamente las siguientes preguntas:
¿Por qué hacer una fragmentación de datos?

¿Cómo realizar la fragmentación?
¿Qué tanto se debe fragmentar?
¿Cómo probar la validez de una fragmentación?
¿Cómo realizar el asignamiento de fragmentos?
¿Cómo considerar los requerimientos de la información?
10
El problema de fragmentación de relaciones.
El problema de fragmentación
El problema de fragmentación se refiere al particionamiento de la

información para distribuir cada parte a los diferentes sitios de la red, como
se observa en la Figura 3.2. Inmediatamente aparece la siguiente pregunta:
¿cuál es la unidad razonable de distribución?. Se puede considerar que una
relación completa es lo adecuado ya que las vistas de usuario son
subconjuntos de las relaciones. Sin embargo, el uso completo de relaciones
no favorece las cuestiones de eficiencia sobre todo aquellas relacionadas con
el procesamiento de consultas.
La otra posibilidad es usar fragmentos de relaciones (sub-relaciones) lo cual

favorece la ejecución concurrente de varias transacciones que accesan
porciones diferentes de una relación. Sin embargo, el uso de sub-relaciones
también presenta inconvenientes. Por ejemplo, las vistas de usuario que no
se pueden definir sobre un solo fragmento necesitarán un procesamiento
adicional a fin de localizar todos los fragmentos de una vista. Aunado a esto,
el control semántico de datos es mucho más complejo ya que, por ejemplo,
el manejo de llaves únicas requiere considerar todos los fragmentos en los
que se distribuyen todos los registros de la relación. En resumen, el objetivo
de la fragmentación es encontrar un nivel de particionamiento adecuado en
el rango que va desde tuplas o atributos hasta relaciones completas.
El grado de fragmentación.
11
Ejemplo.
Considere la relación J del ejemplo visto.
La relación J se puede fragmentar horizontalmente produciendo los siguientes

fragmentos.
J1: proyectos con presupuesto menor que $200,000
J2: proyectos con presupuesto mayor que o igual a $200,000
Ejemplo.
La relación J del ejemplo anterior se puede fragmentar verticalmente

produciendo los siguientes fragmentos:
J1: información acerca de presupuestos de proyectos
12
J2: información acerca de los nombres y ubicaciones de proyectos
Correctitud de una fragmentación
Al realizar la fragmentación de una relación se deben satisfacer las siguientes

condiciones para garantizar la correctitud de la misma:
1. Condición de completitud. La descomposición de una relación R en

los fragmentos R1, R2, ..., Rn es completa si y solamente si cada elemento
de datos en R se encuentra en algún de los Ri.
2. Condición de Reconstrucción. Si la relación R se descompone en los
fragmentos R1, R2, ..., Rn, entonces debe existir algún operador relacional
Ñ, tal que, R = Ñ 1£i£n Ri
3. Condición de Fragmentos Disjuntos. Si la relación R se descompone en
los fragmentos R1, R2, ..., Rn, y el dato di está en Rj, entonces, no debe estar
en ningún otro fragmento Rk(k1 j).
Alternativas sobre replicación para el asignamiento de fragmentos
La replicación de información es de utilidad para obtener un mejor

rendimiento y para ofrecer un mayor grado de confiabilidad (tolerancia a
fallas). La replicación se complica cuando es necesario hacer actualizaciones
a las copias múltiples de un dato. Por tanto, respecto a la replicación, en
el asignamiento de fragmentos se tienen tres estrategias:
13
1. No soportar replicación. Cada fragmento reside en un solo sitio.

2. Soportar replicación completa. Cada fragmento en cada uno de los
sitios.
3. Soportar replicación parcial. Cada fragmento en algunos de los sitios.
Como regla general se debe considerar que la replicación de fragmentos es

de utilidad cuando el número de consultas de solo lectura es (mucho) mayor
que el número de consultas para actualizaciones. En la Tabla se comparan
la complejidad de implementar o tomar ventaja de las diferentes alternativas
de replicación, respecto de los diferentes aspectos importantes en bases de
datos distribuidas.
Comparación de las estrategias de replicación de fragmentos.
Requerimientos de información
Con el fin de realizar una fragmentación adecuada es necesario proporcionar

información que ayude a realizarla. Esta información normalmente debe ser
proporcionada por el usuario y tiene que ver con cuatro tipos:
1. Información sobre el significado de los datos

2. Información sobre las aplicaciones que los usan
3. Información acerca de la red de comunicaciones
4. Información acerca de los sistemas de cómputo
Tipos de fragmentación de datos
Existen tres tipos de fragmentación:
1. Fragmentación horizontal
2. Fragmentación vertical
3. Fragmentación híbrida
14
En las siguientes secciones revisaremos de manera informal cada uno de los

tipos mencionados. Más adelante, se presentará de manera más formal la
construcción de los diferentes tipos de fragmentación.
Fragmentación horizontal primaria
Consiste del particionamiento en tuplas de una relación global en

subconjuntos, donde cada subconjunto puede contener datos que tienen
propiedades comunes y se puede definir expresando cada fragmento como
una operación de selección sobre la relación global.
Ejemplo.
Considere la relación global
SUPPLIER( SNUM, NAME, CITY )
entonces, la fragmentación horizontal puede ser definida como:
SUPPLIER1 = SLcity == "SF"SUPPLIER

SUPPLIER1 = SLcity == "LA"SUPPLIER
1. Esta fragmentación satisface la condición de completes si "SF" y "LA" son

solamente los únicos valores posibles del atributo CITY.
2. La condición de reconstrucción se logra con:
SUPPLIER = SUPPLIER1 union SUPPLIER2
3. La condición de disjuntos se cumple claramente en este ejemplo
Fragmentación vertical
La fragmentación vertical es la subdivisión de atributos en grupos. Los

fragmentos se obtienen proyectando la relación global sobre cada grupo. La
fragmentación es correcta si cada atributo se mapea en al menos un atributo del
fragmento.
Ejemplo.
Considere la siguiente relación global:
EMP( empnum, name, sal, tax, mgrnum, depnum )
15
una fragmentación vertical de esta relación puede ser definida como:
EMP1 = PJempnum, name, mgrnum, depnum EMP

EMP2 = PJempnum, sal, tax EMP
la reconstrucción de la relación EMP puede ser obtenida como:
EMP = EMP1 (JN empnum) EMP2 porque empnum es una clave de EMP
Fragmentación híbrida
En la que respecto a la fragmentación híbrida, esta consiste en aplicar la

fragmentación vertical seguida de la fragmentación horizontal o viceversa.
Ejemplo.
Considere la relación global
EMP( empnum, name, sal, tax, mrgnum, depnum )
Las siguientes son para obtener una fragmentación mixta, aplicando la vertical
seguida de a horizontal:
EMP1 = SL depnum <= 10 PJempnum, name, mgrnum, depnum EMPEMP2 = 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 reconstrucción de la relación EMP es definida por la siguiente expresión:
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)

DEP(DEPNUM, NAME, AREA, MGRNUM)
SUPPLIER(SNUM, NAME, CITY)
SUPPLY(SNUM, PNUM, DEPNUM, QUAN)
Después de aplicar una fragmentación mixta se obtiene el siguiente esquema

Fragmentado
16
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
Fragmentación horizontal
En las siguientes secciones revisaremos de manera más formal la forma de

construir los diferentes tipos de fragmentación.
La fragmentación horizontal primaria de una relación se obtiene usando

predicados que están definidos en esa relación. La fragmentación horizontal
derivada, por otra parte, es el particionamiento de una relación como resultado
de predicados que se definen en otra relación.
Para poder construir una fragmentación, es necesario proporcionar información

acerca de la base de datos y acerca de las aplicaciones que las utilizan. En primer
término, es necesario proporcionar la información acerca del esquema
conceptual global. En este sentido es importante dar información acerca de las
relaciones que componen a la base de datos, la cardinalidad de cada relación
y las dependencias entre relaciones. Por ejemplo, en la Figura 3.4 se presenta
un diagrama mostrando el esquema conceptual de la base de datos de ejemplo
principal.
En segundo lugar se debe proporcionar información acerca de la aplicación que

utiliza la base de datos. Este tipo de información es cuantitativa y consiste de
los predicados usados en las consultas de usuario.
Esquema conceptual de la base de datos de ejemplo
17
Dada una relación R(A1 , A2, ..., An), donde Ai es un atributo definido sobre el
dominio Di, un predicado simple pj definido en R tiene la forma pj: Ai q Valor
donde q Î { =, <, 1 , £ , >, 3 } y Valor Î Di. Para la relación R se define un
conjunto de predicados simples como Pr = { p1, p2 , ..., pm }.
Ejemplo.
Las siguientes expresiones se consideran como predicados simples.
JNOMBRE = "Mantenimiento"
PRESUPUESO < 200000
Dado la relación R y el conjunto de predicados simples Pr = { p1 , p2 , ...,

pm }, se define el conjunto de predicados minitérmino como M = { m1, m
2, ..., mr } como M = { mi | mi = Ùpj Î Pr p j *}, 1 £ j £ m, 1 £ i £ z donde,
pj * = pj o pj * = Ø (pj).
En términos de la información cuantitativa acerca de las aplicaciones de usuario,

se necesita tener dos conjuntos de datos:
1. La selectividad de los minitérminos: Denotada como sel( m i ), se refiere

al número de tuplos de la relación que serán accesadas por una consulta de
usuario especificada de acuerdo a un predicado minitérmino dado.
2. La frecuencia de acceso: Denotada como acc( q i ), se refiere a la
frecuencia con la cual una consulta de usuario q i es accesada en un periodo
de tiempo. Note que las frecuencias de acceso de minitérminos se pueden
determinar a partir de las frecuencias de consultas. La frecuencia de acceso
de un minitérmino se denota como acc( m i ).
Una fragmentación horizontal primaria se define por una operación de selección

en las relaciones propietarias de un esquema de la base de datos. Por tanto, dada
una relación R, su fragmentación horizontal está dada por
Rj = sFj (R), 1 £ j £ w
donde, F j es una fórmula de selección, la cual es preferiblemente un predicado

minitérmino. Por lo tanto, un fragmento horizontal Ri de una relación R consiste
de todos los tuplos de R que satisfacen un predicado minitérmino mi. Lo anterior
implica que dado un conjunto de predicados minitérmino M, existen tantos
fragmentos horizontales de R como minitérminos existan. El conjunto de
fragmentos horizontales también se entiende como los fragmentos minitérminos.
18
Es necesario desarrollar un algoritmo que tome como entrada una relación R y
el conjunto de predicados simples Pr y proporcione como resultado el conjunto
de fragmentos de R = { R1, R2, ..., Rm } el cual obedece las reglas de
fragmentación. Un aspecto importante del conjunto de predicados es que debe
ser completo y minimal.
Un conjunto de predicados simples Pr se dice que es completo si y solo si los

accesos a los tuplos de los fragmentos minitérminos definidos en Pr requieren
que dos tuplos del mismo fragmento tengan la misma probabilidad de ser
accedidos por cualquier aplicación.
FRAGMENTACION VERTICAL
Una fragmentación vertical de una relación R produce fragmentos R1, R2 , ...,

Rr, cada uno de los cuales contiene un subconjunto de los atributos de R así como
la llave primaria de R. El objetivo de la fragmentación vertical es particionar
una relación en un conjunto de relaciones más pequeñas de manera que varias
de las aplicaciones de usuario se ejecutarán sobre un fragmento. En este contexto,
una fragmentación "óptima" es aquella que produce un esquema de
fragmentación que minimiza el tiempo de ejecución de las consultas de usuario.
La fragmentación vertical ha sido estudiada principalmente dentro del contexto

de los sistemas de manejo de bases de datos centralizados como una herramienta
de diseño, la cual permite que las consultas de usuario traten con relaciones más
pequeñas haciendo, por tanto, un número menor de accesos a páginas.
La fragmentación vertical es inherentemente más complicada que

particionamiento horizontal ya que existe un gran número de alternativas para
realizarla. Por lo tanto, se utilizan heurísticas para hacer el particionamiento.
Los dos enfoques básicos son:
1. Agrupamiento. Inicia asignando cada atributo a un fragmento, y en cada

paso, algunos de los fragmentos satisfaciendo algún criterio se unen para
formar un solo fragmento.
2. División. Inicia con una sola relación realizar un particionamiento basado
en el comportamiento de acceso de las consultas sobre los atributos.
Nos concentraremos aquí al estudio del enfoque divisional ya que, por un lado,
su aplicación es más natural al enfoque de diseño "top-down". Además, el
enfoque divisional genera fragmentos que no se traslapan mientras que el
agrupamiento típicamente resulta en fragmentos traslapados. Por supuesto, la
no traslapación no incluye a las llaves primarias.
Requerimientos de información para la fragmentación vertical
19
Como en el caso de la fragmentación horizontal, es necesario proporcionar
información para poder realizar una adecuada fragmentación vertical. Ya que
el particionamiento vertical coloca en un fragmento aquellos atributos que se
acceden juntos, se presenta la necesidad de una medida que relacione la afinidad
de los atributos, la cual indica qué tan relacionados están los atributos. Esta
medida se obtiene por datos primitivos.
Dado un conjunto de consultas Q = { q1, q2, ..., qq } que serán aplicadas a la

relación R[A1, A2, ..., An ], se define la función
Los vectores use(q i, · ) son fáciles de definir si el diseñador conoce las

aplicaciones que serán ejecutadas en la base de datos.
FRAGMENTACION HIBRIDA
En muchos casos una fragmentación horizontal o vertical de un esquema de una

base de datos no será suficiente para satisfacer los requerimientos de aplicaciones
de usuario. En este caso, una fragmentación vertical puede ser seguida de uno
horizontal, o viceversa, produciendo un árbol de particionamiento estructurado,
como se muestra en la Figura. Ya que los dos tipos de particionamiento se aplican
uno después del otro, esta alternativa se le conoce como fragmentación híbrida.
Fragmentación híbrida.
Un buen ejemplo de la necesidad de la fragmentación híbrida es la relación J,

con la cual se ha trabajado.
20
En la Figura siguiente, se muestra el árbol de reconstrucción de la fragmentación
híbrida de J. Inicialmente se aplica una fragmentación horizontal y
posteriormente una fragmentación vertical.
Fragmentación híbrida de la relación J.
ASIGNAMIENTO DE FRAGMENTOS
El asignamiento de recursos entre los nodos de una red de computadoras

es un problema que se ha estudiado de manera extensa. Sin embargo, la
mayoría de este trabajo no considera el problema de diseño de bases de datos
distribuidas, en lugar de eso considera el problema de ubicar archivos
individuales en redes de computadoras.
El problema de asignamiento
Suponga que hay un conjunto de fragmentos F = { F1, F2, ..., Fn } y una

red que consiste de los sitios S = { S1, S2, ..., Sm } en los cuales un conjunto
de consultas Q = { q1, q2, ..., qq } se van a ejecutar. El problema de
asignamiento determina la distribución "óptima" de F en S. La optimalidad
puede ser definida de acuerdo a dos medidas:
1. Costo mínimo. Consiste del costo de comunicación de datos, del costo

de almacenamiento, y del costo procesamiento (lecturas y
actualizaciones a cada fragmento). El problema de asignamiento,
entonces, pretende encontrar un esquema de asignmiento que minimiza
una función de costo combinada.
2. Rendimiento. La estrategia de asignamiento se diseña para mantener
una métrica de rendimiento. Las dos métricas más utilizadas son el
tiempo de respuesta y el "throughput" (número de trabajos procesados
por unidad de tiempo).
21
En cualquier problema de optimización existen restricciones que se deben
satisfacer. El caso de distribución de fragmentos, las restricciones se
establecen sobre las capacidades de almacenamiento y procesamiento de
cada nodo en la red.
Requerimientos de información
En la fase de asignamiento se necesita conocer información cuantitativa

relativa a la base de datos, las aplicaciones que se utilizarán, la red de
comunicaciones, las capacidades de procesamiento y de almacenamiento de
cada nodo en la red.
Información sobre la base de datos. Es necesario conocer la selectividad de

un fragmento Fj con respecto a una consulta qi , esto es, el número de tuplos
de Fj que será necesario accesar para procesar qi . Este valor se denota como
sel( Fj ). Así también, es necesario conocer el tamaño de cada fragmento,
el cual está dado por:
size(Fj) = card(Fj) * length(Fj)
Información sobre las aplicaciones. Es necesario distinguir el número de

lecturas que una consulta qj hace a un fragmento Fj durante su ejecución,
del número de escrituras. Se requiere de una matriz que indique que
consultas actualizan cuales fragmentos. Una matriz similar se necesita para
indicar las lecturas de consultas a fragmentos. Finalmente, se necesita saber
cual es el nodo de la red que origina cada consulta.
Información sobre cada nodo de la red. Las medidas utilizadas son el costo
unitario de almacenamiento de datos en un nodo y el costo unitario de
procesamiento de datos en un nodo.
Información sobre la red de comunicaciones. Las medidas a considerar son:

la velocidad de comunicación, el tiempo de latencia en la comunicación y
la cantidad de trabajo adicional a realizar para una comunicación.
1.3 Procesamiento de operaciones de actualización

Refiérase al subtema 1.5, la actualización es una transacción.
22
1.4 Procesamiento de consultas distribuidas
El éxito creciente de la tecnología de bases de datos relacionales en el procesamiento

de datos se debe, en parte, a la disponibilidad de lenguajes no procedurales los cuales
pueden mejorar significativamente el desarrollo de aplicaciones y la productividad
del usuario final. Ocultando los detalles de bajo nivel acerca de la localización física
de datos, los lenguajes de bases de datos relacionales permiten la expresión de
consultas complejas en una forma concisa y simple. Particularmente, para construir
la respuesta a una consulta, el usuario no tiene que especificar de manera precisa
el procedimiento que se debe seguir. Este procedimiento es llevado a cabo por un
módulo del DBMS llamado el procesador de consultas (query processor).
Dado que la ejecución de consultas es un aspecto crítica en el rendimiento de un

DBMS, el procesamiento de consultas ha recibido una gran atención tanto para bases
de datos centralizadas como distribuidas. Sin embargo, el procesamiento de consultas
es mucho más difícil en ambientes distribuidos que en centralizados, ya que existe
un gran número de parámetros que afectan el rendimiento de las consultas
distribuidas. En este capítulo revisaremos el procesamiento de consultas para bases
de datos distribuidas.
El problema de procesamiento de consultas
La función principal de un procesador de consultas relacionales es transformar

una consulta en una especificación de alto nivel, típicamente en cálculo
relacional, a una consulta equivalente en una especificación de bajo nivel,
típicamente alguna variación del álgebra relacional (ver Figura).
Procesamiento de consultas.
23
La consulta de bajo nivel implementa de hecho la estrategia de ejecución para
la consulta. La transformación debe ser correcta y eficiente. Es correcta si la
consulta de bajo nivel tiene la misma semántica que la consulta original, esto
es, si ambas consultas producen el mismo resultado.
El mapeo bien definido que se conoce entre el cálculo relacional y el álgebra

relacional hace que la correctitud de la transformación sea fácil de verificar. Sin
embargo, producir una estrategia de ejecución eficiente es mucho más
complicado. Una consulta en el cálculo relacional puede tener muchas
transformaciones correctas y equivalentes en el álgebra relacional.
Ya que cada estrategia de ejecución equivalente puede conducir a consumos de

recursos de cómputo muy diferentes, la dificultad más importante es seleccionar
la estrategia de ejecución que minimiza el consumo de recursos.
Ejemplo 4.1.
Considere el siguiente subconjunto del esquema de la base de datos de
ingeniería que se presentó en el apartado 1.1
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 expresión 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:
24
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.
En un contexto centralizado, las estrategias de ejecución de consultas pueden

ser bien expresadas como una extensión del álgebra relacional. Sin embargo, en
sistemas distribuidos, el álgebra relacional no es suficiente para expresar la
ejecución de estrategias. Debe ser complementada con operaciones para el
intercambio de datos entre nodos diferentes. Además de elegir el orden de las
operaciones del álgebra relacional, el procesador de consultas distribuidas debe
seleccionar también los mejores sitios para procesar datos y posiblemente la
forma en que ellos tienen que ser transformados.
Ejemplo.
Considere la siguiente consulta del Ejemplo anterior:
Supongamos que las relaciones E y G están fragmentadas

horizontalmente como sigue:
E1 = sENO £ "E3" (E)

E2 = sENO > "E3" (E)
G1 = sENO £ "E3" (G)
G2 = sENO > "E3" (G)
Los fragmentos E1, E2, G1 y G2 están almacenados en los nodos 1, 2,

3 y 4, respectivamente, y el resultado se quiere en el nodo 5. En la
Figura se presentan dos estrategias distribuidas de ejecución diferentes
para la misma consulta (se ha ignorado el operador de proyección por
simplicidad del ejemplo).
25
La estrategia A explota el hecho de que las relaciones E y G están

fragmentadas de la mismamanera y ejecuta la operación de selección
y junta en paralelo. La estrategia B centraliza todos los datos en el nodo
resultante antes de procesar la consulta.
Para evaluar el consumo de recursos, se usará un modelo de costo simple.

Suponga que el costo de acceso a un tuplo (tupacc) es 1 unidad, y la
transferencia de un tuplo (tuptrans) tiene un costo de 10 unidades.
Suponga que las relaciones E y G tienen 400 y 1000 tuplos,
respectivamente, y que existen 20 administradores en la relación G.
También, suponga que los datos están uniformemente distribuidos entre

los nodos. Finalmente, suponga que las relaciones G y E están agrupadas
localmente en los atributos RESP y ENO, respectivamente, de manera
que, hay un acceso directo a los tuplos de G y E, respectivamente.
El costo de la estrategia A se puede derivar como sigue:
La estrategia A es mejor por un factor de 37, lo cual es significativo.

La diferencia sería aún mayor si se hubiera asumido un costo de
comunicación mayor y/o un grado de fragmentación mayor.
Objetivos de la optimización de consultas
Como se estableció antes, el objetivo del procesamiento de consultas en un

ambiente distribuido es transformar una consulta sobre una base de datos
distribuida en una especificación de alto nivel a una estrategia de ejecución
eficiente expresada en un lenguaje de bajo nivel sobre bases de datos locales.
26
Así, el problema de optimización de consultas es minimizar una función de
costo tal que
función de costo total = costo de I/O + costo de CPU + costo de comunicación
Los diferentes factores pueden tener pesos diferentes dependiendo del

ambiente distribuido en el que se trabaje. Por ejemplo, en las redes de área
amplia (WAN), normalmente el costo de comunicación domina dado que hay
una velocidad de comunicación relativamente baja, los canales están
saturados y el trabajo adicional requerido por los protocolos de
comunicación es considerable. Así, los algoritmos diseñados para trabajar
en una WAN, por lo general, ignoran los costos de CPU y de I/O. En redes
de área local (LAN) el costo de comunicación no es tan dominante, así que
se consideran los tres factores con pesos variables.
Arquitectura del procesamiento de consultas
El problema de procesamiento de consultas se puede descomponer en varios

subproblems que corresponden a diferentes niveles. En la Figura 4.4, se
presenta un esquema por niveles genérico para el procesamiento de consultas.
Para simplificar la discusión, suponga que se tiene un procesador de
consultas estático semicentralizado en donde no se tienen fragmentos
replicados. Cuatro capas principales están involucradas en mapear una
consulta a una base de datos distribuida en una secuencia optimizada de
operaciones locales, cada una de ellas actuando en una base de datos local.
Las cuatro capas principales son: descomposición de consultas, localización

de datos, optimización global de consultas y optimización local de consultas.
Las primeras tres se realizan en un nodo central usando información global.
La cuarta capa se realiza en cada nodo local.
Arquitectura en capas del procesamiento de consultas.
27
Descomposición de consultas
La primera capa descompone una consulta en el cálculo relacional en una

consulta en el álgebra relacional que opera sobre relaciones globales.
Consiste de cuatro partes:
1. Normalización. Involucra la manipulación de los cuantificadores de

la consulta y de los calificadores de la misma mediante la aplicación
de la prioridad de los operadores lógicos.
2. Análisis. Se detecta y rechazan consultas semánticamente incorrectas.
3. implificación. Elimina predicados redundantes.
4. Reestructuración. Mediante reglas de transformación una consulta en
el cálculo relacional se transforma a una en el álgebra relacional. Se sabe
que puede existir más de una transformación.
Por tanto, el enfoque seguido usualmente es empezar con una consulta

algebraica y aplicar transformaciones para mejorarla.
Localización 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 información sobre la distribución de datos. Esta capa determina
cuales fragmentos están involucrados en la consulta y transforma la consulta
distribuida en una consulta sobre fragmentos.
Optimización Global de Consultas
Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es

hallar una estrategia de ejecución para la consulta cercana a la óptima. La
estrategia de ejecución para una consulta distribuida puede ser descrita con
los operadores del álgebra relacional y con primitivas de comunicación para
transferir datos entre nodos. Para encontrar una buena transformación se
consideran las características de los fragmentos, tales como, sus
cardinalidades. Un aspecto importante de la optimización 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 optimización global es una consulta
algebraica optimizada con operación de comunicación incluidas sobre los
fragmentos.
Optimización Local de Consultas
28
El trabajo de la última capa se efectúa 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 optimización local utiliza los algoritmos de
sistemas centralizados.
1.5 MANEJO DE TRANSACCIONES DISTRIBUIDAS

La evolución de los sistemas de información y el crecimiento no planeado de
la información dentro de las organizaciones, ha traído dispersión de los datos
en sitios local o geográficamente dispersos. La necesidad de integrar y compartir
dicha información, implica el nacimiento de una nueva tecnología capaz de
conformar de manera consistente la información de las organizaciones. Una de
las tecnologías que trabaja en
Hasta este momento, las primitivas básicas de acceso que se han considerado
son las consultas (queries). Sin embargo, no se ha discutido qué pasa cuando,
por ejemplo, dos consultas tratan de actualizar el mismo elemento de datos, o
si ocurre una falla del sistema durante la ejecución de una consulta. Dada la
naturaleza de una consulta, de lectura o actualización, a veces no se puede
simplemente reactivar la ejecución de una consulta, puesto que algunos datos
pueden haber sido modificados antes la falla. El no tomar en cuenta esos factores
puede conducir a que la información en la base de datos contenga datos
incorrectos.
El concepto fundamental aquí es la noción de "ejecución consistente" o

"procesamiento confiable" asociada con el concepto de una consulta. El concepto
de una transacción es usado dentro del dominio de la base de datos como una
unidad básica de cómputo consistente y confiable.
Definición de una transacción
Una transacción es una colección de acciones que hacen transformaciones

consistentes de los estados de un sistema preservando la consistencia del
sistema. 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 información.
Por supuesto, se quiere asegurar que la base de datos nunca entra en un
estado de inconsistencia. Sin embargo, durante la ejecución de una
transacción, la base de datos puede estar temporalmente en un estado
inconsistente. El punto importante aquí es asegurar que la base de datos
regresa a un estado consistente al fin de la ejecución de una transacción (Ver
Figura)
29
Lo que se persigue con el manejo de transacciones es por un lado tener una

transparencia adecuada de las acciones concurrentes a una base de datos y
por otro lado tener una transparencia adecuada en el manejo de las fallas
que se pueden presentar en una base de datos.
Ejemplo.
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 notación de SQL, como

una transacción otorgándole un nombre:
Begin_transaction ACTUALIZA_PRESUPUESTO
begin
UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"
End.
Ejemplo.
Considere una agencia de reservaciones para líneas aéreas con las

siguientes relaciones:
FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP )

CUST( CNAME, ADDR, BAL )
30
FC( FNO, DATE, CNAME, SPECIAL )
Una versión simplificada de una reservación típica puede ser

implementada mediante la siguiente transacción:
Begin_transaction Reservación
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("reservación terminada");
end.
Condiciones de terminación de una transacción
Una transacción siempre termina, aun en la presencia de fallas. Si una

transacción termina de manera exitosa se dice que la transacción hace un
commit (se usará el término en inglés cuando no exista un término en
español que refleje con brevedad el sentido del término en inglés). Si la
transacción se detiene sin terminar su tarea, se dice que la transacción aborta.
Cuando la transacción es abortada, su ejecución es detenida y todas sus
acciones ejecutadas hasta el momento son deshechas (undone) regresando
a la base de datos al estado antes de su ejecución. A esta operación también
se le conoce como rollback.
Ejemplo.
Veamos el caso cuando no existen asientos disponibles para hacer la

reservación.
begin
input( flight_no, date, customer_name );
EXEC SQL SELECT STSOLD, CAP
INTO temp1, temp2
FROM FLIGHT
WHERE FNO = flight_no AND DATE = date
if temp1 = temp2 then
output( "no hay asientos libres" )
31
Abort
else
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 )
Commit
output("reservación terminada");
endif
end.
Caracterización de transacciones
Observe que en el ejemplo anterior las transacciones leen y escriben datos.

Estas acciones se utilizan como base para caracterizar a las transacciones.
Los elementos de datos que lee una transacción se dice que constituyen el
conjunto de lectura (RS). Similarmente, los elementos de datos que una
transacción escribe se les denomina el conjunto de escritura (WS). Note que
los conjuntos de lectura y escritura no tienen que ser necesariamente
disjuntos. La unión de ambos conjuntos se le conoce como el conjunto base
de la transacción (BS = RS U WS).
Ejemplo.
Los conjuntos de lectura y escritura de la transacción del Ejemplo 5.3

son:
RS[Reservación] = { FLIGHT.STSOLD, FLIGHT.CAP }

WS[Reservación] = { FLIGHT.STSOLD, FC.FNO, FC.DATE,
FC.NAME, FC.SPECIAL }
Formalización del concepto de transacción
Sea Oij(x) una operación Oj de la transacción Ti la cual trabaja sobre alguna

entidad x. Oj Î {read, write} y Oj es una operación atómica, esto es, se
ejecuta como una unidad indivisible. Se denota por OSi = Uj Oij al conjunto
de todas las operaciones de la transacción Ti . También, se denota por Ni
la condición de terminación para Ti , donde, Ni Î {abort, commit}.
La transacción Ti es un orden parcial, Ti = { Si , < i }, donde
1. Si = OSi U {Ni}
32
2. Para cualesquiera dos operaciones, Oij , Oik Î OSi , si Oij = R(x) y Oik
= W(x) para cualquier elemento de datos x, entonces, ó Oij < i Oik ó
Oik < i Oi
3. " Oij Î OSi , Oij < i Ni
Ejemplo.
Considere una transacción simple T que consiste de los siguientes pasos:
Read( x )
Read( y )
x ¬ x + y
Write( x )
Commit
La especificación de su transacción de acuerdo con la notación formal que

se ha introducido es la siguiente:
å = { R(x), R(y), W(x), C }

<i = { (R(x), W(x)), (R(y), W(x)), (W(x), C), (R(x), C), (R(y), C) }
Note que la relación de ordenamiento especifica el orden relativo de todas

las operaciones con respecto a la condición de terminación. Esto se debe a
la tercera condición de la definición de transacción.
También note que no se define el ordenamiento entre cualquier par de

operaciones, esto es, debido a que se ha definido un orden parcial.
Propiedades de las transacciones
La discusión en la sección previa clarifica el concepto de transacción. Sin

embargo, aun no se ha dado ninguna justificación para afirmar que las
transacciones son unidades de procesamiento consistentes y confiables. Las
propiedades de una transacción son las siguientes:
1. Atomicidad. Se refiere al hecho de que una transacción se trata como

una unidad de operación. Por lo tanto, o todas las acciones de la
transacción se realizan o ninguna de ellas se lleva a cabo. La atomicidad
requiere que si una transacción se interrumpe por una falla, sus
resultados parciales deben ser deshechos.
La actividad referente a preservar la atomicidad de transacciones en
33
presencia de abortos debido a errores de entrada, sobrecarga del sistema
o interbloqueos se le llama recuperación de transacciones. La actividad
de asegurar la atomicidad en presencia de caídas del sistema se le llama
recuperación de caídas.
2. Consistencia. La consistencia de una transacción es simplemente su
correctitud. En otras palabras, una transacción es un programa correcto
que lleva la base de datos de un estado consistente a otro con la misma
característica. Debido a esto, las transacciones no violan las restricciones
de integridad de una base de datos.
3. Aislamiento. Una transacción en ejecución no puede revelar sus
resultados a otras transacciones concurrentes antes de su commit. Más
aún, si varias transacciones se ejecutan concurrentemente, los resultados
deben ser los mismos que si ellas se hubieran ejecutado de manera
secuencial (seriabilidad).
4. Durabilidad. Es la propiedad de las transacciones que asegura que
una vez que una transacción hace su commit, sus resultados son
permanentes y no pueden ser borrados de la base de datos. Por lo tanto,
los DBMS aseguran que los resultados de una transacción sobrevivirán
a fallas del sistema. Esta propiedad motiva el aspecto de recuperación
de bases de datos, el cual trata sobre como recuperar la base de datos
a un estado consistente en donde todas las acciones que han hecho un
commit queden reflejadas.
En resumen, las transacciones proporcionan una ejecución atómica y

confiable en presencia de fallas, una ejecución correcta en presencia de
accesos de usuario múltiples y un manejo correcto de réplicas (en el caso
de que se soporten).
Tipos de Transacciones
Las transacciones pueden pertenecer a varias clases. Aun cuando los

problemas fundamentales son los mismos para las diferentes clases, los
algoritmos y técnicas que se usan para tratarlas pueden ser
considerablemente diferentes. Las transacciones pueden ser agrupadas a lo
largo de las siguientes dimensiones:
1. Areas de aplicación. En primer lugar, las transacciones se pueden

ejecutar en aplicaciones no distribuidas. Las transacciones que operan
en datos distribuidos se les conoce como transacciones distribuidas. Por
otro lado, dado que los resultados de una transacción que realiza un
commit son durables, la única forma de deshacer los efectos de una
transacción con commit es mediante otra transacción. A este tipo de
transacciones se les conoce como transacciones compensatorias.
Finalmente, en ambientes heterogéneos se presentan transacciones
34
heterogéneas sobre los datos.
2. Tiempo de duración. Tomando en cuenta el tiempo que transcurre
desde que se inicia una transacción hasta que se realiza un commit o
se aborta, las transacciones pueden ser de tipo batch o en línea. Estas
se pueden diferencias también como transacciones de corta y larga vida.
Las transacciones en línea se caracterizan por tiempos de respuesta muy
cortos y por accesar un porción relativamente pequeña de la base de
datos. Por otro lado, las transacciones de tipo batch toman tiempos
relativamente largos y accesan grandes porciones de la base de datos.
3. Estructura. Considerando la estructura que puede tener una
transacción se examinan dos aspectos: si una transacción puede contener
a su vez subtransacciones o el orden de las acciones de lectura y
escritura dentro de una transacción.
Estructura de transacciones
Las transacciones planas consisten de una secuencia de operaciones

primitivas encerradas entre las palabras clave begin y end. Por ejemplo;
...
end.
En las transacciones anidadas las operaciones de una transacción pueden ser

así mismo transacciones.
Por ejemplo;
...
Begin_transaction Vuelo
...
end. {Vuelo}
...
Begin_transaction Hotel
...
end.
...
end.
Una transacción anidada dentro de otra transacción 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 transacción
anidada: debe empezar después que su padre y debe terminar antes que él.
35
Más aún, el commit de una subtransacción es condicional al commit de su padre,
en otras palabras, si el padre de una o varias transacciones aborta, las
subtransacciones hijas también serán abortadas.
Las transacciones anidadas proporcionan un nivel más alto de concurrencia entre

transacciones. Ya que una transacción consiste de varios transacciones, es posible
tener más concurrencia dentro de una sola transacción. Así también, es posible
recuperarse de fallas de manera independiente de cada subtransacción. Esto
limita el daño a un parte más pequeña de la transacción, haciendo que costo
de la recuperación sea menor.
En el segundo punto de vista se considera el orden de las lecturas y escrituras.

Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna
restricción, entonces, a este tipo de transacciones se les conoce como generales.
En contraste, si se restringe o impone que un dato deber ser leído antes de que
pueda ser escrito entonces se tendrán 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 acción para transacciones restringidas en donde
se aplica aún más la restricción de que cada par <read,write> tiene que ser
ejecutado de manera atómica.
Aspectos relacionados al procesamiento de transacciones
Los siguientes son los aspectos más importantes relacionados con el

procesamiento de transacciones:
1. Modelo de estructura de transacciones. Es importante considerar si
las transacciones son planas o pueden estar anidadas.
2. Consistencia de la base de datos interna. Los algoritmos de control
de datos semántico tienen que satisfacer siempre las restricciones de
integridad cuando una transacción pretende hacer un commit.
3. Protocolos de confiabilidad. En transacciones distribuidas es
necesario introducir medios de comunicación entre los diferentes nodos
de una red para garantizar la atomicidad y durabilidad de las
transacciones. Así también, se requieren protocolos para la recuperación
local y para efectuar los compromisos (commit) globales.
4. Algoritmos de control de concurrencia. Los algoritmos de control de
concurrencia deben sincronizar la ejecución de transacciones
concurrentes bajo el criterio de correctitud. La consistencia entre
transacciones se garantiza mediante el aislamiento de las mismas.
5. Protocolos de control de réplicas. El control de réplicas se refiere a
cómo garantizar la consistencia mutua de datos replicados. Por ejemplo
se puede seguir la estrategia read-one-write-all (ROWA).
36
Incorporación del manejador de transacciones a la arquitectura de un SMBD
Con la introducción del concepto de transacción, se requiere revisar el

modelo arquitectural presentado anteriormente. En esta sección, se expande
el papel del monitor de ejecución distribuida.
El monitor de ejecución distribuida consiste de dos módulos: El

administrador de transacciones (TM) y el despachador (SC). Como se puede
apreciar en la Figura 5.2, el administrador de transacciones es responsable
de coordinar la ejecución en la base de datos de las operaciones que realiza
una aplicación. El despachador, por otra parte, es responsable de
implementar un algoritmo específico de control de concurrencia para
sincronizar los accesos a la base de datos.
Un tercer componente que participa en el manejo de transacciones

distribuidas es el administrador de recuperación local cuya función es
implementar procedimientos locales que le permitan a una base de datos
local recuperarse a un estado consistente después de una falla.
Un modelo del administrador de transacciones.
Los administradores de transacciones implementan una interfaz para los

programas de aplicación que consiste de los comandos:
1. Begin_transaction.
2. Read.
3. Write.
4. Commit.
5. Abort.
37
En la Figura se presenta la arquitectura requerida para la ejecución
centralizada de transacciones.
Ejecución centralizada de transacciones.
Las modificaciones requeridas en la arquitectura para una ejecución

distribuida se pueden apreciar en la Figura. En esta última figura se
presentan también los protocolos de comunicación necesarios para el manejo
de transacciones distribuidas.
Ejecución distribuida de transacciones.
CONTROL DE CONCURRENCIA
El control de concurrencia trata con los problemas de aislamiento y

consistencia del procesamiento de transacciones.
38
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 más simple de

lograr este objetivo es ejecutar cada transacción sola, una después de otra.
Sin embargo, esto puede afectar grandemente el desempeño de un DDBMS
dado que el nivel de concurrencia se reduce al mínimo. El nivel de
concurrencia, el número de transacciones activas, es probablemente el
parámetro más importante en sistemas distribuidos.
Por lo tanto, los mecanismos de control de concurrencia buscan encontrar

un balance entre el mantenimiento de la consistencia de la base de datos
y el mantenimiento de un alto nivel de concurrencia.Si no se hace un
adecuado control de concurrencia, se pueden presentar dos anomalías. En
primer lugar, se pueden perder actualizaciones provocando que los efectos
de algunas transacciones no se reflejen en la base de datos. En segundo
término, pueden presentarse recuperaciones de información inconsistentes.
En este capítulo se hace la suposición de que el sistema distribuido es
completamente confiable y no experimente falla alguna. En el capítulo
siguiente, se considerará la presencia de fallas para obtener sistemas
confiables.
39
Conclusiones del Tema.
Incluir aquí las conclusiones del tema
40
41

Sistemas de Bases de Datos Distribuidas

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sistemas de Bases de Datos Distribuidas

Caricato da

Copyright:

Formati disponibili

IT Superior de Lerdo

TÓPICOS DE BASES DE DATOS

La evolución de los sistemas de información y el crecimiento no planeado de la

El presente capítulo ofrece, en primera instancia, un panorama global delas Bases de

1.1 Conceptos de bases de datos distribuidas

Es una colección de datos que pertenecen lógicamente a un sólo sistema, pero

El procesamiento de bases de datos distribuidas es el proceso en el cual la

Las Bases de Datos Distribuidas, no son simplemente implementaciones

Los principales factores que distinguen un SBDD de un sistema centralizado son

 Hay múltiples computadores, llamados sitios o nodos.

Las características de las bases de datos son las siguientes:

 Autonomía Local: Los sitios distribuido deben ser autónomos, es decir

Un medio ambiente distribuido para bases de datos.

1.2 Diseño de Bases de Datos Distribuidas

El problema de diseño de bases de datos distribuidos se refiere, en general, a

Los pasos a seguir para diseñar una base de datos distribuida:

 Diseño del “esquema conceptual” el cual describe la base de datos integrada

ARQUITECTURA DE BASE DE DATOS DISTRIBUIDA

Niveles de transparencia en sbdd

El propósito de establecer una arquitectura de un sistema de bases de datos

En sistemas de bases de datos distribuidos el propósito fundamental de la

1. Independencia lógica de datos. Se refiere a la inmunidad de las

La transparencia al nivel de red se refiere a que los datos en un SBDD se

1. Transparencia sobre la localización de datos. Esto es, el comando que

La transparencia sobre replicación de datos se refiere a que si existen réplicas

La transparencia a nivel de fragmentación de datos permite que cuando los

Como un ejemplo se utilizará a lo largo de estas notas una base de datos

Un ingeniero puede participar en más de un proyecto pero su salario

Bases de datos de una empresa con cuatro relaciones.

Si se quisiera obtener todos los empleados y sus salarios en la corporación

Se debe tener en cuenta que en cada sitio de la corporación puede haber

Por ejemplo, en la siguiente figura se presentan esquemas diferentes para

Diferentes sitios de un corporación.

En resumen, la transparencia tiene como punto central la independencia de

Organización en capas de los niveles de transparencia.

La responsabilidad sobre el manejo de transparencia debe estar compartida

El problema de diseño de bases de datos distribuidos se refiere, en general,

El diseño de las bases de datos centralizadas contempla los dos puntos

1. Diseño del "esquema conceptual" el cual describe la base de datos

En el caso de las bases de datos distribuidas se tienen que considerar los

1. Diseño de la fragmentación, este se determina por la forma en que

Objetivos del Diseño de la Distribución de los Datos.

Procesamiento local. La distribución de los datos, para maximizar el

Distribución de la carga de trabajo. La distribución de la carga de trabajo

Costo de almacenamiento y disponibilidad. La distribución de la base de

Enfoques al problema de diseño de bases de datos distribuidas

Existen dos estrategias generales para abordar el problema de diseño de

1. El enfoque de arriba hacia abajo (top-down). Este enfoque es más

El enfoque top-down para el diseño de bases de datos distribuidas.

El diseño de una base de datos distribuida, cualquiera sea el enfoque que

¿Por qué hacer una fragmentación de datos?

El problema de fragmentación de relaciones.

El problema de fragmentación se refiere al particionamiento de la

La otra posibilidad es usar fragmentos de relaciones (sub-relaciones) lo cual

Considere la relación J del ejemplo visto.

La relación J se puede fragmentar horizontalmente produciendo los siguientes

J1: proyectos con presupuesto menor que $200,000

J2: proyectos con presupuesto mayor que o igual a $200,000

La relación J del ejemplo anterior se puede fragmentar verticalmente

J1: información acerca de presupuestos de proyectos

J2: información acerca de los nombres y ubicaciones de proyectos

Correctitud de una fragmentación

Al realizar la fragmentación de una relación se deben satisfacer las siguientes

1. Condición de completitud. La descomposición de una relación R en