Teoría Bases Datos II UCENM

Teora Bases Datos II Universidad Cristiana Evanglica Nuevo Milenio (UCENM)
Impresin Offset: Corporacin Nuevo Milenio (C.N.M.) Tel 2552-4100 E-mail:primiciadefe@hotmail.com Primera Impresin: Tegucigalpa M.D.C., Junio, 2011
Teora de Bases de Datos II
UCENM
Captulo
1. Consultas
INDICE I
3- 41
Conceptos de consultas. Tipos de Consultas en bases de datos. Consultas simple y complejas. Algebra Relacional. Comandos de Consulta. Ejemplos de consultas.
Captulo
II 42- 73
2. Transacciones.
Introduccin a las Transacciones. Propiedades de la Transacciones. Gestin de Transacciones. Instrucciones para uso de Transacciones. Tcnicas para implantacin de Transacciones. Protocolos de Compromisos. Estructura de Transacciones. Proceso de Transacciones. Transacciones en sistemas Distribuidos. Ejemplo tipo de Transacciones Distribuidas.
Captulo
III .74-100
3. Concurrencia
El control de Concurrencia Principales algoritmos Algoritmo de cerradura o candado. Control comn en sistema de archivo. Prevencin de Abrazo Mortales. Introduccin a la concurrencia ADO.NET Concurrencia en base de datos Ejemplos de concurrencia. Teora de Bases de Datos II 2 UCENM
Captulo
IV .101- 155
4. Bases de Datos Distribuidas.

Introduccin a Bases de Datos Distribuidas. Administracion de una DDBMS Cuadro de Ventajas y Desventajas bases datos distribuidas. Configuraciones Principales. Transparencia y Autonoma. Diseo de base datos distribuidas. Tipos de Fragmentacin. Tres entrada necesarias para desarrollo de fragmentacin. Fragmentacin Mixta o Hibrida. Tipos Bases datos Distribuidas. Cuatro Metas de un DBMS Distribuidas.
Capitulo
V 156- 195
5. Base de Datos Paralelas.

Introduccin a base datos paralela. Paralelismo entre consulta. Paralelismo entre Operaciones. Ordenacin entre Operaciones. Eliminacin de Duplicados. Costos de evaluacin en paralelo de operaciones. Diseo de sistema Paralelos en base datos GRID. Claves en seguridad GRID. Gestin de Claves. Criptografa de clave pblica. Integracin de base datos de un sistema GRID. Metadatos en base de Datos Sistema GRID. Procesamiento Paralelo.
UCENM
CONSULTAS
Objetivos del captulo I
1. 2. 3. 4. 5. Comprender y analizar el concepto consultas en Base .....de Datos. Conocer los tipos de esquemas en consulta. Conocer las consultas simple y complejas. Comprender la Algebra Relacional. Conocer los Comandos de Consultas.
UCENM
Introduccin a las Consultas de Base de Datos En bases de datos, una consulta es el mtodo 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 ms utilizado es el SQL.
Tcnicamente hablando, las consultas a la base de datos se realizan a travs de un lenguaje de manipulacin de datos (DML Data Manipulation Language). SQL es un lenguaje DML, pero adems posee otras caractersticas de otros lenguajes. Por ejemplo, permite tambin crear bases de datos. Un esquema es un conjunto lgico 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 ms de un esquema. Por ejemplo, un esquema estrella est compuesto de tablas, donde una gran y central tabla tiene toda la informacin importante, con la que se accede, va claves ajenas, a tablas dimensionales, las cuales tienen informacin de detalle, y pueden ser usadas en una unin para crear informes detallados. Un esquema en estrella es aquel que tiene una tabla facturas de hechos que contiene los datos de anlisis, rodeada de las tablas lookup o de dimensiones. Este aspecto, de tabla de hechos (o central) ms grande rodeada de radios o tablas ms pequeas 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 interseccin de las dimensiones que la definen. Este esquema es ideal por su simplicidad y velocidad para ser usado para anlisis: Data Marts? (Mercado de datos) y EIS (Sistemas de informacin ejecutiva). Teora de Bases de Datos II 5 UCENM
Permite acceder tanto a datos agregados como de detalle. Adems, permite reducir el nmero de joins entre tablas y deja a los usuarios establecer jerarquas y niveles entre las dimensiones. Finalmente, es la opcin 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 informacin en procesos, vistas y mtricas recordando a una estrella (por ello el nombre star schema). Es decir, tendremos una visin multidimensional de un proceso que medimos a travs de unas mtricas. A nivel de diseo, consiste en una tabla de hechos (lo que en los libros encontraremos como fact table) en el centro para el hecho objeto de anlisis y una o varias tablas de dimensin (dimensin table) por cada dimensin de anlisis que participa de la descripcin de ese hecho. En la tabla de hecho encontramos los atributos destinados a medir (cuantificar) el hecho: sus mtricas. Mientras, en las tablas de dimensin, los atributos se destinan a elementos de nivel (que representan los distintos niveles de las jerarquas de dimensin) y a atributos de dimensin (encargados de la descripcin de estos elementos de nivel). En el esquema en estrella la tabla de hechos es la nica tabla del esquema que tiene mltiples joins que la conectan con otras tablas (foreign keys hacia otras tablas). El resto de tablas del esquema (tablas de dimensin) nicamente hacen join con esta tabla de hechos.
UCENM
Las
tablas
de
dimensin
se
encuentran
adems
totalmente
denormalizadas, es decir, toda la informacin referente a una dimensin 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 representacin derivado del esquema en estrella, en el que las tablas de dimensin se normalizan en mltiples tablas. Por esta razn, 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 anlisis se representan ahora en tablas de dimensin normalizadas. En la estructura dimensional normalizada, la tabla que representa el nivel base de la dimensin 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 dimensin. Para conseguir un esquema en copo de nieve se ha de tomar un esquema en estrella y conservar la tabla de hechos, centrndose nicamente en el modelado de las tablas de dimensin, que si bien en el esquema en estrella se encontraban totalmente denormalizadas, ahora se dividen en subtablas tras un proceso de normalizacin. Es posible distinguir dos tipos de esquemas en copo de nieve, un snowflake completo (en el que todas las tablas de dimensin en el esquema en estrella aparecen ahora normalizadas en el snowflake) o un snowflake parcial (slo se lleva a cabo la normalizacin de algunas de ellas).
UCENM
Esquema de relacin y esquema relacional En un esquema de relacin debemos especificar los atributo s y dominios sobre los que se define la relacin, as como las restricciones de integridad que se deben cumplir para que la relacin constituya una ocurrencia vlida del esquema; es decir, aquellas restricciones que afectan a cada uno de los elementos que forman parte del correspondiente esquema de relacin (restricciones intraelementos). Por tanto, podremos definir un esquema de relacin como: R <A:D, S> Siendo R el nombre de la relacin, A la lista de atributos, D los dominios sobre los que estn definidos los atributos y S las restricciones de integridad, intraelementos. El esquema de la base de datos relacional ser una coleccin de esquemas de relacin 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 relacin, e {Ii} representa el conjunto de restricciones de integridad nter elementos. Podemos definir una base de datos relacional variable relacional siguiendo la terminologa de DATE (1995) como un esquema relacional junto con una ocurrencia vlida de dicho esquema, es decir, una ocurrencia que cumple todas las restricciones descritas en el esquema. La creacin de esquemas se lleva a cabo mediante la sentencia: <Definicin de esquemas>::= CREATE SCHEMA <clusula de nombre del esquema> Teora de Bases de Datos II 8 UCENM
[<Especificacin del conjunto de caracteres del esquema>] [<Elementos de esquemas>] <Clusula de nombre del esquema> ::= <Nombre del esquema> | AUTHORIZATION <id. Autorizacin del esquema | <Nombre del esquema AUTHORIZATION <id. Autorizacin Del esquema> Podramos, por ejemplo, crear el siguiente esquema: CREATE SCHEMA biblioteca AUTHORIZATION uc3m; Diferencia entre una simple consulta de fila y una mltiple consulta de filas Primero, para cubrir lo obvio, una consulta de una slo fila es una consulta que slo devuelve una fila como resultado, y una consulta de mltiples filas es una consulta que devuelve ms de una fila como resultado. Si una consulta devuelve una fila o ms esto depende enteramente del diseo (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 mltiples filas). Por ejemplo, si quieres estar seguro que una consulta de la tabla Propietarios _ antigedades devuelve slo una fila, considera una condicin de igualdad de la columna de la clave prim aria, ID _ propietario. Tres razones vienen inmediatamente a la mente de por qu esto es importante. Primero, tener mltiples filas cuando t slo esperabas una, o viceversa, puede significar que la consulta es errnea, que la base de datos est incompleta, o simplemente, has aprendido algo nuevo sobre tus datos. Teora de Bases de Datos II 9 UCENM
Segundo, se ests usando una sentencia Update o Delete, debes de estar seguro que la sentencia que ests escribiendo va a hacer la operacin en la fila (o filas) que t quieres o sino, estars borrando o actualizando ms filas de las que queras. Tercero, cualquier consulta escrita en SQL embebido debe necesitar ser construida para completar el programa lgico requerido. Si su consulta, por otra parte, devuelve mltiples filas, debers usar la sent encia Fetch, y muy probablemente, algn tipo de estructura de bucle para el procesamiento iterativo de las filas devueltas por la consulta. Hay algn filtro en general que pueda usar para hacer mis consultas SQL y bases de datos mejores y ms rpidas (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 porcin 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 ms tiempo recuperar los datos que si las columnas fueran seleccionadas de forma normal, y las expresiones se manejaran programticamente. Si estas usando una unin, trata de tener las columnas unidas por ndices (desde ambas tablas). Cuando tengas dudas, ndice. A no ser que tengas mltiples cuentas o consultas complejas, usa COUNT (*) (el nmero de filas generadas por la consulta) mejor que COUNT (Nombre _ columna). Escribiendo y Editando Consultas Manualmente La tarea realizada ms comn con el MySQL Query Browser es ejecutar consultas y analizar sus resultados. La manera ms directa de crear consultas es escribirlas directamente sobre el rea de consultas.
10
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 lneas inciales de altura a un mximo de diez lneas de altura. Para espacio adicional, usted puede presionar la tecla F11 para maximiz ar el rea de consultas. Tambin puede seleccionar la opcin Maximizar rea de Consulta de el men Ver para maximizar el rea de consultas. Cuando una consulta es maximizada, el nmero de lneas es desplegado para la consulta, y el rea de consulta puede ser redimensionada haciendo click y arrastrando la lnea 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 botn Ejecutar y los resultados de la consulta sern desplegados en el rea de resultados. Usted puede tambin presionar las teclas ctrl.+ Aceptar para ejecutar la consulta. Si hay algn 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 cdigo del error. En adicin para cargar resultados de consultas en el rea de resultados activa, usted puede tambin 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 seccin. 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 botn Ejecutar y escoja la opcin Ejecutar en nueva Pestaa 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 botn Ejecutar y escoja la opcin Dividir Pestaa y Ejecutar o presione las teclas ctrl.+Alt+Enter.
11
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 conexin, o click -derecho en la base de datos en el navegador de base de datos y eligiendo la opcin Hacer Esquema por Defecto, o eligiendo la opcin 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 ms eficientemente, el MySQL Query Browser puede copiar consultas desde el cdigo de aplicaciones usando su entorno (IDE) favorito. Esta funcionalidad est solamente disponible para la versin de MySQL Query Browser para Windows. El siguiente cdigo 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 cdigo (incluyendo la porcin de asignacin), click derecho dentro del rea de consultas del MySQL Query Browser, y elegir la opcin Pegar Contenido del portapapeles como cdigo PHP. Las porciones que no son consulta sern removidas y la consulta ser pegada dentro del rea de consultas. Los elementos dinmicos de la consulta son convertidos en parmetros locales, visibles en el navegador de parmetros: SELECT Id, Name, Country FROM City WHERE Name LIKE: cityname
12
UCENM
Para establecer un valor a un parmetro local, seleccione el valor en el navegador de parmetros y presione F2. Usted tambin puede dar doble -click sobre el valor para editarlo. El valor que asigne ser usado cuando la consulta sea ejecutada. Despus de editar una consulta, click-derecho dentro del rea de consultas y elegir la opcin Copiar Consulta Como Cdigo PHP. El cdigo PHP que corresponde ser re-insertado junto con la consulta modificada. Esta funcionalidad permite editar consultas rpidamente 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 ms compleja y potente de las sentencias SQL. Empezaremos por ver las consultas ms simples, basadas en una sola tabla. Esta sentencia forma parte del DML (lenguaje de manipulacin de datos), en este tema veremos cmo seleccionar columnas de una tabla, cmo seleccionar filas y cmo obtener las filas ordenadas por el criterio que queramos. El resultado de la consulta es una tabla lgica, 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.
13
UCENM
Si no conoces todava las tablas que utilizaremos para los ejemplos y ejercicios clic aqu
Sintaxis de la sentencia SELECT (consultas simples)
La tabla origen - FROM Con la clusula FROM indicamos en qu tabla tiene que buscar la informacin. En este captulo de consultas simples el resultado se obtiene de una nica tabla. La sintaxis de la clusula es: FROM especificacin de tabla Una especificacin 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:
14
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, adems ese nombre slo es vlido en la consulta donde se define. El alias se suele emplear en consultas basadas en ms 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 ningn 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 estn 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 clusula IN. En la clusula IN el nombre de la base de datos debe incluir el camino completo, la extensin (.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\, habra 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 clusula IN. Seleccin de columnas La lista de columnas que queremos que aparezcan en el resultado es lo que llamamos lista de seleccin y se especifica delante de la clusula
15
UCENM
FROM.
Utilizacin del * Se utiliza el asterisco * en la lista de seleccin para indicar 'todas las columnas de la tabla'. Tiene dos ventajas: Evitar nombrar las columnas una a una (es ms corto). Si aadimos 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 ms cuando el origen de la consulta son dos tablas. SELECT * FROM oficinas o bien SELECT oficinas.* FROM 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 ms adelante. Cuando el nombre de la columna o de la tabla contiene espacios en blanco, hay que poner el nombre entre corchetes [ ] y adems el nmero de espacios en blanco debe coincidir. Lista todos los datos de las oficinas
16
UCENM
Por ejemplo [codigo de cliente] no es lo mismo que [ cdigo de cliente] (el segundo lleva un espacio en blanco delante de cdigo) Ejemplos : SELECT nombre, oficina, contrato FROM ofiventas SELECT idfab, idproducto, descripcin, precio FROM 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 clusula AS ser el nombre que aparecer como ttulo de la columna. Ejemplo: SELECT idfab AS fabricante, idproducto, descripcin FROM productos Columnas calculadas. Adems 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 seleccin una expresin en vez de un nombre de columna. La expresin puede contener sumas, restas, multiplicaciones y divisiones, concatenacin & , parntesis y tambin funciones predefinidas). Teora de Bases de Datos II 17 UCENM Lista una tarifa de productos
Lista el nombre, oficina, y fecha de contrato de todos los empleados.
..Como ttulo de la primera columna .aparecer fabricante en vez de idfab
Para ver con ms detalle cmo formar una expresin pincha aqu Ejemplos: SELECT ciudad, regin, (ventasobjetivo) AS supervit FROM oficinas
Lista la ciudad, regin y el supervit de cada oficina.
SELECT idfab, idproducto, descripcin, (existencias * precio) AS valoracin FROM productos
De cada producto obtiene su fabricante, idproducto, su descripcin y el valor del inventario Lista el nombre, mes y ao del
SELECT nombre, MONTH(contrato), YEAR(contrato) FROM repventas
contrato de cada vendedor. La funcin MONTH() devuelve el mes de una fecha La funcin YEAR() devuelve el ao de una fecha
SELECT oficina, 'tiene ventas de ', ventas FROM oficinas Consultas complejas
Listar las ventas en cada oficina con el formato: 22 tiene ventas de 186,042.00 lps
Uno de los temas que ms cuesta a los que empiezan a aprender SQL son las consultas en las que se recogen diferentes tipos de datos de una mltiples tablas. Este artculo es una introduccin a cmo definir consultas de este tipo en PostgreSQL. Unos conocimientos bsicos de normalizacin de datos y un poco de lgebra relacional no vienen mal para entender mejor algunos de los trminos que vamos a usar en este artculo. Teora de Bases de Datos II 18 UCENM
La normalizacin de datos es tema para otro artculo, 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 relacin resultado. Es la base indispensable para poder escribir buenas consultas en SQL. Las operaciones ms importantes disponibles en lgebra relacional son:
Las operaciones de conjunto aplicadas a relaciones: unin(), interseccin() y diferencia(-) Operaciones que eliminan una parte de las relaciones:
seleccin() y proyeccin()
Operaciones que combinan las duplas de dos relaciones: producto cartesiano(x), combinacin natural (><) y theta Operacin que cambia el nombre de los atributos relaci n: renombre()
A continuacin vamos a dar una breve introduccin sobre estas operaciones: Unin [RS] La unin 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 unin. En el lenguaje SQL este tipo de operacin se puede realizar con la clausula UNION Interseccin [RS] La interseccin de R y S es el conjunto de elementos que existen en R y en S. En el lenguaje SQL este tipo de operacin 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 operacin se puede realizar con la clausula EXCEPT Teora de Bases de Datos II 19 UCENM
Seleccin [c(R)] Esta operacin aplicada a una relacin R, produce una nueva relacin con un subconjunto de duplas de R. Este subconjunto de duplas satisface y cumple cierta condicin(c) Proyeccin [a1,a2,...,an(R)] Esta operacin aplicada a una relacin R, produce una nueva relacin con solamente los atributos (columnas) especificados por a1,a2,...,an Producto cartesiano [RxS] El producto cartesiano de dos relaciones R y S es la relacin que se obtiene de la combinacin de todas las duplas de R con todas las duplas de S. Las duplas de la relacin que se obtiene estn formadas por todos los atributos de R seguidos de todos los atributos de S. En el lenguaje SQL este tipo de operacin se puede realizar con la clusula CROSS JOIN separando las relaciones usadas en el producto con comas, en el FROM de la sentencia SQL. Combinaciones Por medio del operador combinacin (JOIN) podemos combinar dos relaciones segn una condicin para obtener duplas compuestas por atributos de las dos relaciones combinadas. En el lenguaje SQL existen diferentes maneras de combinar dos relaciones. A continuacin 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 despus de aplicar al producto cartesiano de las dos relaciones R y S, una condicin 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 condicin que acota el resultado es una comparacin 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
20
UCENM
relaciones que se combinan, solo se incluir una de ellas en el resultado de la combinacin. Combinaciones externas (OUTER JOINS): Un OUTER JOIN entre dos relaciones R y S contiene todas las duplas que un INNER JOIN devolvera, ms una serie de duplas que no tienen atributos en comn 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 combinacin que tengan un atributo comn, ms todas las duplas de la relacin de la izquierda (R) que no tengan un equivalente en la relacin 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 combinacin que tengan un atributo comn, ms todas las duplas de la relacin de la derecha (S) que no tengan un equivalente en la relacin 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 combinacin que tengan un atributo comn, ms todas las duplas de la relacin de la izquierda (R) que no tenga un equivalente en la relacin de la derecha (S) y todas las duplas de la relacin de la derecha (S) que no tenga un equivalente en la relacin de la izquierda (R). Esta operacin aplicada a una relacin R, produce una nueva relacin idntica 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 ms menos complejas. Utilizando los operadores definidos en algebra relacional, podemos definir de manera grfica (rboles) lineal la representacin algebraica de nuestra consulta. En consultas muy complicadas es lo que se debera de hacer antes de empezar a escribir el cdigo SQL, pero este es un tema para otro artculo.
21
UCENM
Ejemplos prcticos Nada mejor que unos ejemplos bsicos para ver como se aplica la teora 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 unin 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 continuacin realizamos una interseccin entre las dos relaciones: postgres=# SELECT * FROM relacion_r INTERSECT SELECT * FROM relacion_s; a|b|c ---+---+--4|5|6 (1 row)
22
UCENM
La diferencia entre estas dos relaciones dara el siguiente resultado. Como podis ver, y por definicin, no es lo mismo la diferencia entre relacin y relacion_s, que entre relacion_s y relacin 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 cmo 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 ms 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 despus del FROM. postgres=# SELECT * FROM relacion_r,relacion_s; Teora de Bases de Datos II 23 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 clusula 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 definicin un producto cartesiano al que se le aplica una condicin para acotar el resultado. En este caso particular la condicin siempre se cumple para todas las duplas al utilizar el valor TRUE, con lo que obtendremos todas las duplas del producto cartesiano.
24
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 continuacin podeis ver cmo definir un INNER JOIN con la condicin definida dentro de ON(). Este ejemplo es un Equi-join al utilizarse una comparacin de igualdad en la condicin. 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 podra haber conseguido obteniendo el producto cartesiano de las dos relaciones y aplicando una condicin con WHERE (definicin 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) Teora de Bases de Datos II 25 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 artculo, existen diferentes maneras de obtener un mismo resultado utilizando diferentes tipos de consultas. Teniendo los conceptos claros y con prctica, os aseguro que todos estos tipos de consultas os saldrn de forma natural despus de un tiempo. A continuacin 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 Teora de Bases de Datos II 26 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 bsica de las operaciones que se pueden utilizar para obtener resultados con datos de mltiples relaciones. En la vida real nos encontraremos con casos muchos ms complicados en los que tendremos que combinar todas estas operaciones junto con el resto de operadores y clusulas SQL disponibles. En casos complicados es importante pensar antes de empezar a escribir nuestra consulta SQL. A continuacin vamos a ver un ejemplo un poco ms complicado para ver cmo 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 identificacin de los diferentes componentes usados para el ensamblado de diferentes modelos de PCs. Las columnas vacas de la tabla 'PC' significan componentes no presentes en dichos modelos. El resto de tablas contienen informacin adicional sobre los diferentes componentes usados para construir un PC. Teora de Bases de Datos II 27 UCENM
postgres=# SELECT * FROM pc; pcid | memoria | cpu | disco | tgrafica | precio ------+---------+---------+-----------+-----------+-----------------1 | mem0001 | cpu0001 | disco0001 | ati001 2 | mem0001 | cpu0001 | disco0002 | ati001 | 1000 | 1100
3 | mem0002 | cpu0002 | disco0003 | nvidia001 | 1400 4 | mem0004 | cpu0003 | disco0004 | nvidia001 | 1600 5| 6| | (6 rows) postgres=# SELECT * FROM cpu ; cpu_id | cpu_fabricante | cpu_tipo ---------+----------------+------------------cpu0001 | Intel cpu0002 | Intel cpu0003 | AMD (3 rows) postgres=# SELECT * FROM memoria ; mem_id | mem_capacidad | mem_tipo ---------+---------------+-----------mem0001 | mem0002 | mem0003 | mem0004 | (4 rows) postgres=# SELECT * FROM disco ; disco_id | disco_fabricante | disco_capacidad -----------+------------------+----------------disco0001 | seagate disco0002 | seagate disco0003 | seagate disco0004 | samsung (4 rows) Teora de Bases de Datos II 28 UCENM | | | | 350 500 1024 500 1024 | DDR SDRAM 1024 | DDR2 SDRAM 1024 | DDR3 SDRAM 2048 | DDR3 SDRAM | Core2 do | Core2 Quad | Athlon X2 | cpu0001 | disco0001 | ati001 | | ati001 | 400 | 900
postgres=# SELECT * FROM tgrafica ; tgraf_id | tgraf_fabricante -----------+----------------------ati001 | ati nvidia001 | nvidia Utilizando estas tablas vamos a realizar varias consultas: Consulta 1 Obtener una relacin de solo los modelos de PC 'completos' a la venta. Queremos toda la informacin 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 algn 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 informacin 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 acotarn 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
29
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) Teora de Bases de Datos II 30 UCENM
ORDER BY precio DESC;

El resultado de nuestra consulta presentar las caractersticas 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 3 | DDR2 SDRAM | 1024 | Intel 2 | DDR SDRAM | 1024 | Intel 1 | DDR SDRAM | 1024 | Intel (4 rows) | Athlon X2 | Core2 do | Core2 duo | samsung | 500 | nvidia | 1024 | nvidia | 500 | ati | 350 | ati | seagate | seagate | 1600 | 1400 | 1100 | 1000 | Core2 Quad | seagate
Consulta 2 Obtener una relacin de todos los modelos de PC a la venta. Queremos toda la informacin 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 algn componente. La tabla PC es la tabla principal de nuestra combinacin, 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 clusulas JOIN y por definicin es la que se encuentra ms a la izquierda. Por ello utilizaremos el tipo LEFT OUTER JOIN para conseguir el resultado de la consulta 1, ms todos los PC a los que le falta algn componente. Lo nico que tenemos que hacer es cambiar INNER JOIN por LEFT OUTER JOIN. La consulta quedara 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
31
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 caractersticas 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 3 | DDR2 SDRAM | 1024 | Intel 2 | DDR SDRAM | 1024 | Intel 1 | DDR SDRAM | 1024 | Intel 5| 6| | | | intel | | Athlon X2 | Samsung | | Core2 Quad | seagate | | Core2 do | seagate | | Core2 do | seagate | | Core2 do | seagate | | | | 500 | nvidia 1024 | nvidia 500 | ati 350 | ati 350 | ati | ati | 1600 | 1400 | 1100 | 1000 | | 900 400
(6 rows) Consulta 3 Obtener una relacin de solo los modelos de 'PC NO completos' a la venta. Queremos toda la informacin 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 podramos 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
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) 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 | 900 6 | 400 (2 rows) | | | | | | ati | | | Intel | Core2 do | seagate | 350 | ati |
33
UCENM
Consulta 4 Obtener una relacin de todos los PC que tengan CPUs de AMD y discos Samsung. Queremos toda la informacin 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;
34
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 (1 row) | Athlon X2 | Samsung | 500 | nvidia | 1600
Consulta 5 Obtener una relacin del nmero 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 segn el fabricante de la CPU utilizada, y contar cuantas duplas existen en cada grupo. Al necesitar solamente informacin contenida en la tabla 'CPU', solo tendremos que combinar la tabla 'PC' con la tabla 'CPU'. Como queremos obtener solamente los PC que tienen algn 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 continuacin vamos a agrupar el resultado obtenido segn el fabricante de la CPU y contaremos el nmero 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; Teora de Bases de Datos II 35 UCENM
El resultado obtenido seria: cpu_fabricante | total ----------------+-----------intel Amd (2 rows) En fin, espero que tenga una idea de cmo 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. Tambin 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 operacin. Existen cuatro tipos de consultas de comando Eliminacin, de Actualizacin, de Alineacin y de Creacin de Tablas y parmetros. 1. Consultas de eliminacin: Este tipo de consulta elimina un grupo de registros de una o ms tablas. Existe la posibilidad, por ejemplo, de utilizar una consulta de eliminacin para reemplazar los productos que se han dejado de producir o para aquellos sobre los cuales no existen pedidos. Con las consultas de eliminacin siempre se eliminan registros internos y no nicamente determinados campos de su interior. 2. Consultas de actualizacin: Este tipo aporta modificaciones globales a uno o ms tablas. Existe la posibilidad, por ejemplo, de aumentar en un 10 por ciento el precio de todos los productos lcteos o aumentar los salarios en un 5 por ciento a las personas pertenecientes a una determinada categora laboral. | | 4 1
36
UCENM
3. Consultas de alineacin: Estas consultas agregan un grupo de registros de una o ms tablas al final de una o ms tablas. Supongamos, por ejemplo, que se han conseguido nuevos clientes y existe una base de datos que contiene una tabla de informacin sobre estos. En vez de teclear nuevamente todas estas informaciones, se alinean en la tabla correspondiente de Clientes.
4. Consultas de creacin de tablas: Este tipo de consultas crea una nueva tabla basndose en todos los datos o parte de estos existentes en una o ms tablas. 5. Consultas de parmetros: Una consulta de parmetros es una consulta que, cuando se ejecuta, muestra una ventana de dilogo 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 aqul que no existe en la tabla y que se crea slo temporalmente dentro de una columna en la consulta para realizar algn tipo de operacin matemtica. Consulta sueldo 1. Las formulas o expresiones a poner en cada columna de la vista de diseo de la consulta son Columna Expresin 1 Salario 2 Bonificacin: salario* 5/100 3 Bruto: Salario+ Bonificacin 4 Retencin: Bruto* 8/100 5 Neto: Bruto Retencin 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.
37
UCENM
Segn lo que acabamos de ver podemos utilizar las consultas para realizar clculos de cualquier tipo, utilizando Nuestras propias expresiones con operadores ms o menos sencillos, as como con las funciones y operadores que trae Access. Funciones de grupo No obstante en muchas ocasiones necesitaremos realizar clculos 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 clculos 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 Funcin Descripcin Cuenta Para contar el nmero de filas del grupo Suma Para sumar el contenido del campo especificado de todas las filas del grupo Promedio Para hallar la media aritmtica del campo especificado de todas las filas del grupo Mn Para hallar el menor valor del campo especificado de todas las filas del grupo Mx Para hallar el mayor valor del campo especificado de todas las filas del grupo DesvEst Para hallar la desviacin tpica del campo especificado de todas las filas del grupo.
38
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.
39
UCENM
7-. Que significado tiene el smbolo 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.
40
UCENM
TRANSACCIONES
Objetivos del captulo II
1 .Comprender y analizar el concepto de Transacciones. 2 .Conocer las propiedades de las transacciones. 3 .Conocer las tcnicas de Implantacin. 4 .Comprender las estructuras de transacciones. 5 .Comprender los ejemplos de transacciones.
41
UCENM
INTRODUCCION A TRANSACCIONES DE BASE DE DATOS. Una transaccin en un Sistema de Gestin de Bases de Datos (SGBD), es un conjunto de rdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atmica. 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 transaccin, 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 transaccin 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 transaccin.

BEGIN TRAN: Especifica que va a empezar una transaccin. COMMIT TRAN: Le indica al motor que puede considerar la transaccin 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 deberan garantizar todas las propiedades ACID; en la prctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento. Un ejemplo de transaccin Un ejemplo habitual de transaccin 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.
42
UCENM
Para garantizar la atomicidad del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atmicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una cada del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna. Una transaccin es una secuencia de operaciones realizadas como una sola unidad lgica de trabajo. Una unidad lgica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades de atomicidad, coherencia, aislamiento y durabilidad (ACID), para ser calificada como transaccin. PROPIEDADES DE TRANSACCIONES. Atomicidad Una transaccin debe ser una unidad atmica de trabajo, tanto si se realizan todas sus modificaciones en los datos, como si no se realiza ninguna de ellas. Coherencia Cuando finaliza, una transaccin 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 transaccin 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 transaccin. Aislamiento Las modificaciones realizadas por transacciones simultneas se deben aislar de las modificaciones llevadas a cabo por otras transacciones simultneas.
43
UCENM
Una transaccin reconoce los datos en el estado en que estaban antes de que otra transaccin simultnea los modificara o despus de que la segunda transaccin 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 inciales y reproducir una serie de transacciones para finalizar con los datos en el mismo estado en que estaban despus de realizar las transacciones originales. Durabilidad Una vez concluida una transaccin, sus efectos son permanentes en el sistema. Las modificaciones persisten an 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 lgica de los datos. El programador debe definir la secuencia de modificaciones de datos que los dejan en un estado coherente en relacin con las reglas de negocios de la organizacin. El programador incluye estas instrucciones de modificacin en una sola transaccin de forma que SQL Server Database Engine (Motor de base de datos de SQL Server) puede hacer cumplir la integridad fsica 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 fsica de cada transaccin. Motor de base de datos proporciona: Servicios de bloqueo que preservan el aislamiento de la transaccin. Servicios de registro que aseguran la durabilidad de la transaccin. 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 automticamente las transacciones incompletas al punto en que se produjo el error del sistema.
44
UCENM
Caractersticas de administracin de transacciones que exige n la atomicidad y coherencia de la transaccin. Una vez iniciada una transaccin, 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 transaccin.
Gestin de transacciones y administrador de la base de datos

Varias operaciones sobre la base de datos forman a menudo una nica unidad lgica 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 depsito tengan lugar o bien no ocurra ninguno. Este requisito de todo o nada se denomina atomicidad. Adems es esencial que la ejecucin 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 correccin se llama consistencia. Finalmente tras la ejecucin 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 transaccin es una coleccin de operaciones que se lleva a cabo como una nica funcin lgica en una aplicacin de bases de datos. Cada transacciones una unidad de atomicidad y consistencia. As se requiere que las transacciones no violen ninguna restriccin de consistencia de la base de datos. Es decir si la base de datos era consistente cuando la transaccin comenz, la base de datos debe ser consistente cuando la transaccin termine con xito
45
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
Definicin del esquema.- El DBA crea el esquema original de la base de datos escribiendo un conjunto de instrucciones de definicin de datos en el L DD. Definicin de la estructura y del mtodo de acceso. Modificacin del esquema y de la organizacin fsica.Los DBA realizan cambios en el esquema y en la organizacin fsica para reflejar las necesidades cambiantes de la organizacin, o para alterar la organizacin fsica para mejorar el rendimiento. Concesin de autorizacin para el acceso a los datos. - la concesin de diferentes tipos de autorizacin Permite al administrador de la base de datos determinar a qu partes de la base de datos puede acceder cada usuario. La informacin de autorizacin se mantiene en una estructura del sistema especial que el sistema de base de datos consulta Cuando se intenta de el acceso la a base los de datos del datos sistema. son:
Mantenimiento rutinario.- Algunos ejemplos de actividades rutinarias de mantenimiento Copia de seguridad peridica de la base de datos, para prevenir La prdida y de el datos espacio en en caso disco segn de sea desastres. necesario.
Asegurarse de que haya suficiente espacio libre en disco para las operaciones normales aumentar Supervisin de los trabajos que se ejecuten en la base de datos.
46
UCENM
DEFINICIN 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 dependan de la consistencia de la informacin almacenada. Las transacciones son mecanismos que ayudan a simplificar la construccin de sistemas confiables mediante procesos que proporcionan soporte uniforme para invocar y sincronizar operaciones como: Operaciones de comparacin de datos Aseguramiento de la seriabilidad de las transacciones con otras Atomicidad en su comportamiento Recuperacin de fallas La palabra transaccin describe una secuencia de operaciones con uno o ms recursos que transforman su estado actual en un nuevo estado de consistencia. Es un conjunto de operaciones sobre datos que son tratadas como una unidad. Una transaccin puede terminar, haciendo sus cambios persistentes, o abortar voluntaria o involuntariamente. Dentro del rea de los sistemas computacionales el concepto de transacciones fue inicialmente utilizado para definir la consistencia entre mltiples usuarios en una base de datos. Una transaccin es una coleccin de operaciones que hacen transformaciones consistentes de los estados de un sistema conservando la consistencia del sistema. Una base de datos est en estado consistente si cumple todas las restricciones de integridad definidas sobre ella. Los cambios de estado se dan debido a actualizacin, insercin y eliminacin de la informacin. Se quiere asegurar que la base de datos no entre en un estado de inconsistencia, pero durante la ejecucin de una transaccin, la base de datos puede estar temporalmente en un estado inconsistente. Lo importante aqu es asegurar que la base de datos vue lva a un estado consistente al concluir la ejecucin de una transaccin (Figura A)
47
UCENM
Figura A . Un modelo de transaccin. Lo que se persigue con el uso de transacciones es por un lado contar con una transparencia adecuada de las acciones concurrentes a una base de datos y por el otro tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos. Comentario sobre el modelo Una transaccin es una accin atmica, siendo una unidad de control de concurrencia y de recuperacin. Las transacciones se mantienen consistentes solo si se efecta 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 aplicacin culminar sus tareas a pesar de las fallas de componentes hardware o software Teora de Bases de Datos II 48 UCENM
INSTRUCCIONES PARA EL USO DE TRANSACIONES La programacin con uso de transacciones requiere de instrucciones especiales, las cuales deben ser proporcionadas por el sistema operativo, por el compilador del lenguaje o por el manejador de la base de datos, algunos son: BEGIN _TRANSACCIN: Los comandos siguientes forman una transaccin END _ TRANSACCIN: Termina la transaccin y se intenta un compromiso ABORT_ TRANSACCIN: Se elimina la transaccin, se recuperan los valores anteriores. READ: Se leen datos de un archivo WRITE: Se escriben datos en un archivo Las operaciones entre BEGIN y END forman el cuerpo de la transaccin y deben ejecutarse todas o ninguna de ellas. La cantidad exacta de instrucciones disponibles para manejar transacciones depende del tipo de objetos y operaciones que deban ser procesadas. TCNICAS DE IMPLANTACIN DE TRANSACCIONES > rea de trabajo privada > Bitcora de escritura anticipada > Protocolo de compromiso de dos fases (two-phase)
rea de trabajo privada: Consiste en realizar copias de los bloques que sern utilizados dentro de una transaccin de manera que se trabaje con estas copias para realizar todas las modificaciones necesarias. Todo el espacio de trabajo con la informacin que Teora de Bases de Datos II 49 UCENM
ser utilizada es contenido dentro de estas copias denominado rea de trabajo privada. Los dems usuarios trabajaran con la copia original de los bloques pero no podrn obtener una segunda copia de los mismos. Al iniciarse la transaccin 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 optimizacin para los datos que estn organizados en bloques apuntados desde un ndice, como los ficheros, es crear copias solo de los fragmentos modificados. Bitcora de escritura anticipada: Este mtodo 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 sern actualizadas con la informacin una vez que se ha determinado el fin de la transaccin. Se modifican los datos pero antes se escribe en un log sobre memoria estable la descripcin de la operacin. En el log tambin se escriben registros para indicar el inicio y fin de la transaccin, cuando se aborta la transaccin se recorre el log para deshacer los cambios. Despus de una cada tempor al, se debe recorrer el log. Si una transaccin no ha escrito su registro de fin se aborta, si lo ha escrito, se hacen los cambios pendientes. Para evitar recorrer todo el log despus de un fallo temporal de la maquina, se usan generalmente checkpoints. Protocolo de compromiso de dos fases: En un sistema distribuido una transaccin puede afectar a varios procesadores lo cual dificulta la atomicidad. La solucin ms tpica es el protocolo de compromiso de dos fases (C2F). En este protocolo existe un coordinador que normalmente es el proceso que inicio la transaccin.
50
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 transaccin. Cada proceso imp licado decide si est listo para hacer el compromiso, escribe en su log la decisin (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 transaccin. En caso contrario decide realizar el compromiso. El coordinador escribe en el log la decisin y manda un mensaje a los procesos implicados. Cada proceso que recibe el mensaje escribe en su log la decisin del coordinador y realiza la accin correspondiente. La terminacin de una transaccin se hace mediante la regla del compromiso global. El coordinador aborta una transaccin si y solo si al menos un proceso implicado decide abortar. El coordinador hace un compromiso de la transaccin si y solo si todos los participantes deciden realizar el compromiso. Comportamiento ante un fallo de un nodo: El nodo N se recupera despus de una cada transitoria y detecta que la transaccin T estaba a medias. Si el log contiene (compromiso T) se realiza la transaccin. Si contiene (abort T) se aborta la transaccin, si contiene (listo T) debe consultar al coordinador para determinar si se compromete o aborta la transaccin, si no hay mensajes en el log se aborta. Comportamiento ante fallos del coordinador: Cada nodo implicado N debe decidir sobre la transaccin T. Si el log contiene (compromiso T) se realiza la transaccin. Si contiene (abort T) se aborta, si no contiene (listoT) el coordinador no ha podido decidir el compromiso, por lo tanto, lo ms apropiado es abortar la transaccin.
51
UCENM
Si todos los nodos tienen (listo T) pero ninguno tiene (compromiso T) o (abort T) no se puede determinar la decisin del coordinador. Se debera esperar que se recuperase. ESTRUCTURA DE LAS TRANSACCIONES La estructura de una transaccin usualmente viene dada segn el modelo de la transaccin, estas pueden ser planas (simples) o anidadas. Transacciones planas: Consisten en una secuencia de operaciones primitivas encerradas entre las palabras clave BEGIN y END. Por ejemplo: BEGIN _TRANSACTION Reservacin .... END. Transacciones Anidadas: Consiste en tener transacciones que dependen de otras, estas transacciones estn incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transaccin de nivel superior puede producir hijos (subtransacciones) que hagan ms fcil la programacin del sistema y mejoras del desempeo.
En las transacciones anidadas las operaciones de una transaccin pueden ser as mismo otras transacciones. Por ejemplo: BEGIN _TRANSACTION Reservacin .......... BEGIN _TRANSACTION Vuelo ........ Teora de Bases de Datos II 52 UCENM
END.( Vuelo ) ...... BEGIN _TRANSACTION Hotel ........ END ...... END. Una transaccin 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 transaccin anidada: debe empezar despus 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 tambin sern abortadas. Las transacciones anidadas brindan un nivel ms alto de concurrencia entre transacciones. Ya que una transaccin consiste de varias transacciones es posible tener mayor concurrencia dentro de una sola transaccin. As tambin, es posible recuperarse de de fallas de forma independiente d e cada subtransaccion. Esto limita el dao a una parte ms pequea de la transaccin, haciendo que el costo de la recuperacin sea el menor. Tambin se deben considerar el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restriccin, entonces, a este tipo de transacciones se les conoce como Generales .Por el contrario, si se restringe o impone que un dato debe ser ledo antes de que pueda ser escrito entonces se tendrn transacciones Restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de Dos Pasos. Finalmente existe un modelo de accin para transacciones restringidas en donde se aplica aun ms la restriccin de que cada par < read, write > tiene que ser ejecutado de manera atmica.
53
UCENM
PROCESAMIENTO DE TRANSACCIONES Los siguientes son los aspectos ms importantes relacionados con el procesamiento de transacciones: Modelo de estructura de transacciones Es importante considerar si las transacciones son planas o anidadas. Consistencia de la base de datos interna Los algoritmos de control de datos tienen que satisfacer las restricciones de integridad cuando una transaccin pretende hacer un compromiso. Protocolos de confiabilidad En transacciones distribuidas es necesario introducir medios de comunicacin entre los diferentes nodos de una red para garantizar la atomicidad de las transacciones. Algoritmos de control de concurrencia Deben sincronizar la ejecucin de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas. Protocolos de control de replicas Se refiere a cmo garantizar la consistencia mutua de datos replicados. El procesamiento de transacciones bsicamente consiste en una serie de
modificaciones (transacciones) a un determinado recurso del sistema (por ejemplo una base de datos) y en donde se define un punto de inicio y un punto de terminacin que define un bloque entre el conjunto de operaciones que son realizadas.
54
UCENM
Dentro de este proceso en bloque los dems usuarios no pueden modificar nada hasta que no se presente un estado estable de los datos, esto ocasiona inconsistencia temporal y conflictos. Para evitar lo anterior se implementan dos maneras diferentes: Ejecucin..de..Transacciones..Serializadas Ejecucin de transacciones calendarizadas Ejecutar transacciones serializadas: Es un sistema que permite el procesamiento de transacciones en forma secuencial o serializado dndole una secuencia a cada transaccin, este proceso reduce el rendimiento del sistema, pero tiene como ventaja que el proceso de sincronizacin es ms sencillo. Ejecutar transacciones calendarizadas: Permite el proceso de transacciones asignndoles tiempos de procesamiento el cual permite incrementar el rendimiento del sistema ya que se ejecuta un mximo de procesos en forma concurrente y no a travs de una serie. La ventaja es que a un mismo tiempo de reloj se pueden hacer dos operaciones, aunque el proceso de sincronizacin es ms complicado. Un aspecto muy importante en el manejo de transacciones es el de mantener y aplicar algoritmos de control sobre los datos o recursos; para ese control tambin se utilizan protocolos que proporcionen confiabilidad como lo siguientes: Atomicidad Protocolos de recuperacin total Protocolos de compromiso global El control de las transacciones tambin 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 ejecucin concurrente de transacciones Consistencia intra transaccin (Aislamiento) Teora de Bases de Datos II 55 UCENM
Para llevar a cabo el control de concurrencia dentro de un proceso de transacciones se manejan dos modos: Ejecucin centralizada de transacciones (Figura B)
Figura C. Ejecucin distribuida de transacciones.
56
UCENM
CONDICIONES DE TERMINACION DE UNA TRANSACCION Una transaccin siempre termina, aun en la presencia de fallas. Si una transaccin termina de manera exitosa se dice que la transaccin hace un compromiso. Si la transaccin se detiene sin terminar su tarea, se dice que la transaccin aborta. Cuando la transaccin es abortada, puede ser por distintas razones relacionadas con la naturaleza de la transaccin misma, o por conflicto con otras transacciones o por fallo de un proceso o computador, entonces su ejecucin es detenida y todas las acciones ejecutadas hasta el momento son deshechas regresando a la base de datos al estado antes de su ejecucin. A esta operacin tambin 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 atmicas, a menudo llamadas transacciones. Cuando est disponible esta facilidad, un cliente puede indicarle al servidor que comience una transaccin, seguida por cualquier nmero de aperturas y operaciones de archivos, y finalizar con un comando para terminar la transaccin. El servidor debe ser capaz de llevar a cabo todos los pedidos efectuados de forma atmica (indivisible) sin interferencia de otros pedidos de clientes. Si el cliente decide abortar la transaccin o finalizan sus temporizadores, todos los archivos son restaurados al estado anterior al comienzo de la transaccin. Una transaccin es cualquier operacin de E/S sobre un archivo que modifica el contenido de un archivo existente del mismo. Esto incluye el agregar datos, cambiar el tamao y sobrescribir datos existentes. En una implementacin, junto al archivo de datos existe el denominado transaction log file que mantiene la descripcin de las modificaciones hechas sobre el archivo de datos y el mantenimiento de este archivo se llama transaction tracking.
57
UCENM
La operacin 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 diseo de un sistema de transacciones se tienen : Minimizar la sobrecarga de los sistemas de archivos, Identificar
automticamente las inconsistencias de datos. Una vez identificados debe producirse una operacin rollback sin la intervencin del usuario. Obviamente mientras se produce esta operacin, 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 informacin: Identificacin completa y univoca del archivo de datos. El modo y los permisos utilizados al abrir el archivo. La ubicacin de los datos modificados. Una copia de los datos originales. La descripcin de la alteracin que tuvo lugar. Los datos con que se llevo a cabo tal modificacin. Esta informacin convenientemente organizada, forma el ncleo de los denominados registros de transacciones, la unidad de datos de datos de los archivos log
58
UCENM
EJEMPLOS DE TIPOS DE TRANSACCIONES en SQL Server

INJ.HN Introduccin Una transaccin es un conjunto de operaciones que van a ser tratadas como una nica unidad. Estas transacciones deben cumplir 4 propiedades fundamentales comnmente conocidas como ACID (atomicidad, coherencia, asilamiento y durabilidad). La transaccin ms 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 transaccin. (Como siempre ejemplos de Northwind) Esta es una transaccin 'autocommit', una transaccin autocompletada. Cuando enviamos esta sentencia al SQL Server se escribe en el fichero de transacciones lo que va a ocurrir y a continuacin realiza los cambios necesarios en la base de datos. Si hay algn tipo de problema al hacer esta operacin 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 intervencin 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 explcita. Sentencias para una transaccin Como decamos una transaccin es un conjunto de operaciones tratadas como una sola. Este conjunto de operaciones debe marcarse como transaccin para que todas las operaciones que la conforman tengan xito o todas fracasen. La sentencia que se utiliza para indicar el comienzo de una transaccin es 'BEGIN TRAN'. Si alguna de las operaciones de una transaccin falla hay que deshacer la transaccin 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 Teora de Bases de Datos II 59 UCENM
'ROLLBACK TRAN'. Si todas las operaciones de una transaccin se completan con xito hay que marcar el fin de una transaccin 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 transaccin 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 cdigo de error BEGIN TRAN Iniciamos la transaccin UPDATE Products SET UnitPrice=20 WHERE ProductName ='Chai' Ejecutamos la primera sentencia SET @Error=@@ERROR Si ocurre un error almacenamos su cdigo en @Error y saltamos al trozo de cdigo que deshar la transaccin. 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 transaccin en la base de datos COMMIT TRAN Teora de Bases de Datos II 60 UCENM
TratarError: Si ha ocurrido algn error llegamos hasta aqu If @@Error<>0 THEN BEGIN PRINT 'Ha ecorrido un error. Abortamos la transaccin' Se lo comunicamos al usuario y deshacemos la transaccin 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 cdigo que deshace la transaccin. Hay una interpretacin incorrecta en cuanto al funcionamiento de las transacciones que est bastante extendida. Mucha gente cree que si tenemos varias sentencias dentro de una transaccin y una de ellas falla, la transaccin se aborta en su totalidad. Ahora tenemos dos sentencias dentro de una transaccin. 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 ejecutarn como una sola. Si por ejemplo en medio de la transaccin (despus del primer update y antes del segundo) hay un corte de electricidad, cuando el SQL Server se recupere se encontrar en medio de una transaccin y, o bien la termina o bien la deshace, pero no se quedar a medias.
61
UCENM
El error est en pensar que si la ejecucin de la primera sentencia da un error se cancelar la transaccin. El SQL Server slo se preocupa de ejecutar las sentencias, no de averiguar s i lo hacen correctamente o si la lgica de la transaccin es correcta. Eso es cosa nuestra. Por eso en el ejemplo que tenemos ms arriba para cada sentencia de nuestro conjunto averiguamos si se ha producido un error y si es as actuamos en consecuencia cancelando toda la operacin. 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 transaccin sin haber terminado la anterior. Asociada a esta idea de anidamiento existe una variable global
@@TRANCOUNT que tiene valor 0 si no existe ningn nivel de anidamiento, 1 si hay una transaccin 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 transaccin anidada esta sentencia deshace todas las transacciones internas hasta la instruccin BEGIN TRANSACTION ms externa. COMMIT TRAN: Dentro de una transaccin anidada esta sentencia nicamente reduce en 1 el valor de @@TRANCOUNT, pero no "finaliza" ninguna transaccin ni "guarda" los cambios. En el caso en el que @@TRANCOUNT=1 (cuando estamos en la ltima transaccin) COMMIT TRAN hace que todas las modificaciones efectuadas sobre los datos desde el inicio de la transaccin sean parte permanente de la base
62
UCENM
de datos, libera los recursos mantenidos por la conexin y reduce @@TRANCOUNT a 0. Como siempre un ejemplo es lo mejor para entender cmo 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 transaccin 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 transaccin anidada con ROLLBACK TRAN BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1 Teora de Bases de Datos II 63 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 transaccin 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 transaccin ms externa y adems hace @@TRANCOUNT=0 Supone este funcionamiento asimtrico 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 ms lejos hay una cuarta sentencia para trabajar con transacciones: SAVE TRAN
Save Tran
Esta sentencia crea un punto de almacenamiento dentro de una tr ansaccin. Esta marca sirve para deshacer una transaccin en curso slo hasta ese punto. Por supuesto nuestra transaccin 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) Teora de Bases de Datos II 64 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 transaccin se lleva a cabo o se deshace completamente Para deshacerla un ROLLBACK bastar como hemos visto Pero para guardar la transaccin 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 transaccin 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 transaccin ms 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 fciles de manejar.
Un par de ejemplos ms
65
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 transaccin 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 transaccin. 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
66
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 transaccin 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 transaccin en curso, pero si hay una transaccin externa al procedimiento en el que estamos trabajando se cancelar esa transaccin externa.
67
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 artculo. Veamos cmo se comporta una transaccin en un procedimiento almacenado llamado desde una transaccin. 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 sera: EXECUTE inserta1 SELECT * FROM tabla1 txt -------------------------------------------------Valor1 Valor3 (2 filas afectadas) Pero lo que obtenemos es:
68
UCENM
EXECUTE inserta1 SELECT * FROM tabla1 (1 filas afectadas) (1 filas afectadas) Servidor: mensaje 266, nivel 16, estado 2, procedimiento Inserta2, lnea 8 El recuento de transacciones despus de EXECUTE Indica TRANSACTION. Recuento anterior = 1, recuento actual = 0. (1 filas afectadas) Servidor: mensaje 3902, nivel 16, estado 1, procedimiento Inserta1, lnea 8 La peticin 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 transaccin exterior, la del primer procedimiento almacenado. A continuacin 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 transaccin pendiente. Al volver al procedimiento almacenado externo se ejecuta el INSERT que inserta la tercera fila y a continuacin el 'COMMIT TRAN --Uno'. Aqu aparece otro error puesto que este 'COMMIT TRAN -Uno' estaba ah para finalizar una transaccin que ya ha sido cancelada anteriormente. que falta una instruccin COMMIT o ROLLBACK
69
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 transaccin slo hasta el punto guardado. Adems 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 Teora de Bases de Datos II 70 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-. Cul es el conjunto de acciones deben constituir una transaccin?
3-. Enumere cuales son las propiedades de la transacciones.
4-.Que es la gestin y administracin de base de datos?
71
UCENM
5-. Cules son las instrucciones para el uso de transacciones?
6-. Elabore un explicacin de las TCNICAS DE IMPLANTACIN DE TRANSACCIONES.
7-.Que es un protoloco de compromiso de dos fases?
8-.Que tipo de estructura existen indquelas?
9-.Que entiende por transacciones en sistemas de archivos distribuidos?
10-.Que son las Transacciones y procedimientos almacenados?
72
UCENM
CONCURRENCIA
Objetivos del captulo III
1. 2. 1. 2. 3.
Comprender y analizar el concepto de concurrencia. Conocer los conceptos de los principales algoritmos. Conocer la concurrencia en sistema archivo. Comprender el concepto de abrazos mortales. Comprender ejemplos de concurrencia.
73
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 estn en espera, ninguno de ellos podr ocasionar nunca ninguno de los eventos que podra desbloquear a algunos de los otros miembros del conjunto y los dems procesos seguirn 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 ms simple de lograr este objetivo es ejecutar cada transaccin sola, una despus de otra. Sin embargo esto puede afectar enormemente el desempeo de un sistema de manejo de bases de datos distribuidas dado que el nivel de concurrencia se reduce al mnimo. El nivel de concurrencia, el nmero de transacciones activas, es probablemente el parmetro ms 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 diseo de mecanismos apropiados de sincronizacin y en obligar su uso por cada proceso que utiliza recursos comunes, produce frecuentemente un comportamiento errneo del sistema y rupturas que son notablemente difciles de depurar. La concurrencia puede producir un incremento de la productividad cuando se implementan correctamente, pero puede tambin degradar la fiabilidad cuando Teora de Bases de Datos II 74 UCENM
la sincronizacin impropia entre procesos contamina el sistema con errores artificios de tiempo.Si no se lleva a cabo un adecuado control de concurrencia, se podran llegar a presentar dos anomalas. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo lugar, pueden presentarse recuperaciones de informacin 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 hbridos. Los algoritmos optimistas se componen por los algoritmos basados en candados y algoritmos basados en estampas de tiempo. (Figura D)
Figura D. Clasificacin de los algoritmos de control de concurrencia.
75
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, tambin llamados compartidos, o de escritura, tambin 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 operacin sobre la base de datos (lectura o escritura) e informacin asociada, como por ejemplo el elemento de datos que es accesado y el identificador de la transaccin que est enviando la operacin 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 transaccin solicitante es retrasada. De otra forma, el candado se define sobre el dato en el modo deseado y la operacin a la base de datos es transferida al procesador de datos. El administrador de transacciones es informado luego sobre el resultado de la operacin. La terminacin de una transaccin libera todos los candados y se puede iniciar otra transaccin 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 transaccin se establecen los cerrojos y en la fase de decrecimiento se liberan los cerrojos. Hay que tener en cuenta que se pueden producir interbloqueos.
76
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 transaccin le pone un candado a un objeto antes de usarlo. Cuando un objeto es bloqueado con un candado por otra transaccin, la transaccin solicitante debe esperar. Cuando una transaccin libera un candado, ya no puede solicitar ms candados. 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 transaccin aborta despus de liberar un candado, otras transacciones que hayan accesado el mismo elemento de datos aborten tambin 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 transaccin termina (con compromiso o aborta). Candados de dos fases centralizados: En sistemas distribuidos puede que la administracin de los candados se dedique a un solo nodo del sistema, por lo tanto, se tiene un despachador central el cual recibe todas las solicitudes de candados del sistema. La comunicacin se presenta entre el administrador de transacciones del nodo en donde se origina la transaccin, 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 operacin se va a llevar a cabo.
77
UCENM
Figura E. Comunicacin en un administrador centralizado de candados de dos fases. La crtica ms 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 transaccin 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 envan 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 envan su mensaje de "fin de operacin" al administrador de transacciones coordinador Teora de Bases de Datos II 78 UCENM
Figura F. Comunicacin 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 transaccin conflictiva que accesa el mismo dato. As, la ejecucin de cualquier operacin de una transaccin sigue la secuencia de fases: validacin, lectura, cmputo y escritura (ver Figura G, sigte pag). Los algoritmos optimistas, por otra parte, retrasan la fase de validacin justo antes de la fase de escritura (ver Figura G, sigte pag). De esta manera, una operacin sometida a un despachador optimista nunca es retrasada.
79
UCENM
Las operaciones de lectura, cmputo y escritura
de cada transaccin se
procesan libremente sin actualizar la base de datos corriente. Cada transaccin inicialmente hace sus cambios en copias locales de los datos. La fase de validacin consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra manera, la transaccin 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 transaccin. Cada transaccin tiene tres fases:. Fase de lectura: Cuerpo de la transaccin donde se copian datos desde la base de datos, copias que pueden ser actualizadas pero sin copiar a la base de datos Fase de validacin: 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 estn en conflicto entre s cuando, operan sobre los mismos datos, una de las operaciones es de escritura, o cada operacin pertene ce a diferentes transacciones.
Figura G. Fases de la ejecucin de una transaccin a) pesimista, b) optimista
80
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 exclusin mutua. En su lugar eligen un orden de socializacin en primera instancia y ejecutan las transacciones de acuerdo a ese orden. En estos algoritmos cada transaccin 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 transaccin que hizo la ltima operacin de ese tipo sobre el dato. Para leer la marca de tiempo de escritura del dato, debe ser menor que el de la transaccin, si no aborta. Para escribir las marcas de tiempo de escritura y lectura del dato, deben ser menores que el de la transaccin, sino se aborta. Esta tcnica est libre de Interbloqueos pero puede darse que halla que repetir varias veces la transaccin. 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 mltiples clientes de los que encargarse. Si dos o ms clientes, accidentalmente o no, deciden acceder al mismo archivo al mismo tiempo pueden producirse conflictos. La solucin utilizada es permitir a los usuarios el uso de bloqueos sobre los archivos de trabajo.
81
UCENM
La idea es sencilla, mientras un usuario est trabajando sobre una parte de los datos, otros no podrn hacerlo de manera que las distintas act ualizaciones 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 consideracin importante. Es posible bloquear archivos enteros, pero tambin es posible bloquear archivos enteros o subrboles, cuanto menor sea la unidad lgica 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 comn cuando se efectan transferencias de dinero en aplicaciones bancarias, hay una posibilidad de abrazo mortal. Abrazos mortales: Principalmente, existen dos mtodos para manejar el problema de los abrazos mortales. Podemos usar algn 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 despus recuperarnos. El recuperarse de un abrazo mortal puede ser muy difcil y muy caro. Por ello, primeramente consideraremos los mtodos para asegurar que no ocurran los abrazos mortales. Comnmente, existen dos mtodos: El de PREVENCIN de abrazos mortales LA EVASIN de abrazos mortales.
82
UCENM
PREVENCIN de abrazos mortales. Un conjunto de procesos est en un abrazo mortal cuando todos los procesos en ese conjunto estn esperando un evento que slo puede ser causado por otro proceso en el conjunto. Los eventos a los cuales nos estamos refiriendo son
concernientes con la asignacin y liberacin 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 tambin 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.
83
UCENM
Es obvio que un abrazo mortal es una condicin indeseable. En un abrazo mortal, los procesos nunca terminan de ejecutarse y los recursos del sistema estn amarrados, evitando que otros procesos puedan siquiera empe zar. Condiciones Necesarias. Una situacin de abrazo mortal puede surgir s y solo s las siguientes cuatro condiciones ocurren simultneamente en un sistema: Exclusin 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, slo 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 estn 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 explcitamente por el proceso que los contiene. Los recursos no pueden ser desasignados ; esto es, un recurso slo puede ser liberado voluntariamente por el proceso que lo retiene, despus de que el proceso ha terminado su tarea. Espera Circular. Debe haber una cadena de dos o ms 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.
84
UCENM
Se remarca que las cuatro condiciones deben de cumplirse para que pueda ocurrir un abrazo mortal. La condicin 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 condicin por separado. Una forma de modelar estas condiciones es usando un grafo de recursos: Los crculos 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 esperndolo. Entonces, si hacemos el grafo con todos los procesos y todos los recursos del sistema y encontramos un ciclo, los procesos en el ciclo estn bajo bloqueo mutuo.
Ejemplo de un grafo de recursos.
85
UCENM
La discusin del control de concurrencia hasta aqu se ha centralizado alrededor del problema de qu hacer cuando mltiples 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 informacin en el archivo, un cliente puede crear una nueva versin del archivo que reemplaza (pero no modifica) el original. De esta manera, un archivo se vuelve una secuencia de versiones inmutables. La sincronizacin entre procesos es necesaria para prevenir y corregir errores de sincronizacin debidos al acceso concurrente de recursos compartidos, tales como estructuras de datos o dispositivos de E/S, de procesos contendientes. La sincronizacin entre procesos tambin permite intercambiar seales de tiempo entre procesos cooperantes para garantizar las relaciones especficas de precedencia impuestas por el problema que se resuelva. Sin una sincronizacin adecuada entre procesos, la actualizacin entre variables compartidas puede inducir a errores de tiempo relacionadas con la concurrencia que son con frecuencia difciles 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 semforos son un mecanismo sencillo pero poderoso de sincronizacin entre procesos. Los semforos satisfacen la mayora 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.
86
UCENM
Mediante el uso de semforos se pueden resolver algunos problemas bien conocidos de sincronizacin, como los de PRODUCTOR/CONSUMIDOR y LECTORES/ESCRITORES. Sincronizacin entre procesos La ejecucin concurrente de procesos, puede producir mejoras significativas de rendimiento respecto a la ejecucin secuencial de programas. Cuando es crtico el rendimiento, se puede dividir el trabajo en varios procesos cooperantes definidos por el programador para explotar la posible concurrencia de un programa o aplicacin 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 sincronizacin entre procesos es necesaria para preservar la integridad del sistema y prevenir problemas de tiempo producidos por el acceso concurrente a recursos compartidos por mltiples 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 fsicos comunes. El fallo en diseo de protocolos apropiados de sincronizacin y en obligar su uso por cada proceso que utiliza recursos comunes, produce frecuentemente un comportamiento errneo del sistema y rupturas que son notablemente difciles de depurar. La concurrencia puede producir un incremento de la productividad cuando se implementan correctamente, pero puede tambin degradar la fiabilidad cuando la sincronizacin impropia entre procesos contamina el sistema con errores artificios de tiempo.
87
UCENM
Introduccin 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 situacin 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 estn actualizando. La actualizacin 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 infraccin de concurrencia.
"El ltimo gana": Una fila no est disponible para otros usuarios mientras los datos se estn 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.
88
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 tambin en situaciones en las que no es conveniente que cambie el registro durante una transaccin. Un buen ejemplo sera una aplicacin de inventario. Consideremos que el representante de una compaa va a comprobar el inventario para un posible cliente. Lo normal sera bloquear el registro hasta que se generase un pedido, lo que, en lneas generales, identificara el artculo con el estado de pedido y lo quitara del inventario dispon ible. Si no se generase ningn pedido, el bloqueo se liberara 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 slo el tiempo suficiente para leer los datos o actualizarlos, por lo que los bloqueos no se pueden mantener durante perodos de tiempo prolongados. Adems, una aplicacin que mantiene los bloqueos durante perodos de tiempo prolongados no es escalable. Nota Si el origen de datos subyacente admite las transacciones, puede simular la concurrencia pesimista mediante la actualizacin de los datos dentro de una transaccin. Para obtener ms informacin, vea Caractersticas que
proporciona System.Transactions.
89
UCENM
Concurrencia optimista En la concurrencia optimista, los bloqueos se establecen y mantienen slo 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 estn siempre disponibles, excepto durante el momento preciso en que est teniendo lugar una actualizacin. Para obtener ms informacin, vea Utilizar concurrencia optimista. Cuando se intenta realizar una actualizacin, se compara la versin original de una fila modificada con la fila existente en la base de datos. Si las dos son diferentes, la actualizacin no se realiza debido a un error de concurrencia. En ese instante, es de su responsabilidad la reconciliacin de las dos filas mediante su propia lgica de empresa. El ltimo gana Con la tcnica de "el ltimo gana", no se realiza ninguna comprobacin de los datos originales y la actualizacin 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. Asegrese de que esta situacin 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. Teora de Bases de Datos II 90 UCENM
Por ello, es necesario agregar lgica de empresa para resolver los problemas de la concurrencia optimista. Si decide utilizar la concurrencia optimista, existen dos mtodos generales para determinar si se han producido cambios: el planteamiento del nmero de versin (nmeros de versin reales o marcas de fecha y hora) y el planteamiento de guardar todos los valores. Planteamiento del nmero de versin En el planteamiento del nmero de versin, el registro que se va a actualizar debe tener una columna que contenga una marca de fecha y hora o un nmero de versin. La marca de fecha y hora o el nmero de versin se guardan en el cliente cuando se lee el registro. Despus, se hace que el valor forme parte de la actualizacin. Una forma de controlar la concurrencia es actualizar slo si el valor de la clusula WHERE coincide con el valor del registro. La representacin SQL de este planteamiento es: Copier
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2 WHERE DateTimeStamp = @origDateTimeStamp Alternativamente, se puede realizar la comparacin con el nmero de versin: Copiar UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2 WHERE RowVersion = @origRowVersionValue
Si las marcas de fecha y hora o los nmeros de versin coinciden, el registro del almacn 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 cdigo para implementar esta forma de comprobar la concurrencia en Visual Studio. Teora de Bases de Datos II 91 UCENM
Tambin deber escribir cdigo para responder a los posibles conflictos de actualizacin. Para mantener la exactitud de la marca de fecha y hora o el nmero de versin, 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 nmero de versin 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 versin original (la que se ley originalmente del origen de datos) y una versin 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 coleccin de parmetros. Cada comando tiene parmetros para los valores originales y para los valores actuales (o modificados). Nota Cuando se agregan registros nuevos (comando INSERT), slo se requieren los valores actuales, ya que no existe ningn registro original; cuando se quitan registros (comando DELETE), slo se requieren los valores originales para poder localizar el registro que se desea eliminar.
92
UCENM
En el ejemplo siguiente se muestra el texto de un comando del conjunto de datos que actualiza una tabla Customers tpica. El comando se especifica para SQL dinmico 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)
93
UCENM
Tenga en cuenta que los nueve parmetros de la instruccin SET representan los valores actuales que se escribirn en la base de datos, mientras que los nueve parmetros de la instruccin WHERE representan los valores originales que se utilizan para encontrar el registro original. Los nueve primeros parmetros de la instruccin SET se corresponden con los nueve primeros parmetros de la coleccin de parmetros. Estos parmetros tendran su propiedad SourceVersion establecida en Current. Los nueve parmetros siguientes de la instruccin WHERE se utilizan para la concurrencia optimista. Estos marcadores de posicin se corresponderan con los nueve parmetros siguientes de la coleccin de parmetros, y cada uno de estos parmetros tendra la propiedad SourceVersion establecida en Original. La instruccin SELECT se utiliza para actualizar el conjunto de datos despus de que se haya producido la actualizacin. Se genera cuando se establece la opcin Actualizar el conjunto de datos del cuadro de dilogo Opciones de generacin SQL avanzadas. Nota En la instruccin SQL anterior se utilizan parmetros con nombre, mientras que los comandos OleDbDataAdapter usan signos de interrogacin (?) como marcadores de posicin de los parmetros.
De
manera
predeterminada,
Visual
Studio
crea
estos
parmetros
automticamente si selecciona la opcin Concurrencia optimista en el Asistente para la configuracin del adaptador de datos. Debe decidir si desea agregar cdigo para controlar los errores basndose en las necesidades de su empresa. ADO.NET proporciona un objeto DBConcurrencyException que devuelve la fila que infringe las reglas de concurrencia. Para obtener ms informacin, vea Cmo: Controlar errores de concurrencia.
94
UCENM
CONTROL DE CONCURRENCIA EN BASES DE DATOS El control de transacciones concurrentes en una base de datos brinda un eficiente desempeo del Sistema de Base de Datos, puesto que permite controlar la ejecucin de transacciones que operan en paralelo, accesando a informacin compartida y, por lo tanto, interfiriendo potencialmente unas con otras. El hecho de reservar un asiento en una avin mediante un sistema basado en aplicaciones web, cuando decenas de personas en el mundo pueden reservarlo tambin, 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 podra ocurrir que se paguen dos cheques en forma simultnea 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 atmicamente, como si no existieran otras aplicaciones ejecutndose concurrentemente. Esta abstraccin de una ejecucin atmica y confiable de una aplicacin se conoce como una transaccin. Un algoritmo de control de concurrencia asegura que las transacciones se ejecuten atmicamente controlando la intercalacin de transacciones concurrentes, para dar la ilusin de que las transacciones se ejecutan seriamente, una despus de la otra, sin ninguna intercalacin.
95
UCENM
Las ejecuciones intercaladas cuyos efectos son los mismos que las ejecuciones seriales son denominadas serializadles y son correctos ya que soportan la ilusin de la atomicidad de las transacciones. El concepto principal es el de transaccin. Informalmente, una transaccin es la ejecucin de ciertas instrucciones que accesan a una base de datos compartida. El objetivo del control de concurrencia y recuperacin es asegurar que dichas transacciones se ejecuten atmicamente, es decir: Cada transaccin accede a informacin compartida sin interferir con otras transacciones, y si una transaccin 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 informacin. Por supuesto, se quiere asegurar que la base de datos nunca entre en un estado de inconsistencia. Sin embargo, durante la ejecucin de una transaccin, 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 ejecucin de una transaccin.
96
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 debera hacer un rollback y Volver X al valor anterior- y entonces luego T2 debera tambin abortar y hacer Un rollback, porque ley un valor sucio que le dej T1, pero si lo hacemos Estaramos violando la semntica del commit y esto trae confusin. Llegamos a una situacin en el que estado consistente anterior de la BD es Irrecuperable. Para evitar esta situacin deberamos 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 Todava podemos recuperar el estado consistente anterior abortando T2. Pero sin embargo esto nos puede llevar a la situacin no deseada de aborts
En cascada.
Para evitar esta situacin deberamos demorar cada Read(X) hasta que los Correspondientes Ti que previamente hicieron un Write(X,val) hayan hecho Abort o commit.
97
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?
98
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 explicacin de lo que comprendi en los ejemplo 1 y 2 de concurrencia de la pag 98.
99
UCENM
Nodo w
DBMw
BDw
Nodo x Programa de consulta o transaccin Nodo y Programa de consulta o transaccin Nodo z Programa de consulta o transaccin DDB Interfaz de accin DDBMS DTMx DBMx BDx
DTMy
DBMy
BDy
DTMz
Interfaz de solicitud
BASES DE DATOS DISTRIBUIDAS

Objetivos del captulo IV
1. Comprender y analizar el concepto Bases de Datos Distribuidas. 2. Conocer la administracin de DDBMS. 3. Conocer el Diseo de DDBMS. 4. Comprender los tipos de Base Datos Distribuidas.
100
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 travs de diversos medios de comunicacin, tales como cables de alta velocidad o lneas telefnicas.
No comparten la memoria principal ni el reloj. Los procesadores de un sistema distribuido pueden variar en cuanto su tamao y funcin. Pueden incluir microcomputadores pequeos, estaciones de trabajo y sistemas de computadores grandes de aplicacin 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 ejecucin 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.
101
UCENM
Transacciones y Administradores de una DDBMS

El sistema de administracin 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 genrico que implica un conjunto de programas que operan en diversas computadoras. Estos programas pueden ser subsistemas de un producto nico DDBMS, concesionado por un slo fabricante, o tambin pudiera resultar una coleccin de programas de fuentes dispares: algunos concesionados por fabricantes, y algunos otros escritos en casa. El pro psito 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 solicitudes 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 funcin importante del DTM es coordinar y controlar dichas acciones. Dependiendo de la naturaleza de la aplicacin del DDBMS, el DTM puede ser proporcionado como parte de DDBMS o puede desarrollarse en casa por la organizacin que pone en prctica el sistema distribuido. En aplicaciones menos complejas, una parte de sus funciones puede ser llevada a cabo por personas, siguiendo slo procedimientos manuales.
Administrador de la base de datos (DBM):

Es un programa que procesa cierta porcin de la base de datos distribuida, como es el hecho de recuperar y actualizar datos del usuario y generales, de acuerdo con comandos de accin recibidos de los DTM. El DBM puede ser un subconjunto de un producto DDBMS, o ser tambin un DBMS comercial no distribuido.
102
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 transaccin 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 transaccin como de base de datos con DTMx' DBMx y BDx. De modo similar, el Nodo Y es tanto un nodo de transaccin como de base de datos, pero el Nodo Z es solamente un nodo de transaccin. Los programas de consulta o de transaccin se comunican con los DTM a travs de solicitudes parecidas a las solicitudes de accin del DBMS. Ejemplos son SELECT EMPLOYEE WHERE E# EQ 123 o bien STORE DUE-DATE. Estas solicitudes operan sobre estructuras lgicas. El programa de consulta o de aplicacin no se refiere a ninguna instancia fsica en particular de la estructura. Los DTM se comunican con los DBM por medio de acciones a ejecutarse en ocurrencias especficas 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 informacin. En principio, las solicitudes y las acciones pueden tambin diferir en trminos de su nivel de abstraccin. Por ejemplo, se puede expresar una solicitud en trminos de un objeto y puede ser traducida en acciones o expresada en trminos 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 utilizacin, de forma que el tiempo de comunicacin sea ms corto. Varias computadoras operando en forma simultnea pueden entregar ms volumen de procesamiento que una sola computadora.
103
UCENM
Figura 2 Un negocio distribuido geogrficamente
Planta A Almacn
Planta B Planta C
Segundo, los datos duplicados aumentan su confiabilidad. Cuando falla una computadora, se pueden obtener los datos extrados 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 tamao de un modo ms sencillo. Se pueden agregar computadoras adicionales a la red conforme aumentan el nmero de usuario s y su carga de procesamiento. A menudo es ms fcil y ms barato agregar una nueva computadora ms pequea que actualizar una computadora nica y centralizada. Despus, si la carga de trabajo se reduce, el tamao de la red tambin puede reducirse. Por ltimo, los sistemas distribuidos se pueden adecuar de una manera ms sencilla a las estructuras de la organizacin de los usuarios. La Figura 2 muestra la organizacin de un fabricante distribuido geogrficamente.
104
UCENM
Los gerentes generales de cada una de las plantas poseen una enorme autoridad y libertad en la operacin de sus instalaciones. Si tales plantas dependieran de una computadora nica centralizada, la arquitectura de sistema entrara en conflicto con la filosofa y las polticas operacionales de la empresa. Incluso en organizaciones ms 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 mltiples, ya que stos pueden ser abrumados por las tareas de coordinacin y de control req ueridas. Tal situacin es probable cuando la carga de trabajo necesita un gran nmero 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.
105
UCENM
Figura 3 Ventajas y desventajas del procesamiento de una base de datos distribuida
VENTAJAS
Mayor rendimiento Mayor confiabilidad Cambia de tamao con facilidad Adecuado fcilmente a la estructura de la organizacin
DESVENTAJAS
Peor rendimiento Menor confiabilidad Mayor complejidad Costos ms altos Difcil de controlar
Una tercera desventaja es su mayor complejidad, a menudo se traduce en altos gastos de construccin y mantenimiento. Ya que existen ms componentes de hardware, hay ms cantidad de cosas por aprender y ms interfaces susceptibles de fallar. El control de concurrencia y recuperacin de fallas puede convertirse en algo complicado y difcil de implementar, puede empujar a u na mayor carga sobre programadores y personal de operaciones y quiz se requiera de personal ms experimentado y ms costoso. El procesamiento de bases de datos distribuido es difcil 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 fsico no est controlado, y los procedimientos operativos son demasiado suaves y efectuados por personas que tienen escasa apreciacin o comprensin sobre su importancia. En sistemas centralizados, en caso de un desastre o catstrofe, la recuperacin puede ser ms difcil de sincronizar.
106
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 comunicacin entre ellas. Las localidades pueden conectarse fsicamente de diversas formas, las principales son:

Red totalmente conectada Red prcticamente conectada Red con estructura de rbol Red de estrella Red de anillo
Las diferencias principales entre estas configuraciones son:
Costo de instalacin: El coste de conectar fsicamente las localidades del sistema Cost0 de comunicacin: 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 lnea de comunicacin o una localidad. Disponibilidad: La posibilidad de acceder a informacin a pesar de fallos en algunas localidades o lneas de comunicacin.
Las localidades pueden estar dispersas, ya sea por un rea geogrfica extensa (a lo largo de un pas), llamadas redes de larga distancia; o en un rea reducida (en un mismo edificio), llamadas redes de rea local.
107
UCENM
Para las primeras se utilizan en la comunicacin lneas telefnicas, conexiones de microondas y canales de satlites; 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 informacin, fiabilidad y disponibilidad y agilizar el procesamiento de las consultas. Pero tambin tiene sus desventajas, como desarrollos de software ms costosos, mayor posibilidad de errores y costos extras de procesamiento. Ventajas de la distribucin de datos La principal ventaja de los sistemas distribuidos es la capacidad de compartir y acceder a la informacin de una forma fiable y eficaz. Utilizacin compartida de los datos y distribucin del control La ventaja principal de compartir los datos por medio de la distribucin es que cada localidad pueda controlar hasta cierto punto los datos almacenados localmente. En un sistema centralizado, el administrador de base de datos de la localidad central controla la base de datos. En un sistema distribuido existe un administrador global de la base de datos que se encarga de todo el sistema. Parte de esta responsabilidad se delega al administrador de base de datos de cada localidad. Dependiendo del diseo del sistema distribuido, cada administrador local podr tener un grado de autonoma diferente, que se conoce como autonoma local. La posibilidad de contar con autonoma local es en mu chos casos una ventaja importante de las bases de datos distribuidas.
108
UCENM
Fiabilidad y disponibilidad Si se produce un fallo en una localidad de un sistema distribuido, es posible que las dems localidades puedan seguir trabajando. En particular, si los dato s se repiten en varias localidades, una transaccin que requiere un dato especfico puede encontrarlo en ms de una localidad. As, el fallo de una localidad no implica necesariamente la desactivacin del sistema. El sistema debe detectar cuando falla una localidad y tomar las medidas necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que fall. Por ltimo, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mnimo de complicaciones. La disponibilidad es fundamental para los sistemas de bases de datos que se utilizan en aplicaciones de tiempo real. Por ejemplo, si una lnea area no puede tener acceso a la informacin, es posible que pierda clientes a favor de la competencia. Agilizacin del procesamiento de consultas Si una consulta comprende datos de varias localidades, puede ser posible dividir la consulta en varias subconsultas que se ejecuten en paralelo en distintas localidades. Sin embargo, en un sistema distribuido no se comparte la memoria principal, as que no todas las estrategias de interseccin se pueden aplicar en estos sistemas. En los casos en que hay repeticin de los datos, el sistema puede pasar la consulta a las localidades ms ligeras de carga.
109
UCENM
Desventajas de la distribucin de los datos La desventaja principal de los sistemas distribuidos es la mayor complejidad que se requiere para garantizar una coordinacin adecuada entre localidades. El aumento de la complejidad se refleja en:
Coste del desarrollo de software: es ms difcil estructura un sistema de bases de datos distribuidos y por tanto su coste es menor Mayor posibilidad de errores: puesto que las localidades del sistema distribuido operan en paralelo, es ms difcil garantizar que los algoritmos sean correctos. Mayor tiempo extra de procesamiento: el intercambio de mensajes y los clculos adicionales son una forma de tiempo extra que no existe en los sistemas centralizados.
Transparencia y Autonoma En la seccin anterior se vio que una relacin r puede almacenarse de varias formas en un sistema de base de datos distribuida. Es esencial que el sistema reduzca al mnimo la necesidad de que el usuario se d cuenta de cmo est almacenada una relacin. Como veremos. Un sistema puede ocultar los detalles de la distribucin de la informacin en la red. Esto se denomina transparencia de la red. La transparencia de la red se relaciona, en algn modo, a la autonoma local. La transparencia de la red es el grado hasta el cual los usuarios del sistema pueden ignorar los detalles del diseo distribuido. La autonoma local es el grado hasta el cual el diseador o administrador de una localidad pueden ser independientes del resto del sistema distribuido.
110
UCENM
Los temas de transparencia y autonoma sern considerados desde los siguientes puntos de vista:

Nombre de los datos. Repeticin de los datos. Fragmentacin de los datos. Localizacin de los fragmentos y copias.
Asignacin de nombres y autonoma local Todo elemento de informacin de una base de dat os debe tener un nombre nico. Esta propiedad se asegura fcilmente 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 solucin 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 autonoma local, ya que la asignacin de nombres se controla de forma centralizada.
Un enfoque diferente que origina una mayor autonoma local es exigir que cada localidad ponga como prefijo un identificador de localidad a cualquier nombre que genere. Esto garantiza que dos localidades nunca generarn el mismo nombre (ya que cada localidad tiene un identificador nico). Adems , no se requiere un control central.
111
UCENM
Esta solucin al problema de asignacin de nombres, logra autonoma local, pero no transparencia de la red, ya que se agregan identificadores de localidad a los nombres. As, la relacin depsito podra llamarse localidad17.depsito en vez de depsito simplemente. Cada copia y fragmento de un elemento de informacin deben tener un nombre nico. Es importante que el sistema pueda determinar qu copias son copias del mismo elemento de informacin y qu fragmentos son f ragmentos del mismo elemento de informacin. Transparencia de la repeticin y la fragmentacin No es conveniente requerir que los usuarios hagan referencia a una copia especfica de un elemento de informacin. 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 peticin de escritura. Cuando se solicita un dato, no es necesario especificar la copia. El sistema utiliza una tabla-catlogo para determinar cules son todas las copias de ese dato. De manera similar, no debe exigirse a los usuarios que sepan cmo est fragmentado un elemento de informacin. Es posible que los fragmentos verticales contengan id-duplas, que representan direcciones de duplas. Los fragmentos horizontales pueden haberse obtenido por predicados de seleccin complejos. Por tanto, un sistema de bases de datos distribuido debe permitir las consultas que se hagan en trminos de elementos de informacin sin fragmentar. Esto no presenta problemas graves, ya que siempre es posible reconstruir el elemento de informacin original a partir de sus fragmentos. Sin embargo, este proceso puede ser ineficiente.
112
UCENM
Transparencia de localizacin Si el sistema es transparente en cuanto a repeticin y fragmentacin, 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 localizacin se logra creando un conjunto de seudnimos o alias para cada usuario. As, el usuario puede referirse a los datos usando nombres sencillos que el sistema traduce a nombres completos. Con el uso de seudnimos, no ser necesario que el usuari o conozca la localizacin fsica de un dato. Adems, el administrador de la base de datos puede cambiar un dato de una localidad a otra sin afectar a los usuarios. Esquema completo de asignacin de nombres Ya vimos que un nombre proporcionado por el usuario debe pasar por varios pasos de traduccin antes de que pueda servir como referencia a una copia especfica de un fragmento determinado en una localidad especfica. Para ilustrar cmo funciona el esquema, consideramos un usuario que se encuentra en la sucursal 1 (L1). Este usuario emplea el seudnimo depsito-local para el fragmento local depsito-F1 de la relacin deposito. Cuando este usuario hace referencia a depsito-local, el subsistema de procesamiento de consultas busca depsito local en la tabla de seudnimos y la sustituye por Ll.depsito.F1. Es posible que L1.depsito.Fl est repetido. Si es as, debe consultarse la tabla de copias para elegir una copia. Esta copia podra tambin estar fragmentada, lo que hara necesario consultar la tabla de fragmentacin. En la mayor parte de los casos, slo es preciso consultar una o dos tablas.
113
UCENM
Transparencia y actualizaciones De alguna forma es ms difcil hacer transparente la base de datos para usuarios que la actualizan que para aquellos que slo leen datos. El problema principal es asegurarse de que se actualizan todas las copias de un dato y tambin los fragmentos afectados. En el caso ms general, el problema de actualizacin de informacin repetida y fragmentada est relacionado con el problema de actualizacin de vistas. Diseo de la distribucin: Introduccin El diseo de un sistema de base de datos distribuido implica la toma de decisiones sobre la ubicacin de los programas que accedern 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 ubicacin de los programas, a priori, no debera suponer un excesivo problema dado que se puede tener una copia de ellos en cada mquina de la red (de hecho, en este documento se asumir que as es). Sin embargo, cul es la mejor opcin para colocar los datos: en una gran mquina que albergue a todos ellos, encargada de responder a todas las peticiones del resto de las estaciones - sistema de base de datos centralizado -, o podramos pensar en repartir las relaciones, las tablas, por toda la red. En el supuesto que nos decantsemos por esta segunda opcin, qu criterios se deberan seguir para llevar a cabo tal distribucin? Realmente este enfoque ofrecer un mayor rendimiento que el caso centralizado? Podra optarse por alguna otra alternativa?
114
UCENM
Tradicionalmente se ha clasificado la organizacin de los sistemas de bases de datos distribuidos sobre tres dimensiones: el nivel de comparticin, las caractersticas de acceso a los datos y el nivel de conocimiento de esas caractersticas de acceso. El nivel de comparticin presenta tres alternativas: inexistencia, es decir, cada aplicacin y sus datos se ejecutan en un ordenador con ausencia total de comunicacin con otros programas u otros datos; se comparten slo los datos y no los programas, en tal caso existe una rplica de las aplicaciones en cada mquina 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 distribucin. Servicio a otro programa localizado en un segundo lugar, el cual podr acceder a los datos situados en un tercer emplazamiento. Como se coment lneas atrs, en este caso se optar por el punto intermedio de comparticin. Respecto a las caractersticas de acceso a los datos existen dos alternativas principalmente: el modo de acceso a los datos que solicitan los usuarios puede ser esttico, es decir, no cambiar a lo largo del tiempo, o bien, dinmico. El lector podr comprender fcilmente la dificultad de encontrar sistemas distribuidos reales que puedan clasificarse como estticos. Sin embargo, lo realmente importante radica, estableciendo el dinamismo como base, cmo de dinmico es, cuntas variaciones sufre a lo largo del tiempo. Esta dimensin establece la relacin entre el diseo de bases de datos distribuidas y el procesamiento de consultas. La tercera clasificacin es el nivel de conocimiento de las caractersticas de acceso. Una posibilidad es, evidentemente, que los diseadores carezcan de informacin alguna sobre cmo los usuarios acceden a la base de datos.
115
UCENM
Es una posibilidad terica, pero sera muy laborioso abordar el diseo de la base de datos con tal ausencia de informacin. Lo ms prctico sera conocer con detenimiento la forma de acceso de los usuarios o, en el caso de su imposibilidad, conformarnos con una informacin parcial de sta. El problema del diseo de bases de datos distribuidas podra enfocarse a travs de esta trama de opciones. En todos los casos, excepto aquel en el que no existe comparticin, aparecern una serie de nuevos problemas que son irrelevantes en el caso centralizado. A la hora de abordar el diseo 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 resultara extrao a la hora de abordar un trabajo real de diseo de una base de datos que se pudiesen emplear en diferentes etapas del proyecto una u otra estrategia. La estrategia ascendente podra aplicarse en aquel caso donde haya que proceder a un diseo a partir de un nmero de pequeas bases de datos existentes, con el fin de integrarlas en una sola. En este caso se partira de los esquemas conceptuales locales y se trabajara 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, debera resultar familiar a la persona que posea conocimientos sobre el diseo de bases de datos, exceptuando la fase del diseo de la distribucin. Pese a todo, se resumirn brevemente las etapas por las que se transcurre.
116
UCENM
Estrategia descendente. Todo comienza con un anlisis de los requisitos que definirn 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 debern 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 econmico. Como puede observarse, los resultados de este ltimo paso sirven de entrada para dos actividades que se realizan de forma paralela. El diseo de las vistas trata de definir las interfaces para el usuario final y, por otro lado, el diseo conceptual se encarga de examinar la empresa para determinar los tipos de entidades y establecer la relacin entre ellas. Existe un vnculo entre el diseo de las vistas y el diseo conceptual. El diseo conceptual puede interpretarse como la integracin de las vistas del usuario, este aspecto es de vital importancia ya que el modelo conceptual debera soportar no slo las aplicaciones existentes, sino que debera estar preparado para futuras aplicaciones. En el diseo conceptual y de las vistas del usuario se especificar n las entidades de datos y se determinarn las aplicaciones que funcionarn sobre la base de datos, as mismo, se recopilarn datos estadsticos o estimaciones sobre la actividad de estas aplicaciones. Dichas estimaciones deberan girar en torno a la frecuencia de acceso, por parte de una aplicacin, a las distintas relaciones de las que hace uso, podra afinarse ms anotando los atributos de la relacin a la que accede. Desarrollado el trabajo hasta aqu, se puede abordar la confeccin del esquema conceptual global. Este esquema y la informacin relativa al acceso a los datos sirven de entrada al paso distintivo: el diseo de la distribucin.
117
UCENM
El objetivo de esta etapa consiste en disear los esquemas conceptuales locales que se distribuirn a lo largo de todos los puestos del sistema distribuido. Sera posible tratar cada entidad como una unidad de distribucin; en el caso del modelo relacional, cada entidad se corresponde con una relacin. Resulta bastante frecuente dividir cada relacin en subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ah, que el proceso del diseo de la distribucin conste de dos actividades fundamentales: la fragmentacin y la asignacin. El ltimo paso del diseo de la distribucin es el diseo fsico, el cual proyecta los esquemas conceptuales locales sobre los dispositivos de almacenamiento fsico disponibles en los distintos sitios. Las entradas para este paso son los esquemas conceptuales locales y la informacin de acceso a los fragmentos. Por ltimo, se sabe que la actividad de desarrollo y diseo es un tipo de proceso que necesita de una monitorizacin y un ajuste peridicos, para que si se llegan a producir desviaciones, se pueda retornar a alguna de las fases anteriores.
Diseo
Existen diversas formas de afrontar el problema del diseo de la distribucin. En el primer caso, caso A, los dos procesos fundamentales, la fragmentacin y la asignacin, se abordan de forma simultnea. Esta metodologa se encuentra en desuso, sustituida por el enfoque en dos fases, caso B: la realizacin primeramente de la particin para luego asignar los fragmentos generados. El resto de los casos se comentan en la seccin referente a los distintos tipos de la fragmentacin.
118
UCENM
Enfoques para realizar el diseo distributivo. Antes de exponer las alternativas existentes de fragmentacin, se desean presentar las ventajas e inconvenientes de esta tcnica. Se ha comentado en la introduccin la conveniencia de descomponer las relaciones de la base de datos en pequeos 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 descomposicin, esa fragmentacin. El principal problema de la fragmentacin radica en encontrar la unidad apropiada de distribucin. Una relacin no es una buena unidad por muchas razones. Primero, las vistas de la aplicacin normalmente son subconjuntos de relaciones. Adems, la localidad de los accesos de las aplicaciones no est definida sobre relaciones enteras pero s sobre subconjuntos de las mismas. Por ello, sera normal considerar como unidad de distribucin a estos subconjuntos de relaciones. Segundo, si las aplicaciones tienen vistas definidas sobre una determinada relacin (considerndola ahora una unidad de distribucin) que reside en varios sitios de la red, se puede optar por dos alternativas. Por un lado, la relacin no estar replicada y se almacena en un nico sitio, o existe rplica en todos o algunos de los sitios en los cuales reside la aplicacin. Las consecuencias de esta estrategia son la generacin de un volumen de accesos remotos innecesario. Adems, se pueden realizar rplicas innecesarias que causen problemas en la ejecucin de las actualizaciones y puede no ser deseable si el espacio de almacenamiento est limitado. Tercero, la descomposicin de una relacin en fragmentos, tratados cada uno de ellos como una unidad de distribucin, permite el proceso concurrente de las transacciones. Teora de Bases de Datos II 119 UCENM
Tambin la relacin de estas relaciones, normalmente, provocar la ejecucin paralela de una consulta al dividirla en una serie de subconsultas que operar sobre los fragmentos. Pero la fragmentacin tambin acarrea inconvenientes. Si las aplicaciones tienen requisitos tales que prevengan la descomposicin de la relacin en fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas estn definidas sobre ms de un fragmento pueden sufrir una degradacin en el rendimiento. Por tanto, puede ser necesario recuperar los datos de dos fragmentos y llevar a cabo sobre ellos operacin de unin y yunto , lo cual es costoso. Un segundo problema se refiere al control semntico. Como resultado de la fragmentacin 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 bsqueda de los datos implicados en un gran nmero de sitios. Tipos de fragmentacin: Dado que una relacin se corresponde esencialmente con una tabla y la cuestin consiste en dividirla en fragmentos menores, inmediatamente surgen dos alternativas lgicas para llevar a cabo el proceso: La divisin horizontal y la divisin vertical. La divisin o fragmentacin horizontal trabaja sobre las duplas, dividiendo la relacin en subrelaciones que contienen un subconjunto de las duplas que alberga la primera. La fragmentacin vertical, en cambio, se basa en los atributos de la relacin para efectuar la divisin.
120
UCENM
Estos dos tipos de particin podran considerarse los fundamentales y bsicos. Sin embargo, existen otras alternativas. Fundamentalmente, se habla de fragmentacin mixta o hbrida cuando el proceso de particin hace uso de los dos tipos anteriores. La fragmentacin mixta puede llevarse a cabo de tres formas diferentes: desarrollando primero la fragmentacin vertical y, posteriormente, aplicando la particin horizontal sobre los fragmentos verticales (denominada particin VH), o aplicando primero una divisin horizontal para luego, sobre los fragmentos generados, desarrollar una fragmentacin vertical (llamada particin HV), o bien, de forma directa considerando la semntica de las transacciones. Otro enfoque distinto y relativamente nuevo, consiste en aplicar sobre una relacin, de forma simultnea y no secuencial, la fragmentacin horizontal y la fragmentacin 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 (ntese que en este caso el grado de fragmentacin alcanzado es mximo, y no por ello la descomposicin resultar ms eficiente). Puede observarse como los casos C y D se basan en la mencionada generacin de la rejilla, con la diferencia que en el primero de ellos se produce una fusin, una desfragmentacin de las celdas, agrupndolas de la manera ms adecuada para obtener mayor rendimiento, ya que los fragmentos generados son muy pequeos. En el segundo caso se asignan las celdas a los sitios y luego se realiza una rigurosa optimizacin de cada sitio. El caso E sera aquel en el que se utiliza la fragmentacin VH o la fragmentacin HV.
121
UCENM
Enfoques para realizar el diseo distributivo. Grado de fragmentacin. Cuando se va a fragmentar una base de datos deberamos pesar qu grado de fragmentacin va a alcanzar, ya que ste ser un factor que influir notablemente en el desarrollo de la ejecucin de las consultas. El grado de fragmentacin puede variar desde una ausencia de la divisin, considerando a las relaciones unidades de fragmentacin; o bien, fragmentar a un grado en el cada Dupla o atributo forme un fragmento. Ante estos dos casos extremos, evidentemente se ha de buscar un compromiso intermedio, el cual debera establecerse sobre las caractersticas de las aplicaciones que hacen uso de la base de datos. Dichas caractersticas se podrn formalizar en una serie de parmetros. De acuerdo con sus valores, se podr establecer el grado de fragmentacin del banco de datos. Distintos tipos de fragmentacin. Grado de Fragmentacin Cuando se va a fragmentar una base de datos deberamos sopesar qu grado de fragmentacin va a alcanzar, ya que ste ser un factor que influir notablemente en el desarrollo de la ejecucin de las consultas. El grado de fragmentacin puede variar desde una ausencia de la divisin, considerando a las relaciones unidades de fragmentacin; o bien, fragmentar a un grado en el cada Dupla o atributo forme un fragmento. Ante estos dos casos extremos, evidentemente se ha de buscar un compromiso intermedio, el cual debera establecerse sobre las caractersticas de las aplicaciones que hacen uso de la base de datos.
122
UCENM
Dichas caractersticas se podrn formalizar en una serie de parmetros. De acuerdo con sus valores, se podr establecer el grado de fragmentacin del banco de datos. Reglas de correccin de la fragmentacin A continuacin se enuncian las tres reglas que se han de cumplir durante el proceso de fragmentacin, las cuales asegurarn la ausencia de cambios semnticos en la base de datos durante el proceso. Complecin: Si una relacin R se descompone en una serie de fragmentos R1, R2, ..., Rn, cada elemento de datos que pueda encontrarse en R deber poder encontrarse en uno o varios fragmentos Ri. Esta propiedad extremadamente importante asegura que los datos de la relacin global se proyectan sobre los fragmentos sin prdida alguna. 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. Reconstruccin: Si una relacin R se descompone en una serie de fragmentos R1, R2, ..., Rn, puede definirse una operador relacional tal que el operador ser diferente dependiendo de las diferentes formas de fragmentacin. La reconstruccin de la relacin a partir de sus fragmentos asegura la preservacin de las restricciones definidas sobre los datos en forma de dependencias. Disyuncin. : Si una relacin R se descompone horizontalmente en una serie de fragmentos R1, R2, ..., Rn, y un elemento de datos di se encuentra en algn fragmento Rj, entonces no se encuentra en otro fragmento Rk (k j). Esta regla asegura que los fragmentos horizontales sean disjuntos. Teora de Bases de Datos II 123 UCENM
Si una relacin R se descompone verticalmente, sus atributos primarios clave normalmente se repiten en todos sus fragmentos. Alternativas de asignacin 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 rplica 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 podra acceder a esos datos ubicados en sitios distintos. Adems, las consultas que acceden a los mismos datos pueden ejecutarse en paralelo, ya que habr copias en diferentes sitios. Por otra parte, la ejecucin de consultas de actualizacin, de escritura, implicara la actualizacin de todas las copias que existan en la red, cuyo proceso puede resultar problemtico y complicado. Por tanto, un buen parmetro para afrontar el grado de rplica consistira en sopesar la cantidad de consultas de lectura que se efectuarn, as como el nmero de consultas de escritura que se llevarn a cabo. En una red donde las consultas que se procesen sean mayoritariamente de lectura, se podra alcanzar un alto grado de rplica, no as en el caso contrario. Una base de datos fragmentada es aquella donde no existe rplica 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 rplica, podemos considerar una base de dat os 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.
124
UCENM
El nmero de copias de un fragmento ser una de las posibles entradas a los algoritmos de asignacin, o una variable de decisin cuyo valor lo determine el algoritmo. La figura de ejemplo, compara las tres alternativas de rplica con respecto a distintas funciones de un sistema de base de datos distribuido. Rplica parcial dificultad
Rplica total Procesamiento consultas Gestin del directorio Control de concurrencia Seguridad \Realidad de
Particin
fcil
similar similar fcil baja posible aplicacin
fcil o inexistente dificultad moderado muy alta difcil alta
posible aplicacin realista
Informacin necesaria Un aspecto importante en el diseo de la distribucin es la cantidad de factores que contribuyen a un diseo ptimo. La organizacin lgica de la base de datos, la localizacin de las aplicaciones, las caractersticas de acceso de las aplicaciones a la base de datos y las caractersticas del sistema en cada sitio, tienen una decisiva influencia sobre la distribucin. La informacin necesaria para el diseo de la distribucin pu ede dividirse en cuatro categoras: la informacin del banco de datos, la informacin de la aplicacin, la informacin sobre la red de ordenadores y la informacin sobre los ordenadores en s. Las dos ltimas son de carcter cuantitativo y servirn, principalmente, para desarrollar el proceso de asignacin. Se entrar en detalle sobre la informacin empleada cuando se aborden los distintos algoritmos de fragmentacin y asignacin.
125
UCENM
Fragmentacin Horizontal: Como se ha explicada anteriormente, la fragmenta cin horizontal se realiza sobre las duplas de la relacin. Cada fragmento ser un subconjunto de las duplas de la relacin. Existen dos variantes de la fragmentacin horizontal: la primaria y la derivada. La fragmentacin horizontal primaria de una relacin se desarrolla empleando los predicados definidos en esa relacin. Por el contrario, la fragmentacin horizontal derivada consiste en dividir una relacin partiendo de los predicados definidos sobre alguna otra. Informacin necesaria para la fragmentacin horizontal Informacin sobre la base de datos. Esta informacin implica al esquema conceptual global. Es importante sealar cmo las relaciones de la base de datos se conectan con otras. En una conexin de relaciones normalmente se denomina relacin propietaria a aquella situada en la cola del enlace, mientras que se llama relacin miembro a la ubicada en la cabecera del vnculo. 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 proyectarn un conjunto de enlaces sobre un conjunto de relaciones. Adems, dado un enlace, devolvern el miembro y el propietario de la relacin, respectivamente. La informacin cuantitativa necesaria gira en torn o a la cardinalidad de cada relacin, notada como card(R).
126
UCENM
Informacin sobre la aplicacin. Necesitaremos tanto informacin cualitativa como cuantitativa. La informacin cualitativa guiar la fragmentacin, mientras que la cuantitativa se necesitar en los modelos de asignacin. La principal informacin de carcter 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 deberan investigar las ms importantes. Podemos pensar en la regla "80/20" para guiarnos en nuestro anlisis, esta regla dice que el 20% de las consultas existentes acceden al 80% de los datos. Llegados a este punto, sera interesante determinar los predicados simples. A parte de los predicados simples, las consultas emplean predicados ms complejos resultado de combinaciones lgicas de los simples. Una combinacin especialmente interesante es la conjuncin de predicados simples, al predicado resultante se le denomina predicado mintrmino. Partiendo de que siempre es posible transformar una expresin lgica en su forma normal conjuntiva, usaremos los predicados mintrmino en los algoritmos para no causar ninguna prdida de generalidad. Sobre la informacin cuantitativa necesaria relativa a las aplicaciones, necesitaremos definir dos conjuntos de datos. Selectividad mintrmino: Es el nmero de duplas de una relacin a las que accede una consulta de acuerdo a un predicado mintrmino 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 mintrmino mi como sel(mi).
127
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. Fragmentacin horizontal primaria Antes de presentar un algoritmo formal que lleve a cabo la fragmentacin horizontal, intentaremos explicar de manera intuitiva los procesos de fragmentacin horizontal primaria y derivada. La fragmentacin horizontal primaria se define como una operacin de seleccin de las relaciones propietarias del esquema de la base de datos Ahora definiremos la fragmentacin horizontal ms formalmente. Un fragmento horizontal Ri de una relacin R contiene todas las duplas de R que satisfacen un predicado mintrmino m. Por tanto, dado un conjunto de predicados mintrmino M, existen tantos fragmentos horizontales de la relacin R como predicados mintrmino. Este conjunto de fragmentos horizontales tambin se conocen como conjuntos de fragmentos mintrmino. En los prrafos siguientes se asumir que la definicin de fragmentos horizontales se basa en los predicados mintrmino. Adems, el primer paso para el algoritmo de fragmentacin consiste en establecer un conjunto de predicados con ciertas propiedades. Un aspecto importante de los predicados simples es su complecin, as como su minimalidad. Un conjunto de predicados simples Pr se dice que es completo si y solo si existe una probabilidad idntica de acceder por cada aplicacin a cualquier par de duplas pertenecientes a cualquier fragmento mintrmino que se define de acuerdo con Pr. Se puede apreciar como la definicin de complecin de un conjunto de predicados simples difiere de la regla de complecin de la fragmentacin.
128
UCENM
El segundo paso en el proceso de fragmentacin p rimaria consiste en derivar el conjunto de predicados mintrmino que pueden definirse sobre los predicados del conjunto Pr'. Estos predicados mintrmino establecen los fragmentos candidatos para el proceso de asignacin. El establecimiento de los predicados mintrmino es trivial: La dificultad radica en el tamao del conjunto de predicados mintrmino, que puede ser muy grande (de hecho, exponencial respecto al nmero de predicados simples). En el paso siguiente se presentarn formas de reducir el nmero de predicados mintrmino necesarios para la fragmentacin. El tercer paso aborda, como ya se ha citado, la eliminacin de algunos fragmentos mintrmino que puedan ser redundantes. Esta eliminacin se desarrolla identificando aquellos mintrminos que puedan resultar contradictorios sobre un conjunto de implicaciones. Fragmentacin horizontal derivada Una fragmentacin horizontal derivada se define sobre una relacin miembro de acuerdo a una operacin de seleccin 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 travs de semiyuntos. Este segundo punto es especialmente importante para nuestros propsitos, ya que deseamos fraccionar una relacin miembro segn la fragmentacin de su propietaria, adems es necesario que el fragmento resultante se defina nicamente sobre los atributos de la relacin miembro.
129
UCENM
Las tres entradas necesarias para desarrollar la fragmentacin horizontal derivada son las siguientes: El conjunto de particiones de la relacin propietaria, la relacin miembro y el conjunto se predicados resultados de aplicar el semi-yunto entre la propietaria y la miembro. El algoritmo de fragmentacin resulta tan trivial que no se ve la necesidad de entrar en detalles. Existe una posible complicacin que necesita nuestro estudio. En un esquema de base de datos, resulta frecuente que existan ms de dos enlaces sobre una relacin R. En este caso, aparecen ms de una posibilidad de fragmentacin horizontal derivada. La decisin para elegir una u otra se basa en dos criterios: Uno, la fragmentacin con mejores caractersticas de yunto. Dos, la fragmentacin empleada en ms aplicaciones. Discutamos el segundo criterio primero. Resulta sencillo de establecer si tomamos en consideracin la frecuencia con la que cada aplicacin accede a los datos. Si es posible, deberamos 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 fragmentacin expuesta en el ejemplo 8. El objetivo de esta fragmentacin consiste en beneficiar a la consulta que haga uso de las dos relaciones al Teora de Bases de Datos II 130 UCENM
poder realizarse el yunto de CLIENTES y PROVINC sobre relaciones ms pequeas (es decir, fragmentos), y posibilitar la confeccin de yuntos de manera distribuida. El primer aspecto resulta obvio. Los fragmentos de CLIENTES son ms pequeos que la propia relacin CLIENTES. Por tanto, resultar ms rpido 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 ms importante ya que es la esencia de las bases de datos distribuidas. Si, adems de estar ejecutando un nmero 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 diseo donde la relacin de yunto entre los fragmentos es simple, radica en la asignacin 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 obtencin d e grafos de yunto simples no siempre es posible. En tal caso, la mejor alternativa sera realizar un diseo que provoque un grafo de yuntos fragmentados. Un grafo fragmentado consiste en dos o ms subgrafos que no estn enlazados entre ellos. Por tanto, l os fragmentos que se obtengan no se distribuirn para ejecuciones paralelas de un modo tan fcil como aquellos obtenidos a travs de grafos simples, pero su asignacin an ser posible.
131
UCENM
Procederemos ahora a probar la correccin de los algoritmos presentados con respecto a los tres criterios enunciados: Complecin: La complecin de una fragmentacin horizontal primaria se basa en la seleccin de los predicados a usar. En la medida que los predicados seleccionados sean completos, se garantizar que el resultado de la fragmentacin tambin lo ser.
Partiendo de la base que el algoritmo de fragmentacin es un conjunto de predicados completos y mnimos Pr', se garantiza la complecin siempre que no aparezcan errores al realizar la definicin de Pr'. La complecin de una fragmentacin horizontal derivada es algo ms difcil de definir. La dificultad viene dada por el hecho de que los predicados que intervienen en la fragmentacin forman parte de dos relaciones. Definamos la regla de complecin formalmente. Sea R la relacin miembro de un enlace cuya propietaria es la relacin S, la cual est fragmentada como FS = {S1, S2, ..., Sw}. Adems, 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]. Reconstruccin: La reconstruccin de una relacin global a partir de sus fragmentos se desarrolla con el operador de unin tanto para la fragmentacin horizontal primaria como para la derivada. Disyuncin: Resulta sencillo establecer la disyuncin de la fragmentacin tanto para la primaria como para la derivada. En el primer caso, la disyuncin se garantiza en la medida en que los predicados mintrmino que determinan la Teora de Bases de Datos II 132 UCENM
fragmentacin son mutuamente exclusivos. En la fragmentacin derivada, s in embargo, implica un semi-yunto que aade complejidad al asunto. La disyuncin 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 relacin miembro con dos o ms duplas de una relacin propietaria cuando estas duplas se encuentran en fragmentos diferentes a los de la propietaria. Esto no es fcil de establecer, e ilustra por qu los esquemas de la fragmentacin derivada que generan un grafo de yunto simple son siempre ms atractivos. Fragmentacin Vertical: Recurdese que la fragmentacin vertical de una relacin 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 fragmentacin vertical consiste en dividir la relacin en un conjunto de relaciones ms pequeas tal que algunas de las aplicaciones de usuario slo hagan uso de un fragmento. Sobre este marco, una fragmentacin ptima es aquella que produce un esquema de divisin que minimiza el tiempo de ejecucin de las aplicaciones que emplean esos fragmentos. La particin vertical resulta ms complicada que la horizontal. Esto se debe al aumento del nmero total de alternativas que tenemos disponibles. Por ejemplo, en la particin horizontal, si el nmero total de predicados simples de Pr es n, existen 2n predicados mintrminos posibles que puedan definirse. Adems, sabemos que algunos de estos predicados resultarn contradictorios con algunas de las aplicaciones existentes, por lo que podremos reducir el nmero inicial.
133
UCENM
En el caso vertical, si una relacin tiene m atributos clave no primarios, el nmero de posibles fragmentos es igual a B(m), es decir el m-simo nmero 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 obtencin de una solucin ptima de la fragmentacin vertical resultar una tarea intil, sino nos apoyamos en el uso de heursticos. Existen dos enfoques heursticos para la fragmentacin vertical de relaciones: Agrupacin: Comienza asignando cada atributo a un fragmento, y en cada paso, junta algunos de los fragmentos hasta que satisface un determinado criterio. La agrupacin sugiri en principio para bases de datos centralizadas y se us posteriormente para las bases de datos distribuidas. Escisin: A partir de la relacin se deciden que fragmentos resultan mejores, basndose en las caractersticas de acceso de las aplicaciones a los atributos. Esta tcnica se present, tambin, para bases de datos centralizadas. Posteriormente, se extendi al entorno distribuido. En este documento se tratar nicamente la tcnica de escisin, ya que es ms apropiada para la estrategia descendente y porque resulta ms probable encontrar la solucin para la relacin entera que a partir de un conjunto de fragmentos con un nico atributo. Adems, la escisin genera fragmentos no solapados mientras que la agrupacin 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. Teora de Bases de Datos II 134 UCENM
Antes de comenzar, vamos a aclarar un problema: la rplica de las claves de la relacin en los fragmentos. Esta es una caracterstica de la fragmentacin vertical que permite la reconstruccin de la relacin global. Por tanto, la escisin considera nicamente aquellos atributos que no son parte de la clave primaria. La rplica 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 semntica. Tenga en cuenta que cada dependencia (funcional, multivaluada ...) es, de hecho, una restriccin que influye sobre el valor de los atributos de las respectivas relaciones en todo momento. Tambin muchas de estas dependencias implican a los atributos clave de una relacin. Si queremos disear 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 peticin de actualizacin provocar la verificacin de integridad que necesitar de una comunicacin entre esos sitios. La rplica de los atributos clave de cada fragmento reduce esta problemti ca, pero no elimina toda su complejidad, ya que la comunicacin 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 rplica de los atributos clave es el empleo de identificadores de duplas, que son valores nicos asignados por el sistema a las duplas de una relacin. Mientras el sistema mantenga los identificadores, los fragmentos permanecern disjuntos.
135
UCENM
Informacin necesaria para la fragmentacin vertical La principal informacin que necesitaremos se referir a las aplicaciones. Por tanto, este punto tratar de especificar la informacin que de una aplicacin que funciona sobre la base de datos podamos extraer. Teniendo en cuenta que la fragmentacin vertical coloca en un fragmento aquellos atributos a los que se accede de manera simultnea, necesitaremos alguna medida que defina con ms precisin el concepto de simultaneidad. Esta medida es la afinidad de los atributos, que indica la relacin estrecha existente entre los atributos. Desgraciadamente, no es muy realista esperar que el diseador o los usuarios puedan especificar estos valores. Por ello, presentaremos una forma por la cual obtengamos esos valores partiendo de datos ms bsicos. 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 relacin R(A1, A2, ..., An). Los vectores uso (qi,) pueden definirse muy fcilmente para cada aplicacin siempre que el diseador conozca las aplicaciones existentes en el sistema. La regla 80/20 expuesta pginas atrs podra 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 escisin y la fragmentacin de los atributos, ya que estos valores no representan el peso de las frecuencias de la aplicacin. La dimensin de esta frecuencia puede incluirse en la definicin de la m edida de los atributos afines afd(Ai, Aj), la cual mide el lmite entre dos atributos de una relacin de acuerdo a cmo las aplicaciones acceden a ellos.
136
UCENM
Fragmentacin mixta o hbrida: En muchos casos la fragmentacin vertical u horizontal del esquema d e 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 fragmentacin mixta. Cuando al proceso de fragmentacin vertical le sigue una horizontal, es decir, se fragmentan horizontalmente los fragmentos verticales resultantes, se habla de la fragmentacin mixta HV. En el caso contrario, estaremos ante una fragmentacin VH. Una caracterstica comn a ambas es la generacin d e rboles que representan la estructura de fragmentacin. Considere, por ejemplo, la relacin PROVINC. Recordar que se le aplic una fragmentacin horizontal de acuerdo al valor del atributo CCODZONA resultando cuatro fragmentos horizontales. Podramos pensar en aplicarle una nueva fragmentacin de carcter vertical. Entonces resultaran cuatro fragmentos horizontales divididos, por ejemplo, en dos fragmentos verticales. En este caso el nmero total de fragmentos ascendera, lgicamente, a ocho. Estructura arbrea de fragmentacin mixta. No se desea entrar en excesivos detalles sobre las reglas y condiciones para efectuar la fragmentacin mixta. Entre otras razones porque, tanto a la fragmentacin HV como la fragmentacin VH, se le pueden aplicar los mismos criterios y reglas que a la fragmentacin horizontal y vertical. Es decir, volviendo al ejemplo anterior, al cual le practicamos la fragmentacin HV, al realizar la fragmentacin horizontal tal como se ha expuesto, lo que se obtienen no son ms que subrelaciones, la unin de las cuales da lugar a la relacin PROVINC. Por tanto, para fragmentar cada subrelacin sera perfectamente viable aplicarle el mtodo de fragmentacin vertical que se ha desarrollado. Como, en este caso, se han querido generar dos fragmentos verticales por cada uno horizontal, simplemente deberamos confeccionar la
137
UCENM
matriz de grupos afines (a travs del algoritmo BEA) para cada fragmento horizontal y aplicarle, posteriormente, el algoritmo de fragmentacin binaria PARTICIN. Tambin debe tenerse en cuenta el nmero de niveles arbreos que se generen, es decir, nadie impide que tras realizar una fragmentacin VH, podamos aplicar a los fragmentos resultantes una nueva fragmentacin vertical, y a estos ltima una nueva fragmentacin horizontal, etc. Dicho nmero puede ser grande, pero tambin ser ciertamente finito.
En el caso horizontal, el nivel mximo 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 a tributo. Sin embargo, aunque no deba tomarse como dogma, el nmero de niveles no debera superar el par (VH y HV). El porqu de esta afirmacin es bien sencillo, piense, por ejemplo, en el coste que supondra realizar la unin o el yunto de una relacin con fragmentacin nivel 7. Evidentemente, el coste sera muy elevado y ese aumento de rendimiento que se persigue al aplicar estas tcnicas, quizs, no se produzca. Antes de pasar a estudiar el problema de la asignacin se desea comentar la tcnica de fragmentacin mixta basada en celdas [2]. Esta tcnica se basa en la generacin de celdas de rejilla. Qu es una celda de rejilla, podramos definirla como un fragmento horizontal y vertical simultneo. La tcnica aplica un algoritmo de fragmentacin vertical y otro horizontal de manera concurrente sobre la relacin. Los algoritmos realizan una fragmentacin mxima, es decir, se persigue que en cada celda nicamente haya un atributo y una dupla. Quiz el lector pueda encontrar el mtodo contradictorio con lo citado anteriormente respecto a la eficiencia, dada la gran cantidad de fragmentos generados, el nmero es, Teora de Bases de Datos II 138 UCENM
efectivamente, el mximo. Sin embargo, este slo es el primer paso del proceso. Una vez generadas las celdas se aplica un mtodo para optimizar la rejilla mediante fusin o desfragmentacin, de acuerdo, fundamentalmente, a las aplicaciones que acten sobre esos fragmentos. El mtodo, por tanto, persigue una fragmentacin la ms especfica posible acorde con las aplicaciones y los sitios existentes en la red.
Informacin necesaria En esta etapa de la asignacin, necesitaremos datos cuantitativos sobre la base de datos, las aplicaciones que funcionan sobre ella, la red de comunicaciones, las caractersticas de proceso, y el lmite de almacenamiento de cada sitio de la red. Procederemos a discutirlos en detalle. Informacin de la base de datos. Para desarrollar la fragmentacin horizontal, definimos la selectividad de los mintrminos. Ahora, necesitamos extender esta definicin a los fragmentos y definir la selectividad de un fragmento Fj con respecto a una consulta qi. Es el nmero 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 tamao. El tamao de un fragmento Fj viene dado por tamao (Fj) = card(Fj)*long(Fj), donde long(Fj) es la longitud (en octetos) de una tupla del fragmento Ej. Informacin de los sitios. Sobre cada ordenador necesitamos conocer sus capacidades de procesamiento y almacenamiento. Obviamente, estos valores pueden calcularse a travs de funciones elaboradas o por simples estimaciones. Teora de Bases de Datos II 139 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 debera ser idntica a aquella utilizada en las medidas RR y UR. Informacin 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 comunicacin por trama entre los sitios Si y Sj. Para permitir el clculo del nmero de mensajes, usaremos tamao como el tamao (en octetos) de una trama. Es evidente que existen modelos de red mucho ms elaborados que toman en cuenta las capacidades del canal, las distancias entre sitios, las caract ersticas del protocolo, etc. Sin embargo, se cree que la derivacin 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 especfica es el nmero de accesos al disco. En un sistema distribuido es preciso tener en cuenta otros factores, como son:

El costo de transmisin de datos en la red. El beneficio potencial que supondra en la ejecucin 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 vara 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.
140
UCENM
Repeticin y fragmentacin Considere una consulta muy sencilla: encontrar todas las duplas de la relacin depsito. Aunque la consulta es muy simple, de hecho es trivial; su procesamiento no es trivial, ya que es posible que la relacin depsito est fragmentada, repetido o las dos cosas, como ya se vio. Si la relacin 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 transmisin ms reducidos. Pero si una copia est fragmentada, la eleccin no es tan sencilla, ya que es preciso calcular varios productos o uniones para reconstruir la relacin depsito. En tal caso, el nmero de estrategias para este ejemplo sencillo puede ser grande. De hecho, la eleccin de una estrategia puede ser una ta rea tan compleja como hacer una consulta arbitraria. Procesamiento de interseccin simple Considere la expresin 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 tcnicas de procesamiento de consulta, escoger una estrategia para procesar en forma local la consulta completa en Li. Enviar una copia de la relacin cliente a la localidad Li y calcular cliente x depsito de Ld. Enviar cliente x depsito de Ld a Lb, donde se calcula
141
UCENM
(cliente x depsito) x sucursal. El resultado de esta operacin 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 estn 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 interseccin utilizando el paralelismo Considere un producto de cuatro relaciones: r1 x r2 r3 r4 Donde la relacin r1 est almacenada en la localidad Li. Suponemos qu e el resultado ha de presentarse en la localidad Li. Existen, por supuesto muchas estrategias que se pueden considerar. Un mtodo atractivo sera utilizar la estrategia de interseccin 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 clculo de (r1 x r2) x (r3 x r4) en paralelo con el clculo de (r1 x r2) en L2 y de (r3 x r4) en L4. Estrategia de seminterseccin Suponer que deseamos calcular la expresin r1 x r2, donde r1 y r2 estn almacenados en las localidades L1 y L2 respectivamente. Sean R1 y R2 los Teora de Bases de Datos II 142 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 envo de r2 a S1 requiere el envo 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 situacin si r1 es el resultado de una expresin de lgebra relacional que contenga la seleccin. Esta estrategia es conocida como una estrategia de semiproducto, despus del operador de semiproducto, indicado por x, de lgebra relacional. Conclusiones y consideraciones: A lo largo de este documento se ha intentado dar una visin global y genrica de los problemas y caractersticas que contiene el diseo de una base de datos distribuida. Se ha hecho especial hincapi en las tcnicas de fragmentacin horizontal y vertical a travs de mtodos y algoritmos muy frecuentes en la literatura referida al tema. Se espera que el lector no haya tenido demasiados problemas para su comprensin, las tcnicas son sencillas y se ha procurado incluir distintos Teora de Bases de Datos II 143 UCENM
ejemplos para facilitar el entendimiento. Igualmente, la puesta en prctica de los algoritmos, es decir, su codificacin, no es un proceso complicado si se poseen nociones en el desarrollo de algoritmos. Piense, por ejemplo, que los dos algoritmos de particin vertical presentados, no hacen ms que manipular matrices. Tambin debera tenerse presente la existencia de enfoques de fragmentacin distintos y, posiblemente, ms complejos, pero se debe pensar que ms eficientes. Sean, por ejemplo, las tcnicas de fragmentacin vertical basadas en grafos, como el algoritmo de Navathe y Ra que genera en un solo pas fragmentos verticales. Adems, estn apareciendo mtodos de fragmentacin mixta como el que se ha comentado. Si bien, estos mtodos son enfoques formales ms que prcticos, desarrollados por insignes investigadores en universidades, por tanto, lejos todava de su desarrollo comercial. Pese a la aparicin de los mtodos de bases de datos distribuidas hace ya aos, parece que el salto de lo centralizado a lo distribuido a escala comercial est por venir. Todava no se ha extendido suficientemente el esquema distribuido, pero se espera que prximamente se produzca el avance definitivo. Considere los dos componentes bsicos de los sistemas de bases de datos distribuidos (la propia base de datos y la red de ordenadores) y piense en la situacin actual de la informtica. Si las bases de datos es una de las ramas ms antiguas e importantes de la informtica, muchas empresas compran ordenadores para dedicarlos exclusivamente a la gestin de sus datos (pienso que, prcticamente, 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 conexin de los ordenadores, la instalacin de una red, se puede concluir diciendo que el terreno ya est abonado para su extensin comercial. Slo fa lta Teora de Bases de Datos II 144 UCENM
que determinadas multinacionales decidan apostar ms fuerte por este enfoque a travs de sus famosos sistemas gestores de bases de datos y que se produzca la consolidacin de la resolucin de los problemas que el enfoque distribuido acarrea. TIPOS DE BASES DE DATOS DISTRIBUIDAS
HETEROGENEA Las Bases de datos heterogneas con un alto grado de autonoma 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 slo conecta con otros nodos en no tiene. Este tipo de base de datos se suele llamar sistema federado o federacin. Se ha hecho cada da ms popular en las organizaciones, tanto por su escalabilidad, su capacidad de mezclar distintos paquetes software y su reducido coste al aadir nuevos nodos cuando es necesario. A diferencia de los sistemas homogneos, los sistemas heterogneos 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. busca de informacin que
DDBMS HETEROGNEO

Esquema global nico. Modelo de datos y lenguaje de consultas comn. Esquema integrado. Consultas reales distribuidas.
INTERFAZ HETEROGNEA

Acceso en lnea a una nica base de datos No hay integracin de bases de datos El acceso usa un modelo de datos; el DBMS, otro 145 UCENM
SISTEMA HOMOGNEO Las bases de datos distribuidas homogneas usan el mismo software de SGBD y tienen las mismas aplicaciones en cada nodo. Tienen un esquema comn y pueden tener grados diversos de autonoma local. Pueden estar basadas en cualquier SGBD que soporte estas caractersticas, pero no puede haber ms de un SGBD en el sistema. La autonoma local especifica cmo el sistema funciona desde la perspectiva de los usuarios y programadores. Por ejemplo: Podemos tener un sistema con poca o sin autonoma local, donde todas las peticiones se envan a un nodo central, llamado gateway. Desde aqu se asigna al nodo que contiene esa informacin o aplicacin requerida. Esto es lo tpico que se ve con los mirrors de sitios web muy populares a los cuales una pgina central deriva las peticiones de sus usuarios dependiendo de su origen geogrfico.
146
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 investigacin 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 administracin 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 distribucin de la base de datos. Los programadores y los usuarios pueden concentrarse en la naturaleza y en la lgica del problema de la informacin que necesitan resolver, no vindose obligados a tratar asuntos que corresponden al DDBMS: para simplificar este anlisis, en el resto de este documento nos referiremos a los usuarios de consulta y a los programas de transaccin slo como transacciones.
147
UCENM
Las transacciones necesitan tener acceso a la base de datos va un DDBMS que proporcione los cuatro siguientes tipos de transparencia: localizacin de los datos, duplicacin de los datos, concurrencia y falla. Lo cual significa que, en forma ideal, la transaccin ni siquiera est consciente que los datos se encuentran distribuidos. Los cuatro temas de distribucin se manejan tras bambalinas. TRANSPARENCIA DE LOCALIZACIN Las transacciones necesitan ser independientes de la localizacin de un elemento de datos particular. De no ser as, las cuestiones de localizacin complicaran la lgica de la transaccin. 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, debern modificarse dos registros de inventario. Suponga que los datos involucrados no estn duplicados; pero que datos puedan estar almacenados en una computadora en cualquiera de las dos localizaciones. Si el programa que procesa esta transaccin no es transparente en lo que se refiere a localizacin 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 lgica de la transaccin se confunde por la necesidad de considerar la localizacin de los datos. La lgica sera mucho ms complicada para un ejemplo ms complejo, en cualquier caso estas consideraciones son innecesarias e inapropiadas para un programa de aplicacin. Se puede conseguir la transparencia de localizacin si los administradores de transacciones distribuidas (los DTM en la Figura 1) son responsables de determinar la localizacin de los datos y de emitir las acciones a l os DBM apropiados, lo cual se puede llevar a cabo si los DTM poseen acceso a los Teora de Bases de Datos II 148 UCENM
directorios de las localizaciones de los datos. Si los datos se mueven, slo el DTM necesita involucrarse. Todas las transacciones quedan aisladas de la modificacin en la localizacin. TRANSPARENCIA DE DUPLICACIN Las transacciones son accesibles a la duplicacin si pueden procesarse sin saber cuntas veces, o incluso si los datos estn duplicados. La transaccin puede actuar como si todos los datos estuvieran almacenados slo una vez en nada ms un nodo. Con la transparencia de duplicacin, se pueden crear nuevos duplicados, o los duplicados existentes pueden ser eliminados, sin provocar efecto alguno sobre la transaccin del usuario o el procesamiento de la consulta. Para proporcionar transparencia en la duplicacin, los administradores de transacciones deben traducir las solicitudes de procesamiento de transaccin 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 accin para su lectura. Para facilitar la seleccin, el DTM pudiera conservar estadsticas sobre el tiempo que se requiere para leer datos de varios nodos, y seleccionar el nodo con el mejor rendimiento. Es ms complicado la escritura de datos dupl icados, porque el DTM deber emitir una accin de escritura para cada uno de los DBM que almacena una copia de dichos datos. Este anlisis supone que cada DTM posee una copia exacta y actualizada de un directorio que indique la localizacin de los datos. Sin embargo, aparecen problemas interesantes, si consideramos lo que ocurrira cuando el directorio deba modificarse para tomar en cuenta nuevas copias de datos o su eliminacin. Resulta crtica la coordinacin.
149
UCENM
Todos los directorios debern ser instalados de forma que ningn DTM piense que los datos estn disponibles antes que as sea (en el caso de lecturas) y que todos los DTM sepan que los datos estn disponibles cuando lo estn (en el caso de escrituras). De lo contrario, un DTM pudiera solicitar datos que toda no estn disponibles o dejar de emitir una orden de escritura a un DBM cuando los datos estn disponibles. TRANSPARENCIA DE CONCURRENCIA Aunque mltiples transacciones que involucran la base de datos distribuida se lleven a cabo al mismo tiempo, los resultados de las transacciones no debern afectarse. El DDBMS proporciona transparencia de concurrencia si los resultados de todas las transacciones concurrentes son consistentes de manera lgica con los resultados que se habran obtenido si las transacciones se hubieran ejecutado una por una, en algn orden serial arbitrario. Expresada de otra forma, la lgica de las transacciones procesadas en forma concurrente con otras transacciones deber de ser la misma que si la transaccin 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 extensin del mecanismo de control de concurrencia. Un segundo mtodo se llama pedido con sello de recepcin. Ambos han sido implementados en productos DDBMS. Es ms comn 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 transaccin, en el DDBMS, en la red y en la computadora. Frente
150
UCENM
a una falla, las transacciones debern ser atmicas, esto es, ya sea que se procesen todas las transacciones o ninguna de ellas.
Adems, una vez comprometidos los resultados de las transacciones, sern permanentes. La transparencia contra fallas es la meta ms difcil entre las cuatro. Parte del problema es que existen muchos tipos distintos de fallas. En un extremo del espectro habr un nodo que jams 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 travs de la red, o bien, en razn de su falla, pudiera enviar acciones inapropiadas, pero con formato vlido por la red. Nodos como stos se conocen como nodos desquiciados. Otro tipo de falla corresponde a nodos que se convierten en malvolos, lo cual significa el nodo tiene el propsito expreso de llevar a cabo una activida d no autorizada, o de causar daos 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 estn los nodos sensatos. Un nodo sensato es un nodo que puede fallar, pero slo en una forma definida y conocida. El ejemplo ms sencillo de un nodo sensato es uno que, o es perfecto, o deja de responder completo. Otra razn por la cual la transparencia de falla es tan difcil 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 Teora de Bases de Datos II 151 UCENM
burbuja de aire bajo el tapiz que se empuja de una esquina slo 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 recuperacin en una cierta forma, etc. En el caso general de bases de datos divididas y duplicadas quedan an por resolver mltiples problemas tericos y prcticos de puesta en prctica.
152
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.
153
UCENM
5-.Cual es la Estructura de Base de Datos Distribuidas?
6-.Que comprende por Diseo de la distribucin?
7-.Cuales son los Tipos de fragmentacin que existen?
8-.Que Reglas de correccin de la fragmentacin?
9.-Cules son los criterios para correccin de los algoritmos?
10-.Que
tipo
de
Tipos
de
Bases
de
Datos
Distribuidas
Hetereogenea..hay?
154
UCENM
BASES DE DATOS PARALELAS

Objetivos del captulo V
1 Comprender Paralelas. 2 Conocer Diseo de Sistemas paralelos. 3 Conocer la Integracin de Bases paralelas. 4 Conocer el procesamiento paralelo.
Teora de Bases de Datos II 155 UCENM
y analizar el concepto Bases
Datos
Bases de Datos Paralelas.

Introduccin De forma general el concepto de paralelismo en las bases de datos lo podramos definir como la particin 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 operacin sobre la base de datos. Hace unos aos 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. Adems los sitios web tienen millones de visitantes para los que se requieren bases de datos enormes. Las empresas utilizan cada vez mayores volmenes 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 paralelizaran. Las mquinas paralelas con varios procesadores son relativamente baratas. El paralelismo se usa para mejorar la velocidad en la ejecucin de consultas. Adems 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 comn.
156
UCENM
De discos compartidos:
Todos los procesadores comparten un conjunto de discos comn. Sin compartimiento: Los procesadores no comparten ni memoria ni disco. Jerrquica: Este modelo es un hbrido 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 recuperacin. Normalmente la divisin ms comn en un entorno de bases de datos paralelas es la divisin horizontal. En este tipo de divisin las duplas de cada relacin se dividen entre varios discos de modo que cada dupla resida en un disco distinto. Suponiendo que tenemos n discos (D0,D1,,DnEntre los que se van a dividir los datos, existen varias estrategias de divisin: Turno rotatorio: Se recorre la relacin y la i-sima Dupla se enva al disco Di modo n quedando una distribucin homognea de las duplas en los discos. Divisin por asociacin: Se escogen varios atributos del esquema de la relacin y se designan como atributos de divisin. Se escoge una funcin de asociacin cuyo rango es {0,1,,n-1}. Cada dupla de la relacin original se asocia en trminos de los atributos de divisin. Si la funcin de asociacin devuelve i, la dupla de ubi ca en el disco DI. Divisin por rangos: Se distribuye rangos contiguos de valores de los atributos a cada disco. Para ello se escoge un atributo de divisin, AD, como vector de divisin y la relacin se divide de la siguiente manera: o Sea [vo, v1, , vn-2] el vector de divisin con i<j y vi<vj. Considrese una dupla t tal que t[A]=x. o Si x< vo entonces t se ubica en el disco Do. Teora de Bases de Datos II 157 UCENM
o Si xvn-2 entonces t se ubica en el disco Dn-1. o Si vix < vi+1 entonces t se ubica en el disco DI+1 Comparativa entre tcnicas de divisin Cuando ya hemos dividido una relacin en varios discos se puede recuperar en paralelo utilizndolos todos de la misma manera que se puede escribir en paralelo cuando se est dividiendo una relacin. Por lo tanto, cuando se quiera leer (o escribir) la relacin completa ganaremos tiempo gracias al paralelismo. Adems de leer de forma completa una relacin Eisten otro tipo de lecturas o consultas: Exploracin de la relacin 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 tcnicas de divisin explicadas permiten estos tipos de acceso pero con diferentes Niveles de eficacia: Turno rotatorio: Se adapta bien a la exploracin completa pero no es eficiente para consultas concretas y de rango ya que tiene que buscar en todos los discos. Divisin por asociacin: Este esquema se adapta bien a las consultas concretas basadas en el atributo de divisin ya que dirigimos la consulta al disco que se nos indica la funcin de asociacin para el atributo y el valor del mismo. Tambin se adapta bien a una exploracin completa si la funcin de asociacin reparte bien las duplas en los discos. Sin embargo no es adecuada esta tcnica para consultas concretas cuando el atributo de bsqueda no coincide con el atributo de divisin. Divisin por rangos: Se adapta bien a las consultas concretas y de rango basadas en el atributo de divisin. Para consultas concretas se debe analizar el vector de divisin para
158
UCENM
Ver en que disco est la dupla al igual que para una consulta de rango se consulta el vector de divisin para ver en que rango de discos estn las Duplas. En general se prefiere divisin por asociacin o por rangos a turno rotatorio. En la siguiente Tabla se resume la comparativa: Tcnica Divisin Relacin Completa Consulta Concreta Consulta de Rango Turno Rotatorio Eficaz Ineficaz Ineficaz Por Rango - Eficaz si coincide Con atributo de Divisin Eficaz si coincide Con atributo de Divisin Por Asociacin Eficaz si la Funcin reparte Bien las duplas Eficaz si coincide Con atributo de Divisin El problema de las divisiones por asociacin es que tienden a almacenar un alto porcentaje de duplas en algunos discos especficos, situacin 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 divisin equilibrado.
159
UCENM
Si una relacin contiene un nmero pequeo 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 simultneamente 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 versin en la memoria intermedia. El problema de asegurar que la versin sea la ltima disponible se denomina problema de coherencia del bloqueo compartido o exclusivo de la pgina, la transaccin lee tambin su copia mas reciente del disco compartido. Antes de que una transaccin libere el bloqueo exclusivo de una pgina, la traslada al disco compartido, posteriormente libera el bloqueo. Con este protocolo se garantiza que cuando una transaccin establece un bloqueo compartido o exclusivo sobre una pgina, obtenga la copia correcta de la pgina. Paralelismo en consultas Es la ejecucin en paralelo de una nica consulta entre varios procesadores y discos, cuyo objetivo es acelerar las consultas de ejecucin 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 ejecucin de cada una de sus operaciones Individuales ordenacin, seleccin, proyeccin y reunin. Paralelismo entre Operaciones. Se puede acelerar el procesamiento de la Consulta ejecutando en paralelo las diferentes operaciones de las expresiones de las consultas. Teora de Bases de Datos II 160 UCENM
Por lo tanto el objetivo que se persigue es dividir la relacin que interviene en la consulta por medio de tcnicas de divisin 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 ejecutndolas sobre subconjuntos diferentes de las relaciones en paralelo. Segn el tipo de operacin se siguen distintos criterios en el tratamiento que son: Ordenacin Paralela Reunin Paralela. Ordenacin Paralela. Dependiendo del criterio en la divisin de la relacin se pueden distinguir dos tipos de ordenacin: Ordenacin divisin de Rangos. Esta forma de divisin por rangos posee dos etapas Diferenciadas: Redistribuir las duplas de la relacin utilizando una estrategia de divisin por rangos, de manera que todas las duplas que se hallen dentro del rango isimo se enven al procesador Pi, que almacena temporalmente la relacin en el disco Di. Para implementar en paralelo la divisin por rangos cada procesador lee las duplas de su disco y las enva al procesador de destino. Cada procesador P0,P1Pn tambin recibe las duplas correspondientes a su particin y las almacena localmente. Cada uno de los procesadores ordena localmente su particin de la relacin sin Interactuar con los dems. La operacin final de mezcla es trivial ya que la divisin por rangos de la primera etapa asegura que los valores de la clave del procesador Pi sean menores que los procesador Pj Teora de Bases de Datos II 161 UCENM
Ordenacin y mezcla externa paralela. Este tipo de ordenacin es una alternativa a la efectuada por la divisin por rangos. Las etapas que se definen una vez que la relacin se ha divida entre los diferentes discos D1,D2Dn-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 tambin paralelizado mediante la siguiente secuencia de acciones. El sistema divide en rangos las particiones ordenadas encada procesador Pi Entre los procesadores P0,P1Pn-1. Enva 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 segn 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. Reunin Paralela. La operacin reunin exige que el sistema compare pares de duplas para ver si satisface la Condicin de reunin, si la cumple aade el par al resultado de la reunin. Los algoritmos de reunin paralela intentan repartir entre varios procesadores los pares que hay que comparar. Cada procesador procesa luego localmente parte de la reunin. Despus, el sistema rene 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: Reunin por Divisin. Vlida para reuniones de tipo equirreuniones y reuniones
162
UCENM
Naturales, en la cual existen n procesadores y las relaciones que hay que reunir son r y s. La reunin por divisin funciona de esta forma: El sistema divide las relaciones r y s en n particiones r0,r1,rn -1 y s0,s1,sn1 Enva las particiones ri y si al procesador Pi, donde la reunin se procesa localmente. Existen dos maneras diferentes de dividir las relaciones r y s y son Divisin por rangos de los atributos de reunin, en el que se debe usar el mismo vector de divisin. Divisin por asociacin de los atributos de reunin, se debe usar la misma funcin de asociacin. Una vez divididas las relaciones se pueden utilizar localmente cualquier tcnica de reunin en cada procesador Pi para calcular la reunin de ri y si. Reunin con fragmentos y replicas. Proporcionan una alternativa para las Reuniones que no puede ser procesada por la tcnica de reunin por divisin, como por ejemplo si la condicin de reunin es una desigualdad. En este tipo de reuniones pueden paralelizarse Utilizando una tcnica denominada fragmentos y replicas, cuyo funcionamiento es el siguiente. El sistema divide una de las relaciones (por ejemplo s) mediante cualquier tcnica de divisin, incluida por turno rotatorio. El sistema replica la otra relacin r en todos los procesadores El procesador Pi procesa localmente la reunin de ri con todos, utilizando cualquier tcnica de reunin. Reunin por asociacin dividida en paralelo. La reunin por asociacin 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 hbrido de reunin por asociacin para guardar en cach algunas de las duplas de entrada, y evitar as los costes de escribirlas y volver a leerlas.
163
UCENM
Otras operaciones relacionales Tambin se puede realizar en paralelo la evaluacin de otras operaciones relacionales: Seleccin. Sea la seleccin me(r). Considrese 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 relacin r se divide basndose en ai la seleccin se lleva a cabo en un solo procesador. Si e es de la forma l ) ai ) u (es decir, que ees una seleccin de rango) y la relacin se ha dividido por rangos basndose en ai, entonces la seleccin se lleva a cabo en cada procesador cuya particin se solape con el rango de valores especificado. En el resto de los casos la seleccin se lleva a cabo en todos los procesadores en paralelo. Eliminacin de duplicados. La eliminacin de duplicados puede llevarse a cabo por ordenacin; puede utilizarse cualquiera de las tcnicas de ordenacin en paralelo, con la optimizacin de eliminar los duplicados durante la ordenacin tan pronto como se encuentren. Tambin se puede realizar la eliminacin de duplic ados en paralelo dividiendo las duplas (mediante divisin por rangos o por asociacin) y llevando a cabo localmente en cada procesador la eliminacin de duplicados. Proyeccin. Se puede llevar a cabo la proyeccin sin eliminacin de duplicados segn se leen en paralelo las duplas del disco. Si se va a llevar a cabo la eliminacin de duplicados se puede utilizar las tcnicas que se acaban de describir. Agregacin. La agregacin puede considerarse una operacin. Se puede paralelizar la operacin dividiendo la relacin basndose en los atributos de agrupacin y procesando luego localmente los valores de agregacin en cada procesador. Se puede utilizar divisin por rangos o por asociacin. Si la relacin ya est dividida basndose en los atributos de agrupacin se puede omitir el primer paso. Costo de la evaluacin 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 Teora de Bases de Datos II 164 UCENM
paralelo que utilicen n procesadores tardarn 1/n lo que tardaran en un solo procesador. Ya se sabe cmo estimar el coste de operaciones como la reunin o la seleccin. El coste en tiempo del procesamiento paralelo sera entonces 1/n el del Procesamiento secuencial de la operacin. Tambin hay que tener en cuenta los costes siguientes: Los costos de iniciar la operacin en varios procesadores. El sesgo en la distribucin de trabajo entre los procesadores, con algunos procesadores con mayor nmero de duplas que otros. La contencin 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 tamao del paso medio, es el tiempo de procesamiento del paso ms lento el que determina el tiempo empleado en procesar la consulta en su conjunto. Una evaluacin en paralelo de las particiones, por ejemplo, slo es tan rpida como la ms lenta de sus ejecuciones en paralelo. Por tanto, el rendimiento se ve muy afectado por cualquier sesgo en la distribucin del trabajo entre los procesadores. El problema del sesgo de la divisin est ntimamente relacionado con el del Desbordamiento de particiones en las reuniones por asociacin secuenciales. Se puede utilizar la resolucin del desbordamiento y las tcnicas de evitacin desarrolladas para las reuniones por asociacin para tratar el sesgo cuando se utilice la divisin por asociacin. 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 economa de procesamiento para el procesamiento de consultas de bases de datos. La ventaja principal de la ejecucin encauzada de las Teora de Bases de Datos II 165 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 razn que en los sistemas secuenciales. Sin embargo, el encauzamiento puede utilizarse tambin como fuente de paralelismo, del mismo modo que el encauzamiento de instrucciones se utiliza como fuente de paralelismo en el diseo de hardware. Esta forma de paralelismo se denomina paralelismo de encauzamiento. El paralelismo encauzado resulta til con un nmero pequeo 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 re lacin que no producen resultados hasta que se ha tenido acceso a todas las entradas, como la operacin diferencia de conjuntos. En tercer lugar, slo se obtiene una aceleracin marginal en los casos frecuentes en que el coste de ejecucin de un operador es mucho mayor que los de los dems 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 razn 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.
166
UCENM
Optimizacin de consultas. Un factor importante en el xito de la tecnologa relacional ha sido el diseo con xito de optimizadores de consultas. Los optimizadores de consultas para la evaluacin de consultas en paralelo son ms complicados que los optimizadores de consultas para la evaluacin secuencial de consultas. En primer lugar, los modelos de costes son ms complicados dado que hay que tener en cuenta los costes de divisin, y deben tenerse en consideracin aspectos como el sesgo y la contencin de recursos. Resulta de mayor importancia el asunto de la paralelizaran de las consultas. Supngase que de algn modo se ha escogido una expresin (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 operacin y el nmero 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. Diseo de sistemas paralelos. La carga de datos en paralelo desde fuentes externas es un requisito importante si se van a tratar grandes volmenes de datos entrantes. Un gran sistema paralelo de bases de datos debe abordar tambin los siguientes aspectos de disponibilidad: El poder de recuperacin frente al fallo de algunos procesadores o discos La reorganizacin interactiva de los datos y los cambios de los esquemas.
167
UCENM
Con un gran nmero 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 diseado dejar de funcionar si cualquier componente (procesador o disco) falla. Suponiendo que la probabilidad de fallo de cada procesador o disco es pequea, la probabilidad de fallo del sistema asciende. Por tanto, los sistemas paralelos de bases de datos de gran escala se disean 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 dems 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 desvan automticamente a los emplaza mientos de las copias de seguridad que guardan una rplica de los datos. Cuando se manejan grandes volmenes de datos (del orden de terabytes), las operaciones sencillas, como la creacin de ndices, y los cambios en los esquemas, como aadir una columna a una relacin, pueden tardar mucho tiempo (quizs horas o incluso das). Por tanto, es inaceptable que los sistemas de bases de datos no estn 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 Introduccin. Grid es una tecnologa que surgi como una nueva forma de computacin distribuida. Ian Foster y Carl Kesselman son considerados los padres de esta tecnologa, introducida por ellos en los aos 90. Esta tecnologa se basa en la utilizacin de recursos externos adems de los locales, logrando con ello una mayor disponibilidad de recursos para la realizacin de una tarea. Teora de Bases de Datos II 168 UCENM
La tecnologa estndar, o una de las ms 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 geogrfico y que no estn 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 localizacin 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 atencin en los datos que se transmiten en s, como es el caso de los sistemas Cliente -Servidor sino que el punto de inters 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 tamao. Una definicin de computacin Grid encontrada en la wiki peda es la siguiente: GRID COMPUTING: Es una tecnologa innovadora que permite utilizar de forma coordinada todo tipo de recursos (entre ellos cmputo, almacenamiento y aplicaciones especficas) que no estn sujetos a un control centralizado. En este sentido es una nueva forma de computacin distribuida, en la cual los recursos pueden ser heterogneos (diferentes arquitecturas, supercomputadores, Clster...) y se encuentran conectados mediante redes de rea extensa (por ejemplo Internet). Desarrollado en mbitos cientficos a principios de los aos 90 su entrada al mercado comercial siguiendo la idea de la llamada Utility Computing supone una revolucin que dar mucho que hablar.
169
UCENM
Las caractersticas de esta arquitectura seran: Capacidad de balanceo de sistemas: no habra necesidad de calcular la capacidad de los sistemas en funcin 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. Reduccin 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 tecnologas Grid, adems 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 aparicin de un error en un equipo y en una localizacin determinada, provoque el error en toda la red. Bases de Datos GRID. Las Bases de Datos Grid nos proporcionan una visin uniforme de bases de datos heterogneas en los entornos Grid. Es decir, puesto que ex isten diversos tipos de bases de datos, refirindonos con ellos a que stas pueden ser relacionales, orientadas a objetos, en XML, etctera, nuestro sistema nos tiene que proporcionar la abstraccin necesaria de los datos para que el usuario no distinga entre si esta accediendo a una relacional o a una orientada a objetos,
170
UCENM
Ya que el usuario no le importa cmo se realice el trabajo, solo necesita que se haga y debe ser el Grid middleware quien se ocupe de que se efecte correctamente. Por otro lado la especificacin de los servicios de bases de datos deben ser ortogonales a los mecanismos de autentificacin y autorizacin 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 cmo se hace, donde o incluso que recursos o almacenamiento est siendo utilizado. Del mismo modo, no deber preocuparse por la administracin de los recursos. Requisitos para la utilizacin 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: Autentificacin: Verificacin de la validez de la identidad de un usuario, recurso, Servicio,.. Autorizacin: 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: Informacin sensible como puede ser informacin de carcter Personal, orientacin sexual, datos mdicos o bancarios, no puede ser observada por terceros.
171
UCENM
Gestin de claves: Hace referencia a la gestin de seguridad, proceso de distribucin, generacin y almacenamiento de claves.
Encriptacin: o Simtrica: El proceso de encriptacin se realiza usando la misma clave privada. Inconvenientes: El emisor y el receptor deben intercambiar la clave. o Asimtrica: Se utilizan dos claves diferentes para encriptar y desencriptar datos. Criptografa de clave pblica. Lentitud considerable en mensajes grandes. Aparicin de patrones que puede simplificar su criptoanlisis. Secure Socket Layer/ Transport Layer Security (SSL/ TLS): Protocolo de comunicacin segura. Autentificacin Mutua: Dos entidades que quieren comunicarse usan su clave pblica almacenada en un certificado digital para autentificarse. Estos servicios fundamentales se garantizan mediante: GRID Security Infrastructure (GSI) Public Key Infrastructure (PKI) Integracin 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. Teora de Bases de Datos II 172 UCENM
Otra de las ventajas de estandarizar siempre es reducir el esfuerzo de construccin 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 informacin sobre los servicios que ofrece el sistema. Adems, cuando los usuarios del sistema soliciten un servicio no saben en qu sistema est y mediante los metadatos l se pueden construir dinmicamente las interfaces para acceder a los distintos sistemas de bases de datos que forman parte del Grid. Manejo de consultas. Como hemos comentado ms arriba los lenguajes pueden ser diferentes. Por eso en los metadatos se proporciona la informacin necesaria sobre el lenguaje de consulta que soporta cada base de datos. Tambin es importante que los resultados de una consulta se puedan enviar a distintos destinos y que sean comprensibles por stos para poder construir sistemas ms amplios y complejos.
173
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 comunicacin del sistema Grid para llevar a cabo la transferencia de esos datos o Notificacin. Sirve para notificar los cambios que se producen a los clientes que deseen recibir esa informacin. Los clientes deben poder expresar si estn 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 ms 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. Planificacin. Se debe permitir por ejemplo que cuando un superordenador conecte con un DBS, la informacin 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 prctico, se requieren mecanismos con suficientes recursos (discos, CPUs, memoria, red). Ventajas e Inconvenientes de las BBDD en un Sistema GRID Teora de Bases de Datos II 174 UCENM
Las bases de datos alojadas en un sistema GRID van a heredar todas las caractersticas:
Ventajas e inconvenientes del sistema al que pertenecen. La Computacin GRID est creada con el fin de ofrecer una solucin a determinadas cuestiones, como problemas que requieren de: Un gran nmero 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 mquinas 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 informacin, mediante la colaboracin y la flexibilidad operacional, aunando no slo recursos tecnolgicos dispares, sino tambin 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 investigacin, en donde enormes cantidades de informacin 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 colaboracin transparente y la comparticin de recursos. Tiende a incrementar la productividad otorgando a los usuarios finales acceso a los recursos de computacin, datos y almacenamiento que necesiten, cuando los necesiten. o Se aprovechan los ciclos de procesamiento inutilizados de ordenadores que se encuentran en diversas zonas geogrficas.
175
UCENM
Ejemplo: ordenadores que normalmente se encuentran inutilizados por la noche en una compaa en Europa, podran ser utilizados en el da por una sede de operaciones en Amrica. El paralelismo puede estar visto como un problema, ya que una mquina paralela es muy costosa. Pero, si tenemos disponibilidad de un conjunto de mquinas heterogneas de pequeo o mediano porte, cuya potencia computacional sumada sea considerable, eso permitira generar sistemas distribuidos de muy bajo coste y gran potencia computacional. La tolerancia a fallos significa que si una de las mquinas que forman parte del GRID colapsa, el sistema lo reconoce y la tarea se reenva a otra mquina, con lo cual se cumple el objetivo de crear infraestructuras operativas flexibles y resistentes. As se obtiene una tecnologa ms 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 autorizacin del usuario. Monitoriza la ejecucin. Adems, 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 das, con banda ancha, servidores de capacidad, seguridad informtica, VPN, firewalls, encriptacin, comunicaciones seguras, polticas de seguridad, normas ISO, y algunas caractersticas ms Metadatos en Bases de Datos en un Sistema GRID. Por qu son necesarios los metadatos? Teora de Bases de Datos II 176 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 construccin 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 informacin sobre los servicios que ofrece el sistema. Adems, cuando los usuarios del sistema soliciten un servicio no saben en qu sistema est y mediante los metadatos se pueden construir dinmicamente las interfaces para acceder a los distintos sistemas de bases de datos que forman parte del GRID. Manejo de consultas. Como hemos comentado ms arriba los lenguajes pueden ser diferentes. Por eso en los metadatos se proporciona la informacin necesaria sobre el lenguaje de consulta que soporta cada base de datos. Tambin es importante que los resultados de una consulta se puedan enviar a distintos destinos y que sean comprensibles por stos para poder construir sistemas ms 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 Teora de Bases de Datos II 177 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 comunicacin del sistema GRID para llevar a cabo la transferencia de esos datos. o Notificacin. Sirve para notificar los cambios que se producen a los clientes que deseen recibir esa informacin. Los clientes deben poder expresar si estn 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 ms 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. Planificacin. Se debe permitir por ejemplo que cuando un superordenador conecte con un sistema de base de datos, la informacin 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 prctico, se requieren mecanismos con suficientes recursos (discos, CPUs, memoria, red).
PROCESAMIENTO PARALELO El procesamiento paralelo es un trmino que se usa para denotar un grupo de tcnicas significativas que se usan para proporcionar tareas simultneas de procesamiento de datos con el fin de aumentar la velocidad computacional de un sistema de computadoras. En lugar de procesar cada instruccin 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 ejecucin. Por ejemplo, cuando se ejecuta una instruccin en la ALU, puede leerse la siguiente instruccin de la memoria. Teora de Bases de Datos II 178 UCENM
El sistema puede tener 2 o mas ALUS y ser capaz de ejecutar dos o mas instrucciones al mismo tiempo. Adems, el sistema puede tener dos o ms procesadores operando en forma concurrente.
EL propsito 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 circuitera aumenta con el procesamiento paralelo y, con l, tambin el costo del sistema. Sin embargo, los descubrimientos tecnolgicos han reducido el costo de la circuitera a un punto en donde las tcnicas de procesamiento paralelo son econmicamente factibles. El procesamiento paralelo puede considerarse de diversos niveles de complejidad. En el nivel ms 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 simultnea. Puede obtenerse procesamiento paralelo a un nivel ms alto de complejidad al tener mltiples unidades funcionales que ejecuten operaciones idnticas o diferentes, de manera simultnea. El procesamiento paralelo se establece al distribuir los datos entre las unidades funcionales mltiples. Por ejemplo, las operaciones aritmticas, lgicas y de corrimiento pueden separarse en tres unidades y dividirse los operandos a cada una, bajo la supervisin de una unidad de control.
Procesador con unidades funcionales mltiples La operacin ejecutada en cada unidad funcional se indica en cada bloque del diagrama. El sumador y el multiplicador de enteros ejecutan las operaciones aritmticas con nmeros enteros. Las operaciones de punto flotante se separan en tres circuitos que operan en paralelo. Las operaciones lgicas de corrimiento y de incremento pueden Teora de Bases de Datos II 179 UCENM
ejecutarse en forma concurrente sobre diferentes datos. Todas las unidades son independientes unas de otra, por lo que puede correrse un nmero mientras otro se incrementa. Por lo general, una organizacin 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 organizacin interna de los procesadores, desde la estructura de interconexin entre los procesadores o desde del flujo de informacin a travs del sistema. Una clasificacin presenta por M. J. Flynn considera la organizacin de un sistema de computadora mediante la cantidad de instrucciones y unidades de datos que se manipulan en forma simultnea. La operacin normal de una computadora es recuperar instrucciones de la memoria y ejecutarlas en el procesador. La secuencia de instrucciones ledas 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 clasificacin de Flynn divide a las computadoras en cuatro grupo principales de la manera siguiente: Flujo de instruccin nico, Flujo de datos nico (SISD) Flujo de instruccin nico, Flujo de datos Mltiple (SIMD) Flujo de instruccin Mltiple, Flujo de datos nico (MISD) Flujo de instruccin Mltiple, Flujo de datos Mltiple (MIMD) SISD. Representa la organizacin de una computadora nica que contiene una unidad de control, una unidad de procesador y una unidad de memoria. Las
180
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 mltiples o mediante una arquitectura paralela. SIMD. Representa una organizacin que influye muchas unidades de procesamiento bajo la supervisin de una unidad de control comn. Todos los procesadores reciben la misma instruccin de la unidad de control, pero operan sobre diferentes conjuntos de datos. La unidad de memoria compartida debe de contener mdulos mltiples para que pueda comunicarse con todos los procesadores simultneamente. LA estructura MISD es sola de intereses terico porque no se ha construido ningn sistema prctico utilizando esta organizacin. La organizacin MIMD se refiere a un sistema de computadoras capaz de procesar mltiples programas al mismo tiempo la mayora de los sistemas de multicomputadoras y multiprocesador pueden clasificarse en esta categora. La clasificacin de Flynn depende en la diferencia entre el desempeo de la unidad de control y el de la unidad de procesamiento de datos. Enfatiza las caractersticas de desempeo del sistema de computadoras ms que sus interconexiones estructurales y operacionales.
Un tipo de procesamiento paralelo que no entra en la clasificacin flynn es la arquitectura paralela (pipe-line) Las nicas dos categoras utilizadas de esta clasificacin son los procesadores de arreglo SIMD, El procesamiento por arquitectura paralela es una tcnica de implantacin en donde las suboperaciones aritmticas o las fases de un ciclo de instruccin de computadora se traslapan en su ejecucin el procesamiento de vectores relaciona con los clculos que implican vectores y matrices grandes. Teora de Bases de Datos II 181 UCENM
Los procesadores de arquitectura paralela ejecutan clculos sobre arreglos de datos grandes. Arquitectura Paralela La arquitectura paralela o de lneas paralelas (pipe -line), es una tcnica 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 lnea puede considerarse como un conjunto de segmentos de procesamiento por el que fluye informacin bi naria. Cada segmento ejecuta un procesamiento parcial, dictado por la manera en que se divide la tarea. El resultado obtenido del clculo en cada segmento se transfiere al siguiente segmento en la lnea. El resultado final se obtiene despus de que los datos han recorrido todos los segmentos. El nombre "lnea" implica un flujo reinformacin similar a una lnea de ensamblado industrial. Es caracterstico de las lneas que varios clculos puedan estar en proceso en distintos segmentos, al mismo tiempo. La simultaneidad de los clculos es posible al asociar un registro con cada segmento en la lnea. Los registros proporcionan aislamiento entre cada segmento para que cada uno pueda operar sobre datos distintos en forma simultnea. Tal vez la manera ms simple de apreciar la arquitectura de lneas 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 suboperacin 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 despus de que se ha transcurrido un tiempo suficiente para ejecutar toda la actividad del segmento. De esta manera la informacin fluye por la lnea un paso a la vez. Teora de Bases de Datos II 182 UCENM
La organizacin de la lnea se mostrar mediante un ejemplo: Supongamos que deseamos ejecutar las operaciones multiplicar y sumar combinadas con un flujo de nmeros. Ai * B1 + Ci para i=1,2,3,7 Cada suboperacin se va a implantar en un segmento dentro de la lnea. 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 simultnea. 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 lnea 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 lnea. 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 lnea Consideraciones generales Cualquier operacin que pueden descomponerse en una secuencia de suboperaciones de aproximadamente la misma complejidad, puede implementarse mediante un procesador de arquitectura parale la. La tcnica es eficiente para aquellas aplicaciones que necesitan repetir la misma tarea Teora de Bases de Datos II 183 UCENM
muchas veces con diferentes conjuntos de datos. La estructura general de una lnea de cuatros segmentados . Los operandos recorren los cuatros segmentos de una secuencia fija. Cada segmento consta de cada circuito combinacional Si Que ejecuta una suboperacin sobre el flujo de datos que fluyen por la lnea. Los segmentos se separan mediante registros Ri Que contienen los resultados intermedios entre las etapas. La informacin fluye entre etapas adyacentes bajo el control de un reloj comn aplicado a todos los registros en forma simultnea definimos una tarea como la operacin total ejecutada cuando se recorren todos los segmentos en la lnea. Lnea paralela de cuatro segmentos Para ver el grfico seleccione la opcin "Descargar" del men superior El desempeo de la arquitectura paralela puede ilustrarse mediante un diagrama espacio- tiempo. Este es un diagrama que muestra la utilizacin del segmento como una funcin 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 nmero 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. Despus 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 despus del cuarto ciclo de reloj. De ah en adelante la lnea completa una tarea en cada ciclo de reloj . No importa cuntos segmentos existan en el sistema, una vez que la lnea est llena, solo se necesita un periodo de reloj para obtener una salida. Ahora consideremos el caso en donde se utiliza una lnea 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 operacin, porque existen K Teora de Bases de Datos II 184 UCENM
segmentos en la lnea. Las n-1 tareas restantes emergen en la lnea a una velocidad de una tarea por ciclo de reloj y se terminar despus de un tiempo igual (n-1)tp por lo tanto, para completar n tareas una lnea 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 segn se indica en el diagrama.
Ciclos de reloj
1 Segmento 1 2 3 4 T1 T2 T1
2 T3 T2 T1
3 T4 T3 T2 T1
4 T5 T4 T3 T2
5 T6 T5 T4 T3
T6 T5 T4 T6 T5 T6
Figura 9.4 Diagrama espacio-tiempo para lnea paralela A continuacin consideremos una unidad de arquitectura no paralela que ejecuta la misma operacin y requiere un tiempo igual a Tn para completar cada tarea. El tiempo total requerido para n tareas es NTn. La aceleracin de un procesamiento por arquitectura paralela sobre un procesamiento no paralelo equivalente se define mediante la relacin: Conforme aumenta la cantidad de tareas, n se vuelve mucho ms grande que K-1, y K+n-1 se aproxima al valor de n. Bajo esta condicin, la aceleracin 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 suposicin, la aceleracin se reduce a: Esto muestra que la mxima aceleracin terica que puede proporcionar un conducto es K, en donde K es la cantidad de segmentos en el conducto. Teora de Bases de Datos II 185 UCENM
Para duplicar la ventaja de velocidad terica de un proceso paralelo mediante unidades funcionales mltiples, es necesario construir k segmentos iguale el desempeo de k copias de un circuito de arquitectura no paralela equivalente bajo condiciones de operacin iguales. En donde estn conectados en paralelo cuatro circuitos idnticos. 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 lnea, los circuitos paralelos aceptan cuatro conjuntos de datos de entrada en forma simultnea y ejecutan cuatro tareas al mismo tiempo. En lo que se refiere a la velocidad de operacin esta es equivalente a una lnea con cuatro segmentos. Ntese que el circuito de cuatro unidades, constituye una organizacin de instruccin nica, datos mltiples en paralelo. Unidades funcionales mltiples en paralelo Existen varias razones por las que una arquitectura paralela no puede operar a su mxima velocidad terica. Los diferentes segmentos pueden requerir tiempos diferentes para completar su suboperacin. Debe elegirse el ciclo de reloj para iguale el tiempo de retraso del segmento con el mximo tiempo de propagacin. Esto provoca que los otros segmentos desperdicien tiempo mientras esperan el siguiente ciclo de reloj. Adems 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 necesitarn en un circuito de una sola unidad el cual, por lo general, puede construirse por completo como un circuito combinatorio. No obstante, la tcnica de arquitectura paralela proporciona una operacin ms rpida que una secuencia puramente serial, aunque nunca se logra por completo la mxima velocidad terica.
186
UCENM
Existen dos reas de diseo de computadoras en las que es aplicable la organizacin paralela. Una lnea aritmtica divide una operacin aritmtica en suboperaciones que se ejecutan en los segmentos de la lnea. Una lnea de instrucciones opera sobre un flujo de instrucciones al sobreponer las fases de recuperacin, decodificacin y ejecucin. En las siguientes secciones se explican los dos tipos de lneas. Lnea paralela aritmtica Por lo general, se encuentran unidades aritmticas de arquitectura paralela en computadoras de gran velocidad. Se usan para implantar operaciones de punto flotante, multiplicacin de nmeros de punto fijo y clculos similares encontrados en problemas cientficos. En esencia, un multiplicador de arquitectura paralela es un arreglo multiplicador como el que se describe en la figura 10-10, con sumadores especiales diseados para minimizar el tiempo de propagacin de acarreo mediante los productos parciales. Las operaciones de punto flotante se descomponen con facilidad en suboperaciones, como se muestra en la seccin 10-5. Ahora mostraremos un ejemplo de una unidad paralela para suma y resta de punto flotante. Las entradas para la lnea sumadora de punto flotante son dos nmeros 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. Teora de Bases de Datos II
187
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 ejecucin 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 cuntas veces debe ejecut arse 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 diseado 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 nmeros 0 significativos en la mantisa determina el nmero de corrimientos a la izquierda y la cantidad que debe restarse del exponente. El siguiente ejemplo numrico puede aclarar las sub -operaciones que se ejecutan en cada segmento. Por simplicidad utilizamos nmeros binarios. Consideremos los dos nmeros de punto flotante normalizados: X = 0.9504 X 103 Y = 0.8200 X 102 Lnea paralela de instrucciones El procesamiento por lnea paralela puede ocurrir en el flujo de datos y tambin en el flujo de instrucciones. Una lnea paralela de instrucciones lee instrucciones consecutivas de la memoria mientras, en otros segmentos, se ejecutan instrucciones anteriores.
188
UCENM
Una posible digresin asociada con tal esquema es que una instruccin puede producir un brinco fuera de secuencia.
En tal caso, debe vaciarse la lnea y deben descartarse todas las instrucciones que se han ledo de la memoria despus de la instruccin de brinco. Consideremos una computadora con una unidad de recuperacin y una unidad de ejecucin de instrucciones diseada para proporcionar una lnea de dos segmentos. Puede implantarse el segmento de recuperacin 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 ejecucin no est usando la memoria, el control incrementa el contador de programa y utiliza su valor de direccin 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 ejecucin. El mecanismo de formacin 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 recuperacin de instrucciones. El registro intermedio acta como una cola de la que el control obtiene las instrucciones para la unidad de ejecucin. Las computadoras con instrucciones complejas requieren otras fases adems de las de recuperacin y ejecucin para procesar por completo una instruccin. En el caso ms general, la computadora necesita procesar cada instruccin con la siguiente secuencia de pasos.
1. Recuperar la instruccin de la memoria 2. Decodificar la instruccin 3. Calcular la direccin efectiva
189
UCENM
4. Recuperar los operandos de la memoria 5. Ejecutar la instruccin 6. Almacenar el resultado en el lugar adecuado.
Existen ciertas dificultades que evitarn que la lnea paralela de instrucciones funcione a su velocidad mxima. Segmentos diferentes pueden necesitar tiempos diferentes para actuar sobre la informacin que llega. Se saltan algunos segmentos para ciertas operaciones. Por ejemplo, una instruccin de modo de registro no necesita un clculo de direccin efectiva. Dos o ms segmentos pueden requerir el acceso a la memoria al mismo tiempo, provocando que un segmento espere hasta que otro termine su comunicacin. En ocasiones, se resuelven los conflictos de acceso a memoria al usar dos canales de memoria para acceder las instrucciones y los datos en mdulos separados. De esta manera, pueden leerse de forma simultnea una palabra de instruccin y una palabra de datos de dos mdulos diferentes. El diseo de una lnea paralela de instrucciones ser ms eficiente si se divide el ciclo de instrucciones en segmentos de igual duracin. El tiempo que necesita cada paso para terminar su funcin depende de la instruccin y de la manera como se ejecuta. Ejemplo: Lnea paralela de instrucciones de cuatro segmentos Consideremos que pueden combinarse en un segmento de decodificacin de la instruccin y el clculo de la direccin efectiva. Adems, consideremos que la mayora de las instrucciones colocan el resultado en un registro de procesador, para que la ejecucin de la instruccin y el almacenamiento del resultado puedan combinarse en un segmento. Esto reduce la lnea paralela de instrucciones a cuatro segmentos. El ciclo de instrucciones en la CPU con una lnea paralela de cuatro segmentos. Mientras se ejecuta una instruccin en el segmento cuatro, la siguiente instruccin en secuencia se ocupa en recuperar un operando de la memoria en el segmento 3. Teora de Bases de Datos II 190 UCENM
En un circuito aritmtico separado puede calcularse la direccin efectiva para la tercera instruccin y, cuando est disponible la memoria, pueden recuperarse y colocarse en una localidad del registro intermedio FIFO la cuarta instruccin 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 instruccin 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 informacin almacenada en el registro intermedio de instrucciones. Despus, la lnea paralela y vuelva a iniciar a partir de un nuevo valor de direccin Arquitectura paralela de CPU de cuatro segmentos. El tiempo en el eje horizontal se divide en pasos de igual duracin. En el diagrama, los cuatro segmentos se representan con un smbolo abreviado. 1. FI es el segmento que recupera una instruccin 2. DA es el segmento que decodifica la instruccin y calcula la direccin efectiva. 3. FO es el segmento que recupera el operando. 4. EX es el segmento que ejecuta la instruccin. Figura 8 Temporizacin d lnea paralela de instrucciones.
Paso 1 2 3 4 5 1 FI 2 DA FI 3 FO DA FI 4 EX FO DA FI EX FO EX FI DA FI FO DA EX FO EX 5 6 7 8 9 10 11 12 13
191
UCENM
6 7
FI
DA FI
FO DA
EX FO EX
Se considera que el procesador tiene memorias de instrucciones y datos separadas, por lo que puede avanzar la operacin en FI y FO, al mismo tiempo. En ausencia de una instruccin de transferencia de control, cada segmento opera sobre instrucciones diferentes. Por lo tanto, en el paso 4, se ejecuta la instruccin en el segmento EX; el operando para la instruccin 2 se recupera en el segmento FO; en el segmento DA se decodifica la instruccin 3 y en el segmento FI se recupera de la memoria la instruccin 4. Supongamos que la instruccin 3 es una instruccin de transferencia de control. Tan pronto como se decodifica esta instruccin 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 instruccin de transferencia de control en el paso 6. Si se da la transferencia, se recupera una nueva instruccin en el paso 7. Si no se da la transferencia, puede usarse la instruc cin recuperada antes, en el paso 4. Despus, la lnea paralela continua la ejecucin hasta que se encuentra una nueva instruccin de transferencia de control. Puede ocurrir otro retraso en la lnea si el segmento EX necesita almacenar el resultado de la operacin 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 operacin. En general, existen tres dificultades principales que provocan que una l nea de instrucciones se aparte de su operacin 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.
192
UCENM
2. Surgen conflictos de dependencia de datos cuando una instruccin depende del resultado de una anterior, pero ste todava no est disponible. 3. Se producen dificultades de transferencia de control a partir de instrucciones que modifican el valor del PC.
193
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 eliminacin por duplicados?
194
UCENM
6-.Que significa Costo de la evaluacin en paralelo de las operaciones?
7-Explique en que consisten los Diseo de sistemas paralelos.
8-.Que es una Bases de Datos GRID?
9-.Caules son las caractersticas de esta arquitectura?
10-.Cuales son los servicion dentro del Grid(base datos?
195
UCENM
196
UCENM
BIBLIOGRAFIA
Todas las pantallas, Logos de Windows son marcas Registradas de Microsoft Corporacin EE.UU y otros Pases
Todas las pantallas, Logos de MAC son marcas Registradas
Cisco Reservados) Version 3.1 www.recursos-vista.es (CC) 2007

www.aulaclick.com www.adlszone www.microsoft.com www.ubuntu Sistemas operativos pearsons www.lawebdelprogramador www.abcdatos.com
Networking Academy Program(Derechos
197
UCENM
198
UCENM

Teoría Bases Datos II UCENM

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Teoría Bases Datos II UCENM

Загружено:

Авторское право:

Доступные форматы

Teora Bases Datos II Universidad Cristiana Evanglica Nuevo Milenio (UCENM)

Teora de Bases de Datos II

4. Bases de Datos Distribuidas.

5. Base de Datos Paralelas.

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Sintaxis de la sentencia SELECT (consultas simples)

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Lista el nombre, oficina, y fecha de contrato de todos los empleados.

..Como ttulo de la primera columna .aparecer fabricante en vez de idfab

Lista la ciudad, regin y el supervit de cada oficina.

SELECT idfab, idproducto, descripcin, (existencias * precio) AS valoracin FROM productos

SELECT nombre, MONTH(contrato), YEAR(contrato) FROM repventas

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

ORDER BY precio DESC;

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Y el resultado quedaria asi:

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

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.

Teora de Bases de Datos II

7-. Que significado tiene el smbolo 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.

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Gestin de transacciones y administrador de la base de datos

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Teora de Bases de Datos II

Figura C. Ejecucin distribuida de transacciones.

Teora de Bases de Datos II

Teora de Bases de Datos II