Teoría de Bases de Datos II 1 UCENM
Teoría Bases Datos II
Universidad Cristiana Evangélica Nuevo Milenio
(UCENM)
Impresión Offset:
Corporación Nuevo Milenio (C.N.M.) Tel 2552-4100
E-mail:[email protected]
Primera Impresión:
Tegucigalpa M.D.C., Junio, 2011
Teoría de Bases de Datos II 2 UCENM
INDICE
Capítulo I ………………………… 3- 41 1. Consultas
Conceptos de consultas.
Tipos de Consultas en bases de datos.
Consultas simple y complejas.
Algebra Relacional.
Comandos de Consulta.
Ejemplos de consultas.
Capítulo II ……………………… 42- 73 2. Transacciones.
Introducción a las Transacciones.
Propiedades de la Transacciones.
Gestión de Transacciones.
Instrucciones para uso de Transacciones.
Técnicas para implantación de Transacciones.
Protocolos de Compromisos.
Estructura de Transacciones.
Proceso de Transacciones.
Transacciones en sistemas Distribuidos.
Ejemplo tipo de Transacciones Distribuidas.
Capítulo III ……………………….74-100 3. Concurrencia
El control de Concurrencia
Principales algoritmos
Algoritmo de cerradura o candado.
Control común en sistema de archivo.
Prevención de Abrazo Mortales.
Introducción a la concurrencia ADO.NET
Concurrencia en base de datos
Ejemplos de concurrencia.
Teoría de Bases de Datos II 3 UCENM
Capítulo IV …………………….…101- 155
4. Bases de Datos Distribuidas.
Introducción a Bases de Datos Distribuidas.
Administracion de una DDBMS
Cuadro de Ventajas y Desventajas bases datos distribuidas.
Configuraciones Principales.
Transparencia y Autonomía.
Diseño de base datos distribuidas.
Tipos de Fragmentación.
Tres entrada necesarias para desarrollo de fragmentación.
Fragmentación Mixta o Hibrida.
Tipos Bases datos Distribuidas.
Cuatro Metas de un DBMS Distribuidas.
Capitulo V ………………………156- 195 5. Base de Datos Paralelas.
Introducción a base datos paralela.
Paralelismo entre consulta.
Paralelismo entre Operaciones.
Ordenación entre Operaciones.
Eliminación de Duplicados.
Costos de evaluación en paralelo de operaciones.
Diseño de sistema Paralelos en base datos GRID.
Claves en seguridad GRID.
Gestión de Claves.
Criptografía de clave pública.
Integración de base datos de un sistema GRID.
Metadatos en base de Datos Sistema GRID.
Procesamiento Paralelo.
Teoría de Bases de Datos II 4 UCENM
CONSULTAS
Objetivos del capítulo I
1. Comprender y analizar el concepto consultas en Base
……….....de Datos.
2. Conocer los tipos de esquemas en consulta.
3. Conocer las consultas simple y complejas.
4. Comprender la Algebra Relacional.
5. Conocer los Comandos de Consultas.
Teoría de Bases de Datos II 5 UCENM
Introducción a las Consultas de Base de Datos
En bases de datos, una consulta es el método para acceder a los datos en las
bases de datos.
Con las consultas se puede modificar, borrar, mostrar y agregar datos en una
base de datos. Para esto se utiliza un lenguaje de consultas. El lenguaje de
consultas a base de datos más utilizado es el SQL.
Técnicamente hablando, las consultas a la base de datos se realizan a través
de un lenguaje de manipulación de datos (DML – Data Manipulation Language).
SQL es un lenguaje DML, pero además posee otras características de otros
lenguajes. Por ejemplo, permite también crear bases de datos.
Un esquema es un conjunto lógico de tablas, como la base de datos.
Usualmente, se piensa en él simplemente como “la base de datos”, pero una
base de datos puede contener más de un esquema. Por ejemplo, un esquema
estrella está compuesto de tablas, donde una gran y central tabla tiene toda la
información importante, con la que se accede, vía claves ajenas, a tablas
dimensionales, las cuales tienen información de detalle, y pueden ser usadas
en una unión para crear informes detallados.
Un esquema en estrella es aquel que tiene una tabla facturas de hechos que
contiene los datos de análisis, rodeada de las tablas lookup o de dimensiones.
Este aspecto, de tabla de hechos (o central) más grande rodeada de radios o
tablas más pequeñas es lo que asemeja con una estrella.
Una tabla facturas o tabla de hechos es la tabla central de un esquema
dimensional y contiene los valores de las medidas de negocio. Cada medida se
toma mediante la intersección de las dimensiones que la definen.
Este esquema es ideal por su simplicidad y velocidad para ser usado para
análisis: Data Marts? (Mercado de datos) y EIS (Sistemas de información
ejecutiva).
Teoría de Bases de Datos II 6 UCENM
Permite acceder tanto a datos agregados como de detalle.
Además, permite reducir el número de joins entre tablas y deja a los usuarios
establecer jerarquías y niveles entre las dimensiones.
Finalmente, es la opción con mejor rendimiento y velocidad pues permite
indexar las dimensiones de forma individualizada sin que repercuta en el
rendimiento de la base de datos en su conjunto.
Tipos de Esquemas
Esquema en estrella:
Consiste en estructurar la información en procesos, vistas y métricas
recordando a una estrella (por ello el nombre star schema).
Es decir, tendremos una visión multidimensional de un proceso que
medimos a través de unas métricas. A nivel de diseño, consiste en una
tabla de hechos (lo que en los libros encontraremos como fact table) en
el centro para el hecho objeto de análisis y una o varias tablas de
dimensión (dimensión table) por cada dimensión de análisis que
participa de la descripción de ese hecho.
En la tabla de hecho encontramos los atributos destinados a medir
(cuantificar) el hecho: sus métricas. Mientras, en las tablas de
dimensión, los atributos se destinan a elementos de nivel (que
representan los distintos niveles de las jerarquías de dimensión) y a
atributos de dimensión (encargados de la descripción de estos
elementos de nivel). En el esquema en estrella la tabla de hechos es la
única tabla del esquema que tiene múltiples joins que la conectan con
otras tablas (foreign keys hacia otras tablas).
El resto de tablas del esquema (tablas de dimensión) únicamente hacen
join con esta tabla de hechos.
Teoría de Bases de Datos II 7 UCENM
Las tablas de dimensión se encuentran además totalmente
denormalizadas, es decir, toda la información referente a una dimensión
se almacena en la misma tabla.
Esquema en copo de nieve (snowflake schema):
El esquema en copo de nieve (snowflake schema) es un esquema de
representación derivado del esquema en estrella, en el que las tablas de
dimensión se normalizan en múltiples tablas.
Por esta razón, la tabla de hechos deja de ser la única tabla del
esquema que se relaciona con otras tablas, y aparecen nuevas joins
gracias a que las dimensiones de análisis se representan ahora en tablas
de dimensión normalizadas. En la estructura dimensional normalizada, la
tabla que representa el nivel base de la dimensión es la que hace join
directamente con la tabla de hechos.
Diferencia entre ambos Esquemas.
La diferencia entre ambos esquemas (star y snowflake) reside entonces
en la estructura de las tablas de dimensión. Para conseguir un esquema
en copo de nieve se ha de tomar un esquema en estrella y conservar la
tabla de hechos, centrándose únicamente en el modelado de las tablas
de dimensión, que si bien en el esquema en estrella se encontraban
totalmente denormalizadas, ahora se dividen en subtablas tras un
proceso de normalización. Es posible distinguir dos tipos de esquemas
en copo de nieve, un snowflake completo (en el que todas las tablas de
dimensión en el esquema en estrella aparecen ahora normalizadas en el
snowflake) o un snowflake parcial (sólo se lleva a cabo la normalización
de algunas de ellas).
Teoría de Bases de Datos II 8 UCENM
Esquema de relación y esquema relacional
En un esquema de relación debemos especificar los atributos y dominios sobre
los que se define la relación, así como las restricciones de integridad que se
deben cumplir para que la relación constituya una ocurrencia válida del
esquema; es decir, aquellas restricciones que afectan a cada uno de los
elementos que forman parte del correspondiente esquema de relación
(restricciones intraelementos).
Por tanto, podremos definir un esquema de relación como:
R <A:D, S>
Siendo R el nombre de la relación, A la lista de atributos, D los dominios sobre
los que están definidos los atributos y S las restricciones de integridad,
intraelementos.
El esquema de la base de datos relacional será una colección de esquemas de
relación y de restricciones de integridad ínter elementos. Esto se puede
representar:
E < {Ri}, {Ii}>
Donde E es el nombre del esquema relacional, {Ri} es el conjunto de esquemas
de relación, e {Ii} representa el conjunto de restricciones de integridad ínter
elementos.
Podemos definir una base de datos relacional –“variable relacional” siguiendo la
terminología de DATE (1995) –como un esquema relacional junto con una
ocurrencia válida de dicho esquema, es decir, una ocurrencia que cumple todas
las restricciones descritas en el esquema.
La creación de esquemas se lleva a cabo mediante la sentencia:
<Definición de esquemas>::=
CREATE SCHEMA <cláusula de nombre del esquema>
Teoría de Bases de Datos II 9 UCENM
[<Especificación del conjunto de caracteres del esquema>]
[<Elementos de esquemas>…]
<Cláusula de nombre del esquema> ::=
<Nombre del esquema>
| AUTHORIZATION <id. Autorización del esquema›
| <Nombre del esquema› AUTHORIZATION <id. Autorización
Del esquema>
Podríamos, por ejemplo, crear el siguiente esquema:
CREATE SCHEMA biblioteca
AUTHORIZATION uc3m;
Diferencia entre una simple consulta de fila y una múltiple consulta de filas
Primero, para cubrir lo obvio, una consulta de una sólo fila es una consulta que
sólo devuelve una fila como resultado, y una consulta de múltiples filas es una
consulta que devuelve más de una fila como resultado. Si una consulta
devuelve una fila o más esto depende enteramente del diseño (o esquema) de
las tablas de la base de datos. Como escritor de consultas, debes conocer el
esquema, estar seguro de incluir todas las condiciones, y estructurar tu
sentencia SQL apropiadamente, de forma que consigas el resultado deseado
(aunque sea una o múltiples filas). Por ejemplo, si quieres estar seguro que una
consulta de la tabla Propietarios _ antigüedades devuelve sólo una fila,
considera una condición de igualdad de la columna de la clave primaria, ID _
propietario. Tres razones vienen inmediatamente a la mente de por qué esto es
importante. Primero, tener múltiples filas cuando tú sólo esperabas una, o
viceversa, puede significar que la consulta es errónea, que la base de datos
está incompleta, o simplemente, has aprendido algo nuevo sobre tus datos.
Teoría de Bases de Datos II 10 UCENM
Segundo, se estás usando una sentencia Update o Delete, debes de estar
seguro que la sentencia que estás escribiendo va a hacer la operación en la fila
(o filas) que tú quieres… o sino, estarás borrando o actualizando más filas de
las que querías. Tercero, cualquier consulta escrita en SQL embebido debe
necesitar ser construida para completar el programa lógico requerido. Si su
consulta, por otra parte, devuelve múltiples filas, deberás usar la sentencia
Fetch, y muy probablemente, algún tipo de estructura de bucle para el
procesamiento iterativo de las filas devueltas por la consulta.
¿Hay algún filtro en general que pueda usar para hacer mis consultas SQL y
bases de datos mejores y más rápidas (optimizadas)?
Puedes intentar, si puedes, evitar expresiones en Selects, tales como SELECT
Columna A + Columna B, etc. La consulta optimizada de la base de datos, la
porción de la DBMS que determina el mejor camino para conseguir los datos
deseados fuera de la base de datos, tiene expresiones de tal forma que puede
requerir más tiempo recuperar los datos que si las columnas fueran
seleccionadas de forma normal, y las expresiones se manejaran
programáticamente.
Si estas usando una unión, trata de tener las columnas unidas por
índices (desde ambas tablas).
Cuando tengas dudas, índice.
A no ser que tengas múltiples cuentas o consultas complejas, usa
COUNT (*) (el número de filas generadas por la consulta) mejor que
COUNT (Nombre _ columna).
Escribiendo y Editando Consultas Manualmente
La tarea realizada más común con el MySQL Query Browser es ejecutar
consultas y analizar sus resultados. La manera más directa de crear consultas
es escribirlas directamente sobre el área de consultas.
Teoría de Bases de Datos II 11 UCENM
Con forme se va escribiendo en el área de resultados, las porciones de sintaxis
de SQL (SELECT, FROM, WHERE, etc.) se van resaltando en azul.
Una vez que se escriba la consulta, el área de consultas se expandirá desde
tres líneas iníciales de altura a un máximo de diez líneas de altura. Para
espacio adicional, usted puede presionar la tecla F11 para maximizar el área
de consultas. También puede seleccionar la opción Maximizar Área de
Consulta de el menú Ver para maximizar el área de consultas. Cuando una
consulta es maximizada, el número de líneas es desplegado para la consulta, y
el área de consulta puede ser redimensionada haciendo click y arrastrando la
línea que divide el área de consulta con el área de resultado. Para restablecer
el área de consultas, presione nuevamente la tecla F11.
Una vez que capturada la consulta, dar un click en el botón Ejecutar y los
resultados de la consulta serán desplegados en el área de resultados. Usted
puede también presionar las teclas ctrl.+ Aceptar para ejecutar la consulta. Si
hay algún error en su consulta un área de errores aparecerá en la parte de
abajo de el área de resultados desplegando el mensaje de error y el código del
error.
En adición para cargar resultados de consultas en el área de resultados activa,
usted puede también crear una nueva área de resultado para los resultados de
su consulta o dividir su área de resultado actual y cargar los resultados dentro
de la nueva sección.
Para ejecutar una consulta y cargar los resultados en un área de resultados
nueva click en la flecha hacia abajo en la parte baja del botón Ejecutar y escoja
la opción Ejecutar en nueva Pestaña o presione las teclas ctrl.+Shift+Aceptar.
Para dividir el área de resultado activa y desplegar los resultados de la consulta
dar click en la flecha hacia abajo en la parte baja del botón Ejecutar y escoja la
opción Dividir Pestaña y Ejecutar o presione las teclas ctrl.+Alt+Enter.
Teoría de Bases de Datos II 12 UCENM
Usted debe establecer una base de datos por defecto antes de que usted
pueda consultar la base de datos satisfactoriamente. Puede establecer la base
de datos por defecto en la pantalla de conexión, o click-derecho en la base de
datos en el navegador de base de datos y eligiendo la opción Hacer Esquema
por Defecto, o eligiendo la opción Cambiar el esquema por defecto del menú
Archivo.
Editando Consultas desde una Herramienta de Desarrollo
En orden de ayudar a programadores a optimizar y depurar sus consultas más
eficientemente, el MySQL Query Browser puede copiar consultas desde el
código de aplicaciones usando su entorno (IDE) favorito.
Esta funcionalidad está solamente disponible para la versión de MySQL Query
Browser para Windows.
El siguiente código PHP será usado como ejemplo:
$SQL = “SELECT Id, Name, Country FROM City” .
“WHERE Name LIKE $cityname”;
Para copiar la consulta dentro de el MySQL Query Browser, copie el bloque de
código (incluyendo la porción de asignación), click derecho dentro del área de
consultas del MySQL Query Browser, y elegir la opción Pegar Contenido del
portapapeles como código PHP. Las porciones que no son consulta serán
removidas y la consulta será pegada dentro del área de consultas.
Los elementos dinámicos de la consulta son convertidos en parámetros locales,
visibles en el navegador de parámetros:
SELECT Id, Name, Country FROM City
WHERE Name LIKE: cityname
Teoría de Bases de Datos II 13 UCENM
Para establecer un valor a un parámetro local, seleccione el valor en el
navegador de parámetros y presione F2. Usted también puede dar doble-click
sobre el valor para editarlo. El valor que asigne será usado cuando la consulta
sea ejecutada.
Después de editar una consulta, click-derecho dentro del área de consultas y
elegir la opción Copiar Consulta Como Código PHP. El código PHP que
corresponde será re-insertado junto con la consulta modificada. Esta
funcionalidad permite editar consultas rápidamente mientras programa.
Consultas Simples.
Empezaremos por estudiar la sentencia SELECT, que permite recuperar
datos de una o varias tablas. La sentencia SELECT es con mucho la más
compleja y potente de las sentencias SQL. Empezaremos por ver las
consultas más simples, basadas en una sola tabla.
Esta sentencia forma parte del DML (lenguaje de manipulación de datos),
en este tema veremos cómo seleccionar columnas de una tabla, cómo
seleccionar filas y cómo obtener las filas ordenadas por el criterio que
queramos.
El resultado de la consulta es una tabla lógica, porque no se guarda en el
disco sino que está en memoria y cada vez que ejecutamos la consulta se
vuelve a calcular.
Cuando ejecutamos la consulta se visualiza el resultado en forma de tabla
con columnas y filas, pues en la SELECT tenemos que indicar qué
columnas queremos que tenga el resultado y qué filas queremos
seleccionar de la tabla origen.
Teoría de Bases de Datos II 14 UCENM
Si no conoces todavía las tablas que utilizaremos para los ejemplos y
ejercicios clic aquí
Sintaxis de la sentencia SELECT (consultas
simples)
La tabla origen - FROM -
Con la cláusula FROM indicamos en qué tabla tiene que buscar la
información. En este capítulo de consultas simples el resultado se
obtiene de una única tabla. La sintaxis de la cláusula es:
FROM especificación de tabla
Una especificación de tabla puede ser el nombre de una consulta
guardada (las que aparecen en la ventana de base de datos), o
el nombre de una tabla que a su vez puede tener el siguiente
formato:
Teoría de Bases de Datos II 15 UCENM
Aliastabla es un nombre de alias, es como un segundo nombre que
asignamos a la tabla, si en una consulta definimos un alias para la tabla,
esta se deberá nombrar utilizando ese nombre y no su nombre real,
además ese nombre sólo es válido en la consulta donde se define. El alias
se suele emplear en consultas basadas en más de una tabla que veremos
en el tema siguiente. La palabra AS que se puede poner delante del nombre
de alias es opcional y es el valor por defecto por lo que no tienen ningún
efecto.
Ejemplo: SELECT ......FROM oficinas ofi ; equivalente a SELECT ......FROM
oficinas AS ofi esta sentencia me indica que se van a buscar los datos en la
tabla oficinas que queda renombrada en esta consulta con ofi.
En una SELECT podemos utilizar tablas que no están definidas en la base
de datos (siempre que tengamos los permisos adecuados claro), si la tabla
no está en la base de datos activa, debemos indicar en qué base de datos
se encuentra con la cláusula IN.
En la cláusula IN el nombre de la base de datos debe incluir el camino
completo, la extensión (.mdb), y estar entre comillas simples.
Supongamos que la tabla empleados estuviese en otra base de datos
llamada otra en la carpeta c:\mis documentos\, habría que indicarlo así:
SELECT *FROM empleados IN 'c:\mis documentos\otra.mdb'
Generalmente tenemos las tablas en la misma base de datos y no hay que
utilizar la cláusula IN.
Selección de columnas
La lista de columnas que queremos que aparezcan en el resultado es lo
que llamamos lista de selección y se especifica delante de la cláusula
Teoría de Bases de Datos II 16 UCENM
FROM.
Utilización del *
Se utiliza el asterisco * en la lista de selección para indicar 'todas las
columnas de la tabla'.
Tiene dos ventajas:
Evitar nombrar las columnas una a una (es más corto).
Si añadimos una columna nueva en la tabla, esta nueva columna saldrá sin
tener que modificar la consulta.
Se puede combinar el * con el nombre de una tabla (ej. oficinas.*), pero esto
se utiliza más cuando el origen de la consulta son dos tablas.
SELECT * FROM oficinas
o bien
SELECT oficinas.* FROM
oficinas
Lista todos los datos de las oficinas
Columnas de la tabla origen
Las columnas se pueden especificar mediante su nombre simple (nbcol) o
su nombre cualificado (nbtabla.nbcol, el nombre de la columna precedido
del nombre de la tabla que contiene la columna y separados por un punto).
El nombre cualificado se puede emplear siempre que queramos y es
obligatorio en algunos casos que veremos más adelante.
Cuando el nombre de la columna o de la tabla contiene espacios en blanco,
hay que poner el nombre entre corchetes [ ] y además el número de
espacios en blanco debe coincidir.
Teoría de Bases de Datos II 17 UCENM
Por ejemplo [codigo de cliente] no es lo mismo que [ código de cliente] (el
segundo lleva un espacio en blanco delante de código)
Ejemplos :
SELECT nombre, oficina,
contrato
FROM ofiventas
Lista el nombre, oficina, y fecha de
contrato de todos los empleados.
SELECT idfab, idproducto,
descripción, precio
FROM productos
Lista una tarifa de productos
Alias de columna.
Cuando se visualiza el resultado de la consulta, normalmente las columnas
toman el nombre que tiene la columna en la tabla, si queremos cambiar ese
nombre lo podemos hacer definiendo un alias de columna mediante la
cláusula AS será el nombre que aparecerá como título de la columna.
Ejemplo:
SELECT idfab AS fabricante,
idproducto, descripción
FROM productos
..Como título de la primera columna
….aparecerá fabricante en vez de idfab
Columnas calculadas.
Además de las columnas que provienen directamente de la tabla origen,
una consulta SQL puede incluir columnas calculadas cuyos valores se
calculan a partir de los valores de los datos almacenados.
Para solicitar una columna calculada, se especifica en la lista de selección
una expresión en vez de un nombre de columna. La expresión puede
contener sumas, restas, multiplicaciones y divisiones, concatenación & ,
paréntesis y también funciones predefinidas).
Teoría de Bases de Datos II 18 UCENM
Para ver con más detalle cómo formar una expresión pincha aquí
Ejemplos:
SELECT ciudad, región, (ventas-
objetivo) AS superávit
FROM oficinas
Lista la ciudad, región y el superávit
de cada oficina.
SELECT idfab, idproducto, descripción,
(existencias * precio) AS valoración
FROM productos
De cada producto obtiene su
fabricante, idproducto, su
descripción y el valor del
inventario
SELECT nombre, MONTH(contrato),
YEAR(contrato)
FROM repventas
Lista el nombre, mes y año del
contrato de cada vendedor.
La función MONTH() devuelve el
mes de una fecha
La función YEAR() devuelve el año
de una fecha
SELECT oficina, 'tiene
ventas de ', ventas
FROM oficinas
Listar las ventas en cada oficina con el
formato: 22 tiene ventas de 186,042.00 lps
Consultas complejas
Uno de los temas que más cuesta a los que empiezan a aprender SQL son las
consultas en las que se recogen diferentes tipos de datos de una ó múltiples
tablas. Este artículo es una introducción a cómo definir consultas de este tipo
en PostgreSQL.
Unos conocimientos básicos de normalización de datos y un poco de álgebra
relacional no vienen mal para entender mejor algunos de los términos que
vamos a usar en este artículo.
Teoría de Bases de Datos II 19 UCENM
La normalización de datos es tema para otro artículo, pero en este veremos
brevemente algunos conceptos de álgebra relacional que nos pueden ayudar a
entender mejor el tema que estamos tratando.
Algebra relacional
El álgebra relacional es un tipo de álgebra con una serie de operadores que
trabajan sobre una ó varias relaciones para obtener una relación resultado. Es
la base indispensable para poder escribir buenas consultas en SQL.
Las operaciones más importantes disponibles en álgebra relacional son:
Las operaciones de conjunto aplicadas a relaciones: unión(∪),
intersección(∩) y diferencia(-)
Operaciones que eliminan una parte de las relaciones:
selección(σ) y proyección(Π)
Operaciones que combinan las duplas de dos relaciones:
producto cartesiano(x), combinación natural (><) y theta
Operación que cambia el nombre de los atributos ó relación:
renombre(ρ)
A continuación vamos a dar una breve introducción sobre estas operaciones:
Unión [R∪S]
La unión de R y S es el conjunto de elementos que existen en R, ó en S, ó en
las dos. Un elemento que existe tanto en R como en S aparece solamente una
vez en la unión. En el lenguaje SQL este tipo de operación se puede realizar
con la clausula UNION
Intersección [R∩S]
La intersección de R y S es el conjunto de elementos que existen en R y en S.
En el lenguaje SQL este tipo de operación se puede realizar con la clausula
INTERSECT
Diferencia [R-S]
La diferencia de R y S es el conjunto de elementos que existen en R pero no en
S. R-S es diferente a S-R, S-R seria el conjunto de elementos que existen en S
pero no en R. En el lenguaje SQL este tipo de operación se puede realizar con
la clausula EXCEPT
Teoría de Bases de Datos II 20 UCENM
Selección [σc(R)]
Esta operación aplicada a una relación R, produce una nueva relación con un
subconjunto de duplas de R. Este subconjunto de duplas satisface y cumple
cierta condición(c)
Proyección [Πa1,a2,...,an(R)]
Esta operación aplicada a una relación R, produce una nueva relación con
solamente los atributos (columnas) especificados por a1,a2,...,an
Producto cartesiano [RxS]
El producto cartesiano de dos relaciones R y S es la relación que se obtiene de
la combinación de todas las duplas de R con todas las duplas de S. Las duplas
de la relación que se obtiene están formadas por todos los atributos de R
seguidos de todos los atributos de S. En el lenguaje SQL este tipo de operación
se puede realizar con la cláusula CROSS JOIN ó separando las relaciones
usadas en el producto con comas, en el FROM de la sentencia SQL.
Combinaciones
Por medio del operador combinación (JOIN) podemos combinar dos relaciones
según una condición para obtener duplas compuestas por atributos de las dos
relaciones combinadas.
En el lenguaje SQL existen diferentes maneras de combinar dos relaciones. A
continuación tenes un resumen de las existentes en PostgreSQL:
Combinaciones internas (R INNER JOIN S): Un INNER JOIN
entre dos relaciones R y S, es el resultado que se obtiene
después de aplicar al producto cartesiano de las dos relaciones R
y S, una condición para acotar dicho producto. Existen un par de
casos especiales:
De equivalencia (Equi-join): Es un caso particular de INNER JOIN
en el que la condición que acota el resultado es una comparación
de igualdad.
R NATURAL JOIN S: Es un caso especial de equi-join en el que
en el caso de existir columnas con el mismo nombre en las
Teoría de Bases de Datos II 21 UCENM
relaciones que se combinan, solo se incluirá una de ellas en el
resultado de la combinación.
Combinaciones externas (OUTER JOINS): Un OUTER JOIN entre
dos relaciones R y S contiene todas las duplas que un INNER
JOIN devolvería, más una serie de duplas que no tienen atributos
en común en las dos relaciones. Los diferentes tipos son:
R LEFT OUTER JOIN S: Un LEFT OUTER JOIN entre dos
relaciones R y S, retorna todas las duplas de la combinación que
tengan un atributo común, más todas las duplas de la relación de
la izquierda (R) que no tengan un equivalente en la relación de la
derecha (S).
R RIGHT OUTER JOIN S: Un RIGHT OUTER JOIN entre dos
relaciones R y S, retorna todas las duplas de la combinación que
tengan un atributo común, más todas las duplas de la relación de
la derecha (S) que no tengan un equivalente en la relación de la
izquierda (R).
R FULL OUTER JOIN S: Un FULL OUTER JOIN entre dos
relaciones R y S, retorna todas las duplas de la combinación que
tengan un atributo común, más todas las duplas de la relación de
la izquierda (R) que no tenga un equivalente en la relación de la
derecha (S) y todas las duplas de la relación de la derecha (S)
que no tenga un equivalente en la relación de la izquierda (R).
Esta operación aplicada a una relación R, produce una nueva relación idéntica
a R en donde el atributo 'b' ha sido renombrado a 'a'.
El uso combinado de todas estas operaciones aplicado a nuestras relaciones
dará lugar a consultas más ó menos complejas.
Utilizando los operadores definidos en algebra relacional, podemos definir de
manera gráfica (árboles) ó lineal la representación algebraica de nuestra
consulta. En consultas muy complicadas es lo que se debería de hacer antes
de empezar a escribir el código SQL, pero este es un tema para otro artículo.
Teoría de Bases de Datos II 22 UCENM
Ejemplos prácticos
Nada mejor que unos ejemplos básicos para ver como se aplica la teoría que
hemos visto. Lo primero que vamos a hacer es definir un par de tablas que
utilizaremos en nuestros ejemplos:
postgres=# SELECT * FROM relacion_r;
a | b | c
---+---+---
1 | 2 | 3
4 | 5 | 6
(2 rows)
postgres=# SELECT * FROM relacion_s;
c | d | e
---+---+---
4 | 5 | 6
7 | 8 | 9
(2 rows)
En nuestro primer ejemplo realizamos una unión de las dos relaciones, el resultado
obtenido seria:
postgres=# SELECT * FROM relacion_r UNION SELECT * FROM relacion_s;
a | b | c
---+---+---
4 | 5 | 6
1 | 2 | 3
7 | 8 | 9
(3 rows)
A continuación realizamos una intersección entre las dos relaciones:
postgres=# SELECT * FROM relacion_r INTERSECT SELECT * FROM relacion_s;
a | b | c
---+---+---
4 | 5 | 6
(1 row)
Teoría de Bases de Datos II 23 UCENM
La diferencia entre estas dos relaciones daría el siguiente resultado. Como
podéis ver, y por definición, no es lo mismo la diferencia entre relación y
relacion_s, que entre relacion_s y relación
postgres=# SELECT * FROM relacion_r EXCEPT SELECT * FROM relacion_s;
a | b | c
---+---+---
1 | 2 | 3
(1 row)
postgres=# SELECT * FROM relacion_s EXCEPT SELECT * FROM relacion_r;
c | d | e
---+---+---
7 | 8 | 9
(1 row)
Vamos a definir una nueva fila (3,4,5) en la tabla relacion_s para ver unos
ejemplos de cómo combinar estas dos relaciones mediante JOINs.
postgres=# SELECT * FROM relacion_r;
a | b | c
---+---+---
1 | 2 | 3
4 | 5 | 6
(2 rows)
postgres=# SELECT * FROM relacion_s;
c | d | e
---+---+---
4 | 5 | 6
7 | 8 | 9
3 | 4 | 5
(3 rows)
La manera más simple de combinar estas dos relaciones es realizar el producto
cartesiano de ambas. Esto se puede realizar de dos maneras, ó bien definiendo
las dos relaciones separadas por comas después del FROM.
postgres=# SELECT * FROM relacion_r,relacion_s;
Teoría de Bases de Datos II 24 UCENM
a | b | c | c | d | e
---+---+---+---+---+---
1 | 2 | 3 | 4 | 5 | 6
1 | 2 | 3 | 7 | 8 | 9
1 | 2 | 3 | 3 | 4 | 5
4 | 5 | 6 | 4 | 5 | 6
4 | 5 | 6 | 7 | 8 | 9
4 | 5 | 6 | 3 | 4 | 5
(6 rows)
O utilizando la cláusula CROSS JOIN entre las dos relaciones.
postgres=# SELECT * FROM relacion_r CROSS JOIN relacion_s;
a | b | c | c | d | e
---+---+---+---+---+---
1 | 2 | 3 | 4 | 5 | 6
1 | 2 | 3 | 7 | 8 | 9
1 | 2 | 3 | 3 | 4 | 5
4 | 5 | 6 | 4 | 5 | 6
4 | 5 | 6 | 7 | 8 | 9
4 | 5 | 6 | 3 | 4 | 5
(6 rows)
En realidad un CROSS JOIN es el equivalente a un INNER JOIN ON (true).
Esto porque el INNER JOIN es por definición un producto cartesiano al que se
le aplica una condición para acotar el resultado. En este caso particular la
condición siempre se cumple para todas las duplas al utilizar el valor TRUE,
con lo que obtendremos todas las duplas del producto cartesiano.
Teoría de Bases de Datos II 25 UCENM
postgres=# SELECT * FROM relacion_r INNER JOIN relacion_s ON (true);
a | b | c | c | d | e
---+---+---+---+---+---
1 | 2 | 3 | 4 | 5 | 6
1 | 2 | 3 | 7 | 8 | 9
1 | 2 | 3 | 3 | 4 | 5
4 | 5 | 6 | 4 | 5 | 6
4 | 5 | 6 | 7 | 8 | 9
4 | 5 | 6 | 3 | 4 | 5
(6 rows)
A continuación podeis ver cómo definir un INNER JOIN con la condición
definida dentro de ON(). Este ejemplo es un Equi-join al utilizarse una
comparación de igualdad en la condición.
postgres=# SELECT * FROM relacion_r AS r INNER JOIN relacion_s AS s ON
(r.c = s.c);
a | b | c | c | d | e
---+---+---+---+---+---
1 | 2 | 3 | 3 | 4 | 5
(1 rows)
El mismo resultado obtenido con la clausula INNER JOIN se podría haber
conseguido obteniendo el producto cartesiano de las dos relaciones y
aplicando una condición con WHERE (definición de INNER JOIN).
postgres=# SELECT * FROM relacion_r AS r, relacion_s AS s WHERE r.c = s.c;
a | b | c | c | d | e
---+---+---+---+---+---
1 | 2 | 3 | 3 | 4 | 5
(1 rows)
postgres=# SELECT * FROM relacion_r as r CROSS JOIN relacion_s as s
WHERE r.c = s.c;
a | b | c | c | d | e
---+---+---+---+---+---
1 | 2 | 3 | 3 | 4 | 5
(1 row)
Teoría de Bases de Datos II 26 UCENM
Un NATURAL JOIN retorna el mismo resultado que un equi-join, pero sin
repetir las columnas comunes.
postgres=# SELECT * from relacion_r natural join relacion_s;
c | a | b | d | e
---+---+---+---+---
3 | 1 | 2 | 4 | 5
postgres=# SELECT a,b,c,d,e from relacion_r natural join relacion_s;
a | b | c | d | e
---+---+---+---+---
1 | 2 | 3 | 4 | 5
(1 row)
Como puede ver en lo que llevamos de artículo, existen diferentes maneras de
obtener un mismo resultado utilizando diferentes tipos de consultas. Teniendo
los conceptos claros y con práctica, os aseguro que todos estos tipos de
consultas os saldrán de forma natural después de un tiempo.
A continuación vamos a ver las combinaciones de tipo OUTER JOIN. En
PostgreSQL el uso de la palabra OUTER es opcional.
La primera es un LEFT OUTER JOIN.
postgres=# SELECT * FROM relacion_r AS r LEFT OUTER JOIN relacion_s AS
s ON (r.c = s.c);
a | b | c | c | d | e
---+---+---+---+---+---
1 | 2 | 3 | 3 | 4 | 5
4 | 5 | 6 | | |
(2 rows)
Seguido de un RIGHT OUTER JOIN:
postgres=# SELECT * FROM relacion_r AS r RIGHT OUTER JOIN relacion_s
AS s ON (r.c = s.c);
a | b | c | c | d | e
---+---+---+---+---+---
1 | 2 | 3 | 3 | 4 | 5
| | | 4 | 5 | 6
| | | 7 | 8 | 9
Teoría de Bases de Datos II 27 UCENM
(3 rows)
Y para terminar un FULL OUTER JOIN:
postgres=# SELECT * FROM relacion_r AS r FULL OUTER JOIN relacion_s AS
s ON (r.c = s.c);
a | b | c | c | d | e
---+---+---+---+---+---
1 | 2 | 3 | 3 | 4 | 5
| | | 4 | 5 | 6
4 | 5 | 6 | | |
| | | 7 | 8 | 9
(4 rows)
Un ejemplo casi real
Los ejemplos que hemos visto hasta ahora, nos han mostrado la sintaxis básica
de las operaciones que se pueden utilizar para obtener resultados con datos de
múltiples relaciones.
En la vida real nos encontraremos con casos muchos más complicados en los
que tendremos que combinar todas estas operaciones junto con el resto de
operadores y cláusulas SQL disponibles.
En casos complicados es importante pensar antes de empezar a escribir
nuestra consulta SQL. A continuación vamos a ver un ejemplo un poco más
complicado para ver cómo podemos desglosar y resolver la consulta que
necesitamos para obtener el resultado deseado.
Utilizaremos unas tablas creadas únicamente para este ejemplo y no
representativas de un sistema real. Tenemos una tabla principal llamada 'PC',
con diferentes columnas conteniendo cadenas de identificación de los
diferentes componentes usados para el ensamblado de diferentes modelos de
PCs.
Las columnas vacías de la tabla 'PC' significan componentes no presentes en
dichos modelos. El resto de tablas contienen información adicional sobre los
diferentes componentes usados para construir un PC.
Teoría de Bases de Datos II 28 UCENM
postgres=# SELECT * FROM pc;
pcid | memoria | cpu | disco | tgrafica | precio
------+---------+---------+-----------+-----------+------------------
1 | mem0001 | cpu0001 | disco0001 | ati001 | 1000
2 | mem0001 | cpu0001 | disco0002 | ati001 | 1100
3 | mem0002 | cpu0002 | disco0003 | nvidia001 | 1400
4 | mem0004 | cpu0003 | disco0004 | nvidia001 | 1600
5 | | cpu0001 | disco0001 | ati001 | 900
6 | | | | ati001 | 400
(6 rows)
postgres=# SELECT * FROM cpu ;
cpu_id | cpu_fabricante | cpu_tipo
---------+----------------+-------------------
cpu0001 | Intel | Core2 dúo
cpu0002 | Intel | Core2 Quad
cpu0003 | AMD | Athlon X2
(3 rows)
postgres=# SELECT * FROM memoria ;
mem_id | mem_capacidad | mem_tipo
---------+---------------+------------
mem0001 | 1024 | DDR SDRAM
mem0002 | 1024 | DDR2 SDRAM
mem0003 | 1024 | DDR3 SDRAM
mem0004 | 2048 | DDR3 SDRAM
(4 rows)
postgres=# SELECT * FROM disco ;
disco_id | disco_fabricante | disco_capacidad
-----------+------------------+-----------------
disco0001 | seagate | 350
disco0002 | seagate | 500
disco0003 | seagate | 1024
disco0004 | samsung | 500
(4 rows)
Teoría de Bases de Datos II 29 UCENM
postgres=# SELECT * FROM tgrafica ;
tgraf_id | tgraf_fabricante
-----------+-----------------------
ati001 | ati
nvidia001 | nvidia
Utilizando estas tablas vamos a realizar varias consultas:
Consulta 1
Obtener una relación de solo los modelos de PC 'completos' a la venta.
Queremos toda la información disponible sobre los componentes que lo
forman. Ordenar el resultado de mayor a menor precio.
Sabemos que al tener que coger datos de diferentes tablas, necesitaremos
algún tipo de clausula JOIN.
En esta consulta nos piden solamente, PCs completos, con todos sus
componentes. Por ello descartamos todas las combinaciones de tipo OUTER
JOIN y utilizamos INNER JOIN para obtener solamente las duplas con atributos
en todas las relaciones combinadas.
Cada PC tiene 4 componentes y la información de cada componente se
encuentra en una tabla separada. Con estos datos sabemos que tendremos
que realizar 4 INNER JOIN entre todas las tablas involucradas en la consulta.
Vamos a empezar a escribir la consulta SQL. Primero realizamos los INNER
JOIN y declaramos las condiciones que acotarán el resultado. Tendremos que
emparejar los atributos de componentes presentes en la tabla 'PC' con los
correspondientes atributos en el resto de tablas de componentes.
SELECT *
FROM pc AS a
INNER JOIN memoria AS b ON (a.memoria = b.mem_id)
INNER JOIN cpu AS c ON (a.cpu = c.cpu_id)
INNER JOIN disco AS d ON (a.disco = d.disco_id)
INNER JOIN tgrafica AS e ON (a.tgrafica = e.tgraf_id);
Una vez que hemos combinado todas las tablas, vamos a definir los atributos
que queremos presentar en nuestro resultado. Utilizaremos los prefijos de
Teoría de Bases de Datos II 30 UCENM
tablas definidos en la consulta anterior (a,b,c,d,e), para acceder a los atributos
de cada tabla:
SELECT
a.pcid,
b.mem_tipo,
b.mem_capacidad AS mem_MB,
c.cpu_fabricante AS cpu_fab,
c.cpu_tipo,
d.disco_fabricante AS disco_fab,
d.disco_capacidad AS disco_GB,
e.tgraf_fabricante AS tgraf_fab,
a.precio
FROM pc AS a
INNER JOIN memoria AS b ON (a.memoria = b.mem_id)
INNER JOIN cpu AS c ON (a.cpu = c.cpu_id)
INNER JOIN disco AS d ON (a.disco = d.disco_id)
INNER JOIN tgrafica AS e ON (a.tgrafica = e.tgraf_id);
Y para terminar ordenamos el resultado:
SELECT
a.pcid,
b.mem_tipo,
b.mem_capacidad AS mem_MB,
c.cpu_fabricante AS cpu_fab,
c.cpu_tipo,
d.disco_fabricante AS disco_fab,
d.disco_capacidad AS disco_GB,
e.tgraf_fabricante AS tgraf_fab,
a.precio
FROM pc AS a
INNER JOIN memoria AS b ON (a.memoria = b.mem_id)
INNER JOIN cpu AS c ON (a.cpu = c.cpu_id)
INNER JOIN disco AS d ON (a.disco = d.disco_id)
INNER JOIN tgrafica AS e ON (a.tgrafica = e.tgraf_id)
Teoría de Bases de Datos II 31 UCENM
ORDER BY precio DESC;
El resultado de nuestra consulta presentará las características de solo los PC
completos:
pcid | mem_tipo | mem_mb| cpu_fab | cpu_tipo | disco_fab | disco_gb | tgraf_fab |
precio
------+------------+--------+---------+------------+-----------+----------+-----------+--------
4 | DDR3 SDRAM | 2048 | amd | Athlon X2 | samsung | 500 | nvidia | 1600
3 | DDR2 SDRAM | 1024 | Intel | Core2 Quad | seagate | 1024 | nvidia | 1400
2 | DDR SDRAM | 1024 | Intel | Core2 dúo | seagate | 500 | ati | 1100
1 | DDR SDRAM | 1024 | Intel | Core2 duo | seagate | 350 | ati | 1000
(4 rows)
Consulta 2
Obtener una relación de todos los modelos de PC a la venta. Queremos toda la
información disponible sobre los componentes que lo forman. Ordenar el
resultado de mayor a menor precio. En esta consulta nos piden lo mismo que la
consulta 1 pero de todos los modelos de PC, los completos y los que se
venden sin algún componente. La tabla PC es la tabla principal de nuestra
combinación, y la tabla a la que le faltan valores en ciertos atributos en algunas
duplas. Esta tabla es la primera que se define cuando definimos las cláusulas
JOIN y por definición es la que se encuentra más a la izquierda. Por ello
utilizaremos el tipo LEFT OUTER JOIN para conseguir el resultado de la
consulta 1, más todos los PC a los que le falta algún componente.
Lo único que tenemos que hacer es cambiar INNER JOIN por LEFT OUTER
JOIN. La consulta quedaría así:
SELECT
a.pcid,
b.mem_tipo,
b.mem_capacidad AS mem_MB,
c.cpu_fabricante AS cpu_fab,
c.cpu_tipo,
d.disco_fabricante AS disco_fab,
d.disco_capacidad AS disco_GB,
e.tgraf_fabricante AS tgraf_fab,
a.precio
Teoría de Bases de Datos II 32 UCENM
FROM pc AS a
LEFT OUTER JOIN memoria AS b ON (a.memoria = b.mem_id)
LEFT OUTER JOIN cpu AS c ON (a.cpu = c.cpu_id)
LEFT OUTER JOIN disco AS d ON (a.disco = d.disco_id)
LEFT OUTER JOIN tgrafica AS e ON (a.tgrafica = e.tgraf_id)
ORDER BY precio DESC;
Y el resultado de nuestra consulta presentará las características de todos los
PC:
pcid | mem_tipo | mem_mb | cpu_fab | cpu_tipo | disco_fab | disco_gb | tgraf_fab | precio
------+------------+--------+---------+------------+-----------+----------+-----------+----------------+------------
4 | DDR3 SDRAM | 2048 | AMD | Athlon X2 | Samsung | 500 | nvidia | 1600
3 | DDR2 SDRAM | 1024 | Intel | Core2 Quad | seagate | 1024 | nvidia | 1400
2 | DDR SDRAM | 1024 | Intel | Core2 dúo | seagate | 500 | ati | 1100
1 | DDR SDRAM | 1024 | Intel | Core2 dúo | seagate | 350 | ati | 1000
5 | | | intel | Core2 dúo | seagate | 350 | ati | 900
6 | | | | | | | ati | 400
(6 rows)
Consulta 3
Obtener una relación de solo los modelos de 'PC NO completos' a la venta.
Queremos toda la información disponible sobre los componentes que lo forman
Observe esta consulta la podriamos obtener si al resultado que muestra todas
las PCs, le 'restamos' el resultado con solo las PCs completos.
Esto lo podríamos realizar combinando la consulta 1 con la consulta 2 mediante
el operador EXCEPT (consulta 2 EXCEPT consulta 1):
SELECT
a.pcid,
b.mem_tipo,
b.mem_capacidad AS mem_MB,
c.cpu_fabricante AS cpu_fab,
c.cpu_tipo,
d.disco_fabricante AS disco_fab,
d.disco_capacidad AS disco_GB,
e.tgraf_fabricante AS tgraf_fab,
a.precio
Teoría de Bases de Datos II 33 UCENM
FROM pc AS a
LEFT OUTER JOIN memoria AS b ON (a.memoria = b.mem_id)
LEFT OUTER JOIN cpu AS c ON (a.cpu = c.cpu_id)
LEFT OUTER JOIN disco AS d ON (a.disco = d.disco_id)
LEFT OUTER JOIN tgrafica AS e ON (a.tgrafica = e.tgraf_id)
EXCEPT
SELECT
a.pcid,
b.mem_tipo,
b.mem_capacidad AS mem_MB,
c.cpu_fabricante AS cpu_fab,
c.cpu_tipo,
d.disco_fabricante AS disco_fab,
d.disco_capacidad AS disco_GB,
e.tgraf_fabricante AS tgraf_fab,
a.precio
FROM pc AS a
INNER JOIN memoria AS b ON (a.memoria = b.mem_id)
INNER JOIN cpu AS c ON (a.cpu = c.cpu_id)
INNER JOIN disco AS d ON (a.disco = d.disco_id)
INNER JOIN tgrafica AS e ON (a.tgrafica = e.tgraf_id)
ORDER BY precio DESC;
El resultado seria el esperado:
pcid | mem_tipo | mem_mb | cpu_fab | cpu_tipo | disco_fab | disco_gb |
tgraf_fab | precio
------+----------+--------+---------+-----------+-----------+----------+-----------+--------
5 | | | Intel | Core2 dúo | seagate | 350 | ati |
900
6 | | | | | | | ati |
400
(2 rows)
Teoría de Bases de Datos II 34 UCENM
Consulta 4
Obtener una relación de todos los PC que tengan CPUs de AMD y discos
Samsung. Queremos toda la información disponible sobre los componentes
que lo forman
El trabajo para definir esta consulta está casi hecho. Lo único que tenemos que
hacer es aplicar mediante la sentencia WHERE, las dos condiciones que nos
piden, a la consulta 2:
SELECT
a.pcid,
b.mem_tipo,
b.mem_capacidad AS mem_MB,
c.cpu_fabricante AS cpu_fab,
c.cpu_tipo,
d.disco_fabricante AS disco_fab,
d.disco_capacidad AS disco_GB,
e.tgraf_fabricante AS tgraf_fab,
a.precio
FROM pc AS a
LEFT OUTER JOIN memoria AS b ON (a.memoria = b.mem_id)
LEFT OUTER JOIN cpu AS c ON (a.cpu = c.cpu_id)
LEFT OUTER JOIN disco AS d ON (a.disco = d.disco_id)
LEFT OUTER JOIN tgrafica AS e ON (a.tgrafica = e.tgraf_id)
WHERE c.cpu_fabricante = 'amd'
AND d.disco_fabricante = 'samsung'
ORDER BY precio DESC;
Teoría de Bases de Datos II 35 UCENM
Y el resultado quedaria asi:
pcid | mem_tipo | mem_mb | cpu_fab | cpu_tipo | disco_fab | disco_gb | tgraf_fab | precio
------+------------+--------+---------+-----------+-----------+----------+-----------+--------------+--------
4 | DDR3 SDRAM | 2048 | AMD | Athlon X2 | Samsung | 500 | nvidia | 1600
(1 row)
Consulta 5
Obtener una relación del número de PCs que tienen CPUs de Intel y de AMD.
Ordenar de mayor a menor.
Esta consulta es un poco diferente a las anteriores. Aquí tenemos que agrupar
los resultados según el fabricante de la CPU utilizada, y contar cuantas duplas
existen en cada grupo. Al necesitar solamente información contenida en la
tabla 'CPU', solo tendremos que combinar la tabla 'PC' con la tabla 'CPU'.
Como queremos obtener solamente los PC que tienen algún tipo de CPU,
utilizaremos un INNER JOIN para descartar los PCs sin CPU definida.
SELECT *
FROM pc AS a
INNER JOIN CPU AS b ON (a.cpu = b.cpu_id);
A continuación vamos a agrupar el resultado obtenido según el fabricante de la
CPU y contaremos el número de duplas en cada grupo:
SELECT
b.cpu_fabricante,
count(*) AS total
FROM pc AS a
INNER JOIN cpu AS b ON (a.cpu = b.cpu_id)
GROUP BY b.cpu_fabricante;
Y ordenamos el resultado:
SELECT
b.cpu_fabricante,
count(*) AS total
FROM pc AS a
INNER JOIN cpu AS b ON (a.cpu = b.cpu_id)
GROUP BY b.cpu_fabricante
ORDER BY total DESC;
Teoría de Bases de Datos II 36 UCENM
El resultado obtenido seria:
cpu_fabricante | total
----------------+------------
intel | 4
Amd | 1
(2 rows)
En fin, espero que tenga una idea de cómo funciona el tema de combinar
diferentes tablas para obtener un resultado.
En la vida real os encontrareis con ejemplos bastantes complicados, lo
importante es pensar la estrategia a seguir antes de empezar a escribir la
consulta SQL.
También es importante hacerlo paso a paso, aplicando las restricciones
necesarias hasta conseguir lo que queremos.
TIPOS DE COMANDOS DE CONSULTAS:
Una consulta de comandos aporta modificaciones a muchos registros con una
única operación. Existen cuatro tipos de consultas de comando
Eliminación, de Actualización, de Alineación y de Creación de Tablas y
parámetros.
1. Consultas de eliminación:
Este tipo de consulta elimina un grupo de registros de una o más tablas.
Existe la posibilidad, por ejemplo, de utilizar una consulta de eliminación para
reemplazar los productos que se han dejado de producir o para aquellos sobre
los cuales no existen pedidos. Con las consultas de eliminación siempre se
eliminan registros internos y no únicamente determinados campos de su
interior.
2. Consultas de actualización:
Este tipo aporta modificaciones globales a uno o más tablas.
Existe la posibilidad, por ejemplo, de aumentar en un 10 por ciento el precio de
todos los productos lácteos o aumentar los salarios en un 5 por ciento a las
personas pertenecientes a una determinada categoría laboral.
Teoría de Bases de Datos II 37 UCENM
3. Consultas de alineación:
Estas consultas agregan un grupo de registros de una o más tablas al final de
una o más tablas. Supongamos, por ejemplo, que se han conseguido nuevos
clientes y existe una base de datos que contiene una tabla de información
sobre estos. En vez de teclear nuevamente todas estas informaciones, se
alinean en la tabla correspondiente de Clientes.
4. Consultas de creación de tablas:
Este tipo de consultas crea una nueva tabla basándose en todos los datos o
parte de estos existentes en una o más tablas.
5. Consultas de parámetros:
Una consulta de parámetros es una consulta que, cuando se ejecuta, muestra
una ventana de diálogo que solicita informaciones, como por ejemplo criterios
para recuperar registros o un valor que se desea insertar en un campo.
Otros tipos de consultas
Los campos calculados
Un campo de este tipo es aquél que no existe en la tabla y que se crea sólo
temporalmente dentro de una columna en la consulta para realizar algún tipo
de operación matemática.
Consulta sueldo 1.
Las formulas o expresiones a poner en cada columna de la vista de diseño de
la consulta son
Columna Expresión
1 Salario
2 Bonificación: salario* 5/100
3 Bruto: Salario+ Bonificación
4 Retención: Bruto* 8/100
5 Neto: Bruto – Retención
6 NombVen
Para introducir los valores en las columnas utilizaremos el generador de
expresiones, y de esta forma nos
Aseguramos de que se utilice la sintaxis correcta.
Teoría de Bases de Datos II 38 UCENM
Según lo que acabamos de ver podemos utilizar las consultas para realizar
cálculos de cualquier tipo, utilizando
Nuestras propias expresiones con operadores más o menos sencillos, así
como con las funciones y operadores que trae Access.
Funciones de grupo No obstante en muchas ocasiones necesitaremos realizar
cálculos que involucren los datos contenidos en varias cada una de sus filas
contiene los datos de un único cliente, parece evidente que lo único que hay
que hacer es.
Contar las filas.
Para resolver este tipo de situaciones en las que hay que hacer cálculos
utilizando grupos de filas los gestores
de bases de datos en general disponen de varias funciones especiales que se
llaman funciones funciones agregadas. Estas funciones en Access son: de
grupo o
Función Descripción Cuenta Para contar el número de filas del grupo
Suma Para sumar el contenido del campo especificado de todas las filas del
grupo
Promedio Para hallar la media aritmética del campo especificado de todas las
filas del grupo
Mín Para hallar el menor valor del campo especificado de todas las filas del
grupo
Máx Para hallar el mayor valor del campo especificado de todas las filas del
grupo
DesvEst Para hallar la desviación típica del campo especificado de todas las
filas del grupo.
Teoría de Bases de Datos II 39 UCENM
CUESTIONARIO.
1-.¿ Que comprendio sobre el concepto de consultas ?
2-.¿Que tipos de esquemas existen?
3-. Explique que comprendió por Esquema en estrella.
4-. Explique que comprendió por Esquema copo de nieve.
5-. Explique la direncia entre una consulta Simple y una compuesta.
6 -. Explique para que sirve la sentencia SELECT.
Teoría de Bases de Datos II 40 UCENM
7-.¿ Que significado tiene el símbolo del asterico(*) en consultas ?
8-. ¿Qué es la Algebra relacional?
9-. ¿Qué tipo de combinaciones existen en SQL para realizar consultas?
10-.¿ Caules son los tipos de comandos de consulta?
10-. Analize el ejemplo de consulta No 2,de la pagina 32.
Teoría de Bases de Datos II 41 UCENM
TRANSACCIONES
Objetivos del capítulo II
1 .Comprender y analizar el concepto de Transacciones.
2 .Conocer las propiedades de las transacciones.
3 .Conocer las técnicas de Implantación.
4 .Comprender las estructuras de transacciones.
5 .Comprender los ejemplos de transacciones.
Teoría de Bases de Datos II 42 UCENM
INTRODUCCION A TRANSACCIONES DE BASE DE DATOS.
Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un
conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir,
en forma indivisible o atómica.
Un SGBD se dice transaccional, si es capaz de mantener la integridad de los
datos, haciendo que estas transacciones no puedan finalizar en un estado
intermedio. Cuando por alguna causa el sistema debe cancelar la transacción,
empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su
estado inicial (llamado punto de integridad), como si la orden de la transacción
nunca se hubiese realizado.
Para esto, el lenguaje de consulta de datos SQL (Structured Query Language),
provee los mecanismos para especificar que un conjunto de acciones deben
constituir una transacción.
BEGIN TRAN: Especifica que va a empezar una transacción.
COMMIT TRAN: Le indica al motor que puede considerar la transacción
completada con éxito.
ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe
restablecer la base al punto de integridad.
En un sistema ideal, las transacciones deberían garantizar todas las
propiedades ACID; en la práctica, a veces alguna de estas propiedades se
simplifica o debilita con vistas a obtener un mejor rendimiento.
Un ejemplo de transacción
Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero
entre cuentas bancarias. Normalmente se realiza mediante dos operaciones
distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la
que incrementamos el saldo de la cuenta destino.
Teoría de Bases de Datos II 43 UCENM
Para garantizar la atomicidad del sistema (es decir, para que no aparezca o
desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el
sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída
del sistema), el resultado final es que, o bien se han realizado las dos
operaciones, o bien no se ha realizado ninguna.
Una transacción es una secuencia de operaciones realizadas como una sola
unidad lógica de trabajo. Una unidad lógica de trabajo debe exhibir cuatro
propiedades, conocidas como propiedades de atomicidad, coherencia,
aislamiento y durabilidad (ACID), para ser calificada como transacción.
PROPIEDADES DE TRANSACCIONES.
Atomicidad
Una transacción debe ser una unidad atómica de trabajo, tanto si se
realizan todas sus modificaciones en los datos, como si no se realiza
ninguna de ellas.
Coherencia
Cuando finaliza, una transacción debe dejar todos los datos en un
estado coherente. En una base de datos relacional, se deben aplicar
todas las reglas a las modificaciones de la transacción para mantener la
integridad de todos los datos. Todas las estructuras internas de datos,
como índices de árbol b o listas doblemente vinculadas, deben estar
correctas al final de la transacción.
Aislamiento
Las modificaciones realizadas por transacciones simultáneas se deben
aislar de las modificaciones llevadas a cabo por otras transacciones
simultáneas.
Teoría de Bases de Datos II 44 UCENM
Una transacción reconoce los datos en el estado en que estaban antes
de que otra transacción simultánea los modificara o después de que la
segunda transacción haya concluido, pero no reconoce un estado
intermedio. Esto se conoce como seriabilidad, ya que deriva en la
capacidad de volver a cargar los datos iníciales y reproducir una serie de
transacciones para finalizar con los datos en el mismo estado en que
estaban después de realizar las transacciones originales.
Durabilidad
Una vez concluida una transacción, sus efectos son permanentes en el
sistema. Las modificaciones persisten aún en el caso de producirse un
error del sistema.
Especificar y exigir transacciones
Los programadores de SQL son los responsables de iniciar y finalizar las
transacciones en puntos que exijan la coherencia lógica de los datos. El
programador debe definir la secuencia de modificaciones de datos que los
dejan en un estado coherente en relación con las reglas de negocios de la
organización. El programador incluye estas instrucciones de modificación en
una sola transacción de forma que SQL Server Database Engine (Motor de
base de datos de SQL Server) puede hacer cumplir la integridad física de la
misma.
Es responsabilidad de un sistema de base de datos corporativo, como
una instancia de Motor de base de datos, proporcionar los mecanismos
que aseguren la integridad física de cada transacción. Motor de base de
datos proporciona:
Servicios de bloqueo que preservan el aislamiento de la transacción.
Servicios de registro que aseguran la durabilidad de la transacción.
Aunque se produzca un error en el hardware del servidor, el sistema
operativo o la instancia de Motor de base de datos, la instancia utiliza
registros de transacciones, al reiniciar, para revertir automáticamente las
transacciones incompletas al punto en que se produjo el error del
sistema.
Teoría de Bases de Datos II 45 UCENM
Características de administración de transacciones que exigen la
atomicidad y coherencia de la transacción. Una vez iniciada una
transacción, debe concluirse correctamente; en caso contrario, la
instancia de Motor de base de datos deshará todas las modificaciones
de datos realizadas desde que se inició la transacción.
Gestión de transacciones y administrador de la base de datos
Varias operaciones sobre la base de datos forman a menudo una única unidad
lógica de trabajo. Un ejemplo es la transferencia de fondos, en el que de la
cuenta A se retira y en la cuenta B se deposita. Es esencial que tanto el retiro
como el depósito tengan lugar o bien no ocurra ninguno.
Este requisito de todo o nada se denomina atomicidad. Además es esencial
que la ejecución de la transferencia de fondos preserva la consistencia de la
base de datos, es decir el valor de la suma A+B se debe preservar.
Este requisito de corrección se llama consistencia. Finalmente tras la ejecución
correcta de la transferencia de fondos los nuevos valores de las cuentas A y B
deben persistir, a pesar de la posibilidad de fallo del sistema. Este requisito de
persistencia se llama durabilidad.
Una transacción es una colección de operaciones que se lleva a cabo como
una única función lógica en una aplicación de bases de datos. Cada
transacciones una unidad de atomicidad y consistencia. Así se requiere que las
transacciones no violen ninguna restricción de consistencia de la base de
datos.
Es decir si la base de datos era consistente cuando la transacción comenzó, la
base de datos debe ser consistente cuando la transacción termine con éxito
Teoría de Bases de Datos II 46 UCENM
ADMINISTRADOR DE LA BASE DE DATOS
Una de las principales razones de usar un SGBDs es tener un control
centralizado tanto de los datos como de los programas que acceden a esos
datos.
La persona que tiene este control central sobre el sistema se llama
administrador de la base de datos (ABD)
FUNCIONES DEL ADMINISTRADOR DE LA BASE DE DATOS
Definición del esquema.- El DBA crea el esquema original de la base de datos
escribiendo un conjunto de instrucciones de definición de datos en el LDD.
Definición de la estructura y del método de acceso.
Modificación del esquema y de la organización física.-
Los DBA realizan cambios en el esquema y en la organización física para
reflejar las necesidades cambiantes de la organización, o para alterar la
organización física para mejorar el rendimiento.
Concesión de autorización para el acceso a los datos.- la concesión de
diferentes tipos de autorización
Permite al administrador de la base de datos determinar a qué partes de la
base de datos puede acceder cada usuario. La información de autorización se
mantiene en una estructura del sistema especial que el sistema de base de
datos consulta
Cuando se intenta el acceso a los datos del sistema.
Mantenimiento rutinario.- Algunos ejemplos de actividades rutinarias de
mantenimiento de la base de datos son:
Copia de seguridad periódica de la base de datos, para prevenir
La pérdida de datos en caso de desastres.
Asegurarse de que haya suficiente espacio libre en disco para las operaciones
normales y aumentar el espacio en disco según sea necesario.
Supervisión de los trabajos que se ejecuten en la base de datos.
Teoría de Bases de Datos II 47 UCENM
DEFINICIÓN DE TRANSACIONES
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 dependían de la
consistencia de la información almacenada.
Las transacciones son mecanismos que ayudan a simplificar la construcción de
sistemas confiables mediante procesos que proporcionan soporte uniforme
para invocar y sincronizar operaciones como:
Operaciones de comparación de datos
Aseguramiento de la seriabilidad de las transacciones con otras
Atomicidad en su comportamiento
Recuperación de fallas
La palabra transacción describe una secuencia de operaciones con uno o más
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 transacción puede terminar, haciendo sus cambios
persistentes, o abortar voluntaria o involuntariamente.
Dentro del área de los sistemas computacionales el concepto de transacciones
fue inicialmente utilizado para definir la consistencia entre múltiples usuarios en
una base de datos. Una transacción es una colección 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 actualización, inserción y eliminación
de la información. Se quiere asegurar que la base de datos no entre en un
estado de inconsistencia, pero durante la ejecución de una transacción, 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 ejecución de una transacción (Figura A)
Teoría de Bases de Datos II 48 UCENM
Figura A . Un modelo de transacción.
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.
Comentario sobre el modelo
Una transacción es una acción atómica, siendo una unidad de control de
concurrencia y de recuperación. Las transacciones se mantienen consistentes
solo si se efectúa a partir de un estado consistente. Las transacciones
simplifican el modelo computacional dado que proveen:
Transparencia de concurrencia:
Habilita a diversos procesos para que operenconcurrentementeusando
recursos compartidos sin interferencia entre ellos
Transparencia de fallas:
Permite el encubrimiento de fallos, permitiendo a usuarios y programas
de aplicación culminar sus tareas a pesar de las fallas de componentes
hardware o software
Teoría de Bases de Datos II 49 UCENM
INSTRUCCIONES PARA EL USO DE TRANSACIONES
La programación 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 _TRANSACCIÓN:
Los comandos siguientes forman una transacción
END _ TRANSACCIÓN:
Termina la transacción y se intenta un compromiso
ABORT_ TRANSACCIÓN:
Se elimina la transacción, 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 forman el cuerpo de la transacción 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.
TÉCNICAS DE IMPLANTACIÓN DE TRANSACCIONES
> Área de trabajo privada
> Bitácora de escritura anticipada
> Protocolo de compromiso de dos fases (two-phase)
Área de trabajo privada:
Consiste en realizar copias de los bloques que serán utilizados dentro de una
transacción de manera que se trabaje con estas copias para realizar todas las
modificaciones necesarias. Todo el espacio de trabajo con la información que
Teoría de Bases de Datos II 50 UCENM
será utilizada es contenido dentro de estas copias denominado área de trabajo
privada. Los demás usuarios trabajaran con la copia original de los bloques
pero no podrán obtener una segunda copia de los mismos.
Al iniciarse la transacción el proceso obtiene una copia privada de los datos.
Lecturas y escrituras sobre la zona privada. Para optimizar solo se crean
copias privadas de los datos modificados. Una segunda optimización para los
datos que están organizados en bloques apuntados desde un índice, como los
ficheros, es crear copias solo de los fragmentos modificados.
Bitácora de escritura anticipada:
Este método consiste en realizar una copia con todas las transacciones que
van siendo ejecutadas hacia un bloque o espacio (LOG) de trabajo que sea
estable, esta lista se la conoce como lista de intenciones.
Las transacciones serán actualizadas con la información una vez que se ha
determinado el fin de la transacción.
Se modifican los datos pero antes se escribe en un log sobre memoria estable
la descripción de la operación. En el log también se escriben registros para
indicar el inicio y fin de la transacción, cuando se aborta la transacción se
recorre el log para deshacer los cambios. Después de una caída temporal, se
debe recorrer el log. Si una transacción no ha escrito su registro de fin se
aborta, si lo ha escrito, se hacen los cambios pendientes. Para evitar recorrer
todo el log después de un fallo temporal de la maquina, se usan generalmente
checkpoints.
Protocolo de compromiso de dos fases:
En un sistema distribuido una transacción puede afectar a varios procesadores
lo cual dificulta la atomicidad. La solución más típica es el protocolo de
compromiso de dos fases (C2F). En este protocolo existe un coordinador que
normalmente es el proceso que inicio la transacción.
Teoría de Bases de Datos II 51 UCENM
Fase 1: El coordinador escribe en el log almacenado en memoria
estable el registro (preparar T). Manda un mensaje con ese contenido a
los nodos implicados en la transacción. Cada proceso implicado decide
si está listo para hacer el compromiso, escribe en su log la decisión (listo
T o no listo T) y la manda en un mensaje al coordinador.
Fase 2: Si el coordinador recibe alguna respuesta negativa u obtiene
alguna falla de respuesta decide abortar la transacción. En caso
contrario decide realizar el compromiso.
El coordinador escribe en el log la decisión y manda un mensaje a los
procesos implicados. Cada proceso que recibe el mensaje escribe en su
log la decisión del coordinador y realiza la acción correspondiente.
La terminación de una transacción se hace mediante la regla del compromiso
global. El coordinador aborta una transacción si y solo si al menos un proceso
implicado decide abortar. El coordinador hace un compromiso de la transacción
si y solo si todos los participantes deciden realizar el compromiso.
Comportamiento ante un fallo de un nodo:
El nodo N se recupera después de una caída transitoria y detecta que la
transacción T estaba a medias. Si el log contiene (compromiso T) se realiza la
transacción. Si contiene (abort T) se aborta la transacción, si contiene (listo T)
debe consultar al coordinador para determinar si se compromete o aborta la
transacción, si no hay mensajes en el log se aborta.
Comportamiento ante fallos del coordinador:
Cada nodo implicado N debe decidir sobre la transacción T. Si el log contiene
(compromiso T) se realiza la transacción. Si contiene (abort T) se aborta, si no
contiene (listoT) el coordinador no ha podido decidir el compromiso, por lo
tanto, lo más apropiado es abortar la transacción.
Teoría de Bases de Datos II 52 UCENM
Si todos los nodos tienen (listo T) pero ninguno tiene (compromiso T) o (abort
T) no se puede determinar la decisión del coordinador. Se debería esperar que
se recuperase.
ESTRUCTURA DE LAS TRANSACCIONES
La estructura de una transacción usualmente viene dada según el modelo de la
transacción, estas pueden ser planas (simples) o anidadas.
Transacciones planas:
Consisten en una secuencia de operaciones primitivas encerradas entre las
palabras clave BEGIN y END. Por ejemplo:
BEGIN _TRANSACTION Reservación
....
END.
Transacciones Anidadas:
Consiste en tener transacciones que dependen de otras, estas transacciones
están incluidas dentro de otras de un nivel superior y se las conoce como
subtransacciones. La transacción de nivel superior puede producir hijos
(subtransacciones) que hagan más fácil la programación del sistema y mejoras
del desempeño.
En las transacciones anidadas las operaciones de una transacción pueden ser
así mismo otras transacciones. Por ejemplo:
BEGIN _TRANSACTION Reservación
..........
BEGIN _TRANSACTION Vuelo
........
Teoría de Bases de Datos II 53 UCENM
END.( Vuelo )
......
BEGIN _TRANSACTION Hotel
........
END
......
END.
Una transacción anidada dentro de otra conserva las mismas propiedades que
las de su padre, 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. El compromiso
de una subtransaccion es condicional al compromiso de su padre, si el padre
de una o varias subtransacciones aborta, las subtransacciones hijas también
serán abortadas. Las transacciones anidadas brindan un nivel más alto de
concurrencia entre transacciones.
Ya que una transacción consiste de varias transacciones es posible tener
mayor concurrencia dentro de una sola transacción.
Así también, es posible recuperarse de de fallas de forma independiente de
cada subtransaccion. Esto limita el daño a una parte más pequeña de la
transacción, haciendo que el costo de la recuperación sea el menor.
También se deben considerar 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 .Por el
contrario, si se restringe o impone que un dato debe 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 aun más la restricción de que cada par < read,
write > tiene que ser ejecutado de manera atómica.
Teoría de Bases de Datos II 54 UCENM
PROCESAMIENTO DE TRANSACCIONES
Los siguientes son los aspectos más 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 transacción pretende hacer un compromiso.
Protocolos de confiabilidad
En transacciones distribuidas es necesario introducir medios de comunicación
entre los diferentes nodos de una red para garantizar la atomicidad de las
transacciones.
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.
Protocolos de control de replicas
Se refiere a cómo garantizar la consistencia mutua de datos replicados.
El procesamiento de transacciones básicamente 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 terminación que define un bloque entre el conjunto de operaciones que son
realizadas.
Teoría de Bases de Datos II 55 UCENM
Dentro de este proceso en bloque los demás 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:
Ejecución..de..Transacciones..Serializadas
Ejecución de transacciones calendarizadas
Ejecutar transacciones serializadas:
Es un sistema que permite el procesamiento de transacciones en forma
secuencial o serializado dándole una secuencia a cada transacción, este
proceso reduce el rendimiento del sistema, pero tiene como ventaja que el
proceso de sincronización es más sencillo.
Ejecutar transacciones calendarizadas:
Permite el proceso de transacciones asignándoles tiempos de procesamiento el
cual permite incrementar el rendimiento del sistema ya que se ejecuta un
máximo de procesos en forma concurrente y no a través de una serie. La
ventaja es que a un mismo tiempo de reloj se pueden hacer dos operaciones,
aunque el proceso de sincronización es más complicado.
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
también se utilizan protocolos que proporcionen confiabilidad como lo
siguientes:
Atomicidad
Protocolos de recuperación total
Protocolos de compromiso global
El control de las transacciones también requiere de controlar la concurrencia
del acceso y uso hacia el recurso que se está manipulando, ese control de
concurrencia tiene dos objetivos:
Como sincronizar la ejecución concurrente de transacciones
Consistencia intra transacción (Aislamiento)
Teoría de Bases de Datos II 56 UCENM
Para llevar a cabo el control de concurrencia dentro de un proceso de
transacciones se manejan dos modos:
Ejecución centralizada de transacciones (Figura B)
Figura C. Ejecución distribuida de transacciones.
Teoría de Bases de Datos II 57 UCENM
CONDICIONES DE TERMINACION DE UNA TRANSACCION
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
compromiso. Si la transacción se detiene sin terminar su tarea, se dice que la
transacción aborta. Cuando la transacción es abortada, puede ser por distintas
razones relacionadas con la naturaleza de la transacción misma, o por conflicto
con otras transacciones o por fallo de un proceso o computador, entonces su
ejecución es detenida y todas las acciones ejecutadas hasta el momento son
deshechas regresando a la base de datos al estado antes de su ejecución. A
esta operación también se la conoce como rollback.
TRANSACCIONES EN LOS SISTEMAS DE ARCHIVOS DISTRIBUIDOS
Como alternativa a tener clientes que instalen bloqueos individuales, algunos
servidores de archivos soportan acciones atómicas, a menudo llamadas
transacciones. Cuando está disponible esta facilidad, un cliente puede indicarle
al servidor que comience una transacción, seguida por cualquier número de
aperturas y operaciones de archivos, y finalizar con un comando para terminar
la transacción. El servidor debe ser capaz de llevar a cabo todos los
pedidos efectuados de forma atómica (indivisible) sin interferencia de otros
pedidos de clientes. Si el cliente decide abortar la transacción o finalizan sus
temporizadores, todos los archivos son restaurados al estado anterior al
comienzo de la transacción. Una transacción es cualquier operación de E/S
sobre un archivo que modifica el contenido de un archivo existente del mismo.
Esto incluye el agregar datos, cambiar el tamaño y sobrescribir datos
existentes.
En una implementación, junto al archivo de datos existe el denominado
transaction log file que mantiene la descripción de las modificaciones hechas
sobre el archivo de datos y el mantenimiento de este archivo se llama
transaction tracking.
Teoría de Bases de Datos II 58 UCENM
La operación denominada transaction rollback es aquella por la cual las
alteraciones indicadas en el log se deshacen retornando los datos al estado
previo (estado inicial), que se supone consistente.
Dentro de los objetivos de diseño de un sistema de transacciones se tienen:
Minimizar la sobrecarga de los sistemas de archivos, Identificar
automáticamente las inconsistencias de datos. Una vez identificados debe
producirse una operación rollback sin la intervención del usuario. Obviamente
mientras se produce esta operación, debe negarse el acceso a los archivos
potencialmente corruptos. < maximizar la portabilidad.
La clave está en la posibilidad de volver al punto de partida y, si corresponde,
rehacer las operaciones.
Para ello debe disponerse de la siguiente información:
Identificación completa y univoca del archivo de datos.
El modo y los permisos utilizados al abrir el archivo.
La ubicación de los datos modificados.
Una copia de los datos originales.
La descripción de la alteración que tuvo lugar.
Los datos con que se llevo a cabo tal modificación.
Esta información convenientemente organizada, forma el núcleo de los
denominados registros de transacciones, la unidad de datos de datos de los
archivos log
Teoría de Bases de Datos II 59 UCENM
EJEMPLOS DE TIPOS DE TRANSACCIONES en SQL Server
INJ.HN
Introducción
Una transacción es un conjunto de operaciones que van a ser tratadas como
una única unidad.
Estas transacciones deben cumplir 4 propiedades fundamentales comúnmente
conocidas como ACID (atomicidad, coherencia, asilamiento y durabilidad).
La transacción más simple en SQL Server es una única sentencia SQL. Por
ejemplo una sentencia como esta:
UPDATE Products SET UnitPrice=20 WHERE ProductName ='Chai'
Es una transacción. (Como siempre ejemplos de Northwind) Esta es una
transacción 'autocommit', una transacción autocompletada.
Cuando enviamos esta sentencia al SQL Server se escribe en el fichero de
transacciones lo que va a ocurrir y a continuación realiza los cambios
necesarios en la base de datos. Si hay algún tipo de problema al hacer esta
operación el SQL Server puede leer en el fichero de transacciones lo que se
estaba haciendo y si es necesario puede devolver la base de datos al estado
en el que se encontraba antes de recibir la sentencia.
Por supuesto este tipo de transacciones no requieren de nuestra intervención
puesto que el sistema se encarga de todo. Sin embargo si hay que realizar
varias operaciones y queremos que sean tratadas como una unidad tenemos
que crear esas transacciones de manera explícita.
Sentencias para una transacción
Como decíamos una transacción es un conjunto de operaciones tratadas como
una sola. Este conjunto de operaciones debe marcarse como transacción para
que todas las operaciones que la conforman tengan éxito o todas fracasen.
La sentencia que se utiliza para indicar el comienzo de una transacción es
'BEGIN TRAN'. Si alguna de las operaciones de una transacción falla hay que
deshacer la transacción en su totalidad para volver al estado inicial en el que
estaba la base de datos antes de empezar. Esto se consigue con la sentencia
Teoría de Bases de Datos II 60 UCENM
'ROLLBACK TRAN'.
Si todas las operaciones de una transacción se completan con éxito hay que
marcar el fin de una transacción para que la base de datos vuelva a estar en un
estado consistente con la sentencia 'COMMIT TRAN'.
Un ejemplo
Trabajaremos con la base de datos Northwind en nuestros ejemplos. Vamos a
realizar una transacción que modifica el precio de dos productos de la base de
datos.
USE NorthWind
DECLARE @Error int
Declaramos una variable que utilizaremos para almacenar un posible código de
error
BEGIN TRAN
Iniciamos la transacción
UPDATE Products SET UnitPrice=20 WHERE ProductName ='Chai'
Ejecutamos la primera sentencia
SET @Error=@@ERROR
Si ocurre un error almacenamos su código en @Error
y saltamos al trozo de código que deshará la transacción. Sí, eso de
ahí es un
GOTO, el demonio de los programadores, pero no pasa nada por usarlo
Cuando es necesario
IF (@Error<>0) GOTO TratarError
Si la primera sentencia se ejecuta con éxito, pasamos a la segunda
UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'
SET @Error=@@ERROR
Y si hay un error hacemos como antes
IF (@Error<>0) GOTO TratarError
Si llegamos hasta aquí es que los dos UPDATE se han completado con
Éxito y podemos "guardar" la transacción en la base de datos
COMMIT TRAN
Teoría de Bases de Datos II 61 UCENM
TratarError:
Si ha ocurrido algún error llegamos hasta aquí
If @@Error<>0 THEN
BEGIN
PRINT 'Ha ecorrido un error. Abortamos la transacción'
Se lo comunicamos al usuario y deshacemos la transacción
Todo volverá a estar como si nada hubiera ocurrido
ROLLBACK TRAN
END
Como se puede ver para cada sentencia que se ejecuta miramos si se ha
producido o no un error, y si detectamos un error ejecutamos el bloque de
código que deshace la transacción.
Hay una interpretación incorrecta en cuanto al funcionamiento de las
transacciones que está bastante extendida. Mucha gente cree que si tenemos
varias sentencias dentro de una transacción y una de ellas falla, la transacción
se aborta en su totalidad.
Ahora tenemos dos sentencias dentro de una transacción.
USE NorthWind
BEGIN TRAN
UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'
UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'
COMMIT TRAN
Estas dos sentencias se ejecutarán como una sola. Si por ejemplo en medio de
la transacción (después del primer update y antes del segundo) hay un corte de
electricidad, cuando el SQL Server se recupere se encontrará en medio de una
transacción y, o bien la termina o bien la deshace, pero no se quedará a
medias.
Teoría de Bases de Datos II 62 UCENM
El error está en pensar que si la ejecución de la primera sentencia da un error
se cancelará la transacción.
El SQL Server sólo se preocupa de ejecutar las sentencias, no de averiguar si
lo hacen correctamente o si la lógica de la transacción es correcta. Eso es cosa
nuestra.
Por eso en el ejemplo que tenemos más arriba para cada sentencia de nuestro
conjunto averiguamos si se ha producido un error y si es así actuamos en
consecuencia cancelando toda la operación.
Transacciones anidadas
Otra de las posibilidades que nos ofrece el SQL Server es utilizar transacciones
anidadas. Esto quiere decir que podemos tener transacciones dentro de
transacciones, es decir, podemos empezar una nueva transacción sin haber
terminado la anterior.
Asociada a esta idea de anidamiento existe una variable global
@@TRANCOUNT que tiene valor 0 si no existe ningún nivel de anidamiento, 1
si hay una transacción anidada, 2 si estamos en el segundo nivel de
anidamiento. y así sucesivamente.
La dificultad de trabajar con transacciones anidadas está en el comportamiento
que tienen ahora las sentencias 'COMMIT TRAN' y 'ROLLBACK TRAN'
ROLLBACK TRAN: Dentro de una transacción anidada esta sentencia
deshace todas las transacciones internas hasta la instrucción BEGIN
TRANSACTION más externa.
COMMIT TRAN: Dentro de una transacción anidada esta sentencia
únicamente reduce en 1 el valor de @@TRANCOUNT, pero no "finaliza"
ninguna transacción ni "guarda" los cambios. En el caso en el que
@@TRANCOUNT=1 (cuando estamos en la última transacción)
COMMIT TRAN hace que todas las modificaciones efectuadas sobre los
datos desde el inicio de la transacción sean parte permanente de la base
Teoría de Bases de Datos II 63 UCENM
de datos, libera los recursos mantenidos por la conexión y reduce
@@TRANCOUNT a 0.
Como siempre un ejemplo es lo mejor para entender cómo funciona.
CREATE TABLE Test (Columna int)
GO
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (1)
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (2)
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (3)
COMMIT TRAN TranInterna2 -- Reduce @@TRANCOUNT a 2.
Pero no se guarda nada en la base de datos.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 1.
Pero no se guarda nada en la base de datos.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0. Se lleva a cabo
la transacción externa y todo lo que conlleva.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
SELECT * FROM Test
Por cierto que lo de usar nombre para las transacciones es por claridad, puesto
que COMMIT TRAN como ya hemos dicho solamente reduce en 1 el valor de
@@TRANCOUNT.
Veamos ahora un ejemplo de transacción anidada con ROLLBACK TRAN
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1
Teoría de Bases de Datos II 64 UCENM
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (1)
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (2)
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (3)
ROLLBACK TRAN --@@TRANCOUNT es 0 y se deshace
La transacción externa y todas las internas
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
SELECT * FROM Test
En este caso no se inserta nada puesto que el ROLLBACK TRAN deshace
todas las transacciones dentro de nuestro anidamiento hasta la transacción
más externa y además hace @@TRANCOUNT=0
¿Supone este funcionamiento asimétrico del COMMIT y del ROLLBACK un
problema?. La manera de tratar las transacciones por el SQL Server es la que
nos permite programar de manera natural los anidamientos. De todos modos, si
queremos ir un poco más lejos hay una cuarta sentencia para trabajar con
transacciones: SAVE TRAN
Save Tran
Esta sentencia crea un punto de almacenamiento dentro de una transacción.
Esta marca sirve para deshacer una transacción en curso sólo hasta ese punto.
Por supuesto nuestra transacción debe continuar y terminar con un COMMIN
TRAN (o los que hagan falta) para que todo se guarde o con un ROLLBACK
TRAN para volver al estado previo al primer BEGIN TRAN.
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (1)
Teoría de Bases de Datos II 65 UCENM
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (2)
SAVE TRAN Guadada
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (3)
ROLLBACK TRAN Guadada -- se deshace lo hecho el punto guardado.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
Ahora podemos decidir si la transacción se lleva a cabo
o se deshace completamente
Para deshacerla un ROLLBACK bastará como hemos visto
Pero para guardar la transacción hace falta reducir @@TRANCOUNT a 0
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 1.
Pero no se guarda nada en la base de datos.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0.
Se lleva a cabo la transacción externa y todo lo que conlleva.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
SELECT * FROM Test
Si no ponemos el nombre del punto salvado con SAVE TRAN al hacer un
ROLLBACK TRAN se deshace la transacción más externa y @@TRANCOUNT
se pone a 0.
Como podemos ver el uso de transacciones no es complicado, e incluso las
transacciones anidadas si se tratan con cuidado son fáciles de manejar.
Un par de ejemplos más
Teoría de Bases de Datos II 66 UCENM
Veamos otro par de ejemplos para dejar claro como funcionan las sentencias
BEGIN, COMMIT y SAVE
BEGIN TRAN
Primer BEGIN TRAN y ahora @@TRANCOUNT = 1
BEGIN TRAN
Ahora @@TRANCOUNT = 2
COMMIT TRAN
Volvemos a @@TRANCOUNT = 1
Pero no se guarda nada ni se hacen efectivos los posibles cambios
COMMIT TRAN
Por fin @@TRANCOUNT = 0
Si hubiera cambios pendientes se llevan a la base de datos
Y volvemos a un estado normal con la transacción acabada
Uso del COMMIT
BEGIN TRAN
Primer BEGIN TRAN y @@TRANCOUNT = 1
BEGIN TRAN
Ahora @@TRANCOUNT = 2
COMMIT TRAN
Como antes @@TRANCOUNT = 1
Y como antes nada se guarda
ROLLBACK TRAN
Se cancela TODA la transacción. Recordemos que el COMMIT
de antes no guardo nada, solo redujo @@TRANCOUNT
Ahora @@TRANCOUNT = 0
COMMIT TRAN
No vale para nada porque @@TRANCOUNT es 0 por el efecto del
ROLLBACK
Uso del ROLLBACK
Teoría de Bases de Datos II 67 UCENM
En cuanto al SAVE TRAN podemos recordarlo con el siguiente ejemplo:
CREATE TABLE Tabla1 (Columna1 varchar(50))
GO
BEGIN TRAN
INSERT INTO Tabla1 VALUES ('Primer valor')
SAVE TRAN Punto1
INSERT INTO Tabla1 VALUES ('Segundo valor')
ROLLBACK TRAN Punto1
INSERT INTO Tabla1 VALUES ('Tercer valor')
COMMIT TRAN
SELECT * FROM Tabla1
Columna1
--------------------------------------------------
Primer valor
Tercer valor
(2 filas afectadas)
Un ROLLBACK a un SAVE TRAN no deshace la transacción en curso ni
modifica @@TRANCOUNT, simplemente cancela lo ocurrido desde el 'SAVE
TRAN nombre' hasta su 'ROLLBACK TRAN nombre'
Transacciones y procedimientos almacenados.
Cuando trabajamos con procedimientos almacenados debemos recordar que
cada procedimiento almacenado es una unidad. Cuando se ejecuta lo hace de
manera independiente de quien lo llama. Sin embargo si tenemos un
ROLLBACK TRAN dentro de un procedimiento almacenado cancelaremos la
transacción en curso, pero si hay una transacción externa al procedimiento en
el que estamos trabajando se cancelará esa transacción externa.
Teoría de Bases de Datos II 68 UCENM
Con esto no quiero decir que no se pueda usar, simplemente que hay que tener
muy claras las 4 normas sobre las sentencias BEGIN, ROLLBACK y COMMIT
que comentamos al principio de este artículo. Veamos cómo se comporta una
transacción en un procedimiento almacenado llamado desde una transacción.
CREATE PROCEDURE Inserta2
AS
BEGIN TRAN --Uno
INSERT INTO Tabla1 VALUES ('Valor2')
ROLLBACK TRAN --Uno
GO
CREATE PROCEDURE Inserta1
AS
BEGIN TRAN --Dos
INSERT INTO Tabla1 VALUES ('Valor 1')
EXEC Inserta2
INSERT INTO Tabla1 VALUES ('Valor3')
COMMIT TRAN --Dos
GO
En principio parece que si ejecutamos el procedimiento 'Inserta1' el resultado
sería:
EXECUTE inserta1
SELECT * FROM tabla1
txt
--------------------------------------------------
Valor1
Valor3
(2 filas afectadas)
Pero lo que obtenemos es:
Teoría de Bases de Datos II 69 UCENM
EXECUTE inserta1
SELECT * FROM tabla1
(1 filas afectadas)
(1 filas afectadas)
Servidor: mensaje 266, nivel 16, estado 2, procedimiento Inserta2, línea 8
El recuento de transacciones después de EXECUTE
Indica que falta una instrucción COMMIT o ROLLBACK
TRANSACTION.
Recuento anterior = 1, recuento actual = 0.
(1 filas afectadas)
Servidor: mensaje 3902, nivel 16, estado 1, procedimiento Inserta1, línea 8
La petición COMMIT TRANSACTION no tiene la correspondiente BEGIN
TRANSACTION.
txt
--------------------------------------------------
Valor3
(1 filas afectadas)
Si analizamos estos mensajes vemos que se inserta la primera fila, se salta al
segundo procedimiento almacenado y se inserta la segunda fila. Se ejecuta el
'ROLLBACK TRAN -Dos' del segundo procedimiento almacenado y se
deshacen las dos inserciones porque este ROLLBACK cancela la transacción
exterior, la del primer procedimiento almacenado. A continuación se termina el
segundo procedimiento almacenado y como este procedimiento tiene un
'BEGIN TRAN -Dos' y no tiene un COMMIT o un ROLLBACK (recordemos que
el 'ROLLBACK TRAN -Dos' termina el 'BEGIN TRAN -Uno') se produce un error
y nos avisa que el procedimiento almacenado termina con una transacción
pendiente. Al volver al procedimiento almacenado externo se ejecuta el
INSERT que inserta la tercera fila y a continuación el 'COMMIT TRAN --Uno'.
Aquí aparece otro error puesto que este 'COMMIT TRAN -Uno' estaba ahí para
finalizar una transacción que ya ha sido cancelada anteriormente.
Teoría de Bases de Datos II 70 UCENM
El modo correcto
Para que nuestras transacciones se comporten como se espera dentro de un
procedimiento almacenado podemos recurrir al SAVE TRAN.
Veamos como:
CREATE PROCEDURE Inserta2
AS
SAVE TRAN Guardado
INSERT INTO Tabla1 VALUES ('Valor2')
ROLLBACK TRAN Guardado
GO
CREATE PROCEDURE Inserta1
AS
BEGIN TRAN
INSERT INTO Tabla1 VALUES ('Valor 1')
EXEC Inserta2
INSERT INTO Tabla1 VALUES ('Valor 3')
COMMIT TRAN
GO
Ahora el 'ROLLBACK TRAN guardado' del segundo procedimiento almacenado
deshace la transacción sólo hasta el punto guardado. Además este ROLLBACK no
decrementa el @@TRANCOUNT ni afecta a las transacciones en curso.
El resultado obtenido al ejecutar este procedimiento almacenado es:
EXECUTE inserta1
SELECT * FROM tabla1
(1 filas afectadas)
(1 filas afectadas)
(1 filas afectadas)
txt
Valor 1
Teoría de Bases de Datos II 71 UCENM
Valor 3
(2 filas afectadas)
Una vez vistos estos ejemplos queda claro que no hay problema en utilizar
transacciones dentro de procedimientos almacenados siempre que tengamos
en cuenta el comportamiento del ROLLBACK TRAN y que utilicemos el SAVE
TRAN de manera adecuada
CUESTIONARIO
1-. ¿ Que compendio por transacciones en base de datos?
2-. ¿Cuál es el conjunto de acciones deben constituir una transacción?
3-. Enumere cuales son las propiedades de la transacciones.
4-.¿Que es la gestión y administración de base de datos?
Teoría de Bases de Datos II 72 UCENM
5-. ¿Cuáles son las instrucciones para el uso de transacciones?
6-. Elabore un explicación de las TÉCNICAS DE IMPLANTACIÓN DE
TRANSACCIONES.
7-.¿Que es un protoloco de compromiso de dos fases?
8-.¿Que tipo de estructura existen indíquelas?
9-.¿Que entiende por transacciones en sistemas de archivos distribuidos?
10-.¿Que son las Transacciones y procedimientos almacenados?
Teoría de Bases de Datos II 73 UCENM
CONCURRENCIA
Objetivos del capítulo III
1. Comprender y analizar el concepto de concurrencia.
2. Conocer los conceptos de los principales algoritmos.
1. Conocer la concurrencia en sistema archivo.
2. Comprender el concepto de abrazos mortales.
3. Comprender ejemplos de concurrencia.
Teoría de Bases de Datos II 74 UCENM
EL CONTROL DE CONCURRENCIA EN EL MODELO
TRANSACCIONAL
Los bloqueos se pueden definir formalmente como sigue: "Un conjunto de
procesos se bloquean si cada proceso del conjunto está esperando un evento
que solo otro proceso del conjunto puede provocar". Puesto que todos los
procesos están en espera, ninguno de ellos podrá ocasionar nunca ninguno de
los eventos que podría desbloquear a algunos de los otros miembros del
conjunto y los demás procesos seguirán esperando indefinidamente
El control de concurrencia trata sobre los problemas de aislamiento y
consistencia del procesamiento de transacciones.
El control de concurrencia distribuido en sistema de manejo de bases de datos
distribuidas 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 enormemente el desempeño de un sistema de
manejo de bases de datos distribuidas 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. 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.
El fallo en diseño de mecanismos apropiados de sincronización y en obligar su
uso por cada proceso que utiliza recursos comunes, produce frecuentemente
un comportamiento erróneo del sistema y rupturas que son notablemente
difíciles de depurar.
La concurrencia puede producir un incremento de la productividad cuando se
implementan correctamente, pero puede también degradar la fiabilidad cuando
Teoría de Bases de Datos II 75 UCENM
la sincronización impropia entre procesos contamina el sistema con errores
artificios de tiempo.Si no se lleva a cabo un adecuado control de concurrencia,
se podrían llegar a 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 lugar, pueden presentarse recuperaciones de información
inconsistentes.
Los algoritmos para el control de concurrencia son útiles cuando se ejecutan
varias transacciones al mismo tiempo
Los principales algoritmos son:
Los de cerradura o basados en candados
El de control optimista de la concurrencia
El de las marcas de tiempo
El conjunto de algoritmos pesimistas está formado por algoritmos basados en
candados, algoritmos basados en ordenamiento por estampas de tiempo y
algoritmos híbridos. Los algoritmos optimistas se componen por los algoritmos
basados en candados y algoritmos basados en estampas de tiempo. (Figura D)
Figura D. Clasificación de los algoritmos de control de concurrencia.
Teoría de Bases de Datos II 76 UCENM
ALGORITMOS DE CERRADURA O BASADOS EN CANDADOS
En los algoritmos basados en candados, las transacciones indican sus
intenciones solicitando candados al despachador (llamado el administrador de
candados) Los candados son de lectura, también llamados compartidos, o de
escritura, también llamados exclusivos.
En sistemas basados en candados, el despachador es un administrador de
candados. El administrador de transacciones le pasa al administrador de
candados la operación sobre la base de datos (lectura o escritura) e
información asociada, como por ejemplo el elemento de datos que es accesado
y el identificador de la transacción que está enviando la operación a la base de
datos.
El administrador de candados verifica si el elemento de datos que se quiere
accesar ya ha sido bloqueado por un candado. Si el candado solicitado es
incompatible con el candado con que el dato está bloqueado, entonces, la
transacción solicitante es retrasada. De otra forma, el candado se define sobre
el dato en el modo deseado y la operación a la base de datos es transferida al
procesador de datos.
El administrador de transacciones es informado luego sobre el resultado de la
operación. La terminación de una transacción libera todos los candados y se
puede iniciar otra transacción que estaba esperando el acceso al mismo dato.
Se usan cerraduras o candados de lectura o escritura sobre los datos.
Para asegurar la secuencialidad se usa un protocolo de dos fases, en la fase
de crecimiento de la transacción se establecen los cerrojos y en la fase de
decrecimiento se liberan los cerrojos. Hay que tener en cuenta que se pueden
producir interbloqueos.
Teoría de Bases de Datos II 77 UCENM
En los sistemas distribuidos el nodo que mantiene un dato se encarga
normalmente de gestionar los cerrojos sobre el mismo.
Candados de dos fases:
En los candados de dos fases una transacción le pone un candado a un objeto
antes de usarlo. Cuando un objeto es bloqueado con un candado por otra
transacción, la transacción solicitante debe esperar. Cuando una transacción
libera un candado, ya no puede solicitar más candados. En la primera fase
solicita y adquiere todos los candados sobre los elementos que va a utilizar y
en la segunda fase libera los candados obtenidos uno por uno.
Puede suceder que si una transacción aborta después de liberar un candado,
otras transacciones que hayan accesado el mismo elemento de datos aborten
también provocando lo que se conoce como abortos en cascada.
Para evitar lo anterior, los despachadores para candados de dos fases
implementan lo que se conoce como los candados estrictos de dos fases en los
cuales se liberan todos los candados juntos cuando la transacción termina (con
compromiso o aborta).
Candados de dos fases centralizados:
En sistemas distribuidos puede que la administración 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.
La comunicación se presenta entre el administrador de transacciones del nodo
en donde se origina la transacción, el administrador de candados en el nodo
central y los procesadores de datos de todos los nodos participantes. Los
nodos participantes son todos aquellos en donde la operación se va a llevar a
cabo.
Teoría de Bases de Datos II 78 UCENM
Figura E. Comunicación en un administrador centralizado de candados de dos
fases.
La crítica más fuerte a los algoritmos centralizados es el "cuello de botella" que
se forma alrededor del nodo central reduciendo los tiempos de respuesta de
todo el sistema. Su disponibilidad es reducida a cero cuando se presentan
fallas en el nodo central.
Candados de dos fases distribuidos:
En los candados de dos fases distribuidos se presentan despachadores en
cada nodo del sistema. Cada despachador maneja las solicitudes de candados
para los datos en ese nodo. Una transacción puede leer cualquiera de las
copias replicada del elemento x, obteniendo un candado de lectura en
cualquiera de las copias de x. La escritura sobre x requiere que se obtengan
candados para todas las copias de x. Los mensajes de solicitud de candados
se envían a todos los administradores de candados que participan en el
sistema. Las operaciones son pasadas a los procesadores de datos por los
administradores de candados. Los procesadores de datos envían su mensaje
de "fin de operación" al administrador de transacciones coordinador
Teoría de Bases de Datos II 79 UCENM
Figura F. Comunicación en candados de dos fases distribuidos
CONTROL OPTIMISTA DE LA CONCURRENCIA
Los algoritmos de control de concurrencia pesimistas asumen que los conflictos
entre transacciones son muy frecuentes y no permiten el acceso a un dato si
existe una transacción conflictiva que accesa el mismo dato. Así, la ejecución
de cualquier operación de una transacción sigue la secuencia de fases:
validación, lectura, cómputo y escritura (ver Figura G, sigte pag).
Los algoritmos optimistas, por otra parte, retrasan la fase de validación justo
antes de la fase de escritura (ver Figura G, sigte pag). De esta manera, una
operación sometida a un despachador optimista nunca es retrasada.
Teoría de Bases de Datos II 80 UCENM
Las operaciones de lectura, cómputo y escritura de cada transacción se
procesan libremente sin actualizar la base de datos corriente. Cada transacción
inicialmente hace sus cambios en copias locales de los datos.
La fase de validación consiste en verificar si esas actualizaciones conservan la
consistencia de la base de datos. Si la respuesta es positiva, los cambios se
hacen globales (escritos en la base de datos corriente). De otra manera, la
transacción es abortada y tiene que reiniciar
Lo que se hace es dejar ejecutar las transacciones y si al terminar se detecta
que ha habido conflicto se aborta y se reinicia la transacción.
Cada transacción tiene tres fases:.
Fase de lectura:
Cuerpo de la transacción donde se copian datos desde la base de datos,
copias que pueden ser actualizadas pero sin copiar a la base de datos
Fase de validación:
Se comprueba que no existan conflictos
Fase de escritura:
Si no existen conflictos se instalan lo cambios en la base de datos
Conflictos entre operaciones:
Dos operaciones están en conflicto entre sí cuando, operan sobre los mismos
datos, una de las operaciones es de escritura, o cada operación pertenece a
diferentes transacciones.
Figura G. Fases de la ejecución de una transacción a) pesimista, b) optimista
Teoría de Bases de Datos II 81 UCENM
ALGORITMOS BASADOS EN MARCAS DE TIEMPO
A diferencia de los algoritmos basados en candados, los algoritmos basados en
marcas de tiempo no pretenden mantener la seriabilidad por la exclusión
mutua. En su lugar eligen un orden de socialización en primera instancia y
ejecutan las transacciones de acuerdo a ese orden.
En estos algoritmos cada transacción lleva asociada una marca de tiempo.
Cada dato lleva asociado dos marcas de tiempo: uno de lectura y otro de
escritura, que reflejan la marca de tiempo de la transacción que hizo la última
operación de ese tipo sobre el dato.
Para leer la marca de tiempo de escritura del dato, debe ser menor que el de la
transacción, si no aborta. Para escribir las marcas de tiempo de escritura y
lectura del dato, deben ser menores que el de la transacción, sino se aborta.
Esta técnica está libre de Interbloqueos pero puede darse que halla que repetir
varias veces la transacción. En los sistemas distribuidos se puede usar un
mecanismo como, los relojes de Lamport para asignar marcas de tiempo.
CONTROL DE CONCURRENCIA EN SISTEMAS DE ARCHIVOS
DISTRIBUIDOS
Hasta aquí se ha hablado sobre el modelo transaccional haciendo hincapié en
lo referido a base de datos distribuidas. En adelante se desarrollara como se
emplea el control de concurrencia en sistemas distribuidos de archivos
Los sistemas de archivos que forman parte de una red de computadoras tienen
múltiples clientes de los que encargarse. Si dos o más clientes,
accidentalmente o no, deciden acceder al mismo archivo al mismo tiempo
pueden producirse conflictos. La solución utilizada es permitir a los usuarios el
uso de bloqueos sobre los archivos de trabajo.
Teoría de Bases de Datos II 82 UCENM
La idea es sencilla, mientras un usuario está trabajando sobre una parte de los
datos, otros no podrán hacerlo de manera que las distintas actualizaciones se
efectuaran en forma sucesiva y ordenada sin interferencias. Se utilizan dos
clases de bloqueos: Los bloqueos compartidos que por lo general se usan para
lectura, y los bloqueos exclusivos que normalmente se usan para escritura.
La granularidad del bloqueo es otra consideración importante. Es posible
bloquear archivos enteros, pero también es posible bloquear archivos enteros o
subárboles, cuanto menor sea la unidad lógica bloqueada mayor será la
concurrencia admisible.
El concepto de bloqueo introduce varios problemas de contrapartida. Primero,
si un cliente necesita acceder a varios archivos, como ocurre de forma común
cuando se efectúan transferencias de dinero en aplicaciones bancarias, hay
una posibilidad de abrazo mortal.
Abrazos mortales:
Principalmente, existen dos métodos para manejar el problema de los abrazos
mortales. Podemos usar algún protocolo para asegurar que el sistema nunca
entrará en un estado de abrazo mortal. Alternativamente, podemos permitir que
el sistema entre en un estado de abrazo mortal y después recuperarnos.
El recuperarse de un abrazo mortal puede ser muy difícil y muy caro. Por ello,
primeramente consideraremos los métodos para asegurar que no ocurran los
abrazos mortales. Comúnmente, existen dos métodos:
El de PREVENCIÓN de abrazos mortales
LA EVASIÓN de abrazos mortales.
Teoría de Bases de Datos II 83 UCENM
PREVENCIÓN de abrazos mortales.
Un conjunto de procesos está en un abrazo mortal cuando todos los procesos
en ese conjunto están esperando un evento que sólo puede ser causado por
otro proceso en el conjunto.
Los eventos a los cuales nos estamos refiriendo son
concernientes con la asignación y liberación de recursos principalmente. Sin
embargo, pueden llevara la existencia de abrazos mortales.
Para ejemplificar un estado de abrazo mortal, se considerara un sistema con
tres unidades de disco. Supongamos que existen tres procesos, cada uno de
ellos tiene asignada una de las unidades de disco. Si ahora cada proceso pide
otra unidad de disco, los tres procesos se encuentran ahora en un estado de
abrazo mortal. Cada uno está esperando el evento "unidad de disco liberada",
lo cual solo puede ser causada por alguno de los otros procesos en espera.
Este ejemplo ilustra un abrazo mortal involucrando procesos compitiendo por el
mismo tipo de recurso. Los abrazos mortales pueden también involucrar
diferentes tipos de recursos.
Por ejemplo, consideremos un sistema con una impresora y una unidad de
disco. Supongamos que el proceso A tiene asignada la unidad de disco y que
el proceso B tiene asignada la impresora. Ahora, si A pide la impresora y B pide
la unidad de disco, ocurre un abrazo mortal.
Ejemplo de un abrazo mortal.
Teoría de Bases de Datos II 84 UCENM
Es obvio que un abrazo mortal es una condición indeseable. En un abrazo
mortal, los procesos nunca terminan de ejecutarse y los recursos del sistema
están amarrados, evitando que otros procesos puedan siquiera empezar.
Condiciones Necesarias. Una situación de abrazo mortal puede surgir sí y solo
sí las siguientes cuatro condiciones ocurren simultáneamente en un sistema:
Exclusión Mutua. Cada recurso se asigna por lo regular exactamente a un
proceso o bien está disponible. Al menos un recurso es mantenido en un modo
no-compartible; esto es, sólo un proceso a la vez puede usar el recurso. Si otro
proceso solicita ese recurso, tiene que ser retardado hasta que el recurso haya
sido liberado.
Retener y Esperar. Los procesos que regularmente contienen recursos
otorgados antes pueden solicitar nuevos recursos. Debe existir un proceso que
retenga al menos un recurso y esté esperando para adquirir recursos
adicionales que están siendo retenidos por otros procesos.
No existe el derecho de desasignar : Los recursos previamente otorgados no
pueden extraerse por la fuerza de un proceso. Deben ser liberados
explícitamente por el proceso que los contiene. Los recursos no pueden ser
desasignados ; esto es, un recurso sólo puede ser liberado voluntariamente por
el proceso que lo retiene, después de que el proceso ha terminado su tarea.
Espera Circular. Debe haber una cadena de dos o más procesos, cada uno de
los cuales esté esperando un recurso contenido en el siguiente miembro de la
cadena. Debe existir un conjunto {p0, p1, ...,pn} de procesos en espera tal que
p0 esté esperando por un recurso que está siendo retenido por p1, p1 está
esperando por un recurso que está siendo retenido por p2, ..., pn-1 está
esperando por un recurso que está siendo retenido por pn y pn está esperando
por un recurso que está siendo retenido por p0.
Teoría de Bases de Datos II 85 UCENM
Se remarca que las cuatro condiciones deben de cumplirse para que pueda
ocurrir un abrazo mortal. La condición de espera circular implica la condición de
retener y esperar, de tal manera que las cuatro condiciones no son totalmente
independientes. Sin embargo, puede ser útil el considerar cada condición por
separado.
Una forma de modelar estas condiciones es usando un grafo de recursos:
Los círculos representan procesos.
Los cuadrados recursos.
Una arista desde un recurso a un proceso indica que el recurso ha sido
asignado al proceso. Una arista desde un proceso a un recurso indica que el
proceso ha solicitado el recurso, y está bloqueado esperándolo. Entonces, si
hacemos el grafo con todos los procesos y todos los recursos del sistema y
encontramos un ciclo, los procesos en el ciclo están bajo bloqueo mutuo.
Ejemplo de un grafo de recursos.
Teoría de Bases de Datos II 86 UCENM
La discusión del control de concurrencia hasta aquí se ha centralizado
alrededor del problema de qué hacer cuando múltiples usuarios quieren
actualizar el mismo archivo. Una manera completamente diferente es prevenir
todas las actualizaciones.
Desde este punto de vista, los archivos son inmutables; una vez que se crea un
archivo no puede modificarse. En este caso, para incorporar nueva información
en el archivo, un cliente puede crear una nueva versión del archivo que
reemplaza (pero no modifica) el original. De esta manera, un archivo se vuelve
una secuencia de versiones inmutables.
La sincronización entre procesos es necesaria para prevenir y corregir errores
de sincronización debidos al acceso concurrente de recursos compartidos,
tales como estructuras de datos o dispositivos de E/S, de procesos
contendientes.
La sincronización entre procesos también permite intercambiar señales de
tiempo entre procesos cooperantes para garantizar las relaciones específicas
de precedencia impuestas por el problema que se resuelva.
Sin una sincronización adecuada entre procesos, la actualización entre
variables compartidas puede inducir a errores de tiempo relacionadas con la
concurrencia que son con frecuencia difíciles de depurar.
Una de las causas principales de este problema es que procesos concurrentes
puedan tener valores temporalmente inconsistentes de una variable compartida
mientras se actualizan.
Los semáforos son un mecanismo sencillo pero poderoso de sincronización
entre procesos. Los semáforos satisfacen la mayoría de los requerimientos que
hemos especificado para un buen mecanismo de control de concurrencia, sin
incluir suposiciones sobre las velocidades y prioridades relativas de los
procesos contendientes y sin saber nada sobre los otros contendientes excepto
que existen probablemente.
Teoría de Bases de Datos II 87 UCENM
Mediante el uso de semáforos se pueden resolver algunos problemas bien
conocidos de sincronización, como los de PRODUCTOR/CONSUMIDOR y
LECTORES/ESCRITORES.
Sincronización entre procesos
La ejecución concurrente de procesos, puede producir mejoras significativas de
rendimiento respecto a la ejecución secuencial de programas. Cuando es
crítico el rendimiento, se puede dividir el trabajo en varios procesos
cooperantes definidos por el programador para explotar la posible concurrencia
de un programa o aplicación dada. Sin embargo, para que funcione
apropiadamente un grupo de procesos, se deben sincronizar sus actividades
de forma que asegure la observancia de las relaciones de precedencia dictadas
por el problema que se está resolviendo.
La sincronización entre procesos es necesaria para preservar la integridad del
sistema y prevenir problemas de tiempo producidos por el acceso concurrente
a recursos compartidos por múltiples procesos.
En general, los procesos cooperantes deben sincronizarse siempre que
intenten usar recursos compartidos por varios de ellos, tales como estructuras
de datos o dispositivos físicos comunes. El fallo en diseño de protocolos
apropiados de sincronización y en obligar su uso por cada proceso que utiliza
recursos comunes, produce frecuentemente un comportamiento erróneo del
sistema y rupturas que son notablemente difíciles de depurar.
La concurrencia puede producir un incremento de la productividad cuando se
implementan correctamente, pero puede también degradar la fiabilidad cuando
la sincronización impropia entre procesos contamina el sistema con errores
artificios de tiempo.
Teoría de Bases de Datos II 88 UCENM
Introducción a la concurrencia de datos en ADO.NET
Cuando varios usuarios intentan modificar datos al mismo tiempo, es necesario
establecer controles para impedir que las modificaciones de un usuario influyan
negativamente en las de otros. El sistema mediante el cual se controla lo que
sucede en esta situación se denomina control de concurrencia.
Tipos de control de concurrencia
En general, existen tres formas comunes para administrar la concurrencia en
una base de datos:
Control de concurrencia pesimista:
Una fila no está disponible para los usuarios desde el momento en que
se obtiene el registro hasta que se actualiza en la base de datos.
Control de concurrencia optimista:
Una fila no está disponible para otros usuarios mientras los datos se
estén actualizando. La actualización examina la fila de la base de datos
y determina si se han realizado cambios. Si se intenta actualizar un
registro que ya se ha modificado, se produce una infracción de
concurrencia.
"El último gana":
Una fila no está disponible para otros usuarios mientras los datos se
estén actualizando. Sin embargo, no se intenta comparar las
actualizaciones con el registro original; simplemente, el registro se
escribe, con la posibilidad de sobrescribir los cambios realizados por
otros usuarios desde la última vez que se actualizaron los registros.
Teoría de Bases de Datos II 89 UCENM
Concurrencia pesimista
Normalmente, la concurrencia pesimista se utiliza por dos razones. En primer
lugar, a veces existe una gran contienda por los mismos registros. El costo de
bloquear los datos es menor que el de deshacer los cambios cuando se
producen conflictos de concurrencia.
La concurrencia pesimista es útil también en situaciones en las que no es
conveniente que cambie el registro durante una transacción. Un buen ejemplo
sería una aplicación de inventario.
Consideremos que el representante de una compañía va a comprobar el
inventario para un posible cliente. Lo normal sería bloquear el registro hasta
que se generase un pedido, lo que, en líneas generales, identificaría el artículo
con el estado de pedido y lo quitaría del inventario disponible.
Si no se generase ningún pedido, el bloqueo se liberaría para que otros
usuarios que comprobasen el inventario obtuviesen un recuento exacto del
inventario disponible.
No obstante, el control de concurrencia pesimista no es posible en una
arquitectura desconectada. Las conexiones se abren sólo el tiempo suficiente
para leer los datos o actualizarlos, por lo que los bloqueos no se pueden
mantener durante períodos de tiempo prolongados. Además, una aplicación
que mantiene los bloqueos durante períodos de tiempo prolongados no es
escalable.
Nota
Si el origen de datos subyacente admite las transacciones, puede simular la
concurrencia pesimista mediante la actualización de los datos dentro de una
transacción. Para obtener más información, vea Características que
proporciona System.Transactions.
Teoría de Bases de Datos II 90 UCENM
Concurrencia optimista
En la concurrencia optimista, los bloqueos se establecen y mantienen sólo
mientras se está teniendo acceso a la base de datos. Los bloqueos impiden
que otros usuarios intenten actualizar registros en ese mismo instante. Los
datos están siempre disponibles, excepto durante el momento preciso en que
está teniendo lugar una actualización. Para obtener más información, vea
Utilizar concurrencia optimista.
Cuando se intenta realizar una actualización, se compara la versión original de
una fila modificada con la fila existente en la base de datos. Si las dos son
diferentes, la actualización no se realiza debido a un error de concurrencia. En
ese instante, es de su responsabilidad la reconciliación de las dos filas
mediante su propia lógica de empresa.
El último gana
Con la técnica de "el último gana", no se realiza ninguna comprobación de los
datos originales y la actualización simplemente se escribe en la base de datos.
Es comprensible que se pueda producir el siguiente escenario:
El usuario A obtiene un registro de la base de datos.
El usuario B obtiene el mismo registro de la base de datos, lo modifica y
devuelve a la base de datos el registro actualizado.
El usuario A modifica el registro "antiguo" y lo devuelve a la base de
datos.
En el escenario anterior, los cambios que realizó el usuario B no los ve nunca
el usuario A. Asegúrese de que esta situación sea aceptable si tiene previsto
usar el planteamiento "el último gana" del control de concurrencia.
Control de concurrencia en ADO.NET y Visual Studio
ADO.NET y Visual Studio utilizan la concurrencia optimista porque la
arquitectura de datos se basa en datos desconectados.
Teoría de Bases de Datos II 91 UCENM
Por ello, es necesario agregar lógica de empresa para resolver los problemas
de la concurrencia optimista.
Si decide utilizar la concurrencia optimista, existen dos métodos generales para
determinar si se han producido cambios: el planteamiento del número de
versión (números de versión reales o marcas de fecha y hora) y el
planteamiento de guardar todos los valores.
Planteamiento del número de versión
En el planteamiento del número de versión, el registro que se va a actualizar
debe tener una columna que contenga una marca de fecha y hora o un número
de versión. La marca de fecha y hora o el número de versión se guardan en el
cliente cuando se lee el registro. Después, se hace que el valor forme parte de
la actualización.
Una forma de controlar la concurrencia es actualizar sólo si el valor de la
cláusula WHERE coincide con el valor del registro.
La representación SQL de este planteamiento es:
Copier
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2
WHERE DateTimeStamp = @origDateTimeStamp
Alternativamente, se puede realizar la comparación con el número de versión:
Copiar
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2
WHERE RowVersion = @origRowVersionValue
Si las marcas de fecha y hora o los números de versión coinciden, el registro
del almacén de datos no ha cambiado y se puede actualizar de manera segura
con los nuevos valores del conjunto de datos. Si no coinciden, se devuelve un
error. Puede escribir código para implementar esta forma de comprobar la
concurrencia en Visual Studio.
Teoría de Bases de Datos II 92 UCENM
También deberá escribir código para responder a los posibles conflictos de
actualización. Para mantener la exactitud de la marca de fecha y hora o el
número de versión, necesita configurar un desencadenador en la tabla para
que se actualice cuando se produzca un cambio en alguna fila.
Planteamiento de guardar todos los valores
Una alternativa al uso de una marca de fecha y hora o un número de versión es
obtener copias de todos los campos cuando se lea el registro. El objeto
DataSet de ADO.NET mantiene dos versiones de cada registro modificado: una
versión original (la que se leyó originalmente del origen de datos) y una versión
modificada que representa las actualizaciones del usuario.
Cuando se intenta volver a escribir el registro en el origen de datos, se
comparan los valores originales de la fila de datos y el registro del origen de
datos. Si coinciden, significa que el registro de la base de datos no ha
cambiado desde que se leyó.
En ese caso, los valores modificados del conjunto de datos se escriben en la
base de datos sin problemas. Cada uno de los cuatro comandos del adaptador
de datos (DELETE, INSERT, SELECT y UPDATE) tiene una colección de
parámetros. Cada comando tiene parámetros para los valores originales y para
los valores actuales (o modificados).
Nota
Cuando se agregan registros nuevos (comando INSERT), sólo se requieren los
valores actuales, ya que no existe ningún registro original; cuando se quitan
registros (comando DELETE), sólo se requieren los valores originales para
poder localizar el registro que se desea eliminar.
Teoría de Bases de Datos II 93 UCENM
En el ejemplo siguiente se muestra el texto de un comando del conjunto de
datos que actualiza una tabla Customers típica. El comando se especifica para
SQL dinámico y para la concurrencia optimista.
Copiar
UPDATE Customers SET CustomerID = @currCustomerID, CompanyName =
@currCompanyName, ContactName = @currContactName,ContactTitle =
currContactTitle, Address = @currAddress, City = @currCity, PostalCode =
@currPostalCode, Phone = @currPhone, Fax = @currFax
WHERE (CustomerID = @origCustomerID) AND (Address = @origAddress OR
@origAddress IS NULL AND Address IS NULL) AND (City = @origCity OR
@origCity IS NULL AND City IS NULL)
AND (CompanyName = @origCompanyName OR @origCompanyName IS
NULL AND CompanyName IS NULL) AND (ContactName =
@origContactName OR @origContactName IS NULL AND ContactName IS
NULL) AND (ContactTitle = @origContactTitle OR @origContactTitle IS NULL
AND ContactTitle IS NULL)
AND (Fax = @origFax OR @origFax IS NULL AND Fax IS NULL) AND
(Phone = @origPhone OR @origPhone IS NULL AND Phone IS NULL) AND
(PostalCode = @origPostalCode OR @origPostalCode IS NULL AND
PostalCode IS NULL);
SELECT CustomerID, CompanyName, ContactName, ContactTitle, Address,
City,
PostalCode, Phone, Fax
FROM Customers WHERE (CustomerID = @currCustomerID)
Teoría de Bases de Datos II 94 UCENM
Tenga en cuenta que los nueve parámetros de la instrucción SET representan
los valores actuales que se escribirán en la base de datos, mientras que los
nueve parámetros de la instrucción WHERE representan los valores originales
que se utilizan para encontrar el registro original.
Los nueve primeros parámetros de la instrucción SET se corresponden con los
nueve primeros parámetros de la colección de parámetros. Estos parámetros
tendrían su propiedad SourceVersion establecida en Current.
Los nueve parámetros siguientes de la instrucción WHERE se utilizan para la
concurrencia optimista. Estos marcadores de posición se corresponderían con
los nueve parámetros siguientes de la colección de parámetros, y cada uno de
estos parámetros tendría la propiedad SourceVersion establecida en Original.
La instrucción SELECT se utiliza para actualizar el conjunto de datos después
de que se haya producido la actualización. Se genera cuando se establece la
opción Actualizar el conjunto de datos del cuadro de diálogo Opciones de
generación SQL avanzadas.
Nota
En la instrucción SQL anterior se utilizan parámetros con nombre, mientras que
los comandos OleDbDataAdapter usan signos de interrogación (?) como
marcadores de posición de los parámetros.
De manera predeterminada, Visual Studio crea estos parámetros
automáticamente si selecciona la opción Concurrencia optimista en el Asistente
para la configuración del adaptador de datos. Debe decidir si desea agregar
código para controlar los errores basándose en las necesidades de su
empresa. ADO.NET proporciona un objeto DBConcurrencyException que
devuelve la fila que infringe las reglas de concurrencia. Para obtener más
información, vea Cómo: Controlar errores de concurrencia.
Teoría de Bases de Datos II 95 UCENM
CONTROL DE CONCURRENCIA EN BASES DE DATOS
El control de transacciones concurrentes en una base de datos brinda un
eficiente desempeño del Sistema de Base de Datos, puesto que permite
controlar la ejecución de transacciones que operan en paralelo, accesando a
información compartida y, por lo tanto, interfiriendo potencialmente unas con
otras.
El hecho de reservar un asiento en una avión mediante un sistema basado en
aplicaciones web, cuando decenas de personas en el mundo pueden reservarlo
también, nos da una idea de lo importante y crucial que es el control de
concurrencia en un sistema de base de datos a mediana o gran escala.
Otro ejemplo en el que podemos observar la incidencia del control de
concurrencia en el siguiente: en una Base de Datos bancaria podría ocurrir que
se paguen dos cheques en forma simultánea sobre una cuenta que no tiene
saldo suficiente para cubrirlos en su totalidad, esto es posible evitarlo si se
tiene un control de concurrencia.
TRANSACCIONES
Los sistemas que tratan el problema de control de concurrencia permiten que
sus usuarios asuman que cada una de sus aplicaciones se ejecutan
atómicamente, como si no existieran otras aplicaciones ejecutándose
concurrentemente.
Esta abstracción de una ejecución atómica y confiable de una aplicación se
conoce como una transacción.
Un algoritmo de control de concurrencia asegura que las transacciones se
ejecuten atómicamente controlando la intercalación de transacciones
concurrentes, para dar la ilusión de que las transacciones se ejecutan
seriamente, una después de la otra, sin ninguna intercalación.
Teoría de Bases de Datos II 96 UCENM
Las ejecuciones intercaladas cuyos efectos son los mismos que las
ejecuciones seriales son denominadas serializadles y son correctos ya que
soportan la ilusión de la atomicidad de las transacciones.
El concepto principal es el de transacción. Informalmente, una transacción es la
ejecución de ciertas instrucciones que accesan a una base de datos
compartida. El objetivo del control de concurrencia y recuperación es asegurar
que dichas transacciones se ejecuten atómicamente, es decir:
Cada transacción accede a información compartida sin interferir con otras
transacciones, y si una transacción termina normalmente, todos sus efectos
son permanentes, en caso contrario no tiene afecto alguno.
Una base de datos está en un estado consistente si obedece todas las
restricciones de integridad (significa que cuando un registro en una tabla haga
referencia a un registro en otra tabla, el registro correspondientes debe existir)
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 entre 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.
Teoría de Bases de Datos II 97 UCENM
EJEMPLOS DE CONCURRENCIA
EL PROBLEMA DE LA RECUPERABILIDAD:
Ejemplo 1:
H1= Write1(X,2); Read2(X); Write2(Y,3); Commit2.
Supongamos que inicialmente los item X e Y tienen un valor igual a 1.
Ahora supongamos que T1 aborta y por lo tanto debería hacer un rollback y
Volver X al valor anterior- y entonces luego T2 debería también abortar y hacer
Un rollback, porque leyó un valor sucio que le dejó T1, pero si lo hacemos
Estaríamos violando la semántica del commit y esto trae confusión.
Llegamos a una situación en el que estado consistente anterior de la BD es
Irrecuperable.
Para evitar esta situación deberíamos demorar el commit de T2
Ejemplo 2:
H2= Write1(X,2); Read2(X); Write2(Y,3); Abort1.
Supongamos un caso similar al anterior pero donde T1 abortó y por lo tanto
Todavía podemos recuperar el estado consistente anterior abortando T2.
Pero sin embargo esto nos puede llevar a la situación no deseada de aborts
En cascada.
Para evitar esta situación deberíamos demorar cada Read(X) hasta que los
Correspondientes Ti que previamente hicieron un Write(X,val) hayan hecho
Abort o commit.
Teoría de Bases de Datos II 98 UCENM
CUESTIONARIO.
1-.¿Que comprendió por concurrencia y de ejemplos?
2-. ¿Cuale son los principales algoritmos que hay en la concurrencia?
3-.¿Que significan los algorirmos de cerraduras y candado?
4-.¿Que es un control optimista en la concurrencia?
5-.¿Que son los algoritmos basados en marcas de tiempo?
Teoría de Bases de Datos II 99 UCENM
6-.¿Que son los abrazos mortales?
7-.¿Que sinconizacion de procesos?
8-.¿Que tipos de concurrencia en ADO.NET hay?
9-.¿Que entendió por control de concurrencia en base de datos?
10-.De una explicación de lo que comprendió en los ejemplo 1 y 2 de
concurrencia de la pag 98.
Teoría de Bases de Datos II 100 UCENM
BASES DE DATOS
DISTRIBUIDAS
Objetivos del capítulo IV
1. Comprender y analizar el concepto Bases de Datos
Distribuidas.
2. Conocer la administración de DDBMS.
3. Conocer el Diseño de DDBMS.
4. Comprender los tipos de Base Datos Distribuidas.
Programa de consulta o transacción
Programa de consulta o transacción
Programa de consulta o transacción
DTMx
DTMy
DTMz
DBMw
DBMx
DBMy
BDw
BDx
BDy
Nodo z
Nodo y
Nodo x
DDBMS Interfaz de solicitud
Interfaz de acción
Nodo w
DDB
Teoría de Bases de Datos II 101 UCENM
INTRODUCCION
En un sistema de base de datos distribuida, los datos se almacenan en varios
computadores. Los computadores de un sistema distribuido se comunican
entre sí a través de diversos medios de comunicación, tales como cables de
alta velocidad o líneas telefónicas.
No comparten la memoria principal ni el reloj.
Los procesadores de un sistema distribuido pueden variar en cuanto su tamaño
y función. Pueden incluir microcomputadores pequeños, estaciones de trabajo
y sistemas de computadores grandes de aplicación general.
Estos procesadores reciben diferentes nombres, tales como localidades, nodos
o computadores.
Un sistema distribuido de bases de datos consiste en un conjunto de
localidades, cada uno de las cuales puede participar en la ejecución de
transacciones que accedan a datos de una o varias localidades.
La diferencia principal entre los sistemas de base de datos centralizados y
distribuidos es que, en los primeros, los datos residen en una sola localidad,
mientras que, en los últimos, se encuentran en varias localidades.
Teoría de Bases de Datos II 102 UCENM
Transacciones y Administradores de una DDBMS
El sistema de administración de base de datos distribuida (DDBMS), está
formado por las transacciones y los administradores de base de datos
distribuidos de todas las computadoras. Tal y como se muestra, tal DDBMS es
un esquema genérico que implica un conjunto de programas que operan en
diversas computadoras. Estos programas pueden ser subsistemas de un
producto único DDBMS, concesionado por un sólo fabricante, o también
pudiera resultar una colección de programas de fuentes dispares: algunos
concesionados por fabricantes, y algunos otros escritos en casa. El propósito
de esta figura es ilustrar las funciones que deban atenderse en el
procesamiento de bases de datos distribuidas.
Administrador de transacciones distribuidas (DTM):
Es un programa que recibe so- licitudes de procesamiento de los programas de
consulta o de transacciones ya su vez las traduce en acciones para los
administradores de la base de datos. Una función importante del DTM es
coordinar y controlar dichas acciones. Dependiendo de la naturaleza de la
aplicación del DDBMS, el DTM puede ser proporcionado como parte de
DDBMS o puede desarrollarse en casa por la organización que pone en
práctica el sistema distribuido. En aplicaciones menos complejas, una parte de
sus funciones puede ser llevada a cabo por personas, siguiendo sólo
procedimientos manuales.
Administrador de la base de datos (DBM):
Es un programa que procesa cierta porción de la base de datos distribuida,
como es el hecho de recuperar y actualizar datos del usuario y generales, de
acuerdo con comandos de acción recibidos de los DTM. El DBM puede ser un
subconjunto de un producto DDBMS, o ser también un DBMS comercial no
distribuido.
Teoría de Bases de Datos II 103 UCENM
En algunos casos, el DDBMS pudiera contener diferentes productos DBMS.
Un nodo es una computadora que ejecuta un DTM, un DBM, o inclusive ambos.
Un nodo de transacción procesa un DTM, y un nodo de base de datos procesa
un DBM y su base de datos': En la Figura 17-1, el Nodo W es un nodo de base
de datos ejecutando DBMwY almacenando BDw. El Nodo X es tanto un nodo
de transacción como de base de datos con DTMx' DBMx y BDx. De modo
similar, el Nodo Y es tanto un nodo de transacción como de base de datos,
pero el Nodo Z es solamente un nodo de transacción.
Los programas de consulta o de transacción se comunican con los DTM a
través de solicitudes parecidas a las solicitudes de acción del DBMS. Ejemplos
son SELECT EMPLOYEE WHERE E# EQ 123 o bien STORE DUE-DATE.
Estas solicitudes operan sobre estructuras lógicas. El programa de consulta o
de aplicación no se refiere a ninguna instancia física en particular de la
estructura.
Los DTM se comunican con los DBM por medio de acciones a ejecutarse en
ocurrencias específicas de datos. Por lo tanto, si la nueva ocurrencia de DUE-
DA TE debe almacenarse en DBx y en DBy, el DTM traducirá la solicitud
STORE DUE-DA TE en dos acciones. Una se dirigirá a DBMx para almacenar
los nuevos datos, y la segunda se dirigirá a DBMy para a su vez almacenar tal
información. En principio, las solicitudes y las acciones pueden también diferir
en términos de su nivel de abstracción. Por ejemplo, se puede expresar una
solicitud en términos de un objeto y puede ser traducida en acciones o
expresada en términos de relaciones compuestas distribuidas o de archivo. A la
fecha, sin embargo, no existe un DDBMS como éste.
VENTAJAS DEL PROCESAMIENTO DISTRIBUIDO
Existen cuatro ventajas del procesamiento de base de datos distribuido. La
primera, puede dar como resultado un mejor rendimiento que el que se obtiene
por un procesamiento centralizado. Los datos pueden colocarse cerca del
punto de su utilización, de forma que el tiempo de comunicación sea más corto.
Varias computadoras operando en forma simultánea pueden entregar más
volumen de procesamiento que una sola computadora.
Teoría de Bases de Datos II 104 UCENM
Figura 2
Un negocio distribuido geográficamente
Segundo, los datos duplicados aumentan su confiabilidad. Cuando falla una
computadora, se pueden obtener los datos extraídos de otras computadoras.
Los usuarios no dependen de la disponibilidad de una sola fuente para sus
datos. Una tercera ventaja es que los sistemas distribuidos pueden variar su
tamaño de un modo más sencillo. Se pueden agregar computadoras
adicionales a la red conforme aumentan el número de usuarios y su carga de
procesamiento. A menudo es más fácil y más barato agregar una nueva
computadora más pequeña que actualizar una computadora única y
centralizada. Después, si la carga de trabajo se reduce, el tamaño de la red
también puede reducirse.
Por último, los sistemas distribuidos se pueden adecuar de una manera más
sencilla a las estructuras de la organización de los usuarios. La Figura 2
muestra la organización de un fabricante distribuido geográficamente.
Planta A
Planta B
Planta C
Almacén
Teoría de Bases de Datos II 105 UCENM
Los gerentes generales de cada una de las plantas poseen una enorme
autoridad y libertad en la operación de sus instalaciones. Si tales plantas
dependieran de una computadora única centralizada, la arquitectura de sistema
entraría en conflicto con la filosofía y las políticas operacionales de la empresa.
Incluso en organizaciones más centralizadas, el procesamiento distribuido
ofrece una mayor flexibilidad para adecuarse a la estructura organizacional, de
lo que permite el procesamiento centralizado.
DESVENTAJAS DEL PROCESAMIENTO DISTRIBUIDO
Las primeras dos desventajas de las bases de datos distribuidas son las
mismas que las dos primeras ventajas. Primero, el rendimiento puede ser peor
para el procesamiento distribuido que para el procesamiento centralizado.
Depende de la naturaleza de la carga de trabajo, la red, el DDBMS y las
estrategias utilizadas de concurrencia y de falla, así como las ventajas del
acceso local a los datos y de los procesadores múltiples, ya que éstos pueden
ser abrumados por las tareas de coordinación y de control requeridas. Tal
situación es probable cuando la carga de trabajo necesita un gran número de
actualizaciones concurrentes sobre datos duplicados, y que deben estar muy
distribuidos.
Segundo, el procesamiento de base de datos distribuida puede resultar menos
confiable que el procesamiento centralizado. De nuevo, depende de la
confiabilidad de las computadoras de procesamiento, de la red, del DDBMS, de
las transacciones y de las tasas de error en la carga de trabajo. Un sistema
distribuido puede estar menos disponible que uno centralizado. Estas dos
desventajas indican que un procesamiento distribuido no es ninguna panacea.
A pesar de que tiene la promesa de un mejor rendimiento y de una mayor
confiabilidad, tal promesa no está garantizada.
Teoría de Bases de Datos II 106 UCENM
Figura 3
Ventajas y desventajas del procesamiento de una base de datos distribuida
Una tercera desventaja es su mayor complejidad, a menudo se traduce en altos
gastos de construcción y mantenimiento. Ya que existen más componentes de
hardware, hay más cantidad de cosas por aprender y más interfaces
susceptibles de fallar. El control de concurrencia y recuperación de fallas puede
convertirse en algo complicado y difícil de implementar, puede empujar a una
mayor carga sobre programadores y personal de operaciones y quizá se
requiera de personal más experimentado y más costoso.
El procesamiento de bases de datos distribuido es difícil de controlar. Una
computadora centralizada reside en un entorno controlado, con personal de
operaciones que supervisa muy de cerca, y las actividades de procesamiento
pueden ser vigiladas, aunque a veces con dificultad. En un sistema distribuido,
las computadoras de proceso, residen muchas veces en las áreas de trabajo
de los usuarios. En ocasiones el acceso físico no está controlado, y los
procedimientos operativos son demasiado suaves y efectuados por personas
que tienen escasa apreciación o comprensión sobre su importancia. En
sistemas centralizados, en caso de un desastre o catástrofe, la recuperación
puede ser más difícil de sincronizar.
VENTAJAS Mayor rendimiento Mayor confiabilidad Cambia de tamaño con facilidad Adecuado fácilmente a la estructura de la organización
DESVENTAJAS Peor rendimiento Menor confiabilidad Mayor complejidad Costos más altos Difícil de controlar
Teoría de Bases de Datos II 107 UCENM
Estructura de Base de Datos Distribuidas
Un sistema distribuido de base de datos consiste en un conjunto de
localidades, cada una de las cuales mantiene un sistema de base de datos
local. Cada localidad puede procesar transacciones locales, o bien
transacciones globales entre varias localidades, requiriendo para ello
comunicación entre ellas.
Las localidades pueden conectarse físicamente de diversas formas, las
principales son:
Red totalmente conectada
Red prácticamente conectada
Red con estructura de árbol
Red de estrella
Red de anillo
Las diferencias principales entre estas configuraciones son:
Costo de instalación: El coste de conectar físicamente las localidades
del sistema
Cost0 de comunicación: El coste en tiempo y dinero que implica enviar
un mensaje desde la localidad A a la B.
Fiabilidad: La frecuencia con que falla una línea de comunicación o una
localidad.
Disponibilidad: La posibilidad de acceder a información a pesar de fallos
en algunas localidades o líneas de comunicación.
Las localidades pueden estar dispersas, ya sea por un área geográfica extensa
(a lo largo de un país), llamadas redes de larga distancia; o en un área
reducida (en un mismo edificio), llamadas redes de área local.
Teoría de Bases de Datos II 108 UCENM
Para las primeras se utilizan en la comunicación líneas telefónicas, conexiones
de microondas y canales de satélites; mientras que para las segundas se utiliza
cables coaxiales de banda base o banda ancha y fibra óptica.
Consideraciones al distribuir la base de datos
Existen varias razones para construir sistemas distribuidos de bases de datos
que incluyen compartir la información, fiabilidad y disponibilidad y agilizar el
procesamiento de las consultas. Pero también tiene sus desventajas, como
desarrollos de software más costosos, mayor posibilidad de errores y costos
extras de procesamiento.
Ventajas de la distribución de datos
La principal ventaja de los sistemas distribuidos es la capacidad de compartir y
acceder a la información de una forma fiable y eficaz.
Utilización compartida de los datos y distribución del control
La ventaja principal de compartir los datos por medio de la distribución 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 diseño del sistema distribuido, cada administrador local podrá
tener un grado de autonomía diferente, que se conoce como autonomía local.
La posibilidad de contar con autonomía local es en muchos casos una ventaja
importante de las bases de datos distribuidas.
Teoría de Bases de Datos II 109 UCENM
Fiabilidad y disponibilidad
Si se produce un fallo en una localidad de un sistema distribuido, es posible
que las demás localidades puedan seguir trabajando. En particular, si los datos
se repiten en varias localidades, una transacción que requiere un dato
específico puede encontrarlo en más de una localidad. Así, el fallo de una
localidad no implica necesariamente la desactivación 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 mínimo 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 línea aérea no
puede tener acceso a la información, es posible que pierda clientes a favor de
la competencia.
Agilización 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 intersección se pueden
aplicar en estos sistemas.
En los casos en que hay repetición de los datos, el sistema puede pasar la
consulta a las localidades más ligeras de carga.
Teoría de Bases de Datos II 110 UCENM
Desventajas de la distribución de los datos
La desventaja principal de los sistemas distribuidos es la mayor complejidad
que se requiere para garantizar una coordinación adecuada entre localidades.
El aumento de la complejidad se refleja en:
Coste del desarrollo de software: es más difícil 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 más difícil garantizar que los
algoritmos sean correctos.
Mayor tiempo extra de procesamiento: el intercambio de mensajes y los
cálculos adicionales son una forma de tiempo extra que no existe en los
sistemas centralizados.
Transparencia y Autonomía
En la sección anterior se vio que una relación r puede almacenarse de varias
formas en un sistema de base de datos distribuida. Es esencial que el sistema
reduzca al mínimo la necesidad de que el usuario se dé cuenta de cómo está
almacenada una relación. Como veremos. Un sistema puede ocultar los
detalles de la distribución de la información en la red.
Esto se denomina transparencia de la red. La transparencia de la red se
relaciona, en algún modo, a la autonomía local. La transparencia de la red es el
grado hasta el cual los usuarios del sistema pueden ignorar los detalles del
diseño distribuido.
La autonomía local es el grado hasta el cual el diseñador o administrador de
una localidad pueden ser independientes del resto del sistema distribuido.
Teoría de Bases de Datos II 111 UCENM
Los temas de transparencia y autonomía serán considerados desde los
siguientes puntos de vista:
Nombre de los datos.
Repetición de los datos.
Fragmentación de los datos.
Localización de los fragmentos y copias.
Asignación de nombres y autonomía local
Todo elemento de información de una base de datos debe tener un nombre
único. Esta propiedad se asegura fácilmente en una base de datos que no esté
distribuida. Sin embargo, en una base de datos distribuida, las distintas
localidades deben asegurarse no utilizar el mismo nombre para dos datos
diferentes.
Una solución para este problema es requerir que se registren todos los
nombres en un asignador central de nombres. Sin embargo, este enfoque tiene
varias desventajas:
Es posible que el asignador de nombres se convierta en un cuello de
botella..
Si el asignador de nombres se cae, es posible que ninguna de las
localidades del sistema distribuido pueda seguir trabajando.
Se reduce la autonomía local, ya que la asignación de nombres se
controla de forma centralizada.
Un enfoque diferente que origina una mayor autonomía local es exigir que cada
localidad ponga como prefijo un identificador de localidad a cualquier nombre
que genere. Esto garantiza que dos localidades nunca generarán el mismo
nombre (ya que cada localidad tiene un identificador único). Además, no se
requiere un control central.
Teoría de Bases de Datos II 112 UCENM
Esta solución al problema de asignación de nombres, logra autonomía local,
pero no transparencia de la red, ya que se agregan identificadores de localidad
a los nombres. Así, la relación depósito podría llamarse localidad17.depósito en
vez de depósito simplemente.
Cada copia y fragmento de un elemento de información deben tener un nombre
único. Es importante que el sistema pueda determinar qué copias son copias
del mismo elemento de información y qué fragmentos son fragmentos del
mismo elemento de información.
Transparencia de la repetición y la fragmentación
No es conveniente requerir que los usuarios hagan referencia a una copia
específica de un elemento de información. El sistema debe ser el que
determine a qué copia debe acceder cuando se le solicite su lectura, y debe
modificar todas las copias cuando se produzca una petición de escritura.
Cuando se solicita un dato, no es necesario especificar la copia. El sistema
utiliza una tabla-catálogo para determinar cuáles son todas las copias de ese
dato.
De manera similar, no debe exigirse a los usuarios que sepan cómo está
fragmentado un elemento de información. Es posible que los fragmentos
verticales contengan id-duplas, que representan direcciones de duplas. Los
fragmentos horizontales pueden haberse obtenido por predicados de selección
complejos.
Por tanto, un sistema de bases de datos distribuido debe permitir las consultas
que se hagan en términos de elementos de información sin fragmentar. Esto no
presenta problemas graves, ya que siempre es posible reconstruir el elemento
de información original a partir de sus fragmentos. Sin embargo, este proceso
puede ser ineficiente.
Teoría de Bases de Datos II 113 UCENM
Transparencia de localización
Si el sistema es transparente en cuanto a repetición y fragmentación, se
ocultará al usuario gran parte del esquema de la base de datos distribuida. Sin
embargo, el componente de los nombres que identifican a la localidad obliga al
usuario a darse cuenta del hecho de que cl sistema está distribuido.
La transparencia de localización se logra creando un conjunto de seudónimos 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 seudónimos, no será necesario que el usuario conozca la
localización física de un dato. Además, el administrador de la base de datos
puede cambiar un dato de una localidad a otra sin afectar a los usuarios.
Esquema completo de asignación de nombres
Ya vimos que un nombre proporcionado por el usuario debe pasar por varios
pasos de traducción antes de que pueda servir como referencia a una copia
específica de un fragmento determinado en una localidad específica.
Para ilustrar cómo funciona el esquema, consideramos un usuario que se
encuentra en la sucursal 1 (L1).
Este usuario emplea el seudónimo depósito-local para el fragmento local
depósito-F1 de la relación deposito. Cuando este usuario hace referencia a
depósito-local, el subsistema de procesamiento de consultas busca depósito-
local en la tabla de seudónimos y la sustituye por Ll.depósito.F1. Es posible
que L1.depósito.Fl esté repetido.
Si es así, debe consultarse la tabla de copias para elegir una copia. Esta copia
podría también estar fragmentada, lo que haría necesario consultar la tabla de
fragmentación. En la mayor parte de los casos, sólo es preciso consultar una o
dos tablas.
Teoría de Bases de Datos II 114 UCENM
Transparencia y actualizaciones
De alguna forma es más difícil hacer transparente la base de datos para
usuarios que la actualizan que para aquellos que sólo leen datos. El problema
principal es asegurarse de que se actualizan todas las copias de un dato y
también los fragmentos afectados.
En el caso más general, el problema de actualización de información repetida y
fragmentada está relacionado con el problema de actualización de vistas.
Diseño de la distribución:
Introducción
El diseño de un sistema de base de datos distribuido implica la toma de
decisiones sobre la ubicación de los programas que accederán a la base de
datos y sobre los propios datos que constituyen esta última, a lo largo de los
diferentes puestos que configuren una red de ordenadores.
La ubicación de los programas, a priori, no debería suponer un excesivo
problema dado que se puede tener una copia de ellos en cada máquina de la
red (de hecho, en este documento se asumirá que así es). Sin embargo, cuál
es la mejor opción para colocar los datos: en una gran máquina que albergue a
todos ellos, encargada de responder a todas las peticiones del resto de las
estaciones - sistema de base de datos centralizado -, o podríamos pensar en
repartir las relaciones, las tablas, por toda la red.
En el supuesto que nos decantásemos por esta segunda opción, ¿qué criterios
se deberían seguir para llevar a cabo tal distribución? ¿Realmente este
enfoque ofrecerá un mayor rendimiento que el caso centralizado? ¿Podría
optarse por alguna otra alternativa?
Teoría de Bases de Datos II 115 UCENM
Tradicionalmente se ha clasificado la organización de los sistemas de bases de
datos distribuidos sobre tres dimensiones: el nivel de compartición, las
características de acceso a los datos y el nivel de conocimiento de esas
características de acceso.
El nivel de compartición presenta tres alternativas: inexistencia, es decir, cada
aplicación y sus datos se ejecutan en un ordenador con ausencia total de
comunicación con otros programas u otros datos; se comparten sólo los datos y
no los programas, en tal caso existe una réplica de las aplicaciones en cada
máquina y los datos viajan por la red; y, se reparten datos y programas, dado
un programa ubicado en un determinado sitio, éste puede solicitar un
Enfoque de la distribución.
Servicio a otro programa localizado en un segundo lugar, el cual podrá acceder
a los datos situados en un tercer emplazamiento. Como se comentó líneas
atrás, en este caso se optará por el punto intermedio de compartición.
Respecto a las características de acceso a los datos existen dos alternativas
principalmente: el modo de acceso a los datos que solicitan los usuarios puede
ser estático, es decir, no cambiará a lo largo del tiempo, o bien, dinámico.
El lector podrá comprender fácilmente la dificultad de encontrar sistemas
distribuidos reales que puedan clasificarse como estáticos. Sin embargo, lo
realmente importante radica, estableciendo el dinamismo como base, cómo de
dinámico es, cuántas variaciones sufre a lo largo del tiempo.
Esta dimensión establece la relación entre el diseño de bases de datos
distribuidas y el procesamiento de consultas.
La tercera clasificación es el nivel de conocimiento de las características de
acceso. Una posibilidad es, evidentemente, que los diseñadores carezcan de
información alguna sobre cómo los usuarios acceden a la base de datos.
Teoría de Bases de Datos II 116 UCENM
Es una posibilidad teórica, pero sería muy laborioso abordar el diseño de la
base de datos con tal ausencia de información. Lo más práctico sería conocer
con detenimiento la forma de acceso de los usuarios o, en el caso de su
imposibilidad, conformarnos con una información parcial de ésta.
El problema del diseño de bases de datos distribuidas podría enfocarse a
través de esta trama de opciones. En todos los casos, excepto aquel en el que
no existe compartición, aparecerán una serie de nuevos problemas que son
irrelevantes en el caso centralizado.
A la hora de abordar el diseño de una base de datos distribuida podremos optar
principalmente por dos tipos de estrategias: la estrategia ascendente y la
estrategia descendente. Ambos tipos no son excluyentes, y no resultaría
extraño a la hora de abordar un trabajo real de diseño de una base de datos
que se pudiesen emplear en diferentes etapas del proyecto una u otra
estrategia.
La estrategia ascendente podría aplicarse en aquel caso donde haya que
proceder a un diseño a partir de un número de pequeñas bases de datos
existentes, con el fin de integrarlas en una sola. En este caso se partiría de los
esquemas conceptuales locales y se trabajaría para llegar a conseguir el
esquema conceptual global.
Aunque este caso se pueda presentar con facilidad en la vida real, se prefiere
pensar en el caso donde se parte de cero y se avanza en el desarrollo del
trabajo siguiendo la estrategia descendente. La estrategia descendente,
debería resultar familiar a la persona que posea conocimientos sobre el diseño
de bases de datos, exceptuando la fase del diseño de la distribución. Pese a
todo, se resumirán brevemente las etapas por las que se transcurre.
Teoría de Bases de Datos II 117 UCENM
Estrategia descendente.
Todo comienza con un análisis de los requisitos que definirán el entorno del
sistema en aras a obtener tanto los datos como las necesidades de
procesamiento de todos los posibles usuarios del banco de datos. Igualmente,
se deberán fijar los requisitos del sistema, los objetivos que debe cumplir
respecto a unos grados de rendimiento, seguridad, disponibilidad y flexibilidad,
sin olvidar el importante aspecto económico.
Como puede observarse, los resultados de este último paso sirven de entrada
para dos actividades que se realizan de forma paralela. El diseño de las vistas
trata de definir las interfaces para el usuario final y, por otro lado, el diseño
conceptual se encarga de examinar la empresa para determinar los tipos de
entidades y establecer la relación entre ellas.
Existe un vínculo entre el diseño de las vistas y el diseño conceptual. El diseño
conceptual puede interpretarse como la integración de las vistas del usuario,
este aspecto es de vital importancia ya que el modelo conceptual debería
soportar no sólo las aplicaciones existentes, sino que debería estar preparado
para futuras aplicaciones.
En el diseño conceptual y de las vistas del usuario se especificarán las
entidades de datos y se determinarán las aplicaciones que funcionarán sobre la
base de datos, así mismo, se recopilarán datos estadísticos o estimaciones
sobre la actividad de estas aplicaciones. Dichas estimaciones deberían girar en
torno a la frecuencia de acceso, por parte de una aplicación, a las distintas
relaciones de las que hace uso, podría afinarse más anotando los atributos de
la relación a la que accede.
Desarrollado el trabajo hasta aquí, se puede abordar la confección del
esquema conceptual global. Este esquema y la información relativa al acceso a
los datos sirven de entrada al paso distintivo: el diseño de la distribución.
Teoría de Bases de Datos II 118 UCENM
El objetivo de esta etapa consiste en diseñar los esquemas conceptuales
locales que se distribuirán a lo largo de todos los puestos del sistema
distribuido. Sería posible tratar cada entidad como una unidad de distribución;
en el caso del modelo relacional, cada entidad se corresponde con una
relación.
Resulta bastante frecuente dividir cada relación en subrelaciones menores
denominadas fragmentos que luego se ubican en uno u otro sitio. De ahí, que
el proceso del diseño de la distribución conste de dos actividades
fundamentales: la fragmentación y la asignación.
El último paso del diseño de la distribución es el diseño físico, el cual proyecta
los esquemas conceptuales locales sobre los dispositivos de almacenamiento
físico disponibles en los distintos sitios.
Las entradas para este paso son los esquemas conceptuales locales y la
información de acceso a los fragmentos. Por último, se sabe que la actividad de
desarrollo y diseño es un tipo de proceso que necesita de una monitorización y
un ajuste periódicos, para que si se llegan a producir desviaciones, se pueda
retornar a alguna de las fases anteriores.
Diseño
Existen diversas formas de afrontar el problema del diseño de la distribución.
En el primer caso, caso A, los dos procesos fundamentales, la fragmentación y
la asignación, se abordan de forma simultánea.
Esta metodología se encuentra en desuso, sustituida por el enfoque en dos
fases, caso B: la realización primeramente de la partición para luego asignar
los fragmentos generados. El resto de los casos se comentan en la sección
referente a los distintos tipos de la fragmentación.
Teoría de Bases de Datos II 119 UCENM
Enfoques para realizar el diseño distributivo.
Antes de exponer las alternativas existentes de fragmentación, se desean
presentar las ventajas e inconvenientes de esta técnica. Se ha comentado en la
introducción la conveniencia de descomponer las relaciones de la base de
datos en pequeños fragmentos, pero no se ha justificado el hecho ni se han
aportado razones para efectuarlo.
Por ello, desde este punto se va a intentar aportar las razones necesarias para
llevar a cabo esa descomposición, esa fragmentación.
El principal problema de la fragmentación radica en encontrar la unidad
apropiada de distribución. Una relación no es una buena unidad por muchas
razones. Primero, las vistas de la aplicación normalmente son subconjuntos de
relaciones. Además, la localidad de los accesos de las aplicaciones no está
definida sobre relaciones enteras pero sí sobre subconjuntos de las mismas.
Por ello, sería normal considerar como unidad de distribución a estos
subconjuntos de relaciones.
Segundo, si las aplicaciones tienen vistas definidas sobre una determinada
relación (considerándola ahora una unidad de distribución) que reside en varios
sitios de la red, se puede optar por dos alternativas.
Por un lado, la relación no estará replicada y se almacena en un único sitio, o
existe réplica en todos o algunos de los sitios en los cuales reside la aplicación.
Las consecuencias de esta estrategia son la generación de un volumen de
accesos remotos innecesario.
Además, se pueden realizar réplicas innecesarias que causen problemas en la
ejecución de las actualizaciones y puede no ser deseable si el espacio de
almacenamiento está limitado.
Tercero, la descomposición de una relación en fragmentos, tratados cada uno
de ellos como una unidad de distribución, permite el proceso concurrente de las
transacciones.
Teoría de Bases de Datos II 120 UCENM
También la relación de estas relaciones, normalmente, provocará la ejecución
paralela de una consulta al dividirla en una serie de subconsultas que operará
sobre los fragmentos.
Pero la fragmentación también acarrea inconvenientes. Si las aplicaciones
tienen requisitos tales que prevengan la descomposición de la relación en
fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas estén
definidas sobre más de un fragmento pueden sufrir una degradación en el
rendimiento.
Por tanto, puede ser necesario recuperar los datos de dos fragmentos y llevar a
cabo sobre ellos operación de unión y yunto , lo cual es costoso.
Un segundo problema se refiere al control semántico. Como resultado de la
fragmentación los atributos implicados en una dependencia se descomponen
en diferentes fragmentos los cuales pueden destinarse a sitios diferentes.
En este caso, la sencilla tarea de verificar las dependencias puede resultar una
tarea de búsqueda de los datos implicados en un gran número de sitios.
Tipos de fragmentación:
Dado que una relación se corresponde esencialmente con una tabla y la
cuestión consiste en dividirla en fragmentos menores, inmediatamente surgen
dos alternativas lógicas para llevar a cabo el proceso:
La división horizontal y la división vertical.
La división o fragmentación horizontal trabaja sobre las duplas, dividiendo la
relación en subrelaciones que contienen un subconjunto de las duplas que
alberga la primera.
La fragmentación vertical, en cambio, se basa en los atributos de la relación
para efectuar la división.
Teoría de Bases de Datos II 121 UCENM
Estos dos tipos de partición podrían considerarse los fundamentales y básicos.
Sin embargo, existen otras alternativas.
Fundamentalmente, se habla de fragmentación mixta o híbrida cuando el
proceso de partición hace uso de los dos tipos anteriores.
La fragmentación mixta puede llevarse a cabo de tres formas diferentes:
desarrollando primero la fragmentación vertical y, posteriormente, aplicando la
partición horizontal sobre los fragmentos verticales (denominada partición VH),
o aplicando primero una división horizontal para luego, sobre los fragmentos
generados, desarrollar una fragmentación vertical (llamada partición HV), o
bien, de forma directa considerando la semántica de las transacciones.
Otro enfoque distinto y relativamente nuevo, consiste en aplicar sobre una
relación, de forma simultánea y no secuencial, la fragmentación horizontal y la
fragmentación vertical; en este caso, se generara una rejilla y los fragmentos
formaran las celdas de esa rejilla, cada celda será exactamente un fragmento
vertical y un fragmento horizontal (nótese que en este caso el grado de
fragmentación alcanzado es máximo, y no por ello la descomposición resultará
más eficiente).
Puede observarse como los casos C y D se basan en la mencionada
generación de la rejilla, con la diferencia que en el primero de ellos se produce
una fusión, una desfragmentación de las celdas, agrupándolas de la manera
más adecuada para obtener mayor rendimiento, ya que los fragmentos
generados son muy pequeños.
En el segundo caso se asignan las celdas a los sitios y luego se realiza una
rigurosa optimización de cada sitio. El caso E sería aquel en el que se utiliza la
fragmentación VH o la fragmentación HV.
Teoría de Bases de Datos II 122 UCENM
Enfoques para realizar el diseño distributivo.
Grado de fragmentación.
Cuando se va a fragmentar una base de datos deberíamos pesar qué grado de
fragmentación va a alcanzar, ya que éste será un factor que influirá
notablemente en el desarrollo de la ejecución de las consultas.
El grado de fragmentación puede variar desde una ausencia de la división,
considerando a las relaciones unidades de fragmentación; o bien, fragmentar a
un grado en el cada Dupla o atributo forme un fragmento. Ante estos dos casos
extremos, evidentemente se ha de buscar un compromiso intermedio, el cual
debería establecerse sobre las características de las aplicaciones que hacen
uso de la base de datos.
Dichas características se podrán formalizar en una serie de parámetros. De
acuerdo con sus valores, se podrá establecer el grado de fragmentación del
banco de datos.
Distintos tipos de fragmentación.
Grado de Fragmentación
Cuando se va a fragmentar una base de datos deberíamos sopesar qué grado
de fragmentación va a alcanzar, ya que éste será un factor que influirá
notablemente en el desarrollo de la ejecución de las consultas.
El grado de fragmentación puede variar desde una ausencia de la división,
considerando a las relaciones unidades de fragmentación; o bien, fragmentar a
un grado en el cada Dupla o atributo forme un fragmento.
Ante estos dos casos extremos, evidentemente se ha de buscar un
compromiso intermedio, el cual debería establecerse sobre las características
de las aplicaciones que hacen uso de la base de datos.
Teoría de Bases de Datos II 123 UCENM
Dichas características se podrán formalizar en una serie de parámetros. De
acuerdo con sus valores, se podrá establecer el grado de fragmentación del
banco de datos.
Reglas de corrección de la fragmentación
A continuación se enuncian las tres reglas que se han de cumplir durante el
proceso de fragmentación, las cuales asegurarán la ausencia de cambios
semánticos en la base de datos durante el proceso.
Compleción:
Si una relación 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
relación global se proyectan sobre los fragmentos sin pérdida alguna. Tenga en
cuenta que en el caso horizontal el elemento de datos, normalmente, es una
dupla, mientras que en el caso vertical es un atributo.
Reconstrucción:
Si una relación 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 fragmentación. La reconstrucción de
la relación a partir de sus fragmentos asegura la preservación de las
restricciones definidas sobre los datos en forma de dependencias.
Disyunción. :
Si una relación R se descompone horizontalmente en una serie de fragmentos
R1, R2, ..., Rn, y un elemento de datos di se encuentra en algún fragmento Rj,
entonces no se encuentra en otro fragmento Rk (k j). Esta regla asegura que
los fragmentos horizontales sean disjuntos.
Teoría de Bases de Datos II 124 UCENM
Si una relación R se descompone verticalmente, sus atributos primarios clave
normalmente se repiten en todos sus fragmentos.
Alternativas de asignación
Partiendo del supuesto que el banco de datos se haya fragmentado
correctamente, habrá que decidir sobre la manera de asignar los fragmentos a
los distintos sitios de la red.
Cuando una serie de datos se asignan, éstos pueden replicarse para mantener
una copia. Las razones para la réplica giran en torno a la seguridad y a la
eficiencia de las consultas de lectura. Si existen muchas reproducciones de un
elemento de datos, en caso de fallo en el sistema se podría acceder a esos
datos ubicados en sitios distintos. Además, las consultas que acceden a los
mismos datos pueden ejecutarse en paralelo, ya que habrá copias en
diferentes sitios.
Por otra parte, la ejecución de consultas de actualización, de escritura,
implicaría la actualización de todas las copias que existan en la red, cuyo
proceso puede resultar problemático y complicado. Por tanto, un buen
parámetro para afrontar el grado de réplica consistiría en sopesar la cantidad
de consultas de lectura que se efectuarán, así como el número de consultas de
escritura que se llevarán a cabo.
En una red donde las consultas que se procesen sean mayoritariamente de
lectura, se podría alcanzar un alto grado de réplica, no así en el caso contrario.
Una base de datos fragmentada es aquella donde no existe réplica alguna. Los
fragmentos se alojan en sitios donde únicamente existe una copia de cada uno
de ellos a lo largo de toda la red.
En caso de réplica, podemos considerar una base de datos totalmente
replicada, donde existe una copia de todo el banco de datos en cada sitio, o
considerar una base de datos parcialmente replicada donde existan copias de
los fragmentos ubicados en diferentes sitios.
Teoría de Bases de Datos II 125 UCENM
El número de copias de un fragmento será una de las posibles entradas a los
algoritmos de asignación, o una variable de decisión cuyo valor lo determine el
algoritmo. La figura de ejemplo, compara las tres alternativas de réplica con
respecto a distintas funciones de un sistema de base de datos distribuido.
Réplica total
Réplica
parcial Partición
Procesamiento de
consultas fácil dificultad similar
Gestión del directorio fácil o inexistente dificultad similar
Control de concurrencia moderado difícil fácil
Seguridad muy alta alta baja
\Realidad posible aplicación realista posible
aplicación
Información necesaria
Un aspecto importante en el diseño de la distribución es la cantidad de factores
que contribuyen a un diseño óptimo. La organización lógica de la base de
datos, la localización de las aplicaciones, las características de acceso de las
aplicaciones a la base de datos y las características del sistema en cada sitio,
tienen una decisiva influencia sobre la distribución.
La información necesaria para el diseño de la distribución puede dividirse en
cuatro categorías: la información del banco de datos, la información de la
aplicación, la información sobre la red de ordenadores y la información sobre
los ordenadores en sí. Las dos últimas son de carácter cuantitativo y servirán,
principalmente, para desarrollar el proceso de asignación. Se entrará en detalle
sobre la información empleada cuando se aborden los distintos algoritmos de
fragmentación y asignación.
Teoría de Bases de Datos II 126 UCENM
Fragmentación Horizontal:
Como se ha explicada anteriormente, la fragmentación horizontal se realiza
sobre las duplas de la relación. Cada fragmento será un subconjunto de las
duplas de la relación.
Existen dos variantes de la fragmentación horizontal: la primaria y la derivada.
La fragmentación horizontal primaria de una relación se desarrolla empleando
los predicados definidos en esa relación. Por el contrario, la fragmentación
horizontal derivada consiste en dividir una relación partiendo de los predicados
definidos sobre alguna otra.
Información necesaria para la fragmentación horizontal
Información sobre la base de datos.
Esta información implica al esquema conceptual global. Es importante señalar
cómo las relaciones de la base de datos se conectan con otras. En una
conexión de relaciones normalmente se denomina relación propietaria a
aquella situada en la cola del enlace, mientras que se llama relación miembro a
la ubicada en la cabecera del vínculo.
Dicho de otra forma podemos pensar en relaciones de origen cuando nos
refiramos a las propietarias y relaciones destino cuando lo hagamos con las
miembro. Definiremos dos funciones: propietaria y miembro, las cuales
proyectarán un conjunto de enlaces sobre un conjunto de relaciones.
Además, dado un enlace, devolverán el miembro y el propietario de la relación,
respectivamente. La información cuantitativa necesaria gira en torno a la
cardinalidad de cada relación, notada como card(R).
Teoría de Bases de Datos II 127 UCENM
Información sobre la aplicación.
Necesitaremos tanto información cualitativa como cuantitativa. La información
cualitativa guiará la fragmentación, mientras que la cuantitativa se necesitará
en los modelos de asignación.
La principal información de carácter cualitativo son los predicados empleados
en las consultas de usuario. Si no fuese posible investigar todas las
aplicaciones para determinar estos predicados, al menos se deberían investigar
las más importantes.
Podemos pensar en la regla "80/20" para guiarnos en nuestro análisis, esta
regla dice que el 20% de las consultas existentes acceden al 80% de los datos.
Llegados a este punto, sería interesante determinar los predicados simples.
A parte de los predicados simples, las consultas emplean predicados más
complejos resultado de combinaciones lógicas de los simples.
Una combinación especialmente interesante es la conjunción de predicados
simples, al predicado resultante se le denomina predicado mintérmino.
Partiendo de que siempre es posible transformar una expresión lógica en su
forma normal conjuntiva, usaremos los predicados mintérmino en los algoritmos
para no causar ninguna pérdida de generalidad.
Sobre la información cuantitativa necesaria relativa a las aplicaciones,
necesitaremos definir dos conjuntos de datos.
Selectividad mintérmino:
Es el número de duplas de una relación a las que accede una consulta de
acuerdo a un predicado mintérmino dado. Por ejemplo, en el ejemplo anterior,
la selectividad de m6 es 0 ya que no existe ninguna dupla que satisfaga las
condiciones; en cambio, la selectividad de m1 es 2. Notaremos la selectividad
de un mintérmino mi como sel(mi).
Teoría de Bases de Datos II 128 UCENM
Frecuencia de acceso:
Es la frecuencia con la que un usuario accede a los datos. Si Q = {q1, q2, ...,
qq} es un conjunto de consultas de usuario, acc(qi) indica la frecuencia de
acceso a la consulta qi en un periodo dado.
Fragmentación horizontal primaria
Antes de presentar un algoritmo formal que lleve a cabo la fragmentación
horizontal, intentaremos explicar de manera intuitiva los procesos de
fragmentación horizontal primaria y derivada.
La fragmentación horizontal primaria se define como una operación de
selección de las relaciones propietarias del esquema de la base de datos
Ahora definiremos la fragmentación horizontal más formalmente. Un fragmento
horizontal Ri de una relación R contiene todas las duplas de R que satisfacen
un predicado mintérmino mí. Por tanto, dado un conjunto de predicados
mintérmino M, existen tantos fragmentos horizontales de la relación R como
predicados mintérmino.
Este conjunto de fragmentos horizontales también se conocen como conjuntos
de fragmentos mintérmino. En los párrafos siguientes se asumirá que la
definición de fragmentos horizontales se basa en los predicados mintérmino.
Además, el primer paso para el algoritmo de fragmentación consiste en
establecer un conjunto de predicados con ciertas propiedades.
Un aspecto importante de los predicados simples es su compleción, así como
su minimalidad. Un conjunto de predicados simples Pr se dice que es completo
si y solo si existe una probabilidad idéntica de acceder por cada aplicación a
cualquier par de duplas pertenecientes a cualquier fragmento mintérmino que
se define de acuerdo con Pr. Se puede apreciar como la definición de
compleción de un conjunto de predicados simples difiere de la regla de
compleción de la fragmentación.
Teoría de Bases de Datos II 129 UCENM
El segundo paso en el proceso de fragmentación primaria consiste en derivar el
conjunto de predicados mintérmino que pueden definirse sobre los predicados
del conjunto Pr'. Estos predicados mintérmino establecen los fragmentos
candidatos para el proceso de asignación.
El establecimiento de los predicados mintérmino es trivial:
La dificultad radica en el tamaño del conjunto de predicados mintérmino, que
puede ser muy grande (de hecho, exponencial respecto al número de
predicados simples). En el paso siguiente se presentarán formas de reducir el
número de predicados mintérmino necesarios para la fragmentación.
El tercer paso aborda, como ya se ha citado, la eliminación de algunos
fragmentos mintérmino que puedan ser redundantes.
Esta eliminación se desarrolla identificando aquellos mintérminos que puedan
resultar contradictorios sobre un conjunto de implicaciones.
Fragmentación horizontal derivada
Una fragmentación horizontal derivada se define sobre una relación miembro
de acuerdo a una operación de selección especificada sobre su propietaria. Se
deben dejar claros dos puntos.
Primero, el enlace entre las relaciones propietaria y miembro se define como un
equi-yunto. Segundo, un equi-yunto puede desarrollarse a través de
semiyuntos. Este segundo punto es especialmente importante para nuestros
propósitos, ya que deseamos fraccionar una relación miembro según la
fragmentación de su propietaria, además es necesario que el fragmento
resultante se defina únicamente sobre los atributos de la relación miembro.
Teoría de Bases de Datos II 130 UCENM
Las tres entradas necesarias para desarrollar la fragmentación horizontal
derivada son las siguientes:
El conjunto de particiones de la relación propietaria, la relación miembro y el
conjunto se predicados resultados de aplicar el semi-yunto entre la propietaria y
la miembro.
El algoritmo de fragmentación resulta tan trivial que no se ve la necesidad de
entrar en detalles.
Existe una posible complicación que necesita nuestro estudio. En un esquema
de base de datos, resulta frecuente que existan más de dos enlaces sobre una
relación R. En este caso, aparecen más de una posibilidad de fragmentación
horizontal derivada.
La decisión para elegir una u otra se basa en dos criterios: Uno, la
fragmentación con mejores características de yunto. Dos, la fragmentación
empleada en más aplicaciones.
Discutamos el segundo criterio primero. Resulta sencillo de establecer si
tomamos en consideración la frecuencia con la que cada aplicación accede a
los datos. Si es posible, deberíamos intentar facilitar el acceso a los usuarios
que hagan mayor uso de los datos para, de esta manera, minimizar el impacto
total del rendimiento del sistema.
Grafo de yuntos entre fragmentos.
El primer criterio, sin embargo, no es tan sencillo. Considere, por ejemplo, la
fragmentación expuesta en el ejemplo 8. El objetivo de esta fragmentación
consiste en beneficiar a la consulta que haga uso de las dos relaciones al
Teoría de Bases de Datos II 131 UCENM
poder realizarse el yunto de CLIENTES y PROVINC sobre relaciones más
pequeñas (es decir, fragmentos), y posibilitar la confección de yuntos de
manera distribuida.
El primer aspecto resulta obvio. Los fragmentos de CLIENTES son más
pequeños que la propia relación CLIENTES. Por tanto, resultará más rápido
llevar a cabo el yunto de un fragmento de PROVINC con otro de CLIENTES
que trabajar con las propias relaciones.
El segundo punto, sin embargo, es más importante ya que es la esencia de las
bases de datos distribuidas. Si, además de estar ejecutando un número de
consultas en diferentes sitios, podemos ejecutar una consulta en paralelo, se
espera que el tiempo de respuesta del sistema aumente.
En el caso de yuntos, esto es posible bajo ciertas circunstancias. Considere,
por ejemplo, el grafo de yunto (los enlaces) entre los fragmentos de CLIENTES
y la derivada PROVINC. Hay únicamente un enlace entrando o saliendo de un
fragmento. De ahí, que se denomine a este grafo, grafo simple.
La ventaja de este diseño donde la relación de yunto entre los fragmentos es
simple, radica en la asignación a un sitio tanto de la propietaria como de la
miembro y los yuntos entre pares diferentes de fragmentos pueden realizarse
independientemente y en paralelo. Desgraciadamente, la obtención de grafos
de yunto simples no siempre es posible.
En tal caso, la mejor alternativa sería realizar un diseño que provoque un grafo
de yuntos fragmentados. Un grafo fragmentado consiste en dos o más
subgrafos que no están enlazados entre ellos. Por tanto, los fragmentos que se
obtengan no se distribuirán para ejecuciones paralelas de un modo tan fácil
como aquellos obtenidos a través de grafos simples, pero su asignación aún
será posible.
Teoría de Bases de Datos II 132 UCENM
Procederemos ahora a probar la corrección de los algoritmos presentados con
respecto a los tres criterios enunciados:
Compleción:
La compleción de una fragmentación horizontal primaria se basa en la
selección de los predicados a usar. En la medida que los predicados
seleccionados sean completos, se garantizará que el resultado de la
fragmentación también lo será.
Partiendo de la base que el algoritmo de fragmentación es un conjunto de
predicados completos y mínimos Pr', se garantiza la compleción siempre que
no aparezcan errores al realizar la definición de Pr'. La compleción de una
fragmentación horizontal derivada es algo más difícil de definir.
La dificultad viene dada por el hecho de que los predicados que intervienen en
la fragmentación forman parte de dos relaciones. Definamos la regla de
compleción formalmente. Sea R la relación miembro de un enlace cuya
propietaria es la relación S, la cual está fragmentada como FS = {S1, S2, ...,
Sw}. Además, sea A el atributo de yunto entre R y S. Entonces para cada dupla
t de R, existirá una dupla t' de S tal que t[A] = t'[A].
Reconstrucción:
La reconstrucción de una relación global a partir de sus fragmentos se
desarrolla con el operador de unión tanto para la fragmentación horizontal
primaria como para la derivada.
Disyunción:
Resulta sencillo establecer la disyunción de la fragmentación tanto para la
primaria como para la derivada. En el primer caso, la disyunción se garantiza
en la medida en que los predicados mintérmino que determinan la
Teoría de Bases de Datos II 133 UCENM
fragmentación son mutuamente exclusivos. En la fragmentación derivada, sin
embargo, implica un semi-yunto que añade complejidad al asunto.
La disyunción puede garantizarse si el grafo de yunto es simple. Si no es
simple, será necesario investigar los valores de las Duplas.
En general, no se desea juntar una dupla de una relación miembro con dos o
más duplas de una relación propietaria cuando estas duplas se encuentran en
fragmentos diferentes a los de la propietaria.
Esto no es fácil de establecer, e ilustra por qué los esquemas de la
fragmentación derivada que generan un grafo de yunto simple son siempre
más atractivos.
Fragmentación Vertical:
Recuérdese que la fragmentación vertical de una relación R produce una serie
de fragmentos R1, R2, ..., Rr, cada uno de los cuales contiene un subconjunto
de los atributos de R así como la clave primaria de R.
El objetivo de la fragmentación vertical consiste en dividir la relación en un
conjunto de relaciones más pequeñas tal que algunas de las aplicaciones de
usuario sólo hagan uso de un fragmento. Sobre este marco, una fragmentación
óptima es aquella que produce un esquema de división que minimiza el tiempo
de ejecución de las aplicaciones que emplean esos fragmentos.
La partición vertical resulta más complicada que la horizontal. Esto se debe al
aumento del número total de alternativas que tenemos disponibles. Por
ejemplo, en la partición horizontal, si el número total de predicados simples de
Pr es n, existen 2n predicados mintérminos posibles que puedan definirse.
Además, sabemos que algunos de estos predicados resultarán contradictorios
con algunas de las aplicaciones existentes, por lo que podremos reducir el
número inicial.
Teoría de Bases de Datos II 134 UCENM
En el caso vertical, si una relación tiene m atributos clave no primarios, el
número de posibles fragmentos es igual a B(m), es decir el m-ésimo número de
Bell [3]. Para valores grandes de m, B(m) mm; por ejemplo, para m = 10, B(m)
115.000, para m = 15, B(m) 109, para m = 30, B(m) = 1023.
Estos valores indican que la obtención de una solución óptima de la
fragmentación vertical resultará una tarea inútil, sino nos apoyamos en el uso
de heurísticos. Existen dos enfoques heurísticos para la fragmentación vertical
de relaciones:
Agrupación:
Comienza asignando cada atributo a un fragmento, y en cada paso, junta
algunos de los fragmentos hasta que satisface un determinado criterio. La
agrupación sugirió en principio para bases de datos centralizadas y se usó
posteriormente para las bases de datos distribuidas.
Escisión:
A partir de la relación se deciden que fragmentos resultan mejores, basándose
en las características de acceso de las aplicaciones a los atributos. Esta
técnica se presentó, también, para bases de datos centralizadas.
Posteriormente, se extendió al entorno distribuido.
En este documento se tratará únicamente la técnica de escisión, ya que es más
apropiada para la estrategia descendente y porque resulta más probable
encontrar la solución para la relación entera que a partir de un conjunto de
fragmentos con un único atributo. Además, la escisión genera fragmentos no
solapados mientras que la agrupación normalmente produce fragmentos
solapados.
Dentro del contexto de los sistemas de bases de datos distribuidos, son
preferibles los fragmentos no solapados por razones obvias. Evidentemente,
los fragmentos no solapados se refieren únicamente a atributos clave no
primarios.
Teoría de Bases de Datos II 135 UCENM
Antes de comenzar, vamos a aclarar un problema: la réplica de las claves de la
relación en los fragmentos. Esta es una característica de la fragmentación
vertical que permite la reconstrucción de la relación global.
Por tanto, la escisión considera únicamente aquellos atributos que no son parte
de la clave primaria.
La réplica de los atributos clave supone una gran ventaja, a pesar de los
problemas que pueda causar.
La ventaja está relacionada con el esfuerzo para mantener la integridad
semántica. Tenga en cuenta que cada dependencia (funcional, multivaluada ...)
es, de hecho, una restricción que influye sobre el valor de los atributos de las
respectivas relaciones en todo momento.
También muchas de estas dependencias implican a los atributos clave de una
relación. Si queremos diseñar una base de datos tal que los atributos clave
sean parte de una fragmento que está ubicado en un sitio, y los atributos
relacionados sean parte de otro fragmento asignado a un segundo sitio, cada
petición de actualización provocará la verificación de integridad que necesitará
de una comunicación entre esos sitios.
La réplica de los atributos clave de cada fragmento reduce esta problemática,
pero no elimina toda su complejidad, ya que la comunicación puede ser
necesaria para las restricciones de integridad que implican a las claves
primarias, así como para el control de concurrencia.
Una posible alternativa a la réplica de los atributos clave es el empleo de
identificadores de duplas, que son valores únicos asignados por el sistema a
las duplas de una relación. Mientras el sistema mantenga los identificadores,
los fragmentos permanecerán disjuntos.
Teoría de Bases de Datos II 136 UCENM
Información necesaria para la fragmentación vertical
La principal información que necesitaremos se referirá a las aplicaciones. Por
tanto, este punto tratará de especificar la información que de una aplicación
que funciona sobre la base de datos podamos extraer. Teniendo en cuenta que
la fragmentación vertical coloca en un fragmento aquellos atributos a los que se
accede de manera simultánea, necesitaremos alguna medida que defina con
más precisión el concepto de simultaneidad.
Esta medida es la afinidad de los atributos, que indica la relación estrecha
existente entre los atributos. Desgraciadamente, no es muy realista esperar
que el diseñador o los usuarios puedan especificar estos valores.
Por ello, presentaremos una forma por la cual obtengamos esos valores
partiendo de datos más básicos.
El principal dato necesario relativo a las aplicaciones es la frecuencia de
acceso. Sea Q = {q1, q2, ..., qq} el conjunto de consultas de usuario
(aplicaciones) que funcionan sobre una relación R(A1, A2, ..., An).
Los vectores uso (qi,) pueden definirse muy fácilmente para cada aplicación
siempre que el diseñador conozca las aplicaciones existentes en el sistema. La
regla 80/20 expuesta páginas atrás podría resultar útil para el desarrollo de
esta tarea.
Los valores del uso de los atributos en general no son suficientes para
desarrollar la base de la escisión y la fragmentación de los atributos, ya que
estos valores no representan el peso de las frecuencias de la aplicación.
La dimensión de esta frecuencia puede incluirse en la definición de la medida
de los atributos afines afd(Ai, Aj), la cual mide el límite entre dos atributos de
una relación de acuerdo a cómo las aplicaciones acceden a ellos.
Teoría de Bases de Datos II 137 UCENM
Fragmentación mixta o híbrida:
En muchos casos la fragmentación vertical u horizontal del esquema de la base
de datos no será suficiente para satisfacer los requisitos de las aplicaciones.
Como ya se citó al comienzo de este documento podemos combinar ambas,
utilizando por ello la denominada fragmentación mixta. Cuando al proceso de
fragmentación vertical le sigue una horizontal, es decir, se fragmentan
horizontalmente los fragmentos verticales resultantes, se habla de la
fragmentación mixta HV. En el caso contrario, estaremos ante una
fragmentación VH. Una característica común a ambas es la generación de
árboles que representan la estructura de fragmentación.
Considere, por ejemplo, la relación PROVINC. Recordará que se le aplicó una
fragmentación horizontal de acuerdo al valor del atributo CCODZONA
resultando cuatro fragmentos horizontales. Podríamos pensar en aplicarle una
nueva fragmentación de carácter vertical. Entonces resultarían cuatro
fragmentos horizontales divididos, por ejemplo, en dos fragmentos verticales.
En este caso el número total de fragmentos ascendería, lógicamente, a ocho.
Estructura arbórea de fragmentación mixta.
No se desea entrar en excesivos detalles sobre las reglas y condiciones para
efectuar la fragmentación mixta. Entre otras razones porque, tanto a la
fragmentación HV como la fragmentación VH, se le pueden aplicar los mismos
criterios y reglas que a la fragmentación horizontal y vertical.
Es decir, volviendo al ejemplo anterior, al cual le practicamos la fragmentación
HV, al realizar la fragmentación horizontal tal como se ha expuesto, lo que se
obtienen no son más que subrelaciones, la unión de las cuales da lugar a la
relación PROVINC. Por tanto, para fragmentar cada subrelación sería
perfectamente viable aplicarle el método de fragmentación vertical que se ha
desarrollado. Como, en este caso, se han querido generar dos fragmentos
verticales por cada uno horizontal, simplemente deberíamos confeccionar la
Teoría de Bases de Datos II 138 UCENM
matriz de grupos afines (a través del algoritmo BEA) para cada fragmento
horizontal y aplicarle, posteriormente, el algoritmo de fragmentación binaria
PARTICIÓN.
También debe tenerse en cuenta el número de niveles arbóreos que se
generen, es decir, nadie impide que tras realizar una fragmentación VH,
podamos aplicar a los fragmentos resultantes una nueva fragmentación
vertical, y a estos última una nueva fragmentación horizontal, etc. Dicho
número puede ser grande, pero también será ciertamente finito.
En el caso horizontal, el nivel máximo de profundidad se alcanzará cuando
cada fragmento albergue una única dupla, mientras que en el caso vertical el
final llegará cuando cada fragmento contenga un único atributo.
Sin embargo, aunque no deba tomarse como dogma, el número de niveles no
debería superar el par (VH y HV). El porqué de esta afirmación es bien sencillo,
piense, por ejemplo, en el coste que supondría realizar la unión o el yunto de
una relación con fragmentación nivel 7. Evidentemente, el coste sería muy
elevado y ese aumento de rendimiento que se persigue al aplicar estas
técnicas, quizás, no se produzca.
Antes de pasar a estudiar el problema de la asignación se desea comentar la
técnica de fragmentación mixta basada en celdas [2]. Esta técnica se basa en
la generación de celdas de rejilla. Qué es una celda de rejilla, podríamos
definirla como un fragmento horizontal y vertical simultáneo. La técnica aplica
un algoritmo de fragmentación vertical y otro horizontal de manera concurrente
sobre la relación.
Los algoritmos realizan una fragmentación máxima, es decir, se persigue que
en cada celda únicamente haya un atributo y una dupla. Quizá el lector pueda
encontrar el método contradictorio con lo citado anteriormente respecto a la
eficiencia, dada la gran cantidad de fragmentos generados, el número es,
Teoría de Bases de Datos II 139 UCENM
efectivamente, el máximo. Sin embargo, este sólo es el primer paso del
proceso.
Una vez generadas las celdas se aplica un método para optimizar la rejilla
mediante fusión o desfragmentación, de acuerdo, fundamentalmente, a las
aplicaciones que actúen sobre esos fragmentos. El método, por tanto, persigue
una fragmentación la más específica posible acorde con las aplicaciones y los
sitios existentes en la red.
Información necesaria
En esta etapa de la asignación, necesitaremos datos cuantitativos sobre la
base de datos, las aplicaciones que funcionan sobre ella, la red de
comunicaciones, las características de proceso, y el límite de almacenamiento
de cada sitio de la red.
Procederemos a discutirlos en detalle.
Información de la base de datos. Para desarrollar la fragmentación horizontal,
definimos la selectividad de los mintérminos. Ahora, necesitamos extender esta
definición a los fragmentos y definir la selectividad de un fragmento Fj con
respecto a una consulta qi. Es el número de duplas de Fj a las que se necesita
acceder para procesar qi. Este valor lo notaremos como seli(Fj). Otro elemento
informativo de los fragmentos de la base de datos es su tamaño.
El tamaño de un fragmento Fj viene dado por tamaño (Fj) = card(Fj)*long(Fj),
donde long(Fj) es la longitud (en octetos) de una tupla del fragmento Ej.
Información de los sitios. Sobre cada ordenador necesitamos conocer sus
capacidades de procesamiento y almacenamiento. Obviamente, estos valores
pueden calcularse a través de funciones elaboradas o por simples
estimaciones.
Teoría de Bases de Datos II 140 UCENM
La unidad de coste de almacenar datos en el sitio Sk será denotada como
UCAk. Así mismo, especificaremos como medida de coste UPTk al coste de
procesar una unidad de trabajo en el sitio Sk. La unidad de trabajo debería ser
idéntica a aquella utilizada en las medidas RR y UR.
Información sobre la red. En nuestro modelo asumiremos la existencia de una
red simple donde el coste de comunicaciones se define respecto a una trama
de datos.
Entonces gij nota el coste de comunicación por trama entre los sitios Si y Sj.
Para permitir el cálculo del número de mensajes, usaremos tamaño como el
tamaño (en octetos) de una trama.
Es evidente que existen modelos de red mucho más elaborados que toman en
cuenta las capacidades del canal, las distancias entre sitios, las características
del protocolo, etc. Sin embargo, se cree que la derivación de estas ecuaciones
se sale fuera de este documento.
Procesamiento distribuido de consultas
Existen varios medios para calcular la respuesta a una consulta. En el caso de
sistemas centralizado, el criterio principal para determinar el costo de una
estrategia específica es el número de accesos al disco. En un sistema
distribuido es preciso tener en cuenta otros factores, como son:
El costo de transmisión de datos en la red.
El beneficio potencial que supondría en la ejecución el que varias
localidades procesaran en paralelo partes de la consulta.
El costo relativo de la transferencia de datos en la red y la transferencia de
datos entre la memoria y el disco varía en forma considerable, dependiendo del
tipo de red y de la velocidad de los discos. Por tanto, en un caso general, no
podemos tener en cuenta solo los costos del disco o los de la red. Es necesario
llegar a un equilibrio adecuado entre los dos.
Teoría de Bases de Datos II 141 UCENM
Repetición y fragmentación
Considere una consulta muy sencilla: encontrar todas las duplas de la relación
depósito. Aunque la consulta es muy simple, de hecho es trivial; su
procesamiento no es trivial, ya que es posible que la relación depósito esté
fragmentada, repetido o las dos cosas, como ya se vio.
Si la relación deposito está repetida, es preciso decidir qué copia se va a
utilizar.
Si ninguna de las copias está fragmentada, se elige la copia que implique
costos de transmisión más reducidos. Pero si una copia está fragmentada, la
elección no es tan sencilla, ya que es preciso calcular varios productos o
uniones para reconstruir la relación depósito.
En tal caso, el número de estrategias para este ejemplo sencillo puede ser
grande. De hecho, la elección de una estrategia puede ser una tarea tan
compleja como hacer una consulta arbitraria.
Procesamiento de intersección simple
Considere la expresión en álgebra relacional:
cliente x deposito x sucursal
Suponemos que ninguna de las tres relaciones está repetida o fragmentada y
que cliente está almacenada en la localidad Lc, deposito en la Ld y sucursal en
la Lb. Sea Li la localidad donde se originó la consulta. El sistema debe producir
el resultado en la localidad Li. Entre las posibles estrategias para procesar esta
consulta se encuentran las siguientes:
Enviar copias de las tres relaciones a la localidad Li. Al emplear las
técnicas de procesamiento de consulta, escoger una estrategia para
procesar en forma local la consulta completa en Li.
Enviar una copia de la relación cliente a la localidad Li y calcular cliente
x depósito de Ld. Enviar cliente x depósito de Ld a Lb, donde se calcula
Teoría de Bases de Datos II 142 UCENM
(cliente x depósito) x sucursal. El resultado de esta operación es enviado
a Li.
Pueden elaborarse estrategias similares a la anterior al intercambiar los
papeles de Lc, Ld y Lb.
No puede garantizarse que una estrategia sea la mejor en todos los casos.
Entre los factores que deben tomarse en cuenta están la cantidad de datos que
debe transmitirse, el costo de transmitir un bloque de datos entre dos
localidades determinadas y la velocidad de procesamiento relativa en cada
localidad.
Estrategias de intersección utilizando el paralelismo
Considere un producto de cuatro relaciones:
r1 x r2 r3 r4
Donde la relación r1 está almacenada en la localidad Li. Suponemos que el
resultado ha de presentarse en la localidad Li. Existen, por supuesto muchas
estrategias que se pueden considerar.
Un método atractivo sería utilizar la estrategia de intersección encauzada. Por
ejemplo, se puede enviar r1 a L2 y calcular r1 x r2 en L2. Al mismo tiempo se
puede enviar r3 a L4 y calcular r3 x r4 en L4.
La localidad L2 puede enviar duplas de (r1 x r2) a Li conforme se vayan
produciendo, en vez de esperar a que se calcule el producto completo. De
forma similar, L4 pude enviar duplas de (r3 x r4) a Li. Una vez que las duplas
de (r1 x r2) y (r3 x r4) lleguen a Li, esta localidad podrá empezar el cálculo de
(r1 x r2) x (r3 x r4) en paralelo con el cálculo de (r1 x r2) en L2 y de (r3 x r4) en
L4.
Estrategia de semintersección
Suponer que deseamos calcular la expresión r1 x r2, donde r1 y r2 están
almacenados en las localidades L1 y L2 respectivamente. Sean R1 y R2 los
Teoría de Bases de Datos II 143 UCENM
esquemas de r1 y r2. Suponer que queremos obtener el resultado en L1. Si hay
muchas duplas de r2 que no interseccionan con ninguna de r1, entonces el
envío de r2 a S1 requiere el envío de duplas que no contribuyen al resultado.
Es conveniente borrar tales duplas antes de enviar los datos a L1,
particularmente si los costos de la red son muy elevados.
Para hacerlo vemos la siguiente estrategia:
Calcular temp1 " r1 " r2 (r1) en L1.
enviar temp1 de L1 a L2.
Calcular temp2 r2 x temp1 en L2.
Enviar temp2 de L2 a L1.
Calcular r1 x temp2 en L1.
La estrategia anterior es ventajosa particularmente cuando en el producto
participan relativamente pocas duplas de r2. Es probable que suceda esta
situación si r1 es el resultado de una expresión de álgebra relacional que
contenga la selección.
Esta estrategia es conocida como una estrategia de semiproducto, después del
operador de semiproducto, indicado por x, de álgebra relacional.
Conclusiones y consideraciones:
A lo largo de este documento se ha intentado dar una visión global y genérica
de los problemas y características que contiene el diseño de una base de datos
distribuida. Se ha hecho especial hincapié en las técnicas de fragmentación
horizontal y vertical a través de métodos y algoritmos muy frecuentes en la
literatura referida al tema.
Se espera que el lector no haya tenido demasiados problemas para su
comprensión, las técnicas son sencillas y se ha procurado incluir distintos
Teoría de Bases de Datos II 144 UCENM
ejemplos para facilitar el entendimiento. Igualmente, la puesta en práctica de
los algoritmos, es decir, su codificación, no es un proceso complicado si se
poseen nociones en el desarrollo de algoritmos. Piense, por ejemplo, que los
dos algoritmos de partición vertical presentados, no hacen más que manipular
matrices.
También debería tenerse presente la existencia de enfoques de fragmentación
distintos y, posiblemente, más complejos, pero se debe pensar que más
eficientes. Sean, por ejemplo, las técnicas de fragmentación vertical basadas
en grafos, como el algoritmo de Navathe y Ra que genera en un solo pasó
fragmentos verticales.
Además, están apareciendo métodos de fragmentación mixta como el que se
ha comentado. Si bien, estos métodos son enfoques formales más que
prácticos, desarrollados por insignes investigadores en universidades, por
tanto, lejos todavía de su desarrollo comercial.
Pese a la aparición de los métodos de bases de datos distribuidas hace ya
años, parece que el salto de lo centralizado a lo distribuido a escala comercial
está por venir.
Todavía no se ha extendido suficientemente el esquema distribuido, pero se
espera que próximamente se produzca el avance definitivo. Considere los dos
componentes básicos de los sistemas de bases de datos distribuidos (la propia
base de datos y la red de ordenadores) y piense en la situación actual de la
informática.
Si las bases de datos es una de las ramas más antiguas e importantes de la
informática, muchas empresas compran ordenadores para dedicarlos
exclusivamente a la gestión de sus datos (pienso que, prácticamente, en el
100% de las PYMES se produce este hecho) y, como parece ser que se ha
asumido por parte de todo tipo de empresarios los beneficios que acarrea la
conexión de los ordenadores, la instalación de una red, se puede concluir
diciendo que el terreno ya está abonado para su extensión comercial. Sólo falta
Teoría de Bases de Datos II 145 UCENM
que determinadas multinacionales decidan apostar más fuerte por este enfoque
a través de sus famosos sistemas gestores de bases de datos y que se
produzca la consolidación de la resolución de los problemas que el enfoque
distribuido acarrea.
TIPOS DE BASES DE DATOS DISTRIBUIDAS
HETEROGENEA
Las Bases de datos heterogéneas con un alto grado de autonomía local. Cada
nodo en el sistema tiene sus propios usuarios, aplicaciones y datos locales y es
el sistema el que trata con ellos directamente y sólo conecta con otros nodos
en busca de información que
no tiene.
Este tipo de base de datos se suele llamar sistema federado o federación. Se
ha hecho cada día más popular en las organizaciones, tanto por su
escalabilidad, su capacidad de mezclar distintos paquetes software y su
reducido coste al añadir nuevos nodos cuando es necesario. A diferencia de los
sistemas homogéneos, los sistemas heterogéneos pueden incluir diferentes
SGBD en los nodos. Esto los hace atractivos en grandes corporaciones, ya que
pueden mantener sus sistemas heredados antiguos (legacy systems) junto con
los..nuevos..Sistemas.
DDBMS HETEROGÉNEO
Esquema global único.
Modelo de datos y lenguaje de consultas común.
Esquema integrado.
Consultas reales distribuidas.
INTERFAZ HETEROGÉNEA
Acceso en línea a una única base de datos
No hay integración de bases de datos
El acceso usa un modelo de datos; el DBMS, otro
Teoría de Bases de Datos II 146 UCENM
SISTEMA HOMOGÉNEO
Las bases de datos distribuidas homogéneas usan el mismo software de SGBD
y tienen las mismas aplicaciones en cada nodo. Tienen un esquema común y
pueden tener grados diversos de autonomía local. Pueden estar basadas en
cualquier SGBD que soporte estas características, pero no puede haber más
de un SGBD en el sistema. La autonomía local especifica cómo el sistema
funciona desde la perspectiva de los usuarios y programadores.
Por ejemplo:
Podemos tener un sistema con poca o sin autonomía local, donde todas las
peticiones se envían a un nodo central, llamado gateway. Desde aquí se asigna
al nodo que contiene esa información o aplicación requerida. Esto es lo típico
que se ve con los mirrors de sitios web muy populares a los cuales una página
central deriva las peticiones de sus usuarios dependiendo de su origen
geográfico.
Teoría de Bases de Datos II 147 UCENM
CUATRO METAS PARA UN DBMS DISTRIBUIDO
Traiger y sus colegas definieron cuatro metas para un DBMS distribuido, lo que
da un excelente marco de referencia para una investigación de los temas,
problemas y soluciones propuestos para las bases de datos distribuidas. Cada
una de estas metas involucra un aspecto de transparencia.
En un sistema de base de datos distribuida la transparencia significa que las
opciones de consulta y los programas de transacciones quedan aislados de la
administración de la base de datos distribuidos, de forma tal que obtengan las
ventajas del procesamiento distribuido, sin por ello tener que involucrarse en
detalles de la distribución de la base de datos.
Los programadores y los usuarios pueden concentrarse en la naturaleza y en la
lógica del problema de la información que necesitan resolver, no viéndose
obligados a tratar asuntos que corresponden al DDBMS: para simplificar este
análisis, en el resto de este documento nos referiremos a los usuarios de
consulta y a los programas de transacción sólo como transacciones.
Teoría de Bases de Datos II 148 UCENM
Las transacciones necesitan tener acceso a la base de datos vía un DDBMS
que proporcione los cuatro siguientes tipos de transparencia: localización de los
datos, duplicación de los datos, concurrencia y falla.
Lo cual significa que, en forma ideal, la transacción ni siquiera esté consciente
que los datos se encuentran distribuidos. Los cuatro temas de distribución se
manejan tras bambalinas.
TRANSPARENCIA DE LOCALIZACIÓN
Las transacciones necesitan ser independientes de la localización de un
elemento de datos particular. De no ser así, las cuestiones de localización
complicarían la lógica de la transacción.
Considere usted la empresa manufacturera que se utilizó en la Figura 2. Si el
gerente de inventarios desea mover refrigeradores de la Planta A a la Planta B,
deberán modificarse dos registros de inventario.
Suponga que los datos involucrados no están duplicados; pero que datos
puedan estar almacenados en una computadora en cualquiera de las dos
localizaciones. Si el programa que procesa esta transacción no es transparente
en lo que se refiere a localización de los datos, tendrá que considerar cuatro
casos: ambos registros en A, uno en A y uno en B, uno en B y el otro en A o
ambos en B. La lógica de la transacción se confunde por la necesidad de
considerar la localización de los datos.
La lógica sería mucho más complicada para un ejemplo más complejo, en
cualquier caso estas consideraciones son innecesarias e inapropiadas para un
programa de aplicación.
Se puede conseguir la transparencia de localización si los administradores de
transacciones distribuidas (los DTM en la Figura 1) son responsables de
determinar la localización de los datos y de emitir las acciones a los DBM
apropiados, lo cual se puede llevar a cabo si los DTM poseen acceso a los
Teoría de Bases de Datos II 149 UCENM
directorios de las localizaciones de los datos. Si los datos se mueven, sólo el
DTM necesita involucrarse. Todas las transacciones quedan aisladas de la
modificación en la localización.
TRANSPARENCIA DE DUPLICACIÓN
Las transacciones son accesibles a la duplicación si pueden procesarse sin
saber cuántas veces, o incluso si los datos están duplicados. La transacción
puede actuar como si todos los datos estuvieran almacenados sólo una vez en
nada más un nodo.
Con la transparencia de duplicación, se pueden crear nuevos duplicados, o los
duplicados existentes pueden ser eliminados, sin provocar efecto alguno sobre
la transacción del usuario o el procesamiento de la consulta.
Para proporcionar transparencia en la duplicación, los administradores de
transacciones deben traducir las solicitudes de procesamiento de transacción
en acciones para los administradores de la base de datos. Las lecturas son
sencillas, el DTM selecciona uno de los nodos que almacena los datos y emite
una acción para su lectura.
Para facilitar la selección, el DTM pudiera conservar estadísticas sobre el
tiempo que se requiere para leer datos de varios nodos, y seleccionar el nodo
con el mejor rendimiento. Es más complicado la escritura de datos duplicados,
porque el DTM deberá emitir una acción de escritura para cada uno de los
DBM que almacena una copia de dichos datos.
Este análisis supone que cada DTM posee una copia exacta y actualizada de
un directorio que indique la localización de los datos. Sin embargo, aparecen
problemas interesantes, si consideramos lo que ocurriría cuando el directorio
deba modificarse para tomar en cuenta nuevas copias de datos o su
eliminación. Resulta crítica la coordinación.
Teoría de Bases de Datos II 150 UCENM
Todos los directorios deberán ser instalados de forma que ningún DTM piense
que los datos están disponibles antes que así sea (en el caso de lecturas) y
que todos los DTM sepan que los datos están disponibles cuando lo estén (en
el caso de escrituras).
De lo contrario, un DTM pudiera solicitar datos que toda no estén disponibles o
dejar de emitir una orden de escritura a un DBM cuando los datos están
disponibles.
TRANSPARENCIA DE CONCURRENCIA
Aunque múltiples transacciones que involucran la base de datos distribuida se
lleven a cabo al mismo tiempo, los resultados de las transacciones no deberán
afectarse. El DDBMS proporciona transparencia de concurrencia si los
resultados de todas las transacciones concurrentes son consistentes de
manera lógica con los resultados que se habrían obtenido si las transacciones
se hubieran ejecutado una por una, en algún orden serial arbitrario.
Expresada de otra forma, la lógica de las transacciones procesadas en forma
concurrente con otras transacciones deberá de ser la misma que si la
transacción se hubiera procesado sola.
Se han desarrollado dos estrategias para proporcionar control de concurrencia.
Una de ellas conocida como bloqueo distribuido en dos fases, es una extensión
del mecanismo de control de concurrencia. Un segundo método se llama
pedido con sello de recepción. Ambos han sido implementados en productos
DDBMS. Es más común el bloqueo distribuido en dos fases.
TRANSPARENCIA DE FALLAS
La cuarta meta del DDBMS es proporcionar transparencia de fallas, lo que
significa que las transacciones sean procesadas de un modo correcto a pesar
de fallas en la transacción, en el DDBMS, en la red y en la computadora. Frente
Teoría de Bases de Datos II 151 UCENM
a una falla, las transacciones deberán ser atómicas, esto es, ya sea que se
procesen todas las transacciones o ninguna de ellas.
Además, una vez comprometidos los resultados de las transacciones, serán
permanentes.
La transparencia contra fallas es la meta más difícil entre las cuatro. Parte del
problema es que existen muchos tipos distintos de fallas. En un extremo del
espectro habrá un nodo que jamás falla, a veces llamado un nodo perfecto.
En el otro extremo aparece un nodo que falla de una manera del todo
desconocida. Un nodo como éste pudiera comunicar basura a través de la red,
o bien, en razón de su falla, pudiera enviar acciones inapropiadas, pero con
formato válido por la red. Nodos como éstos se conocen como nodos
desquiciados.
Otro tipo de falla corresponde a nodos que se convierten en malévolos, lo cual
significa el nodo tiene el propósito expreso de llevar a cabo una actividad no
autorizada, o de causar daños en forma intencional. Es incluso posible
considerar fallas donde los nodos conspiran unos con otros para hacer caer al
sistema distribuido. A veces se conocen como fallas bizantinas.
Entre los extremos de los nodos perfectos y los nodos desquiciados están los
nodos sensatos. Un nodo sensato es un nodo que puede fallar, pero sólo en
una forma definida y conocida.
El ejemplo más sencillo de un nodo sensato es uno que, o es perfecto, o deja
de responder completo.
Otra razón por la cual la transparencia de falla es tan difícil es que el control de
concurrencia es muy complicado. En un sentido, los problemas de control de
concurrencia se resuelven por medio de recuperaciones de fallas. Es como una
Teoría de Bases de Datos II 152 UCENM
burbuja de aire bajo el tapiz que se empuja de una esquina sólo para volver a
aparecer en otra.
Los mecanismos de control de concurrencia funcionan siempre y cuando no
ocurran fallas en ciertos momentos o en ciertos estados de la base de datos
distribuida, o siempre y cuando se pueda garantizar la recuperación en una
cierta forma, etc. En el caso general de bases de datos divididas y duplicadas
quedan aún por resolver múltiples problemas teóricos y prácticos de puesta en
práctica.
Teoría de Bases de Datos II 153 UCENM
CUESTIONARIO.
1-.¿Que entiende por base de datos dsitribuidas?
2-.¿En que consisten lasTransacciones y Administradores de una DDBMS?
3-.¿Cual es la Diferencia entre un administrador de transacciones y un
administrador de base de datos?
4-.Elabore un cuadro de las Ventajas y desventajas del procesamiento de una
base de datos distribuida.
Teoría de Bases de Datos II 154 UCENM
5-.¿Cual es la Estructura de Base de Datos Distribuidas?
6-.¿Que comprende por Diseño de la distribución?
7-.¿Cuales son los Tipos de fragmentación que existen?
8-.¿Que Reglas de corrección de la fragmentación?
9.-¿Cuáles son los criterios para corrección de los algoritmos?
10-.¿Que tipo de Tipos de Bases de Datos Distribuidas
Hetereogenea..hay?
Teoría de Bases de Datos II 155 UCENM
BASES DE DATOS
PARALELAS
Objetivos del capítulo V
1 Comprender y analizar el concepto Bases Datos
Paralelas.
2 Conocer Diseño de Sistemas paralelos.
3 Conocer la Integración de Bases paralelas.
4 Conocer el procesamiento paralelo.
Teoría de Bases de Datos II 156 UCENM
Bases de Datos Paralelas.
Introducción
De forma general el concepto de paralelismo en las bases de datos lo
podríamos definir como la partición de la base de datos (normalmente a nivel
de relaciones) para poder procesar de forma paralela en distintos discos y con
distintos procesadores una sola operación sobre la base de datos.
Hace unos años este tipo de bases de datos estaban casi descartadas pero
actualmente casi todas las marcas de bases de datos venden este producto
con éxito. Esto se ha debido a:
Los requisitos transaccionales que tienen las empresas han aumentado al
mismo tiempo que ha crecido el empleo de computadoras. Además los sitios
web tienen millones de visitantes para los que se requieren bases de datos
enormes.
Las empresas utilizan cada vez mayores volúmenes de datos para planificar
sus actividades. Las consultas usadas para estos fines son de ayuda a la toma
de decisiones pueden necesitar hasta varios terabytes de datos que no se
pueden manejar con un único procesador en el tiempo necesario.
La naturaleza orientada a conjuntos de las consultas se presta a la
paralelizarían.
Las máquinas paralelas con varios procesadores son relativamente baratas.
El paralelismo se usa para mejorar la velocidad en la ejecución de consultas.
Además el paralelismo se usa para proporcionar dimensionabilidad ya que la
creciente carga de trabajo se trata sin incrementar el tiempo de respuesta pero
incrementando el grado de paralelismo.
Existen cuatro arquitecturas de sistemas paralelos:
De memoria compartida: Todos los procesadores comparten una memoria
común.
Teoría de Bases de Datos II 157 UCENM
De discos compartidos:
Todos los procesadores comparten un conjunto de discos común.
Sin compartimiento:
Los procesadores no comparten ni memoria ni disco.
Jerárquica:
Este modelo es un híbrido de las arquitecturas anteriores.
Paralelismo de E/S
De forma general podemos hablar de paralelismo de E/S cuando hablamos de
divisiones en las relaciones entre varios discos para reducir el tiempo necesario
de su recuperación.
Normalmente la división más común en un entorno de bases de datos paralelas
es la división horizontal. En este tipo de división las duplas de cada relación se
dividen entre varios discos de modo que cada dupla resida en un disco distinto.
Suponiendo que tenemos n discos (D0,D1,…,Dn-
Entre los que se van a dividir los datos, existen varias estrategias de división:
Turno rotatorio:
Se recorre la relación y la i-ésima Dupla se envía al disco Di modo n quedando
una distribución homogénea de las duplas en los discos.
División por asociación:
Se escogen varios atributos del esquema de la relación y se designan como
atributos de división. Se escoge una función de asociación cuyo rango es
{0,1,…,n-1}. Cada dupla de la relación original se asocia en términos de los
atributos de división. Si la función de asociación devuelve i, la dupla de ubica
en el disco DI.
División por rangos: Se distribuye rangos contiguos de valores de los atributos
a cada disco. Para ello se escoge un atributo de división, AD, como vector de
división y la relación se divide de la siguiente manera:
o Sea [vo, v1, …, vn-2] el vector de división con i<j y vi<vj. Considérese una
dupla t
tal que t[A]=x.
o Si x< vo entonces t se ubica en el disco Do.
Teoría de Bases de Datos II 158 UCENM
o Si x≥vn-2 entonces t se ubica en el disco Dn-1.
o Si vi≤x < vi+1 entonces t se ubica en el disco DI+1
Comparativa entre técnicas de división
Cuando ya hemos dividido una relación en varios discos se puede recuperar en
paralelo utilizándolos todos de la misma manera que se puede escribir en
paralelo cuando se está dividiendo una relación. Por lo tanto, cuando se quiera
leer (o escribir) la relación completa ganaremos tiempo gracias al paralelismo.
Además de leer de forma completa una relación
Eisten otro tipo de lecturas o consultas:
Exploración de la relación completa: Ya mencionada Consultas concretas:
Buscan duplas con un determinado valor para un atributo
Concreto.
Consultas de rango:
Buscan duplas con un valor que esté dentro de un rango para un atributo
concreto.
Las técnicas de división explicadas permiten estos tipos de acceso pero con
diferentes
Niveles de eficacia:
Turno rotatorio: Se adapta bien a la exploración completa pero no es eficiente
para consultas concretas y de rango ya que tiene que buscar en todos los
discos.
División por asociación: Este esquema se adapta bien a las consultas
concretas basadas en el atributo de división ya que dirigimos la consulta al
disco que se nos indica la función de asociación para el atributo y el valor del
mismo. También se adapta bien a una exploración completa si la función de
asociación reparte bien las duplas en los discos. Sin embargo no es adecuada
esta técnica para consultas concretas cuando el atributo de búsqueda no
coincide con el atributo de división.
División por rangos:
Se adapta bien a las consultas concretas y de rango basadas en el atributo de
división.
Para consultas concretas se debe analizar el vector de división para
Teoría de Bases de Datos II 159 UCENM
Ver en que disco está la dupla al igual que para una consulta de rango se
consulta el vector de división para ver en que rango de discos están las Duplas.
En general se prefiere división por asociación o por rangos a turno rotatorio. En
la siguiente
Tabla se resume la comparativa:
Técnica División Relación
Completa
Consulta
Concreta
Consulta de
Rango
Turno
Rotatorio
Eficaz Ineficaz Ineficaz
Por Rango - Eficaz si coincide
Con atributo de
División
Eficaz si coincide
Con atributo de
División
Por Asociación Eficaz si la
Función reparte
Bien las duplas
Eficaz si coincide
Con atributo de
División
El problema de las divisiones por asociación es que tienden a almacenar un
alto porcentaje de duplas en algunos discos específicos, situación que no se da
con el turno rotatorio. Esto se debe a que muchas duplas contienen valores
similares en sus atributos. Para minimizar este problema se debe de elegir un
vector de división equilibrado.
Teoría de Bases de Datos II 160 UCENM
Si una relación contiene un número pequeño de duplas ésta no debe ser
dividida y debe almacenarse en un solo disco.
Paralelismo entre consultas
Los sistemas de bases de datos con arquitectura paralela deben asegurar de
que dos procesadores no actualicen simultáneamente los mismos datos de
manera independiente.
Cuando un procesador accede a los datos o los actualiza, el sistema de bases
de datos debe garantizar que tenga su última versión en la memoria intermedia.
El problema de asegurar que la versión sea la última disponible se denomina
problema de coherencia del bloqueo compartido o exclusivo de la página, la
transacción lee también su copia mas reciente del disco compartido.
Antes de que una transacción libere el bloqueo exclusivo de una página, la
traslada al disco compartido, posteriormente libera el bloqueo.
Con este protocolo se garantiza que cuando una transacción establece un
bloqueo compartido o exclusivo sobre una página, obtenga la copia correcta de
la página.
Paralelismo en consultas
Es la ejecución en paralelo de una única consulta entre varios procesadores y
discos, cuyo objetivo es acelerar las consultas de ejecución prologada. Por
tanto se puede hacer paralelas las consultas haciendo paralelas las
operaciones que las forman.
Existen dos maneras de ejecutar en paralelo una sola consulta:
Paralelismo en operaciones.
Se puede acelerar el procesamiento de las
Consulta haciendo paralela la ejecución de cada una de sus operaciones
Individuales ordenación, selección, proyección y reunión.
Paralelismo entre Operaciones.
Se puede acelerar el procesamiento de la
Consulta ejecutando en paralelo las diferentes operaciones de las expresiones
de las consultas.
Teoría de Bases de Datos II 161 UCENM
Por lo tanto el objetivo que se persigue es dividir la relación que interviene en la
consulta por medio de técnicas de división de relaciones, guardar dichas
relaciones en discos que van a ser gestionados cada uno de ellos por un
procesador, a su vez, cada procesador ejecuta su consulta local y cada uno de
estos resultados parciales se unen para formar la respuesta a la
Consulta.
Paralelismo en operaciones
Ya que las operaciones relacionales trabajan con relaciones que contienen
grandes conjuntos de duplas, las operaciones se pueden paralelizar
ejecutándolas sobre subconjuntos diferentes de las relaciones en paralelo.
Según el tipo de operación se siguen distintos criterios en el tratamiento que
son:
Ordenación Paralela
Reunión Paralela.
Ordenación Paralela.
Dependiendo del criterio en la división de la relación se pueden distinguir dos
tipos de ordenación:
Ordenación división de Rangos.
Esta forma de división por rangos posee dos etapas
Diferenciadas:
Redistribuir las duplas de la relación utilizando una estrategia de división
por rangos, de manera que todas las duplas que se hallen dentro del rango i-
ésimo se envíen al procesador Pi, que almacena temporalmente la relación en
el disco Di. Para implementar en paralelo la división por rangos cada
procesador lee las duplas de su disco y las envía al procesador de destino.
Cada procesador P0,P1…Pn también recibe las duplas correspondientes a su
partición y las almacena localmente.
Cada uno de los procesadores ordena localmente su partición de la relación sin
Interactuar con los demás. La operación final de mezcla es trivial ya que la
división por rangos de la primera etapa asegura que los valores de la clave del
procesador Pi sean menores que los procesador Pj
Teoría de Bases de Datos II 162 UCENM
Ordenación y mezcla externa paralela.
Este tipo de ordenación es una alternativa a la efectuada por la división por
rangos. Las etapas que se definen una vez que la relación se ha divida entre
los diferentes discos D1,D2…Dn-a son las siguientes:
Cada procesador Pi ordena localmente los datos del disco Di
El sistema mezcla las partes ordenadas por cada procesador para
obtener el resultado ordenado final.
A su vez el paso en el que el sistema realiza la mezcla puede ser también
paralelizado mediante la siguiente secuencia de acciones.
El sistema divide en rangos las particiones ordenadas encada procesador Pi
Entre los procesadores P0,P1…Pn-1. Envía las duplas de acuerdo con el orden
Establecido por lo que cada procesador recibe las duplas en corrientes
Ordenadas.
Cada procesador Pi, realiza una mezcla de las corrientes según las recibe para
Obtener una sola parte ordenada.
Las partes ordenadas de los procesadores P0,P1… Pn-1 se concatenan para
Obtener el resultado final.
Reunión Paralela.
La operación reunión exige que el sistema compare pares de duplas para ver si
satisface la
Condición de reunión, si la cumple añade el par al resultado de la reunión. Los
algoritmos de reunión paralela intentan repartir entre varios procesadores los
pares que hay que comparar.
Cada procesador procesa luego localmente parte de la reunión. Después, el
sistema reúne los resultados de cada procesador para producir el resultado
final.
Existe un problema por el cual no todas los tipos de reuniones pueden ser
divididas por lo que existen distintas formas de proceder que son:
Reunión por División. Válida para reuniones de tipo equirreuniones y reuniones
Teoría de Bases de Datos II 163 UCENM
Naturales, en la cual existen n procesadores y las relaciones que hay que
reunir son r y s.
La reunión por división funciona de esta forma:
El sistema divide las relaciones r y s en n particiones r0,r1,…rn-1 y s0,s1,…sn-
1 Envía las particiones ri y si al procesador Pi, donde la reunión se procesa
localmente.
Existen dos maneras diferentes de dividir las relaciones r y s y son División por
rangos de los atributos de reunión, en el que se debe usar el mismo vector
de división.
División por asociación de los atributos de reunión, se debe usar la misma
función de asociación.
Una vez divididas las relaciones se pueden utilizar localmente cualquier técnica
de reunión en cada procesador Pi para calcular la reunión de ri y si.
Reunión con fragmentos y replicas. Proporcionan una alternativa para las
Reuniones que no puede ser procesada por la técnica de reunión por división,
como por ejemplo si la condición de reunión es una desigualdad. En este tipo
de reuniones pueden paralelizarse
Utilizando una técnica denominada fragmentos y replicas, cuyo funcionamiento
es el siguiente.
El sistema divide una de las relaciones (por ejemplo s) mediante
cualquier técnica de división, incluida por turno rotatorio.
El sistema replica la otra relación r en todos los procesadores
El procesador Pi procesa localmente la reunión de ri con todos,
utilizando cualquier técnica de reunión.
Reunión por asociación dividida en paralelo. La reunión por asociación
realizada en cada procesador es independiente de las realizadas en otros
procesadores, y recibir las duplas de ri y de si es parecido a leerlas del disco.
En concreto, se puede utilizar el algoritmo híbrido de reunión por asociación
para guardar en caché algunas de las duplas de entrada, y evitar así los costes
de escribirlas y volver a leerlas.
Teoría de Bases de Datos II 164 UCENM
Otras operaciones relacionales
También se puede realizar en paralelo la evaluación de otras operaciones
relacionales:
Selección. Sea la selección me(r). Considérese primero el caso en el que e es
de la forma ai = v, donde ai es un atributo y v es un valor. Si la relación r se
divide basándose en ai la selección se lleva a cabo en un solo procesador. Si e
es de la forma l ) ai ) u (es decir, que ees una selección de rango) y la relación
se ha dividido por rangos basándose en ai, entonces la selección se lleva a
cabo en cada procesador cuya partición se solape con el rango de valores
especificado. En el resto de los casos la selección se lleva a cabo en todos los
procesadores en paralelo.
Eliminación de duplicados.
La eliminación de duplicados puede llevarse a cabo por ordenación; puede
utilizarse cualquiera de las técnicas de ordenación en paralelo, con la
optimización de eliminar los duplicados durante la ordenación tan pronto como
se encuentren. También se puede realizar la eliminación de duplicados en
paralelo dividiendo las duplas (mediante división por rangos o por asociación) y
llevando a cabo localmente en cada procesador la eliminación de duplicados.
Proyección. Se puede llevar a cabo la proyección sin eliminación de duplicados
según se leen en paralelo las duplas del disco. Si se va a llevar a cabo la
eliminación de duplicados se puede utilizar las técnicas que se acaban de
describir.
Agregación.
La agregación puede considerarse una operación. Se puede paralelizar la
operación dividiendo la relación basándose en los atributos de agrupación y
procesando luego localmente los valores de agregación en cada procesador.
Se puede utilizar división por rangos o por asociación. Si la relación ya está
dividida basándose en los atributos de agrupación se puede omitir el primer
paso.
Costo de la evaluación en paralelo de las operaciones
Se puede obtener el paralelismo dividiendo la E/S entre varios discos y el
trabajo de la UCP entre varios procesadores. Si se logra un reparto así sin
sobrecarga y no hay sesgo en el reparto del trabajo, las operaciones en
Teoría de Bases de Datos II 165 UCENM
paralelo que utilicen n procesadores tardarán 1/n lo que tardarían en un solo
procesador. Ya se sabe cómo estimar el coste de operaciones como la reunión
o la selección.
El coste en tiempo del procesamiento paralelo sería entonces 1/n el del
Procesamiento secuencial de la operación.
También hay que tener en cuenta los costes siguientes:
Los costos de iniciar la operación en varios procesadores.
El sesgo en la distribución de trabajo entre los procesadores, con algunos
procesadores con mayor número de duplas que otros.
La contención de recursos como la memoria, los discos y la red de
comunicaciones que dan lugar a retrasos.
El coste de construir el resultado final transmitiendo los resultados
parciales desde cada procesador.
Aunque dividir una sola consulta en varios pasos en paralelo reduce el tamaño
del paso medio, es el tiempo de procesamiento del paso más lento el que
determina el tiempo empleado en procesar la consulta en su conjunto. Una
evaluación en paralelo de las particiones, por ejemplo, sólo es tan rápida como
la más lenta de sus ejecuciones en paralelo. Por tanto, el rendimiento se ve
muy afectado por cualquier sesgo en la distribución del trabajo entre los
procesadores.
El problema del sesgo de la división está íntimamente relacionado con el del
Desbordamiento de particiones en las reuniones por asociación secuenciales.
Se puede utilizar la resolución del desbordamiento y las técnicas de evitación
desarrolladas para las reuniones por asociación para tratar el sesgo cuando se
utilice la división por asociación.
Paralelismo entre operaciones.
Hay dos formas de paralelismo entre operaciones: el paralelismo de
encauzamiento y el paralelismo independiente.
Paralelismo de encauzamiento. El encauzamiento supone una importante
fuente de economía de procesamiento para el procesamiento de consultas de
bases de datos. La ventaja principal de la ejecución encauzada de las
Teoría de Bases de Datos II 166 UCENM
evaluaciones secuenciales es que se puede ejecutar una secuencia de
operaciones de ese tipo sin escribir en el disco ninguno de los resultados
intermedios.
En los sistemas paralelos el encauzamiento se utiliza principalmente por la
misma razón que en los sistemas secuenciales. Sin embargo, el
encauzamiento puede utilizarse también como fuente de paralelismo, del
mismo modo que el encauzamiento de instrucciones se utiliza como fuente de
paralelismo en el diseño de hardware. Esta forma de paralelismo se denomina
paralelismo de encauzamiento.
El paralelismo encauzado resulta útil con un número pequeño de procesadores,
pero no puede extenderse bien:
En primer lugar, las cadenas del cauce no suelen lograr la longitud
suficiente para proporcionar un alto grado de paralelismo.
En segundo lugar, no es posible encauzar los operadores de relación
que no producen resultados hasta que se ha tenido acceso a todas las
entradas, como la operación diferencia de conjuntos.
En tercer lugar, sólo se obtiene una aceleración marginal en los casos
frecuentes en que el coste de ejecución de un operador es mucho mayor
que los de los demás operadores.
Por consiguiente, cuando el grado de paralelismo es elevado, la importancia
del encauzamiento como fuente de paralelismo es secundaria respecto de la
del paralelismo de particiones.
La razón fundamental para utilizar el encauzamiento es que las ejecuciones
encauzadas pueden evitar escribir en el disco los resultados intermedios.
Paralelismo independiente. Las operaciones en las expresiones de las
consultas que son independientes entre sí pueden ejecutarse en paralelo. Esta
forma de paralelismo se denomina paralelismo independiente.
Al igual que el paralelismo encauzado, el paralelismo independiente no
proporciona un alto grado de paralelismo y es menos útil en sistemas con un
elevado nivel de paralelismo, aunque resulta útil con un grado menor de
paralelismo.
Teoría de Bases de Datos II 167 UCENM
Optimización de consultas.
Un factor importante en el éxito de la tecnología relacional ha sido el diseño
con éxito de optimizadores de consultas.
Los optimizadores de consultas para la evaluación de consultas en paralelo son
más complicados que los optimizadores de consultas para la evaluación
secuencial de consultas.
En primer lugar, los modelos de costes son más complicados dado que hay
que tener en cuenta los costes de división, y deben tenerse en consideración
aspectos como el sesgo y la contención de recursos.
Resulta de mayor importancia el asunto de la paralelizarían de las consultas.
Supóngase que de algún modo se ha escogido una expresión (de entre las
equivalentes a la consulta) para utilizarla para evaluar la consulta.
Para evaluar un árbol de operadores en un sistema paralelo hay que tomar las
decisiones siguientes:
El modo en que se paralelice cada operación y el número de procesadores que
se utilizará para ello.
Las operaciones que se encauzan entre los diferentes procesadores, las
operaciones que se ejecuten independientemente en paralelo y las que se
ejecuten secuencialmente, una tras otra.
Diseño de sistemas paralelos.
La carga de datos en paralelo desde fuentes externas es un requisito
importante si se van a tratar grandes volúmenes de datos entrantes.
Un gran sistema paralelo de bases de datos debe abordar también los
siguientes aspectos de disponibilidad:
El poder de recuperación frente al fallo de algunos procesadores o discos
La reorganización interactiva de los datos y los cambios de los esquemas.
Teoría de Bases de Datos II 168 UCENM
Con un gran número de procesadores y de discos la probabilidad de que al
menos un procesador o un disco funcionen mal es significativamente mayor
que en sistema con un único procesador y un solo disco.
Un sistema paralelo mal diseñado dejará de funcionar si cualquier componente
(procesador o disco) falla. Suponiendo que la probabilidad de fallo de cada
procesador o disco es pequeña, la probabilidad de fallo del sistema asciende.
Por tanto, los sistemas paralelos de bases de datos de gran escala se diseñan
para operar incluso si falla un procesador o un disco. Los datos se replican en
al menos dos procesadores.
Si falla un procesador se puede seguir teniendo acceso desde los demás
procesadores a los datos que guarda. El sistema hace un seguimiento de los
procesadores con fallos y distribuye el trabajo entre los que funcionan. Las
peticiones de los datos guardados en el emplazamiento con
Fallo se desvían automáticamente a los emplazamientos de las copias de
seguridad que guardan una réplica de los datos.
Cuando se manejan grandes volúmenes de datos (del orden de terabytes), las
operaciones sencillas, como la creación de índices, y los cambios en los
esquemas, como añadir una columna a una relación, pueden tardar mucho
tiempo (quizás horas o incluso días).
Por tanto, es inaceptable que los sistemas de bases de datos no estén
disponibles mientras se llevan a cabo tales operaciones. Los sistemas
paralelos de bases de datos permiten que tales operaciones se lleven a cabo
interactivamente, es decir, mientras el sistema ejecuta otras transacciones.
Bases de Datos GRID
Introducción.
Grid es una tecnología que surgió como una nueva forma de computación
distribuida. Ian Foster y Carl Kesselman son considerados los padres de esta
tecnología, introducida por ellos en los años 90. Esta tecnología se basa en la
utilización de recursos externos además de los locales, logrando con ello una
mayor disponibilidad de recursos para la realización de una tarea.
Teoría de Bases de Datos II 169 UCENM
La tecnología estándar, o una de las más utilizadas en su comienzo al menos,
es el Globus Toolkit.
El objetivo es permitir el uso de recursos libres de otras computadoras
localizadas en otro lugar geográfico y que no estén utilizando toda su potencia.
De este modo alguien que no disponga de la suficiente potencia o recursos en
su lugar de trabajo, no se verá imposibilitado para realizar la tarea deseada ya
que podrá hacer uso de recursos ajenos.
Como consecuencia del uso de una red Grid, un usuario puede hacer uso de
recursos libres situados en los computadores que se encuentren dentro de esta
red Grid, sin importar la localización del mismo. De este modo, el usuario
dispone de un computador ficticio con la potencia, disco duro o memoria RAM
necesitada.
Por otro lado, podemos decir que con Grid, no ponemos atención en los datos
que se transmiten en sí, como es el caso de los sistemas Cliente-Servidor sino
que el punto de interés y estudio son los recursos computacionales y el uso
que se hace de ellos.
Otro avance de Grid es que genera un incremento de las posibilidades del uso
de internet ya que proporciona un incremento de su usabilidad. De este modo
se obtiene una mayor velocidad de procesamiento así como la facilidad de
tener bases de datos de mayor tamaño.
Una definición de computación Grid encontrada en la wiki pedía es la siguiente:
GRID COMPUTING:
Es una tecnología innovadora que permite utilizar de forma coordinada todo
tipo de recursos (entre ellos cómputo, almacenamiento y aplicaciones
específicas) que no están sujetos a un control centralizado. En este sentido es
una nueva forma de computación distribuida, en la cual los recursos pueden
ser heterogéneos (diferentes arquitecturas, supercomputadores,
Clúster...) y se encuentran conectados mediante redes de área extensa (por
ejemplo Internet).
Desarrollado en ámbitos científicos a principios de los años 90 su entrada al
mercado comercial siguiendo la idea de la llamada Utility Computing supone
una revolución que dará mucho que hablar.
Teoría de Bases de Datos II 170 UCENM
Las características de esta arquitectura serían:
Capacidad de balanceo de sistemas: no habría necesidad de calcular la
capacidad de los sistemas en función de los picos de trabajo, ya que la
capacidad se puede reasignar desde la granja de recursos a donde se
necesite; Alta disponibilidad. Con la nueva funcionalidad, si un servidor falla, se
reasignan los servicios en los servidores restantes.
Reducción de costos:
Con esta arquitectura los servicios son gestionados por "granjas de recursos".
Ya no es necesario disponer de "grandes servidores" y podremos hacer uso de
Componentes de bajo costo.
GRID Middleware.
En las tecnologías Grid, además de tenerse en cuenta el hardware como son
los recursos, los dispositivos de almacenamiento y por supuesto la propia red
Grid, es necesario un soporte software que gestione todas las transferencias y
el modo en que se realizan, así como la seguridad, todo esto resulta una tarea
complicada y no exenta de posibles errores.
Esto no implica que la aparición de un error en un equipo y en una localización
determinada, provoque el error en toda la red.
Bases de Datos GRID.
Las Bases de Datos Grid nos proporcionan una visión uniforme de bases de
datos heterogéneas en los entornos Grid. Es decir, puesto que existen diversos
tipos de bases de datos, refiriéndonos con ellos a que éstas pueden ser
relacionales, orientadas a objetos, en XML, etcétera, nuestro sistema nos tiene
que proporcionar la abstracción necesaria de los datos para que el usuario no
distinga entre si esta accediendo a una relacional o a una orientada a objetos,
Teoría de Bases de Datos II 171 UCENM
Ya que el usuario no le importa cómo se realice el trabajo, solo necesita que se
haga y debe ser el Grid middleware quien se ocupe de que se efectúe
correctamente.
Por otro lado la especificación de los servicios de bases de datos deben ser
ortogonales a los mecanismos de autentificación y autorización de los sistemas
Grid, lo que significa que las bases de datos deben poseer sistemas de
seguridad que identifiquen a un usuario del Grid y que por tanto permitan o no
su acceso.
Las propias bases de datos deben de ser transparentes al usuario, logrando así
que este se abstraiga de todo lo relacionado con el cómo se hace, donde o
incluso que recursos o almacenamiento está siendo utilizado. Del mismo modo,
no deberá preocuparse por la administración de los recursos.
Requisitos para la utilización de BBDD en GRID
Para utilizar Base de Datos en el GRID, estas primeramente deben de cumplir
una serie de condiciones previas, como son las normas de seguridad en un
GRID.
Algunos aspectos claves de la seguridad en el GRID son:
Autentificación: Verificación de la validez de la identidad de un usuario, recurso,
Servicio,..
Autorización: Cada recurso o usuario solo debe usar los servicios para los que
está permitido (control de acceso).
Integridad: Asegura que los datos no han sido alterados fraudulentamente.
Confidencialidad: Información sensible como puede ser información de carácter
Personal, orientación sexual, datos médicos o bancarios, no puede ser
observada por terceros.
Teoría de Bases de Datos II 172 UCENM
Gestión de claves: Hace referencia a la gestión de seguridad, proceso de
distribución, generación y almacenamiento de claves.
Encriptación: o Simétrica:
El proceso de encriptación se realiza usando la misma clave privada.
Inconvenientes: El emisor y el receptor deben intercambiar la clave.
o Asimétrica: Se utilizan dos claves diferentes para encriptar y desencriptar
datos.
Criptografía de clave pública.
Lentitud considerable en mensajes grandes.
Aparición de patrones que puede simplificar su criptoanálisis.
Secure Socket Layer/ Transport Layer Security (SSL/ TLS): Protocolo de
comunicación segura.
Autentificación Mutua: Dos entidades que quieren comunicarse usan su clave
pública almacenada en un certificado digital para autentificarse.
Estos servicios fundamentales se garantizan mediante:
GRID Security Infrastructure (GSI)
Public Key Infrastructure (PKI)
Integración de Base de Datos en un Sistema GRID
En los sistemas de bases de datos Grid los servicios ofrecidos deben estar, en
la medida de lo posible estandarizados, y decimos en la medida de lo posible
ya que resulta imposible que todos los servicios se estandaricen debido a la
existencia de distintos tipos de bases de datos que pueden existir en el sistema
y que pueden estar usando lenguajes diferentes que no pueden ser integrados
en un único lenguaje debido a su naturaleza. De esta forma podemos aumentar
la portabilidad de dichos sistemas.
Teoría de Bases de Datos II 173 UCENM
Otra de las ventajas de estandarizar siempre es reducir el esfuerzo de
construcción del sistema.
Con lo mencionado anteriormente se hace imprescindible la presencia de los
metadatos en este tipo de sistemas. Con los metadatos lo que conseguimos es
que cada sistema que se conecta al Grid pueda comunicar al resto los servicios
que ofrece. Del mismo modo podremos saber las operaciones que soporta
cada uno.
El sistema gestor de bases de datos (SGBD) va a ser el encargado de saber
que servicios ofrece cada una de las bases de datos, que operaciones se
pueden realizar sobre ellas y de gestionar los permisos de acceso a cada una.
Los servicios que cada sistema debe tener disponibles dentro del Grid son los
siguientes:
Metadatos. Nos dan la información sobre los servicios que ofrece el sistema.
Además, cuando los usuarios del sistema soliciten un servicio no saben en qué
sistema está y mediante los metadatos él se pueden construir dinámicamente
las interfaces para acceder a los distintos sistemas de bases de datos que
forman parte del Grid.
Manejo de consultas. Como hemos comentado más arriba los lenguajes
pueden ser diferentes. Por eso en los metadatos se proporciona la información
necesaria sobre el lenguaje de consulta que soporta cada base de datos.
También es importante que los resultados de una consulta se puedan enviar a
distintos destinos y que sean comprensibles por éstos para poder construir
sistemas más amplios y complejos.
Teoría de Bases de Datos II 174 UCENM
Transacciones. Estas operaciones son en las que interviene un único sistema
de base de datos y a su vez que cada sistema individual tome parte en las
transacciones distribuidas.
La gran variedad de tipos de transacciones que maneja el sistema gestor de
base de datos de un sistema Grid, debido sobre todo a la heterogeneidad de
los sistemas individuales que lo componen, hace que el servicio deba poner
claramente en conocimiento del resto cual es el tipo de transacciones que
soporta el sistema individual de base de datos.
o Carga del sistema o carga de datos. Cuando tenemos grandes cantidades de
datos este tipo de servicio debe ser capaz de acceder a los protocolos de
comunicación del sistema Grid para llevar a cabo la transferencia de esos
datos o Notificación.
Sirve para notificar los cambios que se producen a los clientes que deseen
recibir esa información. Los clientes deben poder expresar si están interesados
en recibir las notificaciones cuando se inserten o se borren datos o cuando se
realicen actualizaciones o en caso de varias acciones como insertar y
actualizar.
La forma más sencilla de que este servicio se ponga en funcionamiento es que
el sistema gestor de base de datos subyacente proporcione la ayuda necesaria,
por ejemplo mediante disparadores.
Planificación. Se debe permitir por ejemplo que cuando un superordenador
conecte con un DBS, la información recuperada del DBS se pueda procesar
por el superordenador.
El ancho de banda en la red que los conecta necesita ser reservada. Como el
acceso exclusivo a un DBS no es práctico, se requieren mecanismos con
suficientes recursos (discos, CPUs, memoria, red).
Ventajas e Inconvenientes de las BBDD en un Sistema
GRID
Teoría de Bases de Datos II 175 UCENM
Las bases de datos alojadas en un sistema GRID van a heredar todas las
características:
Ventajas e inconvenientes del sistema al que pertenecen.
La Computación GRID está creada con el fin de ofrecer una solución a
determinadas cuestiones, como problemas que requieren de:
Un gran número de ciclos de procesamiento o
Un acceso a una gran cantidad de datos.
Las principales ventajas de un sistema GRID son:
Nunca queda obsoleta, ya que se integran diferentes tipos de máquinas y de
recursos y todos los recursos se aprovechan. Si se renuevan todas las PCs de
una oficina, se pueden incorporar las antiguas y las nuevas.
Facilita la posibilidad de compartir, acceder y gestionar información, mediante
la colaboración y la flexibilidad operacional, aunando no sólo recursos
tecnológicos dispares, sino también personas y aptitudes diversas. o Permite a
las empresas acceder y compartir bases de datos remotas. Esto es de gran
importancia en las empresas que se dedican a la investigación, en donde
enormes cantidades de información son generadas y analizadas casi a diario.
Las empresas pueden mejorar la calidad y el tiempo de entrega de los
productos y servicios que ofrecen, a la vez que reducen costes de TI al permitir
la colaboración transparente y la compartición de recursos.
Tiende a incrementar la productividad otorgando a los usuarios finales acceso a
los recursos de computación, datos y almacenamiento que necesiten, cuando
los necesiten. o Se aprovechan los ciclos de procesamiento inutilizados de
ordenadores que se encuentran en diversas zonas geográficas.
Teoría de Bases de Datos II 176 UCENM
Ejemplo: ordenadores que normalmente se encuentran inutilizados por la
noche en una compañía en Europa, podrían ser utilizados en el día por una
sede de operaciones en América.
El paralelismo puede estar visto como un problema, ya que una máquina
paralela es muy costosa.
Pero, si tenemos disponibilidad de un conjunto de máquinas heterogéneas de
pequeño o mediano porte, cuya potencia computacional sumada sea
considerable, eso permitiría generar sistemas distribuidos de muy bajo coste y
gran potencia computacional.
La tolerancia a fallos significa que si una de las máquinas que forman parte del
GRID colapsa, el sistema lo reconoce y la tarea se reenvía a otra máquina, con
lo cual se cumple el objetivo de crear infraestructuras operativas flexibles y
resistentes. Así se obtiene una tecnología más robusta y resistente, capaz de
responder a desastres.
Por tanto se puede decir que un sistema GRID proporciona:
Una forma transparente de ejecutar el trabajo que se desea:
Encuentra los recursos (maquinas) disponibles.
Asegura un acceso optimizado a los datos (incluyendo copias
locales/ cache…)
Comprueba la autorización del usuario.
Monitoriza la ejecución.
Además, si es posible monitoriza el trabajo
Los principales inconvenientes de un sistema GRID son:
Necesita para mantener su estructura, de diferentes servicios como Internet,
conexiones de 24 horas, los 365 días, con banda ancha, servidores de
capacidad, seguridad informática, VPN, firewalls, encriptación, comunicaciones
seguras, políticas de seguridad, normas ISO, y algunas características más…
Metadatos en Bases de Datos en un Sistema GRID.
¿Por qué son necesarios los metadatos?
Teoría de Bases de Datos II 177 UCENM
En los sistemas de bases de datos GRID los servicios ofrecidos deben estar,
en la medida de lo posible estandarizados ya que resulta imposible que todos
los servicios se estandaricen debido a la existencia de distintos tipos de bases
de datos en el sistema GRID y que pueden estar usando lenguajes diferentes
que no pueden ser integrados en un único lenguaje.
De esta forma podemos aumentar la portabilidad de dichos sistemas. Otra de
las ventajas de estandarizar es reducir el esfuerzo de construcción del sistema.
Con lo mencionado anteriormente se hace imprescindible la presencia de los
metadatos en este tipo de sistemas. Con los metadatos lo que conseguimos es
que cada sistema que se conecta al GRID pueda comunicar al resto los
servicios que ofrece. Del mismo modo podremos saber las operaciones que
soporta cada uno.
El sistema gestor de bases de datos (SGBD) va a ser el encargado de saber
que servicios ofrece cada una de las bases de datos, que operaciones se
pueden realizar sobre ellas y de gestionar los permisos de acceso a cada una.
Servicios que describen los metadatos.
Los servicios que cada sistema debe tener disponibles dentro del GRID son los
siguientes:
Metadatos. Nos dan la información sobre los servicios que ofrece el sistema.
Además, cuando los usuarios del sistema soliciten un servicio no saben en qué
sistema está y mediante los metadatos se pueden construir dinámicamente las
interfaces para acceder a los distintos sistemas de bases de datos que forman
parte del GRID.
Manejo de consultas. Como hemos comentado más arriba los lenguajes
pueden ser diferentes. Por eso en los metadatos se proporciona la información
necesaria sobre el lenguaje de consulta que soporta cada base de datos.
También es importante que los resultados de una consulta se puedan enviar a
distintos destinos y que sean comprensibles por éstos para poder construir
sistemas más amplios y complejos.
Transacciones. Estas operaciones son en las que interviene un único sistema
de base de datos y a su vez que cada sistema individual tome parte en las
Teoría de Bases de Datos II 178 UCENM
transacciones distribuidas. La gran variedad de tipos de transacciones que
maneja el sistema gestor de base de datos de un sistema GRID, debido sobre
todo a la heterogeneidad de los sistemas individuales que lo componen, hace
que el servicio deba poner claramente en conocimiento del resto cual es el tipo
de transacciones que soporta el sistema individual de base de datos.
o Carga del sistema o carga de datos. Cuando tenemos grandes cantidades de
taos este tipo de servicio debe ser capaz de acceder a los protocolos de
comunicación del sistema GRID para llevar a cabo la transferencia de esos
datos. o Notificación. Sirve para notificar los cambios que se producen a los
clientes que deseen recibir esa información. Los clientes deben poder expresar
si están interesados en recibir las notificaciones cuando se inserten o se borren
datos o cuando se realicen actualizaciones o en caso de varias acciones como
insertar y actualizar.
La forma más sencilla de que este servicio se ponga en funcionamiento es que
el sistema gestor de base de datos subyacente proporcione la ayuda necesaria,
por ejemplo mediante disparadores.
Planificación. Se debe permitir por ejemplo que cuando un superordenador
conecte con un sistema de base de datos, la información recuperada de ese
sistema pueda ser procesada por el superordenador. El ancho de banda en la
red que los conecta necesita ser reservada. Como el acceso exclusivo a un
sistema de base de datos no es práctico, se requieren mecanismos con
suficientes recursos (discos, CPUs, memoria, red).
PROCESAMIENTO PARALELO
El procesamiento paralelo es un término que se usa para denotar un grupo de
técnicas significativas que se usan para proporcionar tareas simultáneas de
procesamiento de datos con el fin de aumentar la velocidad computacional de
un sistema de computadoras. En lugar de procesar cada instrucción en forma
secuencial como es una computadora convencional, un sistema de
procesamiento paralelo puede ejecutar procesamiento concurrente de datos
para conseguir un menor tiempo de ejecución. Por ejemplo, cuando se ejecuta
una instrucción en la ALU, puede leerse la siguiente instrucción de la memoria.
Teoría de Bases de Datos II 179 UCENM
El sistema puede tener 2 o mas ALUS y ser capaz de ejecutar dos o mas
instrucciones al mismo tiempo. Además, el sistema puede tener dos o más
procesadores operando en forma concurrente.
EL propósito del procesamiento paralelo es acelerar las posibilidades de
procesamiento de la computadora y aumentar su eficiencia, esto es, la
capacidad de procesamiento que puede lograrse durante un cierto intervalo de
tiempo. La cantidades de circuitería aumenta con el procesamiento paralelo y,
con él, también el costo del sistema. Sin embargo, los descubrimientos
tecnológicos han reducido el costo de la circuitería a un punto en donde las
técnicas de procesamiento paralelo son económicamente factibles.
El procesamiento paralelo puede considerarse de diversos niveles de
complejidad. En el nivel más bajo, distinguimos entre operaciones seriales y
paralelas mediante el tipo de registros que utilizan. Los registros de corrimiento
operan en forma serial un bit a la vez, mientras que los registros con carga
paralela operan con todos los bits de la palabra en forma simultánea.
Puede obtenerse procesamiento paralelo a un nivel más alto de complejidad al
tener múltiples unidades funcionales que ejecuten operaciones idénticas o
diferentes, de manera simultánea. El procesamiento paralelo se establece al
distribuir los datos entre las unidades funcionales múltiples. Por ejemplo, las
operaciones aritméticas, lógicas y de corrimiento pueden separarse en tres
unidades y dividirse los operandos a cada una, bajo la supervisión de una
unidad de control.
Procesador con unidades funcionales múltiples
La operación ejecutada en cada unidad funcional se indica en cada bloque del
diagrama. El sumador y el multiplicador de enteros ejecutan las operaciones
aritméticas con números enteros.
Las operaciones de punto flotante se separan en tres circuitos que operan en
paralelo. Las operaciones lógicas de corrimiento y de incremento pueden
Teoría de Bases de Datos II 180 UCENM
ejecutarse en forma concurrente sobre diferentes datos. Todas las unidades
son independientes unas de otra, por lo que puede correrse un número
mientras otro se incrementa.
Por lo general, una organización multifuncional está asociada con una unidad
de control compleja para coordinar todas las agilidades entre los diferentes
componentes.
Existen varias maneras de clasificar el procesamiento paralelo. Puede
considerarse a partir de la organización interna de los procesadores, desde la
estructura de interconexión entre los procesadores o desde del flujo de
información a través del sistema.
Una clasificación presenta por M. J. Flynn considera la organización de un
sistema de computadora mediante la cantidad de instrucciones y unidades de
datos que se manipulan en forma simultánea. La operación normal de una
computadora es recuperar instrucciones de la memoria y ejecutarlas en el
procesador.
La secuencia de instrucciones leídas de la memoria constituye un flujo de
instrucciones. Las operaciones ejecutadas sobre los datos en el procesador
constituyen un flujo de datos.
El procesamiento paralelo puede ocurrir en el flujo de instrucciones, en el flujo
de datos o en ambos.
La clasificación de Flynn divide a las computadoras en cuatro grupo principales
de la manera siguiente:
Flujo de instrucción único, Flujo de datos único (SISD)
Flujo de instrucción único, Flujo de datos Múltiple (SIMD)
Flujo de instrucción Múltiple, Flujo de datos único (MISD)
Flujo de instrucción Múltiple, Flujo de datos Múltiple (MIMD)
SISD. Representa la organización de una computadora única que contiene una
unidad de control, una unidad de procesador y una unidad de memoria. Las
Teoría de Bases de Datos II 181 UCENM
instrucciones se ejecutan en forma secuencial y el sistema puede tener o no
tener posibilidades de procesamiento paralelo.
En este caso el procesamiento paralelo puede lograrse mediante unidades
funcionales múltiples o mediante una arquitectura paralela.
SIMD.
Representa una organización que influye muchas unidades de procesamiento
bajo la supervisión de una unidad de control común. Todos los procesadores
reciben la misma instrucción de la unidad de control, pero operan sobre
diferentes conjuntos de datos. La unidad de memoria compartida debe de
contener módulos múltiples para que pueda comunicarse con todos los
procesadores simultáneamente.
LA estructura MISD es sola de intereses teórico porque no se ha construido
ningún sistema práctico utilizando esta organización. La organización MIMD se
refiere a un sistema de computadoras capaz de procesar múltiples programas
al mismo tiempo la mayoría de los sistemas de multicomputadoras y
multiprocesador pueden clasificarse en esta categoría.
La clasificación de Flynn depende en la diferencia entre el desempeño de la
unidad de control y el de la unidad de procesamiento de datos.
Enfatiza las características de desempeño del sistema de computadoras más
que sus interconexiones estructurales y operacionales.
Un tipo de procesamiento paralelo que no entra en la clasificación flynn es la
arquitectura paralela (pipe-line) Las únicas dos categorías utilizadas de esta
clasificación son los procesadores de arreglo SIMD,
El procesamiento por arquitectura paralela es una técnica de implantación en
donde las suboperaciones aritméticas o las fases de un ciclo de instrucción de
computadora se traslapan en su ejecución el procesamiento de vectores
relaciona con los cálculos que implican vectores y matrices grandes.
Teoría de Bases de Datos II 182 UCENM
Los procesadores de arquitectura paralela ejecutan cálculos sobre arreglos de
datos grandes.
Arquitectura Paralela
La arquitectura paralela o de líneas paralelas (pipe-line), es una técnica en la
que se descomponen un proceso secuencial en suboperaciones, y cada
subproceso se ejecuta en un segmento dedicado especial que opera en forma
concurrente con los otros segmentos. Una línea puede considerarse como un
conjunto de segmentos de procesamiento por el que fluye información binaria.
Cada segmento ejecuta un procesamiento parcial, dictado por la manera en
que se divide la tarea.
El resultado obtenido del cálculo en cada segmento se transfiere al siguiente
segmento en la línea. El resultado final se obtiene después de que los datos
han recorrido todos los segmentos. El nombre "línea" implica un flujo
reinformación similar a una línea de ensamblado industrial. Es característico de
las líneas que varios cálculos puedan estar en proceso en distintos segmentos,
al mismo tiempo. La simultaneidad de los cálculos es posible al asociar un
registro con cada segmento en la línea. Los registros proporcionan aislamiento
entre cada segmento para que cada uno pueda operar sobre datos distintos en
forma simultánea.
Tal vez la manera más simple de apreciar la arquitectura de líneas paralelas es
imaginar que cada segmento consta de un registro de entrada seguido de un
circuito combinatorio. El registro contiene los datos y el circuito combinatorio
ejecuta las suboperación en el segmento particular. La salida del circuito
combinacional es un segmento dado se aplica al registro de entrada del
siguiente segmento.
Se aplica un reloj a todos los registros después de que se ha transcurrido un
tiempo suficiente para ejecutar toda la actividad del segmento. De esta manera
la información fluye por la línea un paso a la vez.
Teoría de Bases de Datos II 183 UCENM
La organización de la línea se mostrará mediante un ejemplo:
Supongamos que deseamos ejecutar las operaciones multiplicar y sumar
combinadas con un flujo de números.
Ai * B1 + Ci para i=1,2,3,…7
Cada suboperación se va a implantar en un segmento dentro de la línea.
Cada segmento tiene uno o dos registros y un circuito combinatorio, como se
muestra en la figura 9.2. De R1 a R5 son registros que reciben nuestros datos
con cada pulso de reloj. El multiplicador y el sumador son circuitos
combinatorios. Las suboperaciones ejecutadas en cada segmento del conducto
son las siguientes:
Los cinco registros se cargan con datos nuevos en cada pulso de reloj. El
efecto de cada pulso de reloj se muestra en la tabla 9.-1 El primer pulso de reloj
transfiere A1 y B1 dentro de R1 y R2. El segundo pulso de reloj transfiere el
producto de R1 y R2 dentro de R3 y C1 dentro de R4. El mismo pulso de reloj
transfiere A2 y B2 dentro de R1 y R2. El tercer pulso de reloj opera sobre los
tres segmentos en forma simultánea. Coloca a A3 y B3 dentro de R1 y R2,
transfiere el producto R1 y R2 dentro de R3, transfiere C2 dentro de R4 y
coloca la suma de R3 y R4 dentro de R5. Se necesita tres pulsos de reloj para
llenar la línea y recuperar la primera salida de R5. De ahí en adelante, cada
ciclo de reloj produce una nueva salida y mueve los datos un paso adelante en
la línea. Estos sucede en tanto fluyan nuevos datos dentro del sistema cuando
ya no hay datos de entrada disponibles, el reloj debe continuar hasta que
emerge la última salida de la línea
Consideraciones generales
Cualquier operación que pueden descomponerse en una secuencia de
suboperaciones de aproximadamente la misma complejidad, puede
implementarse mediante un procesador de arquitectura paralela. La técnica es
eficiente para aquellas aplicaciones que necesitan repetir la misma tarea
Teoría de Bases de Datos II 184 UCENM
muchas veces con diferentes conjuntos de datos. La estructura general de una
línea de cuatros segmentados .
Los operandos recorren los cuatros segmentos de una secuencia fija. Cada
segmento consta de cada circuito combinacional Si Que ejecuta una
suboperación sobre el flujo de datos que fluyen por la línea.
Los segmentos se separan mediante registros Ri Que contienen los resultados
intermedios entre las etapas. La información fluye entre etapas adyacentes
bajo el control de un reloj común aplicado a todos los registros en forma
simultánea definimos una tarea como la operación total ejecutada cuando se
recorren todos los segmentos en la línea.
Línea paralela de cuatro segmentos
Para ver el gráfico seleccione la opción "Descargar" del menú superior
El desempeño de la arquitectura paralela puede ilustrarse mediante un
diagrama espacio- tiempo. Este es un diagrama que muestra la utilización del
segmento como una función del tiempo. El diagrama espacio-tiempo de un
conducto con cuatro segmentos s.
El eje horizontal muestra el tiempo en ciclos de reloj y el eje vertical
proporciona el número de segmentos el diagrama muestra seis tareas de la T1
a la T6 ejecutada en cuatros segmentos. Al principio, ala tarea T1 se maneja
mediante el segmento.
Después del primer ciclo de reloj, el segmento 2 esta ocupado con T1 mientras
que el segmento 1 esta ocupado con la tarea T2. A continuar de esta manera la
primera tarea T1 se complementa después del cuarto ciclo de reloj.
De ahí en adelante la línea completa una tarea en cada ciclo de reloj.
No importa cuántos segmentos existan en el sistema, una vez que la línea está
llena, solo se necesita un periodo de reloj para obtener una salida.
Ahora consideremos el caso en donde se utiliza una línea de K de segmentos
para ejecutar "n" tareas con un tiempo de ciclo de reloj Tp, la primera tarea T1
necesita un tiempo igual a KTp para completar su operación, porque existen K
Teoría de Bases de Datos II 185 UCENM
segmentos en la línea. Las n-1 tareas restantes emergen en la línea a una
velocidad de una tarea por ciclo de reloj y se terminará después de un tiempo
igual (n-1)tp por lo tanto, para completar n tareas una línea en K segmentos se
necesita K+ (n-1) ciclos de reloj. Por ejemplo, el diagrama de la figura 9-4
muestra cuatros segmentos y seis tareas.
El tiempo requerido para completar todas las operaciones es 4 + (6-1)=9 ciclos
de reloj según se indica en el diagrama.
1 2 3 4 5 6 7 8 9
Ciclos de
reloj
Segmento 1 T1 T2 T3 T4 T5 T6
2
T1 T2 T3 T4 T5 T6
3
T1 T2 T3 T4 T5 T6
4
T1 T2 T3 T4 T5 T6
Figura 9.4 Diagrama espacio-tiempo para línea paralela
A continuación consideremos una unidad de arquitectura no paralela que
ejecuta la misma operación y requiere un tiempo igual a Tn para completar
cada tarea. El tiempo total requerido para n tareas es NTn.
La aceleración de un procesamiento por arquitectura paralela sobre un
procesamiento no paralelo equivalente se define mediante la relación:
Conforme aumenta la cantidad de tareas, n se vuelve mucho más grande que
K-1, y K+n-1 se aproxima al valor de n. Bajo esta condición, la aceleración se
convierte en:
Si consideramos que el tiempo que se necesita para procesar una tarea es
igual en una arquitectura paralela y en una arquitectura no paralela, tendremos
Tn = KTp.
Al incluir esta suposición, la aceleración se reduce a:
Esto muestra que la máxima aceleración teórica que puede proporcionar un
conducto es K, en donde K es la cantidad de segmentos en el conducto.
Teoría de Bases de Datos II 186 UCENM
Para duplicar la ventaja de velocidad teórica de un proceso paralelo mediante
unidades funcionales múltiples, es necesario construir k segmentos iguale el
desempeño de k copias de un circuito de arquitectura no paralela equivalente
bajo condiciones de operación iguales.
En donde están conectados en paralelo cuatro circuitos idénticos. Cada circuito
P ejecuta la misma tarea de un mismo circuito con arquitectura paralela
equivalente. En lugar de operar con los datos de entrada en secuencia, como
en una línea, los circuitos paralelos aceptan cuatro conjuntos de datos de
entrada en forma simultánea y ejecutan cuatro tareas al mismo tiempo.
En lo que se refiere a la velocidad de operación esta es equivalente a una línea
con cuatro segmentos. Nótese que el circuito de cuatro unidades, constituye
una organización de instrucción única, datos múltiples en paralelo.
Unidades funcionales múltiples en paralelo
Existen varias razones por las que una arquitectura paralela no puede operar a
su máxima velocidad teórica. Los diferentes segmentos pueden requerir
tiempos diferentes para completar su suboperación. Debe elegirse el ciclo de
reloj para iguale el tiempo de retraso del segmento con el máximo tiempo de
propagación. Esto provoca que los otros segmentos desperdicien tiempo
mientras esperan el siguiente ciclo de reloj.
Además no siempre es correcto considerar que un circuito de arquitectura tiene
el mismo retraso de tiempo que un circuito con arquitectura paralela
equivalente. Muchos de los registros intermedios no se necesitarán en un
circuito de una sola unidad el cual, por lo general, puede construirse por
completo como un circuito combinatorio.
No obstante, la técnica de arquitectura paralela proporciona una operación
más rápida que una secuencia puramente serial, aunque nunca se logra por
completo la máxima velocidad teórica.
Teoría de Bases de Datos II 187 UCENM
Existen dos áreas de diseño de computadoras en las que es aplicable la
organización paralela. Una línea aritmética divide una operación aritmética en
suboperaciones que se ejecutan en los segmentos de la línea.
Una línea de instrucciones opera sobre un flujo de instrucciones al sobreponer
las fases de recuperación, decodificación y ejecución. En las siguientes
secciones se explican los dos tipos de líneas.
Línea paralela aritmética
Por lo general, se encuentran unidades aritméticas de arquitectura paralela en
computadoras de gran velocidad. Se usan para implantar operaciones de punto
flotante, multiplicación de números de punto fijo y cálculos similares
encontrados en problemas científicos.
En esencia, un multiplicador de arquitectura paralela es un arreglo multiplicador
como el que se describe en la figura 10-10, con sumadores especiales
diseñados para minimizar el tiempo de propagación de acarreo mediante los
productos parciales.
Las operaciones de punto flotante se descomponen con facilidad en
suboperaciones, como se muestra en la sección 10-5. Ahora mostraremos un
ejemplo de una unidad paralela para suma y resta de punto flotante.
Las entradas para la línea sumadora de punto flotante son dos números
binarios normalizados de punto flotante.
X = A X 2ª
Y = B X 2b
A y B son dos fracciones que representan las mantisas, en tanto que a y b son
los exponentes. Puede ejecutarse la suma y resta de punto flotante en cuatro
segmentos.
Los registros etiquetados R se colocan entre los segmentos para almacenar los
resultados intermedios. Las sub-operaciones que se ejecutan en los cuatro
segmentos son:
1. Comparar los exponentes.
Teoría de Bases de Datos II 188 UCENM
2. Alinear las mantisas.
3. Sumar o restar las mantisas.
4. Normalizar el resultado.
Esto se apega al procedimiento delineado, pero se usan algunas variaciones
para reducir el tiempo de ejecución de las suboperaciones. Se comparan los
exponentes al restarlos para determinar su diferencia. Se escoge el exponente
mayor como el exponente del resultado.
La diferencia entre exponentes determina cuántas veces debe ejecutarse un
corrimiento a la derecha sobre la mantisa asociada con el exponente menor.
Esto provoca un alineamiento de las dos mantisas. Debe notarse que el
corrimiento debe estar diseñado como un circuito combinatorio para reducir el
tiempo de corrimiento.
Las dos mantisas se suman o restan en el segmento 3. El resultado se
normaliza en el segmento 4. Cuando ocurre un sobre flujo, la mantisa de la
suma o diferencia se recorre a la derecha y el exponente se incrementa en 1.
Si ocurre un sobre flujo, la cantidad de números 0 significativos en la mantisa
determina el número de corrimientos a la izquierda y la cantidad que debe
restarse del exponente.
El siguiente ejemplo numérico puede aclarar las sub-operaciones que se
ejecutan en cada segmento. Por simplicidad utilizamos números binarios.
Consideremos los dos números de punto flotante normalizados:
X = 0.9504 X 103
Y = 0.8200 X 102
Línea paralela de instrucciones
El procesamiento por línea paralela puede ocurrir en el flujo de datos y también
en el flujo de instrucciones. Una línea paralela de instrucciones lee
instrucciones consecutivas de la memoria mientras, en otros segmentos, se
ejecutan instrucciones anteriores.
Teoría de Bases de Datos II 189 UCENM
Una posible digresión asociada con tal esquema es que una instrucción puede
producir un brinco fuera de secuencia.
En tal caso, debe vaciarse la línea y deben descartarse todas las instrucciones
que se han leído de la memoria después de la instrucción de brinco.
Consideremos una computadora con una unidad de recuperación y una unidad
de ejecución de instrucciones diseñada para proporcionar una línea de dos
segmentos. Puede implantarse el segmento de recuperación de instrucciones
mediante un registro intermedio (buffer) primero en entrar, primero en salir
(FIFO). Este es un tipo de unidad que forma una cola en lugar de una pila.
Cuando la unidad de ejecución no está usando la memoria, el control
incrementa el contador de programa y utiliza su valor de dirección para leer
instrucciones consecutivas de la memoria.
Las instrucciones se insertan en el registro intermedio FIFO para que puedan
ejecutarse en un esquema primero en entrar, primero en salir. Por lo tanto,
puede colocarse un flujo de instrucciones en una cola, en espera que lo
decodifique y procese el segmento de ejecución.
El mecanismo de formación de colas con flujos de instrucciones proporciona
una manera eficiente para reducir el tiempo promedio de acceso a memoria
para leer instrucciones.
Cuando hay espacio en recuperación de instrucciones.
El registro intermedio actúa como una cola de la que el control obtiene las
instrucciones para la unidad de ejecución.
Las computadoras con instrucciones complejas requieren otras fases además
de las de recuperación y ejecución para procesar por completo una instrucción.
En el caso más general, la computadora necesita procesar cada instrucción
con la siguiente secuencia de pasos.
1. Recuperar la instrucción de la memoria
2. Decodificar la instrucción
3. Calcular la dirección efectiva
Teoría de Bases de Datos II 190 UCENM
4. Recuperar los operandos de la memoria
5. Ejecutar la instrucción
6. Almacenar el resultado en el lugar adecuado.
Existen ciertas dificultades que evitarán que la línea paralela de instrucciones
funcione a su velocidad máxima. Segmentos diferentes pueden necesitar
tiempos diferentes para actuar sobre la información que llega.
Se saltan algunos segmentos para ciertas operaciones. Por ejemplo, una
instrucción de modo de registro no necesita un cálculo de dirección efectiva.
Dos o más segmentos pueden requerir el acceso a la memoria al mismo
tiempo, provocando que un segmento espere hasta que otro termine su
comunicación.
En ocasiones, se resuelven los conflictos de acceso a memoria al usar dos
canales de memoria para acceder las instrucciones y los datos en módulos
separados. De esta manera, pueden leerse de forma simultánea una palabra
de instrucción y una palabra de datos de dos módulos diferentes.
El diseño de una línea paralela de instrucciones será más eficiente si se divide
el ciclo de instrucciones en segmentos de igual duración. El tiempo que
necesita cada paso para terminar su función depende de la instrucción y de la
manera como se ejecuta.
Ejemplo: Línea paralela de instrucciones de cuatro segmentos
Consideremos que pueden combinarse en un segmento de decodificación de la
instrucción y el cálculo de la dirección efectiva. Además, consideremos que la
mayoría de las instrucciones colocan el resultado en un registro de procesador,
para que la ejecución de la instrucción y el almacenamiento del resultado
puedan combinarse en un segmento. Esto reduce la línea paralela de
instrucciones a cuatro segmentos.
El ciclo de instrucciones en la CPU con una línea paralela de cuatro
segmentos. Mientras se ejecuta una instrucción en el segmento cuatro, la
siguiente instrucción en secuencia se ocupa en recuperar un operando de la
memoria en el segmento 3.
Teoría de Bases de Datos II 191 UCENM
En un circuito aritmético separado puede calcularse la dirección efectiva para la
tercera instrucción y, cuando está disponible la memoria, pueden recuperarse y
colocarse en una localidad del registro intermedio FIFO la cuarta instrucción y
todas las subsecuentes. Por lo tanto, pueden traslaparse y estar en proceso
hasta cuatro suboperaciones en el ciclo de instrucciones.
De vez en cuando, una instrucción en la secuencia puede ser del tipo de
control de transferencia del programa que produce un brinco fuera de la
secuencia normal.
En ese caso, se terminan las operaciones pendientes en los últimos dos
segmentos y se borra toda la información almacenada en el registro intermedio
de instrucciones. Después, la línea paralela y vuelva a iniciar a partir de un
nuevo valor de dirección
Arquitectura paralela de CPU de cuatro segmentos.
El tiempo en el eje horizontal se divide en pasos de igual duración. En el
diagrama, los cuatro segmentos se representan con un símbolo abreviado.
1. FI es el segmento que recupera una instrucción
2. DA es el segmento que decodifica la instrucción y calcula la dirección
efectiva.
3. FO es el segmento que recupera el operando.
4. EX es el segmento que ejecuta la instrucción.
Figura 8 Temporización d línea paralela de instrucciones.
Paso 1 2 3 4 5 6 7 8 9 10 11 12 13
1 FI DA FO EX
2
FI DA FO EX
3
FI DA FO EX
4
FI - - FI DA FO EX
5
- - - FI DA FO EX
Teoría de Bases de Datos II 192 UCENM
6
FI DA FO EX
7
FI DA FO EX
Se considera que el procesador tiene memorias de instrucciones y datos
separadas, por lo que puede avanzar la operación en FI y FO, al mismo tiempo.
En ausencia de una instrucción de transferencia de control, cada segmento
opera sobre instrucciones diferentes.
Por lo tanto, en el paso 4, se ejecuta la instrucción en el segmento EX; el
operando para la instrucción 2 se recupera en el segmento FO; en el segmento
DA se decodifica la instrucción 3 y en el segmento FI se recupera de la
memoria la instrucción 4.
Supongamos que la instrucción 3 es una instrucción de transferencia de
control. Tan pronto como se decodifica esta instrucción en el segmento DA en
el paso 4, se detiene la transferencia de FI a DA de las otras instrucciones,
hasta que se ejecuta la instrucción de transferencia de control en el paso 6. Si
se da la transferencia, se recupera una nueva instrucción en el paso 7.
Si no se da la transferencia, puede usarse la instrucción recuperada antes, en
el paso 4. Después, la línea paralela continua la ejecución hasta que se
encuentra una nueva instrucción de transferencia de control.
Puede ocurrir otro retraso en la línea si el segmento EX necesita almacenar el
resultado de la operación en la memoria de datos mientras el segmento FO
necesita recuperar un operando. En ese caso, el segmento FO debe esperar
hasta que el segmento EX haya terminado su operación.
En general, existen tres dificultades principales que provocan que una línea de
instrucciones se aparte de su operación normal.
1. Conflictos de recursos, provocados al accesar la memoria dos segmentos
diferentes, al mismo tiempo. Gran parte de estos conflictos pueden
resolverse al utilizar memorias de instrucciones y de datos separadas.
Teoría de Bases de Datos II 193 UCENM
2. Surgen conflictos de dependencia de datos cuando una instrucción
depende del resultado de una anterior, pero éste todavía no está
disponible.
3. Se producen dificultades de transferencia de control a partir de
instrucciones que modifican el valor del PC.
Teoría de Bases de Datos II 194 UCENM
CUESTIONARO
1-.¿Que comprendió por bases datos paralela?
2-.¿Que es paralelismo entre consultas?
3-.¿Que es Ordenacion Paralela?
4-.¿Cuales son las otras operaciones relacionales que existen?
5-.¿Que significa eliminación por duplicados?
Teoría de Bases de Datos II 195 UCENM
6-.¿Que significa Costo de la evaluación en paralelo de las operaciones?
7-Explique en que consisten los Diseño de sistemas paralelos.
8-.¿Que es una Bases de Datos GRID?
9-.¿Caules son las características de esta arquitectura?
10-.¿Cuales son los servicion dentro del Grid(base datos?
Teoría de Bases de Datos II 196 UCENM
Teoría de Bases de Datos II 197 UCENM
BIBLIOGRAFIA
TTooddaass llaass ppaannttaallllaass,, LLooggooss ddee WWiinnddoowwss ssoonn mmaarrccaass
RReeggiissttrraaddaass ddee MMiiccrroossoofftt CCoorrppoorraacciióónn EEEE..UUUU yy oottrrooss
PPaaíísseess
TTooddaass llaass ppaannttaallllaass,, LLooggooss ddee MMAACC ssoonn mmaarrccaass
RReeggiissttrraaddaass
CCiissccoo NNeettwwoorrkkiinngg AAccaaddeemmyy
PPrrooggrraamm((DDeerreecchhooss
RReesseerrvvaaddooss))
VVeerrssiioonn 33..11
www.recursos-vista.es (CC) 2007
www.aulaclick.com
www.adlszone
www.microsoft.com
www.ubuntu
Sistemas operativos pearsons
www.lawebdelprogramador
www.abcdatos.com
Teoría de Bases de Datos II 198 UCENM
Top Related